Zugriff auf MSSQL2008 mit User aus trusted domain

[PASST]

Hallo allerseits,

habe ein Programm, welches auf einen MSSQL Server 2008 Express zugreift. Die Anmeldung am MSSQL erfolgt über einen eigenen MSSQL-User. Beim Start des Programms setze ich folgenden Connection-String:

Delphi-Quellcode:

    ConnectionString := 'Provider=SQLNCLI10.1;' +
                        'Integrated Security="";' +
                        'User ID=<dbusername>;' +
                        'Password=<dbuserpw>;' +
                        'Persist Security Info=True;' +
                        'Initial Catalog=' + sDBKatalog + ';' +
                        'Data Source=<MSSQLSERVERNAME>;' +
                        'Application Name=MeinProgramm;' +
                        'Initial File Name="";' +
                        'Server SPN=""';

Beim ersten Öffnen einer Tabelle wird mir aber eine Fehlermeldung angezeigt:
"cannot open database <dbname> requested by the login. the login failed."
Im Log des MSSQL Servers steht dann folgende Meldung:
"Login failed for user <user der trusted domain>. Reason: failed to open the explicitly specified database"

Warum will sich das Programm mit dem Windows-User anmelden obwohl ich im Connection-String einen eigenen DB-User angebe?

Gruß,
Peter

[generic]

Du brauchst nur folgende setzen:

Delphi-Quellcode:

Integrated Security=SSPI;
Persist Security Info=False;

User und PW bleiben dann weg.

[PASST]

Wenn ich mir die Beschreibung zum Parameter "integrated security" des Connection Strings anschaue "Accepts the value "SSPI" for Windows Authentication", dann ist das genau die falsche Lösung. Ich möchte eben unabhängig von der Windows Authentifizierung mit dem DB-User mich anmelden.

Oder verstehe ich da etwas falsch?

[generic]

Wenn du dich mit dem DB-User anmelden möchtest:

Delphi-Quellcode:

User ID=test;
Password=testpwd;
Persist Security Info=True;

Initial Catalog=DBNAME;
Data Source=SERVER

Mehr brauchst du nicht angeben (natürlich noch den Provider).

[PASST]

Wie du den von mir oben geposteten Connection String entnehmen kannst, habe ich genau diese Einträge gesetzt.

[muenster]

Hi,

Du hast da nichts falsch gemacht. Der SQL - Server wird standardmäßig mit der Win-Authentifikation installiert. Er kann mit dem SQL User schlicht nichts anfangen. Also: MS-SQL Server auf die Authentifikation SQL und Win umstellen, den User einrichten und aktivieren und los gehts. Im Netz kursieren verschiedene Methoden, aber das Tool MS SQL Server Management Studio kann das auch. Einfach starten, und beim verbundenen Server mit Rechtsklick Eigenschaften auswählen. Dort unter Sicherheit SQL Server- und Windows-Authentifizierungsmodus auswählen, Server neu starten und gut ist. Hab mir auch dem Problem einen Wolf gesucht.

Viele Grüße

[PASST]

Das kann eigentlich nicht sein. Der MSSQL Server ist bereits auf Windows- UND SQL Server Authentifizierung eingestellt.

[taveuni]

Hallo,

Was passiert den wenn Du mit dem SQL Server Management Studio
per SQL User verbindest?

Gruss

[generic]

Nimm mal das "Integrated Security=" ganz raus.

[PASST]

@generic
Wenn ich das "Integrated Security=" weglasse, dann erhalte ich die obige Fehlermeldung "cannot open database <dbname> requested by the login. the login failed."

@taveuni
Das Verbinden mit diesem (!) SQL-User lässt das Management Studio nicht zu. Dieser SQL-User hat die Server-Rolle "public" zugeteilt.
(Ich muss gestehen, ich kenne mich mit den Berechtigungen nicht gut aus!)

[muenster]

Das einloggen muss(!) bei Management Studio mit dem Windows Administratoren erfolgen, der beim installieren angegeben wurde. Die Weigerung den SQL User anzumelden ist eine Folge der Einstellung.

Viele Grüße

[generic]

Du hast also ein Problem mit dem Userkonto.

Prüfe mal bitte folgendes:

* Darf der User sich am Server anmelden
* Hat der User Zugriffserlaubnis auf die Datenbank
* Hat der User Zugriff auf die Tabellen

[PASST]

ja, der User darf sich anmelden und mit der Datenbank verbinden. Ansonsten ist dem User die "public"-Server Rolle zugewiesen.

[generic]

Welche Rechte hat die Rolle Public auf den Tabellen?

[muenster]

Ist der User in den Sicherheitseinstellungen auf "Aktiv" gesetzt?
Ist die Berechtigung zur Verbindung mit dem Datenbankmodul erteilt?

[PASST]

Hm, eines wundert mich. Wenn ich mir das Log des MSSQL Servers anschaue, wird mir angezeigt, dass das Login des Windows-Users fehlgeschlagen ist. Es wird gar nicht erst der SQL-User verwendet, obwohl ich im Connection String dies so angegeben habe mit dem Parameter "Integrated Security". (Womit wir wieder am Anfang des Threads sind...)

[generic]

Primär solltest du jetzt erstmal versuchen dich über die MS Tools an dem Server mit dem User anzumelden.

Wie schon jemand geschrieben hat, solltest du noch einmal prüfen, dass der Server beide Verfahren akzeptiert.

- konfigurierst du die richtige Instanz?
- Server ggf. neustarten.

So lange der Connect nicht mit den MS-Tools funktioniert, wird er definitiv auch nicht mit den ADO laufen.

[PASST]

Zuerst hat es mit dem Login des SQL-Users über das Management Studio nicht geklappt. Erst nachdem ich die Security-Login Einstellungen "Permission to connect to database engine = GRANT" und "Login = ENABLED" erneut abgespeichert habe, kann ich mich auch mit diesem SQL-User anmelden. Ein Bsp-SQL-String lässt sich auch erfolgreich abrufen.

Dagegen erhalte ich bei meinem Programm immer noch die Fehlermeldung "cannot open database <dbname> requested by the login. the login failed". Obwohl ich dort im Code und zwar erst zur Laufzeit den Connection-String setze.

[generic]

Kannst du dir mit den Microsoft Tools die Datenbank und Tabellen unter Benutzung des Users anzeigen lassen?

[PASST]

ja

[generic]

Ruf mal bitte das Programm "cliconfg" auf.
Ist mindestens ein Protokoll aktiviert, welches auch auf dem Server aktiv ist?

[PASST]

TCPIP und NamedPipes sind aktiviert, entsprechend wie sie auf dem SQL Server aktiviert sind.

Könnte es sein, dass ADO Probleme macht?

Ich habe jetzt mal ein Test-Programm erstellt, welches mit dem SQL-User connecten und ein SQL-Query ausführen soll. Das folgende ist der einzige Code:

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
begin

  with ADOConnection1 do
  begin
    ConnectionString := 'Provider=SQLNCLI10.1;' +
                        'User ID=mein_SQL_User;' +
                        'Password=mein_pw;' +
                        'Integrated Security="";' +
                        'Persist Security Info=True;' +
                        'Initial Catalog=DatenbankName;' +
                        'Data Source=SERVERNAME;' +
                        'Application Name=Mein_Programm_Mame;' +
                        'Initial File Name="";' +
                        'Server SPN=""';
    CommandTimeout := 120;
    LoginPrompt    := False;
  end;

  with ADOQuery1 do
  begin
    Close;
    SQL.Clear;
    SQL.Add('Select * from tabelle');
    open;
    first;
  end;

end;

Wenn ich dieses Programm kompiliere und anschließend ausführe, funktioniert das nur ohne Fehlermeldung, wenn ich es mit einem Windows-User ausführe, der auch am MSSQL Server (immer noch die Express Version!) als Login-User eingetragen ist. Verwende ich einen dort nicht eingetragenen Windows-User, so wird mir der übliche Fehler "login failed" angezeigt und im SQL-Server-Log steht, dass "Login failed for <Windows-User>".
Letztendlich schließe ich daraus, dass der SQL-User von der ADOConnection überhaupt nicht verwendet wird. Was mache ich da falsch?

[taveuni]

Glücklicherweise muss ich mich seit langem nicht mehr mit diesem
ADO Gedöns rumschlagen. Mit den paar Euro für die Corelabs/Devart Compos
bist Du für immer glücklich.
Aber zurück zu Deinem Problem:
Warum verwendest Du den NativeClient und nicht OLEDB?
Ich habe dies noch gefunden:
http://msdn.microsoft.com/en-us/library/ms130978.aspx
Da steht irgendwas von "DataTypeCompatibility=80" was man im Connectionstring
implementieren soll.

Kann das das Problem sein?

Gruss Werner

[muenster]

Falls Du Win XP als Client benutzt, dann kann Dir dieser Link vllt. helfen:

http://www.microsoft.com/downloads/d...1-9e8b9d835cdc

Der Abwärtskompatibilitätspatch bringt den ODBC auf den entsprechenden Kenntnisstand damit der Client den Server findet.

Viele Grüße#

Karsten

[generic]

Was mich jetzt noch verwundert, dass du eine andere Fehlermeldung bekommst, wenn du mal mit Integrate Sec und ohne arbeitest.

Evtl. ist im Connectstring ein Tippfehler oder deine Variablen User,PW, Server oder DB enthalten Zeichen, welche den String aus den tritt bringen.

Versuch mal in Delphi den String neu zusammen zu klicken und dann ein live Test zu machen.
Damit meine ich "test connection" und dann "active=true" im Dataset.

[PASST]

@generic
Ich habe jetzt einen ConnectionString zusammmengeklickt. Dabei habe ich die Variante "Use a specific user name und password" gewählt und nicht "Use Windows NT Integrated security".
Das Ergebnis schaut auch genau wie mein bisheriger String aus. (Das Kennwort wird dabei nicht dargestellt.)

Delphi-Quellcode:

Provider=SQLNCLI10.1;Integrated Security="";Persist Security Info=False;User ID=mein_SQL_User;Initial Catalog=meine_Datenbank;Data Source=mein_SQL_Server;Initial File Name="";Server SPN=""

Komisch ist weiterhin, dass das SQL Server Log (oder auch das Windows Eventlog) sagt "Login succeeded for user 'mein_Windows_User'. Connection made using Windows authentication. [CLIENT: <meine_IP>]"


Starte ich das kompilierte (Test-)Programm mit einem anderen Windows-User, so erhalte ich die übliche Fehlermeldung "Login failed for user 'anderer_Windows_User'".

Daraus schließe ich, dass die ADO-Komponente weiterhin versucht, sich mit dem Windows-User und nicht mit dem in dem Connection String angegebenen SQL-User mit dem MSSQL Server zu verbinden.

Was nü?