The Active Directory Architecture

[Previous] [Next]

As mentioned previously, Active Directory isn't, strictly speaking, an X.500 directory service, although like all existing directory services, it's derived from that standard. The sections that follow enumerate some of the characteristics of the Active Directory architecture.

The Directory System Agent

The DSA is the process that provides access to the physical store of directory information located on a hard disk. The DSA is part of the Local System Authority (LSA) subsystem in Windows 2000. Clients access the directory information using one of the following mechanisms:

  • LDAP clients connect to the DSA using the LDAP protocol. Active Directory supports LDAP v3, defined by RFC 2251; and LDAP v2, defined by RFC 1777. Windows 2000 Server clients and Windows 95/98 clients with the Active Directory client components installed use LDAP v3 to connect to the DSA.
  • Messaging Applications Programming Interface (MAPI) clients such as Microsoft Exchange connect to the DSA using the MAPI Remote Procedure Call (RPC) interface.
  • Windows clients that use Windows NT connect to the DSA using the SAM interface.
  • Active Directory DSAs connect to each other to perform replication using a proprietary RPC interface.

Naming Formats

Active Directory supports several name formats to accommodate both users and applications.

  • RFC 822 names, which are familiar to most users as Internet e-mail addresses, such as MaryPerez@scribes.com. Active Directory provides a "friendly name" in RFC 822 form for all objects. Thus, a user can use a friendly name both as an e-mail address and as the name used to log on.
  • HTTP URLs, which are familiar to most users who have Web browsers. A typical URL takes the form http://domain/path-to-page, where domain refers to a server running Active Directory services and path-to-page is the path through the Active Directory hierarchy to the object of interest. The URL for Mary Perez is http://AServer.scribes.Com/Division/Product/Research/MaryPerez.
  • LDAP names, which are more complicated than Internet names but are usually hidden within an application. LDAP names use the X.500 attributed naming convention. An LDAP URL specifies the server holding Active Directory services and the attributed name of the object—for example, ldap://AServer.scribes.com/CN=maryperez,OU=Research, OU=Product,OU=Division,O=scribes,C=US
  • UNC names, the universal naming convention used in Windows NT Server-based and Windows 2000 Server-based networks to refer to shared volumes, printers, and files. For example, \\scribes.com\Division.Product.Research.Volume\WordDocs\aprilreport.doc

The Data Model

The Active Directory data model is derived from the X.500 data model. The directory holds objects that represent various items, described by attributes. The universe of objects that can be stored in the directory is defined in the schema. For each object class, the schema defines what attributes an instance of the class must have, what additional attributes it may have, and what object class can be a parent of the current object class.

Schema Implementation

The Active Directory schema is implemented as a set of object class instances stored in the directory. This is very different from directories that have a schema but store it as a text file that is read at startup. Storing the schema in the directory has many advantages. For example, user applications can read it to discover what objects and properties are available.

The Security Model

Active Directory is part of the Windows 2000 trusted computing base and is a full participant in the Windows 2000 security infrastructure. The distributed security model is based on the MIT Kerberos authentication protocol (version 5). Kerberos authentication accommodates both public-key and private-key security, using the same ACL support model as the underlying Windows 2000 operating system. ACLs protect all objects in Active Directory. They determine who can see the object, what attributes each user can see, and what actions each user can perform on the object. If a user is not allowed to see an object or an attribute, the fact of its existence is never made known to that user.

An ACL, in turn, is made up of Access Control Entries (ACEs) stored with the object the ACL protects. In Windows NT and Windows 2000, an ACL is stored as a binary value, called a security descriptor. Each ACE contains a security identifier (SID), which identifies the principal (user or group) to which the ACE applies and provides information on what type of access the ACE grants or denies.

ACLs on directory objects contain ACEs that apply to the object as a whole and ACEs that apply to the individual attributes of the object. This allows an administrator to control not just which users can see an object, but what properties those users can see. For example, all users might be granted read access to the e-mail and telephone number attributes for all other users, but access to the security properties of users might be denied to all but members of a special security administrators group. Also, individual users might be granted write access to personal attributes such as the telephone and mailing addresses on their own user objects.

Active Directory is the store for the security system, including user accounts, groups, and domains. This store replaces the registry account database and is a trusted component within the LSA.

Delegation and Inheritance

Delegation is one of the most important security features of Active Directory. An administrator can authorize a user to perform a specified set of actions in some identified subtree of the directory. This is called delegated administration. Delegated administration allows very fine-grained control over who can do what and enables administrators to delegate authority without granting elevated privileges. This also eliminates the need for domain administrators with broad authority over large segments of the user population.

Administrators grant rights for specific operations on specific object classes by adding ACEs to the container's ACL. For example, to allow user Mary Perez to be an administrator of the Research organizational unit, you would add ACEs to the ACL on Research as follows:

 "Mary Perez";Grant ;Create, Modify, Delete;Object-Class User "Mary Perez";Grant ;Create, Modify, Delete;Object-Class Group "Mary Perez";Grant ;Write;Object-Class User; Attribute Password 

Now Mary Perez can create new users and groups in Research and set the passwords for existing users, but she can't create other object classes and she can't affect users in other containers (unless, of course, ACEs grant her that access in the other containers).

Inheritance allows a given ACE to be propagated from the container in which it was applied to all children of the container. Inheritance can be combined with delegation to grant administrative rights to a whole subtree of the directory in a single operation.

Naming Contexts and Partitions

Active Directory is made up of one or more naming contexts or partitions. A naming context is any contiguous subtree of the directory. Naming contexts are the units of partitioning. A single server always holds at least three naming contexts:

  • The schema
  • The configuration (replication topology and related data)
  • One or more user naming contexts (subtrees containing the actual objects in the directory)

The Global Catalog

The DN of an object includes enough information to locate a replica of the partition that holds the object. Many times, however, the user or application does not know the DN of the target object, or which partition might contain the object. The Global Catalog (GC) allows users and applications to find objects in an Active Directory domain tree, given one or more attributes of the target object.

The Global Catalog contains a partial replica of every naming context in the directory. It contains the schema and configuration naming contexts as well. This means that the GC holds a replica of every object in Active Directory, but with only a small number of their attributes. The attributes in the GC are those most frequently used in search operations (such as a user's first and last names, login name, and so on) and those required to find a full replica of the object. The GC allows users to quickly find objects of interest without knowing what domain holds them and without requiring a contiguous extended namespace in the enterprise.

The Global Catalog is built automatically by the Active Directory replication system. The replication topology for the GC is also generated automatically. The properties replicated into the GC include a base set defined by Microsoft. Administrators can specify additional properties to meet the needs of their installation. Specifics on the administration and deployment of Active Directory can be found in Chapters 11 and 12.



Microsoft Windows 2000 Server Administrator's Companion, Vol. 1
Microsoft Windows 2000 Server Administrators Companion (IT-Administrators Companion)
ISBN: 1572318198
EAN: 2147483647
Year: 2000
Pages: 366

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net