Dela via


Skapa gMSA:er för Windows-containrar

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

Windows-baserade nätverk använder ofta Active Directory (AD) för att underlätta autentisering och auktorisering mellan användare, datorer och andra nätverksresurser. Utvecklare av företagsprogram utformar ofta sina appar så att de är AD-integrerade och körs på domänanslutna servrar för att dra nytta av integrerad Windows-autentisering, vilket gör det enkelt för användare och andra tjänster att automatiskt och transparent logga in på programmet med sina identiteter. Den här artikeln beskriver hur du börjar använda Active Directory-grupphanterade tjänstkonton med Windows-containrar.

Även om Windows-containrar inte kan vara domänanslutna kan de fortfarande använda Active Directory-domänidentiteter för att stödja olika autentiseringsscenarier. För att uppnå detta kan du konfigurera en Windows-container så att den körs med ett grupphanterat tjänstkonto (gMSA), som är en särskild typ av tjänstkonto som introducerades i Windows Server 2012 och som utformats för att tillåta flera datorer att dela en identitet utan att behöva känna till lösenordet. Windows-containrar kan inte vara domänanslutna, men många Windows-program som körs i Windows-containrar behöver fortfarande AD-autentisering. Om du vill använda AD-autentisering kan du konfigurera en Windows-container så att den körs med ett grupphanterat tjänstkonto (gMSA).

När gMSA för Windows-containrar ursprungligen introducerades, krävde det att containervärden var domänansluten, vilket skapade mycket merarbete för användarna eftersom de manuellt behövde ansluta Windows-arbetsnoder till en domän. Den här begränsningen har åtgärdats med gMSA-stöd för Windows-containrar på icke-domänanslutna containervärdar. Vi fortsätter att stödja den ursprungliga gMSA-funktionaliteten så att den kan använda en domänansluten containervärd.

Förbättringar av gMSA när du använder en containerhost utan domänanslutning omfattar:

  • Kravet på att manuellt ansluta Windows-arbetsnoder till en domän elimineras eftersom det orsakade mycket omkostnader för användarna. För skalningsscenarier förenklar användningen av en icke-domänansluten containervärd processen.
  • I scenarier med löpande uppdateringar får användarna inte längre återansluta noden till en domän.
  • Det är enklare att hantera datorkonton för arbetsnoder för att hämta lösenord för gMSA-tjänstkonton.
  • Att konfigurera gMSA med Kubernetes är en mindre komplicerad process från slutpunkt till slutpunkt.

Not

Information om hur Kubernetes-communityn stöder användning av gMSA med Windows-containrar finns i konfigurera gMSA-.

gMSA-arkitektur och förbättringar

För att åtgärda begränsningarna i den inledande implementeringen av gMSA för Windows-containrar använder nytt gMSA-stöd för icke-domänanslutna containervärdar en bärbar användaridentitet i stället för ett värddatorkonto för att hämta gMSA-autentiseringsuppgifter. Därför är det inte längre nödvändigt att manuellt ansluta Windows-arbetsnoder till en domän, även om det fortfarande stöds. Användaridentiteten/autentiseringsuppgifterna lagras i ett hemligt arkiv som är tillgängligt för containervärden (till exempel som en Kubernetes-hemlighet) där autentiserade användare kan hämta den.

diagram över grupphanterade tjänstkonton version två

gMSA-stöd för icke-domänanslutna containervärdar ger flexibiliteten att skapa containrar med gMSA utan att ansluta värdnoden till domänen. Från och med Windows Server 2019 stöds ccg.exe som gör att en plugin-mekanism kan hämta gMSA-autentiseringsuppgifter från Active Directory. Du kan använda den identiteten för att starta containern. Mer information om den här plugin-mekanismen finns i gränssnittet ICcgDomainAuthCredentials.

Notis

I Azure Kubernetes Service på Azure Stack HCI kan du använda plugin-programmet för att kommunicera från ccg.exe till AD och sedan hämta gMSA-autentiseringsuppgifterna. Mer information finns i konfigurera grupphanterat tjänstkonto med AKS på Azure Stack HCI.

Visa diagrammet nedan för att följa stegen i Container Credential Guard-processen:

  1. Med hjälp av en CredSpec--fil som indata startas ccg.exe-processen på noden.

  2. ccg.exe använder information i filen CredSpec för att starta ett plugin-program och sedan hämta kontoautentiseringsuppgifterna i det hemliga arkivet som är associerat med plugin-programmet.

  3. ccg.exe använder autentiseringsuppgifterna för det hämtade kontot för att hämta gMSA-lösenordet från AD.

  4. ccg.exe gör gMSA-lösenordet tillgängligt för en container som har begärt autentiseringsuppgifter.

  5. Containern autentiserar till domänkontrollanten med gMSA-lösenordet för att hämta en Kerberos Ticket-Granting Ticket (TGT).

  6. Program som körs som nätverkstjänst eller lokalt system i containern kan nu autentisera och komma åt domänresurser, till exempel gMSA.

    diagram över ccg.exe process

Förutsättningar

Om du vill köra en Windows-container med ett grupphanterat tjänstkonto behöver du följande:

  • En Active Directory-domän med minst en domänkontrollant som kör Windows Server 2012 eller senare. Det finns inga krav på skogs- eller domänfunktionsnivå för att använda gMSAs, men gMSA-lösenorden kan bara distribueras av domänkontrollanter som kör Windows Server 2012 eller senare. Mer information finns i Active Directory-krav för gMSAs.
  • Behörighet att skapa ett gMSA-konto. Om du vill skapa ett gMSA-konto måste du vara domänadministratör eller använda ett konto som har fått behörigheten Skapa msDS-GroupManagedServiceAccount-objekt.
  • Åtkomst till Internet för att ladda ned CredentialSpec PowerShell-modulen. Om du arbetar i ett offlineläge kan du spara modulen på en dator som har internetanslutning och kopiera den till din utvecklingsdator eller värd för containern.

Engångsförberedelse av Active Directory

Om du inte redan har skapat en gMSA i domänen måste du generera KDS-rotnyckeln (Key Distribution Service). KDS ansvarar för att skapa, rotera och släppa gMSA-lösenordet till auktoriserade värdar. När en containervärd behöver använda gMSA för att köra en container kontaktar den KDS för att hämta det aktuella lösenordet.

Kontrollera om KDS-rotnyckeln redan har skapats genom att köra följande PowerShell-cmdlet som domänadministratör på en domänkontrollant eller domänmedlem med AD PowerShell-verktygen installerade:

Get-KdsRootKey

Om kommandot returnerar ett nyckel-ID, är du redo och kan gå vidare till avsnittet skapa ett hanterat tjänstkonto för grupper. Annars fortsätter du att skapa KDS-rotnyckeln.

Viktig

Du bör bara skapa en KDS-rotnyckel per skog. Om flera KDS-rotnycklar skapas kommer gMSA att börja misslyckas när gMSA-lösenordet har roterats.

I en produktionsmiljö eller testmiljö med flera domänkontrollanter kör du följande cmdlet i PowerShell som domänadministratör för att skapa KDS-rotnyckeln.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Även om kommandot innebär att nyckeln börjar gälla omedelbart måste du vänta 10 timmar innan KDS-rotnyckeln replikeras och är tillgänglig för användning på alla domänkontrollanter.

Om du bara har en domänkontrollant i domänen kan du påskynda processen genom att ange att nyckeln ska gälla för 10 timmar sedan.

Viktig

Använd inte den här tekniken i en produktionsmiljö.

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

Skapa ett grupphanterat tjänstkonto

Varje container som använder integrerad Windows-autentisering behöver minst en gMSA. Den primära gMSA används när appar som körs som ett system eller en nätverkstjänst får åtkomst till resurser i nätverket. Namnet på gMSA blir containerns namn i nätverket, oavsett vilket värdnamn som tilldelats containern. Containrar kan också konfigureras med ytterligare gMSA:er, om du vill köra en tjänst eller ett program i containern som en annan identitet än containerdatorkontot.

När du skapar en gMSA skapar du också en delad identitet som kan användas samtidigt på många olika datorer. Åtkomst till gMSA-lösenordet skyddas av en Active Directory-åtkomstkontrollista. Vi rekommenderar att du skapar en säkerhetsgrupp för varje gMSA-konto och lägger till relevanta containervärdar i säkerhetsgruppen för att begränsa åtkomsten till lösenordet.

Eftersom containrar inte automatiskt registrerar några tjänstens huvudnamn (SPN), måste du manuellt skapa minst ett värd-SPN för ditt gMSA-konto.

Vanligtvis registreras värd- eller http-SPN med samma namn som gMSA-kontot, men du kan behöva använda ett annat tjänstenamn om klienterna kommer åt containerapplikationen bakom en lastbalanserare eller ett DNS-namn som skiljer sig från gMSA-namnet.

Om gMSA-kontot till exempel heter "WebApp01" men användarna kommer åt webbplatsen på mysite.contoso.combör du registrera ett http/mysite.contoso.com SPN på gMSA-kontot.

Vissa program kan kräva ytterligare SPN för sina unika protokoll. SQL Server kräver till exempel MSSQLSvc/hostname SPN.

I följande tabell visas de attribut som krävs för att skapa en gMSA.

gMSA-egenskap Obligatoriskt värde Exempel
Namn Valfritt giltigt kontonamn. WebApp01
DNS-värdnamn Domännamnet som läggs till i kontonamnet. WebApp01.contoso.com
Tjänstehuvudnamn Ange minst värd-SPN och lägg till andra protokoll efter behov. 'host/WebApp01', 'host/WebApp01.contoso.com'
Principaler som tillåts hämta hanterade lösenord Säkerhetsgruppen som innehåller dina containernoder. WebApp01Hosts

När du har bestämt dig för namnet på din gMSA kör du följande cmdletar i PowerShell för att skapa säkerhetsgruppen och gMSA.

Tips

Du måste använda ett konto som tillhör säkerhetsgruppen Domänadministratörer eller som har fått behörigheten Skapa msDS-GroupManagedServiceAccount-objekt delegerad för att köra följande kommandon. Cmdleten New-ADServiceAccount är en del av AD PowerShell-verktygen från Verktyg för fjärrserveradministration.

Vi rekommenderar att du skapar separata gMSA-konton för dina utvecklings-, test- och produktionsmiljöer.

Användningsfall för att skapa gMSA-konto för domänanslutna containervärdar

# 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$"

Användningsfall för att skapa gMSA-konto för icke-domänanslutna containervärdar

När du använder gMSA för containrar med icke-domänanslutna värdar skapar och lägger du till ett standardanvändarkonto i stället för att lägga till containervärdar i säkerhetsgruppen WebApp01Hosts.

# 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"

Förbereda containervärden

Användningsfall för att förbereda en containervärd för en domänansluten containervärd

Varje containervärd som ska köra en Windows-container med en gMSA måste vara domänansluten och ha åtkomst till att hämta gMSA-lösenordet.

  1. Anslut datorn till active directory-domänen.

  2. Se till att värden tillhör säkerhetsgruppen som kontrollerar åtkomsten till gMSA-lösenordet.

  3. Starta om datorn för att få sitt nya gruppmedlemskap.

  4. Konfigurera Docker Desktop för Windows 10 eller Docker för Windows Server.

  5. (Rekommenderas) Kontrollera att hosten kan använda gMSA-kontot genom att köra Test-ADServiceAccount. Om kommandot returnerar Falseföljer du felsökningsanvisningarna.

    # 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
    

Användningsfall för att förbereda containervärden för en icke-domänansluten containervärd

När du använder gMSA för Windows-containrar på icke-domänanslutna containervärdar måste varje containervärd ha ett plugin-program för ccg.exe installerat som ska användas för att hämta det bärbara användarkontot och autentiseringsuppgifterna som angavs i föregående steg. Plug-ins är unika för det hemliga lagret som används för att skydda bärbara användarkontots autentiseringsuppgifter. Till exempel skulle olika plugin-program behövas för att lagra kontoautentiseringsuppgifter i Azure Key Vault jämfört med i ett Kubernetes-hemligt arkiv.

Windows erbjuder för närvarande inte ett inbyggt standard-plugin-program. Installationsinstruktioner för plugin-program kommer att vara implementeringsspecifika. Mer information om hur du skapar och registrerar plugin-program för ccg.exefinns i ICcgDomainAuthCredentials-gränssnittet.

Skapa en autentiseringsspecifikation

En autentiseringsspecifikationsfil är ett JSON-dokument som innehåller metadata om de gMSA-konton som du vill att en container ska använda. Genom att hålla identitetskonfigurationen separat från containeravbildningen kan du ändra vilken gMSA containern använder genom att helt enkelt byta autentiseringsspecifikationsfilen, inga kodändringar krävs.

Autentiseringsspecifikationsfilen skapas med hjälp av powershell-modulen CredentialSpec på en domänansluten dator. När du har skapat filen kan du kopiera den till andra containervärdar eller till din containerorkestrerare. Specifikationsfilen för autentiseringsuppgifter innehåller inga hemligheter, till exempel gMSA-lösenordet, eftersom containervärden hämtar gMSA för containerns räkning.

Docker förväntar sig att hitta autentiseringsspecifikationsfilen under katalogen CredentialSpecs i Docker-datakatalogen. I en standardinstallation hittar du den här mappen på C:\ProgramData\Docker\CredentialSpecs.

För att skapa en credentialspecifikationsfil på din containervärd:

  1. Installera RSAT AD PowerShell-verktygen

    • För Windows Server kör du Install-WindowsFeature RSAT-AD-PowerShell.
    • För Windows 10 version 1809 eller senare kör du Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0".
    • För äldre versioner av Windows 10, se https://aka.ms/rsat.
  2. Kör följande cmdlet för att installera den senaste versionen av CredentialSpec PowerShell-modulen:

    Install-Module CredentialSpec
    

    Om du inte har internetåtkomst på containervärden kör du Save-Module CredentialSpec på en Internetansluten dator och kopierar modulmappen till C:\Program Files\WindowsPowerShell\Modules eller till en annan plats i $env:PSModulePath på containervärden.

  3. Kör följande cmdlet för att skapa den nya autentiseringsspecifikationsfilen:

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

    Som standard skapar cmdleten en autentiseringsspecifikation med det angivna gMSA-namnet som datorkonto för containern. Filen sparas i katalogen Docker CredentialSpecs med hjälp av gMSA-domänen och kontonamnet för filnamnet.

    Om du vill spara filen i en annan katalog använder du parametern -Path:

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

    Du kan också skapa en autentiseringsspecifikation som innehåller ytterligare gMSA-konton om du kör en tjänst eller process som en sekundär gMSA i containern. Det gör du genom att använda parametern -AdditionalAccounts:

    New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
    

    Om du vill ha en fullständig lista över parametrar som stöds kör du Get-Help New-CredentialSpec -Full.

  4. Du kan visa en lista över alla autentiseringsspecifikationer och deras fullständiga sökväg med följande cmdlet:

    Get-CredentialSpec
    

Det här är ett exempel på en 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"
            }
        ]
    }
}

Ytterligare autentiseringsspecifikationskonfiguration för användningsfall för icke-domänanslutna containervärdar

När du använder gMSA med icke-domänanslutna containervärdar måste information om det ccg.exe plugin-programmet som du använder läggas till i autentiseringsspecifikationen. Detta läggs till i ett avsnitt i autentiseringsspecifikationen med namnet HostAccountConfig. Avsnittet HostAccountConfig innehåller tre fält som måste fyllas i:

  • PortableCcgVersion: Detta bör vara inställt på "1".
  • PluginGUID: COM CLSID för ccg.exe tillägget. Detta är unikt för plugin-programmet som används.
  • InsticksprogramInmatning: Insticksprogramspecifik inmatning för att hämta användarkontoinformationen från hemlighetslagringen.

Det här är ett exempel på en autentiseringsspecifikation med avsnittet HostAccountConfig lagt till:

{
    "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ästa steg

Nu när du har konfigurerat ditt gMSA-konto kan du använda det för att:

Om du stöter på problem under installationen kan du läsa vår felsökningsguide för efter möjliga lösningar.

Ytterligare resurser