Microsoft windows directory services sam

Last Updated on March 19, 2023 by

In Part 01 of Microsoft Defender for Identity blog series, I have explained about Microsoft Defender for Identity and it’s benefits. I also talked about the prerequisites. In that list, I mentioned that we required Directory Service Account(DSA) to connect to Active Directory forest.

There are two types of DSAs we can use for this task.

1) Regular Active Directory user account
2) Group Managed Service Account (gMSA)

From above, the regular user account is the easiest to setup but that required to manage password manually. Even though this account will only have read-permission on all the objects, it is still create a security risk. Therefore the recommended type for DSA is gMSA. In this article I am going to demonstrate how to create gMSA account with relevant permissions. If you are new to gMSA term, please read following article to get understanding about gMSA. https://www.rebeladmin.com/2018/02/step-step-guide-work-group-managed-service-accounts-gmsa-powershell-guide/

Role of DSA

The DSA required read permission for all AD objects. But why? We need DSA to do following tasks.

1) In initial setup of Microsoft Defender for Identity sensor, we use LDAP to connect to domain controller. This required user name and a password.
2) MDI sensor need to query domain controller to find data about objects appeared in events, traffic.
3) The MDI sensor which act as “domain synchronizer” will connect to domain and track changes of objects and attributes.
4) MDI need to query about members of local administrator group by using SAM-R protocol. For that DSA should have remote access rights to the device.

Apart from that there are few other things you need to consider before setting up DSA.

1) DSA should read-only access to all the objects in Active Directory (including deleted object container).
2) If it is multi-domain/multi-forest environment, you can use one DSA as long as it has read permissions to all the objects. But if it is disconnected environment, each forest should have a DSA account.
3) By default MDI support for 30 DSA accounts, if its more than that you need to contact MDI support.
4) It is recommended to create DSA entry in root domain.
5) It is possible to use both types of DSA accounts in a configuration but gMSA entries get the priority in the processing order.
6) If MDI sensor cant do LDAP authentication in the start-up, the sensor will not enter running state.

When we use gMSA account as a DSA, the sensor should have permission to retrieve the password from Active Directory. The best way to do this is to create security group and assign Domain controllers and ADFS servers to it. Then grant permission by using -PrincipalsAllowedToRetrieveManagedPassword to the group. If you are not planning to use ADFS, you can also use built-in Domain Controllers security group for this.

Let’s start the configuration process by creating Global Security group.

1) Log in to Domain Controller as Domain Admistrator.
2) Run New-ADGroup -Name “MDISensorGrp” -GroupCategory Security -GroupScope Global -Path “OU=Servers,DC=rebeladmin,DC=com”

3) This will create a global security group called “MDISensorGrp”. Path of the above command should change according to your environment.

After the group is in place, we need to add all the Domain Controllers and ADFS servers to it. If you add a server to the group later on, that new server will not get permission until new Kerberos ticket is issued. You can get new Kerberos ticket by rebooting the server. Also you can purge existing tickets and it will force domain controller to request new ticket. We can do this by running klist purge -li 0x3e7 command as an administrator.

The next step of this configuration is to assign members to the newly created user group.

Add-ADGroupMember -identity “MDISensorGrp” -Members PDC01$,SDC01$

In above, I am adding PDC01 & SDC01 domain controllers to the “MDISensorGrp” security group. Please note you need to add $ to the end of the hostname as it is the pattern of the sAMAccountName.

Now we have the group in place. Next step of the configuration is to create the gMSA account.

New-ADServiceAccount -Name mdisvc01 -DNSHostName “mdisvc01.rebeladmin.com” -PrincipalsAllowedToRetrieveManagedPassword MDISensorGrp

In above mdisvc01 is the gMSA account name. We are granting password retrieve permission to MDISensorGrp security group by using -PrincipalsAllowedToRetrieveManagedPassword

Note – Here I assume to KDS root key is already created by using the Add-KdsRootKey cmdlet. If not please follow https://www.rebeladmin.com/2018/02/step-step-guide-work-group-managed-service-accounts-gmsa-powershell-guide/ and create KDC root key.

After account is in place, we can go ahead and install the account in each server by using,

Install-ADServiceAccount -Identity mdisvc01

Note – If you get access denied error, please restart the server to apply permissions.

Once account is installed, we can test it using,

Test-ADServiceAccount -Identity mdisvc01

This completes the gMSA setup and installation.

Configure SAM-R permissions

MDI uses SAM-R protocol to query about members of local administrator group. To do this, DSA account should have specific remote access permissions. We can use GPO to apply this permissions.

1) Create New GPO or select existing GPO for this task. This policy should apply to all computers except Domain Controllers.
2) Open the policy using Group Policy Management Editor and go to Computer configuration | Policies | Windows settings | Security settings | Local policies | Security options
3) Then open policy Network access – Restrict clients allowed to make remote calls to SAM

4) Then click on Define this policy setting

5) Click on Edit Security … button and then add DSA account to the list.

6) Then click on OK to apply the changes.

Note : If you define Access this computer from the network policy setting in any GPO, you need to add DSA account to the list. This policy is located under Computer Configuration | Policies | Windows Settings | Local Policies | User Right Assignment

******* Updates ***************************

1. RODC’s should also have permission to use gMSA account.
2. MDI will no longer support Windows Server 2008 R2 from 15/6/2022
3. Validate the SAM-R hotfixes as listed in Network access – Restrict clients allowed to make remote calls to SAM – Windows security | Microsoft Docs
4. SAM-R Network access: Restrict clients allowed to make remote calls to SAM policy can break applications that uses AuthZ interface. ex- MS Exchange 2016, 2013. If you use such applications, use steps describe in Access checks fail because of AuthZ – Windows Server | Microsoft Docs to fix the issue.
5. If you are using GPO to manage “log on as service” accounts, make sure you add MDI service account to that. Otherwise the sensor service will not start.
6. Service Account should have read-only permissions on the Deleted Objects container. This allow Defender for Identity to detect user deletions from your Active Directory. when you are granting permission the ownership for the ACL should change first as default ACL is system only. dsacls “CN=Deleted Objects,DC=rebeladmin,dc=com” /takeownership Also When adding the gMSA to the ACL, a ‘$’ suffix must be used or an error will be received, “No Sid Found for rebeladmin.com\aatp No mapping between account names and security IDs was done.” dsacls “CN=Deleted Objects,DC=rebeladmin,dc=com” /g rebeladmin\gmsa$:LCRP

**** Special thanks to Ben Robinson – Microsoft Security Architecture for valuable feedback *****

Now we have a DSA ready for the deployment. In next blog post I will demonstrate how to enable Advanced auditing for MDI. Meantime If you have any questions, feel free to contact me on rebeladm@live.com also follow me on Twitter @rebeladm to get updates about new blog posts.