|
|
Last Updated: October 22, 2009
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 root domain called the "People" OU. The People OU is populated with approximately 250,000 U-M user accounts that are copied from and synchronized with the U-M Online 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 OU's, specifically the Accounts OU and the Organizations OU. The reasons for using two delegated OU's, 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 OU. 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 over 250K user accounts. These accounts are replicated and synchronized with the U-M Online Directory (UMOD) 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 logon to a Windows workstation in the UMROOT forest using only their U-M Kerberos 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 U-M kerberos 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 set via the Windows/Active Directory tab on the Reset Password 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 is several ways.
-
The delegated Accounts OU may contain only AD "uniqname" users.
-
Delegated OU administrators must use the tools on the U-M Windows
Central Accounts web page to move users to or from their delegated Accounts OU.
-
Access to certain user attributes is restricted through permissions set on the delegated Accounts OU.
-
An OU administrator cannot create a subordinate OU under their delegated Accounts OU. This last restriction is necessary to enforce the restricted user attribute policy described in the preceding list item.
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 U-M 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.
UMROOT Forest - Child Domains and Domain Trees
Some larger organizations on campus, such as LSA, Engineering and Business, have created their own child domains or domain trees. Within their own domain, the administrators have full control over creating and managing objects and can use uniqnames as usernames. The disadvantage of these non-root domain accounts is that they cannot use pass-thru Kerberos authentication. It is possible for users logging onto computers in non-root forest domains to authenticate using their UMROOT account, however. A user with a Windows uniqname account in both the UMROOT domain and a child domain could logon to a computer in the child domain using their UMROOT account and pass-though Kerberos authentication.
Project Design Criteria
A primary criteria of this project is to maintain full functionality for users logging onto Campus Computing Sites and University Library computers. Delegating UMROOT user accounts to campus Windows administrators using the U-M Windows Central Accounts infrastructure will allow us to meet the following goals:
- Delegated OU administrators can manage user passwords, and most user attributes.
Administrators will be able to reset passwords, setup Exchange accounts, apply group policy and manage many of the Windows-centric user attributes. This will remove the disadvantage to using these accounts. However, some attributes will still be limited. These limitations are in the section, Description of Attributes ACLs Assigned to Accounts OU.
- Pass-thru Kerberos authentication will work.
Users will have a single Windows account that can used for pass-thru authentication, giving them access to central Sites and Library) and local (Departmental) Windows resources throughout the forest and any other applications that use MIT Kerberos credentials.
- Reduce number of future domains.
It will reduce the number of requests for domains in the UMROOT forest. Managing multiple Windows domains in a distributed environment becomes increasingly difficult as the number of domains in the forest grows. In certain instances, a forest domain used as a resource container, coupled with a UMROOT delegated OU, could be an option, however this not a recommended approach due to the added complexity of cross-domain boundary issues.
- Automated account provisioning.
As the U-M Windows Central Accounts project evolves, automated provisioning of user accounts moved into delegated OUs may be possible. Provisioning at this level would probably be geared towards centrally provided services, such as Exchange, and perhaps a common file space.
|
