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.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
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…
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.
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)
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”.
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.
So ganz unbekannt ist dieses Verhalten wohl nicht:
MS TechNet Forum – gMSA log on occurs very slow or hang
MS Developer – SQLOS & Cloud Infrastructure Team Blog – MSA accounts used with SQL
Dort heisst es, gMSA würde von MS SQL nicht unterstützt, allerdings ist die Info von 2014.
Grundsätzlich funktioniert es ja.
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
Bekanntes Problem. 😉
https://learn.microsoft.com/de-de/troubleshoot/windows-server/performance/service-using-gmsa-account-not-start