Managed Service Accounts: MSA Setup
One challenge that IT pros have always faced is managing service accounts, especially those accounts that are either machine or domain based, ie something other than accounts like LocalSystem. Not only do you need to keep track of what is using these accounts, you most likely need to change passwords periodically. All of this service account management is labor intensive, but there might be an alternative for you.
When Windows Server 2008 R2 was released, it included a new feature called Managed Service Accounts (MSA). I believe this feature didn’t garner a lot of attention, primarily because it requires Windows 7 or Windows Server 2008 R2 and the service or application must be designed to work with these new types of accounts. You’ll have to check your product’s documentation or contact the vendor to learn which service cans use an MSA and which don’t.
This is a three-part series. Today I’ll talk about setting up managed service accounts. In part two, we’ll add the MSA to a member server and configured a service. And finally, we’ll look at steps involved in changing or rolling back the MSA.
Managed Service Accounts (MSA) in Active Directory
Managed service accounts are stored in Active Directory in their own container, which I would leave alone. After you create an msa it must be installed on all the computers where you wish to use it and finally the service must be configured to use the account. The beauty is that once set up, you never have to touch the account again. The member server (or desktop) will handle all the necessary password changes behind the scenes securely.
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.
Microsoft did not provide any graphical tools for setting up and managing these accounts, so you’ll have to use Windows PowerShell and the Active Directory module from Microsoft. The best approach, and the one I will use, is to manage remotely from a Windows 7 desktop with Remote Server Administration Tools (RSAT) installed and configured to manage Active Directory.
Go to Control Panel – Programs – Programs and Features and “Turn Windows Features on or off.” Scroll down to Remote Server Administration Tools – Role Administration Tools and expand AD DS and AD LDS Tools. Check the box for Active Directory Module for Windows PowerShell and AD DS Tools.
To begin, we need to load the AD module.
PS C:\> import-module ActiveDirectory
We could use the AD: PSDrive and see what exists in the default msa container.
PS C:\> dir "AD:CN=Managed Service Accounts,DC=globomantics,DC=local"
First, we need to create a new AD Service Account. Care to guess what the cmdlet name is? Let’s ask for help on New-ADServiceAccount. Figure 1 displays the results.
Figure 1 New-ADServiceAccountHelpThe syntax is actually pretty straightforward. The account is very similar to user account in that you can set an account expiration date, define a description, or choose whether to enable it at creation time. Actually, the account is enabled by default so if you want it to be disabled you have to use the –Enabled parameter with a value of $False, which is a bit quirky if you ask me. There is an option to specify a password, but I tend to leave that alone and let Windows handle that for me. That’s the whole point of the msa as far as I’m concerned.
Let’s create a simple test account.
PS C:\> New-ADServiceAccount -Name MSATest
By default, the account will be created in the Managed Service Accounts container. The cmdlet has a –Path parameter if you want to specify an alternate location using the distinguishedname format. Personally, I tend to use the default.
If the msa will also require a service principal name, you can define that at the same time.
PS C:\> New-ADServiceAccount -Name MSATest2 -Description "a second test MSA" –ServicePrincipalNames "MyService/chi-fp01.globomantics.local" -displayname "MSA Test 2" -PassThru 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 :
By default, the cmdlet doesn’t write an object to the pipeline so I used –Passthru to see the result.
Once I have some msas, I can find them with the Get-ADServiceAccount cmdlet.
PS C:\> Get-ADServiceAccount -filter *
The results are in Figure 2.
Figure 2 Getting Managed Service AccountsHopefully, you’ll get the settings right when you create the account, but if you need to modify an account, use the Set-ADServiceAccount cmdlet. I’m going to disable the first msa I created and add a comment in the description field.
PS C:\> Set-ADServiceAccount -Identity "MSATest" -Description "unused" -Enabled:$False
This cmdlet also doesn’t write anything to the pipeline unless you use –Passthru, but it does support –Whatif and –Confirm. I can see the changes were implemented.
PS C:\> Get-ADServiceAccount -filter * -Properties Description,ServicePrincipalName | Select Name,Enabled,Description,ServicePrincipalName | format-list
Figure 3 Updated Managed Service Accounts
Now that we have the accounts defined, we need to deploy them. I’ll cover that in Part 2.