Freigeben über

Erstellen von gMSAs für Windows-Container

  • Artikel

Gilt für: Windows Server 2025, 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 AD-integriert sind und auf domänenverbundenen Servern ausgeführt werden, um die integrierte Windows-Authentifizierung zu nutzen, wodurch Benutzer und andere Dienste sich automatisch und transparent mit ihren Identitäten bei der Anwendung anmelden können. In diesem Artikel wird erläutert, wie Sie mit der Verwendung von verwalteten Active Directory-Dienstkonten mit Windows-Containern beginnen.

Obwohl Windows-Container nicht in die Domäne eingebunden werden können, können sie weiterhin Active Directory-Domänenidentitäten verwenden, um verschiedene Authentifizierungsszenarien zu unterstützen. Um dies zu erreichen, können Sie einen Windows-Container für die Ausführung mit einem gruppenverwalteten Dienstkonto (gMSA) konfigurieren, bei dem es sich um einen speziellen Dienstkontotyp handelt, der in Windows Server 2012 eingeführt wurde und es mehreren Computern ermöglicht, eine Identität freizugeben, ohne sein Kennwort kennen zu müssen. Windows-Container können nicht in eine Domäne eingebunden werden, aber viele Windows-Anwendungen, die in Windows-Containern ausgeführt werden, benötigen weiterhin AD-Authentifizierung. Um die AD-Authentifizierung zu verwenden, können Sie einen Windows-Container so konfigurieren, dass er mit einem gruppenverwalteten Dienstkonto (gMSA) ausgeführt wird.

Bei der ersten Einführung von gMSA für Windows-Containern musste der Containerhost einer Domäne beigetreten sein, wodurch benutzern ein erheblicher Aufwand entsteht, um Windows-Workerknoten manuell mit einer Domäne zu verbinden. Diese Einschränkung wurde durch die gMSA-Unterstützung für Windows-Container auf Containerhosts behoben, die nicht in eine Domäne eingebunden sind. Wir unterstützen weiterhin die ursprüngliche gMSA-Funktionalität, um einen in die Domäne eingebundenen Containerhost zu verwenden.

Zu den Verbesserungen bei gMSA bei Verwendung eines nicht domänenverbundenen Containerhosts gehören:

  • Die Anforderung, Windows-Workerknoten manuell mit einer Domäne zu verbinden, wird eliminiert, da dadurch ein erheblicher Aufwand für Benutzer verursacht wurde. Bei Skalierungsszenarien vereinfacht die Verwendung eines nicht in eine Domäne eingebundenen Containerhosts den Prozess.
  • Im Fall paralleler Updates müssen Benutzende den Knoten nicht mehr 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 ein weniger komplizierter End-to-End-Prozess.

Anmerkung

Informationen dazu, wie die Kubernetes-Community die Verwendung von gMSA mit Windows-Containern unterstützt, finden Sie unter Konfigurieren von gMSA-.

gMSA-Architektur und -Verbesserungen

Um die Einschränkungen der anfänglichen Implementierung von gMSA für Windows-Container zu beheben, verwendet neue gMSA-Unterstützung für nicht domänenverbundene Containerhosts eine tragbare Benutzeridentität anstelle eines Hostcomputerkontos, um gMSA-Anmeldeinformationen abzurufen. Daher ist das manuelle Verknüpfen von Windows-Workerknoten zu einer Domäne nicht mehr erforderlich, obwohl sie weiterhin unterstützt wird. Die Benutzeridentität/Anmeldeinformationen werden in einem geheimen Speicher gespeichert, auf den der Containerhost zugreifen kann (z. B. als Kubernetes-Geheimnis), in dem authentifizierte Benutzer sie abrufen können.

Diagramm der Gruppenverwalteten Dienstkonten, Version Zwei

gMSA-Unterstützung für nicht domänenverbundene Containerhosts bietet die Flexibilität, Container mit gMSA zu erstellen, ohne dem Hostknoten zur Domäne beizutreten. Ab Windows Server 2019 wird ccg.exe unterstützt, mit dem ein Plug-In-Mechanismus gMSA-Anmeldeinformationen aus Active Directory abrufen kann. Sie können diese Identität verwenden, um den Container zu starten. Weitere Informationen zu diesem Plug-In-Mechanismus finden Sie in der ICcgDomainAuthCredentials-Schnittstelle.

Anmerkung

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

Sehen Sie sich das folgende Diagramm an, um die Schritte des Container Credential Guard-Prozesses auszuführen:

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

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

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

  4. ccg.exe stellt das gMSA-Kennwort einem Container zur Verfügung, 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 zugreifen, z. B. die gMSA.

    Diagramm des ccg.exe Prozesses

Voraussetzungen

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

  • Eine Active Directory-Domäne mit mindestens einem Domänencontroller unter Windows Server 2012 oder höher. Für die Verwendung von gMSAs gibt es keine Anforderungen an die Gesamtstruktur oder Domäne auf Funktionsebene, die gMSA-Kennwörter können jedoch nur von Domänencontrollern bereitgestellt werden, auf denen Windows Server 2012 oder höher ausgeführt wird. Weitere Informationen finden Sie unter Active Directory-Anforderungen für gMSAs.
  • Berechtigung zum Erstellen eines gMSA-Kontos. Zum Erstellen eines gMSA-Kontos müssen Sie Domänenadministrator/in sein oder ein Konto verwenden, dem die Berechtigung Erstellen von msDS-GroupManagedServiceAccount-Objekten delegiert wurde.
  • Zugriff auf das Internet zum Herunterladen des PowerShell-Moduls "CredentialSpec". Wenn Sie in einer getrennten Umgebung arbeiten, können Sie das Modul auf einem Computer mit Internetzugang speichern und auf Ihren Entwicklungscomputer oder Containerhost kopieren.

Einmalige Vorbereitung von Active Directory

Wenn Sie noch keine gMSA in Ihrer Domäne erstellt haben, müssen Sie den Schlüsselschlüssel für den Schlüsselverteilungsdienst (Key Distribution Service, KDS) generieren. Die KDS ist für das Erstellen, Drehen und Freigeben des gMSA-Kennworts für autorisierte Hosts verantwortlich. Wenn ein Containerhost die gMSA zum Ausführen eines Containers verwenden muss, wird er sich an die KDS wenden, 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 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 navigieren. Fahren Sie andernfalls mit dem Erstellen des KDS-Stammschlüssels fort.

Wichtig

Sie sollten nur einen KDS-Stammschlüssel pro Gesamtstruktur erstellen. Wenn mehrere KDS-Stammschlüssel erstellt werden, wird die gMSA nicht mehr funktionieren, nachdem das gMSA-Kennwort geändert wird.

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 und für die Verwendung auf allen Domänencontrollern verfügbar ist.

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

Wichtig

Verwenden Sie diese Technik nicht in einer Produktionsumgebung.

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

Erstellen eines gruppenverwalteten Dienstkontos

Jeder Container, der integrierte Windows-Authentifizierung verwendet, benötigt mindestens ein gMSA. Die primäre gMSA wird verwendet, wenn Apps, die als System oder Netzwerkdienst ausgeführt werden, auf Ressourcen im Netzwerk zugreifen. Der Name des gMSA wird, unabhängig vom einem Hostnamen, der dem Container zugewiesen ist, zum Netzwerknamen des Containers. 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 eine gMSA erstellen, erstellen Sie auch eine gemeinsame Identität, die gleichzeitig auf vielen Computern verwendet werden kann. Der Zugriff auf das gMSA-Kennwort ist durch eine Active Directory-Zugriffssteuerungsliste geschützt. Es wird empfohlen, für jedes gMSA-Konto eine Sicherheitsgruppe zu erstellen und die relevanten Containerhosts zur Sicherheitsgruppe hinzuzufügen, um den Zugriff auf das Kennwort zu beschränken.

Da Container keine Dienstprinzipalnamen (Service Principal Names, SPN) automatisch registrieren, müssen Sie mindestens einen Host-SPN für Ihr gMSA-Konto manuell erstellen.

In der Regel wird der Host oder http SPN mit demselben Namen wie das gMSA-Konto registriert. Möglicherweise müssen Sie jedoch einen anderen Dienstnamen verwenden, wenn Clients auf die containerisierte Anwendung von hinter einem Lastenausgleichsmodul oder einem DNS-Namen zugreifen, der sich vom gMSA-Namen unterscheidet.

Wenn z. B. das gMSA-Konto "WebApp01" heißt, Ihre Benutzer aber auf die Website bei mysite.contoso.comzugreifen, sollten Sie einen http/mysite.contoso.com SPN für das gMSA-Konto registrieren.

Einige Anwendungen erfordern möglicherweise zusätzliche SPNs für ihre eindeutigen Protokolle. Sql Server erfordert beispielsweise den MSSQLSvc/hostname SPN.

In der folgenden Tabelle sind die erforderlichen Attribute zum Erstellen eines gMSA aufgeführt.

gMSA-Eigenschaft Erforderlicher Wert Beispiel
Name Ein beliebiger gültiger Kontoname. WebApp01
DnsHostName Der Domänenname, der an den Kontonamen angefügt wurde. 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 Ihrer gMSA entschieden haben, führen Sie die folgenden Cmdlets in PowerShell aus, um die Sicherheitsgruppe und gMSA zu erstellen.

Tipp

Sie müssen ein Konto verwenden, das zur Sicherheitsgruppe Domänenadmins gehört oder dem die Berechtigung zum Erstellen von msDS-GroupManagedServiceAccount-Objekten erteilt wurde, um die folgenden Befehle auszuführen. Das Cmdlet New-ADServiceAccount ist Teil der AD PowerShell-Tools aus Remoteserver-Verwaltungstools.

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

Anwendungsfall zum Erstellen 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 zum Erstellen eines gMSA-Kontos für Nicht-domänenverbundene Containerhosts

Wenn Sie gMSA für Container mit nicht domänenverbundenen Hosts verwenden, erstellen und fügen Sie ein Standardbenutzerkonto hinzu, anstatt der Sicherheitsgruppe WebApp01Hosts Containerhosts 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 eine Domäne eingebundenen Containerhost

Jeder Containerhost, der einen Windows-Container mit einer gMSA ausführt, muss einer Domäne beigetreten sein und Zugriff haben, um das gMSA-Kennwort abzurufen.

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

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

  3. Starten Sie den Computer neu, um die neue Gruppenmitgliedschaft zu erhalten.

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

  5. (Empfohlen) Überprüfen Sie, ob der Host das gMSA-Konto verwenden kann, indem Sie Test-ADServiceAccountausführen. Wenn der Befehl Falsezurückgibt, folgen Sie den 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 eine Domäne eingebundenen Containerhost

Bei Verwendung von gMSA für Windows-Container auf Containerhosts, die nicht in die Domäne eingebunden sind, muss jeder Containerhost über ein Plug-In für ccg.exe verfügen, das zum Abrufen des portablen Benutzerkontos und der im vorherigen Schritt angegebenen Anmeldeinformationen verwendet wird. Plug-Ins sind exklusiv für den Geheimnisspeicher, der zum Schutz der portierbaren Anmeldeinformationen der Benutzerkonten verwendet wird. Beispielsweise wären unterschiedliche Plug-Ins erforderlich, um Kontoanmeldeinformationen im Azure Key Vault im Vergleich zu einem Kubernetes-Geheimspeicher zu speichern.

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

Erstellen einer Spezifikation der Anmeldeinformationen

Eine Spezifikationsdatei für Anmeldeinformationen ist ein JSON-Dokument, das Metadaten zu den gMSA-Konten enthält, die ein Container verwenden soll. Indem Sie die Identitätskonfiguration getrennt vom Containerimage beibehalten, können Sie ändern, welche gMSA der Container verwendet, indem Sie einfach die Anmeldeinformationsspezifikationsdatei austauschen, es sind keine Codeänderungen erforderlich.

Die Anmeldeinformationsspezifikationsdatei wird mithilfe des CredentialSpec PowerShell-Moduls auf einem an die Domäne angebundenen Rechner erstellt. Nachdem Sie die Datei erstellt haben, können Sie sie auf andere Containerhosts oder in Ihren Container-Orchestrator kopieren. Die Spezifikationsdatei für Anmeldeinformationen enthält keine geheimen Schlüssel, z. B. das gMSA-Kennwort, da der Containerhost die gMSA im Namen des Containers abruft.

Docker erwartet, die Datei für die Spezifikation der Anmeldeinformationen im CredentialSpecs-Verzeichnis des Docker-Datenverzeichnisses zu finden. In einer Standardinstallation finden Sie diesen Ordner unter C:\ProgramData\Docker\CredentialSpecs.

So erstellen Sie eine Datei für die Spezifikation der Anmeldeinformationen auf Ihrem Containerhost

  1. Installieren Sie die RSAT AD PowerShell-Tools

    • Führen Sie RSAT-AD-PowerShell Install-WindowsFeaturefür Windows Server aus.
    • Führen Sie für Windows 10, Version 1809 oder höher, Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~0.0.1.0"aus.
    • Ältere Versionen von Windows 10 finden Sie unter https://aka.ms/rsat.

  2. Führen Sie das folgende Cmdlet aus, um die neueste Version des PowerShell-Modulszu installieren:

    Install-Module CredentialSpec

    Wenn Sie keinen Internetzugang auf Ihrem Containerhost haben, führen Sie Save-Module CredentialSpec auf einem mit dem Internet verbundenen Computer aus, und kopieren Sie den Modulordner in 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 Anmeldeinformationen zu erstellen:

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

    Standardmäßig erstellt das Cmdlet eine Spezifikation der Anmeldeinformationen mithilfe des bereitgestellten gMSA-Namens als Computerkonto für den Container. Die Datei wird im Docker CredentialSpecs-Verzeichnis mithilfe 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 Anmeldespezifikation erstellen, die zusätzliche gMSA-Konten enthält, falls Sie im Container einen Dienst oder Prozess als sekundäre gMSA ausführen. Verwenden Sie dazu den parameter -AdditionalAccounts:

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc

    Führen Sie Get-Help New-CredentialSpec -Fullaus, um eine vollständige Liste der unterstützten Parameter anzuzeigen.

  4. Sie können eine Liste aller Anmeldespezifikationen und deren vollständiger Pfad mit dem folgenden Cmdlet anzeigen.

    Get-CredentialSpec

Dies ist ein Beispiel für eine Spezifikation der 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 für zusätzliche Konfiguration der Anmeldeinformationen für nicht in eine Domäne eingebundene Containerhosts

Wenn Sie gMSA mit nicht in die Domäne eingebundenen Container-Hosts verwenden, müssen Informationen zu dem ccg.exe-Plug-In, das Sie verwenden werden, der Berechtigungsspezifikation hinzugefügt werden. Dies wird einem Abschnitt der Berechtigungsspezifikation namens HostAccountConfighinzugefügt. Der HostAccountConfig Abschnitt enthält drei Felder, die ausgefüllt werden müssen:

  • PortableCcgVersion: Dies sollte auf "1" festgelegt werden.
  • PluginGUID: Die COM-CLSID für das ccg.exe-Plug-In. Dies ist einzigartig für das verwendete Plug-In.
  • PluginInput: Plug-In-spezifische Eingabe zum Abrufen der Benutzerkontoinformationen aus dem Geheimnisspeicher.

Dies ist ein Beispiel für eine Spezifikation der Anmeldeinformationen, bei 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, sehen Sie in unserem Leitfaden zur Fehlerbehebung nach, um mögliche Lösungen zu finden.

Weitere Ressourcen