Server 2012 R2 – gMSA Accounts and Security

gMSA (Group Managed Service Accounts) come along with the introduction of Server 2012, these aim to increase the security of service accounts by removing static & known passwords. However, they do introduce their own complications.

Legacy Service Accounts

If your running a Microsoft infrastructure of any size, there is little doubt that you will have a number of service accounts within Active Directory used by software and automated tasks throughout your environment.
These service accounts commonly have the passwords set to never expire and end up written in a list, as the passwords will be required from time to time. In the past, several steps could easily be taken to start to mitigate the risks, including:

• Set a long and complex password
• Store the password in a secure location (Password Vault)
• Limit access to the credentials
• Change them periodically or after key staff leave the team/organisation

There is now another route to securing these accounts, in comes Group Managed Service Accounts (gMSA). There are some great resources online to do with configuring these (some below), but this guide aims to cover the basics to get you running, which I needed while deploying AD FS on Server 2012 R2.

Create the Key Distribution Services KDS Root Key

Before you can use gMSA in Server 2012 R2, you need to perform the one time operation of generating the KDS root key. I found a number of blogs/howtos online while, but couldn’t get this running in my environment to start with for two reasons.
1. You will require a Server 2012 R2 domain controller within the forest root domain (We only had one in the child domain initially).
2. On the Windows Server 2012 domain controller, run Windows PowerShell from the Taskbar as an Administrator. (Right click, Run As Administrator)
At the command prompt type the following commands, and then press ENTER:
To create the KDS root key in a production environment

1	Add-KdsRootKey –EffectiveImmediately

To create the KDS root key in a test environment for immediate effectiveness

1	Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Also see: http://technet.microsoft.com/en-us/library/jj128430.aspx

Setup the gMSA account

Create a security group and add the computer accounts for the servers that will use this account to the group.
Now create the account

1	New-ADServiceAccount -name gmsa1 -DNSHostName gmsa1.jervis.local -PrincipalsAllowedToRetrieveManagedPassword "gmsa-gmsa1grp"

Configure a service

Login to the 2012 target server and from a PowerShell prompt running ‘As Administrator’

1 2 3 4 5 6 7 8 9 10 11

PS C:\Windows\system32> Add-WindowsFeature RSAT-AD-PowerShell   Success Restart Needed Exit Code      Feature Result ------- -------------- ---------      -------------- True    No             Success        {Remote Server Administration Tools, Activ...     PS C:\Windows\system32> Install-ADServiceAccount gmsa-gmsa1 PS C:\Windows\system32> Test-ADServiceAccount gmsa-gmsa1 True PS C:\Windows\system32>

You will now need to change your service to run as the gMSA account, for example:

Possible Issues

• You need at least one 2012 Domain Controller
• Servers that will use the gMSA account need to run Server 2012
• If you plan to use these with SQL, you must use SQL 2012, or SQL 2012 Express
• Your application must support gMSA
• Any other task or service (on the gMSA target server) could use that gMSA account to run.

Security Considerations

You need to consider the overall security of the servers and environment. In most cases, if your able to use a gMSA account, its likely to increase security mainly due to the automatic management of passwords.
More secure: As the admin that has left can’t login to your servers with his account as its disabled and he does not have any service account passwords.
Less secure: As any admin on a server granted to use a gMSA account could map any number of tasks and services to run under that account on that server. (Only have trust worthy admins)
A nasty hole could be a batch file that is in a publicly writeable share, which runs regularly as a gMSA account that has domain admin privileges. This is true of any account and not just gMSA, but consider how easy it would be to just enter that username against any service or task thats being created.
As always you need to provision following the principal of least privilege, and educate admins in how these accounts can be used to increase security while reminding them how issues could occur.
Sometimes it maybe best to use a gMSA account, sometimes a standard user account (with tight password management).