Microsoft Defender for Identity
Formerly known as Azure Advanced Threat Protection (Azure ATP), Defender for Identity is a cloud-based security solution offered by Microsoft to help organizations in identity monitoring with high security, in both on-premises and hybrid environments. With the modern identity threat detection (ITDR), security operation teams in your organization can now prevent, detect, investigate and respond to data breaches, threats and attacks. Furthermore, by analyzing user profiles and security reports, it provides relevant insights into identity configurations to understand identity structure and suggests best practices to enhance security.
What are Directory Service Accounts and why to configure them for Microsoft Defender for Identity
In an enterprise environment, directory service accounts (DSAs) are user accounts, but unlike others, they are not controlled by humans. Instead, these are used by services to interact with the operating system. Directory service accounts are used to identify, authenticate or start a service. They are also used to access and execute codes and applications. With all the access privileges and permissions that service accounts hold, they are easily one the prime targets for security threats and attacks.
Defender for Identity uses DSA to access and analyze data from your organization’s directory service to detect threats and raise alerts. Through DSA connected to a domain controller, Defender for Identity can inquire the domain controller about entities seen on network traffic and events to ensure a full security converge. Microsoft Defender for Identity can support two types of DSAs – Group Managed Service Account (gMSA) or a conventional user account.
Why use a Group Managed Service Account?
Group Managed Service Accounts (gMSAs) are specialized service accounts used to run services on multiple servers in Active Directory (AD). They are managed centrally and come with several advantages over conventional accounts such as automatic password management, simplified administration, and improved security. Follow the steps below to configure a directory service account for defender for identity with a gMSA.
1. Create a gMSA account
The following PowerShell commands enables you to create a group for account’s password retrieval, create a gMSA account and test the account for usage.
# This command defines variables and sets values
$gMSA_AccountName = 'MyServiceAccount'
$gMSA_HostsGroupName = 'MyServiceHosts'
$gMSA_HostNames = 'Server1', 'Server2', 'Server3', 'Server4', 'Server5', 'Server6', 'Server7', 'Server8'
# This command import the required PowerShell module
Import-Module ActiveDirectory
# This command creates the group and lets you add the members
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
# If the directory environment is a single forest containing only domain controller sensors, use the built-in 'Domain Controllers' group
# $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
# This command creates the gMSA account:
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN"
# This command specifies the group whose members are allowed to retrieve the managed password of the MSA.
-PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName
Note : Run the powershell script as an administrator.
2. Allow Read-only permissions to Directory Service Accounts
The Directory Service Accounts (DSA) needs read-only permissions on all the objects in AD, including the Deleted Objects Container. The following code allows you to grant permissions to DSA on Deleted objects container.
# This command declares the identity that you want to allow read-only access to the deleted objects container:
$Identity = 'MarketingGroup'
# This command is used to create a group and add the gMSA to it if the identity is already a gMSA:
$groupName = 'MarketingGroup'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
$groupParams = @{
Name = $groupName
SamAccountName = $groupName
DisplayName = $groupName
GroupCategory = 'Security'
GroupScope = 'Universal'
Description = $groupDescription
}
$group = New-ADGroup @groupParams -PassThru
Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
$Identity = $group.Name
}
# This command gets the distinguished name of the deleted objects container:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
# This command lets you take ownership of the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params
# This command allows 'List Contents' and 'Read Property' access to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
3. Confirm if the domain controller can retrieve the gMSA’s password
# This command checks if the server has the required permissions to retrieve the gMSA's password and returns true if it has. Test-ADServiceAccount -Identity 'mdiSvc01' # If there occurs an error, you can restart the server or run the following command klist purge -li 0x3e7
4. Confirm if the gMSA account has the required rights
If the Log on as a service policy is not configured, or, configured but the permission hasn’t been granted to the gMSA account a “Directory services user credentials are incorrect” alert is displayed. In such scenarios, you need to configure log on as a service policy using any of the two ways.
4.1 To configure the Log on as a service policy in a Local Security Policy
- Run the following command – secpol.msc
- Select “Local Policies” and navigate to “Log on as a service policy” under User Rights Assignment.
- To add the gMSA account to the list of accounts under log on as a service policy, select the account > “Add User or Group” > “OK”
4.2 To configure the Log on as a service policy in a Group Policy setting
- Run the following command – rsop.msc
- Navigate to “Computer Configuration” > “Windows Settings” > “Security Settings”.
- Then go to “Local Policies” > “User Rights Assignment”
- Check if “Log on as a service policy” is selected.
- If yes, on the Group Policy Management Editor panel, add the gMSA account to the list of accounts that can log on a service.
5. Configure a Directory Service Account in Microsoft Defender XDR
- Launch Microsoft Defender XDR
- Navigate to “Settings” > “Identities”
- Click on “Directory Service accounts” on the left panel to view a table of accounts listed with their respective domains.
- Fill the “Account name”, “Domain”, and “Password” fields using the credentials of previously created account.
- You can also choose to check the boxes next to “Group managed service account” (gMSA) and “Single label domain”, if needed.
- Click “Save”.
- To view the settings of any account, select the account to open its “admin settings” panel.
Key considerations
As gMSAs provide automatic password management, their accounts have passwords that are randomly generated and automatically changed on a regular basis by the Windows operating system. However, the above approach can be used to reset the password for other standard Active Directory user accounts. If your AD environments contain a multi-forest or multi-domain architecture, it is suggested that the gMSA you create has a unique name in each forest or domain in your AD environment. Additionally, you can create a universal group consisting of the computer accounts in all sensors in each domain. This ensures that all the sensors can retrieve the gMSAs’ passwords, and carry out cross-domain authentications.