SPN und seine Rolle in Active Directory und Sicherheit

Service Principal Names (SPNs) sind eindeutige Kennungen in Active Directory, die verwendet werden, um Dienstinstanzen für die Kerberos-Authentifizierung Dienstkonten zuzuordnen. Dieser Artikel erklärt die SPN-Struktur, Registrierung, Einzigartigkeitsanforderungen, Werkzeuge (z.B. setspn) und Sicherheitsimplikationen. Er behandelt Angriffe wie Kerberoasting, bewährte Methoden, Erkennungsverfahren und fortgeschrittene Anwendungsfälle in hybriden, Cloud- und containerisierten Umgebungen.

Einführung in Service Principal Names (SPNs)

Was ist ein SPN? Selbst ein Windows-Administrator mit etwas Erfahrung in Active Directory ist sich möglicherweise nicht der Rolle bewusst, die Dienstprinzipalnamen in Domänenumgebungen spielen. Ein Dienstprinzipalname (SPN) ist ein eindeutiger Bezeichner, der eine spezifische Dienstinstanz mit dem Konto verknüpft, das sie ausführt, und es Clients ermöglicht, sich zu authentifizieren und mit dem richtigen Dienst innerhalb von Active Directory (AD) zu verbinden. Dies ist besonders wichtig in großen Unternehmensumgebungen, in denen mehrere Instanzen eines Dienstes auf verschiedenen Servern laufen können. In diesem Artikel werden wir diskutieren, was der Active Directory SPN ist, welchen Beitrag er zur Sicherheit leistet und wie seine Verwendung in modernen Netzwerken heute weiter zunimmt.

Rolle der SPNs bei der Kerberos-Authentifizierung

Genau wie Sie ein Ticket benötigen, um ein Flugzeug zu besteigen oder ein Kino zu betreten, benötigen Sie auch ein Ticket, um auf Ressourcen innerhalb von Active Directory (AD) zuzugreifen. Wenn ein Client Zugriff auf einen von AD gehosteten Dienst anfordert, entfaltet sich der Prozess wie folgt:

1. Ein Client, der versucht, einen Dienst zu nutzen, erstellt einen SPN für diesen Dienst
2. Der Client fordert vom Domänencontroller unter Verwendung dieses SPN ein Ticket an
3. Der Domänencontroller durchsucht das Active Directory nach diesem SPN
4. Sobald gefunden, stellt der Domain-Controller ein Dienstticket aus
5. Der Kunde verwendet dieses Ticket, um sich ohne Passwort beim Dienst zu authentifizieren

Die Grundlagen erläutern

Komponenten eines SPN

SPN besteht aus mehreren Komponenten, die zusammen eine vollständige Identität für einen bestimmten Dienst bieten:

1. Service Class: Dies ist der Name der Serviceinstanz, wie zum Beispiel „MSSQLSvc“ für Microsoft SQL Server oder „www“ für Webdienste.
2. Hostname: Gibt den Server oder Host an, auf dem der Dienst ausgeführt wird. Dies kann der NetBIOS-Name einer Windows-Maschine wie „FilerServer“ oder der vollqualifizierte Domainname wie „fileserver.company.com“ sein
3. Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
4. Port (Optional): Wenn der Dienst auf einem nicht standardmäßigen Port läuft, kann er im SPN angegeben werden.

Beispiele für gängige SPNs in Active Directory

• Web Services – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• Dateifreigaben – CIFS/fileserver.contoso.com
• Remote Desktop Services – TERMSRV/rdserver.abcdomain.com
• LDAP-Authentifizierung – LDAP/domaincontroller.fabricam.com

SPNs und Active Directory: Die Verbindung

Wie sich SPNs mit Active Directory-Objekten integrieren

SPNs sind Attribute, die mit AD-Objekten wie Benutzerkonten, Dienstkonten oder Computerobjekten verbunden sind. Sie fungieren als Etiketten, die anzeigen, welche Dienste unter welchen Konten laufen. Diese Verbindung ermöglicht es Computern, Kerberos für eine sichere Authentifizierung zu verwenden, ohne Passwörter über das Netzwerk zu senden. Wenn ein Dienst installiert oder konfiguriert wird, registriert er einen SPN, der es Kerberos ermöglicht, Authentifizierungsanfragen dem richtigen Konto zuzuordnen. Ohne einen korrekt konfigurierten SPN wird die Kerberos-Authentifizierung fehlschlagen, was potenziell zu Authentifizierungsfehlern und Dienstunterbrechungen führen kann.

SPN-Speicherung im servicePrincipalName-Attribut

SPNs werden innerhalb von Active Directory als Teil des servicePrincipalName-Attributs eines Objekts gespeichert. Dieses Attribut existiert bei Computerkonten und Dienstkonten. Sie können dieses Attribut in den erweiterten Eigenschaften eines Objekts sehen, wenn Sie Active Directory Users and Computers verwenden, wie im folgenden Screenshot gezeigt.

Das Attribut enthält eine Liste von SPNs, die dem Objekt zugewiesen wurden. Jeder SPN-Eintrag folgt einem strukturierten Format, das den Diensttyp, Host und optional die Portnummer umfasst.

Sie können die SPNs eines AD-Objekts einsehen, indem Sie den Befehl verwenden: setspn –L hostname. Im folgenden Beispiel wurde der Befehl verwendet, um die Liste der von einem Domänencontroller für eine Domäne namens ABCDomain.com generierten SPNs zu sehen

Bedeutung der SPN-Einzigartigkeit in einer AD-Forest

Jeder Dienstprinzipalname muss im gesamten Active Directory-Wald einzigartig sein. Diese Einzigartigkeit stellt sicher, dass Kerberos Dienstanfragen korrekt an das richtige Konto weiterleiten kann. Doppelte SPNs auf verschiedenen Konten verursachen Authentifizierungskonflikte, was zu unvorhersehbarem Verhalten oder vollständigen Authentifizierungsfehlern führen kann.

Konfigurieren von SPNs: Schritt-für-Schritt-Anleitung

Werkzeuge erforderlich für SPN-Konfiguration

Das primäre Werkzeug zur SPN-Konfiguration ist setspn.exe, das in die Windows Server-Betriebssysteme integriert ist. Dieses Befehlszeilen-Tool ermöglicht es Administratoren, Service Principal Names für Active Directory-Dienstkonten zu lesen, zu ändern und zu löschen.

In einem früheren Beispiel haben wir den Befehl setspn -L verwendet, um die SPN eines Computerobjekts anzuzeigen. Sie können auch setspn -S verwenden, um eine SPN hinzuzufügen. Um beispielsweise eine HTTP-SPN zu einem Computer namens webserver1 hinzuzufügen, wäre der Befehl:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

Beachten Sie, dass der Befehl setspn -S automatisch auf vorhandene identische SPNs prüft, bevor neue erstellt werden, um doppelte Einträge zu verhindern.

Um ein SPN zu entfernen, verwenden Sie den Befehl setspn -D. Sie können auch PowerShell auf verschiedene Weisen für SPNs nutzen. Zum Beispiel wird das folgende PowerShell-Cmdlet alle in Active Directory registrierten SPNs finden:

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

Während dieses alle doppelten SPNs erkennen wird.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

Best Practices für die SPN-Registrierung

• Gewähren Sie Dienstkonten die minimal notwendigen Berechtigungen für die SPN-Registrierung
• Verwenden Sie PowerShell, um auf Duplikate zu prüfen, bevor Sie ein neues SPN registrieren:
• Führen Sie regelmäßige Audits von SPNs durch, um unnötige oder veraltete Einträge zu identifizieren und zu entfernen
• Verwenden Sie ein standardisiertes SPN-Namensformat beim Hinzufügen von SPNs

Fehlerbehebung bei häufigen SPN-Problemen

Doppelte SPNs können Authentifizierungsfehler verursachen und müssen behoben werden. Achten Sie auf Benutzer, die über intermittierende Zugriffsprobleme berichten, da dies auf SPN-Konflikte hinweisen könnte. Sie können den Befehl setspn -x verwenden, um Duplikate innerhalb einer einzelnen Domäne zu finden, wie im folgenden Screenshot gezeigt.

Verwenden Sie den Befehl setspn -F, um den gesamten Wald zu durchsuchen. Um doppelte SPNs zu lösen:

1. Identifizieren Sie die Konten, die doppelte SPNs halten.
2. Bestimmen Sie, welches Konto das SPN legitim halten sollte.
3. Entfernen Sie das SPN vom falschen Konto mit setspn -D <SPN> <AccountName>8.
4. Fügen Sie das SPN dem richtigen Konto hinzu, indem Sie setspn -S <SPN> <AccountName> verwenden

Zusätzlich zu Duplikaten gehören einige andere häufige SPN-Fehlkonfigurationen:

• Fehlende SPNs für Dienste
• SPNs, die falschen Konten zugeordnet sind
• Outdated SPNs after server name changes

(Es ist nicht nötig, die gleichen Tools hier noch einmal aufzulisten, die wir bereits abgedeckt haben)

Fortgeschrittene SPN-Konzepte

Die Rolle von SPNs in Multi-Service- und Multi-Host-Umgebungen

Dienstkonten sind spezialisierte Benutzerkonten, die für auf Windows Server laufende Dienste erstellt werden. Sie helfen dabei, Domänenkonten in kritischen Anwendungen wie Internet Information Services (IIS) zu isolieren und zu schützen. In komplexen Umgebungen laufen häufig mehrere Dienste auf demselben Rechner, wobei jeder einzelne eigene Dienstprinzipalnamen (SPNs) für eine ordnungsgemäße Authentifizierung benötigt.

Ein gängiges Beispiel ist ein Server, der eine Webanwendung hostet und sowohl SQL Server als auch IIS ausführt. Jeder Dienst benötigt seinen eigenen SPN, um eine korrekte Kerberos-Authentifizierung zu gewährleisten:

• Für IIS: HTTP/servername.domain.com
• Für SQL Server: MSSQLSvc/servername.domain.com:1433

In Multi-Host-Umgebungen, in denen ein Dienst auf mehreren Servern für Lastausgleich oder Failover ausgeführt wird, wird die SPN-Konfiguration komplexer. Betrachten Sie eine Webanwendung, die auf mehreren Servern (Web01, Web02, Web03) unter einem gemeinsamen DNS-Namen gehostet wird. In diesem Szenario müssen SPNs auf einem einzigen Dienstkonto registriert werden, um eine nahtlose Authentifizierung über alle Hosts hinweg zu ermöglichen:

Besondere Fälle: HOST SPNs und ihr einzigartiges Verhalten

HOST SPNs sind eine spezielle Art von SPN, die automatisch auf Computerobjekten in Active Directory registriert werden. Sie fungieren als universeller Identifikator für Dienste, die unter einem lokalen System- oder Netzwerkdienstkonto einer Maschine laufen. Dies vereinfacht das Management für viele standardmäßige Windows-Dienste und verringert den Bedarf an manueller SPN-Konfiguration.

Die folgende Grafik fasst zusammen, wann Sie HOST SPNs vs. Custom SPNs verwenden sollten:

Tipp: Sie sollten niemals manuell HOST SPNs ändern, da diese von AD verwaltet werden.

SPNs und Sicherheitsimplikationen

Warum die Sicherung von SPNs in einer AD-Umgebung entscheidend ist

Der Grund, warum Sicherheit für SPNs wichtig ist, ist einfach. Dienstkonten haben oft erhöhte Privilegien. Sie haben auch kontinuierlichen Zugang zu kritischen Systemen innerhalb des Netzwerks und werden oft vergessen, sobald sie erstellt sind. All dies macht sie zu hochwertigen Zielen für Angreifer. Das Kompromittieren eines SPN kann zu unbefugtem Zugang zu kritischen Diensten führen und Angreifern potenziell ermöglichen, sich seitlich im Netzwerk zu bewegen und ihre Privilegien zu eskalieren.

Wie schwache SPNs ausgenutzt werden können

Wenn SPNs schwach konfiguriert sind, können sie durch Angriffe wie Kerberoasting ausgenutzt werden. So würde ein Angreifer einen solchen Angriff durchführen:

• Ein Angreifer mit minimalen Domänenprivilegien kann Servicetickets für beliebige SPN anfordern Servicetickets für diese SPNs
• Das Service-Ticket, verschlüsselt mit dem Passworthash des Service-Accounts, kann extrahiert und offline zum Knacken mitgenommen werden
• Führt Offline-Passwortknacken auf diesen durch und wenn das Passwort schwach ist, können Angreifer es möglicherweise knacken und Zugang zum Dienstkonto erhalten, oft mit erhöhten Privilegien

Sobald der Angreifer das Passwort eines Dienstkontos knackt und falls dieses Konto hohe Privilegien hat, können sie sich seitlich durch das Netzwerk bewegen oder ihren Zugang eskalieren.

Best Practices für die Sicherung von SPNs und Servicekonten

Im Folgenden finden Sie eine Liste der besten Methoden zur Minderung von Sicherheitsrisiken, die mit SPNs verbunden sind:

• Verwenden Sie lange, komplexe Passwörter für Konten mit SPN und ändern Sie diese regelmäßig.
• Vermeiden Sie die Zuweisung von SPNs zu Konten mit hohen Privilegien wie Domain-Admins
• Beschränken Sie Dienstkonten auf die für ihre Funktion notwendigen Berechtigungen
• Interaktive Anmeldung für Dienstkonten deaktivieren
• Überwachen Sie die unerwartete Verwendung von SPN-bezogenen Befehlen in PowerShell.
• Da jeder Benutzer mit Domänenauthentifizierung nach SPNs suchen kann, sollten Sie einschränken, wer diese Abfragen durchführen kann, indem Sie die Berechtigungen im Active Directory ändern.

Erkennung und Minderung von SPN-Missbrauch

Überwachung und Auditing von SPN-bezogenen Aktivitäten

Die kontinuierliche Überwachung Ihrer AD-Umgebung und die Überprüfung von Kerberos-bezogenen Ereignissen können sich als sehr wirksam erweisen, um SPN-Missbrauch zu verhindern. Einige der Dinge, die Sie erkennen sollten, umfassen:

• Ungewöhnliche SPN-Enumerationsanfragen, da Angreifer AD mithilfe von LDAP-Tools nach SPNs abfragen könnten.
• Häufige Kerberos-Ticketanfragen, da ein plötzlicher Anstieg der Service-Ticketanfragen auf einen laufenden Angriff hindeuten könnte.
• Service-Account-Logins von unerwarteten Standorten anstelle der üblichen festgelegten Orte.
• Fehlgeschlagene Authentifizierungsversuche, da wiederholte Fehlschläge auf Brute-Force- oder Password Spraying-Versuche hindeuten.

Implementierung von Minderungsstrategien gegen SPN-basierte Angriffe

Wenn Ihre Organisation in einer Windows Active Directory-Umgebung arbeitet, sollten Sie die folgenden präventiven Sicherheitskontrollen in Betracht ziehen, um das Risiko von SPN-Missbrauch und Kerberoasting-Angriffen zu minimieren.

• Verwenden Sie lange, komplexe Passwörter (absolutes Minimum 14 Zeichen) für Dienstkonten
• Verhindern Sie die Wiederverwendung von Passwörtern über verschiedene Konten hinweg und wechseln Sie regelmäßig Ihre Passwörter
• Wenden Sie das Prinzip der geringsten Berechtigungen an, um die Kontoberechtigungen zu beschränken.
• Verkürzen Sie die Lebensdauer von Kerberos-Tickets, um das Angriffsfenster zu minimieren
• Überprüfen und entfernen Sie regelmäßig veraltete oder unnötige SPNs
• Setzen Sie eine mehrschichtige Verteidigungsstrategie um, die ein starkes Servicekonto-Management, ausgefeiltes Monitoring und regelmäßige Schulungsprogramme kombiniert.

Verwendung von Gruppenverwalteten Dienstkonten und starken Verschlüsselungsmethoden

Implementieren Sie Group Managed Service Accounts (gMSAs), um von automatisiertem Passwortmanagement zu profitieren. Group Managed Service Accounts (gMSAs) sind spezialisierte Dienstkonten in Active Directory, die im Vergleich zu traditionellen Dienstkonten erweiterte Sicherheitsfunktionen bieten. Sie sind besonders nützlich für domänenverbundene Server, die Dienste wie SQL Server, IIS-Webanwendungen, geplante Aufgaben und andere Dienste ausführen, die in einem Sicherheitskontext mit spezifischen Berechtigungen laufen müssen. Die Verwendung von gMSAs wird manuelle Passwortzuweisungen eliminieren und das Risiko des Diebstahls von Anmeldeinformationen verringern. Bezüglich der Verschlüsselung sollte starke AES128/AES256 Kerberos-Verschlüsselung durchgesetzt werden, während schwächere DES- und RC4-Verschlüsselungsarten in Active Directory deaktiviert werden sollten.

Praktische Anwendungen und Einsatzmöglichkeiten

Wie erwähnt, werden SPNs bei der Kerberos-Authentifizierung für Webanwendungen und Datenbanken verwendet. IIS verwendet SPN im Format „HTTP/ServerName“, das dem Domänenkonto zugeordnet ist, welches den Anwendungspool ausführt, während „MSSQLSvc/host.domain.com:1433“ ein Beispiel für ein SQL-Dienstkonto ist. Die Rolle der Service Principal Names (SPNs) entwickelt sich jedoch über traditionelle Anwendungsfälle hinaus, da Unternehmen zunehmend hybride Netzwerkarchitekturen übernehmen. Heute sehen wir sogar, dass SPNs sichere Authentifizierung zwischen On-Prem-Ressourcen und Cloud-nativen Anwendungen erleichtern. Weitere Beispiele umfassen:

• SPNs werden verwendet, um Identitäten und Zugriff für containerisierte Anwendungen und Dienste in containerisierten Umgebungen zu verwalten.
• Edge-Umgebungen verwenden SPNs, um eine sichere Kommunikation zwischen Edge-Geräten und zentralisierten Cloud-Ressourcen zu erleichtern.
• Azure AD Connect verwendet SPNs für Synchronisationsdienste zwischen On-Prem AD und Azure AD.

Es gibt auch eine zunehmende Verwendung von SPNs in Unternehmensumgebungen heute. Zum Beispiel überwachen Sicherheitsteams SPN-Nutzungsprotokolle, um unbefugte Zugriffsversuche oder Kerberos-Fehler zu erkennen. Weitere Beispiele umfassen:

• Single Sign-On (SSO): SPNs ermöglichen Kerberos-basiertes SSO über mehrere Anwendungen und Dienste hinweg.
• Anwendungsintegration: SPNs erleichtern die sichere Kommunikation zwischen verschiedenen Unternehmensanwendungen und -diensten.
• Delegierte Authentifizierung: SPNs ermöglichen es Diensten, sich im Namen von Benutzern für mehrschichtige Anwendungen zu authentifizieren.

Fazit

Service Principal Names (SPNs) sind seit der Gründung von Active Directory ein Grundpfeiler der Kerberos-Authentifizierung. Sie waren ein Hauptbestandteil für viele der klassischen Dienste, auf die Netzwerkbenutzer angewiesen sind, und SPNs spielen eine entscheidende Rolle bei der Gewährleistung sicherer und reibungsloser Abläufe über zahlreiche Hintergrunddienste hinweg. Da Organisationen weiter wachsen und sich entwickeln, erweitern sich die Anwendungen von SPNs auf Bereiche wie Cloud-Integration und IoT. Mit dem wachsenden Schwerpunkt auf Sicherheit in Unternehmen heute werden SPNs höchstwahrscheinlich eine größere Rolle spielen, indem sie sich an neue Technologien und Sicherheitsherausforderungen in der ständig wachsenden digitalen Landschaft anpassen.

Was ist SPN?

Ein Service Principal Name (SPN) ist ein eindeutiger Bezeichner, der eine bestimmte Dienstinstanz mit dem Active Directory-Konto verknüpft, das sie ausführt. SPNs müssen im gesamten Active Directory-Gesamtstruktur eindeutig sein.

Wenn zwei Konten denselben SPN besitzen, kann der Domänencontroller nicht bestimmen, welchem ein Ticket ausgestellt werden soll, und die Authentifizierung schlägt fehl. Wenn kein Konto den SPN besitzt, schlägt die Anfrage vollständig fehl, und der Client fällt typischerweise auf NTLM zurück, was eigene Risiken birgt.

Ein SPN, der einem persönlichen Benutzerkonto statt einem verwalteten Dienstkonto zugeordnet ist, macht diesen Angriff möglich. Die Abwehr ist Dienstkontopflege. Verwenden Sie Group Managed Service Accounts. Erzwingen Sie lange, zufällig generierte Passwörter für jedes Konto, das noch einen SPN besitzt. Überwachen Sie das Ereignis-ID 4769 auf Spitzen bei Ticketanfragen, die den Angriff verraten.

Rolle der SPNs bei der Kerberos-Authentifizierung

Sie sind auch die Angriffsfläche für Kerberoasting. Jeder domänenauthentifizierte Benutzer kann ein Kerberos-Service-Ticket für ein SPN-tragendes Konto anfordern und es offline knacken, um das Passwort des Kontos zu erhalten, ohne eine Sperrschwelle auszulösen.

1. Der Client erstellt einen SPN für den Dienst, auf den er zugreifen möchte.

Eine Active Directory-Umgebung, die SQL Server, IIS, Exchange und benutzerdefinierte Anwendungen ausführt, benötigt, dass jeder Dienst sich authentifiziert, ohne Benutzer bei jeder Anfrage nach Anmeldedaten zu fragen oder Passwörter in Konfigurationsdateien einzubetten. Service Principal Names ermöglichen dies.

Wenn ein Client Zugriff auf einen Dienst anfordert, folgt der Kerberos-Authentifizierungsablauf einer definierten Reihenfolge:

SPNs existieren auf Computerobjekten und Dienstkonten als mehrwertiges Attribut namens servicePrincipalNameExpand. Jeder Eintrag in diesem Attribut repräsentiert einen registrierten Dienst. Ein Konto, das mehrere Dienste ausführt oder ein Dienst, der über mehrere Hostnamen zugänglich ist, hat mehrere SPN-Einträge.

1. Der Client fordert ein Serviceticket vom Domänencontroller unter Verwendung dieses SPN an.
2. Der Client übergibt das Ticket zum Dienst zur Authentifizierung, und kein Passwort wird über das Netzwerk übertragen.
3. Der Domänencontroller sucht den SPN in Active Directory.
4. Sobald gefunden, stellt der Domänencontroller ein Dienstticket aus, das mit den Anmeldeinformationen des Dienstkontos verschlüsselt ist.

SPN-Struktur und Komponenten

Diese Abfolge zeigt, warum die Genauigkeit des SPN wichtig ist. Ein fehlender, doppelter oder falsch konfigurierter SPN unterbricht die Suche bei Schritt 3, was dazu führt, dass die Authentifizierung fehlschlägt oder auf NTLM zurückfällt.

Komponenten eines SPN

Ein SPN ist kein einzelner Wert, sondern eine strukturierte Zeichenfolge, die aus mehreren Komponenten besteht. Das Verständnis dieser Struktur ist für die korrekte Registrierung, Fehlerbehebung und Sicherheitsüberprüfung unerlässlich.

Jedes SPN folgt einem definierten Format, das den Dienst, den Host, auf dem es läuft, und optional den verwendeten Port identifiziert. Die Komponenten sind:

Gängige SPN-Formate in Active Directory

• Konto: das Active Directory-Konto, das mit dem Dienst verknüpft ist. Dies ist nicht Teil der SPN-Zeichenfolge selbst, sondern das Objekt, bei dem die SPN registriert ist.
• Port (optional): enthalten, wenn der Dienst auf einem nicht standardmäßigen Port läuft (z. B. MSSQLSvc/host.domain.com:1433Expand).
• Dienstklasse: der Name des Diensttyps, wie MSSQLSvcExpand für Microsoft SQL Server oder HTTPExpand für Webdienste.
• Hostname: der Server oder Host, auf dem der Dienst läuft, angegeben entweder als NetBIOS-Name (z. B. FileServerExpand) oder als vollqualifizierter Domainname (z. B. fileserver.company.comExpand).

Das Format ServiceClass/Hostname: PortExpand erzeugt vorhersehbare, erkennbare Zeichenketten über verschiedene Servicetypen hinweg. Häufige Beispiele sind:

• Webdienste: HTTP/webserver.netwrix.comExpand
• SQL Server: MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• Dateifreigaben: CIFS/fileserver.contoso.comExpand
• Remote Desktop Services: TERMSRV/rdserver.abcdomain.comExpand

Wie Active Directory SPNs speichert und auflöst

• LDAP-Authentifizierung: LDAP/domaincontroller.fabrikam.comExpand

Das Attribut servicePrincipalName

SPNs sind Attribute, die mit AD-Objekten wie Benutzerkonten, Dienstkonten oder Computerobjekten verknüpft sind. Sie fungieren als Kennzeichnungen, die anzeigen, welche Dienste unter welchen Konten ausgeführt werden. Diese Verbindung ermöglicht es Computern, Kerberos für eine sichere Authentifizierung zu verwenden, ohne Passwörter über das Netzwerk zu senden.

Wenn Sie einen Dienst installieren oder konfigurieren, registriert dieser einen SPN, der es Kerberos ermöglicht, Authentifizierungsanfragen dem richtigen Konto zuzuordnen. Ohne einen korrekt konfigurierten SPN schlägt die Kerberos-Authentifizierung fehl, was zu Authentifizierungsfehlern und Dienstunterbrechungen führen kann.

Wenn ein Client Zugriff auf einen Dienst anfordert, erstellt er einen SPN für diesen Dienst, sendet ihn an den Domänencontroller, und der DC sucht diesen SPN im Verzeichnis. Wird er gefunden, stellt er ein Kerberos-Service-Ticket aus. Kein Passwort wird über das Netzwerk übertragen.

Wie die Einzigartigkeit von SPN eine korrekte Dienstauflösung ermöglicht

Sie können die SPNs für ein AD-Objekt mit dem Befehl anzeigen: setspn –L hostname. Im folgenden Beispiel wurde der Befehl verwendet, um die Liste der von einem Domänencontroller für eine Domäne namens ABCDomain.com generierten SPNs anzuzeigen.

SPNs werden in Active Directory als Teil des servicePrincipalName-Attributs eines Objekts gespeichert. Dieses Attribut existiert bei Computerkonten und Dienstkonten und enthält eine Liste aller für dieses Objekt registrierten SPNs. Sie können es über die Registerkarte der Eigenschaften eines Objekts in Active Directory Users and Computers, wie im folgenden Screenshot gezeigt, anzeigen.

HOST SPNs und wann AD sie automatisch verwaltet

Die folgende Tabelle fasst zusammen, wann HOST SPNs gegenüber benutzerdefinierten SPNs verwendet werden sollten:

HOST-SPNs sind eine spezielle Kategorie von SPNs, die von Active Directory automatisch auf Computerobjekten registriert werden. Sie fungieren als universelle Kennung für Dienste, die unter dem Local System- oder Network Service-Konto auf einem Computer ausgeführt werden, und decken viele Standard-Windows-Dienste ab, ohne dass manuelle SPN-Einträge erforderlich sind.

Bei der Fehlerbehebung von Authentifizierungsproblemen sollten doppelte SPNs zu den ersten überprüften Punkten gehören. Verwenden Sie setspn -XExpand um Duplikate innerhalb einer Domäne zu erkennen, und setspn -FExpand um die gesamte Forest zu durchsuchen.

Jeder SPN muss im gesamten Active Directory Forest eindeutig sein. Diese Einzigartigkeit ermöglicht es Kerberos authentication, Dienstanforderungen an das richtige Konto weiterzuleiten. Wenn zwei Konten denselben SPN besitzen, kann der Domänencontroller nicht bestimmen, welches verwendet werden soll, was zu Authentifizierungsfehlern, sporadischen Anmeldefehlern und unterbrochenen Dienstverbindungen führt.

Ändern Sie HOST SPNs niemals manuell. Active Directory verwaltet sie automatisch, und Änderungen können Kernservices stören.

So konfigurieren und verwalten Sie SPNs

Schritt 1: Identifizieren Sie den Dienst und das Zielkonto

Schritt 2: Überprüfen Sie vorhandene oder doppelte SPNs

Die korrekte SPN-Konfiguration ist eine Voraussetzung für die Funktion der Kerberos-Authentifizierung. Der Prozess folgt unabhängig vom Diensttyp einer konsistenten Reihenfolge, und das Überspringen von Schritten ist die häufigste Ursache für SPN-bezogene Probleme.

Stellen Sie vor der Registrierung sicher, dass der SPN nicht bereits in einem anderen Konto existiert. Verwenden Sie die folgenden Befehle, um das Verzeichnis abzufragen:

Die Registrierung eines doppelten SPN kann Authentifizierungsfehler verursachen und ist nachträglich schwer zu diagnostizieren.

Schritt 3: Registrieren Sie den SPN mit setspn

Bevor Sie einen SPN registrieren, identifizieren Sie zwei Dinge: die benötigte Dienstklasse und das Format sowie das Active Directory-Konto, das den Dienst ausführt. Für Standarddienste (SQL Server, IIS, Exchange) ist die Dienstklasse gut dokumentiert. Für das Konto bevorzugen Sie ein Active Directory service account dediziertes Konto oder, wenn möglich, eine Group Managed Service Account (gMSA) statt eines gemeinsamen oder persönlichen Kontos.

Für SQL Server, der auf einem nicht standardmäßigen Port läuft:

Verwenden Sie setspn -SExpand (sichere Hinzufügung), um den SPN zu registrieren. Das -S-Flag prüft automatisch auf Duplikate, bevor der Eintrag erstellt wird, und ist somit sicherer als das ältere -A-Flag:

Schritt 4: Überprüfen Sie die Registrierung

Sie können SPNs auch über PowerShell mit den Cmdlets Set-ADUser oder Set-ADComputer registrieren, was für automatisierte Bereitstellungen oder Massenregistrierungen nützlich ist.

Sie können auch mit PowerShell überprüfen:

Nach der Registrierung bestätigen Sie, dass der SPN im richtigen Konto erscheint:

Die Ausgabe sollte den neu registrierten SPN zusammen mit allen anderen, die diesem Konto bereits zugewiesen sind, auflisten.

Schritt 5: Testen Sie die Kerberos-Authentifizierung

Behebung häufiger SPN-Fehlkonfigurationen

Die meisten SPN-Probleme fallen in wenige Kategorien. Jede erfordert eine gezielte Lösung:

Im Windows-Ereignisanzeige erscheint eine erfolgreiche Kerberos-Dienstticket-Anforderung als Ereignis-ID 4769. Wenn die Authentifizierung auf NTLM zurückfällt, fehlt der SPN wahrscheinlich, ist fehlerhaft oder auf dem falschen Konto registriert.

Nachdem der SPN registriert ist, testen Sie, ob die Kerberos-Authentifizierung erfolgreich ist. Verbinden Sie sich mit Domänenanmeldeinformationen zum Dienst und führen Sie dann klistExpand aus, um zu bestätigen, dass der DC ein Kerberos-Service-Ticket (kein NTLM-Ticket) ausgestellt hat.

Best Practices für die SPN-Registrierung

• Doppelte SPNs: Verwenden Sie setspn -DExpand um den SPN vom falschen Konto zu entfernen, und prüfen Sie anschließend, ob er beim richtigen Konto verbleibt. Duplikate treten oft nach Serverumbenennungen oder Kontomigrationen auf.
• Veraltete SPNs nach Serverumbenennung: Alte SPNs, die auf den vorherigen Hostnamen verweisen, müssen entfernt und neue unter dem aktuellen Namen registriert werden.
• Fehlende SPNs: Wenn Kerberos fehlschlägt und auf NTLM zurückfällt, prüfen Sie mit setspn -QExpand, ob der SPN überhaupt existiert. Registrieren Sie ihn, falls er fehlt.
• SPNs, die im falschen Konto registriert sind: Entfernen Sie sie mit setspn -DExpand und registrieren Sie sie im richtigen Dienstkonto neu.

Die Etablierung konsistenter Praktiken für das SPN-Management reduziert sowohl Betriebsfehler als auch Sicherheitsrisiken:

• Führen Sie regelmäßige PowerShell-Prüfungen durch, um SPNs zu identifizieren, die auf unangemessene Konten registriert sind.
• Weisen Sie SPNs dedizierten Dienstkonten zu, nicht persönlichen Benutzerkonten oder Domain Admin-Konten.
• Verwenden Sie setspn -SExpand (nicht -A) beim Registrieren, um versehentliche Duplikate zu vermeiden.
• Verwenden Sie ein standardisiertes Namensformat in Ihrer gesamten Umgebung, um Audits zu vereinfachen.

Sicherheitsrisiken durch falsch konfigurierte SPNs

Kerberoasting

• Gewähren Sie Konten nur die minimal erforderlichen Berechtigungen. Die SPN-Registrierung erfordert Schreibzugriff auf das Attribut servicePrincipalNameExpand, das nicht breit vergeben werden sollte.

Dienstkonten, die mit SPNs verbunden sind, gehören zu den am häufigsten angegriffenen Identitäten in Active Directory. Im Gegensatz zu Standardbenutzerkonten verfügen sie oft über erhöhte Berechtigungen, behalten persistenten Zugriff auf kritische Systeme und werden nach der Erstellung selten überprüft. Diese Kombination führt zu Sicherheitsrisiken durch falsch konfigurierte SPNs.

Silver-Ticket-Angriffe

Ein Angreifer kann das Ticket anfordern, extrahieren und offline Passwort-Cracking durchführen, ohne Sperren auszulösen oder erheblichen Netzwerkverkehr zu erzeugen.

Kerberoasting ist die am weitesten verbreitete SPN-basierte Angriffstechnik. Jeder domänenauthentifizierte Benutzer, einschließlich Konten mit niedrigen Rechten, kann ein Kerberos-Service-Ticket für jeden SPN im Verzeichnis anfordern. Dieses Ticket ist mit dem Passwort-Hash des Dienstkontos verschlüsselt.

Die RC4-Verschlüsselung macht diesen Angriff deutlich schneller, da RC4-verschlüsselte Kerberos-Tickets leichter zu knacken sind als moderne AES-geschützte, weshalb Microsoft RC4 in AD-Umgebungen aktiv zurückzieht.

Verwendet das Dienstkonto ein schwaches oder wiederverwendetes Passwort, kann der Angreifer die Klartext-Anmeldedaten wiederherstellen und auf den Dienst zugreifen, oft mit erhöhten Rechten.

Laterale Bewegung über kompromittierte Dienstkonten

Wie man sich gegen SPN-basierte Angriffe verteidigt

Privilegienerweiterung durch SPNs mit hohen Berechtigungen

SPNs, die auf Konten mit übermäßigen Berechtigungen registriert sind, insbesondere Konten mit Domain Admin-Rechten oder uneingeschränktem Zugriff auf kritische Systeme, stellen die risikoreichsten Konfigurationen dar. Ein erfolgreicher Kerberoasting-Angriff auf eines dieser Konten kompromittiert nicht nur einen Dienst; er kann einem Angreifer die Kontrolle auf Domänenebene verschaffen.

Erkennung von Kerberoasting und SPN-Aufzählung

Eine natürliche Folge des Kerberoasting ist der Silver-Ticket-Angriff. Sobald ein Angreifer den Passwort-Hash eines Dienstkontos knackt, kann er diesen verwenden, um Kerberos-Diensttickets vollständig offline zu fälschen, ohne weitere Interaktion mit dem Domänencontroller. Diese Silver Tickets gewähren dauerhaften Zugriff auf den Zielservice und sind besonders schwer zu erkennen, da sie den DC vollständig umgehen.

Servicekonten haben häufig Zugriff auf mehrere Systeme. Wenn ein Angreifer eine kompromittiert, erhält er einen Fuß in der Tür, der laterale Bewegung im gesamten Umfeld ermöglicht. Da Servicekonten oft von Standardüberwachungs- und Anomalieerkennungsregeln ausgeschlossen sind, kann diese Bewegung über längere Zeit unbemerkt bleiben.

Die kontinuierliche Überwachung Ihrer AD-Umgebung ist die erste Verteidigungslinie. Zu beobachtende Indikatoren sind unter anderem:

Der Schutz vor SPN-basierten Angriffen erfolgt in drei Bereichen: frühzeitige Erkennung von Missbrauch, effektive Reaktion bei Auftreten und Härtung der Umgebung, um die Angriffsfläche vor einem Vorfall zu reduzieren.

• Ungewöhnliche SPN-Abfrage. Angreifer verwenden häufig LDAP-Tools, um während der Aufklärung alle SPNs in einer Domäne aufzulisten.
• Anmeldungen von Dienstkonten von unerwarteten Hosts oder zu ungewöhnlichen Zeiten.

Die Einschränkung, wer SPNs abfragen darf, durch Ändern der Berechtigungen in Active Directory verkürzt das Aufklärungsfenster für Angreifer mit geringen Rechten.

Eindämmung und Reaktion auf SPN-Missbrauch

• Ein plötzlicher Anstieg der Ereignis-ID 4769 (Kerberos-Dienstticket-Anfragen), insbesondere solcher mit RC4-Verschlüsselung (Verschlüsselungstyp 0x17), deutet stark auf Kerberoasting hin, da Angreifer RC4-Tickets für schnelleres Knacken bevorzugen.
• Wiederholte fehlgeschlagene Authentifizierungsversuche, die auf Brute-Force- oder Password-Spraying-Angriffe gegen kompromittierte Zugangsdaten hinweisen können.

Wenn SPN-basierter Missbrauch erkannt wird, hat die Einschränkung der Fähigkeit des Angreifers, die kompromittierten Anmeldedaten zu verwenden, Priorität:

• Setzen Sie das Passwort des betroffenen Dienstkontos sofort mit einem langen, zufällig generierten Zugang zurück.
• Überprüfen Sie, ob das Konto mehr Privilegien hat, als seine Funktion erfordert, und reduzieren Sie diese.
• Überprüfen Sie alle Systeme, auf die das Dienstkonto Zugriff hat, und prüfen Sie die jüngsten Aktivitäten auf Anzeichen seitlicher Bewegungen.

Härtung von SPN-aktivierten Dienstkonten

Proaktives Härtung beseitigt viele der Bedingungen, die SPN-basierte Angriffe ermöglichen:

• Verwenden Sie lange, zufällig generierte Passwörter (mindestens 25 Zeichen) für Servicekonten und wechseln Sie diese nach einem festgelegten Zeitplan.
• Widerrufen Sie alle aktiven Kerberos-Tickets, die für das Konto ausgestellt wurden, indem Sie die Kerberos-Verschlüsselungsschlüssel des Kontos zurücksetzen (ein krbtgt-Reset ist zur Minderung von Silver Tickets nicht erforderlich; das Zurücksetzen des Dienstkontokennworts macht gefälschte Tickets ungültig).
• Deaktivieren Sie die interaktive Anmeldung für Servicekonten, um deren Nutzen bei Kompromittierung zu begrenzen.
• Wenden Sie das Prinzip der geringsten Rechte. Dienstkonten sollten nur Zugriff auf die Systeme und Daten haben, die ihre Funktion erfordert.

Verwendung von gMSAs und AES-Verschlüsselung zur Beseitigung von dauerhaftem Risiko

• Wechseln Sie nach Möglichkeit zu Group Managed Service Accounts, da diese die Passwortverwaltung automatisieren und Kerberoasting deutlich erschweren.

Group Managed Service Accounts (gMSAs) sind spezialisierte Dienstkonten, die den Bedarf an manueller Passwortverwaltung vollständig eliminieren. Active Directory verwaltet gMSA-Passwörter automatisch und rotiert sie nach einem definierten Zeitplan mit langen, zufällig generierten Anmeldeinformationen, die Dienst- und Domänenadministratoren niemals direkt sehen oder handhaben.

SPNs in hybriden und modernen Umgebungen

Standardmäßig rotiert Windows gMSA-Passwörter alle 30 Tage, und das Intervall wird durch das Attribut msDS‑ManagedPasswordInterval (oder den Parameter ManagedPasswordIntervalInDays bei der Erstellung des gMSA) gesteuert, das nur bei der Erstellung festgelegt werden kann.

Für Dienste, die gMSAs nicht unterstützen, erzwingen Sie AES-128- oder AES-256-Kerberos-Verschlüsselung und deaktivieren Sie explizit die schwächeren RC4- und DES-Verschlüsselungstypen in Active Directory. RC4-Verschlüsselung ist der Standard bei Kerberoasting-Angriffen; das Entfernen zwingt Anfragen zur Verwendung von AES, das deutlich widerstandsfähiger gegen Offline-Cracking ist.

• Weisen Sie niemals SPNs Konten mit Domain Admin- oder anderen hochprivilegierten Gruppenmitgliedschaften zu.

SPNs und Microsoft Entra Connect

Die Rolle von SPNs hat sich über das traditionelle lokale Active Directory hinaus erweitert, da Organisationen hybride Architekturen und containerisierte Workloads übernehmen. SPNs bleiben überall relevant, wo Kerberos-Authentifizierung verwendet wird, und in einigen neueren Kontexten ermöglichen sie Authentifizierungsmuster, die im ursprünglichen AD-Design nicht existierten.

SPNs in containerisierten Umgebungen

Delegierte Authentifizierung in mehrstufigen Anwendungen

Microsoft Entra Connect verwendet SPNs für seine Synchronisierungsdienste zwischen lokalem Active Directory und Entra ID (ehemals Azure AD). Das Synchronisierungsdienstkonto benötigt korrekt konfigurierte SPNs, um sich bei beiden Verzeichnissen zu authentifizieren. Falsch konfigurierte oder fehlende SPNs können die Verzeichnissynchronisierung stillschweigend unterbrechen und dazu führen, dass Identitätsdaten in der hybriden Umgebung veralten.

Kerberos-Delegierung ermöglicht es einem Dienst, sich im Namen eines Benutzers bei nachgelagerten Ressourcen zu authentifizieren. Dies ist üblich bei mehrstufigen Anwendungen, bei denen ein Web-Frontend die Identität des Benutzers an eine Backend-Datenbank weitergeben muss.

Containerisierte Workloads, die auf Windows Server ausgeführt werden, können gMSAs und damit auch SPNs für Active Directory security. Kubernetes- und Docker-Deployments auf domänenverbundenen Hosts können so konfiguriert werden, dass sie gMSA-Anmeldeinformationen anfordern, wodurch containerisierte Dienste sich mit Kerberos bei AD-integrierten Ressourcen authentifizieren können, ohne Anmeldeinformationen in Container-Images einzubetten.

SPNs sind dafür zentral: Die Delegierung wird auf dem Dienstkonto konfiguriert, das den SPN hält, und jeder Schritt in der Authentifizierungskette hängt von korrekt registrierten SPNs ab.

SPNs sind grundlegend und werden zunehmend ins Visier genommen

Unbeschränkte Delegierung, bei der ein Dienst jeden Benutzer gegenüber jeder Ressource impersonifizieren kann, stellt eine erhebliche Angriffsfläche dar und sollte nach Möglichkeit durch eingeschränkte oder ressourcenbasierte eingeschränkte Delegierung ersetzt werden.

Service Principal Names sind seit der Einführung von Active Directory ein Grundpfeiler der Kerberos-Authentifizierung. Sie ermöglichen eine sichere, kennwortlose Dienstauthentifizierung in Unternehmensumgebungen, jedoch nur bei korrekter Konfiguration, regelmäßiger Prüfung und strenger Verwaltung.

Netwrix bietet speziell entwickelte Werkzeuge für die zwei wichtigsten SPN-Sicherheitsherausforderungen: das Erkennen laufender Angriffe und die Aufrechterhaltung der Sichtbarkeit von AD-Änderungen, die Risiken verursachen.

Wie Netwrix helfen kann

Während sich Organisationen in hybride Infrastrukturen, Container und cloud-integrierte Identitätssysteme ausdehnen, tauchen SPNs an immer mehr Stellen auf und sind mit Konten verbunden, die über breiteren Zugriff als je zuvor verfügen.

Die Bedrohungsbewertung hat sich entsprechend verschoben. Kerberoasting ist zu einer der am häufigsten beobachteten Techniken für laterale Bewegungen bei Unternehmensverletzungen geworden, gerade weil SPNs sowohl allgegenwärtig als auch unzureichend überwacht sind. Fehlkonfigurationen, die früher zu Authentifizierungsfehlern führten, sind jetzt Teil der Angriffsfläche.

Das Verständnis von SPNs, wie sie aufgebaut sind, wie AD sie auflöst und wie Angreifer schwache Konfigurationen ausnutzen, ist der erste Schritt zu ihrer Sicherung. Die in diesem Artikel behandelten operativen Schritte bilden die Grundlage. Darauf aufbauend helfen kontinuierliche Überwachung, regelmäßige SPN-Prüfungen und, wenn möglich, die Migration zu gMSAs Organisationen, der Bedrohung einen Schritt voraus zu sein.

Netwrix Threat Manager erkennt Identitäts-basierte Angriffe, einschließlich Kerberoasting, SPN-Aufzählungsanfragen und verdächtige Service-Ticket-Anfragen in lokalen Active Directory und Entra ID.

Es korreliert mit anomalen Aktivitäten auf Kontoebene. Wenn ein Benutzer mit geringen Rechten plötzlich 50 Service-Tickets anfordert, sehen Sicherheitsteams dies als eine einzige konsolidierte Warnung und nicht als einzelne Logeinträge.

Fordern Sie eine Demo an und sehen Sie, wie Netwrix Ihnen hilft, SPN-Missbrauch zu erkennen, AD-Änderungen in Echtzeit zu prüfen und die Angriffsfläche zu verringern, bevor Angreifer sie ausnutzen.

Netwrix Auditor verfolgt jede Änderung des servicePrincipalName-Attributs in Ihrer AD-Umgebung, mit Vorher-Nachher-Werten und dem Konto, das für jede Änderung verantwortlich ist. Wenn ein SPN bei einem Konto mit hohen Rechten registriert oder unerwartet von einem Dienstkonto entfernt wird, zeigt Auditor diese Änderung sofort an.