Microsoft Defender for Identity Recommended Actions: Resolve Unsecure Domain Configurations

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with fourteen recommended actions. In a series of blog posts, I will go through all fourteen recommended actions of what it means, a plan of approach, their impact, and my security recommendations, hopefully helping others. The first one in the series is the “Resolve unsecure domain configurations” recommended action.

Introduction

If you filter the Secure Score recommended actions for Microsoft Defender for Identity, you have the following fourteen recommendations.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop legacy protocols communication
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account

Some recommended actions are easy to configure, but others take time, proper planning, auditing, and expertise. This blog post will review the “Resolve unsecure domain configurations” recommended action.

Update: Microsoft updated the recommended actions with an additional six recommendations, which makes it a total of twenty. I will describe the six updated ones after this series.

Resolve unsecure domain configurations

The recommendation’s description and title make it unclear which configurations Microsoft is talking about.

You get detailed information about the unsecured domain configurations if there are any exposed entities, though.

Luckily, Microsoft also provides a link in the implementation tab, which gives us more information. What it comes down to is the following.

1. Enforce LDAP Signing policy to “Require signing.”
2. Set ms-DS-MachineAccountQuota to “0”.

The latter is the easiest of the two. By default, every authenticated user can join ten machines to the domain. Back in the day, it was easier if a user could join a device to the domain, but now that malicious actors misuse this feature, it is wise to limit the machine’s count to zero. If an automated process adds devices to the domain, it has permission to bypass the default limit of ten anyway, so the impact then is presumably very low.

Set ms-DS-MachineAccountQuota to “0”

Some organizations set the “ms-DS-MachineAccountQuota” property to a high number not to hit the ten-device limit, which is even worse. In any case, I highly recommend setting the “ms-DS-MachineAccountQuota” property to 0. Continue reading if you want to know how.

Before setting the “ms-DS-MachineAccountQuota” property to 0, you can be sure a service account or administrative account can add computers to the domain regardless of changing the “ms-DS-MachineAccountQuota” property to 0. There are two main ways to set the permissions.

1. Add a group policy to an organizational unit with the following policy set: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Add workstations to Domain.
2. Create a custom task to delegate using delegation of control and set “Create All Child Objects” for “Computer Objects” for a user or group.

Note: You can only link Group Policy Objects (GPO) to organizational units. If you want to use the “Computers” container in Active Directory, use option 2.

Here is an example of the policy to add an account to add computer objects to the domain.

Here is an example of delegation of control to set permissions for an account to add computer objects to the domain.

Now that the account responsible for adding computer objects to the domain has the proper permissions, use ADSIEDIT to change the limit to 0 for the “ms-DS-MachineAccountQuota” property. Search for the property “ms-DS-MachineAccountQuota” and change it to 0.

Note: If you do not know which account is responsible for adding computer objects to the domain, you can check the event viewer on all domain controllers for event 4741. You can leverage Microsoft Defender for Identity auditing, which monitors “Audit Computer Account Management.”

Enforce LDAP Signing policy to “Require signing”

Unfortunately, enforcing Lightweight Directory Access Protocol (LDAP) Signing is not as easy. Unsigned network traffic is susceptible to a man-in-the-middle attack, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. So, signing is an excellent way to prevent man-in-the-middle attacks. Still, client devices not supporting LDAP signing can not run LDAP queries against the Domain Controllers and will probably cause production disruption. Looking at the possible impact of this recommendation is enormous. Luckily you can monitor the environment for unsigned requests to see their effect before enforcing LDAP Signing. The critical point here is auditing. To determine the impact, you need to audit first.

You enable diagnostic logging on all domain controllers to collect LDAP logging. The following PowerShell command is enough to allow LDAP to audit.

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name "16 LDAP Interface Events" -Value 2 -PropertyType DWORD -Force

Every insecure bind to the Domain Controller creates an event with event ID 2889 in the Directory Service log.

Note: By default, the maximum log size of the Directory Service log is only 1 MB. Changing the size of the Directory Service log is recommended before continuing. Right-click Directory Service in the event viewer and click “Properties.” Change the size to at least 16384 KB (16MB) and possibly higher when in a large organization.

You only want to see the insecure binds to the Domain Controller, but we can authenticate clients over TLS/SSL connections if supported using the following policy.

Using this policy does not affect unsupported clients. Unsupported clients still connect to Active Directory using an unsigned connection. So, once you have set the diagnostic logging and the policy to force TLS/SSL if supported, it is easy to see which clients are using an insecure bind using event 2889 in the Directory Service log. Once you identified the accounts connecting to Active Directory using an unsigned connection, check why the account uses unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection.

Conclusion

The critical point for probably every recommendation is auditing. You need to audit to know what the impact will be. Since the default value for the “ms-DS-MachineAccountQuota” property is ten, I would expect most organizations still use the default value. Since more and more attacks use a computer object in Active Directory, which they need to know the password for, which is the reason for attackers to create their computer object in Active Directory, I highly recommend lowering the “ms-DS-MachineAccountQuota” property to 0.

LDAP signing is a tricky one, but with proper auditing, it is just a matter of appropriate auditing and determining the impact before implementing LDAP signing.