Ich versuche, eine Verbindung mit SQL Server mit Windows-Authentifizierung herzustellen. Microsoft C # - und C-Quellen finden Sie unter NetCpp .
In Delphi habe ich Code wie folgt:
%Vor% Der SPN, den ich bekommen habe, ist wie MSSQLSvc/3R-XP:MSSQL2008 (Client und Server beide auf 3R-XP, Instanz MSSQL2008 ). InitializeSecurityContext hat den Status SEC_I_CONTINUE_NEEDED . Alles funktioniert ohne Fehler, außer dass der Server keine der Zeilen aus der Abfrage zurückgibt, nur TDS_DONE.
Das SQL Server-Protokoll sagt:
Anmeldung erfolgreich für Benutzer '3R-XP \ me'. Verbindung mit Windows-Authentifizierung hergestellt. [KUNDE: 192.168.0.100]
Ich habe auch versucht, OLEDB und meine gesendeten und empfangenen Daten zu vergleichen. Ich kann das erste von OLEDB gesendete Paket aufgrund der SSL-Verschlüsselung nicht sehen. Meine SSPI Login Daten
%Vor%Die Serverantwort von OLEDB (Verbindung zu einem anderen PC aufgrund der Tatsache, dass WinPCAP nur mit realen Adaptern arbeiten kann, also der Hostname ist "hp-6320" und der Clientname ist hier "3R-Win7") ist:
%Vor%SQL Server-Antwort mit meinem Code (Maschine '3R-XP')
%Vor%Es sieht genauso aus. Aber nach diesem zweiten InitializeSecurityContext gibt OLEDB den Wert
zurück %Vor%, während für meinen Code
zurückgegeben wird %Vor%Wie Sie sehen können, sind alle Strukturen leer (Größe 0, 0, Offset 48). Stimmt irgendetwas nicht? Wie repariere ich das Zeug? Ich habe bereits verschiedene Flaggen usw. ausprobiert, die Ergebnisse sind gleich oder sogar schlechter. OLEDB funktioniert, so scheint es, dass der Server richtig konfiguriert ist.
Mit WinAPIOverride habe ich festgestellt, dass die Authentifizierung Bindings verwendet (siehe QueryContextAttributes SECPKG_ATTR_UNIQUE_BINDINGS) aus dem SSL-Handshake in der Verhandlung abgerufen InitializeSecurityContext als SECBUFFER_CHANNEL_BINDINGS-Mitglied.
Bisher habe ich einen SSPI-basierten SSL-Handshake gemacht, habe Bindings , das aussieht wie
hat festgestellt, dass diese leere NTLMSSP-Nachricht korrekt zu sein scheint (mit etwas mehr am Ende), während Client und Server auf demselben Rechner den ODBC-Treiber wie
senden %Vor%Remote letzte Authentifizierungsdaten sieht wie (ODBC-Treiber)
aus %Vor%während SSPI mit Bindings etwas größer aussieht (8 erste Bytes hier ist TDS-Paketheader)
%Vor% QueryContextAttributes (@FCtxHandle, SECPKG_ATTR_NEGOTIATION_INFO, @NegInfo) gibt den Status SECPKG_NEGOTIATION_COMPLETE zurück, damit alles in Ordnung ist, das Serverprotokoll zeigt "Authentifizierung erfolgreich", aber es sind immer noch nicht genug Rechte vorhanden, um Ergebnisse von Abfragen oder Serverfehlern zu erhalten. co_de% während einfache Abfragen wie "SET LOCK TIMEOUT 100" ohne Fehler laufen.
Also meine Gedanken, dass Windows-Authentifizierung in den Augen des eigenen Erstellers nicht sicher genug aussieht, um es einigen Drittanbieter-Anwendungen zu erlauben. "Cannot find the object "all_types" because it does not exist or you do not have permissions" account aktiviert und haben Berechtigungen zum Lesen / Schreiben von Daten und es funktioniert über ODBC-Treiber.
Tags und Links sql-server delphi sspi