Windows OS Hub
  • Windows
    • Windows 11
    • Windows Server 2022
    • Windows 10
    • Windows Server 2019
    • Windows Server 2016
  • Microsoft
    • Active Directory (AD DS)
    • Group Policies (GPOs)
    • Exchange Server
    • Azure and Microsoft 365
    • Microsoft Office
  • Virtualization
    • VMware
    • Hyper-V
  • PowerShell
  • Linux
  • Home
  • About

Windows OS Hub

  • Windows
    • Windows 11
    • Windows Server 2022
    • Windows 10
    • Windows Server 2019
    • Windows Server 2016
  • Microsoft
    • Active Directory (AD DS)
    • Group Policies (GPOs)
    • Exchange Server
    • Azure and Microsoft 365
    • Microsoft Office
  • Virtualization
    • VMware
    • Hyper-V
  • PowerShell
  • Linux

 Windows OS Hub / Active Directory / Using Managed Service Accounts (MSA and gMSA) in Active Directory

October 11, 2024

Using Managed Service Accounts (MSA and gMSA) in Active Directory

You can use Managed Service Accounts (MSA) to securely run services, applications, and scheduler tasks on servers and workstations in an Active Directory domain. The MSA is a special type of account for which the AD generates a complex password (240 characters) and automatically changes the password every 30 days. MSA cannot be used for interactive login, the password is not known to anyone and is not stored on the local system (you cannot extract the password from the LSASS system process using mimikatz or similar tools). So to run services or automated jobs, you don’t have to create separate service users in AD and manage their passwords.

This article shows how to create MSA and gMSA accounts and use them to securely run services and scheduled tasks on Windows computers in an AD domain.

Contents:
  • How to Create a Managed Account (MSA) in Active Directory
  • Create a Group Managed Service Account (gMSA) in Active Directory
  • Install Managed Service Account on Windows
  • How to Run a Windows Service as a Managed Service Account
  • Run Windows Scheduled Task with Managed Service Account (gMSA)

There are two types of service accounts in AD:

  • Managed Service Accounts (MSA) – introduced in Windows Server 2008 R2 (msDS-ManagedServiceAccount object type). The main limitation is that such an account can only be used on a single server (it cannot be used to run cluster services);
  • Group Managed Service Accounts (gMSA) – introduced in Windows Server 2012 (msDS-GroupManagedServiceAccount object type). You can use GMSA accounts on multiple Windows servers.

How to Create a Managed Account (MSA) in Active Directory

Before you start creating AD-managed service accounts, you must perform a one-time operation of creating a KDS root key on a domain controller with the KdsSvc service enabled. This key is used to generate the GMSA password.

Add-KdsRootKey –EffectiveImmediately

In this case, the key is created and becomes available 10 hours after the AD replication has finished.

Tip. For immediate use of the KDS key in the test environment, you can run this command:
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Check that the KDS root key has been successfully created:
Get-KdsRootKey
Add-KdsRootKey - Create the Key Distribution Services KDS Root Key with PowerShell

Use the command to check the KDS key:

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

Test-KdsRootKey

To create a new managed service account (MSA) in AD, use the command:

New-ADServiceAccount -Name msaMunSrv1 –RestrictToSingleComputer

Link your MSA service account to the target computer (to bind, the msDS-HostServiceAccount attribute is used in the computer account properties):

$Identity = Get-ADComputer -identity mun-srv01
Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaMunSrv1

Remember that you can only use one MSA account on one domain server.

Open the ADUC (Active Directory Users and Computers) console and make sure that a new account of type msDS-ManagedServiceAccount has appeared in CN=Managed Service Accounts container.

Managed Service Accounts in Active Directory

This AD container is hidden by default. To display it, enable the Advanced Features option in the View menu of the ADUC snap-in.

Create a Group Managed Service Account (gMSA) in Active Directory

Before creating the gMSA account, create a domain security group and add servers to it that will be allowed to use this service account. You can create and populate a group using PowerShell:

New-ADGroup grMunSQL1 -path 'OU=Groups,OU=Munich,OU=DE,dc=woshub,DC=com' -GroupScope Global -PassThru –Verbose
Add-AdGroupMember -Identity grMunSQL1 -Members mun-sql01$, mun-sql02$, mun-sql03$

create a security group for the gMSA account in AD

Create a Group Managed Service Account (gMSA) and bind it to the grMunSQL1 security group:

New-ADServiceAccount -name gmsaMunSQL1 -DNSHostName gmsaMunSQL1.woshub.com -PrincipalsAllowedToRetrieveManagedPassword grMunSQL1 –verbose

New-ADServiceAccount - create gmsa PrincipalsAllowedToRetrieveManagedPassword

Reboot servers that have been added to the group, or you can refresh the server’s AD group membership without rebooting:

klist.exe -lh 0 -li 0x3e7 purge

The gMSA account is also created by default in the Managed Service Accounts OU. The msDS-GroupMSAMembership attribute in the gMSA account properties links an account to a Windows host or AD group.

msDS-GroupManagedServiceAccount

Some services require a Service Principal Name (SPN) registration for Kerberos authentication to work correctly. Managed service accounts can be used for SPN registration:

setspn -s MSSQLSvc/munsql01 woshub\gmsaMunSQL1$
setspn -s MSSQLSvc/munsql01.woshub.loc woshub\gmsaMunSQL1$

Install Managed Service Account on Windows

To use MSA/gMSA service accounts on domain servers or workstations, you must first install the PowerShell module for Active Directory and the .NET Framework 3.5+:

Add-WindowsFeature RSAT-AD-PowerShell

Install the MSA service account on the server:

Install-ADServiceAccount -Identity gmsaMunSQL1

Only MSA accounts need to be installed in this way. Skip this step for gMSA. It is sufficient for this server to have been added to the PrincipalsAllowedToRetrieveManagedPassword attribute of the gMSA account in the AD:

Get-ADServiceAccount gmsaMunSQL1 -Properties PrincipalsAllowedToRetrieveManagedPassword

Check that the service account is properly installed:

Test-ADServiceAccount gmsaMunSQL1

If the command returns True, this service account can be used on this Windows host.

Install-ADServiceAccount - install gmsa account on Windows Server 2016

If the command returns False, it is most likely that the MSA account is not installed on Windows or that current computer account doesn’t have permission to use it:

Test-ADServiceAccount

WARNING: Test failed for Managed Service Account gmsaMunSQL1. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA.

You cannot use standard RunAs to check that your services and scripts can run under the MSA service account. Use the PsExec tool instead (previously we showed you how to use psexec to run the command prompt on behalf of NT Authority\System).

  1. Open the command prompt as administrator;
  2. Run the command: PsExec64.exe -i -u woshub\gmsaMunSQL1$ -p ~ cmd.exe
    The ~ symbol replaces the password. This means that the computer needs to get the account password from AD.
  3. In the new cmd prompt, run the whoami command to ensure that the console is running under the gMSA account; run cmd on behalf of gmsa (Group Managed Service Account)
  4. Make sure that any scripts, services, or applications that you require can run correctly under a managed service account.

The next step is to configure the necessary Windows services, scheduler jobs, IIS pools, etc. to run as an MSA or gMSA user.

How to Run a Windows Service as a Managed Service Account

Let’s look at configuring a specific Windows service to run under the AD-managed service account.

  1. Open the service management console (services.msc);
  2. Open the properties of the service you need and go to the “Log On” tab;
  3. Select the This account option and enter the name of the MSA account. Add the $ symbol to the end of the account name (no password is required);
  4. The MSA service account will be automatically granted Log On As a Service permissions; configure windows service to run from gMSA service account
  5. Save the changes and restart the service.

To run an IIS application pool on behalf of the Managed Service Account, open the apppool Advanced Settings and change the Identity field from ApplicationPoolIdentity to Custom Account -> woshub\gmsaMunSQL1$ (leave the password field blank):

Using Group Managed Service Accounts with IIS

Or you can use PowerShell to specify the MSA account for the IIS application pool:

Import-Module WebAdministration
$pool = Get-Item IIS:\AppPools\wpad
$pool.processModel.identityType = 3
$pool.processModel.userName = "woshub\gmsaMunSQL1$"
$pool.processModel.password = ''
$pool | Set-Item

To run complex Windows services with gMSA, check the documentation to see if they are supported. Currently, gMSA is supported in SQL Server, IIS, AD LDS, and Exchange Server.

Run Windows Scheduled Task with Managed Service Account (gMSA)

You can configure the Windows Task Scheduler to run jobs under the MSA service account. This is convenient because the passwords for the MSA accounts are not explicitly stored in the scripts, and you do not need to encrypt or protect them. If the domain controller changes the service account password, there is no need to reconfigure the Task.

The only way to configure a scheduled task to run as a gMSA is by using PowerShell. For example, the following script creates a new scheduled task that runs a PowerShell script to backup the database every day at 11:00 pm:

$action = New-ScheduledTaskAction -Execute powershell.exe  -Argument "-file C:\PS\Scripts\DBBackup.ps1 -executionpolicy bypass -NoProfile"
$trigger = New-ScheduledTaskTrigger -At 23:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID woshub\gmsaMunSQL1$ LogonType Password -RunLevel Highest
Register-ScheduledTask DBBackup –Action $action –Trigger $trigger –Principal $principal

Learn more about managing scheduled tasks with PowerShell.

using gMSA for scheduled task (powershell way)

You can also create a scheduled task with the necessary settings using the taskschd.msc GUI. Then reconfigure it to run under a Managed Service Account using the schtasks.exe console command:

schtasks /Change /TN BackupDB /RU "woshub\gmsaMunSQL1$" /RP ""

Grant the necessary service permissions and NTFS permissions on the file system to the MSA/gMSA account. For example, I added gMSA to the server’s local Backup Operators group:

Add-LocalGroupMember -Group "Backup Operators" -Member woshub\gmsaMunSQL1$

grant local permissions to managed service account

To run scheduler tasks, you must grant the gMSA account the Log on as a batch job permission. This can be done using the local GPO editor on a standalone computer: gpedit.msc -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment. Add an account to the policy: woshub\gmsaMunSQL1$

grant logon as batch job permission for gmsa account

14 comments
6
Facebook Twitter Google + Pinterest
Active DirectoryPowerShellWindows 10Windows Server 2019Windows Server 2022
previous post
Parted: Create and Manage Disk Partitions on Linux
next post
How to Reset the HP ILO Administrator Password?

Related Reading

How to Refresh (Update) Group Policy Settings on...

August 13, 2024

Repairing the Domain Trust Relationship Between Workstation and...

May 16, 2024

Backing Up Active Directory with Windows Server Backup

November 26, 2024

Unable to Access SYSVOL and NETLOGON folders from...

May 10, 2023

Updating Group Policy Administrative Templates (ADMX)

January 24, 2025

Configuring Password Policy in Active Directory Domain

March 12, 2024

Troubleshooting: Group Policy (GPO) Not Being Applied to...

March 15, 2024

Checking Active Directory Domain Controller Health and Replication

May 15, 2025

14 comments

Greg H. September 11, 2018 - 5:52 pm

Your comment about changing the password interval is incorrect according to the Microsoft Documentation for the CMDlet (https://docs.microsoft.com/en-us/powershell/module/activedirectory/set-adserviceaccount). Running get-help for Set-ADServiceAccount also does not show this parameter in the syntax. The proper way would be to use the -Replace parameter and to specify @{‘msDS-ManagedPasswordInterval’=’60’}; however, you then get an error “The attribute cannot be modified because it is owned by the system”. This can be further verified under the technical specification for the attribute (https://msdn.microsoft.com/en-us/library/cc220154.aspx).

It seems the only way to achieve a different password interval is to recreate the service account. If you do this, you’ll need to make sure that you replace any references to this account as recreating it will break any prior usage of an account with a similar name.

Reply
Jonas B. Knudsen May 5, 2022 - 10:37 pm

I believe this statement in the beginning is false: “Only Kerberos is used for authentication (no NTLM security issues)”.
I’m able to pass-the-hash with my gMSA account in to a machine where my gMSA is admin, and the 4624 event reveals it is a NTLMv2 logon.

Reply
Manuel M. May 24, 2022 - 2:28 pm

This manual is great! Thank you very much.
In my case i couldnt use the following command in powershell on the target server: “Install-ADServiceAccount -Identity gmsaMunSQL1”

I fixed this, after logging in, as domain administrator on the target server.

What kind of rights does my serveradministrator need, to do this command? I have local adminrights. But it seems to be not enough. I want to remove local admin rights on my servers for the “domainadmin”-Group. Do you have any suggestions?

Reply
Michael Turner June 28, 2022 - 12:58 pm

Not sure that the Domain and Forest functional level requirements are correct. Nothing on the Microsoft gMSA requirements suggest that any particular functional level requirement exists. What is true is that gMSA requires 2012 Schema extensions and at least one 2012 DC to operate. The Microsoft documentation even hints that down-level functional levels are supported because by virtue of saying at least on 2012 DC they are implying that down-level DC versions can co-exist and therefore the functional level cannot be 2012 in that situation.

Reply
Musklor February 3, 2023 - 9:29 pm

Hi, why not a domain local group? (And inside the computers)

New-ADGroup grMunSQL1 -path ‘OU=Groups,OU=Munich,OU=DE,dc=woshub,DC=com’ -GroupScope Global -PassThru –Verbose
Add-AdGroupMember -Identity grMunSQL1 -Members mun-sql01$, mun-sql02$, mun-sql03$

Reply
Jarek November 16, 2023 - 9:28 pm

Thank you for this article. But you failed to cover the most important part:
Test-ADServiceAccount gmsaMunSQL1
If the command returns False, most likely the MSA account is not installed on the server or this computer doesn’t have permission to use it
howto fix it?! it works on one DC, not on another one. I have set perms several times, nothing has changed… actually on the DC where it works, it should not, as the perms are not granted.
PS C:\EREG> get-ADComputerServiceAccount soads04…

DistinguishedName : CN=isimsrv,CN=Managed Service Accounts,DC=*,DC=*,DC=com
Enabled : True
Name : isimsrv
ObjectClass : msDS-GroupManagedServiceAccount
ObjectGUID : c034d2c1-a66a-…
SamAccountName : isimsrv$
SID : S-1-5-21-4066787879-1376076192-…
UserPrincipalName :

PS C:\EREG> Get-ADServiceAccount -Identity isimsrv -Properties * |select host*

HostComputers
————-
{CN=SOADS04…,OU=Domain Controllers,DC=*,DC=*,DC=com}

and the test works on the other DC 03… however it’s NOT in the host computers.

Reply
admin November 20, 2023 - 8:15 am

Have you tried to install the gMSA on the host computer by using the following command?
Install-ADServiceAccount -Identity gmsaMunSQL1

Reply
Jorge July 18, 2024 - 7:02 am

What about the new w2k25 DMSA?

Reply
Phil October 4, 2024 - 12:08 pm

Hi

I am testing the deployment of group managed service accounts (gMSA) in our domain and l am following the instructions. So far l have managed to install the KDS root key, created a security group and added host machines, however when l try and run this Powershell command which will create a Group Managed Service Account (gMSA) and bind it to a security group. I am already created. I get an error message that says “New-ADServiceAccount : Parameter: ‘Path’ is required for this operation” I read this error has to do with the DNSHostName and the domain name field being incorrect, I have checked and it’s correct so l would appreciate any assistance.

New-ADServiceAccount -name gmsaBDLApp01 -DNSHostName gmsaBDLApp01.adbd.Daemon.org -ManagedPasswordIntervalInDays 2 -PrincipalsAllowedToRetrieveManagedPassword grBDLApp01 –verbos

Reply
admin October 5, 2024 - 6:02 pm

Try specifying the distinguishedName of the OU where the new object will be created in the -Path parameter. For, example add:
-Path "CN=Managed Service Accounts,DC=adbd,DC=Daemon,DC=org"

Reply
Phil October 7, 2024 - 10:38 am

Hi
I have already tried to enter a path to which OU l would like the account to be created like -Path “ou=gMSA,ou=Service Accounts Accounts,DC=adbd,DC=Daemon,DC=org” but l am still getting the same error message

Reply
Phil October 8, 2024 - 9:42 am

Please ignore my last message adding the path worked, l wasn’t initially granted full admin rights, and now l have so it worked many thanks for you help!

Reply
Jiri November 19, 2024 - 5:22 pm

I created gMSA account according to this guide and it is possible to assign it to services on the server without issues. Services are running under this account.
However there is a service which manages (CRUD) other services. This service is running under gMSA account.
When the service need to create new Windows service, the operation fails.
When I run PowerShell under gMSA account I also can not manually create a service, while it is possible for Administrator.
Do you have any advice, where and what could be setup?
Assigning gMSA account to Administrators group is no option.

PS C:\Windows\System32> whoami
adamant\gmsamyq1$
PS C:\Windows\System32> New-Service -Name AAAservice -BinaryPathName “C:\Apps\ProcessExplorer\procexp64.exe”
New-Service: Service ‘ (AAAservice)’ cannot be created due to the following error: Access is denied.

Reply
Jiri November 20, 2024 - 10:13 am

Digging further I found out that the service management is not possible without Administrative rights. So the only possibility is to assign the account to Administrators group. I will have to reconsider overall usability of this approach.
https://learn.microsoft.com/cs-cz/windows/win32/services/service-security-and-access-rights?redirectedfrom=MSDN

Reply

Leave a Comment Cancel Reply

join us telegram channel https://t.me/woshub
Join WindowsHub Telegram channel to get the latest updates!

Recent Posts

  • Map a Network Drive over SSH (SSHFS) in Windows

    May 13, 2025
  • Configure NTP Time Source for Active Directory Domain

    May 6, 2025
  • Cannot Install Network Adapter Drivers on Windows Server

    April 29, 2025
  • Change BIOS from Legacy to UEFI without Reinstalling Windows

    April 21, 2025
  • How to Prefer IPv4 over IPv6 in Windows Networks

    April 9, 2025
  • Load Drivers from WinPE or Recovery CMD

    March 26, 2025
  • How to Block Common (Weak) Passwords in Active Directory

    March 25, 2025
  • Fix: The referenced assembly could not be found error (0x80073701) on Windows

    March 17, 2025
  • Exclude a Specific User or Computer from Group Policy

    March 12, 2025
  • AD Domain Join: Computer Account Re-use Blocked

    March 11, 2025

Follow us

  • Facebook
  • Twitter
  • Telegram
Popular Posts
  • Configure Google Chrome Settings with Group Policy
  • Get-ADUser: Find Active Directory User Info with PowerShell
  • How to Disable or Enable USB Drives in Windows using Group Policy
  • How to Find the Source of Account Lockouts in Active Directory
  • Get-ADComputer: Find Computer Properties in Active Directory with PowerShell
  • Configuring Proxy Settings on Windows Using Group Policy Preferences
  • Adding Domain Users to the Local Administrators Group in Windows
Footer Logo

@2014 - 2024 - Windows OS Hub. All about operating systems for sysadmins


Back To Top