Managed Service Accounts: Windows-Dienste mit eigenen Konten anmelden

Per Voreinstellung bedienen sie sich meistens der Accounts Lokales System, Lokaler Dienst oder Netzwerkdienst. Diese besitzen aber relativ hohe Privilegien und lassen sich nicht ohne weiteres auf die Aufgaben eines bestimmten Services eingrenzen, sondern auch für andere Zwecke nutzen. Ihr Vorteil besteht indes darin, dass man für sie keine Passwörter verwalten muss.

Manuelles Passwort-Management bei User-Konten

Bei normalen Domänen-Konten ist der Sachverhalt genau umgekehrt. Sie lassen sich auf die tatsächlich nötigen Rechten beschränken, aber sie unterliegen den zentralen Passwortregeln. Zu denen gehört normalerweise auch, dass Benutzer ihre Kennwörter in bestimmten Intervallen ändern müssen.

Läuft das Passwort eines Kontos ab, unter dem ein Service ausgeführt wird, dann lässt sich dieser nicht mehr starten. Um dies zu verhindern, aktivieren Admins häufig die Option Kennwort läuft nie ab. Das löst zwar das ursprüngliche Problem, entspricht aber nicht den Best Practices für das Management von Passwörtern.

Managed Service Accounts als Lösung

Diese Lücke schließen Managed Service Accounts, indem sie individuelle Konten für bestimmte Dienste bereitstellen und gleichzeitig Passwörter automatisch verwalten. Dafür nutzen sie das gleiche Verfahren wie Computer-Objekte des Active Directory und unterliegen wie diese den definierten Password Policies.

Im Unterschied zu anderen Konten werden die Kennwörter aber von selbst erneuert, wobei die maschinell generierten Passwörter standardmäßig 240 Zeichen lang sind.

Eine interaktive Anmeldung unter einem Managed Service Account ist nicht möglich. Außerdem können sie ebenso wie Computer-Konten nicht gesperrt werden.

Voraussetzungen für MSAs

Nachdem MSAs auf einer mit Windows Server 2008 R2 eingeführten Schema-Erweiterung beruhen, muss unter Umständen ein bestehendes AD mit adprep.exe aktualisiert werden.

Befindet sich die die Funktionsebene der Domäne auf Server 2008 R2 oder höher, dann steht für Managed Service Accounts neben dem automatischen Management der Passwörter auch ein solches für Service Principal Names (SPNs) zur Verfügung. Dieses greift beispielsweise, wenn sich der DNS-Name des Computer-Kontos ändert.

Ist die Funktionsebene auf dem Stand von Windows Server 2008, dann beschränken sich Managed Service Accounts auf die Passwortverwaltung.

Clients und Server, deren Dienste sich unter einem MSA anmelden sollen, müssen ebenfalls einige Voraussetzungen erfüllen. Sie lassen sich auf Clients und Servern verwenden, die Mitglied einer Domäne sind und mindestens unter Windows 7 oder Server 2008 R2 laufen. Desweiteren muss das PowerShell-Modul für Active Directory vorhanden sein, das mit RSAT installiert wird, sowie das .NET Framework 3.5.

Group Managed Service Accounts in Server 2012

Managed Service Accounts werden im AD einem Computer-Objekt zugeordnet und lassen sich ausschließlich für Services auf diesem Rechner einsetzen. Dies erweist sich in bestimmten Konstellationen als Einschränkung, beispielsweise in Server-Farmen oder bei Systemen hinter einem Load-Balancer.

In diesem Fall wäre es wünschenswert, wenn sich alle Instanzen über eine einzige Identität zu erkennen geben, gegenüber der sich die Clients authentifizieren können, ohne zu wissen, mit welchem Server sie sich verbinden. Genau diese Aufgabe erfüllen Group Managed Service Accounts (gMSA). Sie bieten die gleichen Funktionen wie MSAs, nur mit dem Unterschied, dass sie sich auf mehreren Servern anwenden lassen.

Voraussetzungen für gMSA

Die Anforderungen für gMSA sind noch höher als für MSAs. Sie wurden mit Windows Server 2012 eingeführt und benötigen daher dessen Erweiterungen des AD-Schemas. Außerdem ist der Microsoft Key Distribution Service erforderlich, der ebenfalls mit Server 2012 neu hinzugekommen ist. Dieser Dienst wird automatisch auf jedem Domain Controller unter Server 2012 installiert, muss aber manuell aktiviert werden.

Auch bei den Systemen, deren Services einen gMSA nutzen sollen, liegen die Hürden höher als bei den MSAs. Sie müssen mindestens unter Windows 8 (Pro bzw. Enterprise) oder Windows bzw. Hyper-V Server 2012 laufen.