Windows OS Hub
  • Windows Server
    • Windows Server 2022
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2008 R2
    • SCCM
  • Active Directory
    • Active Directory Domain Services (AD DS)
    • Group Policies
  • Windows Clients
    • Windows 11
    • Windows 10
    • Windows 8
    • Windows 7
    • Windows XP
    • MS Office
    • Outlook
  • Virtualization
    • VMWare
    • Hyper-V
    • KVM
  • PowerShell
  • Exchange
  • Cloud
    • Azure
    • Microsoft 365
    • Office 365
  • Linux
    • CentOS
    • RHEL
    • Ubuntu
  • Home
  • About

Windows OS Hub

  • Windows Server
    • Windows Server 2022
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2008 R2
    • SCCM
  • Active Directory
    • Active Directory Domain Services (AD DS)
    • Group Policies
  • Windows Clients
    • Windows 11
    • Windows 10
    • Windows 8
    • Windows 7
    • Windows XP
    • MS Office
    • Outlook
  • Virtualization
    • VMWare
    • Hyper-V
    • KVM
  • PowerShell
  • Exchange
  • Cloud
    • Azure
    • Microsoft 365
    • Office 365
  • Linux
    • CentOS
    • RHEL
    • Ubuntu

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

May 11, 2021 Active DirectoryPowerShellWindows Server 2012 R2Windows Server 2016

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

Managed Service Account (MSA) is a special type of Active Directory account that can be used to securely run services, applications, and scheduled tasks. The basic idea is that the password for these accounts is completely managed by Active Directory. A complex password with a length of 240 characters is automatically generated for them, which changes automatically (by default, every 30 days). Only Kerberos is used for authentication (no NTLM security issues), interactive logon isn’t allowed, 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 with mimikatz or similar tools). This way, to start a service or unattended jobs, you don’t need to create individual service users in AD and manage their passwords.

Managed Service Accounts were introduced in Windows Server 2008 R2 (object type msDS-ManagedServiceAccount). Their main limitation is that such an account can only be used on one server (they cannot be used in cluster and NLB services). Therefore, Windows Server 2012 introduced Group Managed Service Accounts/gMSA (type msDS-GroupManagedServiceAccount). gMSA accounts can be used simultaneously on multiple hosts.

Let’s consider the features of using MSA and gMSA to launch services and tasks on servers and workstation in Active Directory.

Contents:
  • Create the Key Distribution Service (KDS) Key
  • How to Create a Managed MSA Account in Active Directory
  • Create a Group Managed Service Account (gMSA) in Active Directory
  • Installing Group Managed Service Account on Windows
  • How to Run a Windows Service under a Managed Service Account?
  • Running Scheduled Task with Managed Service Account/gMSA

Requirements for using MSA/gMSA service accounts:

Managed Service AccountGroup Managed Service Account
AD domain and forest functional levelWindows Server 2008 R2 or newerWindows Server 2012 or newer
KDCDomain controller with Microsoft Key Distribution Service (KdsSvc) enabled
PowerShellTo create and manage service AD accounts, you need to install the Active Directory module for Windows PowerShell
.Net Framework.NET Framework 3.5 or newer must be installed on the server
Supported Windows versionsWindows 7/Windows Server 2008 R2 or newerWindows Server 2012/Windows 8 or newer

Create the Key Distribution Service (KDS) Key

Before you start creating an MSA/gMSA account, you must to perform a one-time operation and create a KDS root key. To do it, run the following PowerShell command on the domain controller (Microsoft Key Distribution Services has to be installed and running):

Add-KdsRootKey –EffectiveImmediately

In this case the key is created and becomes available in 10 hours after the AD replication is over.

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

Make sure that the KDS root key has been created successfully:
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

How to Create a Managed MSA Account in Active Directory

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

New-ADServiceAccount -Name msaMunSrv1 –RestrictToSingleComputer

By default, MSA and gMSA are created in the container CN=Managed Service Accounts, but you can change the OU using the Path parameter.

Link your MSA service account to the target computer:

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

As a reminder, you can only use the MSA account on one AD host.

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

Managed Service Accounts in Active Directory

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

You can get the MSA account info using the command:

Get-ADServiceAccount msaMunSrv1

Get-ADServiceAccount

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 the password for this group service account. The easiest way to create and populate a group is 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

To create a Group Managed Service Account (gMSA), use the command:

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

New-ADServiceAccount - create gmsa PrincipalsAllowedToRetrieveManagedPassword

The gMSA account is also created by default in the Managed Service Accounts OU.

msDS-GroupManagedServiceAccount

Installing Group Managed Service Account on Windows

To use MSA / gMSA service accounts on target servers or workstations, you first need to install the Active Directory PowerShell module:

Add-WindowsFeature RSAT-AD-PowerShell

Install the MSA (gMSA) service account on the server:

Install-ADServiceAccount -Identity gmsaMunSQL1

Check if the service account is installed correctly:

Test-ADServiceAccount gmsaMunSQL1

If the command returns True, everything is configured correctly.

Install-ADServiceAccount - install gmsa account on Windows Server 2016

If the command returns False, most likely the MSA account is not installed on the server or this computer doesn’t have permissions 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 verify that your services and scripts can run under the MSA service account. Use the PsExec tool instead (we previously 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
    Replace the password with ~. This means that the password must be obtained from AD.
  3. In the cmd window that opens, run the whoami command to make sure that the console is running under the gMSA account; run cmd on behalf of gmsa (Group Managed Service Account)
  4. Verify that scripts, programs, or services are running correctly under a Managed Service Account.

Now it remains to configure the necessary Windows services, task scheduler tasks, IIS pools, etc., to run as MSA/gMSA user.

How to Run a Windows Service under a Managed Service Account?

You can now configure the required Windows service to run under a MSA/gMSA account.

  1. Open the service management console (services.msc);
  2. Open the properties of the required service and go to the “Log On” tab;
  3. Select the This account option and enter the name of the MSA account. Be sure to add the $ symbol at the end of the account name (you don’t need to enter the account password);
  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. After saving the changes, the service must be restarted.
To run complex services with gMSA, check the documentation to see if it is supported. Currently gMSA is supported in SQL Server, IIS, AD LDS, Exchange Server

Running Scheduled Task with Managed Service Account/gMSA

You can configure Windows Task Scheduler to run jobs under the gMSA service account. This is convenient because the passwords for the gMSA account are not stored in scripts, you don’t need to encrypt or protect them. When the password changes, you don’t have to reconfigure the task.

To grant permissions to the MSA/gMSA account, it is enough to add it to the required security group. For example, to the local Administrators group, Domain Admins, DNS Admins, etc.

You can configure the task to run as the gMSA account using PowerShell. For example, the following script will create a new scheduled task that runs a PowerShell script every day at 11:00 pm to backup the database:

$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
Register-ScheduledTask DBBackup –Action $action –Trigger $trigger –Principal $principal

using gMSA for scheduled task (powershell way)

Tip. To run a scheduled task, you need to grant the gMSA account “Log on as a batch job” permission.

The ‘-LogonType Password‘ argument specifies that the password for this gMSA account will be retrieved from the domain controller.

Learn more about managing scheduled tasks with PowerShell.

You can also create a scheduled job with the desired settings using the taskschd.msc GUI. Then you can reconfigure it using the schtasks.exe tool to run under a managed service account:

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

5 comments
2
Facebook Twitter Google + Pinterest
previous post
Using PowerShell Just Enough Administration (JEA) to Delegate Privileges to Non-Admin Users
next post
How to Reset the HP ILO Administrator Password?

Related Reading

Configuring Event Viewer Log Size on Windows

May 24, 2023

How to Detect Who Changed the File/Folder NTFS...

May 24, 2023

Enable Single Sign-On (SSO) Authentication on RDS Windows...

May 23, 2023

Allow Non-admin Users RDP Access to Windows Server

May 22, 2023

How to Create, Change, and Remove Local Users...

May 17, 2023

Categories

  • Active Directory
  • Group Policies
  • Exchange Server
  • Microsoft 365
  • Azure
  • Windows 11
  • Windows 10
  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • PowerShell
  • VMWare
  • Hyper-V
  • Linux
  • MS Office

Recent Posts

  • Configuring Event Viewer Log Size on Windows

    May 24, 2023
  • How to Detect Who Changed the File/Folder NTFS Permissions on Windows?

    May 24, 2023
  • Enable Single Sign-On (SSO) Authentication on RDS Windows Server

    May 23, 2023
  • Allow Non-admin Users RDP Access to Windows Server

    May 22, 2023
  • How to Create, Change, and Remove Local Users or Groups with PowerShell?

    May 17, 2023
  • Fix: BSOD Error 0x0000007B (INACCESSABLE_BOOT_DEVICE) on Windows

    May 16, 2023
  • View Success and Failed Local Logon Attempts on Windows

    May 2, 2023
  • Fix: “Something Went Wrong” Error When Installing Teams

    May 2, 2023
  • Querying Windows Event Logs with PowerShell

    May 2, 2023
  • Configure Windows LAPS (Local Administrator Passwords Solution) in AD

    April 25, 2023

Follow us

  • Facebook
  • Twitter
  • RSS
Popular Posts
  • Configure Google Chrome Settings with Group Policy
  • Get-ADUser: Find Active Directory User Info with PowerShell
  • How to Find the Source of Account Lockouts in Active Directory?
  • Get-ADComputer: Find Computer Properties in Active Directory with PowerShell
  • How to Disable or Enable USB Drives in Windows using Group Policy?
  • Configuring Proxy Settings on Windows Using Group Policy Preferences
  • Deploy PowerShell Active Directory Module without Installing RSAT
Footer Logo

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


Back To Top