Create a Container with Active Directory Support


Windows Containers don’t ship with Active Directory support and due to their nature can’t (yet) act as a full-fledged domain joined objects, but a certain level of Active Directory functionality can be supported through the use of Globally Manages Service Accounts (gMSA).

An introduction to gMSA can be found here: https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/

The gMSA is used to create a ‘CredentialSpec’ which is passed into the container at run time. Any process running on the container under the context of ‘Local Service’ will then present the domain creds of the gMSA to any domain joined service to which it connects. For example: you could run a Windows Service on a Container using a domain account to access a secure SQL server.

An introduction to gMSA use on Windows Containers can be found here:  https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts

Step by Step

Obtain a gMSA Note: In this example we assume the name of the gMSA is adoncontt1. In the likely event that your gMSA has a different name, be sure to place each instance of adoncontt1 in this example with the name of your gMSA.

On the container host console

– Open Admin PowerShell
– Install AD features

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory

– Create the c:\data directory

mkdir c:\data
Cd c:\data

– Fetch CredentialSpec.psm1 script (see below) and place a copy in c:\data

– Create the credential spec

Import-Module ./CredentialSpec.psm1
New-CredentialSpec -Name adoncontt1 -AccountName adoncontt1

– Verify the credential spec

Get-CredentialSpec

Start the Container

Active Directory support is enabled in containers by providing the name of the credentialspec (created above) in the –security-opt option in the docker run command as shown below. In this case the name of the credentialspec is adoncontt1

– Run the container interactively

docker run -it --security-opt "credentialspec=file://adoncontt1.json" microsoft/windowsservercore

Wait for container console shell to start

On the container console

Test AD access <if using AD>

nltest /parentdomain

At his point, if no errors occurred, the LocalSystem account on the container will be a proxy for the configured gMSA account. Any process run as the LocalSystem principal on the container will appear to be the gMSA principal to all assets on the Active Directory domain.

CredentialSpec Source

You may locate the latest version of CredentialSpec.psm1 at Virtualization-Documentation. After cloning a local Git repo the file will be located at <local repo>\Virtualization-Documentation\windows-server-container-tools\ServiceAccounts\CredentialSpec.psm1

The latest version as of 1/30/2017 is provided here for reference:

# This requires the ActiveDirectory module. Run Add-WindowsFeature rsat-ad-powershell to install it
Import-Module ActiveDirectory
$Script:CredentialSpecPath="$($env:ProgramData)\Docker\CredentialSpecs"

function New-CredentialSpec
{
param(
[Parameter(Mandatory=$true)] [String] $Name,
[Parameter(Mandatory=$true)] [String] $AccountName,
[Parameter(Mandatory=$false)] [Microsoft.ActiveDirectory.Management.ADDomain] $Domain = (Get-ADDomain),
[Parameter(Mandatory=$false)] $AdditionalAccounts
)

# TODO: verify $Script:CredentialSpecPath exists

# Start hash table for output
$output = @{}

# Create ActiveDirectoryConfig Object
$output.ActiveDirectoryConfig = @{}
$output.ActiveDirectoryConfig.GroupManagedServiceAccounts = @( @{“Name” = $AccountName; “Scope” = $Domain.DNSRoot } )
$output.ActiveDirectoryConfig.GroupManagedServiceAccounts += @{“Name” = $AccountName; “Scope” = $Domain.NetBIOSName }
if ($AdditionalAccounts) {
$AdditionalAccounts | ForEach-Object {
$output.ActiveDirectoryConfig.GroupManagedServiceAccounts += @{“Name” = $_.AccountName; “Scope” = $_.DomainName }
}
}

# Create CmsPlugins Object
$output.CmsPlugins = @(“ActiveDirectory”)

# Create DomainJoinConfig Object
$output.DomainJoinConfig = @{}
$output.DomainJoinConfig.DnsName = $Domain.Forest
$output.DomainJoinConfig.Guid = $Domain.ObjectGUID
$output.DomainJoinConfig.DnsTreeName = $Domain.DNSRoot
$output.DomainJoinConfig.NetBiosName = $Domain.NetBIOSName
$output.DomainJoinConfig.Sid = $Domain.DomainSID.Value
$output.DomainJoinConfig.MachineAccountName = $AccountName

$output | ConvertTo-Json -Depth 5 | Out-File -FilePath “$($Script:CredentialSpecPath)\\$($Name).json” -encoding ascii
}

function Get-CredentialSpec
{
Get-ChildItem $Script:CredentialSpecPath | Select-Object @{
Name=’Name’
Expression = { $_.BaseName }
},
@{
Name=’Path’
Expression = { $_.FullName }
}
}


Comments (2)

  1. Neeraj says:

    Hello Mark , thanks for this blog this has been very useful. Does this also apply to IIS web applications running inside a container? if not how do we get as IIS web application to run under a domain identity to access network resources and also provide support for windows authentication.

    1. Hi Neeraj:

      The post as it stands today does apply to IIS apps, it will for instance give you everything you need to have your IIS app provide AD creds to access a domain guarded resource, like a SQL server.

      Special configuration of the gMSA and explicit naming of the container is required for support of Windows Auth in IIS apps on containers. I worked this out some time ago and I apologize that it is taking me so long to publish. I will try to get it out today or tomorrow.

Skip to main content