Use gMSA accounts for AVEVA Work Tasks

Manage service accounts with Group Policy

Summary

If customers require centralized management of service accounts for security or operational reasons, they can configure the Work Tasks Services to use Group Managed Service Accounts (gMSA).

This is an optional configuration step and may be implemented only if required by the customer's IT policies.

This document provides guidance for customer IT organizations on how to manage Work Tasks service accounts using Active Directory Group Policy (GPO) with gMSAs, and how to apply these accounts as the login identity for all Work Tasks services.

Note: The tasks detailed in this topic are intended to be performed by Domain and/or Network Administrators only.

Group Managed Service Accounts (gMSA)

gMSAs serve the same purpose as Virtual Service Accounts but are managed as Domain accounts making them usable across multiple computers and multiple services. AVEVA Technical Support recommends creating a separate gMSA for each service to enable more granular management and process isolation. However, if the customer environment does not require such isolation, a single gMSA can be used across all applicable services requiring GPO-based management.

The gMSA requirements are:

• Active Directory schema must be Windows Server 2022 or later

• At least one Windows Server 2022 Domain Controller must be present.

• Requires PowerShell scripting on the Domain Controller

• Each applicable Work Tasks service (on each machine) must be configured to run using the gMSA.

On the Domain Controller

1. Start PowerShell as Administrator on the Domain Controller.

2. Import the Active Directory module.

   Note: The Active Directory module is pre-installed and available for import on all Windows Server 2022 Domain Controllers.

   
   Import-module ActiveDirectory

   

   Figure 1: Powershell script to import-module
   

3. Perform a one-time PowerShell action to create the Key Distribution Service (KDS) Root Key for the domain:

   Add-KDSRootKey -EffectiveImmediately

   

   Figure 2: Powershell script to Add-KDSRootKey
   

   Note: Propagation of the KDS root key can take up to 10 hours across the entire domain. In a parent-child domain environment, the PowerShell command must be executed by a member of the Enterprise Admins group, which exists only in the parent domain. If these conditions are not met, you may encounter the following error: The request is not supported.

4. Create a Domain Security Group that contains the computer accounts allowed to use the gMSA. (Figure below).

   Example: In the figure below, a group named ControlNetworkComputers is used with a gMSA named gMSAForServices. You may use any group name and gMSA name suitable for your environment.

5. Create a security group named ControlNetworkComputers.

6. Add computer accounts for the relevant machines to this group.

7. Reboot the domain-member computers to apply the updated group membership.

   Note: The Domain Controller does not need to be rebooted, only the computers that were added to the security group.

   

8. Create the gMSA that will be used by the above group, in PowerShell.

   New-ADServiceAccount -name gMSAForServices -DNSHostName gMSAForServices.workflow.com -PrincipalsAllowedToRetrieveManagedPassword "ControlNetworkComputers"

   
   

   Note: If the following error is returned - Key does not exist - it indicates that the KDS root key has not yet propagated across the environment. This process can take up to 10 hours.

9. Verify that the gMSA account exists in Active Directory Users and Computers > Managed Service Accounts.

   

10. Configure the Restricted Groups GPO to grant the gMSA account the required permissions.

    
    
    
    
    

    Note: The system automatically appends a $ character to the end of the gMSA account name.

On each computer where the service will run

The following steps must be reapplied after any upgrade or reinstallation of the Work Tasks software:

11. There is no need to run the Install-ADServiceAccount cmdlet when using a gMSA.

12. Configure the service to use the gMSA account as its logon identity. Be sure to include the $ at the end of the account name.

13. When you assign the gMSA to a service, it is automatically granted the Log On As A Service right.

    

14. Reboot the machine to apply group membership changes and finalize deployment.

15. After the reboot, confirm that the gMSA account is still a member of the Administrators group (as defined in the Restricted Groups GPO).

    
    

16. Verify that all Work Tasks services are running successfully under the configured gMSA account.