Exploring Windows 2003 Security: More Active Directory Security Improvements

With this article, we conclude our discussion of Windows Server 2003 Active Directory related security improvements. This installment will cover the following:

• Storing custom data in Active Directory application partitions
• Storing custom volatile data in Active Directory
• Setting quotas on a number of newly created objects
• Mandatory SMB signing of communication with domain controllers
• Securing permissions for privileged groups with AdminSDHolder mechanism

Storing Custom Data in Active Directory – Application Partitions

We conclude our overview of Windows Server 2003 Active Directory related security improvements with a discussion of storing custom data, setting quotas for newly created objects, mandatory SMB signing, and using the AdminSDHolder mechanism to secure permissions for privileged groups.

Windows 2000 Active Directory replaced Windows NT 4.0 Security Account Manager Database, providing not only increased functionality and scalability, but also enhanced security through more-granular levels of permissions, sophisticated encryption, and two-way, resilient authentication protocol (with Kerberos). With the Windows 2003 platform, Microsoft takes full advantage of these features by allowing more flexibility in the way Active Directory information is partitioned and replicated.

Starting with Windows 2000, Active Directory has been divided into three “logical” partitions (physically residing in the NTDS.DIT file on each domain controller) — domain, configuration, and schema. The domain partitions store information specific to each domain (accessible primarily via Active Directory users and computers) and shared among all domain controllers in the same domain (partially replicated to all Global Catalogs in the forest).

The configuration partition contains forest-wide information (accessible primarily via Active Directory sites and services) and is shared among all domain controllers in the forest. The schema partition consists of definitions of all objects and their properties that can exist in the other two partitions; it is also shared forest-wide.

This mechanism for partitioning Active Directory data has been extended in Windows 2003 domains by the introduction of the application partition. Several features differentiate it from its three older counterparts:

• Most importantly, application partitions are intended for custom, Windows 2003 Active-Directory-aware applications. Although they are typically created by such applications, you can also experiment with application partitions using the NTDSUTIL command line utility. For example, you can create your custom application partition with the following steps:
  1. After typing NTDSUTIL at the command prompt, you will be presented with ntdsutil prompt. Start by typing domain management. (Typing ? lists available commands.)
  2. To proceed, you must establish a connection to one of existing domain controllers. This is done from the connection context, which is accessed by typing connection at the domain management prompt.
  3. Next, type in connect to server dc_name, where dc_name is the name of the domain controller to which you intend to connect. You can also provide alternate credentials if you do not want to use the same account you are logged on as.
  4. Once a connection is established, type quit to return to domain management context.
  5. Type create nc partition_name dc_name where partition_name and dc_name are, respectively, the names of the application partition and the domain controller hosting it. The application directory partition is expressed in the fully qualified notation. For example, an application partition called app-one.serverwatch.com would take the form dc=app-one,dc=serverwatch,dc=com.
  6. You can also create additional replicas of the partition created on another domain controller with the add nc partition_name dc_name command, substituting the name of this domain controller in place of dc_name.
  7. Note that removing replicas is equally straightforward with the remove nc partition_name dc_name command. Existing partitions (including non-application partitions) can be listed with the list command available from the domain management context of the NTDSUTIL tool.
• The scope of an application partition can be customized (i.e., the scope is not limited to entire forest or entire domain). This is concluded based on the process described above; creating application partitions with NTDSUTIL requires designating individual domain controllers that will store its replica. This lowers the amount of replication traffic, while still preserving fault tolerance and load balancing (with at least two replicas present). Replication is also minimized because application partitions are not replicated to Global Catalogs. Just as with other partitions, replication is managed automatically by the Knowledge Consistency Checker process.
• Active Directory can contain multiple instances of active directory partitions. The naming is arbitrary, although it does impact the location of the partition in the DNS namespace and security descriptor reference domain used to determine the domain whose administrative groups will have permissions to manage the partition. For example, an application partition called app-one.serverwatch.com references the security descriptor of the serverwatch.com domain (hence, its administrators, by default, will be able to manage it).
• Application partitions cannot contain security principals (users, computers, or groups).

Even though you cannot view the content of application partitions with ADSI Edit (which is typically used to gain read/write access to the other three types of partitions), you can use the LDP utility for this purpose. Both tools are part of the Windows Support Tools included with the installation CD.

Microsoft provides a couple of predefined application partitions intended for storing DNS Active Directory integrated zones. One of them, named DomainDnsZones, is created and replicated automatically across all domain-controller-based DNS servers in the same domain. The other, ForestDnsZones, exists and replicates across all domain-controller-based DNS servers in the forest. (This partition is used in Windows 2003 forest to store _msdcs Active Directory integrated zone.)

The two partitions correspond to two options available in the General tab of the zone Properties dialog box of Active Directory’s integrated DNS zone (in DNS Management MMC snap-in). In addition, one option, available on Windows 2000 domains, is to store the Active Directory integrated zone as part of domain partition (replicated to all domain controllers in a domain represented by the zone).

Storing Custom Volatile Data in Active Directory

Although the majority of the data stored in Active Directory is fairly static, Microsoft notes that it is beneficial, both from a uniformity and a security perspective, to provide the ability to store dynamic data as well. It therefore included this functionality in the Windows 2003 platform.

Support for this feature is based on industry standards (described in RFC 2589) and is based on use of the Time To Live (TTL) parameter to newly created dynamic objects. Such objects will automatically self-destruct after the TTL expires (which also implies that dynamic objects are not tombstoned, like standard static Active Directory objects). Dynamic objects are allowed only in domain and application partitions.

The creation of dynamic objects is handled through applications, so it remains the responsibility of programmers. From an administrative point of view, you can control TTL-related parameters with the already familiar NTDSUTIL command line utility. This time, you must access Configurable Settings by typing Configurable Settings at the command prompt. Next, establish a connection to either the target domain controller or a domain by typing Connections and using Connect to server or Connect to domain command. After typing Quit, you will be back at the Configurable settings prompt. You can type Show values to determine the current settings for two properties associated with the TTL of dynamic objects:

• DynamicObjectDefaultTTL (set by default to 86,400 seconds or 24 hours) determines the default TTL for each newly created dynamic object.
• DynamicObjectMinTTL (set by default to 900 seconds or 15 minutes) determines the minimum TTL required for each newly created dynamic object.

You can change these values with the Set property To value command, where property can be either DynamicObjectDefaultTTL or DynamicObjectMinTTL and value represents the length of the respective one represented in seconds.

New Object Quotas

Windows 2003 Active Directory introduces a feature that is supposed to prevent denial of service attacks and incidents where a number of administratively created objects might exceed the acceptable size of an Active Directory database. New Object Quotas are evaluated on a per-partition basis, and they can be assigned to a user directly or indirectly through membership in a group to which quotas were assigned (objects owned by this user are counted and compared with the quota limit before a new object gets created). The quota limits are stored on a per-partition basis in the NTDS Quotas container. They can be managed using new command line utilities (DSADD, DSMOD, and DSQUERY) as well as via ADSI scripting or programming.

For example, to set a limit of 10 on the number of objects user John.Doe from domain ServerWatch.com can create, the following command prompt is executed (on a single line):

DSADD quota -part dc=ServerWatch,dc=com -acct ServerWatchJohn.Doe 
-qlimit 10 -desc "John.Doe's 10 object limit"

which would result in the creation of an entry (and appropriate description) under the NTDS Quotas container of the domain partition of ServerWatch.com domain. Note that the limit takes into account the tombstoned objects as well, which means that newly deleted objects will count toward the quotas for the duration of the tombstoned interval (by default 60 days).

SMB Signing of Domain Controller Communication

By default, communication involving domain controllers uses SMB signing. This configuration is enforced via Domain Controllers Group Policy. Signing increases security by minimizing the possibility of man-in-the-middle attacks, but at the same rate prevents communication with Windows 9x and Windows NT 4.0, pre-SP3 clients, unless they have Active Directory client installed.

Securing Permissions for Protected Groups With AdminSDHolder Mechanism

Imagine a scenario where a privileged account is mistakenly placed in an organizational unit for which a non-privileged user was delegated elevated permissions. It is very likely you would want some built-in mechanism to prevent modifications to a privileged account based on permissions inherited from those assigned on the organizational unit level — right?

Fortunately, Microsoft provided such a mechanism in Windows 2000 and further enhances it in Windows 2003.

The solution applies to all members of so-called protected groups, which in the Windows 2000 domain includes Enterprise Admins, Schema Admins, Domain Admins, and Domain Local Administrators. In Windows 2003, the solution has been extended with the addition of Account Operators, Server Operators, Print Operators, Backup Operators, and Cert Publishers. Each of these groups is granted specific permissions on the
CN=AdminSDHolder,CN=System,DC=Domain,DC=com Active Directory object, where DC=Domain,DC=com represents the domain partition on which these groups reside. (You can check these permissions using ADSI Edit or Active Directory Users and Computers in Advanced View.) Permissions are then applied to each account that is a member of any of the protected groups, regardless of inheritance settings on a container where such accounts reside. If the permissions for some reason change, they are automatically reset (within 60-minute intervals) by a domain controller serving as PDC Emulator Operations Master. The PDC Emulator checks the Access Control List settings on each member of Protected Groups and, in case of mismatch, resets the permissions to match the ones set on the AdminSDHolder Active Directory object.

The next article in our “Exploring Windows Server 2003 Security” will cover the remaining authentication related enhancements in Windows server 2003, including Active Directory Application Mode, AKA “lightweight” Active Directory.