Die Kerberos Delegation ist in modernen IT-Infrastrukturen unerlässlich, um Anwendungen nahtlos und sicher über mehrere Dienstschichten hinweg zu authentifizieren. Doch für viele Administratoren gleicht sie einer echten Stolperfalle, einem undurchdringlichen Dschungel aus Dienstkonten, SPNs und Active Directory-Einstellungen. Besonders die Kombination aus einem Internet Information Services (IIS) Webserver, der auf einen SQL Server zugreift und dabei die Identität des ursprünglichen Anwenders beibehalten soll, führt häufig zu Kopfzerbrechen. Fehlermeldungen wie „Login failed for user ‘NT AUTHORITYANONYMOUS LOGON'” sind berühmt-berüchtigte Zeichen dafür, dass die Delegation nicht funktioniert.
Dieser Artikel entmystifiziert die Kerberos Delegation mit IIS und SQL Server und führt Sie Schritt für Schritt durch die notwendigen Konfigurationen. Unser Ziel ist es, Ihnen das nötige Wissen zu vermitteln, damit Ihre Implementierung auf Anhieb gelingt und Sie die Vorteile einer sicheren und transparenten Authentifizierung voll ausschöpfen können.
Warum Kerberos Delegation und nicht NTLM?
Bevor wir in die technischen Details eintauchen, klären wir, warum Kerberos hier die bevorzugte Wahl ist. Viele Anwendungen nutzen standardmäßig NTLM (NT LAN Manager) für die Authentifizierung innerhalb einer Domäne. NTLM ist einfacher einzurichten und funktioniert oft „out of the box” für Single-Hop-Szenarien (Client zu Server). Doch wenn ein Dienst (z.B. IIS) die Identität des authentifizierten Clients an einen zweiten Dienst (z.B. SQL Server) weitergeben soll – das sogenannte „Double-Hop”-Szenario – stößt NTLM an seine Grenzen. Hier kommt die Kerberos Delegation ins Spiel, die genau dieses Problem löst, indem sie dem zwischengeschalteten Dienst erlaubt, im Namen des ursprünglichen Benutzers zu agieren.
Die Vorteile von Kerberos liegen auf der Hand:
- Sicherheit: Robuster gegen Relay-Angriffe.
- Transparenz: Die tatsächliche Benutzeridentität wird bis zum finalen Dienst weitergereicht.
- Leistung: Effizienter in großen Umgebungen.
Die Akteure verstehen: Ein Überblick
Um die Delegation erfolgreich zu konfigurieren, müssen wir die beteiligten Komponenten und ihre Rollen verstehen:
- Client: Der Endbenutzer, der über seinen Browser auf die Webanwendung zugreift.
- IIS (Webserver): Die Webanwendung, die die Benutzeranfrage empfängt und Authentifizierung über Windows-Authentifizierung anfordert. Sie muss die Identität des Benutzers an den SQL Server weitergeben.
- SQL Server (Datenbankserver): Die Datenbank, die die Anfragen vom IIS-Server erhält und die Berechtigungen des ursprünglichen Benutzers prüfen muss.
- Active Directory (AD): Der zentrale Verzeichnisdienst, der für die Ausstellung von Kerberos-Tickets, die Speicherung von Dienstkonten und die Verwaltung von Delegationseinstellungen zuständig ist.
Schritt 1: Die Fundamente schaffen – Dienstkonten und FQDNs
Ein stabiles Fundament ist entscheidend. Beginnen wir mit den Grundlagen:
1.1 Dedizierte Dienstkonten
Verwenden Sie für Ihre Dienste dedizierte Dienstkonten und niemals „LocalSystem” oder „NetworkService” für Kerberos Delegation. Diese Accounts würden die Delegation erschweren oder unmöglich machen, da die Authentifizierung dann unter dem Namen des Computerkontos stattfindet. Erstellen Sie zwei separate Domänenbenutzerkonten:
- Ein Konto für den IIS-Anwendungspool (z.B. `DOMAINsvc_iis_app`).
- Ein Konto für den SQL Server-Dienst (z.B. `DOMAINsvc_sql`).
Weisen Sie diesen Konten nur die notwendigen Berechtigungen zu (Least Privilege Principle).
1.2 Vollqualifizierte Domänennamen (FQDNs)
Kerberos ist auf die Verwendung von FQDNs (Fully Qualified Domain Names) angewiesen. Stellen Sie sicher, dass sowohl der IIS-Server als auch der SQL Server unter ihren jeweiligen FQDNs erreichbar sind und dass die Namensauflösung korrekt funktioniert (DNS). Vermeiden Sie die Verwendung von IP-Adressen oder NetBIOS-Namen, da dies Kerberos-Fehler verursachen kann.
Schritt 2: Service Principal Names (SPNs) – Der Personalausweis für Dienste
Ein Service Principal Name (SPN) ist ein eindeutiger Bezeichner für einen Dienst in einer Active Directory-Domäne. Er erlaubt Kerberos, ein Dienstticket für einen bestimmten Dienst zu finden und zuzuordnen. Jeder Dienst, der Kerberos-Authentifizierung nutzen soll, benötigt einen oder mehrere SPNs, die dem Dienstkonto zugeordnet sind, unter dem der Dienst läuft.
2.1 SQL Server SPNs registrieren
Für den SQL Server sind die SPNs von entscheidender Bedeutung. Es gibt zwei Typen:
MSSQLSvc/FQDN_des_SQLServers:PortMSSQLSvc/NetBIOS_Name_des_SQLServers:Port
Wenn Sie eine benannte Instanz verwenden, ist der Port erforderlich. Für eine Standardinstanz kann der Port weggelassen werden, aber es ist gute Praxis, ihn immer anzugeben.
Registrieren Sie die SPNs für das SQL Server-Dienstkonto (DOMAINsvc_sql) mit dem Tool setspn auf einem Domänencontroller oder einem Client mit AD-Verwaltungstools:
setspn -S MSSQLSvc/sqlserver.domain.local:1433 DOMAINsvc_sql setspn -S MSSQLSvc/sqlserver:1433 DOMAINsvc_sql
Ersetzen Sie sqlserver.domain.local durch den FQDN Ihres SQL Servers, sqlserver durch seinen NetBIOS-Namen und 1433 durch den tatsächlichen SQL-Port (falls abweichend). -S prüft auf doppelte SPNs und verhindert, dass ein SPN mehrmals registriert wird (was zu Kerberos-Fehlern führen würde).
Wichtig: Stellen Sie sicher, dass keine doppelten SPNs existieren. Überprüfen Sie dies mit setspn -X oder setspn -Q MSSQLSvc/sqlserver.domain.local:1433.
2.2 IIS SPNs (Optional, aber gut zu wissen)
Obwohl für die Delegation *vom* IIS *zum* SQL Server nicht immer explizit SPNs für IIS benötigt werden, sind sie für die Kerberos-Authentifizierung der Clients zum IIS erforderlich. Wenn Ihr IIS-Anwendungspool unter einem dedizierten Dienstkonto läuft (was wir empfehlen), müssen Sie auch hier SPNs registrieren. Für den HTTP-Dienst lauten die SPNs:
HTTP/FQDN_des_IIS_ServersHTTP/NetBIOS_Name_des_IIS_Servers
setspn -S HTTP/webserver.domain.local DOMAINsvc_iis_app setspn -S HTTP/webserver DOMAINsvc_iis_app
Wenn IIS unter `NetworkService` oder `LocalSystem` läuft, werden die HTTP-SPNs automatisch dem Computerkonto zugewiesen.
Schritt 3: Active Directory-Konfiguration – Die Magie der Delegation
Dies ist der Kernpunkt der Kerberos Delegation. Hier teilen wir dem Active Directory mit, dass unser IIS-Dienstkonto berechtigt ist, Tickets für andere Dienste zu beantragen, und zwar im Namen eines Benutzers.
3.1 Eingeschränkte Delegation (Constrained Delegation) – Der sichere Weg
Verwenden Sie immer die eingeschränkte Delegation (Constrained Delegation), da diese sicherer und flexibler ist als die unbeschränkte Delegation (Unconstrained Delegation), die aus Sicherheitsgründen vermieden werden sollte.
- Öffnen Sie „Active Directory-Benutzer und -Computer” (ADUC).
- Navigieren Sie zu dem Dienstkonto des IIS-Anwendungspools (
DOMAINsvc_iis_app). - Öffnen Sie die Eigenschaften des Kontos und wechseln Sie zum Tab „Delegierung”.
- Wählen Sie die Option: „Diesen Computer für Delegierung nur an angegebene Dienste vertrauen” (Trust this computer for delegation to specified services only).
- Wählen Sie dann: „Beliebiges Authentifizierungsprotokoll verwenden” (Use any authentication protocol). Dies ist oft die einfachere Wahl und funktioniert in den meisten Szenarien.
- Klicken Sie auf „Hinzufügen…”, dann „Benutzer oder Computer…” und suchen Sie nach dem SQL Server-Dienstkonto (
DOMAINsvc_sql). - Wählen Sie in der Liste der Dienste, die SPNs, die Sie für den SQL Server registriert haben (
MSSQLSvc/sqlserver.domain.local:1433undMSSQLSvc/sqlserver:1433). - Klicken Sie auf „OK”, um die Änderungen zu übernehmen.
Diese Konfiguration erlaubt es dem IIS-Dienstkonto, nur die ausgewählten SQL Server-SPNs zu delegieren. Dies erhöht die Sicherheit erheblich.
Schritt 4: IIS-Konfiguration – Der Webserver als Vermittler
Nun müssen wir den IIS-Webserver entsprechend konfigurieren, damit er Kerberos-Tickets korrekt anfordert und weiterleitet.
4.1 Anwendungspool-Identität
Stellen Sie sicher, dass der Anwendungspool Ihrer Webanwendung unter dem dedizierten Dienstkonto (DOMAINsvc_iis_app) läuft, auf dem Sie die Delegationseinstellungen im AD vorgenommen haben.
4.2 Windows-Authentifizierung aktivieren
Aktivieren Sie die Windows-Authentifizierung für Ihre Webanwendung im IIS-Manager und deaktivieren Sie „Anonyme Authentifizierung”.
4.3 Provider-Reihenfolge
Stellen Sie sicher, dass Negotiate (für Kerberos) vor NTLM steht, um Kerberos zu priorisieren. Klicken Sie im IIS-Manager unter „Windows-Authentifizierung” auf „Anbieter…” und verschieben Sie „Negotiate” nach oben.
4.4 Kernel-Modus-Authentifizierung deaktivieren
Dies ist eine der häufigsten Stolperfallen! Deaktivieren Sie die Kernel-Modus-Authentifizierung für die Windows-Authentifizierung der betreffenden Webanwendung. Dies kann über den IIS-Manager erfolgen (Erweiterte Einstellungen der Windows-Authentifizierung) oder direkt in der applicationHost.config:
<location path="IhreWebanwendung">
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
<extendedProtectionTokenChecking enabled="true" />
<useAppPoolCredentials>true</useAppPoolCredentials>
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
</location>
Stellen Sie sicher, dass useAppPoolCredentials auf true gesetzt ist. Die kernelMode-Eigenschaft muss false sein. Wenn Sie sie nicht explizit setzen, ist der Standardwert in manchen IIS-Versionen true, was Probleme verursachen kann. Überprüfen Sie das unter dem `
Schritt 5: SQL Server-Konfiguration – Der Datenbankserver empfängt die Identität
Der SQL Server benötigt keine spezifische Konfiguration für die Delegation selbst, außer dass er unter dem korrekten Dienstkonto läuft und die SPNs registriert sind (was wir bereits getan haben). Das Wichtigste ist, dass die ursprünglichen Benutzer, die über IIS zugreifen, auch entsprechende Berechtigungen auf dem SQL Server haben müssen.
- Erstellen Sie in SQL Server (mit SSMS) Logins für die Domänenbenutzer oder -gruppen, die auf die Datenbank zugreifen sollen.
- Weisen Sie diesen Logins die notwendigen Datenbankrollen und Berechtigungen zu.
Schritt 6: Der Praxistest – Ist alles richtig eingerichtet?
Nach all der Konfiguration ist es Zeit für den Test. Hier sind einige Tipps zur Überprüfung und Troubleshooting:
6.1 Browser-Konfiguration
Stellen Sie sicher, dass der Client-Browser (z.B. Edge, Chrome, Firefox) für die Windows-Authentifizierung konfiguriert ist. In den meisten Fällen muss die IIS-Website in der „Lokales Intranet”-Zone des Browsers liegen, damit die automatische Anmeldung funktioniert.
6.2 Überprüfung in SQL Server
Verwenden Sie in SQL Server Management Studio (SSMS) die Abfrage:
SELECT auth_scheme, original_login_name, client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID;
Wenn die Delegation erfolgreich ist, sollte auth_scheme den Wert „KERBEROS” anzeigen und original_login_name den Namen des ursprünglichen Endbenutzers und nicht den des IIS-Dienstkontos.
6.3 Event Logs
Überprüfen Sie die Ereignisprotokolle (Event Logs) auf dem IIS-Server, dem SQL Server und den Domänencontrollern (Sicherheit, System, Anwendung). Suchen Sie nach Kerberos-Fehlern (Event ID 4625, 4769, 4771 etc.).
6.4 Kerberos-Tools
klist tickets: Auf dem Client, IIS-Server und SQL Server können Sie damit die aktuellen Kerberos-Tickets sehen. Suchen Sie nach dem Ticket für den IIS-Dienst und, auf dem IIS-Server, nach dem Ticket für den SQL Server, das im Namen des Benutzers ausgestellt wurde.KerbView: Ein Tool aus den Microsoft Support Tools, das detaillierte Informationen über Kerberos-Tickets und SPNs anzeigt.- Wireshark: Für Netzwerk-Experten kann ein Mitschnitt des Netzwerkverkehrs detaillierte Einblicke in den Kerberos-Authentifizierungsablauf geben.
Häufige Stolperfallen und Lösungen
- Doppelte SPNs: Führen zu einem „Duplicate SPN”-Fehler im Event Log und verhindern, dass Kerberos ein Ticket ausstellt. Löschen Sie doppelte SPNs mit
setspn -D. - Falsche Dienstkonten: SPNs dem falschen Dienstkonto zugeordnet oder IIS/SQL läuft unter einem anderen Konto. Überprüfen Sie dies sorgfältig.
- Keine FQDNs: Client, IIS oder SQL Server verwenden keine FQDNs. Stellen Sie sicher, dass alles über FQDNs kommuniziert.
- Zeitversatz: Kerberos ist sehr empfindlich gegenüber Zeitunterschieden zwischen Client, Server und Domänencontrollern. Halten Sie die Systemzeiten synchron (max. 5 Minuten Abweichung).
- DNS-Probleme: Wenn die FQDNs nicht korrekt aufgelöst werden können, scheitert Kerberos.
- Kernel-Modus-Authentifizierung: Oft vergessen, führt sie zu NTLM-Fallback oder Anmeldefehlern. Deaktivieren Sie diese!
- Berechtigungen: Der Endbenutzer hat keine Berechtigungen auf dem SQL Server. Die Delegation funktioniert zwar, aber der Login schlägt dennoch fehl, da der Benutzer nicht autorisiert ist.
- NTLM-Fallback: Wenn Kerberos fehlschlägt, versuchen Clients oft, NTLM zu verwenden. Dies führt dann zum „ANONYMOUS LOGON”-Problem. Deaktivieren Sie NTLM als Fallback in IIS, um Kerberos-Fehler klarer zu erkennen.
Fazit
Die Kerberos Delegation mit IIS und SQL Server mag anfangs komplex erscheinen, doch mit einem systematischen Ansatz und dem Verständnis der einzelnen Komponenten ist sie gut beherrschbar. Die Investition in die korrekte Einrichtung zahlt sich in Form einer sicheren, transparenten und leistungsstarken Authentifizierung aus. Folgen Sie dieser Anleitung Schritt für Schritt, achten Sie auf die Details bei den Dienstkonten, SPNs und AD-Einstellungen, und Sie werden die „Stolperfalle Authentifizierung” erfolgreich umschiffen.
Denken Sie daran: Geduld und präzise Fehlersuche sind Ihre besten Verbündeten auf dem Weg zu einer reibungslosen Kerberos-Delegation!