Using Group Managed Service Account (gMSA)

Starting with version 9.96, Netwrix Auditor supports using Group Managed Service Accounts (gMSA) for data collection and storage. This can help you to simplify Netwrix Auditor administration, providing the following benefits:

  • There is no password to manage for this account: Windows handles the password management for it. User interaction for password update on a regular basis is not required.
  • Using the gMSA also eliminates a need in service accounts with static passwords that are set upon creation and then never cycled.
  • The gMSA also helps to ensure that service account is only used to run a service (gMSA accounts cannot be used to log on interactively to domain computers).

Currently, gMSA is supported:

  • As a data collecting account for the following data sources: Active Directory (also for Group Policy and Logon Activity), Windows Server, File Server (currently for Windows File Servers), SQL Server, SharePoint. See Data Collecting Account for more information.
  • As an account for accessing Long-Term archive. See Configure Long-Term Archive Account for more information.
  • As an account for accessing Audit Databases. See Configure Audit Database Account

    IMPORTANT! In case of accessing Audit Databases using gMSA account, SSRS-based reports will not work.

It is recommended to have a dedicated gMSA that will be used for these purposes.

The next sections describe how to prepare for gMSA usage.

Checking for KDS root key

To generate password for gMSA accounts, domain controllers require a Key Distribution Services (KDS) root key. This key is created once, so if there are any gMSA accounts in your domain, this means the root key already exists.

To check whether the root key exists in your domain:

  1. Open the Active Directory Sites and Services Console, select View Show Services Node.
  2. Browse to Services Group Key Distribution Services Master Root Keys.
  3. Alternatively, you can run the Get-KdsRootKey cmdlet. If the key does not exist, it will not return any output.

If the KDS key does not exist, then you can create is as described below, or contact your Active Directory administrator.

To create a KDS key (on a domain controller running Windows Server 2012 or later)

  1. On the domain controller, run Windows PowerShell.
  2. In the command prompt of Windows PowerShell Active Directory module, run the following cmdlet:

    Add-KdsRootKey -EffectiveImmediately

  3. A root key will be added to the target DC which will be used by the KDS service immediately. Note, however, that it requires a 10-hours wait, as other domain controllers will be able to use the root key only after a successful replication. See this Microsoft article for more information.

NOTE: Alternatively, you can use the following cmdlet:

Add-KdsRootKey -EffectiveTime MM/DD/YYYY

This cmdlet generates a KDS root key that will take effect on the specified date. Use the mm/dd/yyyy format, for example: Add-KdsRootKey -EffectiveTime 02/27/21

This approach, however, should be used with care.

Creating a gMSA

When creating a new gMSA, you will need to specify:

  • New account name and FQDN
  • Computer account(s) that will be allowed to make use of that gMSA. Here it will be:

    1. Your Netwrix Auditor Server

    2. If you are going to collect data using the network traffic compression (see the following section for more information: Network Traffic Compression), provide the following:

      • For Windows Server auditing — target Windows Servers

      • For Logon Activity — domain controllers of the monitored domain

For example, you can create a gMSA using the New-ADServiceAccount PowerShell cmdlet. If so, you should specify your Netwrix Auditor Server account in the -PrincipalsAllowedToRetrieveManagedPassword attribute.

NOTE: Make sure you specify a valid computer object in this attribute.

If you have multiple Netwrix Auditor servers, you can specify the computer accounts using a comma separated list, or specify a security group and add the required computer accounts to that security group.

To create a new gMSA in the root domain using PowerShell:

  • If you are using a single Netwrix Auditor Server, run the command as follows:

    New-ADServiceAccount -name nagmsa -DNSHostName nagmsa.mydomain.local -PrincipalsAllowedToRetrieveManagedPassword NASrv$

    here:

    • name — new gMSA name, here nagmsa. Make sure the name refers to a valid computer objects.
    • DNSHostName — FQDN of the new gMSA account, here nagmsa.mydomain.local
    • PrincipalsAllowedToRetrieveManagedPassword — your Netwrix Auditor Server NETBIOS name ended with $, here NASrv$
  • If you want to specify a security group that comprises multiple Netwrix Auditor servers, run the command as follows:

    New-ADServiceAccount -Name gmsagroup -DNSHostName gmsagroup.mydomain.local -PrincipalsAllowedToRetrieveManagedPassword NAServers

    • here NAServers — a security group with your Netwrix Auditor servers

Applying gMSA

To process the corresponding monitored items using gMSA, you can specify this account in the monitored plan properties, as described in the Settings for Data Collection section.

Alternatively, you can set it as a custom account in the monitored item properties:

  1. Open the monitored item properties for editing.
  2. On the General tab, under Specify account for collecting data, select Custom account.

See also the guidelines for the monitored item configuration (Add Items for Monitoring