Every active directory administrator knows that the active directory schema is a partition which can not be rolled back once changed. We will talk about the active directory schema today as it is really an important and the last topic that every exchange administrator should know. I will cover up the remaining part related to DNS, forests and trust relations in active directory whenever they will be referred. So keep watching the new posts. You will enjoy the upcoming stuff I bet.
Active Directory Schema:
As a quick review, the object-oriented LDAP database that comprises Active Directory is built around a set of object classes and their associated attributes. Individual objects are instances of specific object classes. The schema defines the available object classes, their associated attributes, the data types and permitted ranges for those attributes, and the rules for arranging and managing objects within the Active Directory database.
Below is exactly what is held by Schema Partition:
Object Classes. Define the objects that can appear in Active Directory and their associated attributes.
Class Derivations. Define a method for building new object classes out of existing object classes.
Object Attributes. Define the available attributes. This includes extended attributes that govern actions that can be taken on object classes.
Structure Rules. Determine possible tree arrangements.
Syntax Rules. Determine the type of value an attribute is capable of storing.
Content Rules. Determine the attributes that can be associated with a given class.
Extensible schema. Additions can be made to the list of available classes and attributes.
Dynamic class assignments. Certain classes can be dynamically assigned to a specific object rather than an entire class of objects.
In a day to day administration life an administrator rarely get a chance to play around the schema. To understand the above concepts you can simply logon to http://msdn.microsoft.com/activedirectory . I have not covered up the above things in details to prevent the confusions so that it will make it easy to understand and off course remember too.
Before moving forward, let’s look at how Active Directory uniquely identifies objects. This information is crucial to understanding the more advanced Active Directory tools. Here is a brief attribute listing for a sample User object made using the LDIFDE utility. The unique identifiers are highlighted:
C:>ldifde -d cn=bgates, cn=users, dc=dotnet, dc=com -f con
Connecting to “DC01. Company.com”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries. . .
Writing out entries. dn: CN=bgates, CN=Users, DC=dotnet, DC=com
distinguishedName: CN=bgates, CN=Users, DC=dotnet, DC=com
whenCreated: 20020812134034. 0Z
whenChanged: 20020812134034. 0Z
userPrincipalName: bgates@dotnet. com
objectCategory: CN=Person, CN=Schema, CN=Configuration, DC=dotnet, DC=com
The Distinguished Name (DN) attribute of an object defines the LDAP path all the way to the root of the namespace; therefore, the DN must be unique. If you move an object to a different container in Active Directory, in reality, you are simply changing the DN.
Globally Unique Identifier (GUID):
In Exchange 5.0, Microsoft used the DN as the unique database row identifier for objects in the directory service store. This unfortunate engineering decision created a configuration problem for Exchange. When an object is moved, its DN changes, but a unique row identifier in a database cannot ever change. For this reason, in Exchange 5. 5 and earlier, mailbox recipients cannot be moved but must be freshly created and then linked to a User account in the SAM.
To avoid that problem in Active Directory, Microsoft used a different unique row identifier called the Globally Unique Identifier, or GUID. A GUID is created using an algorithm that virtually guarantees its uniqueness within a system.
Using a GUID permits you to move objects at will between containers in Active Directory without changing the unique row numbers for the objects, thereby maintaining internal referential integrity in the database. Keep this behavior in mind, because you’ll see it at work when we discuss the role of the Infrastructure Master in keeping track of group members from other domains.
Security Identifier (SID):
Three classes of Active Director objects can be placed on the access control lists (ACLs) used to protect security objects. These object classes are User, Computer, and Group. Together, they are termed security principals.
A security principal is assigned a unique number called a Security Identifier, or SID. This is exactly the same SID used by NT to identify users, groups, and computers. A SID for a security principal is made up of the SID of the security principal’s domain and a unique suffix, called a Relative ID, or RID. The series of RIDs for security principals that can be created by an administrator start at decimal 1000. For example, the first User account created following the creation of a domain would be given RID 1000. The next object, call it a group, would be RID 1001, and so forth.
The combination of a domain SID and a RID form a unique number within a domain and within a forest. The pool of RIDs is maintained by a specially designated Windows Server 2003 domain controller called a RID Master.
SAM Account Name
In an NT domain, every object in the SAM must have a unique name. This is true for computers, users, and groups. A unique name guarantees that the object will have a unique NetBIOS presence in the network as well as a one-to-one correspondence between the logon name (in the case of users and computers) and the SID used to control resource access.
The same restriction is left in place in Windows 2000 and Windows Server 2003. Every user, computer, and group in a domain must have a unique name. This attribute is called SAMAccountName, although you might hear it called logon name or flat name. When you create a new security principal, regardless of the container where you place the object, it must have a unique flat name in the domain.
User Principal Name (UPN) and Service Principal Name (SPN)
Just as unique flat names identify security principals in NetBIOS, User Principal Names (UPNs) identify security principals within the hierarchical LDAP namespace in Active Directory. A UPN takes the form User@Company.com. Unique UPNs ensure that users can log on with their UPN rather than the classic domainusername construct. The Global Catalog is used to “crack” the UPN into its constituent parts.
To assure uniqueness, when a security principal is created, the system refers to the Global Catalog to verify that the UPN has not already been used. If a GC server is not available, the system displays an error message prompting the administrator to wait until a GC is available so that uniqueness can be verified.
In a Parent/Child trust configuration, the UPN suffix of the root dom
ain is assigned to every security principal. In a Tree Root trust configuration, you must manually assign a common UPN suffix. This is done using the Properties window of the domain tree in the AD Domains and Trusts console.
Object Identifier (OID) In addition to the attributes that assure uniqueness of a particular object, Active Directory needs a way to assure that objects of the same class all come from the same Schema object. This is done by assigning a unique Object Identifier, or Object Identifier (OID) to each object in the Schema naming context. ISO defines the structure and distribution of OIDs in ISO/IEC 8824:1990, “Information Technology—Open Systems Interconnection—Specification of Abstract Syntax Notation One (ASN. 1).”
ASN.1 provides a mechanism for standards bodies in various countries to enumerate standard data items so that they do not conflict with one other. ASN.1 governs more than just directory services classes and attributes. For example, OIDs are used extensively in SNMP to build hierarchies of Management Information Base (MIB) numbers. They are also assigned to many items associated with the Internet. If you’re interested in the list of organizations that assign OID numbers and their hierarchy, it is available at ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers.
If you ever need to create a new attribute or object class in Active Directory, you must have a unique OID. There are a couple of ways to get one. The first is to apply to ANSI for your own numerical series. This costs a few thousand dollars and takes a while to process. The other is to use the OIDGEN utility from the Resource Kit. This will generate a Class and an Attribute OID out of Microsoft’s address space. The disadvantage to using OIDGEN is that the resultant number is very, very, very long. Here is an example:
Attribute Base OID:
1. 2. 840. 113556. 1. 4. 7000. 233. 180672. 443844. 62. 26102. 2020485. 1873967. 207938
Class Base OID:
1. 2. 840. 113556. 1. 5. 7000. 111. 180672. 443844. 62. 199519. 642990. 1996505. 1182366