In-Depth

Q&A: Secure Your Active Directory

Use Windows Server 2003 features to prevent denial of service occurrences in Active Directory. Also discover the best way to implement a time management service.

• By Danielle Ruest and Nelson Ruest
• 11/01/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. 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.

This quota is made up of both active and tombstone objects—objects that have been removed from the directory, but not yet deleted. Active objects are given a weight of one each when calculating quotas, whereas tombstone objects can be weighted differently, depending on the value you set for them. This means that tombstone objects can have a lower value than active objects in quota calculations. You can create groups and assign them a different quota than the general quota.

For example, if you want print servers to own more than 1,000 print queues, you create a group, place the servers within it, and assign a different quota to it. You can assign quotas to any directory partition (configuration, domain, or application) except the schema partition; it doesn't support quotas. Because you perform quota assignments through the command line, I'll let Nelson tell you how to create and assign them in your directory.

Nelson: Thanks a lot, Danielle. I guess that means I write scripts and you proofread them in our office, right? Well, here goes. You assign quotas through the new directory service commands found in Windows Server 2003 (dsadd, dsquery, dsmove, dsget, and dsmod). Here are a couple of useful commands for query management:

dsadd quota partitionname -acct 
accountname -qlimit value

In these commands, partitionname is the distinguished name of the partition you want to add the quota to, accountname is the distinguished name of the account (it can be a user, group, computer, or InetOrgPerson object), and value is the amount of the quota you want to set. To assign default quotas, assign them to the Domain Users and Domain Computers groups. To identify the names of the partitions in your directory, use this command:

dsquery partition

To view a quota limit or verify the results of your previous command, type:

dsget quota domainroot -qlimit ">=499"

This lists all the accounts that have a limit greater than or equal to 499. To avoid mistakes such as the one in your question, Philippe, you should add quota entries to every partition (except the schema, of course). In most organizations, a limit of 500 is appropriate. This will also protect you from DoS attacks that use object creation to overload your DCs.

Q:
I know time synchronization is important for the Kerberos authentication protocol to work properly. What's the best way to implement a time-management service in a Windows Server 2003 network?

—Kim, Orlando, Fla.

A:
Danielle: You're right, Kim, enterprise networks are highly sensitive to time synchronization. That's why Windows Server 2003 includes a built-in time synchronization system. In a Windows Server 2003 forest, the Windows Time Service configures itself automatically, taking advantage of the time service available on domain controllers. A special domain controller, the PDC Emulator, serves as the authoritative source for time within a domain. In a forest, PDC Emulators synchronize with time sources in parent domains. Ultimately, only one server needs manual time synchronization. This is usually the first domain controller in the forest.

When you configure time in your forest, you need to decide whether you'll synchronize it with an external time source, use an internal time source, or let the forest synchronize on the source server, even though its time setting might not be accurate. Each choice has its own issues. We've included a list of accurate time sources provided by the U.S. Naval Observatory Master Clocks in Washington, D.C., and Colorado Springs, Colo. (see Table 1). Use the appropriate setting according to the time zone your source server belongs to. Not setting the time source will create ID 12 events in the System Event Log (see Figure 2). You probably have a few of these errors now if you haven't configured time in your forest yet.

Nelson: By default, Windows Server 2003 networks are configured to use time.windows.com as the Simple Network Time Protocol (SNTP) time source. If you wish to set a different time source server for the forest root PDC Emulator, you can use the w32tm command line tool. For example, the command to use to set an Eastern Time Zone clock with three source time servers would be:

w32tm /config /manualpeerlist:
"ntp2.usno.navy.mil, tick.usno.navy.mil, 
tock.usno.navy.mil" /update

This sets the forest root PDC Emulator to synchronize time with one of the three computer systems listed and updates the time service immediately. However, beware: To do this, you'll have to open UDP port 123—something that isn't usually open on firewalls by default—in your firewall to allow SNTP traffic. If the port isn't open, at least for requests that originate from your internal network, you will continue to get ID 12 events in the system log. Use Table 1 to identify an appropriate time source for your network. If you prefer, you can also use a non-military time source for your servers. To verify that the command was successful, type:

net time /querysntp

Danielle: Windows Server 2003 also includes Group Policy Objects (GPO) for time service configuration. If you want to use different settings than the default network settings, you can configure the entire enterprise with appropriate GPOs applied globally. This can be in the Default Domain Policy. You can find the GPO elements under Computer Configuration | Administrative Templates | System | Windows Time Service. The first setting lets you determine how time will be handled globally on your machines. The settings found under Time Providers enable both the NTP client and server, and they determine how the client will connect to the server for time updates. Note that there's no need to configure GPOs for time synchronization in most Windows networks because every computer joined to a domain obtains its time settings automatically from the PDC Emulator.