Privilegierte Konten im AD schützen
Hoher Schutzbedarf
Veröffentlicht in Ausgabe 12/2020 - SCHWERPUNKT
Mit Windows 2000 Server kam das Active Directory (AD) vor ungefähr 20 Jahren auf den Markt. Es sollten jedoch 13 Jahre vergehen, bis mit Server 2012 R2 eine der größten Verbesserungen in puncto Sicherheit der Kerberos-Authentifizierung von hochprivilegierten Konten veröffentlicht wurde. Ein Teil der neuen Funktionalität, die Sonderbehandlung der "Protected Users"-Gruppe, wurde mit dem Heraufstufen der Domänenfunktionsebene automatisch eingeführt und hat in manchen Fällen Irritationen hervorgerufen. Weitere Features wie Authentication Policies sind vielen Administratoren bis heute unbekannt.
Hochprivilegierte Konten schützen
Für den normalen User, der sich ohne Systemverwalterrechte an seiner Arbeitsstation oder an einem gemeinsam genutzten Computer anmeldet, um mithilfe von Anwendungsprogrammen
seine Aufgaben zu erledigen, ist die übliche Anmeldung mittels Kerberos durchaus gut genug: Das bei der Anmeldung erteilte Ticket Granting Ticket (TGT) ist standardmäßig zehn Stunden gültig und wird bei Ablauf stillschweigend erneuert. Die Anmeldung ist dabei grundsätzlich an jedem Clientsystem innerhalb des Forests möglich, sofern die Default-Konfiguration nicht verändert wurde. Sind ältere Geräte im Einsatz, ist zur Not auch eine NTLM-Authentifizierung möglich. Das ist in den meisten Fällen auch vollkommen in Ordnung.
Mit Windows 2000 Server kam das Active Directory (AD) vor ungefähr 20 Jahren auf den Markt. Es sollten jedoch 13 Jahre vergehen, bis mit Server 2012 R2 eine der größten Verbesserungen in puncto Sicherheit der Kerberos-Authentifizierung von hochprivilegierten Konten veröffentlicht wurde. Ein Teil der neuen Funktionalität, die Sonderbehandlung der "Protected Users"-Gruppe, wurde mit dem Heraufstufen der Domänenfunktionsebene automatisch eingeführt und hat in manchen Fällen Irritationen hervorgerufen. Weitere Features wie Authentication Policies sind vielen Administratoren bis heute unbekannt.
Hochprivilegierte Konten schützen
Für den normalen User, der sich ohne Systemverwalterrechte an seiner Arbeitsstation oder an einem gemeinsam genutzten Computer anmeldet, um mithilfe von Anwendungsprogrammen
seine Aufgaben zu erledigen, ist die übliche Anmeldung mittels Kerberos durchaus gut genug: Das bei der Anmeldung erteilte Ticket Granting Ticket (TGT) ist standardmäßig zehn Stunden gültig und wird bei Ablauf stillschweigend erneuert. Die Anmeldung ist dabei grundsätzlich an jedem Clientsystem innerhalb des Forests möglich, sofern die Default-Konfiguration nicht verändert wurde. Sind ältere Geräte im Einsatz, ist zur Not auch eine NTLM-Authentifizierung möglich. Das ist in den meisten Fällen auch vollkommen in Ordnung.
Anders ist es jedoch bei einem hochprivilegierten Account. Dabei muss sich "hochprivilegiert" nicht unbedingt auf einen Domänen- oder Schema-Admin beziehen. Auch ein Konto, das weitreichende Verwaltungs- und Datenzugriffsberechtigungen in einem anderen System als dem Active Directory selbst besitzt, muss der IT-Verantwortliche ausreichend schützen. Ein SQL-Admin hat das Potenzial, wichtige Daten zu Geschäftsvorgängen zu entwenden oder zu verändern. Ein Fileserver-Admin könnte unter Umständen auf geheime Entwürfe aus der Produktentwicklung zugreifen und so weiter.
Auch Service-Accounts können einen validen Angriffsvektor darstellen. Diese Konten verfügen oft über tiefgreifenderen Zugriff auf Ressourcen – sowohl auf dem Computer, auf dem der Dienst läuft, als auch im Netzwerk – als die regulären User. Oft kommt erschwerend hinzu, dass die Kennwörter dieser Konten nicht ablaufen. Lässt sich das Kennwort, das DPAPI im Service Control Manager schützt, entwenden, kann der Angreifer für lange Zeit die Rechte des Kontos missbrauchen.
Dem Problem, das Dienstkonto auf vielen Servern gleichzeitig aktualisieren zu müssen, wenn sich das Kennwort ändert, können Administratoren teilweise mithilfe von "Group Managed Service Accounts" (gMSA) begegnen: Deren Kennwort wird durch berechtigte Computer regelmäßig geändert und automatisch im Service Control Manager aktualisiert [1]. Die Anmeldefähigkeit eines solchen Accounts ist jedoch nicht per se auf bestimmte Computer begrenzt; wird das automatisch gesetzte Kennwort bekannt, lässt es sich überall verwenden.
Es ist für die Sicherheit Ihrer IT-Umgebung also enorm wichtig, für hochprivilegierte Konten folgende Punkte zu addressieren:
- Auf welchen Systemen kann sich das Konto anmelden? Ein Domain-Admin, Exchange-Admin oder SQL-Admin hat auf dem PC im Lager nichts zu suchen, wo Malware oder Hacker an seine Zugangsdaten gelangen können.
- Wie lange darf ein Konto das bei der Anmeldung ausgestellte TGT benutzen und ist bei dessen Ablauf eine erneute Authentifizierung notwendig? Kommt es zum Diebstahl eines hochprivilegierten Kerberos-Tickets, sollte die Möglichkeit, es für Authentifizierung einzusetzen, zeitlich begrenzt sein.
- Für Dienstkonten: Wer darf ein Service-Ticket gegenüber Diensten anfordern, die unter diesem Konto laufen? Wo darf dieses Konto sich anmelden? Wenn das Dienstkonto zum Beispiel zur Datenbankschicht einer 3-Tier-Anwendung gehört, sind die einzigen Computer, an denen sich das Konto anmelden muss, die Datenbankserver. Und die einzigen Computer und Benutzer, die mit dem Datenbankdienst kommunizieren müssen, sind die Server der Applikationsschicht und die jeweiligen Dienstkonten sowie Datenbankadministratoren und ihre Workstations. Gegebenenfalls ist es noch von Bedeutung, dass sich Backup- und Monitoringsysteme verbinden können. Normale Arbeitsplatz-PCs haben hingegen keinen Grund, direkt mit dem Back-End einer Anwendung zu kommunizieren.
- Für Computerkonten: Manche Dienste laufen im Sicherheitskontext der ausführenden Maschine. Auch hier ist es wichtig, eingrenzen zu können, wer sich gegenüber diesen Diensten authentifizieren darf und ob NTLM dabei zugelassen oder Kerberos erzwungen wird.
In den frühen Jahren des AD haben Sicherheitsteams sehr komplexe und kaum zu beherrschende Konstrukte aus Rechten, Richtlinien und Firewall-Regelwerken gebaut, um diese Art granularer Segmentierung zu ermöglichen. Mit Server 2012 R2 wurde diese Arbeit maßgeblich erleichtert.
Besserer Schutz durch Protected Users
Für hochprivilegierte Accounts gibt es seit Server 2012 R2 eine einfache Möglichkeit, die Authentifizierung fester zu zurren. Mit der Übertragung der FSMO-Rolle "PDC Emulator" an einen Domaincontroller unter Server 2012 R2 (oder höher) legt Windows eine neue globale Gruppe – die Protected Users – mit der RID 525 an. Dieser Gruppe sind weder im AD noch auf den einzelnen Systemen Berechtigungen zugeordnet. Dennoch bewirkt die Mitgliedschaft eines Benutzerkontos in dieser Gruppe einige wichtige Änderungen am Verhalten von Anmeldungen für diesen Account:
- Keines der Anmeldeverfahren (NTLM, Digest, CredSSP, Kerberos) speichert Anmeldedaten im Klartext oder der hochgradig unsicheren "NT one-way Function". Dies ist unabhängig von den Richtlinien bezüglich der "Delegierung von Standardanmeldeinformationen".
- Die Anmeldebestätigung wird nicht zwischengespeichert, sodass keine Offline-Anmeldung mit einem geschützten Konto möglich ist.
- Kerberos erzeugt keine RC4- oder DES-Schlüssel.
Die Protected-Users-Gruppe steht auf allen Serverbetriebssystemen ab 2012 und auf allen Clientbetriebssystemen ab Windows 8 zur Verfügung. Systeme ab Windows 7/Server 2008 R2 haben im Mai 2014 ein Sicherheitsupdate erhalten, das dieses Feature auch dort aktiviert. Richtig wirkungsvoll ist der Schutz jedoch erst ab Server 2012 R2. Damit gelten für die Mitglieder der Gruppe folgende Einschränkungen:
- Die NTLM-Authentifizierung ist nicht zulässig.
- Delegierung für den Account ist nicht gestattet, weder beschränkt noch unbeschränkt.
- DES- oder RC4-Verschlüsselungstypen für Kerberos-Vorauthentifizierung lassen sich nicht verwenden.
- Das TGT ist vier Stunden lang gültig und nicht erneuerbar. Nach spätestens vier Stunden muss sich der angemeldete User also zwingend neu gegenüber einem Domaincontroller authentifizieren.
Es gibt keine Ausnahmen für bestimmte Benutzergruppen wie Domänen- oder Enterprise-Admins. Es ist also theoretisch möglich, ein Konto allein durch das Hinzufügen zur Protected-Users-Gruppe komplett am Anmelden zu hindern. Dafür muss die Domäne allerdings vor Server 2008 entstanden und das Benutzerpasswort gleich geblieben sein. Ab Server 2008 wird bei jeder Kennwortänderung auch ein AES-Schlüssel erzeugt.
Wenn ein Account bereits unter Server 2000 oder 2003 erstellt und das Kennwort seitdem nie geändert wurde, gibt es zu diesem Account keinen AES-Schlüssel und das Konto kann sich nicht mehr authentifizieren. Dieser Fall ist allerdings bei "Notfall-Admin-Konten", die sich selten anmelden, gar nicht so unwahrscheinlich. Die Art von Konten sollte also nicht Teil der Protected Users werden, genauso wie Computer- oder Dienstkonten.
Aller Härtung zum Trotz kann die Protected-Users-Gruppe nicht verhindern, dass hochprivilegierte Accounts sich an Maschinen anmelden, an denen sie nichts verloren haben. Auch die Granularität der TGT-Lebensdauer oder der NTLM-Anmeldeberechtigung lässt zu wünschen übrig. Es gibt hierfür nur die zentralen Richtlinien der Domäne und die hart verdrahtete Konfiguration der Protected-Users-Gruppe. Für die oft notwendige feinere Unterteilung und noch größere Verbindlichkeit der Abgrenzung sorgen die Authentifizierungsrichtlinien.
Authentifizierungsrichtlinien aktivieren
Die Authentifizierungsrichtlinien stehen erst zur Verfügung, wenn Sie Ihr Active Directory auf die Domänenfunktionsebene 2012 R2 oder höher heraufgestuft haben. Sie können Richtlinien entwerfen und sie verschiedenen Benutzer- und Computer-Accounts zuweisen. Damit sie daraufhin auch greifen, müssen Sie zwei Gruppenrichtlinieneinstellungen setzen. Auf Domaincontrollern ist es die Einstellung mit dem langen Namen "Unterstützung des Kerberos-Domänencontrollers für Ansprüche, Verbundauthentifizierung und Kerberos-Schutz" im Computerzweig "Administrative Vorlagen/System/KDC".
Die möglichen Werte sind "Unterstützt", "Nicht unterstützt", "Immer Ansprüche liefern" und "Ungeschützte Authentifizierungsanfragen ablehnen". Wählen Sie "Unterstützt" für die optimale Kombination von Schutz und Kompatibilität mit anderen Systemen, die die AD-Authentifizierung nutzen (Bild 2).
Den Clients, zumindest solchen unter Server 2012/Windows 8 oder höher, teilen Sie die Richtlinie "Unterstützung des Kerberos-Clients für Ansprüche, Verbundauthentifizierung und Kerberos-Schutz" zu. Sie befindet sich im Computerzweig "Administrative Vorlagen/System/Kerberos". Diese lässt sich nur aktivieren oder deaktivieren; die Kompatibilität wird also ausschließlich auf Seiten des Domaincontrollers gesteuert. Ob die Richtlinie für ein bestimmtes Gerät aktiviert wurde, überprüfen Sie mit whoami /claims. Wenn Sie in Ihrer Active-Directory-Umgebung "Fine
Grained Password Policies" (FGPP) im Einsatz haben, sollten Sie sich mit der Funktionsweise der Authentifizierungsrichtlinien schnell zurechtfinden.
Zum einen lassen sich damit für Parameter, die normalerweise global pro Domäne geregelt werden – in diesem Fall TGT-Lebensdauer und NTLM-Optionen –, einzelnen Konten oder Gruppen von Konten abweichende Werte zuweisen. Zum anderen erfolgt die Verwaltung dieser Einstellungen über das "Active Directory-Verwaltungscenter" (ADAC), das auch den Zugang zum AD-Papierkorb oder der dynamischen Zugriffssteuerung bietet.
Die Authentifizierungsrichtlinie besteht aus fünf Abschnitten. Je nach Einsatzzweck sind nicht immer Einträge in allen Abschnitten nötig:
- Benutzeranmeldung: TGT-Lebensdauer, NTLM-Anmeldebefähigung.
- Dienstticket für Benutzerkonten: Welche Benutzer oder Computer können ein Dienstticket für einen Dienst anfordern, der unter diesem Benutzer läuft?
- Dienstanmeldung: TGT-Lebensdauer für gMSA.
- Dienstticket für Dienstkonten
- Computer: TGT-Lebensdauer, Begrenzungen der Anmeldung.
Damit eine Richtlinie für Benutzer oder gMSA wirkt, müssen Sie für diesen Kontotyp die TGT-Lebensdauer konfigurieren – im Zweifel auf denselben Wert, der aus der Domäne oder aus der Protected-Users-Mitgliedschaft geerbt wird.
Geben Sie hier einen abweichenden Wert an, gilt dieser. So können Sie für die Mitglieder der Protected Users auch eine längere TGT-Lebensdauer als die hart vorgegebenen 240 Minuten einstellen.
Gruppiere und herrsche: Richtlinien-Silos
Eines der häufigsten Einsatzszenarien für Authentifizierungsrichtlinien ist das Schaffen von administrativen Tiers oder Anwendungsinseln, bei denen eine klar definierte Auswahl an Benutzer- und Dienstkonten zur Anmeldung an einer klar definierten Auswahl an Computern zugelassen ist. Solche Inseln bilden Sie mithilfe von Authentifizierungsrichtlinien-Silos ab. Einem Silo können Sie Benutzer, verwaltete Dienstkonten (gMSA) und Computer zuweisen. Anschließend bestimmt das Silo, welche Authentifizierungsrichtlinien für die Silo-Mitglieder gelten sollen: Entweder eine Richtlinie für alle Typen von Konten oder separate Richtlinien pro Kontotyp.
Verwalteten Dienstkonten können Sie Richtlinien und Silos ausschließlich per PowerShell zuweisen. Das Cmdlet "Set-ADAccountAuthenticationPolicySilo" lässt sich für beide Vorgänge verwenden. In beiden Fällen müssen Sie mit dem Argument "-Identity" das zuzuordnende Konto angeben. Der zweite Parameter ist, je nach gewünschter Zuweisung, entweder "-AuthenticationPolicy" oder "-AuthenticationPolicySilo". Authentifizierungsrichtlinien lassen sich ein und demselben Sicherheitsprinzipal sowohl direkt als auch über Richtliniensilos zuweisen. Dabei haben Richtlinien aus dem Silo stets Vorrang vor den direkt zugewiesenen Richtlinien.
Ein weiterer nützlicher Aspekt von Silos ist die Option, sie als Kriterium bei der Auswahl der zulässigen Benutzer und Computer, zum Beispiel für das Ausstellen von Diensttickets, zu verwenden. So können Sie beispielsweise ein Benutzerkonto innerhalb des eigenen Silos zur interaktiven Anmeldung berechtigen. Falls jedoch unter diesem Konto ein Dienst ausgeführt wird, können nur Geräte aus einem bestimmten anderen Silo sich gegenüber diesem Dienst authentifizieren.
Eine Insel bauen
Das einfachste Einsatzszenario für die Authentifizierungsrichtlinien und -silos ist der Bau einer Authentifizierungsinsel, also einer Gruppe von Computern und einer Gruppe von Benutzern, die sich als Einzige auf diesen Computern (und nur dort) anmelden können. Dies erreichen Sie wie folgt:
- Erstellen Sie eine Authentifizierungsrichtlinie "Insel-Policy".
- Erstellen Sie ein Authentifizierungsrichtlinien-Silo "Insel-Silo" und stellen Sie für dieses die Insel-Policy-Richtlinie für alle Account-Typen ein.
- Weisen Sie die vorgesehenen Computer und Benutzer dem Silo "Insel-Silo" zu.
- Bearbeiten Sie die Insel-Policy und stellen Sie die TGT-Lebensdauer für Benutzer-Accounts auf einen passenden Wert ein (600 Minuten sind der AD-Standard, 240 Minuten sind der Standard für Protected Users).
- Erstellen Sie im Bereich "Computer" die Bedingung "User – Authentifizierungs-Silo – ist gleich – Insel-Silo".
- Erstellen Sie im Bereich "Benutzer" die gleiche Bedingung.
Ab sofort können nur die "Insel-Benutzer" sich an "Insel-Computern" anmelden, alle anderen erhalten eine Fehlermeldung mit dem Hinweis auf die Authentifizierungsfirewall, wie in Bild 4 zu sehen ist. Wenn die Insel-Benutzer versuchen, sich an Maschinen außerhalb ihrer Insel anzumelden, erhalten sie eine Fehlermeldung. Damit die Einstellungen wirken, müssen Sie die Insel-Computer neu starten.
Überwachung und Troubleshooting
Für die Überwachung der Kerberos-Schutzfunktionalität hat Microsoft einen speziellen Ereignisprotokollkanal "Microsoft-Windows-Authentication" vorgesehen. Auf den Domaincontrollern werden die Authentifizierungsversuche der Protected Users in den Logkanälen "Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController" und "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" aufgezeichnet.
Fehlgeschlagene Aktivitäten bezüglich der Authentifizierungsrichtlinien finden Sie im Kanal "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController". Unabhängig davon, ob die Protected-Users-Gruppe Mitglieder enthält oder Sie Authentifizierungsrichtlinien erstellt haben, sind diese Protokolle vorerst deaktiviert. Sie sollten sie auch nur zu Troubleshooting-Zwecken aktivieren. Dies gelingt mit der Auswahl von "Protokoll aktivieren" im Kontextmenü des jeweiligen Ereignisprotokolls. Alternativ können Sie den folgenden PowerShell-Befehl auf jedem Domaincontroller absetzen:
$logname = "Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController"
$log = Get-WinEvent -ListLog $logname
$log.IsEnabled = $true
$log.SaveChanges()
Entsprechend lassen sich alle drei Kanäle aktivieren. Auf den betroffenen Member-Maschinen müssen Sie das Clientereignisprotokoll aktivieren. Auch hier können Sie es am schnellsten mit der PowerShell erledigen:
$logname = "Microsoft-Windows-Authentication/ProtectedUser-Client"
$log = Get-WinEvent -ListLog $logname
$log.IsEnabled = $true
$log.SaveChanges()
Die Protokolle sind sehr ausführlich, sodass ihre Größe bei vielen geschützten Accounts schnell das standardmäßig konfigurierte Limit von 1 MByte erreichen kann. Sie können die Größe gleich bei der Aktivierung einstellen, indem Sie in den obigen PowerShell-Text vor "SaveChanges()" die Zeile "$log.MaximumSizeInBytes = 128MB" einfügen. Dies erhöht die maximale Protokollgröße auf 128 MByte. Weitere nützliche Werkzeuge für das Troubleshooting der Kerberos-Authentifizierung sind klist [4] und whoami [5], hier speziell
whoami /claims.Bedenken Sie beim Troubleshooting stets, dass die Authentifizierungsrichtlinien, wie der Name schon sagt, die Authentifizierung steuern. Alle anderen Mechanismen wie der Entzug lokaler Anmelderechte oder die Anmeldebeschränkungen im AD (Attribute "logonHours" und "userWorkstations"), die erst nach erfolgreicher Authentifizierung ausgewertet werden, bleiben unverändert in Kraft.
Link-Codes
[1] Group Managed Service Account: https://docs.microsoft.com/de-de/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview/
[2] Protected Users: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/protected-users-security-group/
[3] Authentifizierungsrichtlinien und -silos: https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos/
[4] KLIST-Dokumentation: https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/klist/
[5] WHOAMI-Dokumentation: https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/whoami/
Fazit
Protected Users und Authentifizierungsrichtlinien erlauben das feingranulare Steuern der Benutzeranmeldung für hochprivilegierte Konten. Da diese Mechanismen direkt am Kerberos-Protokoll wirken, sind sie robuster gegen unerwünschte Veränderungen als andere Möglichkeiten, das Anmeldeverhalten zu beeinflussen. Die Verwaltung der Accounts erfolgt mit dem Active-Directory-Verwaltungscenter oder per PowerShell und unterscheidet zwischen Benutzer-, Computer- und Dienstkonten (gMSA).
Doch auch diese neuen Möglichkeiten des Absicherns für hochprivilegierte Konten entbinden Sie nicht von der Verantwortung dafür, das Prinzip des "least privilege" umzusetzen und das Anmeldeverhalten in Ihrer Umgebung sorgsam zu überwachen.
(jm)