Five ways to Keep Active Directory Secure

Living in a Cloud-First World

We live and work in a cloud-first world. Companies of all sizes build and use cloud services. Despite the focus on the cloud, on-premises Active Directory (AD) remains a vital component of companies’ IT infrastructure. AD should be considered a Tier 0 asset, meaning that if AD is compromised, the entire infrastructure is compromised. Considering Microsoft released Active Directory with Windows 2000 Server, over 20 years ago, there are many security options and best practices that you need to think through when managing and maintaining your company’s AD. Default settings from 20 years ago do not apply to Active Directory today. In this article, I describe five key things you can do to secure Active Directory for today’s environment.

Backup and Restore

First and foremost, it is critical that you back up AD. As it turns out, CTOs and CISOs don’t really care about backups. What really matters is whether the backup can successfully restore data. The built-in Windows Server Backup feature and third-party products can facilitate the backup and restoration of Active Directory. Regardless of which method you use, it is imperative to test the restore process regularly.

Tests should not be limited to restoring an object, a set of objects, or even a single domain controller. The restore process should handle scenarios where the entire Active Directory is compromised. The kind of ransomware attacks prevalent today means that this scenario occurs more often. The possibility of ransomware hitting all the DCs in a company keeps CISOs up at night.

Patching

Patching domain controllers is another critical process that simply must happen. If your DCs are unpatched, they are owned by someone else.

Patching is tricky. Windows exploits come fast and furious. Microsoft develops patches to mitigate these exploits. Occasionally, these patches can have unintended consequences. Patching is a game of risk. Most of the time, if you deploy patches quickly you will win the game and mitigate the risk of being vulnerable to an exploit.

This is why having a patching ring strategy is important. The first ring of servers to receive patches should include some test DCs, then a slightly larger ring that includes a minimal set of production DCs. Eventually, once a patch is proven, it is pushed out across the enterprise. The number of rings and size of rings should be adjusted according to the size of your environment.

Another thing to consider when patching DCs is that domain controllers are tier 0 assets. This means that anything that manages a DC should also be considered a tier 0 asset. While it can be quite a bit of overhead, you typically do not want to use the same system that patches all your workstations and servers to also be patching your domain controllers.  One option to mitigate this risk is to set up a Windows Server Update Services (WSUS) instance dedicated to patching domain controllers.

Limit Privileged Group Membership

One consistent problem I see in Active Directory audits is that the Domain Admins group has more members than necessary. AD has a number of built-in privileged groups. In modern AD deployments, these groups are rarely used. Instead, rights to perform specific tasks are delegated to groups. For example, you don’t need to be a Domain Admin to create users, groups, and computers. These privileges should be delegated to groups that perform these actions for a certain Organizational Unit. For example, you could have a group called “Computer Management” and delegate the right to create, update, and delete computer accounts within a specific OU.

In addition to Domain Admins, other groups that often have too many users are Enterprise Admins and Schema Admins. Except for perhaps a break glass account, these groups should remain empty. A Domain Admin can self-elevate to either group if necessary, but the rights provided by Schema Admins and Enterprise Admins are not needed on a day-to-day basis to manage Active Directory.

Another built-in group that is often misunderstood is “Remote Desktop Users” domain group. I have seen several instances where dozens or even hundreds of people are added to this group because someone thought they needed to be in this group to use Remote Desktop (RDP) to access servers. The Remote Desktop Users domain group allows users to RDP into domain controllers. This group should be empty.

The last two groups to monitor for too many members are Account Operators and DNS Admins. It is much better to delegate to groups and allow them to perform specific tasks rather than use these built-in groups that have more permissions than necessary.

One final note on privileged users. AD admins should have dedicated accounts for AD administration. Do not use the account you use for day-to-day activities, such as signing into workstations, checking email, and browsing the web, to RDP into a domain controller.

Remove Unconstrained Kerberos Delegation

Kerberos delegation allows applications to request end-user credentials to access resources on behalf of an end user. When Windows 2000 Server originally shipped, the only option for delegation was unconstrained. This allows a service to act on behalf of a user and use those credentials to access any other service on the network, a practice that has proven to be insecure and used in numerous types of attacks.

Constrained delegation allows an application or service to use end-user credentials only on a specific service. For example, a web server may only be able to delegate access to a SQL database server on the backend, but nothing else. To find any computers that are using unconstrained delegation, you can use the following PowerShell command:

Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description

Without the filter for “primarygroup -eq 515”, domain controllers are included in the results. Domain controllers are required to be configured with unconstrained delegation to function properly.

If any application use unconstrained delegation, it is important to work with the vendor or developer to change it to constrained delegation.

Remove Support of Older Protocols

Three particular protocols often appear in findings when I audit Active Directory; NT LAN Manager (NTLM), Server Message Block (SMB), and Lightweight Directory Access Protocol (LDAP). Active Directory has been around for over 20 years, and so have these protocols. All three protocols have known vulnerabilities that attackers can use to compromise a network. Unfortunately, there are still applications in the wild that use these legacy protocols, which can make it difficult to get rid of them. A business-critical application that only supports NTLM v1 for authentication can put a Systems Administrator in a tough position. The truth is, retiring protocols often require non-technical skills. It will most likely involve meeting with application owners and stakeholders to help them understand the risk and create a mitigation plan to either upgrade or replace the application. If an application truly is business critical, it should be supported by the vendor or developer, and updates should be available so that older protocols are not required.

NTLM

There are three different versions of NTLM: LAN Manager (LM), NTLM v1, and NTLM v2. LM and NTLM v1 are both insecure and should be removed from your network infrastructure whenever possible. To find applications that use NTLMv1, enable Logon Success Auditing on domain controllers, and then look for success auditing event 4624, which contains information about the version of NTLM.

Configuring NTLM can be done using Group Policy under “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.” The default configuration for NTLM is to “Send NTLM v2 response only.” To get rid of LM and NTLM v1, this should be set to “Send NTLMv2 response only. Refuse LM and NTLM” for domain controllers, workstations, and member servers.

LDAP

LDAP is a protocol that is insecure by default. Two settings can enhance the security of LDAP. The first is to force LDAP to require signing. One approach is to deploy certificates on domain controllers and have clients access LDAP using LDAPS over port 636. However, this is not necessary. Clients can sign LDAP requests using their Kerberos session key and continue to access LDAP over port 389. It is also important to enable channel binding. Channel binding secures LDAP against Man in the Middle attacks.

Enforcing signing and channel binding can break older applications in your network. You can enable LDAP auditing by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\LDAP Interface Events registry key to 2. You can raise it up to 5 for the most detail, but it will also produce a lot of noise in the event log. Level “2” is basic logging and will give you information on clients that are using LDAP in an insecure fashion.

SMBv1

Last but not least, SMBv1 is a protocol that should be removed from your network. SMB is a network file-sharing protocol. Similar to LDAP and NTLM, Auditing can be enabled to find servers that are still using SMBv1. When auditing is enabled, event 3000 appears in the “Microsoft-Windows-SMBServer\Audit” event log and will identify the client that is attempting to connect using SMBv1. This must be done across the network to identify any servers that are serving SMBv1.

Conclusion

The five points covered here create a strong foundation to secure Active Directory. The list is not complete, but it will serve you well on your journey to keep Active Directory secure.