Auf meinem Weg, die Nuancen des Benutzer-Identitätswechsels in Windows zu meistern, hatte ich zuerst ein Problem damit, dass der Identitätswechsel zu einer entfernten Datenbank überhaupt stattfand (siehe diese SO-Frage ), aber das habe ich schließlich herausgefunden. Meine nächste Hürde ist das Rückgängigmachen / Annullieren / Rückgängigmachen (wählen Sie Ihr Lieblingsverb), den Identitätswechsel.
Ich habe ein paar verschiedene Identitätswechsel-Bibliotheken ausprobiert, die mir glaubwürdig erscheinen:
Die Ergebnisse sind identisch mit beiden Bibliotheken. Best Practices schreiben die Verwendung des Anmeldetyps LOGON32_LOGON_NEW_CREDENTIALS vor (siehe Windows-API LogonUser-Funktion ) für eine Remote-DB-Verbindung. Wenn ich das hier mache, ist das, was mein Beispielcode erzeugt:
%Vor%Die einzige Problemumgehung, die ich gefunden habe, besteht darin, den Anmeldetyp LOGON32_LOGON_INTERACTIVE zu verwenden, und dann bekomme ich Folgendes:
%Vor%Aus der knappen Beschreibung des WindowsImpersonationContext.Undo Es scheint, als hätte es in Szenario A funktioniert.
Ist es möglich, mithilfe des Anmeldetyps LOGON32_LOGON_NEW_CREDENTIALS zurückzukehren?
Dank der Eingabe von Harry Johnston (in den Anmerkungen zu der Frage) und Phil Harding (in einer separaten Mitteilung) konnte ich feststellen, dass der SQL Server Verbindungspooling war der Schuldige hier. Da das Pooling durch die Eindeutigkeit der Verbindungszeichenfolge bestimmt wird, beobachtete ich durch leichtes Variieren der Verbindungszeichenfolge (z. B. das Umkehren der Reihenfolge der Parameter oder sogar das Hinzufügen eines Leerzeichens am Ende) das erwartete Verhalten.
%Vor%Ich habe in die Interna des Verbindungspoolings geforscht, und es stellt sich heraus, dass Windows-Anmeldeinformationen überhaupt nicht als Teil des Verbindungspooling-Schlüssels betrachtet werden. Nur SQL-Logins würden berücksichtigt.
Wenn also eine Verbindung verfügbar ist, die unter Benutzer A geöffnet wurde und Sie sich jetzt als Benutzer B ausgeben, wird sie weiterhin verwendet, und SQL wird Sie als Benutzer A sehen. Umgekehrt ist das auch wahr.
Der Ansatz, die Verbindungszeichenfolge für die zwei verschiedenen Benutzer leicht zu ändern, ist in Ordnung. Sie können dies tun, wenn Sie einen "normalen" Benutzer haben und Sie sich dann für einen "erhöhten" Benutzer ausgeben müssen. Natürlich möchten Sie keine - für alle Ihre Anwendung
Wenn Sie Ihre Verbindungszeichenfolge anpassen, können Sie den impersonierten Benutzernamen an die Felder Application Name oder Workstation ID anhängen. Dies hätte den Vorteil, dass für jeden imitierten Benutzer ein eigener Pool eingerichtet wird.
Tags und Links c# windows impersonation