Managed Service Accounts vereinfachen das Arbeiten mit Dienstkonten, Teil 2

Warum eine Ablösung für das lokale Systemdienstkonto (LSA, Local System Account) und das Netzwerkdienst-Konto (Network Service Account, NSA) nötig ist, und wie das Prinzip der Managed Service Accounts (MSAs) funktioniert, das hat bereits der erste Teil dieses Artikels gezeigt. Diese Funktionalität ist mit Windows Server 2008 Release 2 (R2) ins Spiel gekommen. In diesem zweiten Teil steht dagegen das Arbeiten mit den MSAs im Vordergrund – und das wird über die Powershell mit neuen Cmdlets abgewickelt.

Die einzelnen Details der MSAs kann der Administrator mit Hilfe des MMC-Snap-in „Active-Directory Benutzer und -Computer“ (ADUC, Active Directory Users and Computers) sich anzeigen lassen. Dazu muss er in den Container mit der Bezeichnung Managed Service Accounts in der Wurzel der Domäne gehen – das ist die standardmäßige Stelle, an der alle MSAs liegen.

Um aber die notwendigen Aktionen mit den MSAs auszuführen, bedarf es der Powershell. Um eine MSA anzulegen, sind vier Schritte zu absolvieren:

• Zuerst ist mit Hilfe des Cmdlet New-ADServiceAccount der Powershell ein neues MSA im Active Directory (AD) zu erzeugen.
• Dann ist das MSA mit dem gewünschten Computer-Konto im AD zu verbinden. Auch dazu gibt es ein Cmdlet in der Powershell: das Add-ADComputerServiceAccount
• Im dritten Schritt gilt es, das MSA auf dem Computer zu installieren. Diese Aufgabe übernimmt das Cmdlet Install-ADServiceAccount.
• Danach bleibt noch die Konfiguration des Dienstes auf dem Computer, der das MSA verwenden soll. Diese Aufgabe lässt sich mit dem Dienste-Snap-in und der MMC (Microsoft Management Console) erledigen. Aber auch andere Verwaltungsoptionen für die Dienste – wie etwa die Windows Management Instrumentation (WMI), oder der Befehl „sc“ sowie erneut die Powershell können diese Konfigurationsaufgabe übernehmen.

Wichtig in diesem Vorgehen ist ein Punkt: Das MSA muss einem bestimmten Computer zugewiesen werden. Es handelt sich dabei um eine Einschränkung der MSAs – ein MSA lässt sich immer nur für einen Computer verwenden.
Es besteht allerdings die Möglichkeit, dass das MSA für mehrere Dienste auf diesem System herangezogen werden kann.

Doch diese scheinbare Flexibilität sollte man lieber nicht in Anspruch nehmen. Denn damit würden die Überwachung und das Anhäufen von Berechtigungen negativ zu Buche schlagen – so wie das bereits im ersten Teil des Beitrags geschildert wurde. Zudem ist es vorgesehen, dass ein Computer mit mehreren MSAs zusammenarbeiten kann.

Da ein MSA aber nicht für mehrere Computer eingesetzt werden kann, ergeben sich auch beim Einsatz auf einem Cluster Probleme. Generell lassen sich die MSAs auf Cluster-Knoten oder anderen Arten von Load-Balancer-Konfigurationen nicht verwenden, die auf die Kerberos-basierte Authentifizierung zurückgreifen.

MSAs erzeugen und einsetzen

Um die passenden Powershell-Cmdlets vorweisen zu können, muss der Administrator die „Active Directory Module for Windows PowerShell” installiert haben. Sie sind Bestandteil der „Remote Server Administration Tools” (RSAT), die als ein eigenes Feature auf dem Windows Server 2008 R2 vorliegen. Sie liegen im Bereich der Active Directory Domain Services (AD DS) and Active Directory Light Directory Services (AD LDS) Tools.

Diese Cmdlets sind sowohl auf dem Computer, von dem aus der Systembetreuer die MSAs verwaltet, als auch auf den Servern, auf denen die MSAs zum Einsatz kommen, nötig. Danach muss der Administrator eine Powershell-Fenster öffnen und das Modul „ActiveDirectory“ importieren. Damit wird dann der Zugriff auf die AD-Cmdlets möglich.

Dieses Importieren muss immer dann erfolgen, wenn eine neue Powershell-Instanz zum Einsatz kommt und man mit ihr diese AD-Cmdlets verwenden möchte. Das Importieren des Moduls erfolgt über diesen Befehl:

Import-Module ActiveDirectory

Danach kann der Administrator ein neues MSA erzeugen. Es erweist sich in der Praxis als sehr nützlich, wenn er dabei einen Standard für die Benennung des jeweiligen MSA verwendet. Da ein MSA mit einem bestimmten Computer verknüpft ist, hilft einem der Computername als Bestandteil des Namens für das MSA bestimmt weiter. Zudem ist da Zusammenspiel mit dem Dienst (dem Service) eine sinnvolle Information.

In dem hier gezeigten Beispiel wird daher ein MSA mit der Bezeichnung msa_ts01_purgesvc erzeugt, das auf dem Server savdalts01 zum Einsatz kommen soll:

New-ADServiceAccount -name msa_ts  01_purgesvc
-enabled $true

Danach wird das MSA mit dem Server savdalts01verbunden:

Add-ADComputerServiceAccount -identity  savdalts01
  -serviceaccount msa_ts01  _purgesvc

Im nächsten Schritt muss sich der Administrator an dem Server anmelden, der das MSA verwenden soll – in diesem fall das System savdalts01. Nach dem Anmelden muss sichergestellt werden, dass das AD-Modul für die Powershell installiert ist. Dann gilt es, ein Powershell-Fenster zu starten und dann das AD-Modul zu importieren. Danach ist das MSA zu installieren – und zwar mit der folgenden Befehlszeile:

Install-ADServiceAccount -identity  msa_ts01_purgesvc

Zu diesem Zeitpunkt ist das Konto \msa_ts01_purgesvc$ (wie etwa bei savilltech\msa_ts01_purgesvc) für den Einsatz mit jedem Dienst auf diesem Server bereit. Am Ende des Namens ist ein Dollarzeichen zu erwähnen und am Anfang steht ein AD-Domänenname.

Mit Hilfe des MMC-Snap-ins für die Dienste (services.msc) kann man sich das MSA anzeigen lassen. Dazu ist der Name des MSA anzugeben und beide Kennwort-Felder im Reiter Anmeldung (Log On) müssen leer sein. Dann kann man der Dienst starten. Das MSA wird nun verwendet und der Administrator braucht sich danach nicht mehr um das Erneuern des Kennworts zu kümmern.

Das Zugriffsrecht auf das MSA und das Hinzufügen von MSAs zu Gruppen funktioniert wie bei jedem anderen Konto auch. Mit dem Einsatz des MMC-Snap-ins Active Directory-Benutzer und -Computer, mit Powershell-Cmdlets wie Add-ADGroupMember oder mit allen anderen Tools für das Arbeiten mit  Gruppen stehen weitere Bearbeitungsoptionen bereit.

Muss der Administrator zum Beispiel doch einmal das Kennwort für eine MSA zurücksetzen, eignet sich zum Beispiel die folgende Kommandozeile:

Reset-ADServiceAccountPassword -identity  [MSA name]

Allerdings sollte es kaum mehr einen bedarf geben, wo diese Aktion nötig ist.
Möchte man eine bestimmtes MSA nicht länger verwenden, braucht man nur den entsprechenden Dienst (oder die Dienste) zu aktualisieren. Dabei wird das MSA dann als alternatives Konto für das Anmelden angegeben. Dann ist der folgende Befehl nötig:

Remove-ADServiceAccount -identity  [MSA name]

Damit wird dann das MSA vom Server entfernt.

SPN-Management von Kerberos wird einfacher

Ein weiteres Problem bei Dienstkonten ist das Service Principal Name Management (SPN-Management), wie es bei Kerberos auftritt. Die SPNs werden von den jeweiligen Diensten im AD eingetragen.

Client-Systeme suchen unter den SPNs, um das Benutzer- oder Computer-Konto zu finden, das der Dienst verwendet, um die beidseitige Authentifizierung abzuwickeln. Der SPN ist Teil entweder eines Computer- oder eines Benutzerobjekts. Im Normalfall dürfen nur Domänen-Administratoren die SPNs aktualisieren. Doch manchmal kann das auf ein Dienst machen, wenn er unter dem lokalen Systemkonto läuft.

Mit Hilfe der MSAs ist es möglich, das SPN-Management an Service-Administratoren zu delegieren. Dazu muss man aber zuerst das Delegieren bei den MSAs aktivieren. Dazu eignet sich der folgende Befehl:

Set-ADServiceAccount -TrustedForDelegation  $true
  -identity [MSA name]

Damit wird das Delegieren aktiviert und danach kann das angegebene Zielobjekt die SPNs für das Objekt ändern. Das SPN-Management ist mit den MSAs einfacher, doch damit das funktioniert, muss die Domäne im Windows Server 2008 R2 Modus laufen – sprich alle Domänencontroller müssen Windows Server 2008 R2 am Laufen haben.

Ist eine derartige Konfiguration gegeben, ist das automatische Aktualisieren der SPN in den folgenden Szenarien möglich (und damit entfallen die entsprechenden manuellen Arbeiten):

• Umbenennen des Computerkontos,
• Ändern des Attributs dnshostname des Computerkontos,
• Ändern des Attributs additionaldnshostname des Computerkontos sowie
• Ändern des Attributs additionalsamaccountname des Computerkontos.

Virtuelle Konten

Wenn kein Zugriff auf ein bestimmtes Domänenkonto nötig ist und lediglich das Computerkonto gewünscht wird, gibt es eine Abart des MSA-Funktionalität: Ein virtuelles Konto (Virtual Account) agiert wie eine einmalige Instanz des Netzwerkdienstkontos (Network Service Account, NSA) auf dem lokalen Computer. Damit vermeidet man den Einsatz eines generischen NSA und die zugehörigen Probleme, wenn man die Systeme und ihre Aktivitäten zu überwachen hat – so wie sie bei gemeinsam genutzten Konten auftreten.

Da ein virtuelles Konto wie ein einmaliger Klon des eingebauten NSA agiert, erledigt der Dienst die Kommunikation mit anderen Ressourcen im Netzwerk wie das Computer-Objekt-Konto. Um die virtuellen Konten konfigurieren zu können, muss man die lokalen Administratorrechte auf der jeweiligen Maschine haben.

Wie auch die MSA sind die virtuellen Konten nur auf Systemen mit Windows Server 2008 R2 und Windows 7 verfügbar. Es bestehen keine Anforderungen an die Domänen oder das Schema und man kann virtuelle Konten nicht verwalten.
Um ein virtuelles Konto zu benutzen, muss man auf dem Reiter Anmelden (Log ON) des Dienstes NT SERVICE\[service name]" eintragen und sicherstellen, dass beide Kennwort-Felder leer sind. Das reicht dann auch schon. Der Dienstname, den man als Kontennamen eingibt, muss genau dem Dienstnamen des Dienstes entsprechen (und nicht dem langen Anzeigenamen).

In der Abbildung 2 wurde der Remote Debugger des Visual Studio so konfiguriert, dass er ein virtuelles Konto verwendet und dabei das Konto NT Service\msvsmon90 (mit leeren Kennwortfeldern) verwendet. Mit einem Klick auf Apply werden dann die Kennwörter automatisch befüllt.

Den kurzen Namen eines Dienstes kann man sich auf mehrere Arten besorgen. Eine Möglichkeit ist das Durchsuchen der Registry unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services. Eine andere Methode ist das Kommando SC QUERY und der einfachste Weg ist bei den Eigenschaften des Dienstes auf dem Reiter Allgemein der Wert, der für den Service Name eingetragen ist.

Unterstützung für MSAs

Einige Anwendungen fragen im Verlauf der Installation nach dem Konto und dem Kennwort, das verwendet werden soll. In diesen Fällen kann der Administrator nach der Installation den Dienst ändern und die gewünschten Rechte und Berechtigungen in das MSA kopieren. Einige Applikationen werden dies jedoch nicht erlauben –und damit kann man mit ihnen die MSA nicht verwenden.

Wer auf eine derartige Situation trifft, sollte dem Hersteller der Anwendung informieren, dass er diese Funktionalität in der nächsten Version oder beim nächsten Patch für seine Anwendung mit im Programm hat. Viele Applikationen und Features einschließlich der IIS 7.5 Application Pool Identities unterstützen die MSA bereits.

Es bleibt zu hoffen, dass in der nächsten Windows-Version der Support für MSA auch bei Cluster- oder Lastverteilungs-Konfigurationen unterstützt wird. Nichtsdestotrotz hat der Administrator mit den MSAs eine Trumpfkarte in der Hand, um viele Probleme mit den Dienstkonten auszustechen.

John Savill/rhh