In our environment, we use several gMSA accounts, which are more secure than conventional service accounts. While testing our scripts on Windows Server 2025, we ran into issues when installing a gMSA.
Install-ADServiceAccount : Cannot install service account. Error Message: ‘The provided context did not match the target.’
We began by double checking the gMSA itself. To rule out account issues, we tested installing the gMSA on an older Windows Server 2022 system, where everything worked as expected. Next, we checked the PrincipalsAllowedToRetrieveManagedPassword attribute using:
Read more: Troubleshooting gMSA Installation Failure Caused by Kerberos Encryption Mismatch (28 vs 24)
Get-ADServiceAccount -Identity 'gMSA Accountname' -Properties PrincipalsAllowedToRetrieveManagedPassword
This confirmed that the Windows Server 2025 host was authorized to use the gMSA. We also noticed that the affected gMSAs failed the following test:
Test-ADServiceAccount -Identity 'gMSA Accountname'
On Windows Server 2025, this command returned False, indicating the account could not be used successfully.
It took us a while to realize the issue was encryption related. The security baseline on Windows Server 2025 differed from that of Server 2022. The policy “Network security: Configure encryption types allowed for Kerberos“
(Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options)
was configured to allow only AES128_HMAC_SHA1 and AES256_HMAC_SHA1. The option “Future encryption types” is reserved for potential new Kerberos encryption algorithms that may be introduced in future Windows versions. It does not specifically include AES128 or AES256, as these have their own settings.
When we temporarily added RC4_HMAC_MD5 to the allowed list, we were able to install the gMSA successfully. But this raised a red flag, why lower security just to get a gMSA to install? First, we checked the current encryption level on our new Windows Server 2025 using:
Get-ADComputer -Identity $env:COMPUTERNAME -Properties msDS-SupportedEncryptionTypes | Select Name, msDS-SupportedEncryptionTypes
Next, we checked the gMSA itself using:
Get-ADServiceAccount -Identity 'Serviceaccount' -Properties msDS-SupportedEncryptionTypes | Select Name, msDS-SupportedEncryptionTypes
We noticed a mismatch between the server and the gMSA. The server was set to 24, while the gMSA was set to 28. To clarify the relevant Kerberos encryption bitmask values:
- RC4 = 4
- AES128 = 8
- AES256 = 16
- AES-only (AES128 + AES256) = 24
- AES + RC4 = 28
Note: A value of 0 or null means “follow the domain/GPO default,” which often still allows RC4.
In short, Windows Server 2025 was enforcing AES only, while the gMSA was configured for AES + RC4.
This was the most confusing part for us. We initially assumed that if RC4 wasn’t available on the server, Kerberos would simply fall back to AES after all, the gMSA was also capable of AES. However, Kerberos doesn’t really “negotiate” in this scenario. The Key Distribution Center (KDC) selects one encryption type based on what the gMSA allows. If RC4 is enabled on the gMSA, the KDC may choose RC4. If the client (server) is AES only and doesn’t accept RC4, there is no fallback to AES and the operation just fails.Since we didn’t want to lower our security baseline, we decided to update the affected gMSAs to AES-only by running:
Set-ADServiceAccount -Identity 'gMSA Accountname' -KerberosEncryptionType AES128,AES256
After running the command above, the gMSA’s encryption type changed from 28 to 24. We also reviewed the creation process for new gMSAs. By default, they were still being created with AES + RC4, which we already knew would not work on Windows Server 2025. To address this, we added the -KerberosEncryptionType parameter to the New-ADServiceAccount command so that new gMSAs are created with AES only. Just like computer accounts, their passwords are random, complex, and change every 30 days by default
New-ADServiceAccount -Name 'gMSA Accountname' -DNSHostName 'hostname.domain.local' -PrincipalsAllowedToRetrieveManagedPassword 'AllowedGroupOrServer' -KerberosEncryptionType AES128,AES256
The last thing we looked into and tested was the behavior of an AES only gMSA when installed on a Windows Server 2022 system that still allowed AES + RC4. In this scenario, even though the server permitted RC4, the AES only gMSA worked without any issues. This confirmed that all gMSAs we had updated to AES-only (EncryptionTypes 24) continued to function on legacy Windows Server 2022 hosts configured with AES + RC4.