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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
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.