Apr 27, 2015

Managed Service Accounts (MSAs) were first introduced in Windows Server 2008 R2 (and Windows 7) and what a great leap forward for administrators they were – finally, we could create a service account, and let the system take care of the password renewals and the SPN (Service Principal Name) registration for us.

By using MSAs, the system would automatically assign a random string of 120 characters as the password and change it every 30 days by default. However, they did have a number of major drawbacks – each MSA was applicable to only one computer and its resources; they couldn't be used for scheduled tasks or IIS Application Pools, they were not supported by Exchange or SQL services etc. (OK, another drawback for some administrators unfamiliar with PowerShell is that they can only be created by using PowerShell cmdlets). They could also easily become a major security hole, as more often than not service accounts were made members of the Domain Administrator’s group to give them domain visibility etc.

Enter Windows Server 2012.

In Active Directory on Windows Server 2012, the schema has been extended to include a new object class called the msDSGroupManagedServiceAccount (gMSAs). Similar to the original Managed Service Accounts, gMSAs allow the system to change their passwords regularly, but now the gMSAs password is generated by the Key Distribution Service (KDS) on Windows Server 2012 DCs. The password hash is also now stored in AD, so that a service can simply query AD for the current password, and usage of a gMSA is restricted to only those servers specified in the security descriptor msDS-GroupMSAMembership. Any Windows Server 2012 KDS can generate the password as all KDS instances use the same algorithm.

All of this means that a gMSA can do all the things I mentioned above that standard MSAs could not do, including usage on multiple hosts, Exchange, IIS Application Pool and SQL support and so on, thus allowing us proper and secure domain wide administration.

MSAs do have a few requirements of course, in that you must have at least one Windows 2012 Domain Controller (i.e. a 2012 forest and domain level AD); the server using a gMSA must be a Windows Server 2012 (or Windows 8) platform or above and the service making use of a gMSA must also be compatible with this type of account (you may need to check this with the service vendor). Oh, and you still need PowerShell to create the gMSAs in the first place (sorry ‘bout that!)

In practice, using a gMSA is as follows:

1. You need to create the KDS Root Key. This only needs to be done once per domain, but remember there is a built in 10 hour delay in its creation before it can be used, to ensure that all DCs have replicated properly and are therefore, able to respond to the gMSA requests. There is a trick to bypass this delay, but it is not recommended in a production environment. You can use the PowerShell (with the Server 2012 AD module) cmdlet Add-KdsRootKey to create the KDS root key.
2. Create and configure the gMSA. You need to first create or identify a suitable security group to add the computer objects that you wish to use the gMSA. This may mean rebooting those servers to reflect membership changes. You then use the PowerShell (with the Server 2012 AD module) cmdlet New-ADServiceAccount to create the gMSA, specifying a SamAccountName, dnsname and the group allowed to use the gMSA. Once you have done that you will find your new Group Managed Service Account in the Managed Service Accounts folder in each specified domain in AD.
3. Configure the gMSA on the Host. You need to install the gMSA on each host before it can be used. Again, PowerShell (with the AD cmdlets) is used. The cmdlet here is Install-ADServiceAccount specifying the appropriate gMSA name. Once installed on the host, it can be used simply by referring to the standard domain syntax in the appropriate services (e.g. Exchange, IIS Application pool etc.) Logon/Credential UI. Note, that when you specify the gMSA name you need to add the dollar sign ($) after the gMSA name, and leave the password blank. If you are using PowerShell to point to the gMSA, you need to enter the LogonType Password and not the actual password, so that the service knows to retrieve the actual password from AD.

Exact details on Group Managed Service Accounts, with examples (and lots of pretty pictures) can be found here, so go ahead and check it out – it gives you another reason to learn PowerShell syntax, and greatly increases security by not having to run your normal services using a Domain Admin’s account!