Benutzerkonten im Active Directory härten
Privilegierte AD-Konten mit „Protected Users“ schützen

Von Thomas Joos 9 min Lesedauer

„Protected Users“ definiert in Active Directory ein Sicherheitsprofil für Benutzerkonten mit erhöhtem Risiko durch Credential Theft. Die Gruppe erzwingt technische Einschränkungen an Clients und Domänencontrollern, die Kerberos auf AES festlegen, NTLM sperren und lokale Zwi­schen­spei­che­rung sensibler Anmeldedaten unterbinden.

Protected Users härtet privilegierte AD-Konten durch technische Einschränkungen auf Clients und Domänencontrollern. Die Sicherheitsgruppe reduziert Angriffsflächen messbar, verlangt aber Betriebsdisziplin.(Bild: ©  Alexej - stock.adobe.com)
Protected Users härtet privilegierte AD-Konten durch technische Einschränkungen auf Clients und Domänencontrollern. Die Sicherheitsgruppe reduziert Angriffsflächen messbar, verlangt aber Betriebsdisziplin.
(Bild: © Alexej - stock.adobe.com)

Active-Directory-Umgebungen verlieren privilegierte Konten häufig nicht durch Exploits, sondern durch abgegriffene Anmeldeinformationen auf Admin-Systemen, in Speicher­be­rei­chen oder über veraltete Authentifizierungsprotokolle. Der Text zeigt, wie die Sicherheitsgruppe „Protected Users“ unter Windows Server Kerberos auf AES beschränkt, NTLM unterbindet und Credential-Caching verhindert, um diese Angriffsflächen technisch zu schließen.

Das steckt hinter Protected Users

„Protected Users“ ist eine globale Sicherheitsgruppe im Standardcontainer "CN=Users". Administrative Delegation auf Nicht-Dienstadministratoren bleibt ausgeschlossen, da die Verwaltung der Gruppe nicht für Delegation ausgelegt ist. Eine zentrale Einschränkung betrifft den Kryptostack. Mitgliedskonten authentisieren nur mit Kerberos unter AES. Dafür müssen AES-Schlüssel im Benutzerobjekt vorliegen, was ein Kennwortwechsel auf Domänencontrollern voraussetzt. Konten mit sehr alten Kennwortständen oder aus Migrationen ohne Kennwortreset verlieren sonst die Anmeldefähigkeit, da RC4 und DES entfallen und keine passenden Hashes existieren. Das integrierte Domänenadministratorkonto mit RID 500 bleibt als Sonderfall rele­vant, da dieses Konto ohne Kennwortwechsel auf geeigneten Domänencontrollern keinen AES-Schlüssel besitzt und parallel in anderen Schutzmechanismen ebenfalls Sonderregeln unterliegt.