With Active Directory, Microsoft implemented a DNS-based namespace along with LDAP's hierarchical namespace. RFC 2247 is implemented in Active Directory to provide a close tie between LDAP and DNS. For more details, see the following section, Directory Namespace; for now, focus on the fact that the services supporting each Active Directory domain partition require a DNS zone of their own.

The solution Microsoft implemented, however, goes beyond being able to use DNS names in the LDAP namespace. Microsoft had to solve the problem of integrating a flat namespace (NT4 and Netbios) with a hierarchical one (AD and LDAP). To solve this problem, Microsoft defined the NT4 Netbios domains as DNS domains in Active Directory and defined each of these domains as directory partitions that are hosted separately. Each computer and user still has the older Netbios name that is unique only in the domain partition, but each one also has a new LDAP-based name (with DC components) that is unique across the entire Active Directory. This approach ensures that every computer and user entry has a unique, fully qualified name while maintaining backward compatibility with Windows NT4 network functionality. Because the Active Directory namespace is mapped so tightly to the DNS namespace, the names of entries are actually unique worldwide (at least on all net-works that are connected to the Internet). In the future, Microsoft could propose linking all the Active Directory namespaces together.

Active Directory also implements the IETF Internet draft that allows clients to locate an LDAP directory server using DNS SRV records. A client requests the LDAP SRV record for a given DNS namespace and receives the IP address of the LDAP directory server(s) that hold the directory for that namespace. Multiple directory servers can be listed in the DNS SRV record, which provides a round-robin resolution for client load-balancing. Microsoft also uses several special name conventions for the SRV records so clients can be configured to request the SRV record that corresponds to the closest directory server. Windows clients automatically request the closest directory server. This extension to the Internet-draft forms a powerful solution for localizing network traffic and minimizing problems associated with network latency. Active Directory is alone among LDAP servers in providing this level of service resolution functionality.

Finally, you can configure a Microsoft DNS server to use Active Directory to store and replicate the DNS records for that service. Such a configuration integrates management, simplifies network management, and provides fault tolerance for the DNS records via directory replication.

The Active Directory namespace consists of multiple naming contexts that are tied to a DNS zone. When you first create an Active Directory domain, you must pick a DNS zone for its name. This Active Directory domain is the root domain of what Microsoft calls a tree or domain tree. A single tree can also be called a forest (a forest contains one or more trees). DNS zones subordinate to the DNS zone of the root domain can become subordinate Active Directory domains in a tree. The root domain is not the same as the DNS root domain introduced in Chapter 2. A root domain is simply the first Windows domain in a tree. The first domain in a forest is called the forest root domain. Figure 7-1 shows a tree with a root domain and two child domains. A triangle represents a domain.

Figure 7-1. Active Directory domain tree

Active Directory also supports noncontiguous DNS zones. Each noncontiguous DNS zone would be a separate tree. These multiple trees can be connected in a single directory namespace (the forest). Each tree holds a contiguous DNS zone in which each Windows child domain is a DNS child domain of the Windows domain immediately above it. Figure 7-2 shows a forest with two noncontiguous domain trees.

Figure 7-2. Active Directory forest with two domain trees

Each domain consists of an independent domain directory that is hosted by directory servers called domain controllers. A domain can have as many domain controllers as desired. Each domain controller replicates the domain partition to the other controllers for that domain. Client computers can join the domain by accepting it as their primary source of authentication and authorization. These client computers are also loosely considered part of the domain, because by default they share the same security context. As a result, other security principals that reside in that domain partition may have some level of access to those client computers by default. From a directory standpoint, each of the client computers that joins the domain has an entry that represents it in the domain partition.

A forest has properties that are consistent across all the domain directories. For example, there can be only one schema in a forest, and it is replicated across all domain controllers. Additionally, configuration information for each of the pieces of Active Directory is replicated across all the domain controllers.

Figure 7-3 shows the logical directory namespace of the forest pictured in Figure 7-2 and how each domain relates to the partitions and overall directory namespace. Each partition is pictured as an ellipse with a tree structure to simulate the entries within that partition. Each of the partitions of this logical structure does not correspond to a single physical location. Figures 7-4 and 7-5 will illustrate how the namespace is distributed on the domain controllers.

Figure 7-3. Active Directory forest namespace

Figure 7-4. Domains distributed across sites

Figure 7-5. Active Directory naming contexts

Sites are how Active Directory addresses connectivity and bandwidth issues that might affect the operations of the directory. A site is a network with adequate connectivity and bandwidth, as arbitrarily decided by an administrator. The site architecture has no dependencies on the directory hierarchy, and it is external to LDAP namespace design. However, site configuration information is stored in the directory, and it is a factor in determining both replication flow and which directory server any particular client uses. Every computer that participates in AD, including the domain controllers, knows the site to which it belongs. This information in turn affects the client-server interaction; the client automatically prefers to interact with domain controllers in its own site.

The administrator can create multiple sites, which are independent of the directory namespace I just described. For example, a domain might have multiple sites, with a domain controller in each site to provide localized service to clients. In Figure 7-4, the root domain illustrates this configuration (DC stands for domain controller). Alternatively, a site might contain multiple domains so controllers for different domains can provide services to clients from each domain in that site. In Figure 7-4, the Mycompany Main Site demonstrates this configuration.

Domain controllers from the same domain in separate sites replicate the domain partition via a site bridge, according to the schedule and topology in the configuration partition. The configuration partition is conveniently stored local to each domain controller. Root domain controllers replicate the configuration and schema partitions between themselves and all other domain controllers using the site bridge when necessary. When a new domain controller is initially installed, it must be able to receive the existing configuration and schema partitions over the network. If this domain controller is across a low-bandwidth link, this requirement can be extraordinarily painful. Many companies circumvent this problem by building the new domain controller locally and shipping it to the remote site. Microsoft plans to fix this problem with .NET Server 2003 so the initial replication can be done via media.

Sites provide useful functionality in controlling network traffic across WAN links. Clients can simply interact with domain controllers that are local, and domain controllers can replicate at times scheduled to be least disruptive. This type of functionality is uncommon among LDAP server products, and it is one of the many significant benefits in choosing Active Directory.

Each domain directory holds three naming contexts, each of which is a replicated partition. One partition is the domain naming context. The domain naming context is where most of the action takes place. Most of the entries that clients need to interact with are held in this naming context. The domain naming context is replicated only to the domain controllers of that domain. Another partition is the configuration naming context, which is replicated to all the domain controllers in a forest. This context holds all the configuration information for Active Directory. The definitions of Active Directory architecture, replication schedules, and replication topology are held here. Finally, there is the schema naming context, which holds the schema definitions for Active Directory. The schema naming context is subordinate to the configuration naming context, but it has been implemented as a separate namespace. The schema partition is replicated to all the domain controllers in a forest. The following sections explore the purpose of each of the naming contexts; for the details of replication, see the section Replication later in the chapter.

The replication topology used by AD ensures that each domain controller has a copy of the rules, the overall architectural configuration, along with the local domain partition information. No other domain's partition information is replicated to a domain controller. For example, a domain controller for the Muppet HQ domain would host the three naming contexts or partitions shown in Figure 7-5. The naming context, dc=Muppet HQ,dc=root,dc=mycompany,dc=com, is the domain partition that is multimaster-replicated between all Muppet HQ domain controllers. The naming context, cn=Configuration,dc=root, dc=mycompany,dc=com, is the configuration partition. The naming context, cn=Schema,cn=Configuration,dc=root,dc=mycompany,dc=com, is the schema partition. The schema and configuration partitions are stored on every domain controller in every domain, and the information within them is the same throughout the forest. Also note that the container that would make these three naming contexts a contiguous namespace, dc=root,dc=mycompany,dc=com, is not hosted on this domain controller, but it is hosted elsewhere in the Active Directory forest.

Configuration Partition

The configuration partition holds the directory-wide settings

The configuration partition contains a variety of AD configuration information. The container itself, as you can see in Figure 7-6, has several attributes (among others) that are used to keep track of the last replicated update sequence number for various directory operations.

Figure 7-6. Configuration partition

The DisplaySpecifiers container subordinate to the configuration partition stores displaySpecifier entries for special user interface components built with the Component Object Model (COM). COM is a programming model used to simplify development of software. These entries allow object classes to be associated with graphical elements so they can be managed in a graphical user interface via the Microsoft Management Console (MMC). The MMC is a special new interface that all of Microsoft's administrative applications now use. The displaySpecifier object class, COM, and MMC are outside the scope of this book, but you can consult Microsoft's online MSDN documentation as well as Gil Kirkpatrick's Active Directory Programming. These resources should prove helpful for the other technical topics in this chapter too.

The ExtendedRights container subordinate to the configuration partition stores controlAccessRights entries that allow an administrator to create their own set(s) of access rights for object classes. This approach allows an administrator to extend the security functionality of a custom-designed object class in ways the AD designers didn't anticipate.

The LostAndFoundConfig container stores all entries received via replication that don't have an existing parent entry. The entries in this container are said to be orphaned because they have no parent. This situation can occur if a parent entry is created, but the replication of the parent doesn't occur prior to the creation of the child. It can also happen if a child is created prior to the replication of the deletion of the parent.

The Partitions container stores entries of object class crossRef. Each crossRef entry represents a naming context in the directory, an AD naming context external to the forest, or a naming context in an external directory. These entries represent the referrals present in the Active Directory topology.

Group policies are stored under the Services container

The Services container stores information about network services. Each service has a subordinate container. In this container the AD stores the administrative parameters, such as maximum page size, for the LDAP servers. A default forest-wide policy is stored at cn=Default Query Policy,cn=Query-Policies, cn=Directory Service,cn=Windows NT,cn=Services, CN=Configuration,DC=Mycompany,DC=com. The lDAPAdminLimits attribute on this entry stores these settings in a string format. Additional policies can be created and linked to specific domain controllers, so individual domain controllers have settings different from the default.

The Sites container stores information about the AD sites. Each site has its own subordinate container with objects for every domain controller in the site. These objects hold important information, such as whether the domain controller is a global catalog and links to administrative policy objects in the Services container. For information on global catalogs, see the following section, Global Catalog. The subordinate Inter-Site Transports container stores Link and Link Bridge entries that help AD know how and when to replicate between sites.

The WellKnownSecurityPrincipals container contains the built-in user accounts and groups that Windows uses to implement security for various types of service functionality. For example, the built-in group Authenticated Users is defined here and dynamically refers to every account in the forest. Instead of statically putting every account's unique identifier on this group's membership attribute, AD uses these special entries to apply dynamic membership at the time of access. The built-in groups and users here are the only dynamic ACL feature that AD offers, but there are a number of useful principles here (for more details, see the section titled Security later in this chapter).

Domain Partition

The domain partition holds the meat of the directory

The domain partition holds the most active information in AD. Everything that users will want to interact with is stored in a domain partition. The domain partition for any particular domain is held only on the domain controllers for that domain. Each domain controller can host only its own domain partition, not that of any other domain. This is a limitation built into Active Directory.

Figure 7-7 shows the default entries in the Muppet HQ domain partition. The Builtins container holds the default groups that a Windows domain supports. By default, all entries in this container are of the group object class.

Figure 7-7. Domain partition

By default, the Computers container holds the entries of object class computer that represent computers that join the domain. These computers implicitly trust the domain to provide authentication services. Computer entries are placed by default in this container, but you can move the computer entries anywhere within the domain partition. To apply group policies to the computers, move the entries into a container that is of the organizationalUnit (OU) object class. This rearrangement lets you automatically manage the computers. The Computers container doesn't permit automated management; consequently, it is usually abandoned.

The ForeignSecurityPrincipals container holds entries of object class foreignSecurityPrincipal. These entries represent accounts from outside the forest. The entries are used as proxy accounts for the external accounts.

The LostAndFound container serves the identical function as the LostAndFoundConfig container in the configuration partition.

The System container holds a variety of containers and entries of different object classes. These entries represent configuration settings critical to the internal workings of the domain. The entries that represent these settings under this container include other trusted domains, the holders of each of the Flexible Single Master Operation (FSMO) roles, group policies internal to this domain, DNS records (if MS DNS is used and integrated with AD), and several other network services.

The Users container by default holds the entries of the object class user as well as group entries. User or group entries don't have to reside here: you can move them to an OU or other container so you can have greater automated control in applying group policies to user entries. The Users container doesn't permit automated management; consequently, it is usually abandoned.

The Domain Controllers container holds the entries of object class computer for the domain controllers. This container is an OU. The domain controller entries are kept separate from those of other computers because you will want to configure them with more stringent security settings.

FSMO?

FSMO is generally pronounced “fizz-mo.” The Flexible Single Master Operation roles are special services that ensure the consistency of certain directory features. For example, the Infrastructure FSMO role is held by a single domain controller in the domain. This service checks the membership attribute of group entries in other domain partitions for all references to user account entries. The point is to ensure that the user accounts in the references still exist. If not, the value is removed to maintain consistency between partitions.

There are several other FSMO roles. The RID Master is a single domain controller in a domain to create unique identifiers for entries. The Schema Master is the single domain controller in the forest responsible for being the authoritative master for schema modifications. The Domain Naming Master is the single domain controller in a forest that controls which domain partitions are part of a forest (in other words, it controls the AD namespace). And the PDC Emulator Master is the single domain controller in a domain that provides backward compatibility with NT4 domain functionality.

I like the idea of separating the consistency-checking functionality from the core LDAP server. Separating these processes gives administrators a greater ability to troubleshoot problems as well as the ability to direct these loads onto servers that are more reliable.

There is another directory server role outside the FSMO roles for a domain controller called the global catalog (GC). A global catalog assists the AD by holding a copy of every entry in all the domain partitions in the forest. However, each of these entries is not complete; instead, each entry is only a subset of the most interesting attributes. Some attributes are marked by default to participate in the global catalog, and you can designate additional ones in each attribute's schema definition.

A global catalog server holds a read-only partial replica of every domain partition in AD. When a global catalog–enabled attribute is changed anywhere in AD, the change must be replicated to all the global catalog servers. Information about which domain controllers are global catalog servers is stored in the configuration partition. The global catalog service is separate from the normal directory operations that a domain controller handles. The global catalog is accessible only via port 3268; whereas all operations that interact with the other partitions, including the domain partition, are accessible via the default port 389. A client can't accidentally search the global catalog; it must instead choose to search the global catalog.

The global catalog performs several critical roles that integrate the distributed domain partitions in AD. Because it has a copy of all the entries in AD, it can be used as a beginning point to simplify search operations. With a GC, you can accomplish a search without a referral between domain partitions. A global catalog server provides another critical function during authentication; at least one global catalog server must be available for a user to authenticate. The global catalog locates the correct domain partition to verify user credentials, and it is required to form part of the authorization information that is placed in the authentication token when authentication is successful.

A global catalog search does not return subordinate referrals to attributes that aren't part of the GC replica. Instead, you would need to query the appropriate domain controller. However, an external referral outside the forest namespace is valid with a GC search.

Microsoft distributes several LDAP-enabled applications by default that can interact with the AD in a seamless fashion. However, all of these applications run only on the Windows platform. The Address Book application supports simple search functionality through the built-in Search command on the Start menu on most Windows systems. Microsoft provides numerous administrative applications that plug into the MMC interface to support specialized LDAP functionality for accomplishing administrative tasks. Microsoft also offers a complete graphical-based LDAP client with extensive support for security, controls, and options, with all the bells and whistles you might want.

In addition to integrated clients, Microsoft provides extensive LDAP programming support from the Windows platform. A complete LDAP API library is offered in all modern languages for Windows-based code. Microsoft has fully developed a service interface called Active Directory Services Interface (ADSI), which allows a Windows-based programmer to create abstracted code that will interact with LDAP directory implementations, including AD, NDS, and others.

Active Directory supports 16 LDAP controls by default. One of the default controls, called Statistics by one Microsoft source, is completely undocumented, but it will apparently be documented and supported with .NET Server 2003, the next version of AD, which will add three new controls to the default supported controls.

The AD LDAP controls are not well understood and therefore are underutilized by organizations that have implemented Active Directory, but these controls represent one of the key strengths of Active Directory compared to other vendors. For a description of the controls, including the three new ones, see Appendix E. In addition, you can find detailed information about programmatically using these controls at the Microsoft MSDN Web site: http://msdn.microsoft.com/library/en-us/netdir/ldap/extended_controls.asp.

With Active Directory, you can use the configuration partition to store information about directory-enabled services. Because the configuration partition is replicated across every domain controller, this service information is readily available to clients.

An excellent example of integration of a service with Active Directory is Microsoft Exchange 2000, which is an e-mail, calendar, and messaging service. Exchange 2000's predecessor, Exchange 5.5, offered limited LDAP functionality in an application-specific directory. Exchange 5.5's directory held both service configuration information and user information. Exchange 2000 stores all this information in Active Directory. The service configuration information in stored in the configuration partition at DN cn=Microsoft Exchange,cn=Services, cn=Configuration,dc=mydomain,dc=com. User-specific information, such as the location of a user's mailbox, is now simply an attribute of the user entry in the domain partition. A variety of user-specific messaging information like the instant message (IM) connected status is stored in Active Directory.

Exchange 2000 extends the user object class by modifying the schema with auxiliary classes. Exchange 2000 goes overboard in terms of schema modifications. It doubles the total number of both classes and attributes in AD, and it recreates many existing user attributes with little reason. This practice goes against the X.500 directory standard recommendations. In addition to the user schema modifications, Exchange 2000 defines several object classes to support the service configuration information stored in the configuration partition.

Exchange 2000 offers many impressive features that are worth further examination, but such a discussion is beyond the scope of this book.

AD uses a single class inheritance model in which only one class can be superior for any given object class. This inheritance model is common among directories despite the limitations it imposes. AD also makes use of structural schema rules. The attribute possSuperiors contains the names of the classes allowed to contain entries of a particular class. The attribute systemPossSuperiors serves the same purpose, except it cannot be modified. A series of attributes with the system prefix serve this same purpose of keeping some definitions constant so AD won't stop working as Microsoft designed. The allowedChildClasses attribute on an entry lists the names of all classes that an entry of this object class is allowed to contain.

An object class definition is stored in an entry of the classSchema object class. This entry has four attributes that define which attributes can be associated with an entry of that object class: mustContain, mayContain, systemMustContain, and systemMayContain. The values of these attributes are the mandatory and optional attributes for the object class, along with the required system attributes.

Microsoft chose to add operational attributes to the definition of the top class. So the AD top class has 69 optional attributes and 4 mandatory attributes. This nonstandard modification of the top class guarantees that every entry will have the operational attributes that AD requires for basic functionality, but the modification is not compliant with the X.500 standards. Microsoft also chose not to implement the abstract class alias. Alias entries represent an entry in one place but point to the real entry elsewhere in the directory. Microsoft downplays this lack of functionality, claiming it can be produced via other mechanisms; but I disagree, and lack of support severely limits interoperability with other vendors. Although you can add your own alias class, the LDAP-integrated client software from Microsoft is missing the alias support specified in the LDAP standard, thus violating the standard and creating a problematic situation.

User entries are the most important entry in AD. Several attributes of the user object class have unique values and are valid as an RDN: cn, userPrincipalName, canonicalName, sAMAccountName, objectGUID, and objectSID. The user-PrincipalName attribute is the fully qualified Kerberos account name, for example [email protected]. This is the account brian, in the Kerberos realm mycompany.com. Although the format is similar to an e-mail address, it is not the e-mail address of the person associated with the user entry. The objectGUID and objectSID attributes both are used to assign a unique identifier to the entry. These identifiers are assigned by the domain controller with the RID Master FSMO role. The value of objectSID plays an important part in AD security, as it is placed in ACLs associated with entries. The DN of an entry is not placed in an ACL to denote to whom to give access, but rather the value of the objectSID of an entry. The altSecurityIdentities attribute links the user account with an external Kerberos principal or external public key certificate. The userCertificate attribute stores an entry's public key certificate, issued by a certificate authority (CA) trusted by Active Directory. There are many other user attributes that hold various settings, but these are too numerous to detail here.

Entries of the computer object class are also prominent in AD. Information about the computers that have joined a Windows domain is stored in the corresponding computer entry. The computer object class is a subclass of the user object class, and several of the security-related user attributes are used to support basic functionality. Additionally, the fully qualified domain name (FQDN) is kept in the dNSHostName attribute. Information about the operating system of the computer is kept in the operatingSystem, operatingSystemHotfix, and operating-SystemVersion attributes. The servicePrincipalName attribute serves a critically important purpose. It denotes the Kerberos authentication service names supported by the computer. These names are required for a specific service on that computer to support Kerberos authentication.

Active Directory uses attributes in a standard way, with few surprises. By default, AD supports a lot of attribute definitions, which can be very useful.

One interesting feature AD implements is the idea of linked attributes. A linked attribute creates a connection between two entries in the directory. For example, my user entry in AD will have an attribute manager with a link to the RDN of my manager's user entry. My manager's user entry has a directReports attribute that links to the RDN of my user entry and possibly other entries. Adding a value to my manager's manager linked attribute automatically results in a modification to another entry's corresponding directReports linked attribute. AD makes use of linked attributes in several novel ways to ease administration of the directory. For example, user and group entries have a special link via the member and memberOf attributes respectively. If I add a user entry to the member attribute of a group entry, the group's entry is automatically added to the user's memberOf attribute. This functionality has obvious benefits in terms of managing the consistency of information. You can manually define your own linked attributes. For details on this functionality and guidelines for creating your own, see the relevant URL list in Appendix G.

In the section Naming Contexts and Partitions, I discussed the three types of partitions that Active Directory allows. The schema and configuration partitions are replicated across every domain controller in the forest. The many domain partitions are replicated across each domain controller in a domain, as well as partially replicated to each of the global catalog servers in the forest. The section Sites discussed the details of how domain controllers in one site can pass replication traffic to domain controllers in another site. But I didn't cover how Active Directory accomplishes replication within the same site, nor the features that are used to accomplish the replication.

Every domain controller can be written to, and it is considered an authoritative master for the partitions it holds. As a result, Active Directory must use a multimaster replication topology for these partitions. The multimaster model used employs a ring topology in which any domain controller is linked to two other domain controllers. Changes that are passed to one domain controller are also passed along to its partners. Redundant connections are automatically created for large rings so every domain controller is at most three hops from all the others. Figure 7-8 shows a possible replication topology of the entire AD forest namespace that was last pictured in Figure 7-3. In the figure, the squares represent domain controllers (DCs). The circles represent domain controllers that are also global catalog (GC) servers. Each domain controller is named by the first letter of the domain followed by a number. The root domain has two DCs. The Muppet domain also has two DCs. The Yourdomain domain has three DCs. The Sales domain has five DCs. The global catalog (GC) role is held by only two domain controllers: R1 and Y1. The number of DCs and GCs is arbitrarily chosen in this example; AD allows as many DCs per domain and GCs per forest as desired.

Figure 7-8. Active Directory replication topology

Only changes are ever replicated across the wire to minimize the network traffic between domain controllers. In addition, the mechanism used to replicate the changes ensures propagation dampening. Propagation dampening prevents a change from endlessly replicating around the ring, or to the same domain controller more than once. If the entry simply disappears, there isn't anything left for a replication partner to discover, which makes it difficult for deletions to replicate properly to all domain controllers. AD makes use of a tombstone to ensure that a deletion replicates properly. A tombstone is an entry that has been deleted. Users can no longer access it, but replication partners can do so to ensure that they know that the entry is no longer accessible. After a period of 60 days, the tombstones disappear automatically. These Active Directory features ensure that replication is efficient.

Imagine a change is made to a partition on a domain controller, or it has been passed changes from another domain controller. After five minutes, that domain controller contacts its replication partners about this change (and any that have been made in that five-minute period). It sends a change notification that there is new information to be replicated, and this notification includes a special tracking number called an update sequence number (USN). The USN is unique to each domain controller and tracks each change to that domain controller. The partners use this USN to track what changes they need to request. The partners then check their internal database of the changes they have already requested to make sure it isn't a USN that they have requested before. If it is new, the partner requests the change and updates its information. It is important to remember that replication takes time to propagate across all the domain controllers, so information in Active Directory should be considered loosely consistent at any one point in time.

Because changes can be written to the same entry on more than one domain controller, a collision during replication is possible. One factor that limits collisions is that AD tracks changes on an attribute level. For example, imagine someone changes the cn attribute of Brian Arkills's entry on one domain controller, and at the same time someone else changes the member attribute of Brian Arkills's entry on another domain controller. Because the changes are tracked at the attribute level, they will not collide during replication, and both will be replicated without problem. AD also uses other factors to limit collisions. Every attribute in AD has a corresponding version number that uniquely tracks how many times that attribute has been changed during its lifetime. This version number eliminates most collisions at the attribute level. Timestamps and the unique identifier number of the originating domain controller help to decide which change wins collisions on the same attribute of an entry. When a change is made to the same attribute of an entry on two different domain controllers, the attribute version number, a timestamp, and the domain controller's unique ID number are stored as part of the USN in case alternative resolution methods are needed. The latest version number wins first; but if the change is made before the replication cycle is complete, the different changes may have the same version number. Then the modification with the later timestamp wins the collision. System time between domain controllers is synchronized by default. If the timestamp is identical on the colliding changes, the change that originates from the domain controller with a lower ID number wins. This is a purely arbitrary factor, but it ensures that there is a clear winner in every collision. This combination of factors works well to reduce any negative effects from collisions.

Attributes that are frequently searched on, like objectClass, cn, or sn, are indexed by the directory. Indexing makes an attribute more readily available on the domain controller that hosts that domain partition. This design can decrease the overall time spent responding to queries. In addition to the default set, you can index other attributes by modifying their schema definitions. However, be aware that there are performance implications of selecting additional attributes for indexing. Indexing multivalued attributes or attributes with nonunique values can be costly in terms of storage space and time to write to disk and can also affect search operation performance. Perform a careful analysis to determine which attributes should be indexed to optimize search performance.

Microsoft Metadirectory Services is a metadirectory product similar to those mentioned in Chapter 5. MMS has connectors for most major directories and database products. You use a connector to import data into the MMS database. Once data has been imported, data manipulation and business rules can be applied to the data from multiple sources. MMS offers some standard data manipulation functionality in addition to supporting more customized scripting. After the data has been assimilated into a consistent form via manipulation and rules, MMS can push the data back to the source systems. The processed data can overwrite the original data in the source system or alternatively create a parallel instance of the updated data.

You can configure many Active Directory administrative parameters for the LDAP interface. All of the configurable parameters are stored in the Policies container in the configuration naming context, as noted in the earlier section Configuration Partition. You can modify all of these parameters with a variety of methods, although Microsoft usually prescribes a specific method that you can find in its knowledge base for each specific parameter.

Here are the parameters you can configure:

AD employs SASL-based authentication and supports Kerberos v5 as well as the preexisting NTLM authentication. The account used to authenticate to AD can be stored internally or externally to AD. If the account is stored externally, a proxy shadow account must be created internal to AD, with a mapping to the external Kerberos account or PKI certificate. Generally speaking, users don't need to specify the full DN of their account entry to bind but can just specify the RDN, along with the domain partition. The RDN of account entries is unique across the domain partition. But a fully qualified account name (in other words, a DN) is also accepted.

Active Directory also supports the use of smart cards as an authentication method. Smart cards look like credit cards, but they have a limited processor and memory. They store a user's private key and can do the encryption and decryption calculations required to support PKI. The smart card together with a personal identification number (PIN) can be used instead of the traditional username and password.

AD uses an ACL model for authorization. An ACL can be applied to a partition, container, entry, or attribute. The ability to specify an ACL at any level in the directory is useful. The attribute-level ACLs are particularly helpful when you want to give access to the entry, but not to private information in one or more attributes on that entry. The actual ACL definition is stored on the ntSecurityDescriptor attribute of the entry being secured. This attribute stores the access settings, owner information, and auditing configuration. The access settings are known as the discretionary access control list (DACL). These include access control entries (ACEs) that specify the identity, the level of access being granted or denied, and possibly the affected attributes of the entry. The level of access can be defined by permission sets or via 13 incremental permissions (see Table 7-1). In a similar fashion, if you are defining attribute-level access, you can use attribute sets (called extended rights) or individual attributes in ACLs. For more detail on incremental permissions and extended rights, see Kouti and Seitsonen's Inside Active Directory.

You can use only authentication identities, which loosely correspond to four groupings: users, computers, groups, and well-known security principals. The well-known security principal grouping corresponds to the dynamic entries discussed at the end of a prior section Configuration Partition. What exactly these entries represent is dynamically calculated at the time of access. Some of the more useful dynamic entries available are listed in Table 7-2. Several of these entries are useful in the context of ACL inheritance, which is described next.

A further ACL feature is support for inherited container permissions, so you can specify an ACL on a container to apply to all subordinate entries of that container. Inherited permissions are statically applied, not dynamically, which means that when a change is made, it is applied to the ntSecurityDescriptor attribute of each of the subordinate objects. Dynamic inheritance doesn't copy the ACL to the subordinate entries; instead, at the time of access, the ACL of the entry and all parent containers are checked. Perhaps Microsoft will change from static to dynamic inheritance in a future release.

In addition, a directory administrator can define the default ACL for an object class so all entries of that class automatically inherit a certain default ACL. This approach can be useful when your entire environment is different from the assumptions Microsoft made. The combination of all of these ACL features is powerful.

However, AD uses only standard ACLs for authorization factors. Client IP addresses, client encryption (along with algorithm and key strength), and dynamic authorization are not supported as authorization factors. You cannot—but should be able to—prohibit access either via a specific authentication method like cleartext or to specific IP addresses. Several other vendors do support these features. Dynamic authorization, like that which the Directory Server product offers, allows access control to be based on the value of the attributes of the requesting user. This type of access control may seem esoteric, but it can prove to be incredibly useful. For example, if you wanted to give access to all users who are members of a particular organizational unit (OU), dynamic access would permit you to do so directly, without explicitly creating a security group for this purpose. Microsoft is aware of this product weakness and of its customers' desire for this functionality. Enhancements and features are in the pipeline for future upgrades to Active Directory.

An overview of Active Directory security wouldn't be complete without mention of the public key support. The public key certificate integration is nothing short of impressive. Microsoft supplies certificate authority server software as a standard service in Windows 2000. These certificate authority servers can be configured to publish certificates that contain the public key for a user directly to AD. This integration eliminates much of the grueling administrative work that other certificate solutions demand. CRLs are also automatically published in AD. Certificates can even be automatically allocated to users or computers via policies. Certificate policies are flexible and can reduce the amount of manual intervention needed. Because manual intervention is the leading drawback to certificate technology, this is a significant feature. Certificate integration provides the basis for many other security features, like SSL support for the directory itself, the Windows Encrypted File System (EFS), and other applications.