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:

This diagram shows the gMSA architecture: Active Directory creates the KDS root key (green), which replicates to all domain controllers. The gMSA account (green) is installed on Nodinite servers through security group membership. The secret-encryption certificate in the LocalMachine store (yellow) is used by the IIS application pools of the Core Services and agents, and by agents that run as Windows Services (blue); see Secret Management and Install Certificates for gMSA.

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

When using gMSA accounts, you must manually provision and manage the secret-encryption certificates in the LocalMachine certificate store. Unlike traditional service accounts, where Nodinite auto-generates the certificate, gMSA accounts require certificates from your own PKI or certificate authority. See Install Certificates for gMSA for PowerShell scripts and step-by-step instructions. This certificate is separate from the TLS certificate of the Core Services web sites, which you identify by subject in the Core host Configuration.

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
• Use Traditional Account for simpler setup with Nodinite-managed certificates, or if you lack certificate management infrastructure

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
  • Database Monitoring Agent ^{New 7.2.0}
  • Boomi Monitoring Agent ^{New 7.2.0}
  • 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}

In the Portal, agents that support gMSA show the Use gMSA option on their card in the Agents step.

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 for the Core Services and the Monitoring Agents that support gMSA (Step 5 gMSA agents).

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.

How you set the identity depends on how the component is installed:

• Installed by the v7 install package - The Core Services and the agents you add in the Portal run as IIS web sites, each with its own application pool. You set the gMSA in the Nodinite Portal, and the CLI configures the application pools when you run the package.
• Installed with an MSI as a Windows Service - Agents installed this way on a remote server (see each agent's Install page) get the gMSA in the Windows Services console.

Diagram: the gMSA travels through the Portal wizard, from the Service Account Defaults and the optional per-service accounts in Core platform services to the Use gMSA option in the Agents step; Step 6: Review and Download builds the package, and the CLI configures the IIS application pools.

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 IIS Application Pools in the Nodinite Portal

For everything the v7 install package installs, set the gMSA in the Nodinite Portal:

1. In Step 2: Auth, keep Domain mode, select gMSA in Service Account Defaults, and enter the domain and the account name with the trailing $. The Portal refuses to generate the package if the $ is missing.
2. In Step 4: Servers, clear Same account for all Services only if a Core Service needs a different account.
3. In Step 5: Agents, turn on Use gMSA for each agent that supports it.
4. In Step 6: Review and Download, download the package.
5. Run the package with the CLI in elevated PowerShell 7 on each server. The CLI configures the application pools with the gMSA; leave no password anywhere.

Make sure the gMSA can read the private key of the secret-encryption certificate before you run the package; see Install Certificates for gMSA.

Configure Windows Services (MSI-Installed Agents Only)

On remote servers where you installed a Nodinite agent with an MSI as a Windows Service, configure the service to use the gMSA account:

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

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 Steps

• Install Certificates for gMSA - Provision the secret-encryption certificate
• Step 2: Auth - Service Account Defaults in the Portal
• Install Nodinite v7
• Migrate Traditional Account to gMSA - Full migration and certificate workflow
• FAQ - gMSA Troubleshooting - Detailed troubleshooting playbook

Related Topics

• Secret Management - Certificate-based encryption in Nodinite v7
• How to set Logon as a Service right - Service account rights
• Step 5: Agents - Agents with gMSA support
• Core Services - Services that support gMSA accounts
• Monitoring Agents - Agents that support gMSA accounts
• Logging Agents - Logging agents that support gMSA accounts
• Windows Server Troubleshooting
• Troubleshooting - General installation and configuration help
• Microsoft: Group Managed Service Accounts Overview