Describing the global catalog feature of Active Directory
In the second part of this four-part series, I will examine the Global Catalog, which enables users to find on the network anything to which they have been granted access. I will also describe how Active Directory is replicated across the servers on the network and how partitioning can be used to spread the Active Directory load across servers. Finally, I will briefly discuss editing schemas.
Despite the name, Global Catalog is not a resource in whichyou can find any piece of information on the planet.In this context, global refers to an organization’s network within Active Directory.
The Global Catalog is a service within Windows 2000 Server that allows users to find any objects to which they have been granted access. This functionality is similar to, but infinitely more powerful than, that of the Find Computer facility included in previous versions of Windows. With Global Catalog, users can search for any object within Active Directory, such as servers, printers, users, and applications.
The Global Catalog consists of an index stored on Active Directory servers. It contains the names of all objects in the Active Directory server, regardless of how the server has been partitioned. The Global Catalog also contains a handful of searchable attributes for each object. For example, the Global Catalog would store the distinguished names, first names, and last names of all users, allowing someone to search for anyone named Richard and find the distinguished name of the user. The Global Catalog is a subset of Active Directory, and it stores only the attributes that users tend to search on. Microsoft provides useful defaults, and administrators can specify other attributes to be searchable by using the Active Directory schema.For example, usingthe Global Catalogsearchfacility, a user can findall color printers in the building that have the capability to print double-sided documents(provided, of course, that Active Directory was configured to contain these objects and attributes).
This feature is especially important because of the complexity of LDAP names that are used within Active Directory to identify objects. Previous versions of Windows relied on 15-character NetBIOS computer names, which users could easily remember (depending on the naming scheme used, of course). Although it is possible, not many (normal) people would be able to recall LDAP names, such as the following:
Because users can easily search for objectsusing a nice, friendly GUI, remembering names—even short, memorable ones—is much less important.
To index or not to index
If you’ve been involved with database administration, you know that some types of information are more useful to index than others. You should index attributes that users will search for often, but, as always, that is not the whole story. Indexes take up space, so it is not efficient to index everything. Indexes also slow down updates and inserts—if an indexed attribute is modified, the index must be modified as well. Indexing works better when the data being stored varies from user to user. Therefore, never index true or false attributes or any attribute with less than five possible values. Names are an excellent attribute to index since they are almost always unique for each user. Finally, don’t index attributes that aren’t usually filled in. If few users enter a value for their middle name, then indexing that attribute is a waste of time and space. Keep in mind that a search will provide a selection of items that match the search criteria, so there is no need to get too specific.
New objects created in Active Directory are assigned a unique number called a GUID (Globally Unique Identifier). The GUID is a 128-bit identifier. It’s useful because it stays the same for any given object, regardless of where the object is moved. Applications that reference objects in Active Directory can record the GUIDs for objects and use the Global Catalog to find the objects even after they’re moved.
To keep the two abbreviations GUI and GUID separated in your mind, try saying GUID as GU-ID (goo- i.d.)
Replication, Jim, but not as we know it
Windows 2000 networks rely heavily on the services of Active Directory. This reliance means that Active Directory must be available on multiple servers so that if a single server fails, clients can contact a server with duplicate services and information (assuming one exists). Unlike the Windows NT domain databases used with previous versions of Windows NT, Windows 2000 lets you send database updates to any of the Active Directory servers. While this complicates the replication process, it eliminates the possibility that a single domain controller failure would stop updates to the databases. It also addresses the problem of the high load replication placed on Windows NT 4.0 primary domain controllers.
Windows 2000 Server includes a replication component within the suite of Active Directory services that makes this a simple task for administrators. Simply adding domain controllers to an Active Directory domain is sufficient to begin the replication process.
One of the most complex parts of making redundant servers work properly is replicating the information and ensuring that all servers have the most up-to-date content. Active Directory uses multimaster replication, which means that updates can occur on any Active Directory server, and each server keeps track of which updates it has received from which servers, intelligently requesting updates as necessary. (Any administrator who has been involved with Lotus Notes will be familiar with this concept.)
How Active Directory replication works
Active Directory replication will seem logical if you are already familiar with how replication works in Windows NT 4.0 domains. Each update is assigned its own 64-bit unique sequence number (USN) from a counter that is incremented whenever a change is made. These updates are system-specific, so every Active Directory server maintains a separate counter.
When a server replicates an update to other Active Directory servers, it sends the USN along with the change. Each server maintains an internal list of replication partners and the highest USN received from them. The server receiving the update requests only those changes with USNs higher than those previously received. This method has the added benefit of stopping updates from propagating endlessly between multiple Active Directory servers.
An obvious problem inherent in this multimaster replication method is that updates to a single object can occur in multiple places at the same time. For example, if an administrator in Boston changes a user’s name from “Curt” to “Kurt” and an administrator in Chicago simultaneously changes that same user’s name from “Curt” to “Kirk,” a replication collision will occur. There are two problems to deal with when a collision occurs: detecting the collision and resolving the collision.
Active Directory stores property version numbers to allow detection of these replication collisions. Property version numbers are specific to each property of every object within Active Directory and are updated every time the property is modified. These numbers are propagated through Active Directory along with the change. Thus, when a server receives two different updates to the same property with the same property version number, it can conclude that a replication collision has occurred.
Active Directory resolves replication collisions by applying the update with the later timestamp. As the server that initiated the change creates the timestamp, it is very important to keep the system time synchronized between Windows 2000 servers.
Use the built-in distributed time synchronization service to keep all servers working together!
Large networks can contain hundreds of thousands of objects. Windows NT required multiple domains to allow that many objects to be manageable. Administrators often divided users and resources into separate domains and created a trust between the domains. The structure of the databases simply did not allow them to grow to hundreds of thousands of objects. These size limitations are less a factor in Active Directory domains. Supporting a very large Active Directory, however, could be an incredible burden to any single domain controller.
Active Directories can be partitioned to lessen this load. Partitioning allows different domaincontrollers to manage different sections of the database, reducing the load on any individual server. The clients can use resources located within different Active Directory partitions transparently. Therefore, administrators can manage massive Active Directory domains without requiring domain controllers to handle the entire database.
Remember: A schema is a set of attributes used to describe a particular object class in Active Directory. Schemas are important because different types of information must be tracked for different object classes. For example, the Users object class needs attributes for first name, last name, phone number, e-mail address, and mailing address. The Printer object class will have different attributes: Users will want to know how fast a printer is and whether it can duplex or print in color. These attributes can be viewed and edited using the Active Directory Schema MMC snap-in. The Active Directory Schema does not have an icon within the Start menu; you must launch the MMC interface and add the snap-in named Active Directory Schema.
Active Directory provides default object classes with a logical set of attributes that will fit most organizations' needs. However, organizations will need to track additional information about particular object classes. For example, if your company provides employees with security badges, it would be useful for you to track the ID number of the badge in the User object class. To do so, you would first create an attribute called SecurityID, and then make the new attribute optional for the Users class.
The schema is stored within Active Directory just like other objects. Therefore, the schema inherits the ability to be automatically replicated throughout a domain. It also benefits from the security features of Active Directory and allows administrators to delegate authority over the schema to different users and groups. By changing the ACLs on a schema object, an administrator can allow any user to add or modify attributes for an object class.
Cannot edit the schema
By default, Active Directory servers do not allow you to edit the schema. To remove this restriction, you must add a REG_DWORD value to the registry named Schema Update Allowed and set it to 1. This value should be added to the following registry key:
\Hkey Local Machine\System\CurrentControlSet\Services\NTDS\Parameters
New attributes have several properties that must be set. The user creating a new attribute must define a name for the attribute (such as Security Badge ID #), the type of data to be stored (such as a string or a number), and the range limits (such as string length). A unique Object Identifier (OID) must also be provided. New attributes can be indexed, which adds the attributes to the Global Catalog. Indexes should be created for attributes that users will search with. In this example, if security needs to look up user accounts by the Security Badge ID number, this attribute should be indexed. For a search to occur on an unindexed attribute, a much slower, processor-intensive walk of the directory tree must be done.
Be strict with what attributes or classes you add to Active Directory. Classes and attributes cannot be deleted with the Active Directory Schema or any other tool. Once you create them, they will exist forever within your Active Directory. The only option you have is to deactivate a class, which stops it from being used in the future. You cannot deactivate a class or an attribute that has dependencies within Active Directory. For example, if an attribute is still used by an active class, that attribute must remain active.
Object Identifiers should be globally unique. One way to achieve this is to have a central agency that assigns OIDs. The Internet follows a similar practice. The InterNIC assigns domain names and the Internet Assigned Numbers Authority (IANA) assigns IP subnets. In much the same way, a National Registration Authority, or NRA, assigns Object Identifiers. NRAs vary from country to country. In the United States, the American National Standards Institute (ANSI) provides NRA services. For a modest fee, ANSI can supply your organization with a root OID. Any objects created by your organization will have this root OID as the prefix, ensuring that Object Identifiers are globally unique. You can find a list of NRAs at the International Standards Organization’s Web site.
For performance reasons, Active Directory servers cache the schema. It will take up to five minutes for the cache to be updated after you change the schema so remember to wait a few minutes before you try to create objects based on your new object classes and attributes. If you must reload the cache immediately, add the attribute schema UpdateNow to the root object (the object without a distinguished name) and set the value to 1.
Extending the schema of Active Directory is a powerful capability, but most administrators will never need to use anything but the classes and attributes provided with Active Directory out of the box.
In part three, I will explain the differences between objects, object classes, and attributes. I will also cover Lightweight Directory Access Protocol (LDAP), on which the addressing scheme of Active Directory is based and Active Directory Service Interface (ADSI), which allows the administrator to automate common administrative tasks using Visual Basic or other programming tools.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.