email article printer friendly more resources

Secure Your Active Directory
Take advantage of new Windows Server 2003 features to ensure your Active Directory can't be subject to denial of service attacks.
by Danielle Ruest and Nelson Ruest

Posted October 16, 2003

For This Solution: Windows Server 2003, Windows Server 2003 Command-line Tools

Q:
We recently implemented a directory-aware application in our network. Ever since doing this, our directory seems sluggish and doesn't respond to requests quickly. Do you know what's causing this slowdown?

—Sarah, Boise, Idaho

A:
Danielle: This type of slowdown is often a common problem when applications need to look up information in the directory to function. Lookup performance depends on a lot of factors: the position of your domain controllers (DC), the location of the application, the speed of the network link between the application server and the closest DC, your server capacity, and so on. If you haven't already verified these factors, it would be a good idea to do so.

For example, server sizing for your application depends on the function of the application, the number of clients using it, and the number of automated processes it includes. The size you choose is also impacted by whether the application is distributed locally or regionally. If it's distributed regionally, ensure there's a local DC wherever the application is located. You might also want to consider using Active Directory Application Mode (ADAM). ADAM lets you create lightweight directory access protocol (LDAP) deposits that are independent of your network directory. This way, you can store information in an ADAM instance and perform lookups to the Active Directory (AD) only when it's absolutely necessary. At the least, you should make sure the conduit between your application server and the closest DC is as large as possible.

Nelson: Danielle brings up some good points. However, it's always difficult to give advice when we haven't actually seen the application's architecture, or your entire network architecture for that matter. But as Danielle explains, there are some items you can focus on right off the bat. From what you say, it sounds as though you're experiencing some form of denial of service (DoS). DoSs aren't always in the form of an outside attack. In some cases, your application server might be keeping your DCs so busy they can't respond to other requests.

You might want to consider checking the LDAP Query Policy in your Windows Server 2003 AD. This little-known AD feature controls how the directory treats LDAP queries. Policies are domain-centric; that is, they're specific to a domain only, so if you have more than one domain in your forest, you should assign a policy for each.

Windows Server includes a default LDAP Query Policy. This policy controls several parameters related to LDAP queries in AD—elements such as the maximum number of connections, the maximum amount of time a connection can remain idle before it's disconnected, the maximum number of active connections, and so on (see Resources). Assigning a policy protects the directory from being overloaded with LDAP queries. You can also modify the default policy or create your own. But, at the least, you should assign a policy to each domain, even if it's only the default policy.

To assign a policy, launch the Active Directories Sites and Services console. Locate a domain controller (Active Directory Sites and Services | Sites | sitename | Servers | DCname), move to the Details pane, then right-click on NTDS Settings and select Properties. On the General tab, select Default Query Policy from the Query Policy dropdown list. Click on OK to close the Properties dialog box (see Figure 1). Try this and see if it makes any difference in your performance levels.

Query policies are useful in internal networks, but they're essential in external-facing networks such as Internet or extranet networks running AD servers. They'll protect you from DoS attacks directed toward your directory.

Q:
We had a breakdown in our directory service recently because someone in our organization used a script to create accounts. Using the script wasn't bad in and of itself. The problem came from a typo in the script. Instead of adding 100 users, the script added 10,000 users, causing a significant amount of replication and overloading our systems. Is there any way to protect ourselves from such errors in the future?

—Philippe, San Luis Obispo, Calif.

A:
Danielle: Ouch! I guess your fellow employee learned to proofread scripts before running them the hard way. Fortunately, there is a way to prevent such errors and it doesn't rely on testing your script in a lab before running it in a production environment. Windows Server 2003 supports assigning quotas within the directory. These quotas control the number of objects a security principal can create within any given AD partition. Quotas affect every object in the directory. For example, if you set quotas to 1,000, no single user (or automated process using its own credentials) can own more than 1,000 other objects.