Übersicht über delegierte verwaltete Dienstkonten
Wichtig
Windows Server-Insider-Builds befinden sich in der Vorschauphase. Diese Informationen beziehen sich auf eine Vorabversion des Produkts, an der vor der Veröffentlichung noch wesentliche Änderungen vorgenommen werden können. Microsoft übernimmt keine Garantie, weder ausdrücklich noch stillschweigend, für die hier bereitgestellten Informationen.
In der Windows Server Insiders-Vorschau wird ein neuer Kontotyp namens delegiertes verwaltetes Dienstkonto (Delegated Managed Service Account ,dMSA) eingeführt, der die Migration von einem herkömmlichen Dienstkonto zu einem Computerkonto mit verwalteten und vollständig zufälligen Schlüsseln ermöglicht und gleichzeitig die ursprünglichen Dienstkontokennwörter deaktiviert. Die Authentifizierung für dMSA ist mit der Geräteidentität verknüpft, was bedeutet, dass nur bestimmte in AD zugeordnete Computeridentitäten auf das Konto zugreifen können. Die Verwendung von dMSA trägt dazu bei, das Sammeln von Anmeldeinformationen mithilfe eines kompromittierten Kontos (Kerberoasting) zu verhindern, was bei herkömmlichen Dienstkonten ein häufiges Problem darstellt.
Vergleich von dMSA und gMSA
dMSAs und gMSAs sind zwei Typen von verwalteten Dienstkonten, die zum Ausführen von Diensten und Anwendungen in Windows Server verwendet werden. Eine dMSA wird von einem Administrator verwaltet und verwendet, um einen Dienst oder eine Anwendung auf einem bestimmten Server auszuführen. Eine gMSA wird von AD verwaltet und wird verwendet, um einen Dienst oder eine Anwendung auf mehreren Servern auszuführen. Beide bieten verbesserte Sicherheit und eine vereinfachte Kennwortverwaltung. dMSA unterscheidet sich durch:
- Die Verwendung von gMSA-Konzepten zur Begrenzung des Nutzungsumfangs mithilfe von Credential Guard (CG) zur Bindung der Computerauthentifizierung.
- CG kann verwendet werden, um die Sicherheit in dMSA zu erhöhen, indem Kennwörter automatisch rotiert und alle Dienstkontotickets gebunden werden. Legacykonten werden dann deaktiviert, um die Sicherheit weiter zu verbessern.
- Obwohl gMSAs durch computergenerierte und automatisch rotierte Kennwörter gesichert sind, sind die Kennwörter immer noch nicht maschinengebunden und können gestohlen werden.
Funktionalität von dMSA
dMSA ermöglicht es Benutzern, sie als eigenständiges Konto zu erstellen oder ein vorhandenes Standard-Dienstkonto zu ersetzen. Wenn ein dMSA ein vorhandenes Konto ersetzt, wird die Authentifizierung für dieses vorhandene Konto mit dessen Kennwort blockiert. Die Anforderung wird an die lokale Sicherheitsbehörde (Local Security Authority , LSA) umgeleitet, um sich mithilfe von dMSA zu authentifizieren, das Zugriff auf alles hat, auf das das vorherige Konto in AD zugreifen konnte.
Bei der Migration lernt dMSA automatisch, auf welchen Geräten das Dienstkonto verwendet werden soll, das dann zum Wechseln von allen vorhandenen Dienstkonten verwendet wird.
dMSA verwendet einen zufälligen geheimen Schlüssel (abgeleitet von den Anmeldeinformationen des Computerkontos), der vom Domänencontroller (DC) zum Verschlüsseln von Tickets gehalten wird. Das Geheimnis kann durch die Aktivierung von CG weiter geschützt werden. Während die von dMSA verwendeten Geheimnisse regelmäßig in einer Epoche wie bei einem gMSA aktualisiert werden, besteht der Hauptunterschied darin, dass das Geheimnis von dMSA nirgendwo anders als auf dem DC abgerufen oder gefunden werden kann.
Migrationsflow für dMSA
Ein schnelles Konzept des Migrationsprozesses für einen dMSA umfasst die folgenden Schritte:
- Die CG-Richtlinie kann so konfiguriert werden, dass die Computeridentität geschützt wird.
- Ein Administrator startet und schließt die Migration des Dienstkontos ab.
- Das Dienstkonto aktualisiert den Ticket Granting Server (TGT).
- Das Dienstkonto fügt die Computeridentität hinzu, um Prinzipien zuzulassen.
- Das ursprüngliche Dienstkonto wird deaktiviert.
Beachten Sie beim Migrieren von dMSAs Folgendes:
- Sie können nicht von einem verwalteten Dienstkonto oder einem gMSA zu einem dMSA migrieren.
- Warten Sie mindestens zwei Ticketlebensdauern (entspricht 14 Tagen), nachdem Sie die Sicherheitsbeschreibung (SD) geändert haben, bevor Sie die dMSA-Migration abschließen. Es wird empfohlen, einen Dienst für vier Ticketlebensdauern (28 Tage) im Startzustand zu halten. Verzögern Sie die Migration, wenn Ihre DCs partitioniert sind oder die Replikation während des Onboardings unterbrochen wird.
- Achten Sie auf Websites, bei denen die Replikationsverzögerungen länger sind als die standardmäßige Ticketerneuerungszeit von 10 Stunden. Das Attribut groupMSAMembership wird bei jeder Ticketverlängerung und jedes Mal, wenn sich das ursprüngliche Dienstkonto während des Status „Migration starten“ anmeldet, überprüft und aktualisiert, wodurch das Computerkonto zur groupMSAMembership der dMSA hinzugefügt wird.
- Beispielsweise verwenden zwei Websites dasselbe Dienstkonto, und jeder Replikationszyklus dauert mehr als 10 Stunden pro Ticketlebensdauer. In diesem Szenario geht eine Gruppenmitgliedschaft während der ersten Replikationszyklen verloren.
- Für die Migration ist Zugriff auf einen schreibgeschützten Domänencontroller (RWDC) erforderlich, um die SD abzufragen und zu ändern.
- Die nicht eingeschränkte Delegierung funktioniert nicht mehr, sobald die Migration abgeschlossen ist, wenn das alte Dienstkonto es verwendet hat. Wenn Sie eine durch CG geschützte dMSA verwenden, funktioniert die nicht eingeschränkte Delegierung nicht mehr. Weitere Informationen finden Sie unter Überlegungen und bekannte Probleme bei der Verwendung von Credential Guard.
Warnung
Wenn Sie zu einem dMSA migrieren möchten, müssen alle Computer, die das Dienstkonto verwenden, aktualisiert werden, um dMSA zu unterstützen. Wenn dies nicht der Fall ist, schlagen Computer, die dMSA nicht unterstützen, bei der Authentifizierung mit dem vorhandenen Dienstkonto fehl, sobald das Konto während der Migration deaktiviert wird.
Kontoattribute für dMSA
In diesem Abschnitt wird beschrieben, wie sich die Attribute für dMSA im AD-Schema ändern. Diese Attribute können mit dem Snap-In Active Directory-Benutzer und -Computer oder durch Ausführen von ADSI Edit auf dem DC angezeigt werden.
Hinweis
Die für das Konto festgelegten numerischen Attribute zeigen an, dass:
- 1 – Die Kontomigration begonnen hat.
- 2 – Die Kontomigration abgeschlossen wurde.
Beim Ausführen Start-ADServiceAccountMigration werden die folgenden Änderungen ausgeführt:
- Dem Dienstkonto wird Generisches Lesen für alle Eigenschaften im dMSA gewährt
- Dem Dienstkonto wird die Eigenschaft Scheiben für msDS-groupMSAMembership gewährt
- msDS-DelegatedMSAState wird zu 1 geändert.
- msDS-ManagedAccountPrecededByLink ist auf das Dienstkonto festgelegt.
- msDS-SupersededAccountState wird zu 1 geändert.
- msDS-SupersededManagedServiceAccountLink wird auf dMSA festgelegt.
Beim Ausführen Complete-ADServiceAccountMigration werden die folgenden Änderungen ausgeführt:
- Dem Dienstkonto wird von Generisches Lesen für alle Eigenschaften im dMSA entfernt
- Das Dienstkonto wird aus der Schreiben-Eigenschaft des Attributs msDS-GroupMSAMembership entfernt.
- msDS-DelegatedMSAState ist auf 2 festgelegt.
- Die Dienstprinzipalnamen (Service Principal Names, SPN) werden aus dem Dienstkonto in das dMSA-Konto kopiert.
- msDS-AllowedToDelegateTo wird ggf. kopiert.
- msDS-AllowedToActOnBehalfOfOtherIdentity Die Sicherheitsbeschreibung wird ggf. kopiert
- Die zugewiesene AuthN-Richtlinie msDS-AssignedAuthnPolicy des Dienstkontos wird kopiert.
- dMSA wird allen AuthN-Richtliniensilos hinzugefügt, bei denen das Dienstkonto Mitglied war von
- Das vertrauenswürdige Bit "Auth for Delegation" User Account Control (UAC) wird kopiert, wenn es für das Dienstkonto festgelegt wurde.
- msDS-SupersededServiceAccountState ist auf 2 festgelegt
- Das Dienstkonto wird über das UAC-Deaktivierungsbit deaktiviert
- Der SPN wird aus dem Konto entfernt