AD and Dual-Domain Membership

Active Directory (AD) is great, isn't it? Well, sure, as long as you don't want to create an object that lives in two or more domains. One of my consulting clients is a research organization affiliated with a university. The client has two domains--the research organization and the university, and users are either researchers or faculty members. Thus, the IT staff for the research domain can change passwords for the research users, and the IT staff for the university domain (the IT staffs are different) can change passwords for the university users.

This is a classic example of how to set up AD: If one IT staff supports some of your users and another IT staff supports another group of users, then you put the different user groups in different domains or organizational units (OUs). However, in this organization some of the researchers also happen to be faculty members. Oops.

The client wants the small group of people who are both faculty members and researchers to be supported by both the research support people and the faculty support people. For example, a member of this group of dual-domain people should be able to call a Help desk person from either the research staff or the faculty staff and ask to have his or her password reset. (Yes, password reset is a small matter, but it's a good illustrative example.)

The AD techies reading this will say, “Heck, I can fix that; just create a special group and …” and sure, they're right: You can spackle over this particular problem. You can manually change the delegation permissions on any user account from one domain, giving administrators from the other domain the power to modify that user account. Or you could create a user group called "dual domain people" and create a script to ensure that everyone in that group has delegation permissions. But no matter how you slice it, you're creating more management trouble in the long run.

How could a hypothetical AD easily let us create users with "dual citizenship?" How about "AD shortcuts?" We're familiar with the notion of a file or folder shortcut--an object that represents the file or folder but that you can place in another folder. You could, for example, use a shortcut to give a file or a folder a presence on both a C drive and a D drive.

Imagine how you could use an AD shortcut to solve my client's problem. First, you would go to the faculty domain and select all the members who were also researchers and select Copy. Then you would right-click the research domain and choose Create Shortcut. You would then have shortcuts to all the faculty members in the research domain, and anyone who could administer a research account could also administer those faculty members' accounts.

AD shortcuts could address another big shortcoming. OUs are useful tools for subdividing the administrative burden of a domain, but only if you divide your organization along one dimension. For example, if a firm has different IT staffs for each geographical location, then AD lets you easily create New York, Los Angeles, and Charlotte OUs and give each IT staff control of only their territory. Similarly, you could divide a firm's IT work along business units (e.g., a firm whose Engineering, Manufacturing, and Accounting groups have their own IT support staffs).

In both cases, OUs and AD's current delegation structure get the job done. But what if a firm divides itself along more than one dimension (e.g., different support staffs for every geographical/business unit combination?) Unfortunately, AD doesn't do so well in such cases. Your only option is to create a top-level set of OUs along one dimension and sublevel OUs inside those OUs, leading to a monstrous number of OUs. For example, suppose a firm had four business units and five geographical regions. In that case, the firm would need at least 24 OUs: four top-level business-unit OUs and five geographic OUs inside each of those top-level OUs. Worse yet, you can't collectively administer the second-level OUs. For example, if the firm's top level OUs represent geographical areas and second-level OUs represent business units, you have no easy way to make a change to all the second-level OUs that refer to a particular business unit. If you have a legal department OU in each geographical OU, then any global changes you make to the firm's legal OUs, you must manually redo on each geographical legal OU, inviting error.

If OUs and their contents could have shortcuts, you'd still need to create quite a few OUs--one for each business unit/geographical combination--but you could make shortcuts for those OUs in one another's folder, creating an AD that acts both as a hierarchy of OUs with geographical units at its highest level and a hierarchy of OUs with business units at its highest level.

Should we expect something like this for Longhorn? I doubt it. But the notion's pretty powerful. Maybe some day…