Managed Service Accounts: Configure a Service Using MSA
Published: Jun 14, 2012
In part one of this three-part series, we looked at how to set up a managed service account (MSA). These accounts, which I’ll refer to as an msa, are stored in Active Directory and can be implemented on Windows 7 or Windows Server 2008 R2. In Part 1 we saw how to create, find, and modify them using Windows PowerShell. There is no graphical interface really; you have to use Windows PowerShell or find a third party tool. I’m going to manage from my Windows 7 client with RSAT and the Microsoft ActiveDirectory module.
Today we’re going to learn to add the MSA to a member server and configured a service. And in the third and final part, we’ll look at steps involved in changing or rolling back the MSA.
PS C:\> Import-Module ActiveDirectory
The next step is to connect the msa to the computer account in Active Directory. An msa can only be associated with one computer account at a time, but a computer can have multiple msa’s. In Part 1, I created an account to be used on CHI-FP01 with a new service I will be installing.
PS C:\> Get-ADServiceAccount -Identity MSATest2 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 :
Notice that HostComputers is empty. We’re going to add this msa to the CHI-FP01 computer account using the Add-ADComputerServiceAccount cmdlet. I like that this cmdlet supports –Whatif and –Confirm.
PS C:\> Add-ADComputerServiceAccount -Identity CHI-FP01 -ServiceAccount MSATest2 -WhatIf What if: Performing operation "Set" on Target "CN=CHI-FP01,CN=Computers,DC=GLOBOMANTICS,DC=local".
That looks right so I can re-run the command, dropping –Whatif. By default, nothing is written to the pipeline unless you use –Passthru.
PS C:\> Add-ADComputerServiceAccount -Identity CHI-FP01 -ServiceAccount MSATest2 -PassThru DistinguishedName : CN=CHI-FP01,CN=Computers,DC=GLOBOMANTICS,DC=local DNSHostName : CHI-FP01.GLOBOMANTICS.local Enabled : True Name : CHI-FP01 ObjectClass : computer ObjectGUID : 12be17f7-3fa9-456f-be63-2eed3cc57c79 SamAccountName : CHI-FP01$ SID : S-1-5-21-2552845031-2197025230-307725880-1105 UserPrincipalName :
Checking the msa again, we now see a value for HostComputers.
PS C:\> Get-ADServiceAccount -Identity MSATest2 | Select HostComputers
HostComputers
-------------
{CN=CHI-FP01,CN=Computers,DC=GLOBOMANTICS,DC=local}
Despite the property name, even though you can theoretically add the msa to other computer accounts, it can only be used by one at a time, at least with my testing. Because this is an update to Active Directory, depending on the location of the member server or desktop in question, you may need to wait for the change to replicate to all your domain controllers.
When you are ready, the last step is to “install” the msa on the host computer. We will use the Install-ADServiceAccount cmdlet. Now for the unfortunate part: this command must be run ON the member server or domain. That’s right. This means you need to at least temporarily install and configure RSAT, including the AD PowerShell module. You will also need at least version 3.5.1 of the .NET Framework. Finally, you must run the command in an elevated PowerShell session with an administrative account. The next disappointment is that you can’t use PowerShell remoting to install the service account. At least I’ve never been able to get it to work. I can get around the 2nd hop problem but when it comes down to finally installing, PowerShell complains with an unknown error. So, you’ll have to open an interactive console session and run:
PS C:\> Import-Module ActiveDirectory PS C:\> Install-ADServiceAccount -Identity "MSATest2"
Once installed, you can use the Services management console to specify the new logon account. You might need to browse or search your domain for the account. You most likely will also have to set an initial password.
Or, you can use WMI and make the change, locally or remotely.
PS C:\> $w=Get-WmiObject win32_service -filter "name='MyService'" -computername "CHI-FP01"
PS C:\> $msa=Get-ADServiceAccount -Identity MSATest2
PS C:\> $new="Globomantics\{0}" -f $msa.SamAccountName
PS C:\> $w.change($null,$null,$null,$null,$null,$null,$null,$new)
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : 0
PS C:\> $w.StopService()
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : 0
PS C:\> $w.StartService()
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : 0
A value of 0 means success. I then need to restart the service for the change to take effect. Normally, I prefer using Invoke-WMIMethod for this type of task, but because you have to specify all the Null values before you get to the service account name, this cmdlet doesn’t play well with others. But, I now have a managed service account in place.
Conclusion
We’ll wrap up next time by looking at how uninstall and remove managed service accounts.