Securing Windows 2000 Active Directory (Part 1)

Protecting active directory’s integrity is paramount.  This article will focus on active directory security and will be written in two parts.  (If you would like to receive an email when Part 2 of this article is released, subscribe to the WindowSecurity.com Real-Time Article Updates from our Newsletter Subscriptions page). Active directory is the windows 2000 information repository that needs to be kept very secure.  Active directory has vital service dependencies such as DNS witch changes the scope of what needs to remain secure. I will focus on actions that you can take in order to safeguard the active directory service.

The following recommendations need to be tested in a lab environment before being employed in a production environment.  Please fully understand the consequences of implementing these recommendations and the impact they may have in your environment.

Restrict access

Only allow administrators that have a good understanding of active directory to have full administrative access to the active directory.  Have policies in place that force full system backups of the active directory and all the respective domain controllers. You should have a full backup that can be restored to the point before the change of configuration was applied. This ensures a checkpoint that takes you back before any change to the active directory or underlying services were made.  You can test changes to an active directory in a lab environment before going live on your production servers, and this approach is highly recommended.  If your organization is not large enough to have a lab environment you can have a test environment that does not have to comprise of more than three desktop machines running VMware.  Using this system you will be able to closely replicate your live environment.

Active directory DNS

Active directory uses DNS to locate services on other hosts that network users may rely on.  The failure of the DNS server will result in catastrophic consequences.  The reason for the DNS miscommunication will be caused by the active directory service when it tries to resolve a FQDN (fully qualified domain name) into an IP address when locating a network resource.  Furthermore DNS zones and DNS nodes are stored in active directory and it is very important that both active directory and DNS be treated with equivalent importance when defining your security strategy holistically.

Recommendations:

1.       Use dynamic zone updates so that propagation takes place within the multi-master replication scheme. This recommendation will avoid a single point of failure securing your DNS design and ensuring that new domain controllers will be aware of new DNS zones that may be added to the active directory.

On your DNS forward lookup zone right click on the forward lookup zone then click properties.

In the general tab click on the drop down box that is labeled allow dynamic updates and change the option to yes.  Now click ok to save your settings.

2.       Ensure that the secure DNS updates option is enabled this will encrypt all DNS transmission on the LAN. 

3.       After creating a DNS administrator group, only allow that group to administer DNS.

4.       Log all DNS events to make it easy to identify potential breaches.

On your DNS server Right click on the server then click on properties

Click on the logging tab then click the respective check boxes of the events you would like to log.

Ensure that the “everyone” group is not in the Pre-Windows 2000 Compatible Access group, which allows anonymous connections to the server. Rather create a users group and add your network users to that group.  This will prevent external people plugging onto your network and browsing your servers.  Warning: The “everyone” group can pose a serious threat to an organization if this group is not used correctly.  Rather that allowing this default to group to be used in your ACL’s (access control lists), remove the “everyone” group and explicitly add the specified user.

Directory Services Restore Mode

Protect the administrator password that is used to restore the Active Directory database from a backup. The database file that you will be protecting is ntds.dit.  NTFS provides a level of security that assists when securing this file.

Protect the built-in Administrator account.

The administrator account has full control by default, it can also take ownership of any object in the domain, membership of the domains administrators group should be controlled and should not belong to OUs that manage sub-domain elements of the directory tree.  It is a good idea to rename the administrator account.  Then create another account called administrator this account should then have the lowest permission on the network.  This strategy will ensure that if a hacker does get hold of your administrator account, they will have obtained the lowest form of privileges available on your network.

Organizational units

After installing active directory you should shift user and computer objects to respective OUs as a matter of priority.  This will ensure that the user and computer objects will have the permissions that they should be assigned. If you would not like to display some active directory objects you will be able to hide them from users also disable the list permission for normal users.  Note: an intruder can use the hide OU strategy against you.  Do a thorough inspection of all your OUs on a regular basis.

Remove OU object that appears without an icon, which you did not create.  Always label your OUs clearly, this will help you to identify if an OU has been created by an intruder.

To view hidden OUs:

right click on the server in the active directory users and computers MMC console and then check the Advanced features option the system OUs will then be displayed.

Hiding OUs from users:

1. Create an OU then right click on it and click properties.

2. Click on group policy then create a new group policy object then click properties.

3. Assign the respective permissions to the group policy object and if you would like to ensure that users can not see the OU you should remove the read permission. Then click ok to save settings.

Summary:

This article was written in two parts and is only complete when reading the following Part 2. (If you would like to receive an email when Part 2 of this article is released, subscribe to the WindowSecurity.com Real-Time Article Updates from our Newsletter subscriptions page). Knowing that your active directory has been locked away from the prying eyes of intruders is a comforting feeling.  Consistent monitoring of the AD is required to achieve this.  The following article will have vital information that will aid you in further securing your Active directory.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top