Hallo alle zusammen!

Ich bin momentan dabei eine Anwendung von BDE/SQL Links auf ADO umzustellen. Die alte Anwendung erlaubte eine Anmeldung am SQL Server sowohl über SSPI als auch über SQL Login. Zum einen konnte man ein SQL Login durch einen Kommandozeilenparameter erzwingen und zum anderen wurde das SQL Login automatisch angeboten, wenn die SSPI Authentifizierung im ersten Anlauf fehlgeschlagen war.

Beide Modi einzeln habe ich auch schon relativ problemlos mit ADO umsetzen können.
Für die automatische/SSPI-Anmeldung würde der ConnectionString also so aussehen:

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=MeineDatenbank;Data Source=MeinServer

...und für den manuellen/SQL-Login so:

Provider=SQLOLEDB.1;User ID=MeinUserName;Password=MeinPasswort;Persist Security Info=False;Initial Catalog=MeineDatenbank;Data Source=MeinServer

...wobei ich User ID und Password nicht wirklich über den ConnectionString setze, sondern über die Properties Collection der ADOConnection.

Soweit so gut. Das Problem beginnt, wenn ich zuerst die SSPI-Authentifizierung versuche, diese dann fehlschlägt und ich dann das SQL-Login folgen lassen will. Da der ConnectionString prinzipiell dynamisch sein soll (d.h. nicht hartkodiert ist), kann ich ihn nicht einfach komplett neu schreiben, weil dabei sonst möglicherweise wichtige zusätzliche Properties verloren gehen würden. Ich muß also den alten ConnectionString bzw. die alten Connection.Properties ändern. Wenn ich aber einfach Properties['Integrated Security'] := '' setzte, versucht Delphi trotzdem den SSPI-Login anstatt dem SQL-Login. Auch ein Setzen des Properties auf Unassigned, NIL oder Null hat keine Wirkung (beim Sezten auf 'No' oder ähnliches gibt es zumindest einen Fehler). Offensichtlich reicht die schiere Existenz des 'Integrated Security'-Properties schon aus, um die SSPI-Authentifizierung zu erzwingen. Der SQL-Login funktioniert nur, wenn dieses Property komplett fehlt.

Die Frage ist nur, wie bekomme ich das Property wieder weg, wenn es erst einmal dringewesen ist? Die Properties-Collection bietet, so weit ich es erkennen kann, keine Möglichkeit, einzelne Items wieder zu entfernen. Muß ich wirklich erst alle alten Properties irgendwo zwischenspeichern, den ConnectionString leermachen und dann alle Properties bis auf "Integrated Security" wieder zurückschreiben?

Hat vielleicht noch jemand eine andere Idee?

Grüße,

Oliver

Hi, in meinen EDB Komponenten (siehe Open Source) habe ich das so in etwa gemacht:

Das stand mal irgend wo in der MS SQL Server Doku drinne

zusammenfalten · markieren

Delphi-Quellcode:

function TEDBConnect.CreateDBConnection(AEDBTyp: TEDBTyp; DataSource: string; InitDB: string; UN: String; PW: String; ShowMsg: boolean=false; AccessDBPW: String = ''; WindowsSecurity: boolean=false): boolean;
var
  asTimeout, asDataSource, asUN, asPW, asInitDB, ConnectionString: AnsiString;
  iReturn: Integer;
  OldCursor: TCursor;
begin
  result := false;
  asInitDB := '';
  asUN := '';
  asPW := '';
  LastErrorToZero;
....
                         ConnectionString := 'DRIVER={SQL Server}';
                         asDataSource := ';SERVER='+DataSource;
                         asInitDB := ';Initial Catalog='''+InitDB+'''';


                          if WindowsSecurity then // <------ Wenn Windows Sicherheit dann Integrated Security=SSPI ansonnsten Persist Security Info=True
                             ConnectionString := ConnectionString + ';Integrated Security=SSPI' + ';Persist Security Info=False'
                          else begin
                             ConnectionString := ConnectionString + ';Persist Security Info=True';
                             asUN := UN;
                             asPW := PW;
                          end;// ------>>
                       end;
....
  ConnectionString := ConnectionString + asDataSource;
  if trim(asInitDB) <> '' then
     ConnectionString := ConnectionString + asInitDB;
  if trim(asUN) <> '' then
     ConnectionString := ConnectionString + ';User ID=' + asUN;
  if trim(asPW) <> '' then
     ConnectionString := ConnectionString + ';Password=' + asPW;
  if trim(AccessDBPW) <> '' then
     ConnectionString := ConnectionString + ';Jet OLEDB:Database Password='+AccessDBPW;

// Showmessage(ConnectionString);
  // öffne Eine verbindung mit dem ConnectionString
  if OpenConnection(ConnectionString, ShowMsg, asUN, asPW) then begin
     result := true;
  end;
end;

Zitat von clues1:

Hi, in meinen EDB Komponenten (siehe Open Source) habe ich das so in etwa gemacht:
function TEDBConnect.CreateDBConnection(AEDBTyp: TEDBTyp; DataSource: string; InitDB: string; UN: String; PW: String; ShowMsg: boolean=false; AccessDBPW: String = ''; WindowsSecurity: boolean=false): boolean;

Schön und gut, aber:

1. Dafür müßte ich mir die einzelnen Connection-Parameter nochmal extra irgendwo merken, was ich eigentlich vermeiden möchte, um so flexibel wie möglich zu bleiben. Idealerweise schreibt die Installationsroutine des Programms den kundenspezifischen ConnectionString in die Registry und das Programm verwendet diesen dann beim Start als Ausgangswert. Um in diesem Szenario Deine Prozedur verwenden zu können, müßte ich den vorhandenen ConnectionString ja erst wieder in seine Bestandteile parsen, was mir eigentlich zu aufwendig erscheint.

2. Funktioniert auf diese Weise auch das zweistufige Login, auf das meine Frage ja eigentlich gerichtet war? D.h. soetwas wie:

markieren

Delphi-Quellcode:

if not CreateDBConnection(..., True) then
  begin
    <Username und Passwort abfragen>
    CreateDBConnection(..., False);
  end;

Meinen Tests nach vermutlich schon, aber es bleibt immernoch Problem 1...


Am idealsten wäre es meiner Meinung nach, wenn ich entweder einfach das Integrated Security Property löschen könnte oder zumindest auf einen Wert setzen könnte, der bewirkt, daß eben keine SSPI-Authentifizierung stattfindet. Sowas wie 'No' oder 'False' oder so... Bis jetzt hab' ich aber weder auf MSDN noch per Google irgendwas derartiges finden können.

Erschwerend kommt hinzu, daß ich mittlerweile festgestellt habe, daß anscheinend kein "gemischter" Zugriff auf die Verbindungseigenschaften möglich ist: Sobald ich einmal schreibend auf die Properties zugegriffen habe, werden alle programmatischen Änderungen am ConnectionString ignoriert...

Trotzdem vielen Dank für den Vorschlag! Vielleicht läuft's ja am Ende doch noch auf's ConnectionString-parsen raus, dann kann ich damit denke ich doch noch was anfangen.

Oliver

1. Nochmal ganz langsam. Wie melden Sich deine Benutzer nun an der Datenbank an? Windows Sicherheit oder SQL Login, und wann? Währe das vieleich auch ne möglichkeit für dich, via Applications Rolle?

Zitat von clues1:

1. Nochmal ganz langsam. Wie melden Sich deine Benutzer nun an der Datenbank an? Windows Sicherheit oder SQL Login, und wann?

Genaugenommen ist die zweite Stufe (d.h. der SQL-Login) inzwischen nur noch für Admins gedacht, die von einer Benutzerarbeitstation mit anderen Rechten an die Datenbank müssen ohne den jeweiligen Benutzer von Windows abmelden zu müssen (in dem Fall erzwingt man das manuelle Login mittels Kommandozeilen-Parameter oder "geheimer" Tastenkombination), bzw. um sich an der Datenbank anmelden zu können auch wenn man bei Windows gerade nicht als gültiger DB-Nutzer angemeldet ist (sondern z.B. als lokaler Admin - in dem Fall sollte dann der zweistufige Fallback-Mechanismus zum tragen kommen).

Die eigentlichen Benutzer sollen sich normalerweise immer nur per Windows Sicherheit anmelden, für die gibt es auch keine individuellen DB-Accounts; das wird dann nur über Gruppenzugehörigkeiten gesteuert. Früher haben die User sich allerdings auch über SQL-Login angemeldet. Ist halt eine "gewachsene" Lösung...

Zitat:

Währe das vieleich auch ne möglichkeit für dich, via Applications Rolle?

Was meinst Du?

(Vielleicht noch als Erläuterung: Von der reinen Datenbankseite habe ich leider (noch) nicht wirklich so fürchterlich viel Ahnung, weswegen ich da manchmal mit Begrifflichkeiten etwas ins Trudeln komme - ich bin mehr für das Frontend zuständig - wir haben da mittlerweile eine recht strenge Arbeitsteilung)

Also Applicationsrollen sind sowas wie Benutzerrechte, nur das diese Während einer schon bestehenden Verbindung zum SQL Server z.b. Windows Sicherheit noch weitere Rechte vergeben kann. Diese dann Applictionsabhängig sein können. Z.B. Ein Benutzer öffnet mit seinem Windows Benutzer die Verbindung über Excel und darf nur Lesen. Da aber eine Bestimmte Excel Datei (Personal Daten) die Daten unbedingt schreiben muss, kann mann eine Applictionsrolle erstellen (z.b. Excel_PersDaten) und gibt diese AppRole das Schreiben recht auf die Tabelle. Diese Rolle wird dann von Excel ausgeführt und Prommt hat mal Schreib rechte.

Normal:
Windows Benutzer -> ExcelDatei (o. Eig. Programm) -> SQL-Server -> Windows Authentifizierung -> Tabelle nur lesend zu griff.

Mit AppRolle
Windows Benutzer -> ExcelDatei (o. Eig. Programm) -> SQL-Server -> Windows Authentifizierung -> ExcelDatei (o. Eig. Programm) rufft Approlle auf -> Tabelle schreibend zu griff + Lesend durch Windows Authentifizierung.
!! Dies findest du in der MS SQL Dokumentation !!