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.
Achieve instantaneous visibility into user & group permissions with the free Permissions Analyzer Tool for Active Directory!
- Get a complete hierarchical view of the effective permissions & access rights for a specific file folder (NTFS) or share drive
- Easily see what permissions a user has for an object and why (group membership or direct permissions)
- See it all from a totally cool desktop dashboard
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.
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.
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
Now that we have the accounts defined, we need to deploy them. I'll cover that in Part 2.