Wenn unsere gMSA-Konten automatisch rotiert werden, treten etwa 1–10 Minuten lang Anmeldefehler auf. Dies ist besonders bei gMSA-Clientkonten offensichtlich, die eine Verbindung zu MS SQL Server herstellen, aber ich glaube, es passiert auch bei anderen gMSA-Konten. MS SQL Server läuft nicht als gMSA-Konto, aber unsere Anwendung verwendet gMSA, um eine Clientverbindung zu SQL herzustellen. Standardmäßig beträgt ManagedPasswordIntervalInDays alle 30 Tage, sodass wir dies jeden Monat zur gleichen Zeit sehen.
Wenn ich die Domänencontrollerprotokolle überprüfe, sehe ich keine Anmeldefehler für den gMSA-Benutzer, aber der SQL-Server protokolliert den folgenden Fehler
SSPI-Handshake ist beim Herstellen einer Verbindung mit integrierter Sicherheit mit Fehlercode 0x8009030c, Status 14, fehlgeschlagen; die Verbindung wurde geschlossen. Grund: AcceptSecurityContext ist fehlgeschlagen. Der Fehlercode des Betriebssystems gibt die Fehlerursache an. Der Anmeldeversuch ist fehlgeschlagen [CLIENT: xxxx]
Nach meinen Erkenntnissen weist dieser Fehler normalerweise auf eine falsche Benutzername/Passwort-Kombination hin.
Dies tritt bei mehreren Clients auf und jeder von ihnen stellt nach 1-10 Minuten wieder eine Verbindung her. Die Clients stellen nicht alle gleichzeitig eine Verbindung her, sondern es scheint innerhalb dieses Zeitfensters zufällig zu sein.
Anfangs dachte ich, es könnte mit der AD-Replikation des geänderten Passworts zusammenhängen, also haben wir das standardmäßige Replikationsintervall zwischen Standorten auf USE_NOTIFY geändert, um sofort zu replizieren. Wenn die Replikation das Problem wäre, würde ich erwarten, dass Anmeldefehler auf DCs auftreten, und ich sehe keine Anmeldefehler auf DCs. Ich hatte auch gedacht, dass der SQL-Server vielleicht das Authentifizierungstoken zwischenspeichert, aber wenn das der Fall wäre, würde ich erwarten, dass alle Clients gleichzeitig aufgelöst werden (d. h. wenn der SQL-Server aktualisiert wird). Da die Clients jeweils zu einem anderen Zeitpunkt wieder zu arbeiten beginnen, scheint es nicht auf der SQL-Server-Seite zu liegen, sondern eher auf der Client-Seite. Vielleicht das Zwischenspeichern des gMSA-Passworts oder vielleicht etwas im Zusammenhang mit Timeout und Wiederholungs-Backoffs.
Antwort1
Wir haben denselben Fehler aufgrund eines SPN-Problems generiert, das dazu führte, dass sich das gMSA beim SQL-Server über NTLM statt über Kerberos authentifizierte. Wenn Sie sich beim SQL-Server anmelden und die Sitzungen über überprüfen, sys.dm_exec_connectionssollten Sie eine Liste der Sitzungen mit NTLM sehen
(Sie können klist sessionsdie Sitzungen auch über die Befehlszeile anzeigen)
Wir konnten unsere Fehler mit den Passwortänderungen mithilfe von Protokollanalysetools korrelieren und wussten daher, dass dies der Übeltäter war. Ich weiß nicht, wie oft der SCM seine Kopie des Passworts aktualisiert, aber wenn der Dienst sich beim SQL-Server authentifiziert und Kerberos verwendet, sollten die Passwortänderungen meines Erachtens unabhängig von der Lebensdauer/Verlängerung der Kerberos-Sitzung sein, sodass der generierte Fehler ein eindeutiger Hinweis darauf ist, dass das Passwort über NTLM an den SQL-Server-Host gesendet wird. Nachdem wir unser SPN-Problem behoben hatten (das auf einen zusätzlichen DNS-A-Eintrag zurückzuführen war), wechselten die Sitzungen zur Kerberos-Authentifizierung.
Antwort2
Ich fand heraus, dass dies an der Art und Weise lag, wie der Windows-Dienst konfiguriert war. Der Windows-Dienst war als Standarddienst mit einem regulären Benutzerkonto konfiguriert, bei dem es sich zufällig um ein gMSA-Konto handelte und nicht um einen Windows-Dienst mit einem verwalteten Konto.
Dies kann wie folgt überprüft werden:
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
Dies kann geändert werden durch Ausführen von
sc.exe managedaccount ServiceName TRUE
Nach der Änderung des zu verwaltenden Windows-Dienstkontotyps zeigen erste Tests, dass die Anmeldungen während der gMSA-Kennwortrotation jetzt erfolgreich sind.