Managed Service Accounts: Change or Roll Back the MSA

In Part 1 of this series, we looked at setting up managed service accounts. In Part 2, we added the msa to a member server and configured a service. In today’s third and final part, we’ll look at steps involved in changing or rolling back the msa.

Changing and Rolling Back the MSA

Should you decide to stop using an msa, naturally the first thing to do is to modify the service on the domain member to use whatever replacement account you have in mind. Once this is done, you have to decide if you think you’ll use the msa again on this computer or on another computer in the domain.
If you no longer need the msa on the member server, perhaps the application has been removed. You can uninstall it. Like the Install-ADServiceAccount, you must run this command on the host computer.

The cmdlet does not write anything to the pipeline. However, this will also update Active Directory and remove the host from the msa object. If I try to run:
I'll get no result. I can also verify the HostComputers property.
DistinguishedName : CN=MSATest2,CN=Managed Service Accounts,DC=GLOBOMANTICS,DC=local
Enabled           : True
HostComputers     :
Name              : MSATest2
ObjectClass       : msDS-ManagedServiceAccount
ObjectGUID        : 98c79151-5861-4b5c-bccc-de71482ed658
SamAccountName    : MSATest2$
SID               : S-1-5-21-2552845031-2197025230-307725880-1190
UserPrincipalName :

At this point, we still have the msa in Active Directory, but it isn’t tied to any other computer. We could add it to another computer and install it if we wanted to re-use the msa.
If for some reason the host is unavailable, you can still remove the association using Remove-ADComputerServiceAccount.

Remove-ADComputerServiceAccount -Identity "Chi-FP01" -ServiceAccount "MSATest2"

You should only need to do this if you can’t uninstall it locally from the host.
You may decide all you need to do for now is disable the account, which would be a good security practice. We looked at this briefly before. Here’s a refresher:

DistinguishedName : CN=MSATest2,CN=Managed Service Accounts,DC=GLOBOMANTICS,DC=local
Enabled           : False
HostComputers     :
Name              : MSATest2
ObjectClass       : msDS-ManagedServiceAccount
ObjectGUID        : 98c79151-5861-4b5c-bccc-de71482ed658
SamAccountName    : MSATest2$
SID               : S-1-5-21-2552845031-2197025230-307725880-1190
UserPrincipalName :

If you decide to re-use the msa, don’t forget to re-enable it.
Finally, if you decide to permanently delete the msa, the best approach is to use the Remove-ADServiceAccount cmdlet. It supports –Whatif, which makes for a good sanity check.

PS C:\> Remove-ADServiceAccount -Identity MSATest2 -whatif
What if: Performing operation "Remove" on Target "CN=MSATest2,CN=Managed Service Accounts,DC=GLOBOMANTICS,DC=local".
PS C:\> Remove-ADServiceAccount -Identity MSATest2
Confirm
Are you sure you want to perform this action?
Performing operation "Remove" on Target "CN=MSATest2,CN=Managed Service
Accounts,DC=GLOBOMANTICS,DC=local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS C:\>

And that’s it! I can’t tell you if using an msa is right for you. As I mentioned at the start of this series, you must be running Windows 7 or Windows Server 2008 R2 or later to use a managed service account, and you need to verify that your application or service can support it. This is definitely something you want to test in a non-production environment. Using PowerShell to manage these items is not especially difficult, but I strongly recommend you read full cmdlet help and examples for everything I’ve discussed in this series.