Extending Active Directory's GUI

Downloads7883.zip

Use extension attributes to meet business needs

Windows NT comes with the User Manager tool, which lets administrators manipulate the properties of users and groups within a GUI application. In Windows 2000 (Win2K), the Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) snap-in updates this tool's functionality.

Microsoft designed the ADUC to manage users and groups in a manner similar to the User Manager, except that ADUC also lets you manage the objects in any domain. ADUC lets you create an entire domain hierarchy of organizational units (OUs), user accounts, computer accounts, groups, and volumes. You can turn on Advanced View and install the Active Directory Connector to email-enable Active Directory (AD) objects and transfer them to and from Microsoft Exchange Server and view the ADUC pages (e.g., Terminal Services Profile, Exchange General, Exchange Advanced, Security) for a user object, which Screen 1, page 152, shows.

A computer object, which Screen 2, page 152, shows, has many fewer property pages. Are there fewer property pages because a computer object has fewer attributes than a user object? No, a computer object inherits its class structure schema from the user class and adds a few new computer attributes. So, the computer class contains all the attributes of the user class plus some new attributes. Although a computer object has more attributes than a user object, a computer object has fewer property pages because administrators don't need to use the GUI to manage most of the computer attributes. The computer object's description is its most important attribute.

ADUC can effectively manage only the properties that it knows about, which can cause problems. For example, suppose you decide to store all the languages that employees can speak in the AD. This attribute doesn't exist in the AD by default, so what do you do? You can use the Extension attributes or create a new attribute in the AD schema (i.e., the blueprint of all objects and attributes that you can create in the AD).

Each object in the AD has Extension attributes. The system doesn't use these attributes; Microsoft provides them so that you don't have to create them. Extension attributes have numbers that range from 1 to 15. To use these attributes, you need to add the data into the Extension-Attribute-1 attribute on every user object. But first, you'll have to get the data into the Extension-Attribute-1, and you'll need to manage the data in Extension-Attribute-1. You can't use the AD GUI because it doesn't manage these attributes by default.

You can also modify the schema to add a new attribute, such as Languages-Spoken, on the user object. But you still need to get the data into the schema. Suppose, instead, you decided to create a new object class, such as Finance-User, in the schema. How would you create a new class? The AD GUI knows nothing about your objects.

You need to consider the end users. Administrators can use the ADUC tool and the other main AD management tools (e.g., Active Directory Sites and Services Manager, Active Directory Domains and Trusts, Active Directory Schema Manager) to manage an AD. However, users search and query the data in the AD. If users, rather than administrators, need to determine the languages spoken, you need some way to display the information in the shell so that end users can see and interact with the information in the AD.

If the administrator's tools and the shell aren't extensible or customizable, the tools aren't much better than the static User Manager tool is. However, Microsoft has successfully solved the extensibility and customization problems. Now you can use scripts to customize an object's GUI to your liking. These scripts don't have to be complex. In fact, Microsoft provides extensions to the AD so that any properly written GUI to the AD (e.g., all the tools that Microsoft provides) can support these scripts.

Display-Specifiers
Since the early design of the AD, Microsoft has produced documentation about Display-Specifiers for the GUI. Display-Specifiers let you enhance any object type with information that an interface that properly understands the Display-Specifier can read and use.

Each object class in the AD schema has a set of predetermined Display-Specifiers. The Configuration naming context holds these Display-Specifiers in a path such as LDAP://cn=409,cn=DisplaySpecifiers,cn=Configuration,dc=mycorp,dc=com. The container, which Screen 3 shows, signifies the Display-Specifiers for the US English locale 409. If you want to create or manage Display-Specifiers for a different locale, create a new container with the relevant hexadecimal code for the locale and populate the new container with the relevant Display-Specifier objects. For example, 409 in hex format (1033 in decimal) is the US English locale. If you create a new container with 809 in hex format (2057 in decimal), you get the UK English locale, and if you create a container with 40C in hex format (1036 in decimal), you get the French locale. You can find the current installed locale values in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlContentIndexLanguage Registry key. Supporting different locales lets you have different Display-Specifiers for the different locales, so the AD objects can have different names, property pages, and menus depending on which locale and language settings a user has installed.

The container holds a series of Display-Specifier class objects. The user class has an object called user-Display, and the computer class has an object called computer-Display. To extend the interface for a language's object class, you simply modify the attributes on the Display-Specifier object that represents the class in that container.

For example, the class-Display-Name property exists on all Display-Specifier objects. Suppose you use the AD Editor (ADSIEDIT) tool from the Microsoft Windows 2000 Resource Kit to open the group-Display Display-Specifier object in the Configuration container. The group-Display Properties provides an attribute page that has a drop-down menu of properties, which Screen 4 shows. Next, find the classDisplayName property and remove the value that corresponds to the name Group and add in the value that corresponds to the name Moose. This change leaves you with the class-Display-Name attribute holding only the word Moose. Ordinarily, when you right-click any container in the ADUC tool, a context menu appears to let you create a new User, Group, or OU. Now the tool will let you create a new User, Moose, or OU. You have simply changed the name that the class uses for the display; the objects haven't changed. To change the display specifier to the French locale in addition to or instead of the US English locale, you create the 40C container and apply the change to a newly created group-Display Display-Specifier object in the 40C container. You can also make other changes to the interface.

Property Pages
An object has an array of property pages, which Screen 1 shows. You can add and display more property pages for an object. To add a property page, the page has to exist as a COM object that supports the IShellExitInit and IShellPropSheetExt interfaces. Therefore, you first have to create the property page in Visual Basic (VB), Visual C++ (VC++), or a similar language.

Creating the object is the hard part; telling the system to use the object is easy. After you create the property page COM object, it will have a universally unique ID (UUID), which is similar in concept to a globally unique ID (GUID). Then, you use a tool such as ADSIEDIT to access the Display-Specifier object that represents the class that you want to modify, and alter the Admin-Property-Pages or Shell-Property-Pages attributes. These attributes are multivalued and store data in the form that Listing 1 shows. The first value specifies the order in which the pages will appear. The second item represents the UUID. You can use an optional third parameter to store extended information, such as the instruction to pass data to the property page as it displays.

To add your property page to a class, edit either the Shell or Admin property page attribute, depending on whether you want to modify the shell or administrator UI, and add in a line similar to either the first or second line in Listing 1. The process is simple. You can even modify and resequence the existing pages.

Icons
When you use the ADUC tool to look at a container of objects, the ADUC shows you an icon that is appropriate to the specific class for that object. The icons for OUs look different from those for containers, users, and printers. You can also use the icon to represent different states of that object. For example, you can change the icon to show a disabled user or computer object. You can define 16 icons to represent different states for any object class. The first three represent the closed (the default state), open, and disabled states; you can define the last 13.

To modify the icon for an object class, simply use the Icon-Path attribute to store multivalued data, as Listing 2 shows. This modification sets the first four icon values. The number 0 sets the value to closed, 1 to open, and 2 to disabled; 3 through 15 are the values that you define. The code in the first line of Listing 2 uses a proper icon file with an .ico extension, so it doesn't need a third parameter. The code in the second, third, and fourth lines of Listing 2 uses the first (0), third (2), and eighth (7) icons from myicons.dll, which uses an index for the set of icons held in the DLL starting at 0. The icon path has to exist on the local machine for any client to properly display the icon, so you might need to deploy the icon files to all clients in an enterprise before they can properly display the icons.

Class and Attribute Names
You can alter the way class and attribute names appear within a GUI. To change the class name, change the text in the class-Display-Name property of the relevant Display-Specifier object. To change the attribute names, you need to modify the multivalued attribute-Display-Name attribute. Attribute values take the form of a comma-delimited string, which Listing 3 shows. The first value is the Lightweight Directory Access Protocol (LDAP) name that corresponds to the attribute in the schema; the second value is the name that it will display.

Leaf or container. When you view objects in the ADUC interface, some display as containers and some display as leaf objects. Most objects act as containers, even when they display as leaf objects. Let's look at a printer on a computer. If the computer is publishing the printer as a Print-Queue object to the AD, the object displays as a leaf object within the Computer object that is publishing the printer. In other words, the Computer object acts as a container for any print queues that it publishes.

User, Computer, and Group objects by default don't display themselves as containers. In fact, the ADUC tool has an option on the View menu called View Users, Groups, and Computers as containers that adds this capability. For other objects, you can go to the Display-Specifier and change the Boolean value Treat-As-Leaf to True or False to modify any object's default setting.

Object creation wizard. When you create a user, group, or OU, the system provides a simple wizard to let you specify the relevant data for that object. To modify the default behavior, you can replace the wizard or you can add pages to the wizard. You can have only one wizard, so you must create a new one or modify the existing one. Let's suppose you want the Languages-Spoken attribute for a user to be a mandatory attribute of the user class. This attribute forces you to define a value for Languages-Spoken for all new users on creation. The existing User creation wizard doesn't let you input data for this attribute, so you can replace the wizard or place a new page in the wizard to receive data for this attribute. The attribute doesn't have to be a mandatory attribute for you to add a new page; you can also provide wizard pages for any optional attributes. You can provide as many extra pages as you choose and in whatever order you prefer.

As you do with property pages, you need to create a new wizard or extend the creation wizard (the default wizard) as a COM object that supports the IDsAdminWizExt interface. A new wizard that replaces the default wizard is known as a primary extension. This wizard replaces the core set of pages that you would use to create the object. Primary extensions support the extension of the creation wizard, so you can define a primary extension for all users and later extend the creation wizard to add extra pages. You use the COM object UUID to identify the items in the AD. When you replace the default wizard with a primary extension, you modify the Creation-Wizard attribute of the relevant Display-Specifier object to hold the UUID of the COM object. When you provide creation wizard extensions, you specify the order in which the pages will appear, then add the UUID in the Create-Wizard-Ext multivalued attribute. The format is the same as for property pages.

Context menus. When you right-click an object in the ADUC tool, a context menu pops up. You can add your own entries to this context menu. The Admin-Context-Menu attribute on the Display-Specifier object holds the menu items for this context menu. You can also add entries to the context menus that appear in the shell for end users. The Shell-Context-Menu attribute on the Display-Specifier object holds these items. You need to put items that you want to appear in the shell and ADUC in the Context-Menu attribute.

The items that you add to the context menus can launch an application or create an instance of a COM object. The data takes form in the relevant attributes, which Listing 4 shows. The code in the third line of Listing 4 is a COM object. The UUID identifies the object. You must have created the COM object to support the IShellExtInit and IContextMenu interfaces. You can include a third parameter on the line to pass extra data to the COM object. The previous two lines of code are much more important to administrators. In the first and second line of code in Listing 4, you can see that I'm adding two extra items to the menu: an executable program and a VBScript script. You can add any type of application. The second parameter is the string that I want to appear on the context menu. Use of an ampersand (&) character before a letter identifies that letter as the menu selector. So, when the menu displays, typing D selects the first option (i.e., E:myprog.exe) and E selects the second option (i.e., C:myscript.vbs).

The ability to add scripts and programs to a context menu is a significant step forward. When you couple these scripts and programs with Microsoft Active Directory Service Interfaces (ADSI), you have a way to offer new functionality directly from the GUI. Let's say you want to extend the schema and include a new optional Languages-Spoken attribute for the user class. You can go to the user-Display Display-Specifier object and modify the Context-Menu attribute (so that the attribute is available to both users and administrators) to include an ADSI script that displays the languages spoken for that user in a message box. Listing 5 shows a Windows Scripting Host (WSH) 2.0 script written in Extensible Markup Language (XML) with an embedded ADSI VBScript script. To use that script as the program, simply save the file with a .ws extension (as a Windows Script—WS—file). For more information about how to use XML tags with WSH 2.0 to run scripts, see Dino Esposito, Windows Script Host Programmer's Reference (Wrox Press, 1999), or Bob Wells, Scripting Solutions, "Windows Scripting Host 2.0," December 1999.

The script binds to the object's ADsPath and passes to the program the object's ADsPath as an argument and displays the attribute in a message box, which Screen 5 shows, with an appropriate title. In the message box, I right-clicked the Guest user, and a context menu popped up that includes Languages Spoken. In the bottom left corner, you can see that the box's title is a display of the string

&Languages Spoken...

When I click the item or press the L key, Listing 4 generates and displays a dialog box. (The dialog box and the context menu don't display together.)

You can also write a script or program that lets you modify the Languages-Spoken attribute and have the attribute appear only on the administrator's context menus. Then, you can use the ADUC tool to manage your users and this extra attribute without developing a new interface. (For more information about how you can use personal customizations to extend the Win2K GUI, see the Microsoft article "Shell Extension Handlers" at http://msdn.microsoft.com/library/sdkdoc/shellcc/shell/shellext.htm and the Microsoft article "Extending the User Interface for Directory Objects" at http://msdn.microsoft.com/library/sdkdoc/adsi/gldispl1_06pf.htm.)

Next time, I'll discuss the extension-attributes idea further. I'll look at how to use Microsoft Excel 2000 to automatically generate Win2K reports.

Source: Adapted from Alistair G. Lowe-Norris, Windows 2000 Active Directory (O'Reilly and Associates, 2000).