Skip to main content

Creating a managed service account with PowerShell DSC fails: The KDS Root Key was not found

At the moment I am busy with automating the creation of a Windows 2019 server with the Active Directory role enabled. My PowerShell DSC script is hosted in Azure Automation wich acts as the pull server. The script is installing the Active Directory role and configuring the domain. During my initial test I got the following error when the script tries to create a Managed Service Account.

System.InvalidOperationException: Error adding group account 'gMSA-ADSync'. The KDS Root Key was not found. (MSA0019)
Microsoft.ActiveDirectory.Management.ADException: Key does not exist
System.ServiceModel.FaultException: Active Directory returned an error processing the operation.

After doing some research I found out what the reason for this is. According the Microsoft documentation the reason for this behavior is as follows:

Domain Controllers (DC) require a root key to begin generating gMSA passwords. The domain controllers will wait up to 10 hours from time of creation to allow all domain controllers to converge their AD replication before allowing the creation of a gMSA. The 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering gMSA requests. If you try to use a gMSA too soon the key might not have been replicated to all domain controllers and therefore password retrieval might fail when the gMSA host attempts to retrieve the password. gMSA password retrieval failures can also occur when using DCs with limited replication schedules or if there is a replication issue.

For test environments with only one DC, you can create a KDS root key and set the start time in the past to avoid the interval wait for key generation by using the following PowerShell command:

Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))

I added the following Script block to my Active Directory DSC script to automate this.

Script "KDSRootKey"
{
	SetScript = {
		Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))
	}
	GetScript = { @{} }
	TestScript = {
		$rootKey = Get-KdsRootKey -ErrorAction SilentlyContinue

		if ($null -eq $rootKey) {
			return $false
		} else {
			return $true
		}
	}
}

Comments

Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Deploy with ARM templates an Azure DevTest Lab environment

Within the company I work for we use Azure DevTest Labs already for a year to host our personal development computer and the BizTalk CI machines we need. We are planning to host also our development and test environments in Lab environments. At the moment we configure the lab environments manually. I invested some time to write ARM templates to deploy Azure DevTest Labs within 5 minutes based on Azure DevOps CI/CD pipelines. In the process of writing these scripts I learned a lot. For example that the Azure documentation is not always up to date and that includes also tooling like Azure Resource Explorer . Based on querying the REST API with Postman I found the missing pieces for deploying a DevTest Lab environment based on nested ARM templates. In this post I will document the nested ARM template I created the last few days. Lab With the first template you can create the lab environment itself and configure the following parts of the environment Lab settings; like the st