Ten fingers and ten toes...
Published 09 November 08 09:56 AM
When you first deploy Active Directory or slog through an Active Directory merge, you're usually happy if you can simply get everyone to agree to a standard formatting for the basic User attributes: first name, last name, logon name, pre-W2K logon name, location information, what to put in the Notes field, and so forth. Like most new parents, you're happy if the baby has ten fingers and ten toes. But as I discussed in earlier posts, the real work of a merge begins when you consolidate the various user creation and termination processes, and for that, you really need additional User attributes to contain identity information from the legacy organizations.
In a previous post, I described how to create custom attributes in an Active Directory schema to store legacy identity information. To make these attributes useful, they need to be associated with the User class in the schema. That's what I'll cover in this post.
In the Active Directory schema, a class is simply a bundle of attributes with a name. The attributes represent real-world artifacts such as passwords, logon names, distinguished names, common names, creation dates, last logon time stamps, and so forth. Some of these attributes are inherited from parent classes and some are unique to the class itself.
The User class, for example, contains a set of attributes that, taken together, uniquely identify a Windows user account. By jostling around a few attributes, you could create another class such as a Computer class or a Contact class. By playing with different parentage and choosing from a wide palette of attributes, AD designers create classes as diverse as the Site class, the CertificationAuthority class, the DNSZone class, and IPNetwork class.
It's possible to modify the User class directly to add new attributes, but it's much safer (and best practice) to create an auxiliary class to hold the custom attributes then link the auxiliary class to the User class.
Confusing? Here's another way to look at it. Let's say you have a new cell phone. The exterior of the phone is the same dull metallic silver as every other cell phone from the same vendor and you want to personalize yours a bit. You could, given the right time and tools, remove the phone's cover and replace it with a custom cover, but it's simpler and safer to attach a "skin" that overlays the existing cover without compromising the phone's integrity. Even more useful, the skin can be easily removed and replaced with another skin if you get tired of the first one.
Classes such as User, Computer, Contact, and so forth are "structural" classes, meaning that they are used directly to create object instances such as User objects, Computer objects, and Contact objects. An "auxiliary" class cannot be used to create an object. Instead, it acts as a "skin" that layers on a new set of attributes to an existing class without modifying the class' underlying structure.
This is how Exchange does its magic of turning a User object into a "mailbox-enabled" objects. Exchange adds a set of auxiliary classes into the schema that contain the attributes necessary to define "mailbox-enabled" then links these auxiliary classes to existing User, Group, and Contact objects.
In my example domain consolidation project, to make use of the various custom schema attributes that represent legacy Bellus and Zyra identity information, I'll add the custom attributes I previously created to a new custom auxiliary class then link that new class to the User class.
To create the new auxiliary class, use the same Schema Admin console used to create the custom attributes. Right-click the Classes icon and select Create Class. This opens the Create New Schema Class window.
In line with the naming standard I'm using in this example, I'll give the class a Common Name and LDAP Display Name that starts with vxi..., which stands for VirtualXI, the example company name. I recommend using a standard prefix for your classes and attributes so that they will be collected together in the schema listings. Microsoft does business this way, and so should you.
All schema objects require an Object ID, or OID. I used the same OID Generation script I used in the examples for attribute creation and assigned a #.1 series for classes and a #.2 series for attributes.
Under Inheritance and Type, Parent Class, you can leave the field empty or type in Top.
In Class Type, be sure to select Auxiliary. You can't change this after you save the object and the type must be auxiliary for the remaining steps to work.
Click Next. This opens a window for selecting the attributes that will be included with the class. Remember that a class is really just a bundle of attributes.
Only assign Optional attributes. No custom attributes should be assigned as Mandatory because they will not be instantiated by the operating system and this will prevent objects from being created.
In the Optional field, click Add to open the Select Schema Object window. Scroll to the list of custom attributes you created. One by one, add them to the attribute list of the class. Once they're all added, you'll see a list similar to that shown in the screen shot below.
Click Finish to create the auxiliary class object. You're halfway done. You now need to link this auxiliary class object to the User class. Do this by opening the properties of the User object in the schema then select the Relationship tab.
Next to the Auxiliary Classes field, click Add Class. From the Select Schema Object list, select the new auxiliary class that was just created. Then click OK to save the change.
Well, you ask, how do I know if the change took effect? If you're doing these changes on a Windows Server 2008 domain, you can take advantage of the new Attribute Editor tab in Active Directory Users and Computers (ADUC) to view the newly added attributes. If you're doing the changes in a Windows Server 2003 domain, use ADSIEdit.msc from the support tools.
In the next post, I'll discuss how to simplify the display of the new attributes in searches, how to populate them quickly using VB and Powershell scripts, and how to use them to automate user termination processing.
.jpg)
No comments:
Post a Comment