Windows: Group Managed Service Account für Dienste konfigurieren

Wenn man so möchte als Ergänzungsbeitrag zu MS SQL Server 2014 Express auf einem Domänencontroller installieren folgt nun eine Kurzanleitung, wie man unter Windows Server 2012 R2 ein Group Managed Service Account (gMSA) für Dienste einrichtet.

Als Beispiel dient ein Microsoft SQL Server 2014 Express, der für SFIRM V4 verwendet werden soll und auf einem Domänencontroller installiert ist, bei dem nachträglich vom Systemkonto auf ein gMSA gewechselt werden soll.

Alle nachfolgenden Befehle werden auf dem Server in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten ausgeführt.

KdsRootKey anlegen

Zunächst prüfen, ob es bereits einen Key Distribution Services Root Key (KdsRootKey) existiert:

Get-KdsRootKey

Falls nicht, diesen Anlegen:

Add-KdsRootKey –EffectiveImmediately

In der Vorgabe muss man allerdings 10 Stunden warten, bevor man weiter arbeiten kann. Hintergrund ist, sofern vorhanden, das die Replikation zwischen allen Domänencontrollern abgewartet werden muss. Umgehen kann man dies mit diesem Befehl:

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

Dadurch wird der Schlüssel zehn Stunden in der Vergangenheit angelegt. Bei einem einzelnen oder wenigen Domänencontroller(n) geht das in Ordnung.

gMSA erstellen

New-ADServiceAccount <Kontoname> -DNSHostName <FQDN-des-Servers-auf-dem-der-Dienst-läuft> -PrincipalsAllowedToRetrieveManagedPassword "Gruppe"

Beispiel:

New-ADServiceAccount SFIRMV4 -DNSHostName testdc01.testdom01.local -PrincipalsAllowedToRetrieveManagedPassword "Domänencontroller"

Per Vorgabe werden gMSA im Active Directory unter „Managed Service Accounts“ angelegt. Dort sollte man nun das Konto sehen können:

Dienstkonto dem Server zuweisen

Install-AdServiceAccount <Kontoname>

gMSA prüfen

Test-AdServiceAccount <Kontoname>

Dienstkonto des SQL Servers ändern

  • Den „SQL-Server-Konfigurationsmanager“ starten.
  • Zu „SQL-Server-Dienste“ wechseln.
  • Die betreffende Instanz doppelt anklicken.
  • Auf der Registerkarte „Anmelden“ „Dieses Konto:“ und „Durchsuchen“ anklicken.
  • Auf „Objekttypen“ klicken, alles abwählen und „Dienstkonten“ aktivieren.
  • Entweder den Kontoname eingeben oder auf „Erweitert“ klicken und das Konto auswählen.
  • Auf „OK“ klicken.

Damit die Änderung übernommen wird, muss der Dienst neu gestartet werden. Dies als auch weitere notwendige Anpassungen (Registry, Rechte im Dateisystem, …), übernimmt der Konfigurationsassistent von selbst.

Quellen:

MS Docs – Create the Key Distribution Services KDS Root Key

MS Docs – Getting Started with Group Managed Service Accounts

Wydler – Group Managed Service Accounts

Active Direcotry FAQ – Group Managed Service Accounts

Update 16.03.2018

Irgendetwas scheint noch zu fehlen, da nach einem Neustart der Server die SQL-Dienste mit konfigurierten gMSA nicht starten (Ereignis-IDs: 7038, 7034 und 7000).

Eine kleine Änderung im „SQL-Server-Konfigurationsmanager“ soll angeblich ausreichen, um die SQL-Dienste wiederzubeleben. Wenn’s schnell gehen muss, auch wenn es nicht schön ist, auf die Schnelle das Systemkonto verwenden.

Leider habe ich noch nicht herausfinden können, was da schief läuft. Recherche und Tests diverser Lösungsvorschläge half leider bislang nicht. Anscheinend ist man damit auch nicht alleine. Falls jemand einen Tipp hat, dann bitte via Kommentarfunktion melden.

Update 11.04.2018

Gelöst ist es noch nicht. Bitte die Kommentare beachten.

8 Gedanken zu „Windows: Group Managed Service Account für Dienste konfigurieren

  1. Pingback: MS SQL Server 2014 Express auf einem Domänencontroller installieren | Andys Blog – Linux & Windows

  2. Wir haben gerade bei einer Schulung das selbe Problem nachvollziehen können. Ein Neustart der Dienste nach dem Reboot hilft bei uns jedenfalls. Somit lässt sich dieses Feature dann zumindest mit den automatischen Neustartaktionen des Dienstes nutzen…

  3. Gut zu wissen, das man nicht der Einzige ist. Auf meinem Testsystem legt alleine schon das Ändern des Dienstkontos alles lahm, mitunter hilft nur ein Neustart des Servers. Zum Test habe ich den SQL-Dienst mal auf verzögerten Start gesetzt, leider keine Änderung. Automatischen Neustart habe ich auch mal getestet, leider auch keine Änderung. Als letzter potentieller Ausweg wurde der Dienst auf manuell gesetzt, um dann nach einer längeren Verzögerung den Dienst zu starten, das half auch nichts.

    Dann habe ich nochmals alles abgerissen (gMSA-Konto gelöscht, KdsRootKey entfernt, Server neugestartet) und neu eingerichtet. Witzigerweise erzählte mir dann das System, das dem Konto das Recht „Anmelden als Dienst“ fehlt, zuvor musste ich das nicht explizit zuweisen, aber sei’s drum. Ein GPO erstellt, das dieses Recht zuweisst. Dann war der Dienst mit gMSA wieder startbar. Dann Server wieder neugestartet und der Dienst bzw. der gMSA streikt wieder und zwar in der Art und Weise, das der Dienst nicht startet aber auch nichts im Eventlog auftaucht.

    Es scheint als habt ihr eher ein Timing-Problem, aber bei mir irgendwas anderes Schwierigkeiten bereitet.

  4. Bist du sicher, dass es sich hierbei nicht um einen GPO-Konflikt beim „Anmelden als Dienst“-Recht handelt? Sofern das von 2 verschiedenen gesetzt wird, geht es dann auch nur manchmal. Was sagt das Eventlog? (Security-Protokoll)

  5. Wie geschrieben, „Anmelden als Dienst“ musste ich beim letzten Test erstmals manuell setzen, zuvor ging es einfach so. Im Security-Log ist aktuell nichts vermerkt, seit 48 Minuten steht der Dienst bei „Wird gestartet“.

  6. Heute früh lief der Dienst dann. Fünf Minuten nach meinem letzten Kommentar war der Dienst gestartet. D.h. der Dienst benötigte insgesamt 53 Minuten um hoch zu kommen. Das ist durchaus erstaunlich, da auf der Testmaschine nichts weiter läuft und auch genug Ressourcen frei sind. Ich habe jetzt nochmal die Büchse neu gestartet, zuvor den Dienst auf manuell gelassen, nach dem Neustart einige (> 5) Minuten gewartet und diesen gestartet. Es dauerte diesmal 50 Minuten bis der Dienst lief. Man könnte nun süffisant sagen, es geht schon, ist aber mit „ein wenig“ Geduld verbunden. Tragbar finde ich diesen Zustand allerdings nicht.

  7. Um auszuschließen das es ein Timing oder Abhängigkeitsproblem „kurz“ nach dem Neustart ist, habe ich die Testmaschine heute früh neu gestartet, knapp 2 Stunden gewartet und dann den Dienst manuell gestartet. Leider keine Änderung.

    Abhängigkeitsprobleme werden z.B. hier ab „The pitfalls of using a gMSA with SQL Server“ beschrieben:

    Wayne Shefflied – Using a gSMA with SQL Server

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.