The Schema
The schema is a description of the object classes (the various types of objects) and the attributes for those object classes. For each class of object, the schema defines the attributes that object class must have, the additional attributes it may have, and the object class that can be its parent. Every Active Directory object is an instance of an object class. Each attribute is defined only once and can be used in multiple classes. For example, the Description attribute is defined once but is used in many different classes.
The schema is stored in Active Directory. Schema definitions are themselves also stored as objects—Class Schema objects and Attribute Schema objects. This lets Active Directory manage class and attribute objects in the same way that it manages other directory objects.
Applications that create or modify Active Directory objects use the schema to determine what attributes the object must or might have, and what those attributes can look like in terms of data structures and syntax constraints.
Objects are either container objects or leaf objects (also called noncontainer objects). A container object stores other objects and a leaf object does not. For example, a folder is a container object for files, which are leaf objects.
Each class of objects in the Active Directory schema has attributes that ensure:
Unique identification of each object in a directory data store.
For security principals (users, computers, or groups), compatibility with security identifiers (SIDs) used in the Windows NT 4.0 operating system and earlier.
Compatibility with LDAP standards for directory object names.
Schema Attributes and Querying
Using the Active Directory Schema tool, you can mark an attribute as indexed. Doing so adds all instances of that attribute to the index, not just the instances that are members of a particular class. Indexing an attribute helps queries find objects that have that attribute more quickly
You can also include attributes in the global catalog. The global catalog contains a default set of attributes for every object in the forest, and you can add your choices to these. Both users and applications use the global catalog to locate objects throughout the forest. Include only those attributes that have the following characteristics:
Globally useful. The attribute should be one that is needed for locating objects (even if just for read access) that may occur anywhere in the forest.
Not volatile. The attribute should be unchanging or change rarely. Attributes in a global catalog are replicated to all other global catalogs in the forest. If the attribute changes often, significant replication traffic results.
Small. Attributes in a global catalog are replicated to every global catalog in the forest. The smaller the attribute, the lower the impact of that replication.
Schema Object Names
As stated earlier, classes and attributes are both schema objects. Any schema object can be referenced by each of the following types of names:
LDAP display name. The LDAP display name is globally unique for each schema object. The LDAP display name consists of one or more words combined, using initial caps for words after the first word. For example, mailAddress and machinePasswordChangeInterval are the LDAP display names for two schema attributes. Active Directory Schema and other Windows 2000 administrative tools display the LDAP display name of objects, and programmers and administrators use this name to reference the object programmatically. See next subsection for information about programmatically extending the schema; see the section "Lightweight Directory Access Protocol" for more information about LDAP.
Common name. The common name for schema objects is also globally unique. You specify the common name when creating a new object class or attribute in the schema—it is the relative distinguished name (RDN) of the object in the schema that represents the object class. For more about RDNs, see the section "LDAP DN and RDN Names." For example, the common names of the two attributes mentioned in the preceding paragraph are SMTP-Mail-Address and Machine-Password-Change-Interval.
Object identifier (OID). A schema object's identifier is a number issued by an issuing authority such as the International Organization for Standardization (ISO) and the American National Standards Institute (ANSI). For example, the OID for the SMTP-Mail-Address attribute is 1.2.840.113556.1.4.786. OIDs are guaranteed to be unique across all networks worldwide. Once you obtain a root OID from an issuing authority, you can use it to allocate additional OIDs. OIDs form a hierarchy. For example, Microsoft has been issued the root OID of 1.2.840.113556. Microsoft manages further branches from this root internally. One of the branches is used to allocate OIDs for Active Directory schema classes, and another for attributes. To continue the example, the OID in Active Directory is 1.2.840.113556.1.5.4, which identifies the Builtin Domain class and can be parsed as shown in Table 1.
Table 1 Object identifier
Object ID Number
Identifies
1
ISO ("root" authority) issued 1.2 to ANSI, then…
2
ANSI issued 1.2.840 to USA, then…
840
USA issued 1.2.840.113556 to Microsoft, then…
113556
Microsoft internally manages several object identifier branches under 1.2.840.113556 that include…
1
a branch called Active Directory that includes…
5
a branch called classes that includes…
4
a branch called Builtin Domain
For more information about OIDs and how to obtain them, see "For More Information" at the end of this document.
Extending the Schema
The Windows 2000 Server operating system provides a default set of object classes and attributes, which are sufficient for many organizations. Although you cannot delete schema objects, you can mark them as deactivated.
Experienced developers and network administrators can dynamically extend the schema by defining new classes and new attributes for existing classes. The recommended way to extend the Active Directory schema is programmatically, through the Active Directory Service Interfaces (ADSI). You can also use the LDAP Data Interchange Format (LDIFDE) utility. (For more about ADSI and LDIFDE, see the sections "Active Directory Service Interface" and "Active Directory and LDIFDE.")
For development and testing purposes, you can also view and modify the Active Directory schema with the Active Directory Schema tool.
When considering changing the schema, remember these key points:
Schema changes are global throughout the forest.
Schema extensions are not reversible (although you can modify some attributes).
Microsoft requires anyone extending the schema to adhere to the naming rules (discussed in the preceding subsection) for both the LDAP display name and the common name. Compliance is enforced by the Certified for Windows logo program7Microsoft Developer Network Web site for more information. .
All classes in the schema are derived from the special class Top. With the exception of Top, all classes are subclasses derived from another class. Attribute inheritance lets you build new classes from existing classes. The new subclass inherits the attributes of its superclass (parent class).
Extending the schema is an advanced operation. For detailed information about how to extend the schema programmatically, see the section "For More Information" at the end of this document.
Object Naming Conventions
Active Directory supports several formats for object names to accommodate the different forms a name can take, depending on the context in which it is being used (some of the names are in the form of numbers). The following subsections describe these types of naming conventions for Active Directory objects:
Security principal names.
Security identifiers (also called security IDs or SIDs).
LDAP-related names (including DNs, RDNs, URLs, and canonical names).
Object GUIDs.
Logon names (including UPN and SAM account names).
If your organization has several domains, it is possible to use the same user name or computer name in different domains. The security ID, GUID, LDAP distinguished name, and canonical name generated by Active Directory uniquely identify each user or computer in the directory. If the user or computer object is renamed or moved to a different domain, the security ID, LDAP relative distinguished name, distinguished name, and canonical name change, but the GUID generated by Active Directory does not change.
Security Principal Names
A security principal is a Windows 2000 object managed by Active Directory that is automatically assigned a security identifier (SID) for logon authentication and for access to resources. A security principal can be a user account, computer account, or a group, so a security principal name is a name that uniquely identifies a user, computer, or group within a single domain. A security principal object must be authenticated by a domain controller in the domain in which the security principal object is located, and it can be granted or denied access to network resources.
A security principal name is not unique across domains, but, for backward compatibility, it must be unique within its own domain. Security principal objects may be renamed, moved, or contained within a nested domain hierarchy.
The names of security principal objects must conform to the following guidelines:
The name cannot be identical to any other user, computer, or group name in the domain. It can contain up to 20 uppercase or lowercase characters except for the following: " / \ [ ] : ; | = , + * ? <>
A user name, computer name, or group name cannot consist solely of periods (.) or spaces.
Security IDs (SIDs)
A security identifier (SID) is a unique number created by the security subsystem of the Windows 2000 operating system, and assigned to security principal objects, that is, to user, group, and computer accounts. Every account on your network is issued a unique SID when that account is first created. Internal processes in the Windows 2000 operating system refer to an account's SID rather than to the account's user or group name.
Each Active Directory object is protected by access control entries (ACEs) that identify which users or groups can access that object. Each ACE contains the SID of each user or group who has permission to access that object and defines what level of access is allowed. For example, a user might have read-only access to certain files, read-and-write access to others, and no access to others.
If you create an account, delete it, and then create an account with the same user name, the new account does not have the rights or permissions previously granted to the old account, because the accounts have different SID numbers.
LDAP-related Names
Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service. In the Windows 2000 operating system, all access to Active Directory objects occurs through LDAP. LDAP defines what operations can be performed in order to query and modify information in a directory and how information in a directory can be securely accessed. Therefore, it is LDAP that you use to find or enumerate directory objects and to query or administer Active Directory. (For more about LDAP, see the section "Lightweight Directory Access Protocol.")
It is possible to query by LDAP distinguished name (which is itself an attribute of the object), but because they are difficult to remember, LDAP also supports querying by other attributes (for example, color to find color printers). This lets you find an object without having to know the distinguished name.
The following three subsections describe Active Directory-supported object-naming formats that are all based on the LDAP distinguished name:
LDAP DN and RDN names.
LDAP URLs.
LDAP-based canonical names.
LDAP DN and RDN Names
LDAP provides distinguished names (DNs) and relative distinguished names (RDNs) for objects8. Active Directory implements these LDAP naming conventions with the variations shown in Table 2.
Table 2 LDAP naming conventions and their Active Directory counterparts
LDAP DNRDN Naming Convention
Corresponding Active Directory Naming Convention
cn=common name
cn=common name
ou=organizational unit
ou=organizational unit
o=organization
dc=domain component
c=country
(not supported)
Note: cn=, ou=, etc are attribute types. The attribute type used to describe an object's RDN is called the naming attribute. The Active Directory naming attributes, shown on the right above, are for the following Active Directory object classes:
cn is used for the user object class
ou is used for the organizational unit (OU) object class
dc is used for the domainDns object class
Every Active Directory object has an LDAP DN. Objects are located within Active Directory domains according to a hierarchical path, which includes the labels of the Active Directory domain name and each level of container objects. The full path to the object is defined by the DN. The name of the object itself is defined by the RDN. The RDN is that segment of an object's DN that is an attribute of the object itself.
By using the full path to an object, including the object name and all parent objects to the root of the domain, the DN identifies a unique object within the domain hierarchy. Each RDN is stored in the Active Directory database and contains a reference to its parent. During an LDAP operation, the entire DN is constructed by following the references to the root. In a complete LDAP DN, the RDN of the object to be identified appears at the left with the name of the leaf, and it ends at the right with the name of the root, as shown in this example:
cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName.dc=com
The RDN of the JDoe user object is cn=JDoe, the RDN of Widget (the parent object of JDoe) is ou=Widgets, and so on.
Active Directory tools do not display the LDAP abbreviations for the naming attributes (dc=, ou=, or cn=). These abbreviations are shown only to illustrate how LDAP recognizes the portions of the DN. Most Active Directory tools display object names in canonical form (described later). The Windows 2000 operating system uses the DN to let an LDAP client retrieve an object's information from the directory, but no Windows 2000 user interface requires you to enter DNs. The explicit use of DNs, RDNs, and naming attributes is required only when you are writing LDAP-compliant programs or scripts.
LDAP URL Names
Active Directory supports access using the LDAP protocol from any LDAP-enabled client. RFC 1959 describes a format for an LDAP Uniform Resource Locator (URL) that lets Internet clients have direct access to the LDAP protocol. LDAP URLs are also used in scripting. An LDAP URL begins with the prefix "LDAP," and then it names the server holding Active Directory services followed by the attributed name of the object (the distinguished name). For example:
LDAP://server1.USRegion.OrgName.com/cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName,dc=com
LDAP-based Active Directory Canonical Names
By default, Active Directory administrative tools display object names using the canonical name format, which lists the RDNs from the root downward and without the RFC 1779 naming attribute descriptors (dc=, ou=, or cn=). The canonical name uses the DNS domain name format, that is, the constituents of the domain labels section of the name are separated by periods—USRegion.OrgName.com. Table 3 contrasts the LDAP DN with the same name in canonical name format.
Table 3 LDAP DN format contrasted with the canonical name format
Same Name in Two Formats
LDAP DN Name:
cn=JDoe,ou=Widgets,ou=Manufacturing,dc=USRegion,dcOrgName.dc=com
Canonical Name:
USRegion.OrgName.com/Manufacturing/Widgets/JDoe
Object GUIDs
In addition to its LDAP DN, every object in Active Directory has a globally unique identifier (GUID), a 128-bit number assigned by the Directory System Agent when the object is created. The GUID, which cannot be altered or removed, is stored in an attribute, objectGUID, which is a required attribute for every object. Unlike a DN or RDN, which can be changed, the GUID never changes.
When storing a reference to an Active Directory object in an external store (for example, a Microsoft SQL Server™ database), the objectGUID value should be used.
Logon Names: UPN and SAM Account Names
As described earlier, security principals are objects to which Windows-based security is applied for both logon authentication and resource access authorization. Users are one type of security principal. In the Windows 2000 operating system, user security principals require a unique logon name to gain access to a domain and its resources. The next two subsections describe the two types of logon names—UPN and SAM account names.
User Principal Name
In Active Directory, each user account has a user principal name (UPN) in the format
The UPN's three parts are the UPN prefix (user logon name), the @ character, and the UPN suffix (usually, a domain name). The default UPN suffix for a user account is the DNS name of the Active Directory domain where the user account is located9. For example, the UPN for user John Doe, who has a user account in the OrgName.com domain (if OrgName.com is the only domain in the tree), is JDoe@OrgName.com.The UPN is an attribute (userPrincipalName) of the security principal object. If a user object's userPrincipalName attribute has no value, the user object has a default UPN of userName@DnsDomainName.
If your organization has many domains forming a deep domain tree, organized by department and region, default UPN names can become unwieldy. For example, the default UPN for a user might be sales.westcoast.microsoft.com. The logon name for a user in that domain is user@sales.westcoast.microsoft.com. Instead of accepting the default DNS domain name as the UPN suffix, you can simplify both administration and user logon processes by providing a single UPN suffix for all users. (The UPN suffix is used only within the Windows 2000 domain and is not required to be a valid DNS domain name.) You can choose to use your e-mail domain name as the UPN suffix—userName@companyName.com. This gives the user in the example the UPN name of user@microsoft.com.
For a UPN–based logon, a global catalog may be necessary, depending on the user logging on, and the domain membership of the user's computer. A global catalog is needed if the user logs on with a non-default UPN and the user's machine account is in a different domain than the user's user account. That is, if, instead of accepting the default DNS domain name as the UPN suffix (as in the example just given, user@sales.westcoast.microsoft.com), you provide a single UPN suffix for all users (so that the user then becomes simply user@ microsoft.com), a global catalog is required for logon.
You use the Active Directory Domains and Trusts tool to manage UPN suffixes for a domain. UPNs are assigned at the time a user is created. If you have created additional suffixes for the domain, you can select from the list of available suffixes when you create the user or group account. The suffixes appear in the list in the following order:
Alternate suffixes (if any; last one created appears first).
Root domain.
The current domain.
SAM Account Name
A Security Account Manager (SAM) account name is required for compatibility with Windows NT 3.x and Windows NT 4.0 domains. The Windows 2000 user interface refers to the SAM account name as the "User logon name (pre-Windows 2000)."
SAM account names are sometimes referred to as flat names because—unlike DNS names—SAM account names do not use hierarchical naming. Because SAM names are flat, each one must be unique in the domain.
Object Publishing
Publishing is the act of creating objects in the directory that either directly contain the information you want to make available or provide a reference to it. For example, a user object contains useful information about users, such as their telephone numbers and e-mail addresses, and a volume object contains a reference to a shared file system volume.
Here are two examples—publishing file and print objects in Active Directory:
Share publishing. You can publish a shared folder as a volume object (also called a shared folder object) in Active Directory, using the Active Directory Users and Groups snap-in. This means that users can now easily and quickly query Active Directory for that shared folder.
Printer publishing. In a Windows 2000 domain, the easiest way to manage, locate, and connect to printers is through Active Directory. By default10, when you add a printer using the Add Printer wizard and elect to share the printer, Windows 2000 Server publishes it in the domain as an object in Active Directory. Publishing (listing) printers in Active Directory lets users locate the most convenient printer. Users can now easily query Active Directory for any of these printers, searching by printer attributes such as type (PostScript, color, legal-sized paper, and so on) and location. When a printer is removed from the server, it is unpublished by the server.
You can also publish non-Windows 2000-based printers (that is, printers on non-Windows 2000-based print servers) in Active Directory. To do so, use the Active Directory Users and Computers tool to enter the universal naming convention (UNC) path for the printer. Alternatively, use the Pubprn.vbs script provided in the System32 folder. The Group Policy Downlevel Printer Pruning determines how the pruning service (automatic removal of printers) handles printers on non-Windows 2000-based print servers when a printer is not available.
When to Publish
You should publish information in Active Directory when it is useful or interesting to a large part of the user community and when it needs to be highly accessible.
Information published in the Active Directory has two major characteristics:
Relatively static. Publish only information that changes infrequently. Telephone numbers and e-mail addresses are examples of relatively static information suitable for publishing. The user's currently selected e-mail message is an example of highly volatile information.
Structured. Publish information that is structured and can be represented as a set of discrete attributes. A user's business address is an example of structured information suitable for publishing. An audio clip of the user's voice is an example of unstructured information better suited to the file system.
Operational information used by applications is an excellent candidate for publishing in Active Directory. This includes global configuration information that applies to all instances of a given application. For example, a relational database product could store the default configuration for database servers as an object in Active Directory. New installations of that product can then collect the default configuration from the object, simplifying the installation process and enhancing the consistency of installations in an enterprise.
Applications can also publish their connection points in Active Directory. Connection points are used for a client/server rendezvous. Active Directory defines an architecture for integrated service administration using Service Administration Point objects and provides standard connection points for Remote Procedure Call (RPC), Winsock, and Component Object Model (COM)-based applications. Applications that do not use the RPC or Winsock interfaces for publishing their connection points can explicitly publish Service Connection Point objects in Active Directory.
Application data can also be published in the directory using application-specific objects. Application-specific data should meet the criteria discussed above. Data should be globally interesting, relatively non-volatile, and structured.
How to Publish
The means of publishing information varies according to the application or service:
Remote Procedure Call (RPC). RPC applications use the RpcNs* family of APIs to publish their connection points in the directory and to query for the connection points of services that have published theirs.
Windows Sockets. Windows Sockets applications use the Registration and Resolution family of APIs available in Winsock 2.0 to publish their connection points and query for the connection points of services that have published theirs.
Distributed Component Object Model (DCOM). DCOM services publish their connection points using the DCOM Class Store, which resides in Active Directory. DCOM is the Microsoft Component Object Model (COM) specification that defines how components communicate over Windows-based networks. Use the DCOM Configuration tool to integrate client/server applications across multiple computers. DCOM can also be used to integrate robust Web browser applications.
