This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
I've been doing system administration since roughly 1994 and in that time I've come to realize one thing: making changes to established environments always causes a ripple effect. The impact of changes usually doesn't surface right away, so associating the exact change to the problems that crop up down the road can be very difficult.
Recently my Microsoft colleague Bill Almonroeder and I were helping our customer implement a Group Managed Service Account (gMSA) to increase security and lower the administrative overhead on our service accounts. We were methodical in the steps to properly create the account and waited a full weekend between the time that we created the account in active directory. Sounds good so far, right? In complex compute environments where there are many moving parts, things rarely go as planned, and this day was no exception. When we attempted to perform the installation of the gMSA on Windows Server, we received the error message:
Install-ADServiceAccount : Cannot Install service account. Error Message: 'The provided context did not match the target'
Hmmm.."The provided context did not match the target"...not exactly overflowing with relevant information. The Test-ADServiceAccount cmdlet gave us a little more to go on:
WARNING: Test failed for Managed Service Account SQLServerGMSA. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA operational log for more information.
We verified that the account had been created properly and did not suffer from the "linked to another computer object" condition mentioned first in the message. This would be applicable on a Managed Service Account (MSA) scenario since that type of account can only be used with a single computer. Our account was created as a gMSA, and we validated that the group that had been associated with the GMSA was properly configured and contained both servers on which we intended to use the gMSA. Permissions were verified, all is well.
The error also mentions Kerberos encryption, but we're not experiencing any other Kerberos-related issues. Time to look at the event logs. A quick look at the Security-Netlogon event log yielded a couple of clues:
There were event IDs 9001 and 9002 being logged when we attempt to test and install the GMSA. The 9002 event doesn't provide much more information than the "provided context did not match the target" message.
Let's look at the 9001: The account SQLServergMSA cannot be used as a managed service account on the local machine because not all of the supported encryption types are supported by the local machine.
This event is at least pointing us back at the encryption types, which is also mentioned at the tail end of the Test-ADServiceAccount output. What gives?
After dredging through the documentation for gMSAs, I ran across the answer to our issue at: https://technet.microsoft.com/en-us/library/hh831782.aspx :
"A managed service account is dependent upon Kerberos supported encryption types. When a client computer authenticates to a server using Kerberos the DC creates a Kerberos service ticket protected with encryption both the DC and server supports. The DC uses the account's msDS-SupportedEncryptionTypes attribute to determine what encryption the server supports and, if there is no attribute, it assumes the client computer does not support stronger encryption types. If the Windows Server 2012 host is configured to not support RC4 then authentication will always fail. For this reason, AES should always be explicitly configured for MSAs"
Aha...now it makes sense! We had recently decided to remove the RC4 encryption algorithm in Kerberos to tighten security and, until now, had not run into an issue.
Now we're making progress! We'll heed the advice of the documentation and specify the encryption types for the gMSA using the command below:
Set-ADServiceAccount -Identity SQLServerGMSA -KerberosEncryptionType AES128,AES256
To verify, we can look at the GMSAs attributes in Active Directory Users and Computers, specifically, the msDS-SupportedEcryptionTypes attribute to verify that it does not contain RC4.
Now that the problem has been resolved, the Install-ADServiceAccount cmdlet works with no errors, hopefully no news is good news.
If we run the Test-ADServiceAccount cmdlet, note that it returns "True" now. That looks much better! Our gMSA is finally ready for use.