Managed Service Accounts vereinfachen das Arbeiten mit Dienstkonten, Teil 1

Die Managed Service Accounts (MSAs) von Windows Server 2008 Release 2 sind ein großen Schritt nach vorne im Vergleich zu den Vorgängerversionen. Denn die verschiedenen Dienste eines Systems benötigen eine enge Integration mit anderen Ressourcen, die nicht nur auf dem lokalen System, sondern auch netzwerkweit zur Verfügung stehen.

Um in dieser Konstellation einen sicheren Betrieb zu gewährleisten, reichen in vielen Anwendungsfällen die bisherigen Konzepte – sprich einzelne vordefinierte Dienstkonten – nicht mehr aus. Deswegen gehören die MSAs zu den besten Neuerungen, die mit Windows Server 2008 Release 2 ins Spiel kommen.

In diesem ersten, frei verfügbaren Teil dieses Zweiteilers wird das Prinzip der MSAs verdeutlicht, im zweiten können die Abonnenten von NT4Admins sehen, die sich das Arbeiten mit den MSAs über die Powershell erledigen lässt.

Sieht man sich die Neuerungen im Bereich des Active Directory (AD) beim Release 2 (R2) des Windows Server 2008  an, so jubeln viele Administratoren wegen der Vereinfachung, wenn man gelöschte AD-Objekte wiederherstellen muss. Das authoritative Wiederherstellen und das schwierige Reanimieren von Tombstones gehören dabei der Vergangenheit an.

Doch wenn ein Unternehmen den Windows Server 2008 R2 in Betrieb nimmt, zeigt sich recht schnell, dass im Bereich des AD eine Funktionalität sogar noch mehr Beifall findet: die Managed Service Accounts (MSAs). Sie helfen dem Administrator bei der Verwaltung der Dienstkonten und erlauben sogar ein komplettes Umdenken – mit vielen positiven Faktoren.

Warum MSAs nötig sind

Viele Dienste benötigen eine enge Integration mit anderen Netzwerk-Ressourcen und den Verzeichnisdiensten. Damit sind Verbindungen mit anderen Rechnern nötig – also weitaus mehr als nur auf dem lokalen System. Dazu standen vor Windows Server 2008 R2 einige verschiedene Möglichkeiten zur Verfügung:

• das Netzwerkdienst-Konto (Network Service Account, NSA),
• das lokale Systemkonto (Local System Account, LSA),
• oder aber es musste ein spezielles Domänen-Benutzer-Konto für den betreffenden Dienst erstellt werden.

Auf den ersten Blick sieht der Ansatz mit dem NSA oder LSA recht gut aus. Beide Ansätze verwenden bei der Kommunikation mit den anderen Ressourcen im Netzwerk doch das Computerkonto des betreffenden Servers. Doch es treten dann im Betrieb häufig Probleme auf, wenn man auf diese eingebauten Konten zurückgreift.

Einige Dienste brauchen spezielle Berechtigungen oder Zugriffsrechte. Bei Arbeiten mit den eingebauten Konten – vor allem dem LSA – hat das zur Folge, dass der jeweilige Dienst über weitaus mehr Rechte verfügt, als er für seine Aufgabe auf dem eigenen System oder gar netzwerkweit eigentlich benötigt. Aus diesen Konstellationen ergeben sich dann zwangsläufig massive Sicherheitsprobleme.

Denn das übergeordnete Ziel einer jeden Sicherheits-Richtlinie muss lauten: Jeder Dienst bekommt nur die Berechtigungen zugewiesen, die er für die Erfüllung seiner Aufgabe benötigt – und keinesfalls mehr. Vor allem beim LSA ist das gefährlich, denn dieser Dienst besitzt sehr viele Rechte. Das hat bei der Vorstellung des Windows Server 2003 dann auch dazu geführt, dass der NSA ins Spiel kam. Dieses Konto verfügt auf dem jeweiligen lokalen System nicht über so viele Berechtigungen wie das lokale Systemkonto, erlaubt aber dennoch den Zugriff auf das Netzwerk wie das normale Computerkonto.

Ein weiteres, zusätzliches Problem tritt auf, wenn viele Dienste dasselbe Konto nutzen. Das macht ein Überwachen einer einzelnen Aktion auf einem Server praktisch unmöglich. Ein Ausweg aus diesem Dilemma ist das Anlegen von speziellen Domänen-Benutzerkonten für einzelne Dienste. Die meisten Anwendungen, die spezielle Dienste benötigen, empfehlen das Anlegen eines Domänen-Benutzerkontos für den Dienst und dann das Zuweisen von den benötigten Berechtigungen an dieses Konto.

Doch Administratoren versuchen in der Regel, die Anzahl der Konten möglichst gering zu halten. Daher ergibt sich häufig die Konstellation, dass ein Domänen-Benutzerkonto für mehrere Dienste herangezogen wird. Aus dem Blickwinkel der Systemüberwachung ist das keine gute Idee, denn ein Auditing wird damit erneut schwieriger. Und auf der anderen Seite müsste man dann wieder mehr Berechtigungen für dieses Konto vorsehen – falls sich die nötigen Rechte der entsprechenden Dienste unterscheiden.

Wählt der Administrator den Ansatz, wirklich für jeden Dienst ein eigenes Domänen-Benutzerkonto anzulegen, stellt sich erneut ein Problem: Üblicherweise wird das Kennwort für ein Domänen-Benutzerkonto nach bestimmten Vorgaben zu ändern sein. Dabei lassen sich erneut zwei Lösungsansätze unterscheiden:

Es gibt die Option, hier ein Kennwort zu verwenden, das niemals abläuft. Diese sehr unsichere Lösung wird in der Regel bei allen Systemprüfungen dafür sorgen, dass diese Einstellung bemängelt wird und man eventuell notwendige Sicherheits-Vorgaben nicht erfüllt.

Die Alternative lautet, dass das Kennwort entsprechend der gültigen Vorgaben in der Domänen-Sicherheitsrichtlinie geändert wird. Dann wird das Ablaufen des Kennworts in den meisten Unternehmen dazu führen, dass auch der Dienst ausfällt. Dann muss der Administrator einschreiten und in der Regel von Hand das Kennwort neu setzen und dann den Dienst wieder starten. Für komplexe Konfigurationen ist das kein gangbarer Weg.

Ausweg aus der Kennwort-Hölle

Die Probleme im Zusammenhang mit der Verwaltung der Kennwörter für die Dienstkonten adressiert Microsoft mit den MSAs. Dabei wird automatisch das Kennwort neu erzeugt und zwar über den Netlogon-Prozess. Das entspricht der Vorgehensweise, wie sie auch beim automatischen Zurücksetzen des Kennworts für das Computer-Konto zum Einsatz kommt. Standardmäßig wird nach 30 Tagen vom Netlogon-Prozess ein neues, 240 Bit langes mit zufällig erzeugten Zeichen gefülltes Kennwort angelegt und dann diese Information mit der Domäne synchronisiert.

Dabei werden aber auch die feingliedrigen Kennwortrichtlinien sowie die Domänen-Sicherheitsrichtlinien von den Computer-Objekten und den MSAs nicht berücksichtigt. Damit sind immer die 240 Zeichen für das Passwort im Einsatz und keine Abweichungen aufgrund anderer Vorgaben kommen zum Zug.
Um die MSAs verwenden zu können, sind zwei Voraussetzungen zu erfüllen:

• Die AD-Gesamtstruktur muss mit Hilfe des Forest-Prep-Tools von Windows Server 2008 R2 vorbereitet worden sein. Denn damit wird eine neue Objektklasse eingeführt: msDS-ManagedServiceAccount. Darin werden dann die Informationen zu den MSA im AD abgelegt.
• Zum anderen muss das System, auf dem MSA verwendet werden, als Betriebssystem Windows Server R2 oder Windows 7 einsetzen. Gegenwärtig gibt es bei Microsoft keine Pläne, die MSA-Funktionalität in früheren Versionen von Windows nachzuziehen.

Allerdings muss die Domäne nicht im Windows-Server-2008-R2- oder im Windows-Server-2008-Modus laufen. Allerdings ergeben sich noch mehr Möglichkeiten, wenn alle Domänencontroller auf der Stufe von Windows Server 2008 R2 agieren.

Generell wird ein neuer Container in der Wurzel der Domäne (die Managed Service Accounts) angelegt- das ist die standardmäßige Stelle, an der alle MSAs liegen. Doch der Administrator kann vorgeben, dass die MSAs auch woanders abgelegt werden. Um die Details zu den MSAs in dem Container anzusehen, muss man die erweiterten Möglichkeiten im Snap-in Active-Directory Benutzer und -Computer (ADUC, Active Directory Users and Computers) aktiviert haben.

Allerdings lassen sich die MSAs nicht über eine grafische Oberfläche vernünftig verwalten. Dazu hat Microsoft die Powershell vorgesehen. Sie bietet neue Cmdlets, die den Umgang mit den MSAs erlauben. Das Arbeiten mit den MSAs zeigt der Folgebeitrag.

John Savill/rhh