Tworzenie agentów gMSA dla kontenerów systemu Windows

Artykuł
01/27/2025

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019

Sieci oparte na systemie Windows często używają usługi Active Directory (AD) do ułatwienia uwierzytelniania i autoryzacji między użytkownikami, komputerami i innymi zasobami sieciowymi. Deweloperzy aplikacji dla przedsiębiorstw często projektują swoje aplikacje jako zintegrowane z usługą AD i działają na serwerach przyłączonych do domeny, aby korzystać ze zintegrowanego uwierzytelniania systemu Windows, co ułatwia użytkownikom i innym usługom automatyczne i przejrzyste logowanie się do aplikacji przy użyciu ich tożsamości. W tym artykule wyjaśniono, jak rozpocząć korzystanie z kont usług zarządzanych przez grupę usługi Active Directory z kontenerami systemu Windows.

Mimo że kontenery systemu Windows nie mogą być przyłączone do domeny, nadal mogą używać tożsamości domeny usługi Active Directory do obsługi różnych scenariuszy uwierzytelniania. Aby to osiągnąć, można skonfigurować kontener systemu Windows do uruchamiania przy użyciu konta usługi zarządzanej grupy (gMSA), który jest specjalnym typem konta usługi wprowadzonego w systemie Windows Server 2012 i zaprojektowany tak, aby umożliwić wielu komputerom współużytkowanie tożsamości bez konieczności znajomości hasła. Nie można przyłączyć kontenerów systemu Windows do domeny, ale wiele aplikacji systemu Windows uruchomionych w kontenerach systemu Windows nadal wymaga uwierzytelniania usługi AD. Aby użyć uwierzytelniania usługi AD, można skonfigurować kontener systemu Windows do uruchamiania przy użyciu konta usługi zarządzanej przez grupę (gMSA).

Gdy usługa gMSA dla kontenerów systemu Windows została początkowo wprowadzona, wymagała, aby host kontenera został przyłączony do domeny, co spowodowało duże obciążenie dla użytkowników związane z ręcznym dołączaniem węzłów roboczych systemu Windows do domeny. To ograniczenie zostało rozwiązane dzięki wsparciu dla kontenerów systemu Windows przy użyciu usługi gMSA, dedykowanej hostom kontenerów, które nie są przyłączone do domeny. Będziemy nadal wspierać oryginalną funkcjonalność gMSA do korzystania z hosta kontenera przyłączonego do domeny.

Ulepszenia usługi gMSA w przypadku korzystania z nieprzyłączonego do domeny hosta kontenera obejmują:

Wymaganie ręcznego dołączania węzłów roboczych systemu Windows do domeny zostało wyeliminowane, ponieważ spowodowało to duże obciążenie dla użytkowników. W przypadku scenariuszy skalowania użycie hosta kontenera nieprzyłączonego do domeny upraszcza proces.
W scenariuszach aktualizacji stopniowej użytkownicy nie muszą już ponownie dołączać węzła do domeny.
Zarządzanie kontami maszyn węzłów roboczych w celu uzyskania haseł do kont usługi gMSA jest łatwiejsze.
Konfigurowanie gMSA przy użyciu platformy Kubernetes jest mniej skomplikowanym całościowym procesem.

Notatka

Aby dowiedzieć się, jak społeczność Kubernetes obsługuje używanie gMSA z kontenerami systemu Windows, zobacz konfigurowanie gMSA.

Architektura i ulepszenia usługi gMSA

Aby rozwiązać problem z ograniczeniami początkowej implementacji gMSA dla kontenerów systemu Windows, nowa obsługa gMSA dla hostów kontenerów nieprzyłączonych do domeny używa przenośnej tożsamości użytkownika zamiast konta komputera hosta w celu pobrania poświadczeń gMSA. W związku z tym ręczne dołączanie węzłów roboczych systemu Windows do domeny nie jest już konieczne, chociaż nadal jest obsługiwane. Tożsamość użytkownika/poświadczenia są przechowywane w magazynie tajnym dostępnym dla hosta kontenera (na przykład jako wpis tajny Kubernetes), gdzie uwierzytelnieni użytkownicy mogą je pobrać.

Diagram kont usług zarządzanych przez grupę w wersji 2

Obsługa gMSA dla hostów kontenerów nieprzyłączonych do domeny zapewnia elastyczność tworzenia kontenerów, wykorzystując gMSA, bez przyłączania węzła hosta do domeny. Począwszy od systemu Windows Server 2019, obsługiwane jest ccg.exe, co umożliwia użycie mechanizmu wtyczki do pobierania poświadczeń gMSA z usługi Active Directory. Tej tożsamości można użyć do uruchomienia kontenera. Aby uzyskać więcej informacji na temat tego mechanizmu wtyczek, zobacz interfejs ICcgDomainAuthCredentials.

Notatka

W usłudze Azure Kubernetes Service w usłudze Azure Stack HCI możesz użyć wtyczki do komunikowania się z ccg.exe do usługi AD, a następnie pobrać poświadczenia gMSA. Aby uzyskać więcej informacji, zobacz konfigurowanie konta usługi zarządzanej przez grupę za pomocą usługi AKS w usłudze Azure Stack HCI.

Zapoznaj się z poniższym diagramem, aby wykonać kroki procesu container Credential Guard:

Używając pliku CredSpec jako danych wejściowych, proces ccg.exe jest uruchamiany na węźle hosta.
ccg.exe używa informacji w pliku CredSpec, aby uruchomić dodatek, a następnie pobrać poświadczenia konta w magazynie tajnym skojarzonym z dodatkiem.
ccg.exe używa pobranych poświadczeń konta, aby pobrać hasło gMSA z AD.
ccg.exe udostępnia hasło gMSA kontenerowi, który zażądał poświadczeń.
Kontener uwierzytelnia się do kontrolera domeny przy użyciu hasła gMSA, aby uzyskać bilet Kerberos Ticket-Granting (TGT).
Aplikacje uruchomione jako usługa sieciowa lub system lokalny w kontenerze mogą teraz uwierzytelniać się i uzyskiwać dostęp do zasobów domeny, takie jak gMSA.

diagram

Warunki wstępne

Aby uruchomić kontener systemu Windows przy użyciu konta usługi zarządzanej przez grupę, potrzebne są następujące elementy:

Domena usługi Active Directory z co najmniej jednym kontrolerem domeny z systemem Windows Server 2012 lub nowszym. Nie ma żadnych wymagań dotyczących poziomu funkcjonalności lasu lub domeny do używania zarządzanych kont usług grupowych (gMSA), ale hasła gMSA mogą być dystrybuowane tylko przez kontrolery domeny z systemem Windows Server 2012 lub nowszym. Aby uzyskać więcej informacji, zobacz wymagania usługi Active Directory dotyczące konta usług gMSA.
Uprawnienie do tworzenia konta gMSA. Aby utworzyć konto gMSA, musisz być administratorem domeny lub używać konta, które ma przypisane uprawnienie Create msDS-GroupManagedServiceAccount objects.
Dostęp do Internetu w celu pobrania modułu CredentialSpec programu PowerShell. Jeśli pracujesz w środowisku odłączonym, możesz zapisać moduł na komputerze z dostępem do Internetu i skopiować go na maszynę deweloperową lub hosta kontenera.

Jednorazowe przygotowanie usługi Active Directory

Jeśli w domenie nie utworzono jeszcze konta zarządzanego przez użytkownika, musisz wygenerować klucz główny usługi dystrybucji kluczy (KDS). Usługa KDS jest odpowiedzialna za tworzenie, rotację i wydawanie hasła gMSA do autoryzowanych hostów. Gdy host kontenera musi użyć gMSA do uruchomienia kontenera, skontaktuje się z KDS, aby pobrać bieżące hasło.

Aby sprawdzić, czy klucz główny KDS został już utworzony, uruchom następujące polecenie cmdlet PowerShell jako administrator domeny na kontrolerze domeny lub członku domeny z zainstalowanymi narzędziami AD PowerShell.

Get-KdsRootKey

Jeśli polecenie zwróci identyfikator klucza, wszystko jest gotowe i można przejść do sekcji dotyczącej tworzenia konta usługi zarządzanej przez grupę. W przeciwnym razie przejdź do tworzenia klucza głównego KDS.

Ważny

Należy utworzyć tylko jeden główny klucz KDS dla każdego lasu. Jeśli zostanie utworzonych wiele kluczy głównych KDS, doprowadzi to do tego, że gMSA zacznie zawodzić po rotacji hasła gMSA.

W środowisku produkcyjnym lub środowisku testowym z wieloma kontrolerami domeny uruchom następujące polecenie cmdlet w programie PowerShell jako administrator domeny, aby utworzyć klucz główny KDS.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Mimo że polecenie oznacza, że klucz będzie obowiązywać natychmiast, musisz poczekać 10 godzin, zanim klucz główny KDS zostanie zreplikowany i będzie dostępny do użycia na wszystkich kontrolerach domeny.

Jeśli masz tylko jeden kontroler domeny w domenie, możesz przyspieszyć ten proces, ustawiając klucz tak, aby był skuteczny 10 godzin temu.

Ważny

Nie używaj tej techniki w środowisku produkcyjnym.

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

Tworzenie konta usługi zarządzanego przez grupę

Każdy kontener korzystający ze zintegrowanego uwierzytelniania systemu Windows musi mieć co najmniej jedną gMSA. Podstawowy gMSA jest używany za każdym razem, gdy aplikacje działające jako system lub usługa sieciowa uzyskują dostęp do zasobów w sieci. Nazwa grupowego konta zarządzanego (gMSA) będzie nazwą kontenera w sieci, niezależnie od przypisanej do niego nazwy hosta. Kontenery można także skonfigurować z dodatkowymi grupowymi zarządzanymi kontami usług (gMSA), jeśli chcesz uruchomić usługę lub aplikację w kontenerze pod inną tożsamością niż konto komputera kontenera.

Podczas tworzenia gMSA należy również utworzyć tożsamość współdzieloną, która może być używana jednocześnie na wielu różnych maszynach. Dostęp do hasła gMSA jest chroniony przez listę kontroli dostępu usługi Active Directory. Zalecamy utworzenie grupy zabezpieczeń dla każdego konta gMSA i dodanie odpowiednich hostów kontenerów do grupy zabezpieczeń w celu ograniczenia dostępu do hasła.

Na koniec, ponieważ kontenery nie rejestrują automatycznie żadnych głównych nazw usług (SPN), należy ręcznie utworzyć co najmniej nazwę SPN hosta dla konta usługi gMSA.

Zazwyczaj host lub nazwa SPN http jest rejestrowana przy użyciu tej samej nazwy co konto gMSA, ale może być konieczne użycie innej nazwy usługi, jeśli klienci uzyskują dostęp do konteneryzowanej aplikacji zza modułu równoważenia obciążenia lub nazwy DNS, która różni się od nazwy gMSA.

Jeśli na przykład konto usługi gMSA nosi nazwę "WebApp01", ale użytkownicy uzyskują dostęp do witryny w mysite.contoso.com, należy zarejestrować SPN http/mysite.contoso.com na koncie gMSA.

Niektóre aplikacje mogą wymagać dodatkowych nazw SPN dla swoich unikatowych protokołów. Na przykład program SQL Server wymaga nazwy SPN MSSQLSvc/hostname.

W poniższej tabeli wymieniono wymagane atrybuty do utworzenia gMSA.

właściwość gMSA	Wymagana wartość	Przykład
Nazwa	Dowolna prawidłowa nazwa konta.	`WebApp01`
DnsHostName	Nazwa domeny dołączona do nazwy konta.	`WebApp01.contoso.com`
NazwyUsługPrincipala	Ustaw co najmniej nazwę SPN hosta, dodaj inne protokoły w razie potrzeby.	`'host/WebApp01', 'host/WebApp01.contoso.com'`
PodmiotyUprawnioneDoPobraniaZarządzanegoHasła	Grupa zabezpieczeń zawierająca hosty kontenerów.	`WebApp01Hosts`

Po wybraniu nazwy dla gMSA, uruchom następujące polecenia cmdlet w programie PowerShell, aby utworzyć grupę zabezpieczeń i gMSA.

Napiwek

Musisz użyć konta należącego do grupy zabezpieczeń Administratorzy domeny lub takiego, które ma delegowane uprawnienie tworzenia obiektów msDS-GroupManagedServiceAccount, aby uruchomić następujące polecenia. Polecenie cmdlet New-ADServiceAccount jest częścią narzędzi AD PowerShell z Narzędzi do Zdalnej Administracji Serwerem .

Zalecamy utworzenie oddzielnych kont gMSA dla środowisk deweloperskich, testowych i produkcyjnych.

Przypadek użycia tworzenia konta usługi gMSA dla hostów kontenerów przyłączonych do domeny

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

Przypadek użycia tworzenia konta gMSA dla hostów kontenerów nieprzyłączonych do domeny

W przypadku korzystania z usługi gMSA dla kontenerów z hostami nieprzyłączonych do domeny zamiast dodawania hostów kontenerów do grupy zabezpieczeń WebApp01Hosts utwórz i dodaj standardowe konto użytkownika.

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

Przygotowywanie hosta kontenera

Scenariusz przygotowywania hosta kontenera do integracji z domeną.

Każdy host kontenera, który będzie uruchamiał kontener systemu Windows z gMSA musi być przyłączony do domeny i mieć dostęp do pobierania hasła gMSA.

Dołącz komputer do domeny usługi Active Directory.
Upewnij się, że host należy do grupy zabezpieczeń kontrolującej dostęp do hasła gMSA.
Uruchom ponownie komputer, aby uzyskać nowe członkostwo w grupie.
Skonfiguruj Docker Desktop dla systemu Windows 10 lub Docker for Windows Server.

(Zalecane) Sprawdź, czy host może używać konta gMSA, uruchamiając Test-ADServiceAccount. Jeśli polecenie zwróci false, postępuj zgodnie z instrukcjami rozwiązywania problemów .

# 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

Przypadek użycia przygotowania hosta kontenera, który nie jest przyłączony do domeny

W przypadku korzystania z usługi gMSA dla kontenerów systemu Windows na hostach kontenerów nieprzyłączonych do domeny każdy host kontenera musi mieć zainstalowaną wtyczkę dla ccg.exe, która będzie używana do pobierania przenośnego konta użytkownika i poświadczeń określonych w poprzednim kroku. Wtyczki są unikatowe dla magazynu wpisów tajnych używanych do ochrony poświadczeń konta użytkownika mobilnego. Na przykład różne wtyczki będą potrzebne do przechowywania poświadczeń konta w Azure Key Vault niż w sklepie tajemnic Kubernetes.

System Windows nie oferuje obecnie wbudowanej, domyślnej wtyczki. Instrukcje instalacji wtyczek będą specyficzne dla implementacji. Aby uzyskać więcej informacji na temat tworzenia i rejestrowania wtyczek dla ccg.exe, zobacz interfejs ICcgDomainAuthCredentials.

Tworzenie specyfikacji poświadczeń

Plik specyfikacji poświadczeń to dokument JSON zawierający metadane dotyczące kont gMSA, które mają być używane przez kontener. Dzięki oddzieleniu konfiguracji tożsamości od obrazu kontenera, można zmienić, z którego gMSA korzysta kontener, po prostu zamieniając plik specyfikacji poświadczeń — nie są potrzebne żadne zmiany w kodzie.

Plik specyfikacji poświadczeń jest tworzony przy użyciu modułu CredentialSpec programu PowerShell na maszynie przyłączonej do domeny. Po utworzeniu pliku możesz skopiować go na inne hosty kontenerów lub do orkiestratora kontenerów. Plik specyfikacji poświadczeń nie zawiera żadnych wpisów tajnych, takich jak hasło gMSA, ponieważ host kontenera pobiera gMSA w imieniu kontenera.

Platforma Docker oczekuje znalezienia pliku specyfikacji poświadczeń w katalogu CredentialSpecs w katalogu danych platformy Docker. W domyślnej instalacji ten folder znajduje się w C:\ProgramData\Docker\CredentialSpecs.

Aby utworzyć plik specyfikacji poświadczeń na hoście kontenera:

Instalowanie narzędzi programu PowerShell usługi RSAT AD
- W systemie Windows Server uruchom Install-WindowsFeature RSAT-AD-PowerShell.
- W przypadku systemu Windows 10 w wersji 1809 lub nowszej uruchom polecenie Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~0.0.1.0".
- Aby uzyskać informacje o starszych wersjach systemu Windows 10, zobacz https://aka.ms/rsat.
Uruchom następujące polecenie cmdlet, aby zainstalować najnowszą wersję modułu CredentialSpec programu PowerShell:
```
Install-Module CredentialSpec
```
Jeśli nie masz dostępu do Internetu na hoście kontenera, uruchom Save-Module CredentialSpec na komputerze połączonym z Internetem i skopiuj folder modułu do C:\Program Files\WindowsPowerShell\Modules lub do innej lokalizacji w $env:PSModulePath na hoście kontenera.
Uruchom następujące polecenie cmdlet, aby utworzyć nowy plik specyfikacji poświadczeń:
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
Domyślnie polecenie cmdlet utworzy specyfikację poświadczeń, używając podanej nazwy gMSA jako konta komputerowego używanego przez kontener. Plik zostanie zapisany w katalogu Docker CredentialSpecs przy użyciu domeny gMSA i nazwy konta dla nazwy pliku.

Jeśli chcesz zapisać plik w innym katalogu, użyj parametru -Path:
```
New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
```
Możesz również utworzyć specyfikację poświadczeń, która obejmuje dodatkowe konta gMSA, jeśli uruchamiasz usługę lub proces jako dodatkowe gMSA w kontenerze. W tym celu użyj parametru -AdditionalAccounts:
```
New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
```
Aby uzyskać pełną listę obsługiwanych parametrów, uruchom Get-Help New-CredentialSpec -Full.
Możesz wyświetlić listę wszystkich specyfikacji poświadczeń i ich pełną ścieżkę za pomocą następującego polecenia cmdlet:
```
Get-CredentialSpec
```

Oto przykład specyfikacji poświadczeń:

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

Dodatkowa konfiguracja specyfikacji poświadczeń dla przypadku użycia hosta kontenera niepodłączonych do domeny

Podczas korzystania z gMSA na hostach kontenerów nieprzyłączonych do domeny informacje o wtyczce ccg.exe, której używasz, należy dodać do specyfikacji poświadczeń. To zostanie dodane do sekcji specyfikacji poświadczeń o nazwie HostAccountConfig. Sekcja HostAccountConfig zawiera trzy pola, które należy wypełnić:

PortableCcgVersion: należy ustawić na "1".
PluginGUID: COM CLSID dla wtyczki ccg.exe. Jest to unikatowe dla używanej wtyczki.
PluginInput: dane wejściowe specyficzne dla wtyczki służące do pobierania informacji o koncie użytkownika z przechowalni tajemnic.

Jest to przykład specyfikacji poświadczeń z dodaną sekcją HostAccountConfig:

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

Następne kroki

Po skonfigurowaniu konta usługi gMSA możesz go użyć do:

Jeśli podczas instalacji wystąpią jakiekolwiek problemy, zapoznaj się z naszym przewodnikiem rozwiązywania problemów , aby uzyskać możliwe rozwiązania.

Dodatkowe zasoby

Aby dowiedzieć się więcej o kontach gMSA, zobacz omówienie kont usług zarządzanych przez grupę .

Udostępnij za pośrednictwem

Tworzenie agentów gMSA dla kontenerów systemu Windows

Architektura i ulepszenia usługi gMSA

Warunki wstępne

Jednorazowe przygotowanie usługi Active Directory

Tworzenie konta usługi zarządzanego przez grupę

Przypadek użycia tworzenia konta usługi gMSA dla hostów kontenerów przyłączonych do domeny

Przypadek użycia tworzenia konta gMSA dla hostów kontenerów nieprzyłączonych do domeny

Przygotowywanie hosta kontenera

Scenariusz przygotowywania hosta kontenera do integracji z domeną.

Przypadek użycia przygotowania hosta kontenera, który nie jest przyłączony do domeny

Tworzenie specyfikacji poświadczeń

Dodatkowa konfiguracja specyfikacji poświadczeń dla przypadku użycia hosta kontenera niepodłączonych do domeny

Następne kroki

Dodatkowe zasoby

Opinia

Dodatkowe zasoby