When Managed Service Accounts (MSAs) were introduced in Windows Server 2008 R2, lots of us got excited. Especially those of us in security conscious environments, like the DoD, where service accounts passwords needed to be changed at least once every year. So we diligently read up on how to use them and quickly realized there weren’t going to be too many places we could use them. You couldn’t use them for apps like SQL or Exchange, and you could only use them on one machine per MSA. Additionally, some third-party applications didn’t support them.
But now that we have Group Managed Service Accounts (gMSAs), there are many more places they can be used. They can now be used for SQL Server and they’re a lot more flexible and easier to work with.
The first step to using them is to extend your Active Directory Schema, which is not covered here. The new object class “msDSGroupManagedServiceAccount” is created and is derived from the Computer class, and includes the following five new attributes:
So, what else is required besides extending your schema? You’ll need one or more Windows Server 2012 or later Domain Controllers (DCs) and a Windows Server 2012 or Windows 8 computer with the Active Directory (AD) PowerShell Module to create and manage the gMSA. Of course, you’ll also need a Windows Server 2012 or Windows 8 computer that will use the gMSA.
Before we go barreling down the path of using them, there are some interesting things to note about these new gMSAs. First, the passwords are stored (*) in AD. Specifically, the Key Distribution Service on Windows Server 2012 and new DCs is where the passwords are created and managed. Hosting the passwords this way is what allows multiple machines to query AD and use the passwords.
Also, not just any machine can use the password of a gMSA. When a new gMSA is created, the list of machines authorized to use the password is restricted to machines in the msDS-GroupMSAMembership security descriptor. Each time the password is needed, the DC being queried determines if the password needs to be changed. It does that using the msDS-ManagedPasswordInterval attribute.
Passwords are created using a predetermined algorithm and are 120 characters long. And since they’re stored in AD, other DC’s in the domain will be able to use them. Now for the detailed steps to create them in a forest that’s had its schema properly extended.
1. Create the KDS Root Key per Forest. The trick here being that if you use the “-EffectiveImmediately” switch, there is a 10 hour delay built in. This is done to ensure that AD replication is complete before you’re allowed to use them. A workaround is to use the “-EffectiveTime” switch instead as shown below. But keep in mind, if you use the command as shown below, make sure replication is complete before you start using gMSAs
Add-KDSRootKey -EffectiveTime ((get-date).addhours(-10))
2. Create a global security group that will contain the computers that will be allowed to use the gMSA, and then populate the group. This gives you more flexibility to extend the gMSA to more computers without having to run any commands. You simply add the computer object to the group and your off and running, with one small inconvenience. Since your adding the computer object to a group, the server will need to be rebooted to gain the needed group membership. Of course, if they’re already a member of some other common group, you could just nest that group or use it directly instead of creating a new group. Such as a group named “MySQLServers” that contains all your SQL servers. But for security sake, don’t try and shortcut anything. Using a group whose membership isn’t exactly what you need, or that can be managed by someone other than an approved administrator, could lead to problems. These accounts can be used for any service on the computers they’ve been authorized on. So, they have the potential to be abused by anyone who can configure services on them. Ensure you always follow security best practices, such as employing RBAC and a “least privileges” model.
3. Create the new gMSA by using the following command:
Syntax: “New-ADServiceAccount -name <ServiceAccountName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword <group>”
Example: “New-ADServiceAccount -Name gMSA_SomeService -DNSHostName something.example.com -PrincipalsAllowedToRetrieveManagedPassword GlobalSecurityGroup”
If you don’t use the -Path switch to specify a custom OU (using the DN format), the gMSA will be created in the “Managed Service Accounts” container.
Now that the gMSA is created, you need to switch over to the computers you’ll be using it on to put it into use. So on each computer you’ll be using it on, complete the following steps.
4. To use the gMSA on the computer(s) in question, you’ll need to issue the Install-ADServiceAccount PowerShell command. But to do that you’ll need the ActiveDirectory PowerShell module installed. The simplest way to do that if it isn’t already there is to install the Active
Directory Domain Services (ADDS) Remote Server Administration Tools (RSAT) by issuing the “Install-WindowsFeature -Name RSAT-ADDS”
5. After the ActiveDirectory PowerShell module is installed, run the Install-ADServiceAccount commandlet
Install-ADServiceAccount -Identity “gMSA_SomeService”
6. To test the account run the following command, the result of which should simply be “True”
7. Reboot the computer(s) if you used the global security group method
8. To add it to a service simply open “Services.msc”, find the appropriate service and open its properties and on the “Log On” tab specify the gMSA name as the account used for the services logon account. Be sure to add the ‘$’ at the end if you’re manually typing it in and to also use an empty password set. The computer will talk to AD and set the password for you, which of course was the entire point of this exercise.
There are other things to consider and problems you may come across. For starters, you may run across the following error message when you try and to install the account in step 5 above: “The provided context did not match the target”. The only time I’ve seen this is in secured environments. Odds are the “Network Security: Configure encryption types allowed for Kerberos” GPO setting (located at Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options) has been set to something other than the default, again, this is very prevalent in a DoD environment where you’re having to apply DISA STIGs. To get around this, adjust the GMSA with the following command on a DC and rerun step #6:
“Set-ADServiceAccount -Identity gMSA_SomeService -KerberosEncryptionType AES128,AES256”
Also, if you’re using the gMSA to run a scheduled batch job or scripts, it’ll need to be assigned the right to “Logon as a batch job”. This again could be locked down via a GPO and it may be best to assign the right to the global security group you created.
Depending on what you’re gMSA is being used for, it may also need to have other memberships, to include the local Administrators group on the computers you’re using it on.
(*) “Passwords” for gMSAs aren’t traditional passwords, nor are they actually “stored” in AD. They are generated as needed by the Domain Controllers. The msDS-ManagedPassword attribute is a BLOB with password information in it. When a machine attempts to use the password, it creates an encrypted RPC session to a DC. To be encrypted, the calling machine must authenticate to a DC. So, the gMSA password is just as secure as the machines computer account password that is changed by default every 30 days. You can see this by trying to query AD for the name of the account using the “User, Contacts, and Groups” query. You won’t find it there and will need to switch to a “Computers” query to find the gMSA object. You can also always use the “Get-ADServiceAccount” PowerShell command to query for gMSA accounts.