Group Managed Service Accounts

In meinem letzten Blogeintrag [1] habe ich die Notwendigkeit und die Nutzung von den, mit Windows Server 2008 R2 eingeführten, Managed Service Accounts erklärt. In diesem Beitrag zeige ich die Weiterentwicklung dieser Accounts.

Group Managed Service Accounts

Ähnlich wie die Managed Service Accounts, werden auch diese Accounts nicht einfach erstellt und anschließend nie wieder verändert, sondern vom AD verwaltet. Auch hier wird bei der Erstellung nur der Name festgelegt, das Passwort kennt der Administrator nicht. Das AD ändert das Passwort in regelmäßigen Abständen vollautomatisch. Diese Passwortänderung wird auch bei den Diensten, die diese Benutzerkonten verwenden automatisch übernommen.

Soweit klingt das alles sehr nach den Managed Service Accounts aus Windows Server 2008 R2. Allerdings hatten diese einige Einschränkungen, die es jetzt nicht mehr gibt. Group Managed Service Accounts können endlich auch für die Installation von Exchange verwendet werden, sie können über mehrere Rechner hinweg eingesetzt werden und sie können zur Ausführung von Scheduled Tasks verwendet werden.

Wie die MSA (Managed Service Accounts) unter Windows Server 2008 R2, setzen auch die gMSAs eine Schemaerweiterung und mindestens einen Windows Server 2012 voraus. Außerdem können die gMSAs nur von Systemen mit mindestens Windows Server 2012 oder Windows 8 verwaltet und auch nur auf diesen genutzt werden.

Auch die Funktionsweise des Passwortes hat sich seit den MSAs geändert. Wo das Passwort früher noch von einem Rechner verwaltet wurde, wird es jetzt vom Key Distribution Service von einem der Windows Server 2012 (R2) DCs verwaltet. Bei Verwendung des Service Accounts wird das Passwort vom DC erfragt. Genutzt werden können die gMSAs von allen Rechnern, die Mitglied der entsprechenden Gruppe sind. Dazu später mehr.

Bei jeder Passwortanfrage ermittelt der DC, ob eine Änderung des Passwortes notwendig ist. Sollte dem so sein, wird ein 120 Zeichen langes Passwort mithilfe eines vorher festgelegten Algorithmus berechnet. Zusätzlich hängt das Passwort von einem vorher vom Administrator erstellten Key, der aktuellen Zeit und der SID des gMSAs ab. Genug der Theorie, nun zum Erstellen der gMSAs.

Zuerst erstelle ich den vorher bereits angesprochenen Key. Dieser wird anschließend für die Erstellung der Passwörter aller gMSAs verwendet. Der Key muss nur einmal pro Forest erstellt werden.

Den Key erstelle ich mithilfe der PowerShell, indem ich folgenden Befehl absetze:

Add-KdsRootKey –EffectiveImmediately

Nun wurde der Key erstellt. Allerdings muss man nun, aufgrund einer Sicherheitsvorkehrung und anders als der Befehl vermuten lässst, 10 Stunden warten, bevor der Key genutzt werden kann. Dadurch wird sichergestellt, dass der Key auf alle DCs repliziert wurde.

Da ich diese Schritte in einem Lab durchführe und nicht warten möchte, nutze ich einen Weg diese Wartezeit zu umgehen. Setzt man statt dem oberen Befehl folgenden ab:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

kann der Key sofort verwendet werden. Sollten die gMSAs produktiv eingesetzt werden sollte man aber die eingeplanten 10 Stunden warten und die Zeit anders nutzen.

Nun, da ich den Key sofort verwenden kann, definiere ich die Gruppe der Computer, die den gMSA nutzen können. In diesem Beispiel habe ich eine neue Gruppe erstellt und die beiden Exchange Server meiner Testumgebung hinzugefügt. Theoretisch wäre es auch möglich den gMSA wie einen MSA auf nur einem Rechner zu nutzen oder jedem einzelnen Rechner individuell das Recht zu geben den gMSA zu verwenden, aber ich bevorzuge die Verwendung von Gruppen, weil es dadurch deutlich übersichtlicher wird. Der Nachteil bei der Erstellung einer Gruppe ist, dass jeder Server, der Mitglied dieser Gruppe wird, neugestartet werden muss, um über die Gruppenmitgliedschaft informiert zu werden.

Die eigentliche Erstellung des gMSAs ist ähnlich der Erstellung eines MSAs. Ich nutze die PowerShell und setze den Befehl

New-ADServiceAccount –Name -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword

ab. Der Parameter PrincipalsAllowedToRetrieveManagedPassword gibt die Gruppen an, die das Managed Password vom DC erhalten dürfen.

So weit, so gut. Der gMSA ist erstellt und kann nun auf den Servern auf denen er verwendet werden soll installiert werden.

Dazu verwende ich das cmdlet

Install-AdServiceAccount

Und teste die erfolgreiche Konfiguration anschließend mit

Test-AdServiceAccount

Das ist zwar nicht unbedingt notwendig, gibt mir aber einen Anhaltspunkt was nicht funktioniert hat, sollte der Test fehlschlagen.

Der gMSA kann nun auf diesem Server verwendet werden. Wie schon bei MSAs, gibt man in das Accountnamensfeld bei der Verwendung den gMSA Namen gefolgt von einem $ Zeichen ein und lässt das Passwortfeld leer. In meinem Fall wäre das also der Accountname: gMSA$

Ich hoffe, diese Anleitung ist hilfreich um in Zukunft weniger normal erstellte Benutzerkonten als Service Accounts zu sehen.

[1] https://www.escde.net/blog/5710

Active Directory, Windows ServerESCde Windows Server TeamService Accounts, MSA