Configure Group Managed Service Accounts (gMSA)

^{New 7.x}

Empower your Nodinite v7 environment with automated, secure service account management. Group Managed Service Accounts (gMSA) eliminate password expiration issues, enhance security, and are compatible with Nodinite's certificate-based encryption.

✅ Eliminate password expiration management - Passwords rotating 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

Note

gMSA accounts provide the same functionality as traditional service accounts but with automatic password management by Active Directory. This eliminates the operational overhead of password expiration policies while maintaining compatibility with Nodinite's Secret Management and certificate-based encryption introduced in v7.

Important

Nodinite v7+ Required: 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.

Important

Certificate Management Requirement: 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. Ensure you have a certificate lifecycle management process in place.

When to Use gMSA vs Traditional Service Accounts

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?

✅ All Nodinite Windows Services and IIS Application Pools support gMSA:

• Core Services
  • Monitoring Service
  • Logging Service
  • Web Client (IIS Application Pool)
• Monitoring Agents
• Logging Agents

Important

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.

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

Nodinite Naming Convention Recommendations:

• 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, check:

1. Is the server a member of the security group specified in PrincipalsAllowedToRetrieveManagedPassword?
2. Has the KDS root key replicated to all domain controllers (10-hour wait in production)?
3. Run gpupdate /force and restart the server to refresh group membership

Step 5: Configure Nodinite Services to Use gMSA

Once the gMSA is installed and tested on the server, configure Nodinite Windows Services and IIS Application Pools to use the gMSA account.

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

1. Open Services (services.msc)
2. Right-click on the Nodinite service (e.g., Nodinite Monitoring Service)
3. Select Properties → Log On tab
4. Select This account
5. Enter: DOMAIN\gMSAAccountName$ (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

Note

You do NOT enter a password for gMSA accounts. Windows retrieves the password automatically from Active Directory.

Configure IIS Application Pools

For Nodinite Web Client and Web API application pools:

1. Open IIS Manager
2. Navigate to Application Pools
3. Right-click on the Nodinite app pool
4. Select Advanced Settings → Identity
5. Select Custom account → Set
6. Enter: DOMAIN\gMSAAccountName$
7. Leave the password fields EMPTY
8. Click OK
9. Recycle the application pool

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.

Certificate Store and Secret Encryption with gMSA

Nodinite v7 introduced certificate-based secret encryption. When using gMSA accounts, you must manually provide and manage certificates:

⚠️ Important: Manual Certificate Management Required

• gMSA accounts use the LocalMachine certificate store (unlike traditional service accounts which use a personal store)
• Nodinite automatically detects gMSA accounts and uses the LocalMachine certificate store location
• You must manually create and install the certificate in the LocalMachine store before configuring secret encryption
• You are responsible for certificate renewal and lifecycle management - Nodinite will NOT auto-generate certificates for gMSA accounts
• The certificate must be accessible to the gMSA account with appropriate permissions

✅ Benefits with gMSA:

• Automatic password rotation (every 30 days) does NOT break encryption
• No certificate migration needed when password rotates (as long as the certificate remains in LocalMachine store)
• Password and certificate are managed independently - password auto-rotates, you manage certificate lifecycle

Warning

Unlike traditional service accounts where Nodinite can auto-generate and manage certificates in the user's personal store, gMSA accounts require you to manually provision and renew certificates in the LocalMachine store. Ensure you have a certificate management process in place before deploying gMSA with secret encryption.

For detailed information about certificate-based encryption, see Secret Management.

This diagram shows how gMSA password rotation works independently from certificate management.

Troubleshooting gMSA Issues

"Logon failure: the user has not been granted the requested logon type"

Cause: The gMSA account does not have "Log on as a service" right.

Solution: Add the gMSA account to the local policy "Log on as a service". See How to set Logon as a Service right.

Test-ADServiceAccount returns False

Cause: Server cannot retrieve the gMSA password from Active Directory.

Solution:

1. Verify the server is in the security group specified in PrincipalsAllowedToRetrieveManagedPassword
2. Run gpupdate /force to refresh group policy
3. Restart the server
4. Ensure KDS root key has replicated (10-hour wait in production)

gMSA password rotation (30 days)

gMSA passwords are rotated automatically by Active Directory (via the KDS service) on a regular cadence (commonly ~30 days). Important points:

• AD-managed rotation: Active Directory generates and rotates the gMSA password; you do not enter or manage the password on servers.

• KDS replication matters: The KDS root key must replicate to all Domain Controllers before gMSA passwords can be retrieved reliably. Allow time for replication in production (see Step 1).

• Services automatically pick up the new password: Windows will retrieve the managed password when needed — services and IIS app pools using a gMSA do not require manual password updates when rotation occurs.

• Verification: See Step 4 ("Install the gMSA on Nodinite Servers") for the canonical PowerShell commands (Install-ADServiceAccount / Test-ADServiceAccount). If Test-ADServiceAccount returns False, check group membership, run gpupdate /force and restart the server, and verify KDS replication on the domain controllers.

• Certificates: Password rotation is independent from Nodinite's certificate-based secret encryption. You must provision and manage the encryption certificate in the LocalMachine store and ensure the gMSA/service has access to the private key; rotations do not change the certificate.

• Quick checklist when you see authentication failures after a rotation:

  • Verify the server is a member of the PrincipalsAllowedToRetrieveManagedPassword group
  • Verify the KDS root key exists and has replicated to all DCs
  • Run gpupdate /force and reboot if group membership was recently changed
  • Check Event Viewer for specific gMSA errors

Service fails to start with gMSA account

Cause: Multiple possible issues.

Solution:

1. Verify the account format includes the trailing $ (e.g., DOMAIN\gMSAName$)
2. Check that password fields were left empty (common mistake)
3. Verify the gMSA account has necessary permissions (local admin if required)
4. Check Event Viewer for specific error details

Cannot access encrypted configuration files

Cause: Certificate store permissions or gMSA account changed.

Solution:

1. Verify the gMSA account has access to LocalMachine certificate store
2. For step-by-step guidance on granting a machine or service account access to a certificate's private key, see Microsoft: Grant access to a certificate private key (https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/grant-access-certificate-private-key)
3. Check that "Automatically Manage Certificate" is enabled in Nodinite settings
4. Review certificate subject name matches the environment/service

Event Viewer note: Check the System (Service Control Manager), Application and Security logs for entries that reference the service name, the gMSA account, or errors such as "Logon failure" or "Access is denied". Messages mentioning the certificate or private‑key access will help pinpoint whether the issue is a logon right, KDS/group membership, or certificate ACL problem.

For additional help, see the main Troubleshooting page.

Next Step

• Install Nodinite:
  • Install Nodinite v7
• Configure Secret Management:
  • Secret Management - Certificate-based encryption configuration
• Service Account Options:
  • How to set Logon as a Service right - For traditional service accounts

Related Topics

• Secret Management - Certificate-based encryption in Nodinite v7
• How to set Logon as a Service right - Traditional service account setup
• Core Services - Services that support gMSA accounts
• Monitoring Agents - Agents that support gMSA accounts
• Logging Agents - Logging agents that support gMSA accounts
• Web Client - IIS application pool configuration
• Troubleshooting - General installation and configuration help
• Microsoft: Group Managed Service Accounts Overview