Frage ODBC Treiber mit sql authentification

Question

Wir haben eine alte Applikation welche über einen ODBC-Treiber auf dden SQL-Sevrer zugreift.

 

Der Zugriff soll in Zukunft nur noch über SQl-Authentifizierung erfolgen.

Nun habe ich den ODBC-Treiber auf sql authentification geändert, jedoch wird das Paswort nicht gespeichert.

 

Gbt es eine Möglichkeit das Passsort im ODBC-Treiber zu speichern oder muss die Anwendung angepasst werden?

 

Grüße

Christian

Answer 1

Hallo Christian,

nein diese Möglichkeit gibt es nicht. Das dort einzugebende Passwort wird  ausschliesslich für den Abruf der Konfigurationsdaten verwendet
und - aus Sicherheitsgründen - niemals gespeichert. In diesem Falle müsste die Anwendung angepasst werden, so das diese mit einer wie:

DSN=DSNName;UID=xyz;PWD=Kennwort;

 

---

Gruß Falk

Answer 2

Es muss doch auch noch eine andere Lösung geben.

In unserem Falle können wir die Anwendung nämlich nicht ändern!

Es handelt sich hierbei um einen Windows-Service

 

Grüße

 

Christian

Answer 3

Es muss doch auch noch eine andere Lösung geben.

In unserem Falle können wir die Anwendung nämlich nicht ändern!

Es handelt sich hierbei um einen Windows-Service

 

Grüße

 

Christian

Hallo Christian,

ja, die gibt es.
Lege den ODBC-String als File-DSN an.
Anschließend das File mit Texteditor öffnen und den Zusatz PDW hinzufügen.

Ich halte es zwar für fragwürdig aus Sicherheitsperspektive aber wenn es sein soll.

Ausserdem bin ich der festen Überzeugung, daß Eure Altanwendung auch mit integrated Security arbeiten wird, wenn man den Accounts die gleichen Berechtigungen gibt, wie dem SQL Account.

Wenn der Windows Server unter einem Service-Account läuft, dann kannst Du auch diesen Account zur DB hinzufügen und der Zugriff erfolgt über "integrated security"

Nur bei Application Roles wird es etwas komplizierter

---

Uwe Ricken

MCITP Database Administrator 2005
MCITP Database Administrator 2008
MCITP Microsoft SQL Server 2008, Database Development

db Berater GmbH
http://www-db-berater.de

Answer 4

Ausserdem bin ich der festen Überzeugung, daß Eure Altanwendung auch mit integrated Security arbeiten wird, wenn man den Accounts die gleichen Berechtigungen gibt, wie dem SQL Account.

Wenn der Windows Server unter einem Service-Account läuft, dann kannst Du auch diesen Account zur DB hinzufügen und der Zugriff erfolgt über "integrated security"

Wir haben die Herausforderung dass auf die Datenbank nur noch über die SQL-Authentifizierung zugegriffen werden können soll, deshalb können wir die "integrated security" nicht verwenden.

Answer 5

Nun, das klingt fast nach dem Zusammentreffen von einer unaufhaltsamen Kraft auf ein unbewegliches Objekt...

Ihr habt folgende Anforderungen, beziehungsweise Fakten:

1. Datenbankzugriff nur noch über die SQL-Authentifizierung.
2. Anwendung nicht änderbar.

Damit hast du nur die einfache Möglichkeit über die DSN, falls deine Anwendung dies unterstützt. Das hat Uwe schon geschrieben.

Allerdings gibt es noch eine andere Möglichkeit: Implementiert euren eigenen ODBC-Treiber als Proxy zwischen eurer Anwendung und dem Datenbankserver. Sollte für jeden guten C/C++-Programmiere ein leichtes sein ;)

Nun bleibt es bei euch diese Situation zu bewerten und dei Ausgangslage neu zu definieren.

Wobei sich mir die Frage stellt, warum man die Anwendung nicht ändern kann. Wenn sie von Bedeutung ist und nicht geändert werden kann, muss sie ersetzt werden.

Answer 6

... zugegriffen werden können soll ...

Hallo Christian,

letztedlich würde das ja (indirekt).

Da Euer Service ja mit einem Serviceaccount aus dem AD läuft, würde doch dieser Account auch den Zugriff auf die DB realisieren.
Also wenn ich den Auftrag bekäme, ein bewährtes Sicherheitssystem durch ein anfälliges System zu ersetzen, würde ich erst mal auf den Busch klopfen.

Nach meinem Verständnis sieht die Struktur doch wie folgt aus:

Client -> ApplicationService -> Datenbank
Uwe   -> ServiceAccount     -> CREATE LOGIN [ServiceAccount] FROM WINDOWS

Reicht Euer Applicationservice jedoch die Credentials des Clients durch, wäre das was anderes.
Aber auch da würde ich eine AD-Gruppe erstellen und alle Benutzer der APplikation in diese Gruppe bündeln.

Anschließend die entsprechenden Berechtigungen auf dem SQL Server FÜR DIE AD GRUPPE einrichten

Es ist schon beschämend, was manche "Programmierer" und "Vendoren" auf die Beine stellen.
Da muß man sich ernsthaft fragen, ob die SQL Server nicht mit Access oder dBase verwechselt haben.

Frechheit, daß sowas dann auch noch Geld kostet. :)

 

---

Uwe Ricken

MCITP Database Administrator 2005
MCITP Database Administrator 2008
MCITP Microsoft SQL Server 2008, Database Development

db Berater GmbH
http://www-db-berater.de

Answer 7

Hallo Christian

Christian Kiefer wrote:

Nun habe ich den ODBC-Treiber auf sql authentification geändert, jedoch
wird das Paswort nicht gespeichert.

Du hast nur das Passwort für das einlesen der Standard Werte (und Datenbanken) für diese Connection eingegeben. Und wenn diese mal eingelesen sind, dann muss das ja nicht mehr gemacht werden. Das wird nur für die Konfiguration der ODBC Datenquelle verwendet, nicht für den Zugriff auf die Daten.

Gbt es eine Möglichkeit das Passsort im ODBC-Treiber zu speichern oder
muss die Anwendung angepasst werden?

Nein, das gibt es nicht. Du musst das Login beim Aufbau der Verbindung über den ODBC Treiber angeben.

Ich frage mich allerdings, ob dieser Wechsel auf SQL Server Authentication die richtige Entscheidung ist. Wenn der SQL Server im AD verwaltet wird und dort auch Gruppen für die Benutzer definiert sind, wäre es IMO besser und sicherer, die Verwaltung der Zugriffsrechte im Active Directory vorzusehen und das zu delegieren. Dann brauchst Du keine Logins und Passworte mehr irgendwo zu übergeben. Der Benutzer meldet sich im AD an und erhält dann automagisch Zugriff auf die SQL Server mit den definierten Berechtigungen, die er eben braucht.

Gruss
Henry