Here’s the situation: You are called into consult for a client, and in examining their IT infrastructure you observe no organization as to how service accounts are deployed. For instance, some line-of-business (LOB) applications are using the domain Administrator as their service account identity, while others use the Local Service or Network Service identity.
Recently, the client began associating application services with dedicated domain user service accounts. However, because domain password policy forces password changes every 60 days, the manual reassignment of service account passwords created organizational headaches for the IT support staff.
How can you resolve this mess of a real-world situation?
Introducing Managed Service Accounts
In Windows Server 2008 R2, we finally have a solution to the problem of reconciling service accounts with Active Directory password policy: the Managed Service Account, or MSA.
When you define an MSA, you leave the account’s password to Windows. Thus, MSAs interoperate just fine with your organizational password policies. When it comes time to change the MSA password, Windows takes care of that for you, automatically generating a password that meets any complexity requirements you may have mandated.
As wonderful and convenient as MSAs are (and they are, trust me), we need to always keep in mind the IT security principle of least privilege. In other words, we must be careful not to assign permissions, either explicitly or implicitly, to the MSA account that are beyond the required access scope of that account.
Creating Managed Service Accounts
We use Windows PowerShell 2.0 to create and manage MSAs. From an elevated command prompt, type powershell to enter the Windows PowerShell environment.
Next, type import-module activedirectory to load the Active Directory PowerShell cmdlet library.
We use the new-adserviceaccount cmdlet to define a new MSA. For instance, the following statement creates an MSA named testmsa and enables the account for use:
PS>new-adserviceaccount –Name testmsa –Enabled $true
To verify that the MSA has been created and is "ready for action," so to speak, run the get-adserviceaccount cmdlet. Sample output from this cmdlet is shown in Figure 1:
The get-adserviceaccount cmdlet
NOTE: Windows appends a dollar sign ($) to the MSA account name. Therefore, an MSA named testmsa appears in the computer’s SAM or Active Directory as testmsa$.
We can also fetch MSA properties from Active Directory Users and Computers. Open the tool, click View > Advanced Features to display advanced features, and expand the Managed Service Accounts container. This is shown in Figure 2:
Viewing MSAs in Active Direcotry Users and Computers
Using Managed Service Accounts
Once they are defined, we can associate MSAs with applications and services by using any of the traditional methods with which you are familiar.
For instance, you can open the Service Control Manager, double-click a service, and navigate to the Log On tab to browse Active Directory for an MSA. This procedure is shown in Figure 3:
Assigning an MSA to a service
NOTE: Be sure to leave the Password and Confirm password fields empty. Remember, we are delegating account password management to Windows.
Once you apply the change, you will see a Services message box informing you that the designated MSA has been granted the Log On as a Service user right. This message box is shown in Figure 4:
Services message box
Taking the next step
From Windows PowerShell, you can issue the statement get-command –noun *adserv* to retrieve a list of all MSA-related cmdlets.
MSA-related Windows PowerShell cmdlets
You can then run help <cmdname> to obtain online help concerning syntax and usage concerning that specific cmdlet.
If you are like me, then you find that the Managed Service Account capability of Windows Server 2008 R2 is an administrative godsend. Windows PowerShell is increasingly becoming a "must have" skill set for Windows administrators; please see my 4sysops blog posts on the subject if you’d like a general introduction to Windows PowerShell.