Error installing sMSA, the account is linked to another computer object.

Scenario: When installing a Managed Service Account on a server you get the following error in PowerShell:

WARNING: Test failed for Managed Service Account MSASQL01. 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.

Our example account is MSASQL01.

First check which computer object is it linked to. In PowerShell run the following:

Get-AdServiceAccount -Identity MSASQL01 -Properties PrincipalsAllowedToRetreiveManagedPassword

This will return a block with a value showing which computer or group is allowed to retrieve the managed password. A Standalone Managed Service Account (sMSA) should be linked to one computer object, and a Group Managed Service Account (gMSA) should be linked to one AD group object, whose members are all computer objects the gMSA will be installed on. For example, the block will include similar output for either sMSAs or gMSAs:

PrincipalsAllowedToRetreiveManagedPassword : {CN=WRONG-SERVER,OU=Servers,DC=yourdomain,DC=internal}
Or
PrincipalsAllowedToRetreiveManagedPassword : {CN=WRONG-GROUPNAME,OU=MSAGROUPS,DC=yourdomain,DC=internal}

Yes, you can delete your MSA and start over if you made a mistake in creating it, but in most cases it’s easier to replace the wrong server or group with the correct server or group.

To fix it, first extract the distinguished name of the correct server or group. In Active Directory Users and Computers (ADUC) navigate to the server or group object > right-click and select Properties, or double-click on the object to open Properties > open the Attribute Editor tab > scroll down to distinguishedName and double-click on it, or highlight it and click the View button > copy the whole Value: string.

Then run the following in PowerShell, using the computer or group object’s distinguishedName value in the quotations:

Set-ADServiceAccount -Identity MSASQL01 -PrincipalsAllowedToRetrieveManagedPassword "CN=CORRECT-SERVER,OU=Servers,DC=yourdomain,DC=internal"

Then, if you re-run the command to check which Principals are allowed to retrieve the password you should see the updated value. So running:

Get-AdServiceAccount -Identity MSASQL01 -Properties PrincipalsAllowedToRetreiveManagedPassword

Will return:

PrincipalsAllowedToRetreiveManagedPassword : {CN=CORRECT-SERVER,OU=Servers,DC=yourdomain,DC=internal}

Again, mind that MSASQL01 is just an example account name, gMSAs are linked to a group object which contain multiple servers, and sMSAs are linked to a single server object.

IF YOU CONTINUE TO RECIEVE THE ERROR

The error message said the MSA was linked to the wrong group or server object “OR this computer does not support all the Kerberos encryption types required for the gMSA.“

We’ve addressed how to validate and change the linked object, so if you’re still getting the error you need to validate the encryption type.

You are most likely to run into this error if you defined the encryption type when you first created the account, and after the account creation date that encryption type has been deprecated. RC4 for instance. To make things easy, you can simply adjust the MSA to use currently supported encryption types. In this example we’ll set the account to use AES128 and AES256, which are broadly supported. In PowerShell:

Set-ADServiceAccount -Identity MSASQL01 -KerberosEncryptionType AES128,AES256

Lastly, make sure you’re running