Wie man Dienste und geplante Aufgaben mit Managed Service Accounts (MSA & gMSA) verwaltet
Sind Sie es leid, ständig Passwörter für Ihre Dienste und geplanten Aufgaben zu verwalten? Dann sind Managed Service Accounts (MSA) und Group Managed Service Accounts (gMSA) eine echte Erleichterung. Sie verwalten Passwortänderungen automatisch, und das Beste daran: Schluss mit der altmodischen Passwortverwaltung! Natürlich eignen sie sich hauptsächlich für Domänenumgebungen, aber wenn Sie Active Directory (AD) nutzen und Anwendungen sicher ausführen möchten, ohne sich Gedanken um Anmeldeinformationen machen zu müssen, sind sie die ideale Lösung. Die Funktionsweise mag anfangs etwas ungewöhnlich erscheinen, aber glauben Sie mir, nach der Einrichtung werden Sie eine enorme Erleichterung spüren. Mit gMSA können Sie außerdem mehrere Server nutzen, was die Skalierung oder das Clustering von Anwendungen deutlich vereinfacht. Hier finden Sie alle wichtigen Informationen zum Erstellen, Installieren und Verwenden dieser Konten für Dienste und geplante Aufgaben auf Windows-Servern oder PCs, die mit AD verbunden sind.
- So erstellen Sie ein verwaltetes Konto (MSA) in Active Directory
- Erstellen eines gruppenverwalteten Dienstkontos (gMSA) in Active Directory
- Installation eines verwalteten Dienstkontos unter Windows
- So führen Sie einen Windows-Dienst als verwaltetes Dienstkonto aus
- Ausführen einer geplanten Windows-Aufgabe mit einem verwalteten Dienstkonto (gMSA)
Zunächst einmal gibt es AD in zwei Hauptvarianten:
- MSA : Gut geeignet für den Einsatz auf einem einzelnen Server (
msDS-ManagedServiceAccount), jedoch nicht für Cluster oder mehrere Server.Üblicherweise wird es für Dienste verwendet, die auf einem einzelnen Rechner laufen. - gMSA : Eingeführt in Windows Server 2012, gedacht für mehrere Server, ideal für Cluster-Apps oder -Dienste, die eine gemeinsame Identität benötigen (
msDS-GroupManagedServiceAccount).
So erstellen Sie ein verwaltetes Konto (MSA) in Active Directory
Bevor Sie MSAs erstellen, müssen Sie den KDS-Stammschlüssel generieren. Andernfalls kann Active Directory keine Passwörter für Ihre MSAs generieren. Der Befehl ist einfach, muss aber nur einmal ausgeführt werden: `powershell Add-KdsRootKey –EffectiveImmediately`.Dadurch wird die Schlüsselerstellung gestartet. Beachten Sie: In den meisten Umgebungen dauert die Synchronisierung des Schlüssels durch die Active Directory-Replikation etwa 10 Stunden. Erwarten Sie also keine sofortige Lösung. Wenn Sie testen oder es eilig haben, können Sie die Aktivierung sofort mit folgendem Befehl durchführen: `powershell Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))`.Um zu überprüfen, ob der Schlüssel vorhanden ist, führen Sie `powershell Get-KdsRootKey` aus und verifizieren Sie ihn anschließend mit: `powershell Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId`.Sobald dies erledigt ist, lässt sich ein MSA einfach erstellen: `powershell New-ADServiceAccount -Name msaAppService -RestrictToSingleComputer`.Sie sollten dieses MSA wahrscheinlich an einen bestimmten Server binden, damit Dienste sicher ausgeführt werden können. Um dies zu tun, rufen Sie das Computerobjekt in Active Directory ab und fügen Sie das Dienstkonto hinzu: `powershell $identity = Get-ADComputer -Identity „Server01“ Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaAppService`.Es empfiehlt sich, zu überprüfen, ob das Konto unter CN=Verwaltete Dienstkonten in Active Directory-Benutzer und -Computer (ADUC) angezeigt wird. Dieser Container ist jedoch standardmäßig ausgeblendet, solange Sie nicht die *Erweiterten Funktionen* im Menü Ansicht von ADUC aktivieren. Versteckte Funktionen sind unerwünscht.
Erstellen eines gruppenverwalteten Dienstkontos (gMSA) in Active Directory
GMSAs sind etwas komplexer, aber äußerst praktisch, wenn mehrere Server dieselbe Identität benötigen. Zunächst benötigen Sie eine AD-Sicherheitsgruppe, der Sie die Server hinzufügen, auf denen diese GMSA ausgeführt werden soll. Erstellen Sie die Gruppe: `powershell New-ADGroup -Name grWebServers -Path „OU=Servers, DC=domain, DC=com“ -GroupScope Global`.Fügen Sie anschließend Server hinzu: `powershell Add-ADGroupMember -Identity grWebServers -Members server01$, server02$, server03$`.Erstellen Sie danach das gMSA und geben Sie die Servergruppe als zulässigen Prinzipal an: `powershell New-ADServiceAccount -Name gmsaWebApp -DNSHostName gmsaWebApp.domain.com -PrincipalsAllowedToRetrieveManagedPassword grWebServers -Verbose`.Wenn Sie gerade Server zur Gruppe hinzugefügt haben, starten Sie diese neu oder aktualisieren Sie deren AD-Gruppencache: `cmd klist.exe -lh 0 -li 0x3e7 purge` (Dadurch wird der Kerberos-Ticketcache aktualisiert).Das gMSA wird automatisch in der Organisationseinheit „Verwaltete Dienstkonten“ (OU) angezeigt, und Active Directory übernimmt die Kennwortrotation nahtlos. Für Dienste, die eine Kerberos-SPN-Registrierung benötigen, müssen Sie SPNs festlegen: cmd setspn -s MSSQLSvc/mssql01 domain\gmsaWebApp$ setspn -s MSSQLSvc/mssql01.domain.com domain\gmsaWebApp$ Dieser Schritt bereitet manchen Schwierigkeiten, ist aber für SQL Server und andere Kerberos-abhängige Anwendungen unerlässlich.
Installation eines verwalteten Dienstkontos unter Windows
Um MSAs oder gMSAs unter Windows zu verwenden, stellen Sie sicher, dass das Active Directory-Modul bereit ist: `powershell Add-WindowsFeature RSAT-AD-PowerShell`.Installieren Sie anschließend das Konto auf Ihrem Server: `powershell Install-ADServiceAccount -Identity gmsaWebApp`.MSAs müssen nun installiert werden, damit Windows sie erkennt. GMSAs hingegen sind automatisch verfügbar, sobald AD sie erkennt und der Server über die entsprechenden Berechtigungen verfügt.Überprüfen Sie die Funktion: `powershell Test-ADServiceAccount gmsaWebApp`.Wenn die Ausgabe True lautet, ist alles einsatzbereit. Bei False ist das Konto möglicherweise nicht korrekt installiert oder es fehlen Berechtigungen.Zusätzlicher Hinweis: Dienste mit MSAs können nicht einfach über RunAs ausgeführt werden. Stattdessen müssen Sie das Konto in der Dienstkonfiguration oder über PowerShell angeben. Zum Testen können Sie *PsExec* verwenden: cmd PsExec64.exe -i -u domain\gmsaWebApp$ -p ~ cmd.exe. Die Tilde (~) ist ein Platzhalter, der Windows – zumindest theoretisch – veranlasst, das Passwort automatisch aus Active Directory abzurufen. Führen Sie anschließend `whoami` aus, um dies zu überprüfen.
So führen Sie einen Windows-Dienst als verwaltetes Dienstkonto aus
Jetzt wird es ernst. So richten Sie einen Dienst unter einer MSA oder gMSA ein: – Öffnen Sie `services.msc` – Suchen Sie den gewünschten Dienst – Klicken Sie mit der rechten Maustaste, wählen Sie Eigenschaften und wechseln Sie dann zur Registerkarte Anmelden – Wählen Sie Dieses Konto und geben Sie den Kontonamen ein, der mit einem $ endet (z. B.`domain\gmsaWebApp$`) – Es ist kein Kennwort erforderlich; Windows erteilt die Berechtigungen automatisch – Klicken Sie auf OK und starten Sie den Dienst neu. Dasselbe gilt für IIS-Anwendungspools: Sie können die Identität auf ein benutzerdefiniertes Konto festlegen. Gehen Sie dazu in IIS, wählen Sie den Anwendungspool aus und klicken Sie dann auf *Erweiterte Einstellungen*.Ändern Sie die *Identität* von `ApplicationPoolIdentity` in *Benutzerdefiniertes Konto* und geben Sie dann ein
Ausführen einer geplanten Aufgabe mit einem verwalteten Dienstkonto (gMSA)
Das Ausführen geplanter Aufgaben als gMSA ist mit der grafischen Benutzeroberfläche etwas umständlich – Microsoft empfiehlt hierfür dringend PowerShell. So erstellen Sie eine Aufgabe über PowerShell: `powershell $action = New-ScheduledTaskAction -Execute powershell.exe -Argument „-file C:\Scripts\Backup.ps1 -executionpolicy bypass“ $trigger = New-ScheduledTaskTrigger -At 23:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID domain\gmsaWebApp$ -LogonType Password -RunLevel Highest Register-ScheduledTask -TaskName „DailyBackup“ -Action $action -Trigger $trigger -Principal $principal` Hinweis: Sie müssen die Option `-UserID` mit dem gMSA-Konto angeben. Bei manchen Systemkonfigurationen akzeptieren über die grafische Benutzeroberfläche erstellte Aufgaben gMSA nur, wenn sie mit PowerShell oder schtasks.exe erstellt werden: `cmd schtasks /Create /TN „Backup“ /TR „powershell.exe -file C:\Scripts\Backup.ps1“ /SC DAILY /ST 23:00 /RU „domain\gmsaWebApp$“`.Für die Berechtigungen müssen Sie gMSA der Gruppe „Sicherungsoperatoren“ hinzufügen, um Lese- und Schreibrechte zu erhalten, und sicherstellen, dass gMSA in der lokalen Gruppenrichtlinie (`gpedit.msc`) die Berechtigung „Als Batchauftrag anmelden“ erhält. Der Vorteil von gMSA? Wenn Windows das Kennwort automatisch aktualisiert, funktionieren geplante Aufgaben weiterhin. Es sind keine Updates oder Neukonfigurationen erforderlich.
Verwaltete Dienstkonten – insbesondere gMSA – vereinfachen die Sicherheit und reduzieren den Aufwand. Die Einrichtung erfordert zwar etwas Vorarbeit, aber sobald sie eingerichtet sind, laufen Dienste und Zeitpläne reibungslos und ohne Passwortabfragen. Falls das nicht hilft, überprüfen Sie Berechtigungen, Gruppenrichtlinienobjekte (GPOs) oder starten Sie die Active Directory-Dienste neu und warten Sie die Replikation ab. Hoffentlich hilft das jemandem, sich viel Ärger zu ersparen.
Zusammenfassung
- KDS-Root-Schlüssel für die gMSA-Passwortgenerierung erstellt.
- Richten Sie MSA und gMSA in AD ein und verknüpfen Sie diese mit Computern oder Gruppen.
- MSAs/gMSAs wurden auf Windows-Servern installiert.
- Die Dienste und IIS wurden so konfiguriert, dass sie unter verwalteten Konten ausgeführt werden.
- Richten Sie geplante Aufgaben mit gMSA-Konten mithilfe von PowerShell oder schtasks ein.
Zusammenfassung
Die Einrichtung dieser verwalteten Konten erfordert etwas Aufwand, aber sobald es geschafft ist, wird alles viel einfacher. Keine herumliegenden Passwörter mehr, keine manuellen Updates – nur noch ein sicherer, automatisierter Dienst. Wenn dadurch auch nur ein weiterer Dienst alle paar Monate reibungslos läuft, haben wir unser Ziel erreicht. Hoffentlich funktioniert es bei allen anderen genauso gut.