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.

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:

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.

Important

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

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:

• Core Services
  • Log API
  • Logging Service
  • Monitoring Service
  • Web API
  • Web Client (IIS Application Pool)
• Monitoring Agents
  • IBM MQ Monitoring Agent ^{New 7.0.4}
  • Log File Parser Agent ^{New 7.0.4}
  • Message Queuing Agent ^{New 7.0.4}
  • RabbitMQ Monitoring Agent ^{New 7.0.4}
  • Web Services Monitoring Agent ^{New 7.0.4}
• Logging Agents
  • Pickup Log Events Service Logging Agent ^{New 7.0.4}

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

• 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 the Test-ADServiceAccount returns False troubleshooting section below.

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 Migrating from Traditional Account to gMSA for step-by-step migration guidance.

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.

Migrating from Traditional Account to gMSA

If you have an existing Nodinite installation using a traditional service account with Windows Data Protection API (DPAPI) or certificate-based encryption, you must migrate certificates to the LocalMachine store when switching to gMSA.

Important

Why Certificate Migration is Required:

• Traditional service accounts use the Personal certificate store (Cert:\CurrentUser\My) under the user's profile
• gMSA accounts do not have user profiles and require the LocalMachine certificate store (Cert:\LocalMachine\My)
• Existing certificates must be copied from the old account's Personal store to LocalMachine store for gMSA to access them

Migration Overview:

1. Export certificates from old service account's Personal store
2. Import certificates into LocalMachine store (see Install Certificates for gMSA)
3. Grant gMSA account permissions to certificate private keys
4. Update service identities to gMSA account (automated via Nodinite Web Client)
5. Verify encryption and services work correctly

Downtime: Minimal - IIS app pool recycles take seconds.

Step 1: Export Certificates from Old Service Account

Run PowerShell as the old service account (use RunAs or log in as that account):

# List all certificates in the old account's Personal store
Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Subject -like "*Nodinite*" -or $_.FriendlyName -like "*Nodinite*" } | Format-List Subject, Thumbprint, NotAfter, FriendlyName

# Export each certificate to PFX (replace thumbprint with your actual value)
$certThumbprint = "1234567890ABCDEF1234567890ABCDEF12345678"
$cert = Get-ChildItem Cert:\CurrentUser\My\$certThumbprint

if ($null -eq $cert) {
    Write-Error "Certificate not found in Personal store"
    exit
}

# Export with strong password
$pfxPassword = ConvertTo-SecureString -String "SecurePassword123!" -Force -AsPlainText
$pfxPath = "C:\Temp\NodiniteCert_$certThumbprint.pfx"
Export-PfxCertificate -Cert $cert -FilePath $pfxPath -Password $pfxPassword

Write-Host "Certificate exported to $pfxPath" -ForegroundColor Green
Write-Host "Thumbprint: $certThumbprint" -ForegroundColor Cyan

Tip

Repeat the export for each certificate used by Nodinite (you may have multiple certificates for different environments).

Step 2: Import Certificates into LocalMachine Store

Run PowerShell as Administrator:

# Import PFX into LocalMachine store
$pfxPath = "C:\Temp\NodiniteCert_1234567890ABCDEF1234567890ABCDEF12345678.pfx"
$pfxPassword = ConvertTo-SecureString -String "SecurePassword123!" -Force -AsPlainText

$cert = Import-PfxCertificate -FilePath $pfxPath -CertStoreLocation Cert:\LocalMachine\My -Password $pfxPassword -Exportable

Write-Host "Certificate imported to LocalMachine store" -ForegroundColor Green
Write-Host "Thumbprint: $($cert.Thumbprint)" -ForegroundColor Cyan
Write-Host "Subject: $($cert.Subject)" -ForegroundColor Cyan

# Securely delete PFX file
Remove-Item $pfxPath -Force
Write-Host "PFX file deleted" -ForegroundColor Yellow

Step 3: Grant gMSA Account Access to Certificate Private Keys

Run PowerShell as Administrator:

# Replace with your gMSA account and certificate thumbprint
$gmsaAccount = "CONTOSO\NodiniteProdSvc$" # Include trailing $
$certThumbprint = "1234567890ABCDEF1234567890ABCDEF12345678"

# Get certificate from LocalMachine store
$cert = Get-ChildItem Cert:\LocalMachine\My\$certThumbprint
if ($null -eq $cert) {
    Write-Error "Certificate not found in LocalMachine store"
    exit
}

# Get private key file path
$privateKey = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
$privateKeyPath = $privateKey.Key.UniqueName
$privateKeyFullPath = "$env:ProgramData\Microsoft\Crypto\RSA\MachineKeys\$privateKeyPath"

if (-not (Test-Path $privateKeyFullPath)) {
    Write-Error "Private key file not found at $privateKeyFullPath"
    exit
}

# Grant gMSA account Read permission on private key
$acl = Get-Acl -Path $privateKeyFullPath
$permission = $gmsaAccount, "Read", "Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$acl.SetAccessRule($accessRule)
Set-Acl -Path $privateKeyFullPath -AclObject $acl

Write-Host "Granted Read access to $gmsaAccount on certificate private key" -ForegroundColor Green
Write-Host "Certificate: $($cert.Subject)" -ForegroundColor Cyan
Write-Host "Thumbprint: $certThumbprint" -ForegroundColor Cyan

Note

For detailed guidance, see Microsoft: Grant access to a certificate private key

Step 4: Update Service Identities to gMSA

Use Nodinite Portal to update all service identities automatically:

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 updates all IIS application pools and Windows Services to use the gMSA account.

Note

For isolated/air-gapped environments without internet access, you can manually configure services using IIS Manager and Services console. Contact Nodinite support for offline script generation.

Step 5: Verify Migration

Verify certificates and services:

# Verify certificate is in LocalMachine store
$certThumbprint = "1234567890ABCDEF1234567890ABCDEF12345678"
$cert = Get-ChildItem Cert:\LocalMachine\My\$certThumbprint
if ($cert) {
    Write-Host "✓ Certificate found in LocalMachine store" -ForegroundColor Green
    Write-Host "  Subject: $($cert.Subject)" -ForegroundColor Cyan
    Write-Host "  Expires: $($cert.NotAfter)" -ForegroundColor Yellow
}

# Verify IIS app pools are using gMSA
Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Where-Object { $_.name -like "Nodinite*" } | Select-Object name, state, @{n="Identity";e={$_.processModel.userName}}

Test Nodinite functionality:

1. Open Nodinite Web Client (on-premise application) and verify login works
2. Check encrypted configuration - verify services can decrypt settings
3. Test agent functionality - verify monitoring and logging work
4. Review Event Viewer for errors (Application and System logs)

Migration Troubleshooting

"Access Denied" errors after migration

gMSA account does not have permissions on certificate private key.

Re-run Step 3 to grant Read permissions on private keys.

Services fail to start after migration

gMSA account missing "Log on as a service" right or local administrator membership.

1. Verify gMSA has "Log on as a service" right - see LogonAsAService
2. Add gMSA to local Administrators group if required by agents
3. Check Event Viewer for specific error messages

"Certificate not found" errors in logs

Certificate not properly imported into LocalMachine store.

1. Verify certificate exists in Cert:\LocalMachine\My store
2. Check certificate thumbprint matches configuration
3. Ensure certificate has private key (check $cert.HasPrivateKey property)

Encryption/decryption fails after migration

Certificate subject name or permissions issue.

1. Verify certificate in LocalMachine store has same subject name as before
2. Grant gMSA Read permission on private key (Step 3)
3. Check Nodinite configuration points to correct certificate store location (should auto-detect LocalMachine for gMSA)

Troubleshooting gMSA Issues

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

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

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

Server cannot retrieve the gMSA password from Active Directory.

Follow the troubleshooting checklist in the warning box in Step 4: Install the gMSA on Nodinite Servers.

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 automatically
• Services automatically pick up the new password: Windows retrieves the managed password when needed — no manual password updates required
• Verification: See Step 4: Install the gMSA on Nodinite Servers for canonical PowerShell commands. If issues arise, see Test-ADServiceAccount returns False troubleshooting
• Certificates: Password rotation is independent from certificate-based secret encryption. You must provision and manage the encryption certificate in the LocalMachine store

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

Multiple possible issues.

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

Certificate store permissions or gMSA account changed.

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

• Install Certificates for gMSA - PowerShell scripts for certificate installation in LocalMachine store
• 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