So geben Sie Personen an SQL Server weiter

Spaltenvorgaben, Trigger und Sichten Ihrer Datenbank werten USER_NAME() oder SUSER_SNAME() aus. Damit sie die Person sehen statt der Anmeldung des Dienstes, lässt der Dienst jede Anweisung einer mit Windows angemeldeten Person unter ihrer eigenen SQL-Server-Anmeldung laufen (Impersonate).

Die Datenquelle wird auf Personen = Impersonate gestellt; eine Sperrliste nimmt Anmeldungen aus, die der Dienst nie annehmen darf (etwa sa oder Sysadmins von außen). In SQL Server braucht die Anmeldung der Datenquelle das Recht, andere Anmeldungen anzunehmen, und jede Person eine eigene Anmeldung. Regeln und Antworten: Weitergabe der Identität.

1. Geben Sie in SQL Server der Anmeldung der Datenquelle das Recht, und sperren Sie dort zusätzlich Anmeldungen, die nie angenommen werden dürfen:

   GRANT IMPERSONATE ANY LOGIN TO [<Anmeldung der Datenquelle>];
   DENY IMPERSONATE ON LOGIN::[sa] TO [<Anmeldung der Datenquelle>];

   Restrisiko. IMPERSONATE ANY LOGIN erlaubt der Anmeldung der Datenquelle, jede Anmeldung anzunehmen, auch eine mit Sysadmin-Rechten. Ein DENY sperrt nur die genannte Anmeldung; weitere Sysadmins, auch später angelegte, bleiben annehmbar. Die Sperrliste des Dienstes (Schritt 3) prüft vor jedem Wechsel, ist aber Teil des Dienstes: Wer die Verbindungszeichenfolge der Datenquelle besitzt, umgeht sie. Enger ist das Recht je Anmeldung, GRANT IMPERSONATE ON LOGIN::[FIRMA\e.muster] TO [<Anmeldung der Datenquelle>] (GRANT Server Principal Permissions), um den Preis eines Eintrags für jede neue Person.

2. Legen Sie für jede Person eine eigene Windows-Anmeldung in SQL Server an (CREATE LOGIN [FIRMA\e.muster] FROM WINDOWS) und geben Sie ihr die Rechte in der Datenbank. Zugang nur über eine Windows-Gruppe genügt nicht: SQL Server nimmt eine solche Person nicht an.
3. Stellen Sie die Datenquelle um, und legen Sie die Sperrliste des Dienstes an.
   • Mit Verwaltungsspeicher: Datenquellen, Datenquelle markieren, Personen auf Impersonate stellen; die Sperrliste pflegen Sie unter Identitäten, Register Sperrliste Identitätswechsel (Weitere > Neuer Sperreintrag).

   • Ohne Verwaltungsspeicher:

     { "Name": "fachdaten", "Provider": "sqlserver", "ConnectionString": "…",
       "Persons": "Impersonate",
       "DenyImpersonate": [
         { "Logins": [ "sa", "FIRMA\\Datenbankbetrieb" ] },                 // nie
         { "Roles": [ "sysadmin" ], "ExceptFrom": [ "192.168.0.0/16" ] }    // Sysadmins nur aus dem eigenen Netz
       ] }

4. Steht ein Proxy vor dem Dienst und nutzt die Sperrliste Netze, tragen Sie ihn unter Security:TrustedProxies ein; siehe Hinter IIS oder einem Proxy.
5. Prüfen Sie mit der Person: Ein neu angelegter Satz einer Tabelle, deren Spaltenvorgabe SUSER_SNAME() einträgt, trägt die Person. Nimmt die Datenquelle eigene Anweisungen an (AllowPassThrough) und darf die Person dort schreiben, zeigt auch eine eigene Anweisung SELECT SUSER_SNAME(), ORIGINAL_LOGIN() die Person und die Anmeldung der Datenquelle. Das Recht sql braucht die Person dafür nicht: Unter dem Identitätswechsel entscheiden die Rechte der Person in SQL Server.

Rückweg. Personen wieder auf Service stellen; Anweisungen laufen dann wieder unter der Anmeldung der Datenquelle – über den Verwaltungsspeicher mit der nächsten Anfrage, über die Konfigurationsdatei nach einem Neustart. Das Recht in SQL Server entziehen Sie mit REVOKE IMPERSONATE ANY LOGIN FROM [<Anmeldung der Datenquelle>].

• Ein Windows-Konto ohne eigene Anmeldung wird abgewiesen (403), nicht ersatzweise unter der Anmeldung der Datenquelle ausgeführt. Eine Person mit persönlichem Schlüssel ohne eingetragene SQL-Anmeldung läuft dagegen unter der Anmeldung der Datenquelle, mit ihrem Namen im Sitzungskontext; tragen Sie ihr in der Verwaltung eine SQL-Server-Anmeldung ein, wenn sie als sie selbst laufen soll. Am Server geht das mit save-person --login; der Befehl ersetzt aber die ganze Person samt Regeln und Sperre, also geben Sie dort alle Angaben mit (siehe Befehle).
• Nach dem Umbenennen eines Windows-Kontos ist die Anmeldung mit umzubenennen: ALTER LOGIN [FIRMA\alt] WITH NAME = [FIRMA\neu]; siehe Fehlerbehebung.
• Kosten: Der Wechsel verlängert jede Anfrage im Dienst. Richtwert für lokale Windows-Konten: rund 15 ms je Anfrage gegenüber rund 2 ms ohne Wechsel.
• Gemeinsame Anmeldungen statt einer je Person: Sollen Personen unter einer Abteilungsanmeldung arbeiten, richten Sie „So richten Sie Datenbank-Identitäten ein“ (Dokumentation der Verwaltungsanwendung) ein.
• Persönliche Schlüssel nehmen die Anmeldung einer Person an, wenn diese in der Verwaltung eine eigene SQL-Server-Anmeldung hat; Dienstschlüssel wechseln nie die Identität.

• Anmeldung und Weitergabe der Identität
• So richten Sie die Anmeldung mit dem Windows-Konto ein