U-M Windows Forest
How-To Documents
Get Help

U-M Windows Central Accounts Service Purpose

User accounts can reside in several places within Active Directory, including OUs in the root domain, other forest domains and in a special OU of the root domain called the "People" OU. The People OU is provisioned with U-M user accounts from the MCommunity Directory. While keeping all Windows user accounts in a single large OU container simplifies the structure of Active Directory, many administrators are unable to fully exploit the administrative capabilities of the Windows AD environment using this "one size fits all" arrangement.

The purpose of the U-M Windows Central Accounts service is to enhance the level of administrative control that departmental OU administrators can provide to Windows users in their respective organizations. To accomplish this goal, OU administrators can request that user accounts in their organization be moved from the People OU to a "delegated," departmental OU.

Current User Accounts in the UMROOT Domain

The following sections discuss three different types of AD locations in which UMROOT domain user accounts reside. Briefly, the three locations are:

The primary location for most Active Directory accounts is the People OU. The other two types of locations are both "delegated" OUs associated with a department or U-M organization. Users moved from the People OU are placed in a delegated OU residing under an "Accounts" umbrella OU. Non-uniqname AD accounts, which are typically either administrative accounts or accounts for visitors, can be created in a delegated OU residing under an "Organizations" umbrella OU, which is the focal point of most delegated OU activity. The delegated Organizations OU is also the prime repository for other types of AD objects, such as computers, printers, and security groups. An organization's delegated Accounts OU and delegated Organizations OU have the same name, but just reside under separate umbrella OUs, specifically the Accounts OU and the Organizations OU. The reasons for using two delegated OUs, rather than a single OU, are based primarily on Active Directory security and operational considerations.

Here is a sample diagram of UMROOT domain, showing the delegated OU hierarchy. Note that the LSA OU is an example of an umbrella OU that contains multiple delegated OUs. Our current delegated OU model encompasses both one- and two-level delegated OU structures; however we encourage all but the largest organizations to stick with the one-level model.

View larger image in new window

UMROOT Domain - People OU

The People OU in the root domain, UMROOT, contains user accounts that are provisioned from the MCommunity Directory and use equivalent U-M uniqnames for the Windows account name.

For the Windows environment, these accounts are configured to use pass-thru authentication. This means that a user can log on to a Windows workstation in the UMROOT Forest using only their UMICH credentials (uniqname and password). The user will then receive Kerberos tickets for both U-M Kerberos (umich.edu) and UMROOT Windows Forest (adsroot.itcs.umich.edu), both of which are stored in the workstation's Windows Kerberos ticket cache.

Windows "uniqname" accounts are used extensively by Campus Computing Sites, the U-M Library, and other departments for authenticating users to their workstations, since the user only needs to know their UMICH password.

Applications that can read the U-M tickets from the Windows ticket cache will use them for single sign-on authentication. Although few applications currently take advantage of single sign-on, this could change in the future.

By default, users in the People OU do not know their Windows domain password, which has been set to a large random string during the account creation process. If a user needs a Windows password for compatibility with certain Windows applications, it can be synched with their UMICH password on the U-M Password Change web page.

Due to the "one size fits all" nature of the People OU, account attributes such as Exchange settings, Roaming Profiles, and Home Directories cannot be managed by OU administrators. This limits the usefulness of these accounts in many departmental environments, and is one of the key motivations for moving accounts from the People OU to a delegated Accounts OU.

UMROOT Domain - Delegated Accounts OUs

The "Accounts" umbrella OU contains many delegated Accounts OUs, each created for a U-M department. In some cases, such as LSA (Literature, Science & the Arts), another umbrella OU is sandwiched between the Accounts OU and the delegated departmental OU.

Access to a delegated Accounts OU is restricted in several ways.

UMROOT Domain - Delegated Organizations OUs

The "Organizations" umbrella OU contains many delegated Organizations OUs, each created for a U-M department. In some cases, such as LSA (Literature, Science & the Arts), another umbrella OU is sandwiched between the Organizations OU and the delegated departmental OU.

Departments are able to run their own fully delegated OUs within the Organizations OU of the UMROOT domain. Unlike accounts in the People OU, administrators can create and fully manage objects in their delegated Organization OU, including user, computer, printer, security group and organizational unit objects.

To prevent name collisions with accounts in the People OU, Windows administrators should not create uniqname-style user names (3-8 alpha characters) in their delegated Organization OU. Non-uniqname AD accounts, which are typically either Windows administrative accounts or Windows-only accounts for visitors can be created if they don't breach the uniqname naming convention. Since Windows-only accounts have no counterpart in the U-M Kerberos or the MCommunity Directory, these accounts cannot participate in single sign-on and pass-thru authentication. For Windows administrative accounts, this is desirable, since there are no security exposures outside the Windows environment.