Kerberos interoperability requirements have necessitated that centrally maintained Windows/Active Directory accounts be placed in the forest root domain, UMROOT. The UMROOT domain is provisioned with user objects from the MCommunity Directory. These user objects reside in the People Organizational Unit, as shown below. Changes to user entries in the MCommunity Directory are propagated to corresponding user objects in the Active Directory. For users who have requested privacy, only minimal Windows user accounts are created, containing no personal information. For a more complete discussion of schema attribute mapping between the MCommunity Directory and Active Directory, see the Active Directory User Object Provisioning section below.
One aspect of the user provisioning from the campus directory bears mention here. As the user objects are created within Active Directory, they are assigned a long, random, unknown password. For many uses of the campus forest, it is not necessary to know your Windows AD password, because access is via pass-thru authentication (see Configuring a Windows 2000 or XP Workstation for Kerberos Pass-thru Logon and Accessing File Shares with Kerberos Pass-thru Logon for information on how to do this). However, there are occasions when it is necessary to know your Windows AD password. To accomodate those occasions, you can reset your Windows Active Directory password by resetting your UMICH password on the University of Michigan Password Change web page.
Accounts and Organizations OUs
The UMROOT domain also houses two types of delegated OUs, created within the Organizations and Accounts OUs.
The Accounts OU contains OUs for units who wish to manage the attributes of their users. Through the Windows Central Accounts Service, local admins can request that centrally-provisioned users be moved from the People OU into an Accounts OU established for their unit. Once moved into their Accounts OU, the local admins can modify the values of select attributes of the user objects. Local admins cannot create or delete objects in their Accounts OU.
The purpose of the Organizations OU is to provide a space for U-M campus units to administer their own organizational resource OUs. Once an Organizations OU has been created by ITS for the campus unit, administrative control of that OU is delegated to an Active Directory Security Group that is exclusively populated by local administrators of the designated organization. In effect, the local administrator retains exclusive control of that OU, and can create, delete and modify objects within, and subordinate to, their organizational OU. Such objects might include workstations, servers, printers, security groups, subordinate OUs and "external" users.
In this context, an "external" user is defined as a user who does not have, and cannot obtain, a U-M uniqname, and thus does not exist as a user object in the People OU. Examples of Active Directory "external users" might be temporary U-M staff or visiting faculty. To avoid user namespace collisions in the future, Active Directory external users should be given names that include a "dash" symbol (i.e., "-"). Since the U-M uniqname naming standard does not support the use of a dash symbol, external user names of the form "part1-part2" are guaranteed not to collide with any uniqname that may be created in the future. Our Naming Standards recommend using the departmental prefix for part1, leaving the composition of part2 to the local admin.
UMROOT Domain Characteristics
The following chart enumerates important characteristics of the UMROOT domain. Some of the restrictions listed in this table may be removed in the future.
| Characteristic | UMROOT Implementation |
|---|---|
| User object creation | ITS-maintained users reside in the People OU. These AD user objects are provisioned from the MCommunity Directory. External users (those without a U-M uniqname) can be created within delegated Organization OUs, provided their usernames follow the proper naming convention. U-M user accounts (those created with a U-M uniqname) are initially created in the People OU. Using the Windows Central Accounts Service, users can be moved into a delegated Accounts OU. |
| Computer object creation | OU administrators can create computers within their Organization OU, in the UMROOT domain. This is typically done by pre-allocating the computer object in the unit's Organization OU, while delegating to a security group the permission to join the computer to the forest. |
| User group policy | User Group Policy can be applied directly to centrally-provisioned user objects within the People OU once they have been moved into their delegated Accounts OU. Delegated OU administrators can also apply Group Policy via computers within their own Accounts OU. Using loopback processing, these Group Policies can be applied to users logging into computers within the OU. |
| Computer group policy | Computer Group Policy can be applied through the Organization OUs in the UMROOT domain by OU administrators. |
| Kerberos pass-thru logons | Pass-thru logons work for users in the People OU. If a "duplicate" user exists in another domain, the user account in the UMROOT domain will be used for pass-thru logons. |
| Security group creation | ITS may create security groups that can be used by other members of the U-M W2k forest. OU administrators can also create security groups to allow access to resource with their OU. |
| Application services | Each OU can provide application services as needed. |
Active Directory User Object Provisioning
Active Directory user objects in the "UMROOT" People OU are created and updated from equivalent user entries in the MCommunity Directory. This is a one-way process, from the MCommunity Directory to Active Directory.
Active Directory Privacy Issues
A number of users in the MCommunity Directory have designated their directory entries as "private." Corresponding AD user objects, created in the People OU of the UMROOT domain, will also be private. Private Active Directory user objects are created as "minimal" accounts. Like other user objects created in the People OU of the UMROOT domain, private user objects are created with a U-M uniqname. For private users, however, no other personal attributes are created. For instance, name and telephone numbers attributes are not included for AD private users. Additionally, each private user object includes a U-M specific attribute, "umichadHidePersonalInfo", which is set to a value of "TRUE".
Active Directory Schema in the U-M Forest
Attribute Mapping: MCommunity to U-M Active Directory (UMROOT domain)