Running Assessments with Managed Service Accounts

Managed Service Accounts (MSAs) are a type of security principal available in currently supported versions of Active Directory Domain Services. They share characteristics of both computer and user security principals. They can be added to security groups, can authenticate, and access resources on a network. They are intended to be used by services, IIS application pools, and scheduled tasks.

Benefits of Managed Service Accounts

Managed Service Accounts address specific challenges inherent with using user accounts for running services, scheduled tasks, and IIS application pools:

• Automatic password management
• Simplified service principal name (SPN) management
• Cannot be used to interactively log into Windows
• Easily control which computers are authorized authenticate MSAs and run code in their context

On-Demand Assessments that may use Managed Service Accounts

Managed Service Accounts may be configured for running the following On-Demand Assessments

• Active Directory
• Active Directory Security
• System Center Configuration Manager
• SharePoint
• SQL Server
• Windows Client
• Windows Server

Note

Managed Service Accounts are not officially supported by Microsoft customer service for some environmental configurations. While they work in most scenarios, it may be necessary to use a domain account when environmental configurations prevent Managed Service Account usage.

Provision Managed Service Accounts

A prerequisite to configuring an assessment scheduled task to run as an MSA is to provision or create the MSA in Active Directory Domain Services. Each of the supported assessments specifies the authorization and access requirements of the scheduled task account to successfully run. Consult supported assessment getting started documents and prerequisite documents for access requirement details of the scheduled task account.

There are two types of managed service accounts. Either may be configured for the assessment scheduled task for the supported assessments:

• Standalone Managed Service Accounts (also known as Virtual Accounts) can only be authorized to authenticate on a single domain joined computer.
• Group Managed Service Accounts can be authorized to authenticate on several domain computers.

The Windows PowerShell Active Directory module is required for provisioning and configuring both types of MSAs. Domain controllers typically have this PowerShell module installed during installation of the domain controller role.

The module, a component of the Remote Server Administrator Tools, may be added to Windows Server SKUs via Server Manager. The module may also be added to Windows 10.

Scenario 1 – Standalone Managed Service Account (sMSA)

Active Directory Domain Services forest schema must be at Windows Server 2008 R2 minimum to successfully provision standalone managed service accounts. Computers running scheduled tasks as an sMSA must be running Windows Server 2012 or newer.

There are three steps to provision an sMSA for running On-Demand Assessments:

1. Create the sMSA using New-ADServiceAccount PowerShell cmdlet.
2. Authorize the data collection machine to obtain the password for the sMSA using Add-ADComputerServiceAccount PowerShell cmdlet.
3. Grant the sMSA the required access to the environment being assessed per the prerequisite documentation for the relevant assessment being configured.

Create Standalone Managed Service Account

To create the sMSA, execute the following command within a PowerShell session from a domain controller or domain member with the Windows PowerShell Active Directory module installed using an account with necessary permissions to create accounts in Active Directory (Account Operators or Domain Administrators by default have the necessary permissions).

New-ADServiceAccount -Name <sMSAaccountname>  -RestrictToSingleComputer

For example: PS C:> New-ADServiceAccount -Name sMSA-SVC -RestrictToSingleComputer

Authorize Data Collection Machine to use sMSA

To authorize the data collection machine to obtain the password for the sMSA, execute the following command within a PowerShell session from a domain controller or domain member with the Windows PowerShell Active Directory module installed using an account with necessary permissions to create accounts in Active Directory (Account Operators or Domain Administrators by default have the necessary permissions).

Add-ADComputerServiceAccount -Identity “datacollectionmachine$” -ServiceAccount “sMSA samaccountname”

For example: Add-ADComputerServiceAccount -Identity "OMS-AD-Tools$" -ServiceAccount "sMSA-SVC$"

Install sMSA on Data Collection Machine

Pre-caching the sMSA on the data collection machine serves an important validation step to ensure the account is provisioned correctly and the data collection machine can successfully retrieve the sMSA password and use the account. From the data collection machine with the Active Directory Powershell module installed, run the following.

Install-ADServiceAccount -Identity “sMSA samaccountname”

For example: Install-ADServiceAccount -Identity "sMSA-SVC$"

Note

If a cmdlet not found error is returned, then install the Active Directory Powershell module explained in Provision Managed Service Accounts above.

For other errors, review the Microsoft-Windows-Security-Netlogon/Operational event log channel for MSA category events.

Scenario 2 – Group Managed Service Account (gMSA)

Active Directory Domain Services forest schema must be at Windows Server 2012 minimum to successfully provision group managed service accounts. Computers running scheduled tasks as an gMSA must be running Windows Server 2012 or newer.

There are 3 steps to provision an gMSA for running On-Demand Assessments:

1. Create the Key Distribution Services KDS Root Key within Active Directory using Add-KDSRootKey
2. Create the gMSA and authorize data collection machine to obtain the password for the gMSA using New-ADServiceAccount PowerShell cmdlet.
3. Grant the gMSA the required access to the environment being assessed per the prerequisite documentation for the relevant assessment being configured.

Provision KDS Root Key

The KDS root key must first be created if it has never been created in the Active Directory forest.  To determine if there is an existing KDS root key, execute the following command from within a PowerShell session.

Get-KdsRootKey

Note

If nothing is returned from this command, then no root key exists in the Active Directory forest.

To create the KDS root key execute the following command within a PowerShell session from a domain controller or domain member with the Windows PowerShell Active Directory module installed using an account with necessary permissions to create accounts in Active Directory (Enterprise Administrators and Domain Administrators in the forest root domain by default have the necessary permissions).

Add-KdsRootKey -EffectiveImmediately 

Add-KdsRootKey -EffectiveImmediately allows creation of gMSAs after 10hrs to ensure replication has converged to all DCs.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) 

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) allows the creation of gMSAs immediately.

This approach does incur some risks of failed gMSA creation or usage if AD replication convergence forest wide takes several hours under normal operations.

Create Group Managed Service Account

To create the gMSA, execute the following command within a PowerShell session from a domain controller or domain member with the Windows PowerShell Active Directory module installed using an account with necessary permissions to create accounts in Active Directory (Account Operators or Domain Administrators by default have the necessary permissions).

New-ADServiceAccount -Name <gMSAaccountname> -DNSHostname <gMSAaccountname.FQDN> -PrincipalsAllowedToRetrieveManagedPassword “data collection machine samaccountname”

For example: PS C:> New-ADServiceAccount -Name gMSA-SVC -DNSHostName gMSA-SVC.contoso.local -PrincipalsAllowedToRetrieveManagedPassword "oms-ad-tools$"

Install gMSA on Data Collection Machine

Pre-caching the gMSA on the data collection machine serves an important validation step to ensure the account is provisioned correctly and the data collection machine can successfully retrieve the gMSA password and use the account. From the data collection machine with the Active Directory Powershell module installed, run the following.

Install-ADServiceAccount -Identity “gMSA samaccountname”

For example: Install-ADServiceAccount -Identity "gMSA-SVC$"

Note

If a cmdlet not found error is returned, then install the Active Directory Powershell module explained in Provision Managed Service Accounts above.

For other errors, review the Microsoft-Windows-Security-Netlogon/Operational event log channel for MSA category events.