Securing Active Directory

IT administrators have been working with and around Active Directory since the introduction of the technology in Windows 2000 Server. Windows 2000 Server was released on February 17, 2000 but many administrators began working with Active Directory in late 1999 when it was released to manufacturing (RTM) on December 15, 1999.

Active Directory Security

Security is a huge topic because it encompasses so many areas. Even in a specific technology like AD Database, security is a huge topic. For this e-book, we will focus on 3 specific areas of security in AD DS:

  • Securing LDAP traffic with SSL/TLS
  • Modifying the access control list (ACL) on administrative accounts
  • Enabling strong authentication in a domain

 

Securing LDAP traffic

The first step to securing LDAP traffic with SSL/TLS is to install AD CS. It is a good practice is to install the role on a member server. Before you begin implementing a PKI, you should spend ample time gathering information, designing the PKI, and planning. Once you have an operational PKI, you can issue a certificate to each DC. It is also possible to use a third-party Certification Authority (CA) to secure LDAP communication. The certificate must not have strong private key protection enabled.

Additionally, the DC FQDN must appear in either the Common Name of the Subject field, or as a DNS entry in the Subject Alternative Name extension.

They Enhanced Key Usage must also include Server Authentication as an option, object identifier (OID) 1.3.6.1.5.5.7.3.1 By enabling LDAP over SSL, LDAP communication can occur on both ports 389 (LDAP) and 636 (LDAP/SSL). Global catalog requests performed with SSL used port 3269.

The certreq.exe command can be used to create a new certificate request. To create a request, run the following command:

  • certreq -new request.inf request.req

The request.inf file must contain the DC FQDN, and also provides information on the key length and request time. For a full example of the request.inf file, see http://support.microsoft.com/kb/321051. The request.req file will be created, and must be submitted to the CA. After receiving the certificate, process the request with the certreq.exe command.

  • certreq -accept certnew.cer

To verify that SSL has been enabled successful, the Active Directory Administration Tool (ldp.exe) can be used to manually connect to the AD DS environment. Launch the ldp.exe tool, and perform a new connection. In the port field, specify 636. If the RootDSE information is displayed, LDAP over SSL has been configured successfully.

Modifying the access control list (ACL)

Another way to secure AD DS is to modify the ACL of user accounts that have administrative privileges.

User accounts in administrative groups have their ACLs replaced every hour by a process on the PDC Emulator. This process compares the ACLs on each account in the administrative groups and the group itself to the AdminSDHolder object. In a domain named contoso.com, the object is located at CN=AdminSDHolder,CN=System,DC=Contoso,DC=Com. Any difference between the account and the AdminSDHolder object is then replaced on the account.

The following groups and members of these groups are checked by the AdminSDHolder process:

  • Administrators
  • Account Operators
  • Cert Publishers
  • Backup Operators
  • Domain Admins
  • Enterprise Admins
  • Print Operators
  • Schema Admins
  • Server Operators

Additionally, the Administrator and krbtgt user accounts are also checked independently regardless of group membership.

Accounts that are protected by the AdminSDHolder process can be identified by the adminCount attribute of the account. If the account is being protected, this attribute will be set to 1.

To modify the ACL of an account being protected by the AdminSDHolder process, three steps must be taken to verify that the ACL is not replaced.

  1. Remove the account object from all protected groups.
  1. Set the adminCount attribute to 0.
  1. Enable inheritance on the account object.

Note that simply changing the adminCount to 0 without removing the object from the protected groups will not stop the process from replacing the ACLs. Removing the object from the groups without modifying the adminCount attribute doesn’t fix the situation.

Another solution is to modify the AdminSDHolder object to include the ACLs that you want to apply to the user accounts. By including the additional access control entries in the AdminSDHolder object, they will also be included when the ACLs of each account object is compared. This is useful for modifying the permissions of all administrative user account objects.

Strong domain authentication

Another area of AD DS security is to enable strong domain authentication in your environment.

This will ensure that users can authenticate to Active Directory by using only strong authentication protocols. By default, Windows Server 2012 accepts authentication requests that use NTLM and NTLMv2, although it responds by replying with NTLMv2 only.

This setting can be restricted by modifying the “Network Security: LAM Manager Authentication Level” setting in group policy. This setting is applied to DCs, and can be set to “Send NTLMv2 response only. Refuse LM and NTLM.” By configuring this setting, DCs will not respond unless they receive an NTLMv2 request.

More information about Active Directory basisc you will find in our AD tutorial for beginners.