The Tai Chi of Active Directory in the DMZ

When dealing with security I often think of Lao Tzu and the Tao Te Ching when he wrote, “The soft and the pliable will defeat the hard and strong.”

In an effort to provide a manageable form of Authentication in the DMZ for a Micro$oft centric organizations I was required to take a look at incorporating AD into a DMZ environment. A DMZ (DeMilitarized Zone) is a separate network that that is based off of an independent connection on your firewall. It isolates the internal network from the internet and controls what kind of traffic, if any, is allowed to pass on to the internal network.

By creating a DMZ, you limit the amount of damage an intruder can do to your network by containing it in the DMZ. Web servers and e-mail servers are typically the type that goes into the DMZ; a general rule is if a server needs to be exposed to the Internet it should be placed within the DMZ. With these servers being hosted on a separate network segment some form of authentication needs to be present. In Microsoft environments the choice is usually Active Directory.

So how do you take a more secure approach to this?

Since in Active Directory the forest is now the security boundary, the only way to have a fully secure implementation is to create a separate forest for the DMZ and then create a trust between the internal network forest and the DMZ forest. This trust would allow specific domain controllers in the secured network to communicate with only specific domain controllers in the DMZ. You would use IPSec to encrypt and secure the communication between the domain controllers, or you could set firewall rules for that as well.

Using this method you can allow your internal users to access resources in the DMZ, and you can create user accounts for consultants or administrators that can only use resources in the DMZ. This would negate the need to replicate your company’s Active Directory to a domain controller in the DMZ and, if the DMZ is compromised, you’re at risk only with the DMZ Forest.

Domain and local user accounts will be created by applying the Principal of Least Privilege. This will help in establishing what accounts require domain level administrative, or elevated privileges, and which accounts could be assigned lesser domain wide privileges while still maintaining sufficient local server privileges to perform daily administrative tasks.

An Organizational Unit (OU) will be created for every department under an Active Directory (AD) forest created for the DMZ.

A DMZ Admins (Tier3&4) group will be created and granted exclusive rights over the entire OU structure.

A Department Admins (Tier2)¹ group will be created and granted exclusive rights over their departmental OU structure. They cannot, however, manage other departmental OU structures within the directory. Department Admin accounts will be considered highly privileged and, as a result, the accounts are stored in a separate OU hierarchy and managed by the DMZ Admin service administrators. Department Admins are permitted to create most objects without restrictions within their OU structure (a notable exception is the creation of other organizational units), which carries the additional risk of creating objects that may not be manageable by lower tiers.

A WebAnalysts (Tier1) domain group will be created and delegated administrative access to the Web Services OU to provide the analysts with access to the servers. This allows the web analysts to control the web servers, while preventing the web analysts from accessing other DMZ components outside of their Departmental control. These will all have been placed in other OUs to control access to those services.

Web server analysts will be assigned Domain User privileges and Local server Administrator privileges on web servers. This allowed the web analysts to perform all functions pertaining to web server administration, while reducing domain structure exposure if an account was compromised.

The Default Domain Policy will be configured to enforce password age, length, history and complexity.

A Web Services (OU) will be created for each Department to allow application of Group Policy Object (GPOs) and security templates specific to the web servers.

A Web Services security template will be created and applied to the newly created Web Services OU to enforce password history, complexity and minimum age requirements.

Shared administrative accounts will in no way be allowed with in the DMZ structure, if they are currently utilized they will be removed and each web analyst will be assigned an individual account with permissions restricted to that Analyst’s administrative duty requirements. This allows for effective account access auditing policies to be put into place for security reviews.

Local Administrator accounts will be renamed and a 16 character complex password was applied to each account. Each server will have a different Local Administrator account name and password combination created to prevent an attacker from guessing another server’s Administrator account in the event one of the web servers is compromised.

A local WebUsers group will be created on each server. The local IUSR_%machinename% and IWAM_%machinename% accounts will be added to the new group. This group will be assigned log on locally rights as required for access to IIS resources.

The default Everyone group will be removed from the log on locally if it is currently in place. Access this server from the network, and logon as a Batch Job rights to prevent anonymous access to the servers will be assigned to the Local Administrators group and the Local System accounts.