Microsoft

Lock IT Down: Secure Windows Server 2003 Active Directory

Make Active Directory more secure under Windows Server 2003


If I were to tell you that Windows NT Server 4.0 was a lot more secure than Windows 2000 Server, you would probably think that I had lost my mind. Sometimes, though, truth is stranger than fiction. In some ways, Windows NT Server was more secure than Windows 2000 Server. However, Microsoft learned from their mistakes and implemented a Windows NT-like security structure into Windows Server 2003's Active Directory. Let's discuss these security issues and learn some tips you can use to build a secure Active Directory (AD) environment.

Physical security is job 1
When attempting to secure AD, it's critical that you implement physical security first. If anyone you wouldn't trust with the Administrative password has physical access to a domain controller or to your DNS servers, you don't have a secure AD. Many administrative and disaster recovery tools exist that can easily double as hacker tools.

Given physical access to the server, it is easily possible for someone with minimal computer knowledge to hack the server in a matter of minutes. So don't even bother trying to secure AD until you've made sure that all of your servers are placed in a secure location.

Windows NT vs. Windows 2000
Don't get me wrong. In many areas, Windows 2000's security is far superior to that offered by Windows NT. However, there is a basic law of computing that states that the more complex a piece of software is, the greater the chance that it will contain a security hole or a major bug that can be exploited. As we all know, Windows 2000 is a lot more complex than Windows NT.

Perhaps the best example of simplicity and security going hand-in-hand involves the domain model implemented by each server operating system. In Windows NT, the domain was pretty much the only organizational structure that existed. A domain often contained all of the users, groups, and computers for an entire organization. If an organization was really big, they could create multiple domains and have the domains trust each other; but, each domain was an independent structure.

When Microsoft created Windows 2000, they realized that the Windows NT domain model just didn't scale well into larger organizations. So, they based the AD on a structure called a forest. A forest is basically a collection of domain trees. Within a forest, you can have many different domains and can even use parent and child domain trees. Just as was the case with Windows NT, each domain has its own Administrator. This is where the similarities end, though.

In Windows 2000, Microsoft decided they needed to make the domains more manageable. They created different levels of domain administration. For example, a member of the Domain Admins group could typically administer the current domain and any child domains beneath it. A member of the Enterprise Admins group had the ability to administer any domain within the entire forest. Herein lies the problem.

The fatal flaw in the Windows 2000 AD model is that every domain completely trusts every other domain within the forest. This causes a couple of problems. First, if security has not been applied properly, administrators can just add their accounts to the Enterprise Admins group to gain control over the entire forest. If the domain is a bit more secure, rogue administrators need only to tamper with the SID history and launch an elevation of privileges attack against the forest. By manipulating the SID history, administrators could give themselves Enterprise Admin status.

There are other inherent weaknesses in the Windows 2000 AD security model as well. As you probably know, each domain requires at least one domain controller. Likewise, each domain controller contains information relating not only to the domain, but also to the forest. Such information includes AD's schema and some basic configuration.

Now, imagine you had an administrator who wasn't being intentionally malicious, but who installed a malicious application or incorrectly modified an AD. If the change that the administrator made was to a forest-level AD component, the change would eventually be propagated to every domain controller in the entire forest, thus corrupting every single copy of AD and potentially crashing the entire network.

Let's compare this situation to Windows NT. Even if one domain trusts another domain, both domains include a copy of the Security Accounts Manager pertaining to their own domain only. In this way, rogue administrators can't make a change to the SAM in their domain and then use that change to corrupt other domains. Likewise, there is no all-powerful group within Windows NT that a rogue administrator could use to gain control over every domain in the entire organization.

Another nice thing about the way that Windows NT's trust relationships worked was that trust relationships could either be one-way or two-way, and they were never transitive in nature. This meant that if you had a Users domain and an Admin domain, you could either allow both domains to trust each other or you could configure the network so that the Users domain trusted the Admin domain, but not vice versa. It also meant that if Domain A trusted domain B and domain B trusted domain C, then domain A didn't trust domain C unless you told it to.

Windows Server 2003 security
You're probably wondering what all of this has to do with Windows Server 2003. I went into the long comparison between Windows NT and Windows 2000 because in Windows Server 2003, Microsoft incorporated the best of both worlds. And so, to properly secure your Windows Server 2003 network, you need to understand the strengths and weaknesses of both security models.

The biggest AD security weakness in Windows 2000 is that all domains within a forest are linked together by a common administrative structure, the forest itself. In Windows Server 2003, the forest structure still exists and works almost identically to the way it did in Windows 2000.

What is different about the forest structure in Windows Server 2003 than that of Windows 2000 Server is that Windows Server 2003 makes it relatively easy to establish trust relationships between forests. Inter-forest trusts were possible in Windows 2000; but, in Windows Server 2003, inter-forest trusts are actually useful. When a trust relationship exists between forests, an administrator can grant access to a resource in a user from a foreign forest in the same manner that they would if the user existed within the local forest.

Single forest vs. multiple forests
A single forest environment is ideal for most small to medium-sized companies. Single forest environments are easy to manage. But larger companies often need each office or each department to be able to have full administrative capabilities over its own users and computers. In such environments, there is often a high degree of distrust between these various groups. In a situation like this, interconnected forests are ideal because they give each group total autonomy.

At the same time, even though the administrative burden is distributed, such a model usually has a much higher administrative burden than a single forest environment, which results in higher administrative costs to the company as a whole. My point is that, in a Windows Server 2003 AD environment, there is a trade-off between cost and security.

Inter-forest trusts
Let's discuss the specifics behind using multiple forests as a mechanism for securing your organization's AD. First, each forest has its own AD; there is no common thread of any kind tying the forests together. So, it's possible to configure each forest to use a common DNS server. Assuming that the DNS server and backup DNS server are managed by someone trustworthy, DNS server consolidation is a great way to reduce cost and lessen the administrative burden. On the flip side, sharing a common DNS server can also be a single point of failure for the network if no backup DNS server is used.

There are some prerequisites you must meet before you can establish a trust relationship between forests in Windows Server 2003. Perhaps the most difficult of these is that any forest involved in the trust must be running at Windows Server 2003 forest functional level. Windows 2000 allowed you to run AD in either mixed mode or in native mode. The functional level in Windows Server 2003 is very similar to this. Setting a forest to Windows Server 2003 forest functional level requires every domain controller within the forest to be running Windows Server 2003.

Also, to create an inter-forest trust, you must be a member of the Enterprise Admins group. You must also have your DNS server configured so that it can resolve the names of domains and servers within the forest with which you're establishing the trust relationship.

Finally, you may recall from Windows 2000, every forest has a root domain and all other domains fall beneath the root. Windows Server 2003 can create an inter-forest trust only from the root domain, because inter-forest trusts are transitive at the domain level. This means that if you were to establish a trust between Forest A and Forest B, then every domain in Forest A will trust every domain in Forest B, and vice versa. Forest trusts are not transitive at the forest level, though.

For example, if Forest A trusts Forest B and Forest B trusts Forest C, Forest A will not trust Forest C unless you tell it to do so. As you can see, the transitive nature of inter-forest trusts makes them fairly powerful. If your forest has multiple domains, you don't want an administrator of some lower-level domain creating an inter-forest trust without your knowledge or consent. That would cause huge security problems. This is why you can only create an inter-forest trust at the forest root level.

Another interesting thing about creating trusts with Windows Server 2003 is that you don't necessarily have to create a full inter-forest trust. Suppose your business needs to establish a trust relationship with a supplier. You probably need only to establish a trust relationship with one of the supplier's domains. You probably aren't interested in the supplier's human resources or marketing domains. In such a case, you can create what's called an external trust.

An external trust is a trust relationship between domains, similar to the trust relationships that existed in Windows NT. An external trust can be established from any domain within your forest and links to a domain in a foreign forest. Aside from being able to establish the external trust at any domain level, there are other critical differences between an external trust and an inter-forest trust.

Unlike an inter-forest trust, an external trust is completely nontransitive, which means the trust applies only to the domains that the trust is assigned to. Other domains within the two forests don't acknowledge the trust relationship.

Whether you are forming an Inter-forest trust or an external trust, you have the option of creating a two-way trust, a one-way incoming trust, or a one-way outgoing trust. A two-way trust simply means that both domains trust each other. A one-way incoming trust means that users in the current domain or forest can be authenticated by the foreign domain or forest. Likewise, a one-way outgoing trust means that users in the foreign forest or domain can be authenticated by the local domain or forest.

Cross forest authentication
Windows Server 2003 inter-forest trusts support cross forest authentications. Suppose a user who normally logged into Forest A made a business trip to the company hosting Forest B. With forest authentication, users from Forest A could log into Forest B just as though they were logging into Forest A.

This might seem strange at first since neither the domain controllers nor the global catalog in Forest B would have any knowledge of a user from Forest B. When the user tries to log in, the computer checks the domain controller and then the global catalog for the user's account. Because the account is not found, the system implements a cross forest, name-matching function. This function compares the user's credentials with those found within all recognized namespaces (forests). The comparison is made via Kerberos and NTLM, so the process is secure.

Cross forest authorization
Another feature that's great about Windows Server 2003 is cross forest authorization. This allows you to assign permissions to users within both the local forest and trusted forests directly through an Access Control List (ACL). This comes in handy for both granting and denying permissions.

Suppose you were an administrator for your company's research and development department and that your job was to keep all of the files on your server confidential. The forest-level administrator for your company didn't know what he was doing, and he created an inter-forest trust with a competitor. If you wanted to keep users at the competitor's firm from being able to access your data, you could give those users an explicit deny at the root level of each of the servers in your domain.

As nice as this capability sounds, though, there is a catch. You must completely type in the names of users or groups from trusted forests. Enumeration and wild cards aren't supported. This means that you can't just implement a blanket policy that says don't let anyone from that other forest access any of my data. You could, however, get the names of each of the domains belonging to the other forest and deny access to the Everyone group belonging to each of those domains.

The best of both worlds
Even though Windows 2000 is newer than Windows NT, some of the improvements actually decreased security in your organization. Windows Server 2003 gives you added flexibility to restore that security. One way to achieve effective security within an organization is to implement multiple forests and create trust relationships between them. However, this isn't a process to be taken lightly, because there are many prerequisites and the process tends to increase costs and the administrative burden.

Editor's Picks