Freigeben über

Wie man sich nach einem Golden gMSA-Angriff wiederherstellen kann

  • Artikel

In diesem Artikel wird ein Ansatz zum Reparieren der Anmeldeinformationen eines gruppenverwalteten Dienstkontos (Group Managed Service Account, gMSA) beschrieben, das von einem Datenbankvorfall des Domänencontrollers betroffen ist.

Symptome

Eine Beschreibung eines Golden gMSA-Angriffs finden Sie im folgenden Semperis-Artikel:

Einführung in den Golden GMSA-Angriff

Die Beschreibung im obigen Artikel ist richtig. Der Ansatz zum Beheben des Problems besteht darin, das Stammschlüsselobjekt des Microsoft Key Distribution Service (kdssvc.dll, auch bekannt als KDS) und alle gMSAs zu ersetzen, die das kompromittierte KDS-Stammschlüsselobjekt verwenden.

Weitere Informationen

Bei einem erfolgreichen Angriff auf ein gMSA erhält der Angreifer alle wichtigen Attribute des KDS-Stammschlüsselobjekts sowie die Sid Attribute und msds-ManagedPasswordID eines gMSA-Objekts.

Das msds-ManagedPasswordID Attribut ist nur in einer beschreibbaren Kopie der Domäne vorhanden. Wenn die Datenbank eines Domänencontrollers verfügbar gemacht wird, ist daher nur die Domäne, die der Domänencontroller hostet, für den Golden gMSA-Angriff geöffnet. Wenn sich der Angreifer jedoch bei einem Domänencontroller einer anderen Domäne in der Gesamtstruktur authentifizieren kann, verfügt der Angreifer möglicherweise über ausreichende Berechtigungen, um den Inhalt von msds-ManagedPasswordIDabzurufen. Der Angreifer könnte diese Informationen dann verwenden, um einen Angriff auf gMSAs in zusätzlichen Domänen zu erstellen.

Um zusätzliche Domänen Ihrer Gesamtstruktur zu schützen, nachdem eine Domäne verfügbar gemacht wurde, müssen Sie alle gMSAs in der verfügbar gemachten Domäne ersetzen, bevor der Angreifer die Informationen verwenden kann. In der Regel kennen Sie nicht die Details, was offengelegt wurde. Daher wird empfohlen, die Auflösung auf alle Domänen der Gesamtstruktur anzuwenden.

Als proaktive Maßnahme kann die Überwachung verwendet werden, um die Offenlegung des KDS-Stammschlüsselobjekts nachzuverfolgen. Eine Systemzugriffssteuerungsliste (SACL) mit erfolgreichen Lesevorgängen kann im Container Masterstammschlüssel platziert werden, der die Überwachung von erfolgreichen Lesevorgängen für das msKds-RootKeyData Attribut der msKds-ProvRootKey Klasse ermöglicht. Diese Aktion bestimmt die Belichtungslandschaft des Objekts in Bezug auf einen Golden gMSA-Angriff.

Hinweis

Die Überwachung hilft nur, einen Onlineangriff auf die KDS-Stammschlüsseldaten zu erkennen.

Sie können den ManagedPasswordIntervalInDays Parameter auf 15 Tage festlegen oder einen geeigneten Wert auswählen, wenn Sie ein gMSA erstellen, da der ManagedPasswordIntervalInDays Wert nach dem Erstellen eines gMSA schreibgeschützt wird.

Im Falle einer Kompromittierung kann diese Einstellung die nächste Rollzeit verkürzen.

Es reduziert die theoretische Anzahl von gMSA, die zwischen dem Datum der wiederhergestellten Sicherung und dem Ende der Datenbankexposition neu erstellt werden sollen, oder zumindest die Dauer des Risikofensters, bis diese gMSAs rollieren, wenn Sie bei Szenario 1 bleiben.

Hier sehen Sie ein Beispielszenario:

  1. Nach einer Datenbankexposition führen Sie die Wiederherstellung am "Tag D" durch.

  2. Die wiederhergestellte Sicherung stammt von D-15.

    Hinweis

    D-15 bedeutet den Tag, der 15 Tage vor "Tag D" liegt.

  3. Der gMSA-Wert ManagedPasswordIntervalInDays ist 15.

  4. gMSAs sind vorhanden und haben D-1 gerollt.

  5. Neuere gMSAs wurden aus D-10 erstellt.

  6. Die Kompromittierung erfolgt auf D-5, und einige gMSAs wurden an diesem Datum erstellt.

Dies sind die Ergebnisse:

  1. GMSAs, die zwischen D und D-5 erstellt wurden, sind nicht betroffen*.

  2. gMSAs, die zwischen D-15 (Sicherung wiederhergestellt) und D-5 (Kompromittierung)* erstellt wurden, müssen neu erstellt werden, oder die Risikofenster müssen angenommen werden, wenn Sie von D+5 bis D+10 warten können. Beispiel:

    • Auf D+5 müssen auf D-10 erstellte gMSAs neu erstellt werden.
    • Auf D+10 müssen auf D-5 erstellte gMSAs neu erstellt werden.

    *Hängt vom genauen Zeitpunkt der Kompromittierung oder Sicherung ab.

Hier sehen Sie ein Beispiel für die Zeitachse:

Diagramm eines Beispiels für eine gMSAs-Zeitachse.

Zum Debuggen können Sie die Ereignis-IDs für das Ereignisprotokoll System, Sicherheit, Verzeichnisdienste und Security-Netlogon überprüfen.

Weitere Informationen zu einer Kompromittierung finden Sie unter Verwenden von Microsoft- und Azure-Sicherheitsressourcen zur Wiederherstellung nach systemischen Identitätskompromittierungen.

Lösung

Verwenden Sie je nach Situation einen der folgenden Ansätze, um dieses Problem zu beheben. Die Ansätze umfassen das Erstellen eines neuen KDS-Stammschlüsselobjekts und das Neustarten des Microsoft-Schlüsselverteilungsdiensts auf allen Domänencontrollern der Domäne.

Szenario 1: Sie verfügen über zuverlässige Informationen darüber, welche Informationen wann verfügbar gemacht wurden

Wenn Sie wissen, dass die Offenlegung vor einem bestimmten Datum aufgetreten ist und dieses Datum vor dem ältesten gMSA-Kennwort liegt, das Sie haben, können Sie das Problem beheben, ohne die gMSAs neu zu erstellen, wie im folgenden Verfahren gezeigt.

Der Ansatz besteht darin, ein neues KDS-Stammschlüsselobjekt zu erstellen, das dem Angreifer unbekannt ist. Wenn die gMSAs ihr Kennwort angeben, wechseln sie mithilfe des neuen KDS-Stammschlüsselobjekts zu . Um gMSAs zu beheben, die kürzlich ein Rollback für ihr Kennwort mithilfe des alten KDS-Stammschlüssels durchgeführt haben, ist eine autoritative Wiederherstellung erforderlich, um eine Kennwortaktualisierung unmittelbar nach der Wiederherstellung zu erzwingen.

Hinweis

  • Sie müssen keine gMSAs manuell reparieren, die erstellt wurden, nachdem die Ad DS-Datenbank (Active Directory Domain Services) beendet wurde. Der Angreifer kennt die Details dieser Konten nicht, und die Kennwörter für diese Konten werden basierend auf dem neuen KDS-Stammschlüsselobjekt neu generiert.
  • Sie sollten das gMSA-Objekt im "Wartungsmodus" betrachten, bis die Prozedur abgeschlossen ist, und mögliche Fehler ignorieren, die mit den Konten im System-, Sicherheits-, Verzeichnisdienste- und Security-Netlogon Ereignisprotokoll gemeldet werden.
  • In der Anleitung wird davon ausgegangen, dass die gMSAs untergeordnete Objekte des Containers für verwaltete Dienstkonten sind. Wenn Sie die Konten in benutzerdefinierte übergeordnete Container verschoben haben, müssen Sie die Schritte im Zusammenhang mit dem Container "Verwaltete Dienstkonten " im gMSA in diesen Containern ausführen.
  • Bei einer autoritativen Wiederherstellung wird ein Rollback aller Attribute auf den Zustand durchgeführt, in dem sie sich zum Zeitpunkt der Sicherung befanden, einschließlich der Konten, die die gMSA-Anmeldeinformationen abrufen dürfen (PrincipalsAllowedToRetrieveManagedPassword).

Führen Sie in der Domäne mit den gMSAs, die Sie reparieren möchten, die folgenden Schritte aus:

  1. Schalten Sie einen Domänencontroller offline, und isolieren Sie ihn vom Netzwerk.

  2. Stellen Sie den Domänencontroller aus einer Sicherung wieder her, die vor der Offenlegung der AD DS-Datenbank erstellt wurde.

    Wenn das Kennwortintervall für die gMSAs länger als das Alter der Sicherung ist, können Sie das Fenster tolerieren, in dem das vorherige Schlüsselmaterial noch funktioniert. Wenn Sie nicht so lange warten können und die entsprechende ältere Sicherung zu viele gMSAs fehlt, müssen Sie den Plan auf Szenario 2 umstellen.

  3. Führen Sie einen autoritativen Wiederherstellungsvorgang für den Container "Verwaltete Dienstkonten " der Domäne aus. Stellen Sie sicher, dass der Wiederherstellungsvorgang alle untergeordneten Objekte der Container enthält, die diesem Domänencontroller zugeordnet sein können. In diesem Schritt wird ein Rollback für den Status der letzten Kennwortaktualisierung ausgeführt. Wenn ein Dienst das kennwort das nächste Mal abruft, wird das Kennwort basierend auf dem neuen KDS-Stammschlüsselobjekt auf ein neues Aktualisiert.

  4. Beenden und deaktivieren Sie den Microsoft-Schlüsselverteilungsdienst auf dem wiederhergestellten Domänencontroller.

  5. Führen Sie auf einem anderen Domänencontroller die Schritte unter Erstellen des KDS-Stammschlüssels für Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    Hinweis

    In der Produktionsumgebung müssen Sie 10 Stunden warten, um sicherzustellen, dass der neue KDS-Stammschlüssel verfügbar ist. Überprüfen Sie das EffectiveTime Attribut, um zu erfahren, wann der neue KDS-Stammschlüssel verwendet werden kann.

  6. Starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern neu.

  7. Erstellen Sie ein neues gMSA. Stellen Sie sicher, dass der neue gMSA das neue KDS-Stammschlüsselobjekt verwendet, um den Wert für das msds-ManagedPasswordID Attribut zu erstellen.

    Hinweis

    Dieser Schritt ist optional, ermöglicht ihnen jedoch die Überprüfung, ob der neue KDS-Stammschlüssel derzeit verwendet und im Microsoft-Schlüsselverteilungsdienst verwendet wird.

  8. Überprüfen Sie den msds-ManagedPasswordID Wert des ersten erstellten gMSA. Der Wert dieses Attributs sind Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

    Angenommen, das KDS-Stammschlüsselobjekt weist den folgenden CNauf.

    Screenshot: Wert des CN-Attributs eines KDS-Stammschlüsselobjekts

    Ein gMSA, das mit diesem Objekt erstellt wird, weist einen msds-ManagedPasswordID Wert auf, der dem folgenden ähnelt.

    Screenshot des Werts des Attributs msDS-ManagedPasswordId eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

    In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

    Wenn das erste gMSA, das Sie erstellt haben, den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs ebenfalls den neuen Schlüssel.

  9. Deaktivieren und beenden Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern.

  10. Stellen Sie die Verbindung wieder her, und schalten Sie den wiederhergestellten Domänencontroller wieder online. Stellen Sie sicher, dass die Replikation funktioniert.

    Nun werden die autoritative Wiederherstellung und alle anderen Änderungen (einschließlich der wiederhergestellten gMSAs) repliziert.

  11. Aktivieren Und starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern erneut. Die Geheimnisse der wiederhergestellten gMSAs werden rolliert, und neue Kennwörter werden auf Der Grundlage des neuen KDS-Stammschlüsselobjekts auf Anforderung erstellt.

    Hinweis

    Wenn die gMSAs wiederhergestellt, aber nicht verwendet werden und der PrincipalsAllowedToRetrieveManagedPassword Parameter aufgefüllt ist, können Sie das Test-ADServiceAccount Cmdlet auf dem wiederhergestellten gMSA mit einem Prinzipal ausführen, der das Kennwort abrufen darf. Wenn eine Kennwortänderung erforderlich ist, führt dieses Cmdlet die gMSAs dann in den neuen KDS-Stammschlüssel ein.

  12. Vergewissern Sie sich, dass für alle gMSAs ein Rollback ausgeführt wurde.

    Hinweis

    Das gMSA ohne den aufgefüllten PrincipalsAllowedToRetrieveManagedPassword Parameter wird niemals rollt.

  13. Löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  14. Starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern neu.

Szenario 2: Sie kennen die Details des KDS-Stammschlüsselobjekts nicht, und Sie können nicht warten, bis Kennwörter rollieren.

Wenn Sie nicht wissen, welche Informationen verfügbar gemacht wurden oder wann sie verfügbar gemacht wurden, kann eine solche Offenlegung Teil einer vollständigen Offenlegung Ihrer Active Directory-Gesamtstruktur sein. Dies kann zu einer Situation führen, in der der Angreifer Offlineangriffe auf alle Kennwörter ausführen kann. In diesem Fall sollten Sie eine Gesamtstrukturwiederherstellung ausführen oder alle Kontokennwörter zurücksetzen. Die Wiederherstellung der gMSAs in einen sauberen Zustand ist Teil dieser Aktivität.

Während des folgenden Prozesses müssen Sie ein neues KDS-Stammschlüsselobjekt erstellen. Anschließend verwenden Sie dieses Objekt, um alle gMSAs in den Domänen der Gesamtstruktur zu ersetzen, die das verfügbar gemachte KDS-Stammschlüsselobjekt verwenden.

Hinweis

Die folgenden Schritte ähneln dem Verfahren unter Erste Schritte mit gruppenverwalteten Dienstkonten. Es gibt jedoch einige wichtige Änderungen.

Gehen Sie folgendermaßen vor:

  1. Deaktivieren Sie alle vorhandenen gMSAs, und markieren Sie sie als zu entfernende Konten. Legen Sie dazu für jedes Konto das userAccountControl Attribut auf 4098 fest (dieser Wert kombiniert WORKSTATION_TRUST_ACCOUNT- und ACCOUNTDISABLE-Flags (deaktiviert).

    Sie können ein PowerShell-Skript wie dieses verwenden, um die Konten festzulegen:

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. Verwenden Sie einen einzelnen Domänencontroller, und führen Sie die folgenden Schritte aus:

    1. Führen Sie die Schritte unter Erstellen des KDS-Stammschlüssels für Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    2. Starten Sie den Microsoft-Schlüsselverteilungsdienst neu. Nach dem Neustart übernimmt der Dienst das neue Objekt.

    3. Sichern Sie DNS-Hostnamen und Dienstprinzipalnamen (Service Principal Names, SPNs), die jedem gMSA zugeordnet sind, der als entfernt markiert ist.

    4. Bearbeiten Sie die vorhandenen gMSAs, um die SPNs und DNS-Hostnamen zu entfernen.

    5. Erstellen Sie neue gMSAs, um die vorhandenen gMSAs zu ersetzen. Sie müssen auch mit den DNS-Hostnamen und SPNs konfiguriert werden, die Sie gerade entfernt haben.

      Hinweis

      Außerdem müssen Sie alle Berechtigungseinträge mithilfe der direkt entfernten gMSA-SIDs überprüfen, da sie nicht mehr auflösbar sind. Erwägen Sie beim Ersetzen eines Zugriffssteuerungseintrags (Access Control Entry, ACE) die Verwendung von Gruppen zum Verwalten von gMSA-Berechtigungseinträgen.

  3. Überprüfen Sie die neuen gMSAs, um sicherzustellen, dass sie das neue KDS-Stammschlüsselobjekt verwenden. Gehen Sie dazu wie folgt vor:

    1. Notieren Sie sich den CN Wert (GUID) des KDS-Stammschlüsselobjekts.

    2. Überprüfen Sie den msds-ManagedPasswordID Wert des ersten erstellten gMSA. Der Wert dieses Attributs sind Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

      Angenommen, das KDS-Stammschlüsselobjekt weist den folgenden CNauf.

      Screenshot des Werts des CN-Attributs eines KDS-Stammschlüsselobjekts.

      Ein gMSA, der mit diesem Objekt erstellt wird, weist einen msds-ManagedPasswordID Wert auf, der dem Bild ähnelt.

      Screenshot des Werts des Attributs msDS-ManagedPasswordId eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

      In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

      Wenn das erste gMSA, das Sie erstellt haben, den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs ebenfalls den neuen Schlüssel.

  4. Aktualisieren Sie die entsprechenden Dienste, um die neuen gMSAs zu verwenden.

  5. Löschen Sie die alten gMSAs, die das alte KDS-Stammschlüsselobjekt verwendet haben, mithilfe des folgenden Cmdlets:

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. Löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  7. Starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern neu.

Szenario 3: Rücktritt eines Domänenadministrators, zu diesem Zeitpunkt wurden keine Informationen gestohlen, und Sie können warten, bis Kennwörter verwendet werden.

Wenn ein Mitglied mit hohen Berechtigungen mit Domänenadministratoren oder gleichwertigen Rechten zurücktritt, gibt es zu diesem Zeitpunkt keinen Nachweis für die Offenlegung des KDS-Stammschlüssels, und Sie können sich ein Zeitfenster für das Rollieren von Kennwörtern leisten. Sie müssen die gMSAs nicht neu erstellen.

Als vorbeugende Maßnahme muss ein Rollback für den KDS-Stammschlüssel ausgeführt werden, um Angriffe nach der Ausnutzung zu verhindern. Beispielsweise hat sich ein ehemaliger Domänenadministrator als rogue herausgestellt und einige Sicherungen aufbewahrt.

Ein neues KDS-Stammschlüsselobjekt wird erstellt, und gMSAs werden auf natürliche Weise ausgeführt.

Hinweis

Informationen zu einer Kompromittierung im Zusammenhang mit einem Domänenadministrator finden Sie unter Szenario 1 oder Szenario 2 , je nachdem, was verfügbar gemacht wurde, und befolgen Sie die lokalen Wartungsaktivitäten unter "Verwenden von Microsoft- und Azure-Sicherheitsressourcen zur Wiederherstellung nach systemischer Identitätskompromittierung".

Führen Sie in der Domäne mit den gMSAs, die Sie rollieren möchten, die folgenden Schritte aus:

  1. Führen Sie auf einem Domänencontroller die Schritte unter Erstellen des KDS-Stammschlüssels der Schlüsselverteilungsdienste aus, um ein neues KDS-Stammschlüsselobjekt zu erstellen.

    Hinweis

    In der Produktionsumgebung müssen Sie 10 Stunden warten, um sicherzustellen, dass der neue KDS-Stammschlüssel verfügbar ist. Überprüfen Sie das EffectiveTime Attribut, um zu erfahren, wann der neue KDS-Stammschlüssel verwendet werden kann.

  2. Starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern neu.

  3. Erstellen Sie ein neues gMSA. Stellen Sie sicher, dass der neue gMSA das neue KDS-Stammschlüsselobjekt verwendet, um den Wert für das msds-ManagedPasswordID Attribut zu erstellen.

    Hinweis

    Dieser Schritt ist optional, ermöglicht ihnen jedoch die Überprüfung, ob der neue KDS-Stammschlüssel derzeit verwendet und im Microsoft-Schlüsselverteilungsdienst verwendet wird.

  4. Überprüfen Sie den msds-ManagedPasswordID Wert des ersten erstellten gMSA. Der Wert dieses Attributs sind Binärdaten, die die GUID des entsprechenden KDS-Stammschlüsselobjekts enthalten.

    Angenommen, das KDS-Stammschlüsselobjekt weist den folgenden CNauf.

    Screenshot des Werts des CN-Attributs eines KDS-Stammschlüsselobjekts.

    Ein gMSA, der mit diesem Objekt erstellt wird, weist einen msds-ManagedPasswordID Wert auf, der der folgenden Abbildung ähnelt.

    Screenshot des Werts des Attributs msDS-ManagedPasswordId eines gMSA-Objekts, der zeigt, wie es die Teile des CN-Attributs des KDS-Stammschlüssels enthält.

    In diesem Wert beginnen die GUID-Daten bei Offset 24. Die Teile der GUID befinden sich in einer anderen Reihenfolge. In dieser Abbildung identifizieren die roten, grünen und blauen Abschnitte die neu angeordneten Teile. Der orangefarbene Abschnitt identifiziert den Teil der Sequenz, der mit der ursprünglichen GUID identisch ist.

    Wenn das erste gMSA, das Sie erstellt haben, den neuen KDS-Stammschlüssel verwendet, verwenden alle nachfolgenden gMSAs ebenfalls den neuen Schlüssel.

  5. Abhängig von der nächsten Kennwortrolle werden die Geheimnisse der gMSAs natürlich rolliert, und neue Kennwörter werden auf Der Grundlage des neuen KDS-Stammschlüsselobjekts auf Anfrage erstellt.

    Hinweis

    Wenn für verwendete gMSAs ein Rollback ausgeführt wurde, aber nicht verwendete gMSAs mit demselben Rollintervall nicht verwendet wurden und der PrincipalsAllowedToRetrieveManagedPassword Parameter aufgefüllt ist, können Sie das Test-ADServiceAccount Cmdlet ausführen. Es wird ein Prinzipal verwendet, der das gMSA-Kennwort abrufen darf, und dieser Schritt verschiebt dann den gMSA in den neuen KDS-Stammschlüssel.

  6. Vergewissern Sie sich, dass für alle gMSAs ein Rollback ausgeführt wurde.

    Hinweis

    Das gMSA ohne den PrincipalsAllowedToRetrieveManagedPassword Parameter wird niemals rollt.

  7. Nachdem alle gMSAs zum neuen KDS-Stammschlüsselobjekt gerollt wurden, löschen Sie das alte KDS-Stammschlüsselobjekt, und überprüfen Sie die Replikationen.

  8. Starten Sie den Microsoft-Schlüsselverteilungsdienst auf allen Domänencontrollern neu.

References

Übersicht über gruppenverwaltete Dienstkonten

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.