Professor Windows - February 2003

  • Article

Active Directory Security Tips and Practices

By Yossi Saharon

Reviewed By: Arun Nanda, Program Manager - Directory Services, Microsoft Corporation

Introduction

Active Directory (AD) is one of the most important reasons (if not THE reason) that the Windows 2000 platforms achieved the latest CC (Common Criteria) evaluation win of EAL4 + Flaw remediation, the highest Security level ever given to a commercial operating system (see https://www.microsoft.com/technet/security/prodtech/Windows2000/w2kccwp.mspx for more information). We can significantly increase information security in our Active Directory environments by using some simple practices and leveraging certain capabilities. This article will give you a look into some useful tips for securely operating Active Directory, day by day. In addition, this topic is covered at length in more detail and with prescriptive guidance in the recently published white paper: Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part I.

This column assumes you have knowledge of Active Directory terminology and architecture. To read more on Active Directory Technologies, see the following link: https://www.microsoft.com/windows2000/technologies/directory/default.asp

Hardening Your Active Directory Operations

You can achieve higher levels of security in your day-by-day Active Directory operations by adopting certain configuration settings.

Some examples for such settings are as follows:

  • You can "harden" your Domain Controllers' configuration by using Security Templates, which are files that contain relatively restricted configurations and group policy settings. These templates are good starting points, but may not provide adequate security in some cases. Make sure you test these templates before applying them to production servers, to avoid "over-hardening" your Domain Controller in such way that can possibly affect its functionality. You can find sample Security Templates on the Windows 2000 Security Operations guide. Security template settings are covered in detail in the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations.

  • Beginning with Windows 2000 Service Pack (SP) 3, Windows XP SP1 and Windows Server 2003 RC1, all Light Weight Directory Access Protocol (LDAP) traffic to AD is signed & sealed, even when you work daily with your Active Directory MMC Snap-ins. This behavior is automatically turned on when applying SP3 to Windows 2000 Servers or using Windows Server 2003 Domain Controllers. Updating your Windows 2000/XP computers to the proper service pack level is recommended, so all LDAP traffic can be signed & sealed.

  • Passwords are a relatively weak link in information data security. To further protect your password hashes, you can remove the relatively weak LanMan (LM) Hash, from you Active Directory and Security Account Manager (SAM) with a registry key setting on your Domain Controllers. You can turn off the LM Hash by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\NoLMHash to 1 (Enabled). (P.S: Windows Server 2003 implements this setting as a group policy). Pay attention that the LM hash for a user account is not removed until the next time the user changes his password. You will have to accompany this key setting with a password change for all users, and make sure all users have changed their passwords. You can find a script that helps you reset the user passwords all together at the TechNet Script Center.

  • Continuous to the above settings (NoLMHash), Windows 9x clients will still attempt to send LM response along with NTLM, regardless of the setting specified at the server. In order to prevent the LM response from being sent over the wire you can avoid it from the client side by installing the DS Client for Windows 9x and setting the following key: HKLM/SYSTEM/CurrentControlSet/Control/Lsa/LMCompatibilityLevel

    The values for this registry key are:

    • 1: Use LM and NTLM, never use NTLM2
    • 2: Use LM or NTLM Authentication. Use NTLM2 session security if possible
    • 3: Use NTLM only. Use NTLM2 if the server supports it.
    • 4: Refuse LM Authentication (Windows NT 4 DC). Clients use NTLM2 only
    • 5: Refuse LM and NTLM Authentication (Windows NT 4 DC). Clients use NTLM2 only

    To use NTLMv2 only, set this registry key value to 5.

  • Windows 2000/XP workstations can perform Kerberos based authentication to Active Directory, yet down-level clients perform their negotiation by default using NTLM. You can enforce those previous versions of clients (Windows 95/98/NT) to perform their authentication with NTLMv2, so the session key is encrypted and provides a more secure authentication process than NTLM, See 239869: How to Enable NTLM 2 Authentication for Windows 95/98/2000 and NT.

General Considerations and Practices

In addition, there are several practices you can use in your Active Directory environment to achieve higher levels of security:

  • Make sure your machines are up-to-date with the relevant security fixes. Distributing patches and updates can be done using Microsoft Systems Management Server (SMS) and other tools. You can also use Microsoft Software Update Services (SUS) to automate the distribution of critical security updates to domain members.

  • Use the "Trusted For Delegation" option wisely. This powerful configuration enables a machine to perform delegated authentication and operate any service on other machines in the domain.

  • For increased Security, enforce the use of Smart Card login for administrators at minimum.

  • You can achieve high integration between Internet Security and Acceleration (ISA) Server and Active Directory and consolidate your Firewall/VPN users with the domain accounts and simplifying accounts management. Active Directory has also been certified for CheckPoint VPN and Firewall integration. See http://www.opsec.com/.

  • Make sure your account policies are "in shape": Prevent anonymous logon when not needed, enforce strong & complex passwords, with minimum characters etc. Again, these settings are covered in detail in the Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations.

  • When performing Domain Controllers replication over Remote Procedure Calls (RPC), you may want to limit the number of ports involved in the process, especially behind firewalls in a WAN configuration. RPC replication is performed dynamically against the RPC EndPoint Mapper (Port 135) which selects a high port between 1024 to 65535. You can significantly decrease the number of ports needed to be opened by locking down your Domain Controller on using a specific port for Active Directory RPC Universal Unique Identifier (UUID). This can be done by adding a DWORD value named TCP/IP Port under the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\NTDS\Parameters

    The value of this new DWORD key should be the specific port number you wish to use for Active Directory RPC replication. Alternatively, you can use IP Security (IPSec) to encrypt all (or certain) ports and traffic between Domain Controllers. To read more on options to use Active Directory over segmented networks separated by firewalls, see https://www.microsoft.com/windows2000/techinfo/planning/activedirectory/adsegment.asp.

  • Limit the number of members in highly sensitive groups in your Active Directory, such as Enterprise Admins or Schema Admins.

  • Although Active Directory can successfully utilize DNS Services from several types of DNS Servers that support SRV records, it's preferred that you work with Windows 2000 DNS Servers using Active Directory integrated zones. Working with AD Integrated Zones saves DNS information in Active Directory rather than in text files, and allows Secure Dynamic Updates, so you can control who can perform DNS registrations.

  • Active Directory has granular permissions and is capable of applying permissions per object down to the property level. You can use these capabilities to design delegation of administration in Active Directory.

  • You can limit users to certain hours of activity using the logon hours settings. You can also restrict users to login to specific workstations only. These options can be set when editing the user's properties from the Active Directory Users & Computers MMC snap-in, or via scripting (you can find some useful scripts to manipulate user & groups information at the TechNet Script Center.

  • Use Connection Manager Administration kit to create custom dial-up connection settings for your Remote Access Services (RAS) users, along with leveraging RAS policies in Active Directory, such as validating the caller ID, for example.

  • Auditing account management and logins is important, but it's even more important to monitor your audit logs and proactively respond to your auditing findings. You can search for relevant events in the event viewer in many ways, yet products such as Microsoft Operations Manager (MOM) and others can considerably ease this task for you by collecting those events from all Domain Controllers and/or other servers into an "enterprise log" and perform custom actions in response to those events.

At all times, keep in mind that physical access to your Domain Controllers is sacred - there are no real silver bullets against a service administrator with physical access to your console, no matter what operating system you're running on.

Related Links

For any feedback regarding the content of this column, please write to Microsoft TechNet. Please be aware that a response is not guaranteed.