- 11 minutes to read

Configure Group Managed Service Accounts (gMSA)

New 7.x

Empower your Nodinite v7 environment with automated, secure service account management. A Group Managed Service Account (gMSA) provides automation for service account password rotation — eliminating password expiration issues, enhancing security, and is compatible with Nodinite's certificate encryption features.

What are Group Managed Service Accounts?

In traditional Windows service account management, administrators face a painful cycle: passwords expire, services break, and manual updates risk downtime. Group Managed Service Accounts (gMSA) solve this problem completely.

The Traditional Service Account Problem

  • Password expiration - IT must manually update passwords before they expire (30, 60, or 90-day cycles)
  • Service disruption - Forgotten password updates cause production outages
  • Security exposure - Passwords stored in documentation or shared among team members
  • Manual coordination - Updating passwords requires coordinating across multiple servers and services
  • Audit complexity - Tracking who changed what password when becomes difficult

The gMSA Solution

gMSA accounts are special service accounts where Active Directory automatically rotates the password every 30 days without any manual intervention. No administrator ever sees or knows the password.

Key Benefits

  • ✅ Eliminate password expiration management - Passwords rotate automatically every 30 days for gMSA accounts
  • ✅ Enhanced security - Password never stored or known to administrators
  • ✅ Certificate-based encryption compatible - Works with Nodinite v7's secret management
  • ✅ Simplified compliance - Automatic rotation meets security audit requirements
  • ✅ Zero downtime - No service restarts needed for password changes
  • ✅ Multi-server support - Same gMSA account across multiple servers
  • ✅ Multi-service support - Same gMSA account across multiple agents and services

Understanding the gMSA Architecture

The diagram below shows how Group Managed Service Accounts work with Active Directory, Nodinite servers, and certificate-based encryption:

graph TB AD[" Active Directory Domain"] KDS[" KDS Root Key"] DC1[" Domain Controller 1"] DC2[" Domain Controller 2"] GMSA[" gMSA Account"] SG[" Security Group
(Server Members)"] SERVER[" Nodinite Server"] CERT[" LocalMachine
Certificate Store"] IIS[" IIS App Pools
(Web Client, API, Services)"] SVCWIN[" Windows Services
(Remote Agents)"] AD --> KDS KDS --> DC1 KDS --> DC2 DC1 -."10 hours replication".-> DC2 AD --> GMSA GMSA --> SG SG --> SERVER SERVER --> CERT CERT --> IIS CERT --> SVCWIN style GMSA fill:#90EE90 style CERT fill:#FFD700 style IIS fill:#87CEEB style SVCWIN fill:#87CEEB style KDS fill:#90EE90

This diagram shows the gMSA architecture: Active Directory creates the KDS root key, which replicates to all domain controllers. The gMSA account is installed on Nodinite servers via security group membership. Certificates in the LocalMachine store (yellow) are used by IIS app pools and Windows services (blue) for encryption.

Warning

Nodinite v7's certificate-based encryption requires SHA-256 or higher signature algorithms. SHA-1 certificates are deprecated and will cause installation failures. Always use modern hash algorithms (SHA-256, SHA-384, or SHA-512) when generating or obtaining certificates for gMSA accounts. See Microsoft's SHA-1 deprecation guidance for details.

Important

  • gMSA accounts are only supported in Nodinite v7 and later. If you are running Nodinite v6 or earlier, you must use traditional service accounts. See How to set Logon as a Service right for traditional account setup.
  • When using gMSA accounts with Nodinite v7, you must manually provision and manage certificates in the LocalMachine certificate store. Unlike traditional service accounts where Nodinite auto-generates certificates, gMSA accounts require you to provide certificates from your own PKI or certificate authority. See Install Certificates for gMSA for PowerShell scripts and step-by-step instructions.

When to Use gMSA vs Traditional Service Accounts

Feature gMSA (Recommended for v7+) Traditional Service Account
Password Management ✅ Automatic 30-day rotation ❌ Manual, subject to expiration policies
Certificate Management (v7) ⚠️ Manual - You must provide and manage certificates ✅ Auto-generated and managed by Nodinite
Certificate Store Location LocalMachine (shared across services) Personal (user profile)
Nodinite v7 Encryption ✅ Fully compatible (with manual cert setup) ✅ Fully compatible (auto cert setup)
Setup Complexity ⚠️ Requires AD configuration + manual certificate ✅ Simple (create account, set password)
Multi-Server ✅ Same account across all servers ✅ Same account across all servers
Security Audits ✅ Automatic password compliance ⚠️ Manual password rotation tracking
Nodinite Version v7+ ONLY All versions (v5, v6, v7+)

Recommendation:

  • Use gMSA if you have automated certificate management infrastructure (e.g., internal PKI, cert renewal processes) and want automatic password rotation (Nodinite v7+ required)
  • Use Traditional Account for simpler setup with Nodinite-managed certificates, or if you lack certificate management infrastructure, or if running Nodinite v6 or earlier

For traditional service account setup, see How to set Logon as a Service right.

Which Nodinite Services Support gMSA?

The following Nodinite components support gMSA accounts:

gMSA accounts still require the "Log on as a service" right on each server, just like traditional accounts. See the Logon as a Service page for details on setting this local policy.

Some Monitoring Agents also require the gMSA account to be part of the local Administrators group. Review the prerequisites page for each agent you plan to deploy.

Active Directory and Infrastructure Prerequisites

  1. Windows Server 2012 or higher forest functional level
  2. Windows Server 2012 or higher domain member servers (Windows 8 or newer domain-joined computers also supported)
  3. 64-bit architecture to run PowerShell commands to manage gMSA
  4. Active Directory PowerShell module must be installed on the Domain Controller or management workstation
  5. Dedicated security group (e.g., gmsaservergroup) created in Active Directory
    • Add all servers that will use the gMSA into this group

Tip

Create one security group per gMSA account for better control. For example:

  • Nodinite-Prod-Servers for production environment gMSA
  • Nodinite-Test-Servers for test environment gMSA

Step 1: Create the KDS Root Key

The KDS (Key Distribution Service) root key is required for domain controllers to generate and rotate gMSA passwords automatically.

Important

The KDS root key is a one-time setup for your entire Active Directory domain. If you have already created a KDS root key for other gMSA accounts, you can skip this step.

# Check if KDS root key already exists
Get-KdsRootKey

# Create KDS root key effective immediately (production)
Add-KdsRootKey -EffectiveImmediately

# OR make it effective 10 hours in the past (lab/testing only)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Production vs Lab Environments

  • Production: Use -EffectiveImmediately and wait 10 hours for replication across all domain controllers before creating gMSA accounts
  • Lab/Testing: Use -EffectiveTime ((Get-Date).AddHours(-10)) to bypass the 10-hour wait and use the key immediately

Tip

The 10-hour wait ensures the KDS root key replicates to all domain controllers in your forest. Skipping this wait in production can cause gMSA authentication failures on servers using domain controllers that haven't received the key yet.

flowchart LR A[Create KDS Root Key] --> B[Replicate to All DCs] B --> C{Production?} C --> | Yes | D[Wait 10 Hours] C --> | No - Lab | E[Use Immediately] D --> F[Create gMSA Accounts] E --> F

This diagram shows the KDS root key replication process and when you can safely create gMSA accounts.

Step 2: Create the gMSA Account

Run the following PowerShell command on a Domain Controller or management workstation with Active Directory PowerShell module installed:

New-ADServiceAccount "testgmsa" `
  -DNSHostName "testgmsa.domain.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "gmsaservergroup"

Parameter Explanations

  • testgmsa - The name of the gMSA account (use a descriptive name like NodiniteProdSvc)
  • DNSHostName - Fully Qualified Domain Name (FQDN) for the gMSA account
  • PrincipalsAllowedToRetrieveManagedPassword - The Active Directory security group containing all servers that are allowed to retrieve and use this gMSA's password

Tip

  • NodiniteProdSvc - Production environment services
  • NodiniteTestSvc - Test environment services
  • NodiniteDevSvc - Development environment services

Using environment-specific names makes it easier to identify accounts in audit logs and certificate subject names.

Example for Nodinite Production 

New-ADServiceAccount "NodiniteProdSvc" `
  -DNSHostName "NodiniteProdSvc.contoso.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "Nodinite-Prod-Servers"

Step 3: Verify the gMSA Account

After creating the gMSA account, verify it was created correctly:

# Check if the gMSA exists
Get-ADServiceAccount -Identity "testgmsa"

# Get detailed properties of the gMSA
Get-ADServiceAccount -Identity "testgmsa" -Properties *

Key Properties to Verify

  • Enabled - Should be True
  • PrincipalsAllowedToRetrieveManagedPassword - Should list your security group (e.g., gmsaservergroup)
  • DNSHostName - Should match the FQDN you specified
  • ObjectClass - Should be msDS-GroupManagedServiceAccount

Tip

If you see Enabled: False, enable the account with:

Set-ADServiceAccount -Identity "testgmsa" -Enabled $true

Step 4: Install the gMSA on Nodinite Servers

On each Windows Server that will run Nodinite services (Core Services, Monitoring Agents, Logging Agents), install the gMSA account:

Important

The server must be a member of the security group you specified in Step 2 (PrincipalsAllowedToRetrieveManagedPassword). If you just added the server to the group, run gpupdate /force and restart the server for group membership to take effect.

# Install the gMSA on the local server
Install-ADServiceAccount -Identity "testgmsa"

# Test if the gMSA is available and working
Test-ADServiceAccount -Identity "testgmsa"

Expected Result

  • Install-ADServiceAccount - Should complete without errors
  • Test-ADServiceAccount - Should return True

Warning

If Test-ADServiceAccount returns False, see FAQ - gMSA Troubleshooting.

Step 5: Configure Nodinite Services to Use gMSA

Once the gMSA is installed and tested on the server, configure Nodinite to use the gMSA account.

Important

Nodinite deployment architecture varies by server role:

  • Nodinite Application Server - Core Services and agents run inside IIS as application pools (Web Client, Web API, Log API, Logging Service, Monitoring Service, and most agents)
  • Remote Agent Servers - Some agents can be installed as Windows Services on dedicated servers (e.g., Log File Parser, Windows Server Monitoring Agent on remote machines)

The configuration steps below apply to both scenarios. For existing installations, see Migrate Traditional Account to gMSA.

Format for gMSA Account Names

When configuring services or IIS app pools, use the format:

DOMAIN\gMSAAccountName$

Important

Note the trailing dollar sign ($) - this is required for gMSA accounts and distinguishes them from regular user accounts.

Examples

  • CONTOSO\NodiniteProdSvc$
  • FABRIKAM\testgmsa$

Configure Windows Services (Remote Agent Servers Only)

On remote servers where you have installed Nodinite agents as Windows Services (not IIS-hosted), configure the service to use the gMSA account:

Note

This section applies to remote agent deployments (e.g., Log File Parser Agent, Windows Server Monitoring Agent installed as Windows Services on dedicated servers). Most Nodinite deployments run agents inside IIS on the application server and do not require Windows Service configuration.

Configuration Steps

  1. Open Services (services.msc)
  2. Right-click on the Nodinite agent service (e.g., Nodinite Log File Parser Agent)
  3. Select Properties → Log On tab
  4. Select This account
  5. Enter the gMSA account using the format specified above (e.g., CONTOSO\NodiniteProdSvc$)
  6. Leave the password fields EMPTY - gMSA passwords are managed automatically by Active Directory
  7. Click OK - Windows will validate the account
  8. Restart the service

Configure IIS Application Pools (Nodinite Application Server)

On the Nodinite application server, configure IIS application pools to use the gMSA account through the Nodinite Portal (online):

  1. Log in to Nodinite Portal with your account
  2. Navigate to your Environment → Service Accounts
  3. Select Use gMSA Account
  4. Enter the gMSA account name (e.g., CONTOSO\NodiniteProdSvc$)
  5. Click Generate Configuration Script
  6. Download and run the generated PowerShell script as Administrator on the Nodinite server

The script automatically configures all Nodinite application pools (NodiniteWebClient, NodiniteWebAPI, NodiniteLogAPI, NodiniteLoggingService, NodiniteMonitoringService) and recycles them.

Note

For manual configuration or isolated/air-gapped environments, see the Format for gMSA Account Names section for step-by-step IIS Manager instructions.

Set "Log on as a Service" Right

Even though gMSA accounts manage passwords automatically, they still require the "Log on as a service" local policy right.

See How to set Logon as a Service right for step-by-step instructions.

Add to Local Administrators Group (If Required)

Some Monitoring Agents require the service account to be part of the local Administrators group. Check the prerequisites page for each agent you deploy.

To add the gMSA account to local administrators, use the same process as traditional accounts (see Local Administrator section), but remember to include the trailing $ in the account name.

Advanced gMSA Content (Spoke Pages)

This page is the hub for gMSA setup. The deep-dive procedures and troubleshooting are now separated into focused spoke pages to keep this guide easier to maintain and easier to scan.

Migration and Certificate Deep Dive

Use Migrate Traditional Account to gMSA for complete migration guidance, including:

  • Exporting certificates from Cert:\CurrentUser\My under the old service account
  • Importing certificates to Cert:\LocalMachine\My for gMSA
  • Granting private key access to the gMSA identity
  • Verifying app pool identities and encrypted configuration access

Troubleshooting Deep Dive

Use FAQ - gMSA Troubleshooting for detailed issue resolution, including:

  • Test-ADServiceAccount returns False
  • "Logon failure" and "Access is denied" patterns
  • Password rotation behavior and post-rotation checks
  • Certificate access and decryption failures

Next Step