SQLCLR Identitätswechsel hält die Dienstidentität

Question

mit Ich habe den folgenden Code:

Public Shared Function MyTest() As SqlString 

    Dim rc As String = Nothing 
    Dim impersonatedUser As WindowsImpersonationContext = Nothing 
    If SqlContext.IsAvailable Then 
     If SqlContext.WindowsIdentity IsNot Nothing Then 
      impersonatedUser = SqlContext.WindowsIdentity.Impersonate 
     End If 
    End If 
    Try 
     rc = System.IO.File.Exists("C:\Data Files\Test\42.txt").ToString 
    Catch ex As Exception 
     Return ex.Message 
    Finally 
     If impersonatedUser IsNot Nothing Then 
      impersonatedUser.Undo() 
     End If 
    End Try 

    Return rc 
End Function 

In SQL die declation der Baugruppe wie folgt:

CREATE ASYMMETRIC KEY aKeyCLR FROM EXECUTABLE FILE = '$(BASE)CLR.dll' 
CREATE LOGIN CLRLogin FROM ASYMMETRIC KEY aKeyCLR 
GRANT UNSAFE ASSEMBLY TO CLRLogin 

Die Funktion erstellen:

CREATE FUNCTION dbo.Test() 
RETURNS NVARCHAR(4000) 
AS 
    EXTERNAL NAME myStuff.[CLR.FileFunctions].[MyTest] 
GO 

Wenn ich SELECT Test() ausführen, wird der Dateizugriff immer noch vom Konto "NT SERVICE \ MSSQLSERVER" ausgeführt. Ich bin am SQL-Server mit Windows-Authentifizierung angemeldet und würde erwarten, dass dieser Benutzer den Dateizugriff durchführt.

Was fehlt mir hier?

Answer 1

Ihr Code scheint korrekt zu sein. Sie können testen, indem Sie den Lesezugriff nur auf Ihre Windows-Anmeldung zulassen und dann die Exists() in string _Test = ReadAllText() oder etwas Ähnliches ändern.

Was Sie zuerst sehen, ist die Hauptidentität des Prozesses. Die Identitätsübernahme eines anderen Kontos ersetzt nicht den ursprünglichen Sicherheitskontext. Es ist lediglich eine neue SID (Sicherheits-ID), mit der der Prozess ausgeführt werden kann. Tatsächlich ändert die Identität eines Betriebssystemkontos den "aktiven" Benutzer in der Registrierung (d. H. HKEY_CURRENT_USER) nicht, noch setzt es die Umgebungsvariablen zurück (d. H. PATH, TEMP, usw.); Diese Aktionen passieren bei einer vollständigen Anmeldung.

Innerhalb von SQL Server, wenn Sie sich über EXECUTE AS imitieren, können Sie die Hauptidentität der Sitzung über die eingebaute Funktion ORIGINAL_LOGIN() sehen.

Answer 2

Durch Klicken auf einen Schritt weiter in ProcMon auf dem CreateFile-Ereignis zeigen die Ereigniseigenschaften den Identität annehmenden Benutzer.

Arbeiten wie geplant!