Group Managed Service Accounts

Group Managed Service Accounts ab Windows Server 2012 sind die Weiterentwicklung der mit Windows Server 2008 eingeführten Managed Service Accounts. Während Letztere auf Grund vieler Limitierung noch kaum Beachtung gefunden haben, sind Group Managed Service Accounts inzwischen ein nicht zu vernachlässigendes Mittel zur allgemeinen Verbesserung der Sicherheit in AD Umgebungen.

KDS Root Key

Der erste Schritt zur Nutzung von GMSAs ist die Erstellung eines KDS Root Keys. Der Root Key muss einmal pro Forest erstellt werden und wird vom Key Distribution Service auf den Domain Controllern verwendet.

Add-KdsRootKey -EffectiveImmediately

Obwohl der Parameter EffectiveImmediately impliziert, dass der Root Key sofort verfügbar ist und ein GMSA angelegt werden kann, ist dem leider nicht so. Um sicherzustellen, dass der KDS Root Key auf allen DCs auch wirklich repliziert ist und alle DCs auf GMSA Requests antworten können, dauert es bis zu 12 Stunden, bis im Anschluss ein GMSA angelegt und genutzt werden kann.

In (Test-) Umgebungen, die aus nur einem DC bestehen, kann dieser Sicherheitszeitraum manuell ausgehebelt werden, da dort logischerweise keine Replikation stattfindet.

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Erforderliche Sicherheitseinstellungen

Da Group Managed Service Accounts nur mit Kerberos Encryption AES128 oder höher funktionieren, müssen in den Gruppenrichtlinien die Supported Encryption Types angepasst werden, falls noch die Standardeinstellungen verwendet werden.

Konfiguriert werden müssen die Encryption Types in der Einstellung:
Network security: Configure encryption types allowed for Kerberos.

Network security: Configure encryption types allowed for Kerberos

Dabei müssen alle Werte auf „Disabled“ gestellt werden bis auf folgende:

• AES128_HMAC_SHA1
• AES256_HMAC_SHA1
• Future encryption types

Anlegen von Group Managed Service Accounts

Group Managed Service Accounts können eigentlich nur über die PowerShell angelegt werden mit dem New-AdServiceAccount Cmdlet. Details zu allen verfügbaren Parameter sind hier nachzulesen. Über die Active Directory Users and Computers MMC lassen sich GMSAs zwar anzeigen, aber nicht anlegen. Ein findiger Entwickler hat jedoch eine GUI Anwendung für MSAs und GMSAs programmiert, die hier heruntergeladen werden kann. In den folgenden Zeilen gehe ich jedoch auf den „Microsoft-Weg“ per PowerShell ein.

New-AdServiceAccount -Name "<GMSA>" -DNSHostName "<GMSA>.<FQDN>" -PrincipalsAllowedToRetrieveManagedPassword "<ComputerName|ComputerSecurityGroupName>"

Normalerweise reichen die o.g. Parameter Name, DNSHostName und PrincipalsAllowedToRetrieveManagedPassword erst mal aus. Mit dem Parameter PrincipalsAllowedToRetrieveManagedPassword definiert man dabei, welche Computer-Objekte das Passwort für das GMSA anfordern dürfen – zur einfacheren Administration empfiehlt es sich hier Security Gruppen zu verwenden und die Computer-Objekte den entsprechenden Gruppen hinzuzufügen.

Zu bedenken ist allerdings, dass bei ausschließlicher Verwendung der o.g. Parameter ohne weitere Einschränkung das GMSA für jeden Service auf den entsprechenden Computern verwendet werden kann – ggf. auch missbräuchlich oder fälschlich, was insbesondere bei erhöhten Rechten des GMSA für Sicherheitsprobleme sorgen kann. Daher sollte in Produktivumgebungen die Nutzung des GMSA mit dem ServicePrincipalNames Parameter auch auf den entsprechenden Service Principal Name des Dienstes eingeschränkt werden, für den es gedacht ist.

Beim Anlegen des GMSA wird der Fehler Key does not exist angezeigt? Dann hat man wahrscheinlich die Wartezeit für die KDS Root Key Replikation nicht abgewartet. Einfach später nochmal probieren, dann sollte es funktionieren, sobald die Replikation komplett durch ist.

Installation von Group Managed Service Accounts

Nachdem der GMSA im AD angelegt ist, muss er auf dem Host, auf dem er verwendet werden soll, „installiert“ bzw. bekannt gemacht werden.

Install-AdServiceAccount <GMSA>

Ob die Installation auch erfolgreich war, lässt sich mit folgendem Befehl prüfen:

Test-AdServiceAccount <GMSA>

Im Erfolgsfall erhält man als Ausgabe ein True. Im Fehlerfall lautet die Ausgabe logischerweise False und man muss sich ggf. auf Fehlersuche begeben.

Wenn soweit alles passt, ist es an der Zeit, die Login Informationen des Windows Dienstes anzupassen, für den man den GMSA nutzen möchte. Als Benutzerkonto wird hier der Wert <DOMAIN>\<GMSA>$ eingegeben (wichtig ist das „$“ Zeichen nach dem sAMAccountName des GMSAs); das Passwort bleibt leer.

Service Konfiguration

Group Managed Service Accounts und Scheduled Tasks

Im Gegensatz zu den Managed Service Accounts in Windows Server 2008 können die Group Managed Service Accounts ab Windows Server 2012 auch in Scheduled Tasks genutzt werden. Die Konfiguration ist ausschließlich über die PowerShell möglich.

$TaskAction = New-ScheduledTaskAction "<Program|Script>"
$TaskTrigger = New-ScheduledTaskTrigger -At <Time-24h> -Daily|Weekly|Monthly
$TaskPrincipal = New-ScheduledTaskPrincipal -UserID <Domain>\<GMSA>$ -LogonType Password
Register-ScheduledTask <Task-Name> –Action $TaskAction –Trigger $TaskTrigger –Principal $TaskPrincipal

Ausschlaggebend dafür, dass ein GMSA hinterlegt werden kann, ist analog zu Dienstekonfiguration das „$“ Zeichen nach dem sAMAccountName, sowie der Logon Type Password. Letzteres teilt dem Scheduled Task mit, dass das Passwort für den GMSA von einem DC abgefragt werden muss.

Quelle: https://technet.microsoft.com/