Securing Domain Controllers by Auditing Active Directory

Misconfigured Domain Controllers (DCs) present a major security risk for Active Directory. To ensure that your Domain Controllers are configured correctly, you will need to closely review the default Domain Controller Policies, create Domain Controller GPOs (Group Policy Objects) and configure Group Policy Settings. Your policy will need to include patching and protecting Domain Controllers, and include an effective DC auditing strategy for monitoring and reporting changes to event logs. As always, you must thoroughly test your setup before deploying changes.

Default Domain and Domain Controller Group Policies

When you first create an Active Directory domain, a pair of Group Policy Objects are created by default. These are: Default Domain Policy and Default Domain Controllers Policy. Unlike standard AD object GUIDs, theses GPO GUIDs are the same for every instance of AD, as this helps Windows quickly locate them if they are deleted and need to be restored. The Best Practices Analyzer for Active Directory Domain Services can check to ensure that the default GPOs are correctly applied.

The default Domain Policy should consist of the following three settings:

– Password Policy

– Kerberos Policy

– Account Lockout Policy

The default Domain Controller Policy should consist of the following two settings:

– User Rights Assignment

– Security Options

Creating Domain & Domain Controller Security Baseline GPOs

While it’s tempting to change the settings of the default GPOs, it is better practice to add or customize the settings in a new GPO, as it will make organising and changing GPO settings easier. When dealing with password policies, you can create a new GPO and place the policy settings in there. You can then link the policy to the domain and change the link order to 1.

In earlier versions of Windows, customizing the Default Domain Policy GPO was a requirement. While doing it this way is not a major problem, it’s still better to add new settings to a separate GPO.

The default password policy settings are not very secure. It is recommended that you fine-tune the policy to ensure that accounts that perform critical operations have a much stricter policy than those that don’t.  Below is a basic checklist to help you configure your password policy settings:

• Enforce Password History : 24 (the default setting will do).
• Maximum Password Age : 60 – 180 depending on the minimum password length specified by your organisation.
• Minimum Password Age : 1. This should be set to 1 or above in order to prevent users using previously used passwords.
• Minimum Password Length : 14. This is the highest minimum password length the Group Policy Management Console (GPMC) allows, although there are unsupported ways to set a higher value.
• Password must meet complexity requirements : Enabled.
• Store passwords using reversible encryption : Disabled.
• If set to enabled, a password’s encryption can be reversed – effectively allowing it to be extracted by an attacker.
• Account lockout threshold : 5 – 20 invalid logon attempts.
• Account lockout duration : 1 – 90 minutes.
• Reset account lockout counter after : 5 – 60 minutes.

To start with, you will need to create two new GPOs (you can name them as you wish):

– Domain Security Policy

– Domain Controller Security Policy

NOTE : The Domain Security Policy should contain settings that apply to the entire domain.

There are two different approaches to managing Group Policies: The first is to use as few GPOs as possible, with a large number of related settings in each GPO, and the other is to use separate GPOs which contain smaller groups of related settings. Of course, you can use both approaches depending on the GPOs purpose.

Patching Domain Controllers

It is obviously important to apply security patches to Domain Controllers as soon as they are released; however, there is a valid concern that applying the security patches might break some part of the system. Below are some points to consider when applying security patches:

• Don’t apply the patches to all Domain Controllers at once. You should instead test the patch on a subset of DCs. Assuming the patch didn’t create any adverse consequences, you can apply the patch to all DCs. One approach would be to apply the patch to all odd numbered DCs, before applying the patch to all even numbered DCs.
• Apply critical patches first. Patches that relate to things like privilege escalation or remote code execution, should be prioritised.
• Any services, such as a DNS service running on a DC, should also be patched in order to mitigate potential security breaches.
• Servers should be fully patched before being assigned the role of a DC
• You should have a well-rehearsed back-up and restore policy to help you cover all eventualities

Protecting Domain Controllers

As you would expect, newer versions of Windows Server have significantly better security features than older versions; however, security patches and updates will be provided for older versions that are still supported. You should make sure that you only install Windows (or any other software) from a trusted source. Ideally, you shouldn’t have any other software or services installed on Domain Controllers since each additional application installed creates a potential security risk. DCs should be patched in an isolated environment – using tools like Windows Server Update Services (WSUS).

Since there is rarely a good reason for Domain Controllers to have direct access to the internet, it is a good idea to have the Windows firewall enabled and configured.

Perhaps the most effective way to protect Active Directory is to limit access privileges to Domain Controllers, specifically admin and logon rights. The following access rights should be defined to ensure least privilege for Domain Controllers:

• Deny log on as a batch job : Guests
• Allow log on locally : Administrators
• Allow log on through Remote Desktop Services : Administrators
• Add workstations to domain : Administrators
• Shut down the system : Administrators
• Backup file and directories: Administrators
• Restore file and directories : Administrators
• Access this computer from the network : Administrators, Authenticated Users, Enterprise Domain Controllers
• Deny access to this computer from the network : Guests, NT AUTHORITY\Local Account
• Log on as a service : [specific accounts should be entered here]
• Domain controller: Allow server operators to schedule tasks: Disabled
• Deny log on through Remote Desktop Services : Guests, NT AUTHORITY\Local Account
• Devices : Prevent users from installing printer drivers: Enabled

Domain Controller Recommended Group Policy Settings

Below are the recommended security settings for Domain Controllers. Remember to fully test these settings before applying them to all DCs.

Enable NTLM Auditing

• Restrict NTLM : Audit Incoming NTLM Traffic: Enable auditing for all accounts
• Restrict NTLM : Audit NTLM authentication in this domain: Enable all
• LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM
• Lsass.exe audit mode: Enabled
• Enable LSA Protection: Enabled
• Domain member: Require strong (Windows 2000 or later) session key: Enabled
• Network security: Minimum session security for NTLM SSP based (include secure RPC) Servers: Require NTLMv2 session security, Require 128-bit encryption
• Network security: Minimum session security for NTLM SSP based (include secure RPC) Clients: Require NTLMv2 session security, Require 128-bit encryption
• Microsoft network server: Digitally sign communications (if client agrees): Enabled
• Microsoft network server : Digitally sign communication (always): Enabled
• Microsoft network client : Digitally sign communication (always): Enabled
• Network access : Do not allow anonymous enumeration of SAM accounts and shares: Enabled
• WDigest Authentication (disabling may require KB2871997) : Disabled

Securing Domain Controllers using Lepide Data Security Platform

It is crucial that you know who, what, where and when, changes are being made to the files, folders and permissions on your network. You need to be able to monitor who logs on locally and through Remote Desktop Services. You will need to know who has the rights to shut down the system, backup and restore files and directories, and register a process as a service. Our Lepide Data Security Platform provides a range of tools which allow you to keep track of such changes within Active Directory. Our solutions enables you to audit changes to Group Policy, including changes to security group membership. On top of which, we provide threshold alerting tools to help spot suspicious password attempts, as well as provide notifications about password expiration.

Key Domain Controller Security Items

• Servers should have all patches applied before being assigned the role of a DC.
• Avoid moving Domain Controllers outside of the default Domain Controllers OU.
• Create a GPO for each new Domain Controller.
• Use The Best Practices Analyzer to ensure that your DC has been optimally configured.
• Patching of DCs should be done separately and systematically. Perhaps use WSUS to patch DCs and SCCM for everything else.
• Out-of-band (OOB) management passwords, such as DSRM passwords, must be periodically reset, and stored in a secure manner.
• “Force audit policy subcategory settings to override audit policy category settings” via GPO to track changes in AD sub-categories.
• Avoid installing software on DCs, as each installed program introduces a potential security risk.
• Treat virtual admins as Domain Admins.
• Since AD requires DC clocks to be synchronized, configure the primary domain controller (PDC) to automatically synchronize time via GPO.
• Apply the principal of least privilege to DC admin/logon rights.
• Change the default admin account at least once a year.
• Change the KRBTGT account password at least once a year and use a KRBTGT account password reset script.
• If you really need to run an application on a DC, use AppLocker to ensure that only authorized applications are allowed to run.
• All admin accounts should be set to “sensitive & cannot be delegated”.
• Add admin accounts to “Protected Users” group.
• Remove obsolete trust relationships and enable SID filtering.
• Set all domain authentication to: “Send NTLMv2 response only\refuse LM & NTLM.”
• Disallow direct internet access to DCs and servers.
• Monitor scheduled tasks on DCs and servers.