gMSA TroubleShooting unter Windows Server 2025

Einleitung

Auf meinem ersten produktiven Windows Server 2025 wollte ich eine geplante Aufgabe importieren, mit der die Datensicherung über Windows Server Backup gesteuert werden soll. Die Aufgabe selber läuft bei allen Servern mit unterschiedlichen Group Managed Service Accounts (gMSA).

Für die Konfiguration der Aufgabe mit diesem speziellen Account nutze ich mein PowerShell-Script „gMSA-Admin“. Das funktionierte im Windows Server 2016, 2019 und 2022 hervorragend. Unter Windows Server 2025 bekomme ich aber einen Fehler angezeigt:

In diesem Artikel analysiere ich das Problem und finde die Lösung.

TroubleShooting

Nachstellen des Problems

Zur Eingrenzung der Ursache habe ich mir ein altes Demo-Script aus meiner Kursunterlagensammlung geholt und experimentiere damit auf dem Testserver „Win-2025“. Das ist mein Script:

# RSAT für AD installieren
    Install-WindowsFeature RSAT-AD-PowerShell | Out-Null

# Variablen
    $Domain = (Get-ADDomain).dnsroot
    $gMSA = 'gMSA-Test1'

    $MemberServer = 'Win-2025' | Get-ADComputer

# neuen gMSA erstellen      
    New-ADServiceAccount `
        -Name $gMSA `
        -DNSHOSTNAME "$gMSA.$Domain" `
        -PrincipalsAllowedToRetrieveManagedPassword $MemberServer
                    
# Installieren des gMSA (nur für Testzwecke)
    Install-ADServiceAccount $gMSA
    Test-ADServiceAccount $gMSA    

# ScheduledTask erstellen        
    $action    = New-ScheduledTaskAction  "c:\scripts\test-$gMSA.bat" 
    $trigger   = New-ScheduledTaskTrigger -AtLogOn
    $principal = New-ScheduledTaskPrincipal -UserID "$Domain\$gMSA$" -LogonType Password
    Register-ScheduledTask -TaskName "Test-$gMSA" –Action $action –Trigger $trigger –Principal $principal -ErrorAction SilentlyContinue | Out-Null

    New-Item -Path "c:\scripts"  -ItemType directory -ErrorAction SilentlyContinue | Out-Null
    "whoami > c:\Scripts\Protokoll-$gMSA.txt" | Out-File -FilePath "c:\scripts\test-$gMSA.bat" -Encoding default -ErrorAction SilentlyContinue

# ScheduledTask testen    
    Start-ScheduledTask -TaskName "Test-$gMSA"
    Get-Content -Path "c:\Scripts\Protokoll-$gMSA.txt"

Zeile 2 installiert dann das PowerShell-Modul Active Directory, dann folgen einige Variablenzuweisungen. Da der Testserver direkt im Tier-0 platziert ist, konnte ich mich mit meiner T0-Kennung mit Domain Admin Berechtigung anmelden und dann mit Zeile 11 einen neuen gMSA anlegen:

Im Active Directory ist er dann ebenfalls sichtbar:

Bei der Installation des neuen Accounts in Zeile 17, die nur für demonstrative Zwecke notwendig ist, erhalte ich dann aber einen Fehler:

„Das Dienstkonto kann nicht installiert werden. Fehlermeldung: Der bereitgestellte Kontext stimmte nicht mit dem Ziel überein“… Die Meldung habe ich noch nicht gesehen, er passt auch nicht zu dem meines gMSA-Admin-Scriptes.

Suche in den Eventlogs #1

Ich durchsuche erst einmal die Eventlogs des Servers und der Domain Controller, denn da müsste doch was zu finden sein. Auf den DCs finde ich aber nur ein einziges Event. Das ist die Anlage des Accounts gewesen:

Das bringt mich nicht weiter.

Suche mit Wireshark

Da ich einen Wireshark auf dem Testsystem installiert habe, schneide ich mal den Traffic zwischen ihm und den DCs beim Account-Installieren mit. Aber auch hier sehe ich (zugegeben erwartet) nur verschlüsselte Kommunikation beim Abruf des gMSA-Passwortes:

Suche in den Eventlogs #2

OK. Irgendwo muss der Server das Event protokollieren. Auf meinem Server gibt es 449 Eventlogs. 131 davon haben auch mindestens einen Record:

Die manuell zu durchsuchen wäre Wahnsinn. Das lasse ich daher die PowerShell erledigen. Mit Get-WinEvent kann ich die Events filtern. Die Treffer speichere ich in einer Array-Variable. Das ist mein Code:

# Auslösen des Events
    Install-ADServiceAccount -Identity 'gMSA-Test1'

# suche in den aktiven Events in der letzten Minute nach dem Namen des Accounts 
    $Treffer = @()

    get-winevent -ListLog * | 
      Where-Object { $_.RecordCount -gt 0 } | 
        ForEach-Object {
          $CurLog = $_

          $Treffer += Get-WinEvent `
              -ErrorAction SilentlyContinue `
              -FilterHashtable @{ 
                  logname   = $CurLog.LogName
                  StartTime = (get-date).AddMinutes(-1)
                  Data      = 'gMSA-Test1' 
               } 
        }

# Ausgabe der Ergebnisse
    $Treffer | Format-List -Property *

Und hier das Ergebnis. Es gibt 2 Events!!!

Diese Events schaue ich mir genauer an:

Nun kenne ich das Eventlog: Microsoft\Windows\Security-Netlogon\Operational. Das sehe ich mit in der Ereignisanzeige genauer an. In der XML-Ansicht sieht man auch gut meinen DATA-Filter:

Der Fehlertext ist identisch mit dem Fehler in der PowerShell. Nun kenne ich aber zusätzlich die Event-ID und die Quelle. Das kann die Internetsuche deutlich vereinfachen:

Mir fällt aber auf, dass es immer 2 Events mit den Event-IDs 9001 und 9002 gibt. Also prüfe ich noch das andere Event:

Das könnte die Ursache sein: „Das Konto „gMSA-Test1“ kann nicht als verwaltetes Dienstkonto auf dem lokalen Computer verwendet werden, da nicht alle vom Konto unterstützten Verschlüsselungstypen auf dem lokalen Computer unterstützt werden.“

Analyse der verwendeten Verschlüsselungstypen

Die Verschlüsselungstypen beziehen sich bestimmt auf das Protokoll Kerberos, den gMSA funktionieren nur im Active Directory und da wird Microsoft bestimmt kein veraltetes NTLM nutzen. Daher prüfe ich die Eigenschaften meines gMSA-Kontos. Der gMSA unterstützt noch RC4_HMAC_MD5!

Und was unterstützt mein Windows Server 2025? Nur die moderneren Verschlüsselungstypen!

Das ist der Fehler! Nun stellt sich mir die Frage, wo diese Einstellung her kommt. Ein gpresult löst das Rätsel. Es ist die neue Sicherheits-GPO, die ich von Gitlab (hier beschrieben) gezogen habe!

Die Lösung

Wenn es hier also einen Missmatch gibt, dann kann ich das am gMSA-Konto im Active Directory ändern. Dafür muss ich nur den anderen Bitwert eintragen, der nur AES125 und AES256 erlaubt und RC4 deaktiviert. Die Codes habe ich hier im Internet gefunden: Decrypting the Selection of Supported Kerberos Encryption Types | Microsoft Community Hub. Ich ändere den Wert von 28 auf 24:

Nun teste ich die Installation des gMSA auf meinem Testserver erneut und suche nach den dazugehörigen Events. Der gMSA lässt sich nun installieren – wenn auch ohne Eventlog auf dem Memberserver:

Nun teste ich noch die Anlage eines ScriptTasks über die PowerShell. Dieser wird vom gMSA ausgeführt und soll das Ergebnis von whoami in eine Textdatei schreiben:

# ScheduledTask erstellen        
    $action    = New-ScheduledTaskAction  "c:\scripts\test-$gMSA.bat" 
    $trigger   = New-ScheduledTaskTrigger -AtLogOn
    $principal = New-ScheduledTaskPrincipal -UserID "$Domain\$gMSA$" -LogonType Password
    Register-ScheduledTask -TaskName "Test-$gMSA" –Action $action –Trigger $trigger –Principal $principal -ErrorAction SilentlyContinue | Out-Null

    New-Item -Path "c:\scripts"  -ItemType directory -ErrorAction SilentlyContinue | Out-Null
    "whoami > c:\Scripts\Protokoll-$gMSA.txt" | Out-File -FilePath "c:\scripts\test-$gMSA.bat" -Encoding default -ErrorAction SilentlyContinue

Das Ergebnis sieht gut aus:

Damit sollte mein gMSA-Admin-Script auch wieder laufen:

Abschluss

Bei solchen Artikeln überlege ich manchmal, ob ich nicht einfach nur das Problem beschreiben und die Lösung präsentieren sollte. Ich finde aber, dass die Schritte im TroubleShooting mindestens genauso wertvoll wie die Lösung sind. Denn wenn ihr die Methodik und die Werkzeuge in Aktion seht und versteht, dann könnt ihr auch andere Probleme lösen. 😉

Und nun kann ich die Sicherungsjobs meiner 3 neuen Windows Server 2025 endlich auf die gMSA-Konten umstellen:

Stay tuned.