gMSA Pilot zur Erstbereitstellung: KDS vor der Umstellung prüfen

Ein gMSA-Objekt ist noch kein migrierter Dienst

Ein gMSA Pilot zur Erstbereitstellung sollte mit einem funktionierenden Dienst unter seiner neuen Identität, einer genehmigten Rollback-Entscheidung und Nachweisen von den Hosts enden, auf denen er tatsächlich läuft. Das Anlegen eines gruppenverwalteten Dienstkontos in Active Directory erstellt ein Konto. Es belegt weder, dass eine produktive Anwendung dieses Konto verwendet, noch, dass jeder erforderliche Host dessen Anmeldedaten abrufen kann oder die Anwendung nach der Umstellung weiterhin den richtigen Zugriff besitzt.

Diese Unterscheidung ist wichtig, wenn ein Audit meldet, dass keine gMSAs verwendet werden. Nehmen Sie dieses Ergebnis zum Anlass, das Verzeichnisinventar und die Dienstlandschaft zu untersuchen. Ein neues Objekt kann ein Inventarsignal verschwinden lassen, während alle Dienste weiterhin unter ihrer alten Identität laufen. Umgekehrt kann eine unvollständige Erfassung ein vorhandenes Objekt übersehen. Keines dieser Ergebnisse beantwortet die betriebliche Frage: Welcher Dienst wurde erfolgreich umgestellt?

Führen Sie drei getrennte Aufzeichnungen: Verzeichnisobjekte, Host-Bereitschaft und Dienstumstellung. Die erste identifiziert Konten; die zweite hält fest, ob ein bestimmter Host das ausgewählte Konto verwenden kann; die dritte dokumentiert eine getestete Anwendung, die es verwendet. Dieser Artikel schlägt eine Freigabeprüfung für die erste Umstellung vor, mit einem Dienst und einem ausdrücklichen Wiederherstellungsplan. Er setzt nicht voraus, dass alle Benutzer mit SPN kompatible, aktive Dienste repräsentieren.

So funktioniert ein gMSA Pilot zur Erstbereitstellung

Beginnen Sie mit einem Dienstverantwortlichen und einem Anwendungsinventar statt mit einem Antrag auf Kontoerstellung. Erfassen Sie Dienstname, aktuelle Identität, Hostliste, Anwendungsversion, Startkonfiguration, Clients und nachgelagerte Ressourcen. Fragen Sie den Verantwortlichen, welche Funktionen verfügbar bleiben müssen und welche Nachweise den Erfolg der Änderung belegen würden. Ein Prozess, der startet, seine geplante Ausgabe aber nicht schreiben kann, hat den Pilotversuch nicht bestanden.

Microsoft dokumentiert die gMSA-Unterstützung für Dienste, die über den Service Control Manager konfiguriert werden, IIS-Anwendungspools, die Aufgabenplanung und Produkte, die die APIs für verwaltete Konten unterstützen. Der Clusterdienst selbst unterstützt keine gMSAs; kompatible Dienste, die darüber ausgeführt werden, können sie unterstützen. Bestätigen Sie das genaue Produkt und die Bereitstellungstopologie mit dem Verantwortlichen, bevor Sie den Pilotkandidaten auswählen. Microsoft Learn — Gruppenverwaltete Dienstkonten verwalten.

Bauen Sie die Änderungsdokumentation um diese voneinander unabhängigen Freigabeprüfungen auf:

Dies sind vorgeschlagene Kontrollen für den Pilotversuch, keine bereits in Ihrer Umgebung gemessenen Ergebnisse. Benennen Sie für jede Prüfung einen Verantwortlichen. Der AD-Verantwortliche betreut die Gesamtstrukturabhängigkeit; der Dienstverantwortliche akzeptiert das Anwendungsverhalten; der Änderungsgenehmiger autorisiert Umstellung und Wiederherstellung. Halten Sie fest, wer den Pilotversuch stoppen darf, wenn diese Einschätzungen voneinander abweichen.

Erkennung: Objekte, KDS-Bereitschaft und jeden Host prüfen

Ein klassenbasiertes Verzeichnisinventar abgleichen

Prüfen Sie mit einer unabhängigen Klassensuche, was das Collector-Inventar bedeutet. Das folgende schreibgeschützte Beispiel wurde aus den dokumentierten Parametern von Get-ADServiceAccount zusammengestellt. Ersetzen Sie den beispielhaften DC und Domänen-DN durch den genehmigten Umfang; wiederholen Sie die Abfrage für jede in den Pilotversuch einbezogene Domäne. Sie wurde nicht gegen Ihr Verzeichnis ausgeführt.

Get-ADServiceAccount -LDAPFilter '(objectClass=msDS-GroupManagedServiceAccount)' -SearchBase 'DC=example,DC=com' -SearchScope Subtree -Server 'dc01.example.com' -ResultSetSize $null

-LDAPFilter wählt die Strukturklasse unabhängig von der Heuristik des Collectors für das Mitgliedschaftsattribut aus. -SearchBase, -SearchScope und -Server machen die beabsichtigte Grenze ausdrücklich sichtbar; -ResultSetSize $null vermeidet eine Begrenzung der Gesamtergebniszahl. Bei allgemeinerer Verwendung liefert das Cmdlet sowohl eigenständige als auch gruppenverwaltete Konten. Behalten Sie daher die Klassenbeschränkung für dieses Inventar bei. Microsoft Learn — Get-ADServiceAccount.

Dokumentieren Sie die zurückgegebenen Identitäten und den Aktivierungsstatus zusammen mit Umfang und Abfrageergebnis. Findet diese Suche ein gMSA, das der Collector nicht erkannt hat, untersuchen Sie Berechtigungen, angeforderte Attribute, Suchgrenzen und Ergebnislimits. Beheben Sie die Abweichung nicht durch das Anlegen eines weiteren Kontos. Schlägt die Suche fehl, bewahren Sie den Fehler als Erfassungsfehler auf; eine erfolgreiche leere Abfrage und eine fehlgeschlagene Abfrage liefern unterschiedliche Nachweise.

Ordnen Sie anschließend jedes relevante Objekt realen Dienstkonfigurationen zu. Klären Sie, ob es ungenutzt, vorbereitet, außer Betrieb oder von einer getesteten Anwendung verwendet wird. Ein nicht zugeordnetes Objekt bleibt nicht zugeordnet. Ein Kontoname im Verzeichnis allein kann weder einen Dienstverantwortlichen benennen noch beweisen, dass ein Host das Konto verwendet.

Vorhandene KDS-Schlüssel vor dem Antrag auf einen neuen prüfen

Verwenden Sie in einem autorisierten administrativen Kontext mit dem KDS-Modul den dokumentierten Lesebefehl:

Get-KdsRootKey

Er ruft die Liste vorhandener Stammschlüssel einschließlich ihrer Schlüsselwerte ab. Prüfen Sie diese in der administrativen Umgebung und übernehmen Sie nur die erforderlichen Kennungen und die Bereitschaftsentscheidung in die Änderungsdokumentation; fügen Sie kein rohes Schlüsselmaterial in ein allgemeines Ticket ein. Dieser Befehl dient der Inventarisierung, nicht dem Test der Replikation. Microsoft Learn — Get-KdsRootKey.

Microsoft beschreibt eine Wartezeit von bis zu zehn Stunden nach dem Erstellen eines Stammschlüssels, damit die DC-Replikation vor der gMSA-Nutzung konvergieren kann. Eingeschränkte Replikationszeitpläne oder Replikationsfehler können weiterhin Abruffehler verursachen. Bitten Sie den AD-Verantwortlichen, die Verfügbarkeit des Schlüssels und den Replikationszustand für die DCs zu prüfen, die die Pilothosts bedienen; verstrichene Zeit allein liefert diesen Nachweis nicht. Microsoft Learn — Einen KDS-Stammschlüssel erstellen.

Ist bereits ein geeigneter Schlüssel vorhanden, sieht das Verwaltungsverfahren vor, die Schlüsselerstellung zu überspringen. Gibt es keinen, machen Sie den dokumentierten Prozess des AD-Verantwortlichen für Schlüsselerstellung und Replikation zur Voraussetzung, mit eigener Zeitplanung und Autorisierung. Packen Sie eine Gesamtstrukturabhängigkeit nicht in eine ungeprüfte Dienstkontoänderung.

Bereitschaft auf den tatsächlich autorisierten Hosts testen

Prüfen Sie die genehmigten Berechtigten für den Kennwortabruf und bestätigen Sie, dass sie der vorgesehenen Hostgruppe entsprechen. Microsofts Verwaltungsanleitung verlangt außerdem geeignete SPNs, DNS, Netzwerkzugriff, Zeitsynchronisierung und unterstützte Kerberos-Verschlüsselungstypen. Behandeln Sie diese als zu untersuchende Voraussetzungen, statt anzunehmen, eine erfolgreiche Verzeichnissuche würde sie bestätigen.

Führen Sie den dokumentierten Kontotest lokal auf jedem vorgesehenen Host aus und ersetzen Sie den beispielhaften Kontonamen:

Test-ADServiceAccount -Identity 'svc-pilot'

Microsoft definiert einen erfolgreichen Test als Bereitschaft, sich mit den aktuellen Anmeldedaten des Kontos zu authentifizieren und auf die Domäne zuzugreifen. Erfassen Sie Host, Zeitpunkt, Konto und tatsächliches Ergebnis. Der Test prüft weder Datenbankabfragen Ihrer Anwendung noch Dateischreibvorgänge, Client-Authentifizierung oder Neustartverhalten. Microsoft Learn — Test-ADServiceAccount.

Ein Fehlschlag hält die Umstellung auf. Untersuchen Sie mit den zuständigen Verantwortlichen die vorgesehene Autorisierung des Hosts, den Verzeichniszugriff sowie die KDS- und Replikationsabhängigkeit. Den Abrufzugriff auf eine breite Gruppe auszuweiten, ist keine akzeptable Abkürzung. Die bestehende Prüfung der Berechtigungen zum gMSA-Kennwortabruf erklärt, warum der Kreis der Leser eine gesondert zu prüfende Sicherheitsgrenze bildet.

Abhilfe: einen Dienst mit praktikablem Rollback pilotieren (Remediation)

1. Abnahmetests und Wiederherstellungsweg vereinbaren

Wählen Sie eine kompatible Anwendung, deren Verantwortlicher sowohl Normalbetrieb als auch Fehler beobachten kann. Bewahren Sie vor der Identitätsänderung die genehmigte Konfiguration, vorhandene Berechtigungen, das Startverhalten und die Basisergebnisse der Anwendungstests auf. Halten Sie das Wartungsfenster, die genehmigende Person, die für die Wiederherstellung zuständige Person und die auslösenden Bedingungen schriftlich fest.

Machen Sie die Bedingungen dienstspezifisch: Ein erforderlicher Client kann sich nicht authentifizieren, ein geplanter Vorgang schlägt fehl, eine erwartete Ressource ist nicht zugänglich oder ein Neustart stellt den Dienst nicht wieder her. Definieren Sie den Beobachtungszeitraum mit dem Verantwortlichen, statt eine allgemeingültige Dauer zu erfinden. Bei einer Anwendung, die nur zu einem geplanten Zeitpunkt läuft, muss diese Ausführung in die Abnahmeentscheidung einbezogen werden.

2. Autorisierten Host und Kontoberechtigungen vorbereiten

Prüfen Sie vor der Änderung die lokalen Dienstrechte und nachgelagerten Berechtigungen des Kandidaten. Beantragen Sie die für die erwarteten Anwendungsvorgänge benötigten Berechtigungen; erhalten Sie die Abhängigkeiten der alten Identität während des Wiederherstellungsfensters. Trennen Sie die Autorisierung zum Kennwortabruf von der Autorisierung für den Zugriff auf Anwendungsdaten. Ein bestandener Kontotest belegt weder den vollständigen Berechtigungssatz der Anwendung noch ihre korrekte Konfiguration.

Nachdem die Verzeichnis- und Autorisierungsprüfungen bestanden sind, installiert Microsofts Verfahren das Konto auf jedem Host, auf dem der Dienst läuft. Führen Sie den Befehl im Rahmen der genehmigten Änderung lokal in einer PowerShell-Sitzung mit erhöhten Rechten aus:

Install-ADServiceAccount -Identity 'svc-pilot'

Das Cmdlet bereitet das vorhandene verwaltete Konto auf dem lokalen Computer vor. Es ändert nicht die konfigurierte Identität der Anwendung. Laut Referenz muss die Abrufautorisierung für ein gMSA eingerichtet sein. Microsoft Learn — Install-ADServiceAccount.

Wiederholen Sie den Test der Kontobereitschaft auf diesem Host und bewahren Sie das Ergebnis auf. Schlagen Installation oder Test fehl, stoppen Sie an dieser Freigabeprüfung und untersuchen Sie die Ursache. Erfassen Sie den Abschluss eines administrativen Befehls nicht als erfolgreiche Dienstmigration.

3. Über die unterstützte Dienstkonfiguration umstellen

Verwenden Sie das vom Produkt unterstützte Verfahren zur Identitätskonfiguration, um den ausgewählten Dienst umzustellen. Ein allgemeiner Befehl kann nicht jede Art von Windows-Dienst, Anwendungspool, Aufgabe und Anwendung sicher abdecken. Halten Sie das produktspezifische Verfahren und seine Rückwärtsschritte in der genehmigten Änderungsdokumentation fest.

Prüfen Sie die konfigurierte Identität und starten Sie die Anwendung anschließend wie vereinbart oder starten Sie sie neu. Lassen Sie den Verantwortlichen repräsentative Clientvorgänge und nachgelagerte Lese- oder Schreibzugriffe ausführen. Vergleichen Sie die Ergebnisse mit der Basislinie und prüfen Sie die tatsächlichen Anwendungsfehler. Wenn Authentifizierung relevant ist, bestätigen Sie das erwartete Authentifizierungsverhalten von Clients und Ressourcen anhand der etablierten Diagnoseverfahren der Organisation. Kein einzelnes Startergebnis ersetzt diese Tests.

Werden die Abnahmekriterien nicht erfüllt, führen Sie diese Schritte aus und dokumentieren Sie sowohl den auslösenden Fehler als auch das wiederhergestellte Dienstverhalten. Bewahren Sie die Nachweise für die Untersuchung auf. Ein in AD verbleibendes Kontoobjekt während der Wiederherstellung der Anwendung bedeutet nicht, dass der Pilotversuch erfolgreich war.

4. Pilotversuch abschließen und die übrige Landschaft verfolgen

Erfassen Sie nach der Abnahme Dienst, Hosts, neue Identität, Tests, Zeitstempel, Genehmiger und ungeklärte Einschränkungen. Prüfen Sie vor der Stilllegung alle verbleibenden Nutzer der alten Identität. Entfernen Sie diese Identität erst nach der Validierung und dem genehmigten Wiederherstellungszeitraum; dass ihr Name aus einer Dienstkonfiguration verschwindet, beweist nicht, dass keine andere Anwendung von ihr abhängt.

Die bestehende Abhilfe für Dienstkonten mit Empfehlung zur gMSA-Migration begründet die Migration. Dieser Pilotversuch liefert die betrieblichen Nachweise für diese Empfehlung. Verfolgen Sie spätere Kandidaten getrennt: Ein abgenommener erster Dienst ist ein Fortschritt, während die Einführung in der gesamten Landschaft weiterhin ein Inventar und eine Entscheidung für jeden einzelnen Dienst erfordert.

Wie EtcSec dies erkennt

Die relevante EtcSec-Prüfung ist GMSA_NOT_IN_USE. In der geprüften etc-collector-Implementierung zählt sie erkannte gMSA-Benutzer und aktivierte Benutzer mit mindestens einem SPN. Sie liefert einen Befund mit niedriger Schwere und Count = 1 nur dann, wenn die Zahl erkannter gMSAs null ist und die Zahl aktivierter Benutzer mit SPN positiv ist. Andernfalls liefert sie Count = 0.

Die Erkennung ist enger gefasst als ein Inventar anhand der Strukturklasse: User.IsGMSA wird gesetzt, wenn das binäre Attribut msDS-GroupMSAMembership nicht leer ist. Der LDAP-Benutzerfilter enthält msDS-GroupManagedServiceAccount, aber der Parser verwendet diese Klasse nicht zum Setzen dieses Benutzerflags. Ein fehlendes oder nicht lesbares Mitgliedschaftsattribut kann daher die Erkennung beeinflussen; eine unvollständige LDAP-Grenze oder ein MaxUsers-Limit kann das Inventar beeinflussen. Ein GetUsers-Fehler stoppt die Engine, statt ein erfolgreiches leeres Inventar zu erzeugen.

Jedes erkannte gMSA zählt, einschließlich deaktivierter Objekte. Ein erkanntes Objekt reicht aus, um dieses Signal auf null zu setzen, selbst wenn kein Dienst migriert wurde. Null tritt auch dann auf, wenn keine aktivierten Benutzer mit SPN erfasst wurden. Diese Prüfung untersucht weder KDS-Schlüssel noch Replikationsbereitschaft, Hostinstallation, Dienstkonfiguration, Anwendungskompatibilität oder tatsächliche Dienstanmeldungen. Sie misst weder den Anteil der Dienste, die gMSAs verwenden, noch den Erfolg des Pilotversuchs.