Demystifying Managed (MSA) and Group Managed Service Accounts (gMSA)

Using Managed (MSA) or Group Service Accounts (gMSA) offers significant advantages over standard user-based Service accounts in an enterprise environment. Managed Service accounts provide a higher level of security and automation. Specifically designed for applications and services, they reduce the risk of password-related vulnerabilities. Managed accounts have automated password management, complex password policies and automatic password rotation. enhancing overall security posture. Group Service accounts on the other hand allow centralized management and granular access control for multiple users, simplifying permissions management and minimizing the risk of unauthorized access. In contrast, standard user accounts lack the specialized features necessary for secure and efficient application and service management, Making managed and group service accounts the superior choice for maintaining a robust and streamlined security infrastructure.

Key Distribution Services KDS Root Key

Before you create any Managed Service Account or Group Managed Service Account you are required to generate a root key. This allows the Domain Controllers to begin generating Managed or Group Managed Service account passwords.

The Root Key only needs to be created only once however you need to be a member of the Domain Admin or Enterprise Admin group to complete this procedure.

 Add-KdsRootKey -EffectiveImmediately

Note: Once you create the key, you must wait for up to 10 hours before you can begin creating managed or Group Managed Service accounts This is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering managed \ Group Managed Service account requests.

In Lab environments or sites with only a single Domain Controler, you can avoid the interval wait for key generation by using the following command..

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

Once the root key is created type Get-KDSRootKey and it will display all the information on the newly created key. Take note of the EffectiveTime If you have run the initial command. notice below it has added the effective time to 10 hours before the creation date.

To test if the root key is ready for use run this command.

 Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

If you get a result of True as pictured below it verifies that the KDSRootKey is working and we can now create our Managed or Group Managed Service Accounts.

Managed Service Accounts (MSA)

Managed Service Accounts also known as MSA or sMSA (Single Managed Service Account) are a Windows feature designed to enhance security and simplify the management of service accounts used by applications and services running on Windows Servers and clients. MSAs automate password management, eliminating the need to manually manage and update passwords for these accounts. With MSAs the system Generates and manages the passwords of the accounts, ensuring the secure and seamless operation of services without human intervention. However, MSAs have limitations in multi-server environments and cant be used for services that span multiple machines, Prompting the development of a more advanced Group Managed Service Accounts (gMSA) which has since superseded MSA.

New-ADServiceAccount -Name msa_Manageduser -RestrictToSingleComputer

Note: By default, Active Directory creates MSA and gMSA accounts in the Managed Service Accounts OU. You can change this by utilizing the Path parameter to specify a different OU.

Now run the command below to Link the managed Service Account to a particular device. In this example I have attached it to a Remote Desktop Server called RDS01. then you specify the managed Service account you just created.

$Identity = Get-ADComputer -identity RDS01
Add-ADComputerServiceAccount -Identity $Identity -serviceAccount msa_Manageduser

Managed service accounts will only work on this single Device that you specified here.

To See information regarding the managed service account run the command below

Get-ADServiceAccount msa_Manageduser

Group Managed Service Accounts (gMSA)

Group Managed Service Accounts (gMSAs) were introduced as an evolution of MSAs to address the limitations posed by individual MSAs. gMSAs are specifically designed for services that span multiple servers, such as clustered or load-balanced applications. They allow multiple machines to share the same account, enabling consistent authentication across the network without compromising security. Unlike individual MSAs, gMSAs leverage the Active Directory infrastructure to securely manage account passwords and SPNs (Service Principal Names). This results in simplified management, reduced security risks, and improved scalability for enterprise environments.

Essentially, while both MSAs and gMSAs fulfil the role of automating service account password management, gMSAs offer a more robust and flexible solution for modern network architectures. They enable services to scale and distribute seamlessly across multiple servers.

Create a Group

To initiate the process of setting up a gMSA (Group Managed Service Account), the first step involves creating a dedicated group. This group serves as the container for the computers on which you intend to use the gMSA account

In the Active Directory Users and Computers console, proceed by creating a new group.

Choose a name of your preference for the newly created group, then proceed by clicking ‘OK

After creating the group, double-click it to access its properties.

Within the ‘Members’ tab, select ‘Add’ to add the computers that the gMSA will have access to.

Computers are not a default selected object, so you’ll need to add them to this list. This is a common oversight. To do so, select ‘Object type.

Tick ‘Computers’ and then click ‘OK’

Finally, you can search for and select the specific computers where you intend to utilize the gMSA account.

You can search for individual PCs by their names…

You can also employ nested groups such as ‘Domain Computers’ or ‘Domain Controllers’ for added flexibility.

Create a Group with Powershell

If you prefer working in PowerShell, you can create a new group using the following command.

New-ADGroup 'gMSA_test2' -path 'OU=Groups,OU=Empire,dc=empire,dc=local' -GroupScope Global -PassThru -verbose

You can then use ‘Add-ADGroupMember’ to add the desired computers to the group, enabling the gMSA account to function on them.

Add-ADGroupMember -Identity gMSA_test2 -Members dc01$, 'Domain Computers'

Note: Keep in mind that after adding any computer accounts to a group, it’s essential to reboot the respective devices for group membership changes to take effect.

Creating the Group Managed Service Account (gMSA)

Now we need to actually create the group managed service account. For this, you need to be in administrative Powershell and type the command below. spcifie a name for the gMSA account, the host name of your DNS server and the group that you want to attach the account to. “gMSA_test”

To create the Group Managed Service Account (gMSA), open an administrative PowerShell session and execute the following command. Be sure to specify a name for the gMSA account, the hostname of your DNS server, and the group to which you want to attach the gMSA account, which in this case is a group called ‘gMSA_test’

New-ADServiceAccount -Name GroupManaged -DNSHostName dc01.empire.local -PrincipalsAllowedToRetrieveManagedPassword gMSA_test -verbose

After creating the gMSA, you can verify its presence by navigating to Active Directory Users and Computers, and then selecting ‘Managed Service Accounts.’ Here, you should be able to see the newly created gMSA account.

Note: Please note that the gMSA is distinguishable by its icon, which resembles a cogwheel, setting it apart from both user and group icons in Active Directory.

Add Security Groups to gMSA

Finally, to complete the configuration, you will need to assign the necessary permissions to the gMSA account. In this example, ‘GroupManaged’ is added to the ‘Domain Admins’ group. However, in a production environment, it’s crucial to grant the gMSA account only the permissions required for its specific task, following the principle of least privilege.

Ensure that the account you’ve added is indeed the gMSA account, identifiable by its distinctive cogwheel icon.

Add gMSA to a Windows Service

Group Managed Service Accounts (gMSA) offer benefits when used with services in Windows environments, simplifying service management by automatically handling password complexities and rotations, enhancing security with reduced risk of credential exposure, ensuring reliable service operation,

To add a gMSA (Group Managed Service Account) to a Windows service, start by ensuring that you are on a device specified in the attached group. Then, simply navigate to the properties of the service and modify the ‘Log On’ section, adding the gMSA account as the service’s logon credential.

Allow me to illustrate the process using the ‘Unquoted Service Path’ tutorial as an example. After right-clicking on the service you wish to associate with the gMSA account, select ‘Properties’.

Next, navigate to the ‘Log On’ tab and click ‘Browse’ to select the gMSA account. You can recognize the correct account by the trailing ‘$’ sign, indicating it’s a gMSA. Remove any password from both of the password boxes, as gMSA passwords are managed in Active Directory. Finally, select ‘OK’ to confirm your changes.

You will receive a prompt confirming the grant of the ‘Log on as a Service’ right to the gMSA account. Click ‘OK’ to acknowledge this

How to remove a gMSA account from a Windows Service

Please note that once you configure a service with a gMSA account, you won’t have the ability to change the account settings on the ‘Log On’ tab. This effectively locks the service to the specified gMSA account.

If you need to switch the service account after it has become locked to a gMSA, you can employ the ‘sc’ command. Specify the service name you want to modify and provide the username and password for the new account. Here’s an example using the ‘vagrant’ user, who is also a domain admin, though it can be any valid domain credentials:

sc config <ServiceName> obj= domain\username password= password

After running the ‘sc’ command to update the service account, refresh the services GUI. You should now observe that the service, previously associated with the gMSA account, is no longer locked out. You’ll be able to change the ‘Log On’ settings for this service as needed.

Add gMSA To A Server Principle Name (SPN)

Using Group Managed Service Accounts (gMSA) for Service Principal Names (SPNs) in Windows environments offers several advantages. gMSAs enhance security by automatically managing complex passwords and rotating them, reducing the risk of security breaches. They simplify service account management by eliminating the need for manual password updates and enabling delegated authority for account management tasks.

Adding a gMSA (Group Managed Service Account) to a Service Principal Name (SPN) is straightforward. If we use the SPN from the Kerberosting tutorial as an example, you can simply add your gMSA account by including its name followed by a ‘$’ when creating the SPN using the ‘SetSPN’ command, like so

setspn -S http/dc01.empire.local:8081 GroupManaged$

Add gMSA to Scheduled Tasks

Using Group Managed Service Accounts (gMSAs) in conjunction with scheduled tasks in Windows environments offers several distinct advantages. These accounts enhance security by autonomously managing passwords, ensuring that scheduled tasks always execute with up-to-date, strong credentials. This reduces vulnerability to security breaches caused by outdated or weak passwords. Additionally, gMSAs streamline task management by eliminating the need for manual password updates, ultimately reducing administrative workload.

Configuring Task Scheduler to run jobs under a gMSA service account represents a best practice since it eliminates the need to store passwords for the gMSA account in scripts, thus eliminating the necessity for encryption to protect them. Furthermore, when the gMSA password changes, there’s no requirement to reconfigure the task, simplifying task maintenance and security.

To test, access Task Scheduler and proceed to create a new task.

You can name the new task as you prefer, and then, within the “Security Options” section, click on “Change User or Group…

I’m not entirely sure why this occurs, and if anyone reading this has insights, please feel free to share them in the comments. However, when you attempt to input just the name of your gMSA service account, you may encounter an error indicating that the user cannot be located.

After encountering the error, proceed by clicking on ‘Object Types.

Deselect all options except ‘Service Accounts,’ and then click ‘OK

You will now be able to locate your gMSA account. Click ‘OK’ to proceed.

You will notice the account added with a trailing ‘$’ symbol, which signifies that it’s a service account.

Add a gMSA to a Scheduled task with Powershell

When it comes to Microsoft, PowerShell allows you to create scheduled tasks. The following command demonstrates adding a gMSA to a scheduled task. The key here is the ‘-Logontype Password,’ which indicates that the gMSA account will fetch its password from the domain controller.

$action = New-ScheduledTaskAction -Execute powershell.exe  -Argument "-file C:\PS\Scripts\backup.ps1 -executionpolicy bypass -NoProfile"
$trigger = New-ScheduledTaskTrigger -At 18:30 -Daily
$principal = New-ScheduledTaskPrincipal -UserID Empire\GroupManaged$ -LogonType Password
Register-ScheduledTask gMSA_Test –Action $action –Trigger $trigger –Principal $principal

Transitioning Users to Group Managed Service Accounts (gMSA) within Existing Scheduled Tasks

If you’ve already created a scheduled task and now wish to incorporate a gMSA account, you can execute the following command:

schtasks /Change /TN gMSA_test  /RU "empire\GroupManaged$" /RP "*"

• /Change: This option is used to modify an existing scheduled task.
• /TN gMSA_test: Specify the name of the task you want to change.
• /RU Empire\GroupManaged$: Set the Run As User to the gMSA account you want to use. Replace “Domain” with your domain name and “gMSA_Account” with the actual name of your gMSA.
• /RP "*": The /RP (Run As Password) the parameter is set to “*” to indicate that the password is managed by the system for gMSAs.