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.
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

Conclusion

Now that we have the accounts defined, we need to deploy them. I’ll cover that in Part 2.