Übersicht über delegierte verwaltete Dienstkonten

Unter Windows Server 2025 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 ein dMSA ist mit der Geräteidentität verknüpft, was bedeutet, dass nur bestimmte Computeridentitäten, die in Active Directory (AD) zugeordnet sind, 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:

• Utilizing gMSA concepts to limit scope of usage using Credential Guard (CG) to bind machine authentication.
• 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 mit vom Computer generierten und automatisch gedrehten Kennwörtern gesichert sind, sind die Kennwörter immer noch nicht computergebunden 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 bei diesem vorhandenen Konto mit dessen Kennwort blockiert. Die Anforderung wird an die lokale Sicherheitsbehörde (Local Security Authority , LSA) umgeleitet, um sich mit dMSA zu authentifizieren, die Zugriff auf alles hat, auf das das vorherige Konto in AD zugreifen kann.

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:

1. Die CG-Richtlinie kann so konfiguriert werden, dass die Computeridentität geschützt wird.
2. Ein Administrator startet und schließt die Migration des Dienstkontos ab.
3. Das Dienstkonto aktualisiert den Ticket Granting Server (TGT).
4. Das Dienstkonto fügt die Computeridentität hinzu, um Prinzipien zuzulassen.
5. 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. Keeping a service in the start state for four ticket lifetimes (28 days) is recommended. Verzögern Sie die Migration, wenn Ihre DCs partitioniert sind oder die Replikation während des Onboardings unterbrochen wird.
• Pay attention to sites where replication delays are longer than the default ticket renewal time of 10 hours. The groupMSAMembership attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the "start migration" state, which adds the machine account to the groupMSAMembership of the dMSA.
  • 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.

Warning

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, schlägt die dMSA-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 mithilfe des Active Directory-Benutzer und Computer-Snap-Ins angezeigt werden oder indem ADSI Edit auf dem DC ausgeführt wird.

Note

Die für das Konto festgelegten numerischen Attribute geben Folgendes an:

• 1 - Account migration has begun.
• 2 - Account migration has completed.

Beim Ausführen Start-ADServiceAccountMigration werden die folgenden Änderungen ausgeführt:

• The service account is granted Generic Read to all properties on the dMSA
• The service account is granted Write property to msDS-groupMSAMembership
• msDS-DelegatedMSAState is changed to 1
• msDS-ManagedAccountPrecededByLink is set to the service account
• msDS-SupersededAccountState is changed to 1
• msDS-SupersededManagedServiceAccountLink is set to the dMSA

Beim Ausführen Complete-ADServiceAccountMigration werden die folgenden Änderungen ausgeführt:

• The service account is removed from Generic Read to all properties on the dMSA
• The service account is removed from Write property on the msDS-GroupMSAMembership attribute
• msDS-DelegatedMSAState is set to 2
• Die Dienstprinzipalnamen (Service Principal Names, SPNs) werden aus dem Dienstkonto in das dMSA-Konto kopiert.
• msDS-AllowedToDelegateTo is copied over if applicable
• msDS-AllowedToActOnBehalfOfOtherIdentity the security descriptor is copied over if applicable
• The assigned AuthN policy, msDS-AssignedAuthnPolicy, of the service account are copied over
• 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 is set to 2
• Das Dienstkonto wird über das UAC-Deaktivierungsbit deaktiviert
• Der SPNs wird aus dem Konto entfernt

dMSA realms

Bereiche dienen als logische Gruppierungen, die Authentifizierungsgrenzen definieren. Sie werden im Allgemeinen verwendet, wenn verschiedene AD-Versionen domänen- oder gesamtstrukturübergreifend integriert werden. Sie sind besonders in gemischten Domänenumgebungen wichtig, in denen einige Domänen möglicherweise nicht alle Features von dMSAs vollständig unterstützen. Durch die Angabe von Bereichen kann das dMSA einen ordnungsgemäßen Kommunikationsfluss und Authentifizierungsablauf zwischen Domänen sicherstellen.

Mithilfe von Bereichen können Administratoren angeben, welche Domänen oder Verzeichniskomponenten sich authentifizieren und auf das dMSA zugreifen können. Dadurch wird sichergestellt, dass auch ältere untergeordnete Domänen, die dMSA-Features möglicherweise nicht nativ unterstützen, mit den Konten interagieren können und dass dabei die Sicherheitsgrenzen beibehalten werden. Bereiche erleichtern nahtlose Übergänge und die Koexistenz von Funktionen in gemischten Umgebungen und gewährleisten die Kompatibilität zwischen Domänen sowie eine starke Sicherheit, wenn aktiviert.

Wenn Sie beispielsweise über eine primäre Domäne namens corp.contoso.com unter Windows Server 2025 und eine ältere untergeordnete Domäne namens legacy.corp.contoso.com unter Windows Server 2022 verfügen, können Sie den Bereich als legacy.corp.contoso.com angeben.

Um diese Gruppenrichtlinieneinstellung für Ihre Umgebung zu bearbeiten, navigieren Sie zum folgenden Pfad:

Computerkonfiguration\Administrationsvorlagen\System\Kerberos\Anmeldungen bei delegiertem verwaltetem Dienstkonto aktivieren

See also

Einrichten delegierter verwalteter Dienstkonten