Windows Server 2008 R2 AD Domain Services -- Managed Service Accounts

Windows Server 2008 R2 AD Domain Services -- Managed Service Accounts


December 12, 2010

More on Windows Server 2008 R2

One of more common administrative challenges in Windows environments involves configuring user-based credentials that provide arbitrary security context to non-core services. Active Directory schema extensions incorporated into Windows Server 2008 R2 introduced a new feature known as managed service accounts, which eliminate a number of drawbacks associated with such configuration.

One of more common administrative challenges in Windows environments involves configuring user-based credentials that provide arbitrary security context to non-core services (instead of leveraging built-in LocalSystem, LocalService, or NetworkService accounts). The complexity associated with such configuration results from the fact that changing the passwords of these accounts requires manual updates to the Security Control Manager database on each computer where they are being used. As a matter of fact, there are scenarios where considerably more elaborate steps are needed, as documented in articles 934838 and 283811 of Microsoft Knowledge Base. More importantly, the manual nature of this process introduces potential for mistakes and oversights, leading to account lockouts and subsequent outages -- typically after service-dependent applications fail to start following a reboot. The same outcome is sometimes caused by typographical errors when service accounts credentials are misused for interactive logons. Last but not least, to avoid administrative overhead associated with password changes, such accounts are frequently configured with non-expiring passwords, introducing a security vulnerability, which is further aggrevated by their elevated privileges.

Active Directory schema extensions incorporated into Windows Server 2008 R2 introduced a new feature known as managed service accounts (MSAs), which allow you to eliminate these issues. While their most widely recognized benefit is automatic password management, they are also capable of self-correcting Service Principal Names attribute in case of sAMAccountName or DNS name changes. Since they are associated with computer (rather than user) accounts, they cannot be used for interactive logons, and they are not subject to account lockouts. They can, however, be disabled.

On the other hand, it is also important to point out some of their limitations. In particular, they are applicable only to services running on Windows 7 or Window Server 2008 R2. Because of their dependency on the host computer account, they are restricted to an individual OS instance, making them unsuitable for highly available applications operating on failover clusters or Network Load Balancing farms. It is, however, possible to have multiple MSAs associated with the same computer. In addition, this technology's viability must be evaluated in the context of individual applications, so make sure to consult with the respective vendors regarding its supportability.

Active Directory Managed Service Accounts

From the Active Directory perspective, MSAs take the form of objects of msDS-ManagedServiceAccount class (which has computer class as its immediate parent) residing by default in the Managed Service Accounts container and incorporated into Windows Server 2008 R2 schema extension. Effectively, you have an option of implementing them in down-level forests (after you extend their schema by running adprep /forestprep from the Windows Server 2008 R2 installation media), although you will not be able to take advantage of the automatic SPN management until you raise the functional level to Windows Server 2008 R2 (which implies that all your domain controllers must running this version of the operating system). In addition, you will need to install Active Directory Management Gateway Service, which is available from Microsoft Download Center, on your Windows Server 2003 or Windows Server 2008-based domain controllers.

Active Directory Management Gateway Service facilitates administration of MSAs, which is performed primarily via Active Directory Module for Windows PowerShell. Once made available, this can be imported into your PowerShell session by running Import-Module ActiveDirectory. Its cmdlets can be executed either from a Windows Server 2008 R2 (with Active Directory module for Windows PowerShell subcomponent of AD DS and AD LDS Tools component within Remote Server Administration Tools feature enabled) or Windows 7 computer (with Remote Server Administration Tools for Windows 7 installed).

The New-ADServiceAccount cmdlet creates MSAs. You might discover that context-sensitive menu of the Managed Service Accounts container in your Active Directory Users and Computers console includes the New msDS-ManagedServiceAccount entry, you should refrain from using it, since it will yield an object missing a number of relevant attributes. Its syntax allows you to specify practically all of its characteristics. For details, refer to Technet Library. However, you will likely reference only a subset of available parameters, such as -Name (the account name, which, by the way, in the current implementation can not exceed 15 characters), -Enabled ($true or $false), -ServicePrincipalName (in the format service_type/instance_name:port_number), -TrustedForDelegation ($true or $false), and -Path (allowing to specify the distinguished name of an arbitrary target Active Directory location where the account should be created, if the default Managed Service Accounts container does not suit your needs).

Although it is possible to assign an explicit password with the -AccountPassword switch, it's hard to imagine a scenario where this would be beneficial (instead, you should consider relying on a randomly generated one). For example, the following command will create and enable managed service account named s-MSA-0001 with an automatically generated password in the default MSA container of your domain AD.local (CN=Managed Service Accounts,DC=AD,DC=local)

 New-ADServiceAccount s-MSA-0001 -Enabled $true 

If your intention was to modify the target location and set an arbitrary password, run:

 New-ADServiceAccount s-MSA-0002 -Enabled $true -Path "OU=Services,DC=AD,DC=local" -AccountPassword (Convert-To-SecureString -AsPlainText "@br4Cad@brA" -Force) 

Automatic password changes of MSAs (utilizing, by default, a 240-character long autogenerated password) are synchronized with the host computers. Their frequency is determined by the Domain Member:Maximum machine account password age setting (set by default to 30 days and represented by the HKLMSYSTEMCurrentControlSetServicesNetLogonParametersMaximumPasswordAge DWORD registry entry) of Local PoliciesSecurity Options node of Computer Configuration Group Policy Object applicable to the computer on which the managed service account has been installed. This, incidentally, also dictates the frequency of computer password changes. If necessary, you can reset the current password with Reset-ADServiceAccountPassword PowerShell cmdlet. You can also disable automatic password changes by leveraging DisablePasswordChange DWORD entry (which can be set to either 1 or 0) residing in the HKLMSYSTEMCurrentControlSetServicesNetlogonParameters registry key (corresponding to the Domain member: Disable machine account password changes group policy setting).

Install-ADServiceAccount cmdlet sets the msDS-HostServiceAccount attribute of the target computer object in Active Directory (Uninstall-ADServiceAccount reverses this process) to the distinguished name of the managed service account. This attribute is part of a linked pair, with the msDS-HostServiceAccountBL (in the form of the distinguished name of the computer account on which the managed service account has been installed) of the msDS-ManagedServiceAccount object as its counterpart. To identify its value, reference the HostComputers parameter displayed as part of the output of Get-ADServiceAccount cmdlet. The same pair of attributes can be also modified with the Install-ADServiceAccount cmdlet invoked directly on the computer on which the managed service account will be used. To successfully execute this cmdlet, requires local administrative privileges as well as permissions to modify the managed service account, in particular, those outlined in the Service Accounts Step-by-Step Guide on Microsoft Technet.

To assign a specific managed service account to a local service

  • Open Services MMC snap-in (you can access it via Computer Management console or launch it directly by running Services.msc)
  • Locate the target service, display its Properties dialog box
  • Switch to the Log On tab
  • Select This account option button
  • Use Browse... command button to designate domain where the account resides
  • Type the account name followed by $ sign in the Enter the object name to select text box of Select User dialog box
  • Confirm your selection by clicking on the OK button
Ensure that both Password and Confirm password textboxes are empty (if you decided to assign a specific password during the account creation via -AccountPassword parameter, you have an option of typing it in at this point). Once you click on the OK command button, the account will be granted Log on as a service right on the local computer (this privilege needs to be assigned manually if you decide to configure MSAs via other means). Finally, restart the service in order for the change to take effect, completing this way all implementation steps.

Follow ServerWatch on Twitter