Dela via

Felsöka gMSA:er för Windows-containrar

  • Artikel

Gäller för: Windows Server 2025, Windows Server 2022, Windows Server 2019

Kända problem

Containerns värdnamn måste matcha gMSA-namnet för Windows Server 2016 och Windows 10, version 1709 och 1803

Om du kör Windows Server 2016, version 1709 eller 1803 måste värdnamnet för containern matcha ditt gMSA SAM-kontonamn.

När värdnamnet inte matchar gMSA-namnet misslyckas inkommande NTLM-autentiseringsbegäranden och namn/SID-översättning (används av många bibliotek, t.ex. ASP.NET medlemskapsrollprovider). Kerberos fortsätter att fungera normalt även om värdnamnet och gMSA-namnet inte matchar.

Den här begränsningen har åtgärdats i Windows Server 2019, där containern nu alltid kommer att använda sitt gMSA-namn i nätverket oavsett det tilldelade värdnamnet.

Du kan inte använda gMSA:er med isolerade Hyper-V-containrar i Windows 10 version 1703, 1709 och 1803

Containerinitiering låser sig eller misslyckas när du försöker använda en gMSA med en Hyper-V isolerad container i Windows 10 och Windows Server version 1703, 1709 och 1803.

Den här buggen har åtgärdats i Windows Server 2019 och Windows 10 version 1809. Du kan också köra Hyper-V isolerade containrar med gMSAs på Windows Server 2016 och Windows 10 version 1607.

Allmän felsökningsvägledning

Om du får fel när du kör en container med en gMSA kan följande instruktioner hjälpa dig att identifiera grundorsaken.

Domänanslutna hosts: Verifiera att hosten kan använda gMSA

  1. Kontrollera att värden är domänansluten och kan nå domänkontrollanten.

  2. Installera AD PowerShell-verktygen från RSAT och kör Test-ADServiceAccount för att se om datorn har åtkomst till att hämta gMSA. Om cmdleten returnerar Falsehar datorn inte åtkomst till gMSA-lösenordet.

    # 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

  3. Om Test-ADServiceAccount returnerar False, ska du kontrollera att värden tillhör en säkerhetsgrupp som har åtkomst till gMSA-lösenordet.

    # Get the current computer's group membership
Get-ADComputer $env:computername | Get-ADPrincipalGroupMembership | Select-Object DistinguishedName

# Get the groups allowed to retrieve the gMSA password
# Change "WebApp01" for your own gMSA name
(Get-ADServiceAccount WebApp01 -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword

  4. Om din värd tillhör en säkerhetsgrupp som är auktoriserad att hämta gMSA-lösenordet men det fortfarande misslyckas med Test-ADServiceAccount, kan du behöva starta om datorn för att få en ny biljett som återspeglar de aktuella gruppmedlemskapen.

Värdar som inte är anslutna till en domän: Kontrollera att värdarna är konfigurerade för att hämta gMSA-kontot.

Kontrollera att ett plugin för att använda gMSA med en containervärd utan domänanslutning är korrekt installerat på värden. Windows innehåller inte något inbyggt plugin-program och kräver att du tillhandahåller ett plugin-program som implementerar gränssnittet ICcgDomainAuthCredentials. Installationsinformationen är specifik för plugin-programmet.

Kontrollera autentiseringsspecifikationsfilen

  1. Kör Get-CredentialSpec- från CredentialSpec PowerShell-modulen för att hitta alla autentiseringsspecifikationer på datorn. Autentiseringsspecifikationerna måste lagras i katalogen "CredentialSpecs" under Docker-rotkatalogen. Du hittar Docker-rotkatalogen genom att köra docker-information -f {{. DockerRootDir}}".

  2. Öppna filen CredentialSpec och kontrollera att följande fält är korrekt ifyllda:

    1. För domänanslutna containervärdar:

      • Sid: domänens SID
      • MachineAccountName: gMSA SAM-kontonamnet (inkludera inte fullständigt domännamn eller dollartecken)
      • DnsTreeName: FQDN för din Active Directory-skog
      • DnsName: FQDN för domänen som gMSA tillhör
      • NetBiosName: NETBIOS-namn för den domän som gMSA tillhör
      • GroupManagedServiceAccounts/Name: gMSA SAM-kontonamnet (inkludera inte fullständigt domännamn eller dollartecken)
      • GroupManagedServiceAccounts/Scope: en post för domänens FQDN och en för NETBIOS

      Dina indata bör se ut som i följande exempel på en fullständig autentiseringsspecifikation:

      {
    "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"
            }
        ]
    }
}

    2. För icke-domänanslutna värdar: Förutom alla fält för containervärdar som inte är domänanslutna kontrollerar du att "HostAccountConfig"-avsnittet finns och att fälten nedan är korrekt definierade.

      • PortableCcgVersion: Detta bör vara inställt på "1".
      • PluginGUID: COM CLSID för ditt ccg.exe plugin-program. Detta är unikt för plugin-programmet som används.
      • PluginInput: Insticksprogramsspecifika indata för att hämta användarkontoinformationen från den hemliga lagringen.

      Dina indata bör se ut som i följande exempel på en fullständig autentiseringsspecifikation:

      {
    "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>"
        }
    }
}

  3. Kontrollera att sökvägen till autentiseringsspecifikationsfilen är korrekt för orkestreringslösningen. Om du använder Docker kontrollerar du att kommandot för containerkörning innehåller --security-opt="credentialspec=file://NAME.json", där "NAME.json" ersätts med namnutdata av Get-CredentialSpec. Namnet är ett platt filnamn i förhållande till mappen CredentialSpecs under Docker-rotkatalogen.

Kontrollera nätverkskonfigurationen

Kontrollera brandväggskonfigurationen

Om du använder en strikt brandväggsprincip i containern eller värdnätverket kan det blockera nödvändiga anslutningar till Active Directory-domänkontrollanten eller DNS-servern.

Protokoll och port Avsikt
TCP och UDP 53 DNS
TCP och UDP 88 Kerberos
TCP 139 NetLogon
TCP och UDP 389 LDAP
TCP 636 LDAP SSL

Du kan behöva tillåta åtkomst till ytterligare portar beroende på vilken typ av trafik containern skickar till en domänkontrollant. Se Portkrav för Active Directory och Active Directory Domain Services för en fullständig lista över portar som används av Active Directory.

Kontrollera DNS-konfigurationen hos containervärden

Om du använder gMSA med en domänansluten containervärd bör DNS automatiskt konfigureras på värdmaskinen för att den korrekt ska kunna lösa och upprätta en anslutning till domänen. Om du använder gMSA med en icke-domänansluten värd anges inte den här konfigurationen automatiskt. Du bör kontrollera att värdnätverket är konfigurerat så att det kan matcha domänen. Du kan kontrollera att domänen kan lösas upp från hosten med hjälp av:

nltest /sc_verify:contoso.com

Kontrollera containern

  1. Om du kör en version av Windows före Windows Server 2019 eller Windows 10 version 1809 måste containerns värdnamn matcha gMSA-namnet. Kontrollera att parametern --hostname matchar gMSA-kortnamnet (ingen domänkomponent, till exempel "webapp01" i stället för "webapp01.contoso.com").

  2. Granska konfigurationen av containernätverket för att verifiera att containern kan lösa och komma åt en domänkontrollant för gMSA-domänen. Felkonfigurerade DNS-servrar i containern är en vanlig gärningsman till identitetsproblem.

  3. Kontrollera om containern har en giltig anslutning till domänen genom att köra följande cmdlet i containern (med docker exec eller motsvarande):

    nltest /sc_verify:contoso.com

    Förtroendeverifieringen bör returnera NERR_SUCCESS om gMSA är tillgängligt och nätverksanslutningen gör att containern kan kommunicera med domänen. Om det inte fungerar, kontrollera nätverkskonfigurationen för värden och containern. Båda måste kunna kommunicera med domänkontrollanten.

  4. Kontrollera om containern kan hämta en giltig Kerberos Ticket Granting Ticket (TGT):

    klist get <myapp>

    Det här kommandot ska returnera "En biljett till krbtgt har hämtats framgångsrikt" och visa vilken domänkontroller som användes för att hämta biljetten. Om du kan hämta en TGT men nltest från föregående steg misslyckas kan detta vara en indikation på att gMSA-kontot är felkonfigurerat. Se kontrollera gMSA-kontot för mer information.

    Om du inte kan hämta en TGT i containern kan detta tyda på DNS- eller nätverksanslutningsproblem. Kontrollera att containern kan lösa upp en domänkontrollant med domänens DNS-namn och att domänkontrollanten är åtkomlig från containern.

  5. Kontrollera att appen är konfigurerad för att använda gMSA -. Användarkontot i containern ändras inte när du använder en gMSA. Systemkontot använder i stället gMSA när det pratar med andra nätverksresurser. Det innebär att din app måste köras som nätverkstjänst eller lokalt system för att använda gMSA-identiteten.

    Tips

    Om du kör whoami eller använder ett annat verktyg för att identifiera din aktuella användarkontext i containern visas inte själva gMSA-namnet. Det beror på att du alltid loggar in på containern som en lokal användare i stället för en domänidentitet. GMSA används av datorkontot när det pratar med nätverksresurser, vilket är anledningen till att din app måste köras som nätverkstjänst eller lokalt system.

Kontrollera gMSA-kontot

  1. Om containern verkar vara korrekt konfigurerad men användare eller andra tjänster inte kan autentisera automatiskt till din containerbaserade app kontrollerar du SPN:erna på ditt gMSA-konto. Klienterna hittar gMSA-kontot med det namn som de använder för att nå ditt program. Det kan innebära att du behöver ytterligare host SPN för din gMSA om till exempel klienter ansluter till din app via en lastbalanserare eller ett annat DNS-namn.

  2. Om du vill använda gMSA med en domänansluten containervärd kontrollerar du att gMSA- och containervärden tillhör samma Active Directory-domän. Containerhosten kommer inte att kunna hämta gMSA-lösenordet om gMSA tillhör en annan domän.

  3. Kontrollera att det bara finns ett konto i domänen med samma namn som din gMSA. gMSA-objekt har dollartecken ($) kopplade till sina SAM-kontonamn, så det är möjligt att en gMSA får namnet "myaccount$" och att ett orelaterat användarkonto får namnet "myaccount" i samma domän. Detta kan orsaka problem om domänkontrollanten eller programmet måste söka upp gMSA efter namn. Du kan söka i AD efter objekt med liknande namn med följande kommando:

    # Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'

  4. Om du har aktiverat obegränsad delegering på gMSA-kontot kontrollerar du att attributet UserAccountControl fortfarande har flaggan WORKSTATION_TRUST_ACCOUNT aktiverad. Den här flaggan krävs för att NETLOGON i containern ska kunna kommunicera med domänkontrollanten, vilket är fallet när en app måste matcha ett namn till ett SID eller vice versa. Du kan kontrollera om flaggan är korrekt konfigurerad med följande kommandon:

    $gMSA = Get-ADServiceAccount -Identity 'yourGmsaName' -Properties UserAccountControl
($gMSA.UserAccountControl -band 0x1000) -eq 0x1000

    Om ovanstående kommandon returnerar Falseanvänder du följande för att lägga till flaggan WORKSTATION_TRUST_ACCOUNT i gMSA-kontots UserAccountControl-egenskap. Det här kommandot rensar också flaggorna NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNToch SERVER_TRUST_ACCOUNT från egenskapen UserAccountControl.

    Set-ADObject -Identity $gMSA -Replace @{ userAccountControl = ($gmsa.userAccountControl -band 0x7FFFC5FF) -bor 0x1000 }

Icke-domänanslutna containervärdar: Använd händelseloggar för att identifiera konfigurationsproblem

Händelseloggning för användning av gMSA med icke-domänanslutna containervärdar kan användas för att identifiera konfigurationsproblem. Händelser loggas i loggfilen Microsoft-WindowsContainers-CCG och finns i Loggboken under Program- och tjänstloggar\Microsoft\Windows\Containers-CCG\Admin. Om du exporterar loggfilen från containervärden för att läsa den, måste du ha containerfunktionen aktiverad på den enhet där du försöker läsa loggfilen, och du måste ha en Windows-version som stöder användning av gMSA med icke-domänanslutna containervärdar.

Händelser och beskrivningar

Händelsenummer Händelsetext Beskrivning
1 Container Credential Guard instansierade plugin-programmet Den här händelsen anger att det tillägg som specificerades i autentiseringsspecifikationen installerades och kunde läsas in. Ingen åtgärd krävs.
2 Container Credential Guard hämtade gmsa-autentiseringsuppgifter för %1 med plugin-programmet: %2 Det här är en informationshändelse som anger att gMSA-autentiseringsuppgifterna har hämtats från AD. Ingen åtgärd krävs.
3 Container Credential Guard kunde inte parsa autentiseringsspecifikationen. Fel: %1 Den här händelsen anger ett problem med autentiseringsuppgiftsspecifikationen. Detta kan inträffa om GUID för plugin-programmet är felaktigt eller om det finns andra felaktiga fält. Läs felsökningsvägledning för autentiseringsspecifikationen för att verifiera formateringen och innehållet i autentiseringsspecifikationen.
4 Container Credential Guard kunde inte instansiera plugin-programmet: %1. Fel: %2 Den här händelsen anger att plugin-programmet inte kunde läsas in. Kontrollera att plugin-programmet har installerats korrekt på värddatorn.
6 Container Credential Guard kunde inte hämta autentiseringsuppgifter från plugin-programmet: %1. Fel: %2 Den här händelsen anger att plugin-programmet lästes in men inte kunde hämta de autentiseringsuppgifter som behövdes för att hämta gMSA-lösenordet från AD. Du bör kontrollera att ingången till plugin-programmet är korrekt formaterad i autentiseringsspecifikationen och att containerhosten har de nödvändiga behörigheterna för att komma åt den hemliga lagringen som används av plugin-programmet.
7 Container Credential Guard hämtar autentiseringsuppgifterna med hjälp av plugin-programmet: %1 Det här är en informationshändelse. Den här händelsen genereras när gMSA-lösenordet har upphört att gälla och måste uppdateras med de autentiseringsuppgifter som hämtas av plugin-programmet.
8 Container Credential Guard kunde inte hämta gmsa-autentiseringsuppgifter för %1 med plugin-%2. Felanledning: %3 Den här händelsen anger att de autentiseringsuppgifter som hämtades med plugin-programmet inte kunde användas för att hämta gMSA-autentiseringsuppgifter från AD. Du bör kontrollera att kontot som hämtas från plugin-programmet har behörigheter i AD för att hämta gMSA-autentiseringsuppgifterna.