Freigeben über


Erstellen von gMSAs für Windows-Container

Gilt für: Windows Server 2022, Windows Server 2019

Windows-basierte Netzwerke verwenden häufig Active Directory (AD), um die Authentifizierung und Autorisierung zwischen Benutzern, Computern und anderen Netzwerkressourcen zu erleichtern. Entwickler von Unternehmensanwendungen entwerfen ihre Apps häufig so, dass sie in AD integriert sind und auf Servern ausgeführt werden, die mit Domänen verbunden sind, um die Vorteile der integrierten Windows-Authentifizierung zu nutzen, die es Benutzern und anderen Diensten erleichtert, sich automatisch und transparent mit ihrer Identität bei der Anwendung anzumelden. In diesem Artikel werden die ersten Schritte bei der Verwendung von gruppenverwalteten Active Directory-Konten mit Windows-Containern erläutert.

Obwohl Windows-Container nicht mit Domänen verbunden werden können, können sie dennoch Active Directory-Domänenidentitäten verwenden, um verschiedene Authentifizierungsszenarien zu unterstützen. Dazu können Sie einen Windows-Container so konfigurieren, dass er mit einem gMSA (gruppenverwalteten Dienstkonto) ausgeführt wird, bei dem es sich um eine besondere Art von Dienstkonto handelt, das mit Windows Server 2012 eingeführt wurde und es mehreren Computern ermöglichen soll, eine Identität gemeinsam zu nutzen, ohne dass sie das Kennwort kennen müssen. Windows-Container sind nicht zwangsläufig Domänenmitglieder, aber viele Windows-Anwendungen, die in Windows-Containern ausgeführt werden, benötigen trotzdem AD-Authentifizierung. Zur Verwendung von AD-Authentifizierung können Sie einen Windows-Container so konfigurieren, dass er mit einem gruppenverwalteten Dienstkonto (gMSA) ausgeführt wird.

Als gMSA für Windows-Container ursprünglich eingeführt wurde, musste der Containerhost ein Domänenmitglied sein. Dies führte zu einem großen Mehraufwand für Benutzer, um den Domänenbeitritt von Windows-Workerknoten manuell durchzuführen. Diese Einschränkung wurde mit der Unterstützung von gMSA für Windows-Container für nicht in die Domäne eingebundene Containerhosts behoben. Wir unterstützen die ursprüngliche gMSA-Funktionalität zur Verwendung eines in die Domäne eingebundenen Containerhosts auch zukünftig.

Zu den Verbesserungen an gMSA bei Verwendung eines nicht in die Domäne eingebundenen Containerhosts gehören:

  • Das Erfordernis, Windows-Workerknoten manuell mit einer Domäne zu verbinden, ist entfallen, weil es großen Mehraufwand für Benutzer mit sich brachte. In Skalierungsszenarien vereinfacht die Verwendung eines nicht in die Domäne eingebundenen Containerhosts den Prozess.
  • In Rolling-Update-Szenarien müssen Benutzer den Knoten nicht länger erneut in eine Domäne einbinden.
  • Das Verwalten der Computerkonten von Workerknoten zum Abrufen von gMSA-Dienstkontokennwörtern wurde vereinfacht.
  • Das Konfigurieren von gMSA mit Kubernetes ist jetzt ein weniger komplizierter End-to-End-Prozess.

Hinweis

Erfahren Sie hier, wie die Kubernetes-Community die Verwendung von gMSA mit Windows-Containern unterstützt: Konfigurieren von gMSA.

gMSA-Architektur und -Verbesserungen

Zum Überwinden der Einschränkungen der ursprünglichen Implementierung von gMSA für Windows-Container wird bei der neuen gMSA-Unterstützung für nicht in Domänen eingebundene Containerhosts eine portable Benutzeridentität anstelle eines Hostcomputerkontos zum Abrufen der gMSA-Anmeldeinformationen verwendet. Daher ist das manuelle Hinzufügen von Windows-Workerknoten zu einer Domäne nicht mehr erforderlich, wird aber weiterhin unterstützt. Die Benutzeridentität/Anmeldeinformationen werden in einem Geheimnisspeicher gespeichert, auf den der Containerhost zugreifen kann (z. B. als Kubernetes-Geheimnis), in dem authentifizierte Benutzer sie abrufen können.

Diagram of group Managed Service Accounts version two

Die gMSA-Unterstützung für nicht mit Domänen verbundene Containerhosts bietet die Flexibilität, Container mit gMSA zu erstellen, ohne den Hostknoten mit der Domäne zu verbinden. Ab Windows Server 2019 wird ccg.exe unterstützt, wodurch ein Plug-In-Mechanismus zum Abrufen von gMSA-Anmeldeinformationen aus Active Directory Domain Services aktiviert wird. Sie können diese Identität verwenden, um den Container zu starten. Weitere Informationen zu diesem Plug-In-Mechanismus finden Sie unter der ICcgDomainAuthCredentials-Schnittstelle.

Hinweis

In Azure Kubernetes Service in Azure Stack HCI können Sie das Plug-In verwenden, um von ccg.exe aus mit AD zu kommunizieren und dann die gMSA-Anmeldeinformationen abzurufen. Weitere Informationen finden Sie unter Konfigurieren eines gruppenverwalteten Dienstkontos mit AKS unter Azure Stack HCI.

Sehen Sie sich das Diagramm unten an, um die Schritte des Container Credential Guard-Prozesses zu befolgen:

  1. Mithilfe einer CredSpec-Datei als Eingabe wird der ccg.exe-Prozess auf dem Knotenhost gestartet.

  2. Ccg.exe verwendet die Informationen in der CredSpec-Datei, um ein Plug-In zu starten und dann die Kontoanmeldeinformationen im Geheimnisspeicher abzurufen, der dem Plug-In zugeordnet ist.

  3. Ccg.exe verwendet die abgerufenen Kontoanmeldeinformationen, um das gMSA-Kennwort aus AD abzurufen.

  4. Ccg.exe macht das gMSA-Kennwort für einen Container verfügbar, der Anmeldeinformationen angefordert hat.

  5. Der Container authentifiziert sich beim Domänencontroller mithilfe des gMSA-Kennworts, um ein Kerberos Ticket-Granting Ticket (TGT) abzurufen.

  6. Anwendungen, die als Netzwerkdienst oder lokales System im Container ausgeführt werden, können sich jetzt authentifizieren und auf Domänenressourcen wie das gMSA zugreifen.

    Diagram of the ccg.exe process

Voraussetzungen

Sie benötigen Folgendes, um einen Windows-Container mit einem gruppenverwalteten Dienstkonto auszuführen:

  • Eine Active Directory-Domäne mit mindestens einem Domänencontroller mit Windows Server 2012 oder höher. Es gibt keine Anforderungen auf Gesamtstruktur- oder Domänenfunktionsebene für die Verwendung von gMSAs, aber die gMSA-Kennwörter können nur von Domänencontrollern mit Windows Server 2012 oder höher verteilt werden. Weitere Informationen finden Sie unter Active Directory-Anforderungen für gMSAs.
  • Berechtigung zum Erstellen eines gMSA-Kontos. Um ein gMSA-Konto zu erstellen, müssen Sie Domänenadministrator sein oder ein Konto verwenden, dem die Berechtigung msDS-GroupManagedServiceAccount-Objekte erstellen delegiert wurde.
  • Zugriff auf das Internet, um das CredentialSpec PowerShell-Modul herunterzuladen. Wenn Sie in einer nicht verbundenen Umgebung arbeiten, können Sie das Modul auf einem Computer mit Internetzugang speichern und es auf Ihren Entwicklungscomputer oder Containerhost kopieren.

Einmalige Vorbereitung von Active Directory

Wenn Sie nicht bereits einen gMSA in Ihrer Domäne erstellt haben, müssen Sie den Stammschlüssel des Schlüsselverteilungsdiensts (KDS) generieren. Der KDS ist für die Erstellung, Rotation und Freigabe des gMSA-Kennworts für autorisierte Hosts verantwortlich. Wenn ein Containerhost das gMSA zum Betrieb eines Containers verwenden muss, kontaktiert er den KDS, um das aktuelle Kennwort abzurufen.

Um zu überprüfen, ob der KDS-Stammschlüssel bereits erstellt wurde, führen Sie das folgende PowerShell-Cmdlet als Domänenadministrator auf einem Domänencontroller oder auf einem Domänenmitglied aus, auf dem die AD PowerShell-Tools installiert sind:

Get-KdsRootKey

Wenn der Befehl eine Schlüssel-ID zurückgibt, sind Sie bereit und können zum Abschnitt Erstellen eines gruppenverwalteten Dienstkontos übergehen. Andernfalls fahren Sie mit der Erstellung des KDS-Stammschlüssels fort.

Wichtig

Sie sollten nur einen KDS-Stammschlüssel pro Gesamtstruktur erstellen. Wenn mehrere KDS-Stammschlüssel erstellt werden, führt dies nach dem Rotieren des gMSA-Kennworts zu einem Fehler beim gMSA.

Führen Sie in einer Produktionsumgebung oder Testumgebung mit mehreren Domänencontrollern das folgende Cmdlet in PowerShell als Domänenadministrator aus, um den KDS-Stammschlüssel zu erstellen.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Obwohl der Befehl impliziert, dass der Schlüssel sofort wirksam wird, müssen Sie 10 Stunden warten, bevor der KDS-Stammschlüssel repliziert wird und zur Verwendung auf allen Domänencontrollern verfügbar ist.

Wenn Sie in Ihrer Domäne nur über einen Domänencontroller verfügen, können Sie den Prozess beschleunigen, indem Sie den Schlüssel so einstellen, dass er vor 10 Stunden wirksam wird.

Wichtig

Verwenden Sie dieses Verfahren nicht in einer Produktionsumgebung.

# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Erstellen eines gruppenverwalteten Dienstkontos

Jeder Container, der die integrierte Windows-Authentifizierung verwendet, benötigt mindestens ein gMSA. Das primäre gMSA wird immer dann verwendet, wenn Anwendungen, die als System- oder Netzwerkdienst ausgeführt werden, auf Ressourcen im Netzwerk zugreifen. Der Name des gMSAs wird im Netzwerk zum Namen des Containers, unabhängig vom Hostnamen, der dem Container zugewiesen ist. Container können auch mit zusätzlichen gMSAs konfiguriert werden, falls Sie einen Dienst oder eine Anwendung im Container als eine andere Identität als das Containercomputerkonto ausführen möchten.

Wenn Sie ein gMSA erstellen, erstellen Sie auch eine gemeinsame Identität, die gleichzeitig auf vielen verschiedenen Computern verwendet werden kann. Der Zugriff auf das gMSA-Kennwort ist durch eine Active Directory-Zugriffssteuerungsliste geschützt. Wir empfehlen, für jedes gMSA-Konto eine Sicherheitsgruppe zu erstellen und die entsprechenden Containerhosts zur Sicherheitsgruppe hinzuzufügen, um den Zugriff auf das Kennwort zu beschränken.

Da Container nicht automatisch Dienstprinzipalnamen (SPN) registrieren, müssen Sie schließlich mindestens einen Host-SPN für Ihr gMSA-Konto manuell erstellen.

Normalerweise wird der Host- oder HTTP-SPN unter demselben Namen wie das gMSA-Konto registriert, aber Sie müssen möglicherweise einen anderen Dienstnamen verwenden, wenn Clients auf die Container-App hinter einem Lastenausgleich oder einem DNS-Namen zugreifen, der sich vom gMSA-Namen unterscheidet.

Wenn das gMSA-Konto z. B. „WebApp01“ heißt, Ihre Benutzer jedoch auf den Standort unter mysite.contoso.com zugreifen, sollten Sie ein http/mysite.contoso.com-SPN für das gMSA-Konto registrieren.

Einige Anwendungen erfordern möglicherweise zusätzliche SPNs für ihre eindeutigen Protokolle. Beispielsweise ist für SQL Server der MSSQLSvc/hostname-SPN erforderlich.

Die folgende Tabelle listet die erforderlichen Attribute für die Erstellung eines gMSAs auf.

gMSA-Eigenschaft Erforderlicher Wert Beispiel
Name Ein beliebiger gültiger Kontoname. WebApp01
DnsHostName Der an den Kontonamen angefügte Domänenname. WebApp01.contoso.com
ServicePrincipalNames Legen Sie mindestens den Host-SPN fest. Fügen Sie bei Bedarf weitere Protokolle hinzu. 'host/WebApp01', 'host/WebApp01.contoso.com'
PrincipalsAllowedToRetrieveManagedPassword Die Sicherheitsgruppe, die Ihre Containerhosts enthält. WebApp01Hosts

Nachdem Sie sich für den Namen für Ihre gMSA entschieden haben, führen Sie die folgenden Cmdlets in PowerShell aus, um die Sicherheitsgruppe und das gMSA zu erstellen.

Tipp

Sie müssen ein Konto verwenden, das zur Sicherheitsgruppe Domänen-Admins gehört oder dem die Berechtigung msDS-GroupManagedServiceAccount-Objekte erstellen zugewiesen wurde, um die folgenden Befehle auszuführen. Das Cmdlet New-ADServiceAccount ist Teil der AD PowerShell-Tools von Remoteserver-Verwaltungstools.

Es wird empfohlen, separate gMSA-Konten für Ihre Entwicklungs-, Test- und Produktionsumgebung zu erstellen.

Anwendungsfall der Erstellung eines gMSA-Kontos für in die Domäne eingebundene Containerhosts

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName "WebApp01Hosts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$", "ContainerHost02$", "ContainerHost03$"

Anwendungsfall der Erstellung eines gMSA-Kontos für nicht in die Domäne eingebundene Containerhosts

Wenn Sie gMSA für Container mit nicht in die Domäne eingebundenen Hosts verwenden, erstellen Sie ein Standardbenutzerkonto, und fügen Sie es hinzu, anstatt Containerhosts zur Sicherheitsgruppe WebApp01Hosts hinzuzufügen.

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName "WebApp01Accounts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"

# Create the standard user account. This account information needs to be stored in a secret store and will be retrieved by the ccg.exe hosted plug-in to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with a unique username and password. We recommend using a random, long, machine-generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled 1

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"

Vorbereiten des Containerhosts

Anwendungsfall für die Vorbereitung des Containerhosts für einen in die Domäne eingebundenen Containerhost

Jeder Containerhost, auf dem ein Windows-Container mit einem gMSA ausgeführt werden soll, muss mit der Domäne verknüpft sein und Zugriff auf das gMSA-Kennwort haben.

  1. Verbinden Sie Ihren Computer mit Ihrer Active Directory-Domäne.

  2. Stellen Sie sicher, dass Ihr Host zu der Sicherheitsgruppe gehört, die den Zugriff auf das gMSA-Kennwort kontrolliert.

  3. Starten Sie den Computer neu, damit er seine neue Gruppenmitgliedschaft erhält.

  4. Richten Sie Docker Desktop für Windows 10 oder Docker für Windows Server ein.

  5. (Empfohlen) Überprüfen Sie, ob der Host das gMSA-Konto verwenden kann, indem Sie Test-ADServiceAccount ausführen. Wenn der Befehl False zurückgibt, befolgen Sie die Anweisungen zur Problembehandlung.

    # To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
    # To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
    # To install the AD module on older versions of Windows 10, see https://aka.ms/rsat
    
    Test-ADServiceAccount WebApp01
    

Anwendungsfall für die Vorbereitung des Containerhosts für einen nicht in die Domäne eingebundenen Containerhost

Wenn Sie gMSA für Windows-Container auf Containerhosts verwenden, die keine Domänenmitglieder sind, muss auf jedem Containerhost ein Plug-In für ccg.exe installiert sein, das zum Abrufen des portablen Benutzerkontos und der im vorherigen Schritt angegebenen Anmeldeinformationen verwendet wird. Plug-Ins sind für den Geheimnisspeicher, der für den Schutz der Anmeldeinformationen für portable Benutzerkonten verwendet wird, eindeutig. So sind zum Beispiel andere Plug-Ins für das Speichern von Kontoanmeldeinformationen in einem Azure Key Vault als für das Speichern einem Kubernetes-Geheimnisspeicher erforderlich.

Windows bietet derzeit kein integriertes Standard-Plug-In. Installationsanweisungen für Plug-Ins sind implementierungsspezifisch. Weitere Informationen zum Erstellen und Registrieren von Plug-Ins für ccg.exe finden Sie unter ICcgDomainAuthCredentials-Schnittstelle.

Erstellen einer Spezifikation der Anmeldeinformationen

Eine Spezifikationsdatei für die Anmeldeinformationen ist ein JSON-Dokument, das Metadaten über die gMSA-Konten enthält, die ein Container verwenden soll. Indem Sie die Identitätskonfiguration vom Containerimage getrennt halten, können Sie ändern, welches gMSA der Container verwendet, indem Sie einfach die Spezifikationsdatei der Anmeldeinformationen austauschen, ohne dass Codeänderungen erforderlich sind.

Die Spezifikationsdatei für die Anmeldeinformationen wird mit dem CredentialSpec PowerShell-Modul auf einem Computer erstellt, der mit der Domäne verbunden ist. Nachdem Sie die Datei erstellt haben, können Sie sie auf andere Containerhosts oder auf Ihren Containerorchestrator kopieren. Die Spezifikationsdatei für die Anmeldeinformationen enthält keine Geheimnisse, z. B. das gMSA-Kennwort, da der Containerhost das gMSA im Auftrag des Containers abruft.

Docker erwartet, dass die Spezifikationsdatei für die Anmeldeinformationen unter dem Verzeichnis CredentialSpecs im Docker-Datenverzeichnis zu finden ist. In einer Standardinstallation finden Sie diesen Ordner unter C:\ProgramData\Docker\CredentialSpecs.

So erstellen Sie eine Spezifikationsdatei für die Anmeldeinformationen auf Ihrem Containerhost

  1. Installieren der RSAT AD PowerShell-Tools

    • Führen Sie für Windows Server Install-WindowsFeature RSAT-AD-PowerShell aus.
    • Für Windows 10, Version 1809 oder höher, führen Sie WindowsCapability -Online - Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~~~0.0.1.0' aus.
    • Informationen zu älteren Versionen von Windows 10 finden Sie unter https://aka.ms/rsat.
  2. Führen Sie das folgende Cmdlet aus, um die neueste Version des CredentialSpec PowerShell-Moduls zu installieren:

    Install-Module CredentialSpec
    

    Wenn Sie auf Ihrem Containerhost keinen Internetzugriff haben, führen Sie Save-Module CredentialSpec auf einem mit dem Internet verbundenen Computer aus, und kopieren Sie den Modulordner nach C:\Program Files\WindowsPowerShell\Modules oder an einen anderen Speicherort in $env:PSModulePath auf dem Containerhost.

  3. Führen Sie das folgende Cmdlet aus, um die neue Spezifikationsdatei für die Anmeldeinformationen zu erstellen:

    # Replace 'WebApp01' with your own gMSA
    New-CredentialSpec -AccountName WebApp01
    

    Standardmäßig erstellt das Cmdlet eine Spezifikationsdatei für die Anmeldeinformationen unter Verwendung des angegebenen gMSA-Namens als Computerkonto für den Container. Die Datei wird im Verzeichnis „Docker CredentialSpecs“ unter Verwendung der gMSA-Domäne und des Kontonamens für den Dateinamen gespeichert.

    Wenn Sie die Datei in einem anderen Verzeichnis speichern möchten, verwenden Sie den Parameter -Path:

    New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
    

    Sie können auch eine Spezifikation der Anmeldeinformationen erstellen, die zusätzliche gMSA-Konten enthält, wenn Sie einen Dienst oder Prozess als sekundäres gMSA im Container ausführen. Verwenden Sie dazu den Parameter -AdditionalAccounts:

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
    

    Eine vollständige Liste der unterstützten Parameter erhalten Sie, wenn Sie Get-Help New-CredentialSpec -Full ausführen.

  4. Mit dem folgenden Cmdlet können Sie eine Liste aller Spezifikationen der Anmeldeinformationen und deren vollständigen Pfad anzeigen:

    Get-CredentialSpec
    

Dies ist ein Beispiel einer Spezifikation für Anmeldeinformationen:

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ]
    }
}

Anwendungsfall einer zusätzlichen Konfiguration der Anmeldeinformationsspezifikation für einen nicht mit der Domäne verbundenen Containerhost

Wenn Sie gMSA mit Containerhosts verwenden, die nicht mit der Domäne verbunden sind, müssen der Spezifikation der Anmeldeinformationen Informationen zum verwendeten ccg.exe-Plug-In hinzugefügt werden. Dies wird einem Abschnitt der Spezifikation der Anmeldeinformationen mit dem Namen HostAccountConfig hinzugefügt. Der Abschnitt HostAccountConfig enthält drei Felder, die aufgefüllt werden müssen:

  • PortableCcgVersion: Dieses Feld sollte auf „1“ festgelegt werden.
  • PluginGUID: Die COM-CLSID für das ccg.exe-Plug-In. Diese ist für das verwendete Plug-In eindeutig.
  • PluginInput: Plug-In-spezifische Eingabe zum Abrufen der Benutzerkontoinformationen aus dem Geheimnisspeicher.

Dies ist ein Beispiel für eine Spezifikation der Anmeldeinformationen, der der Abschnitt HostAccountConfig hinzugefügt wurde:

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ],
        "HostAccountConfig": {
            "PortableCcgVersion": "1",
            "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
            "PluginInput": "contoso.com:gmsaccg:<password>"
        }
    }
}

Nächste Schritte

Nachdem Sie Ihr gMSA-Konto eingerichtet haben, können Sie es für Folgendes verwenden:

Wenn während des Setups Probleme auftreten, überprüfen Sie unseren Leitfaden zur Problembehandlung auf mögliche Lösungen.

Zusätzliche Ressourcen