Was ist SPN und welche Rolle spielt es 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.