Windows Server 2008 R2 AD Domain Services — Managed Service Accounts Page 2

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