With Active Directory user objects comes the burden with password management. With many business critical applications dependent on user objects, the ability to get a maintenance window to change a password can be a hard battle for an Active Directory administrator or application owner. When that user object is used by many applications, the burden is magnified to near impossibility because of the downtime required. These “service account” passwords become institutional knowledge and reused over time on systems that the password was not originally intended. What Innova Solutions architects discover time-and-time again at our clients are those application-based user objects set with their password to never expire. The previously mentioned simple password never expires report will bring these user objects to the surface if they exist in your organization.

Microsoft started to recognize the issue of administrators using normal user objects to run services like SQL server, scheduled tasks, app pools, or grant application access to Active Directory with the introduction of Windows Server 2008 and Managed Services Accounts (sMSA). By Windows Server 2012, Microsoft greatly improved on this concept with the Group Managed Service Account (gMSA). A gMSA is an Active Directory object that can act like a user object for security assignment and behave like a computer object for password management. If a gMSA is assigned for use to a computer object, the computer will automatically negotiate its password with a Domain Controller. The Application owner never needs to know the password and the application itself never has to have the password changed. Behind the scenes, Active Directory and the computer manage the 120-character password
rotation every 30 days without downtime or human interaction. Tools like HashCat are not going to crack the 120-character password as it will be computationally impossible with current GPUs.

Our experience with Microsoft native applications shows that we can reduce the number of user objects providing security and domain access by ~65% using gMSA objects with failover clustering being the main area where the use is not supported. Your milage may vary with third-party software vendors but if the application runs as a Windows Service, App pool, Batch Job, or Scheduled Task, there is a high probability that a gMSA will work for your application. If you have Windows Server 2012 Domain Controllers in your environment, you can implement gMSA objects within the timeframe of your change control policies. The process is simple and fast. Be aware you need to be a Domain or Enterprise Administrator in order to implement the changes required in production. Be
sure to review all changes in your Active Directory test lab and follow your standard change control process.

If no key is present, you can create one on a 64-bit Windows Server 2012 or better domain controller using the Active Directory PowerShell Module. Once this command is issued, it will take some time for the KDS Root Key to replicate the key in the Configuration container of the Forest. You should delay the usage until replication has passed which depends on the number of domain controllers in the environment and bandwidth. Checking the configuration container as shown above with Get-ADObject on a domain controller will reveal if the key is present.

By default all gMSA objects created will be store in the CN=Managed Service Accounts root container in your domain. This cmdlet will create a basic gMSA object with the name gmsa-Account. It cannot be used until it is assigned to a computer object. There is no requirement to prefix your gMSA object name with gmsa- .

While we can set the computer object(s) we want to allow to use the gMSA when creating it using New -ADServiceAccount , in this demo we will assign the principal with the Set-ADServiceAccount cmdlet using the PrincipalsAllowedToRetrieveManagedPassword argument to allow SERVER01 to retrieve the account and password.

You can review your update on the gMSA using the Get-ADServiceAccount .

Unlike a normal user object, you have to install the gMSA on the member server. in order to perform that installation you must have the Active Directory PowerShell Module locally installed on the target.

Install Active Directory RSAT Windows Feature

gMSA Installation

Once the member server has the Active Directory PowerShell Module available, you can run the Install-ADServiceAccount cmdlet to install the gMSA and assign it to a Windows Service, App pool, Scheduled Task, or other compatible service. One common issue with installing a gMSA is that the kerberos ticket on computer does not have a reference to the delegation immediately. There are two solutions to this problem. First is the standard Windows administrator trick, reboot. Another solution is the reset the local Kerberos ticket using klist and get a fresh one with the referenced delegation. That example is included here.

gMSA CmdLets

You can explore more of the PowerShell tools used for the management by reviewing the ADServiceAccount cmdlets.

Back