|
|
Last Updated: April 02, 2005
U-M Windows Central Accounts Service
U-M Windows Central Accounts Service Web Applications
Several common tasks performed by delegated OU administrators have been automated with self-service web applications. The current set of applications can be found at:
U-M Windows
Central Accounts Applications
Documentation for each web application can be referenced from the "User FAQ and Documentation" menu items of the home page, and by pressing the "Help" button from with the application.
At this time, requests for a new delegated OU are still handled manually, as described in the "How to" document "Joining the U-M Windows Forest as a Delegated Organizational Unit".
Here is a high-level summary of each U-M Windows Central Accounts web application. A quick glance at the U-M Windows Central Accounts Applications page will reveal that it is divided into two sections, one for normal Windows users, and the other for delegated OU administrators. For details on running an application, see the User and Administrators "FAQ and Documentation" menu items. We'll start with applications for delegated OU administrators.
|
Manage OU Profile - Manage OU Affiliations |
|
|
Each delegated OU represents a department or organization within the U-M community, and is associated with one or more officially designated "affiliations". The Manage OU Affiliations application allows OU administrators to associate appropriate affiliations with their delegated OU. This is important because when users are moved to a delegated OU, an affiliation check is done to compare the user's affiliations with the affiliations of the OU to which the user is being moved. If there is a match, then the user is assumed to be legitimately associated with the delegated OU. If a match does not exist, then the OU administrator must request an "exception" for the user. Maintaining an accurate list of delegated OU affiliations can minimize the number of user exceptions that may need to requested.
|
|
The "Manage OU Affiliations" application collects changes to the existing OU affiliation list, and then forwards those changes via email to the U-M Windows Central Accounts administrators for approval. Changes to the OU affiliation list are typically infrequent. Most activity of this type takes place after a new OU has been created.
|
|
Move Users to-from Delegated OU |
|
When an OU administrator needs to move a user from the People OU to their delegated Accounts OU, or visa-versa, they can use the "Move Users to-from Delegated OU" to do this. In the most favorable case, they will enter a list of user account names (U-M uniqnames) into the application, the application will confirm that each user is affiliated with the delegated OU, and all the users will then be moved. In less favorable circumstances, some users may not be affiliated with the delegated OU, and will require the OU administrator to request an "exception", which is shorthand for "consent for alternate Windows administration". |
|
When an "exception" is requested for a user, they will be placed on a exception wait list, and will be notified by email that an exception has been requested on their behalf. By logging on to the "Consent for Alternate Windows Administration" application, the user can either accept or deny the exception request. |
|
In some cases, a user may be affiliated with multiple U-M organizations. If a user has been moved to a delegated Accounts OU, and an administrator from another delegated OU tries to move the user to their OU, the "Move Users" application will flag an error. In these types of situations, the administrators of the two delegated OUs will have to work out a solution that is acceptable to all concerned, including the user.
|
|
When a request is made to move a user to a delegated Accounts OU, the user will also be added to an ITCS maintained group that contains all members of that OU. The naming convention for the groups is -all-users (e.g., lsa-math-all-users, or ssw-all-users).
|
|
To remove a user from a department OU, the admin will submit another request. The user will then be moved back to the People OU. Most of the attributes will be reset when the user is returned to the People OU. The main exception is that group membership will not be touched. The department admins are responsible for removing access to resources they have assigned before submitting the request.
|
|
There are some user attributes, such as account names and phone numbers, which are automatically populated from UMOD which should not be overwritten by administrators. Disabling accounts cannot be allowed because it would deny the user the ability to use a Campus Computing Sites or Library computer. Finally, other user attributes, such as Home Directory, Login Script might adversely affect users when logging into computers in some areas. Appendix C lists all the attributes that are not available to administrators. |
|
Many delegated OU administrators find that they don't need to move users to a delegated Accounts OU. Windows security groups can be used to grant resources to groups of users, regardless of their location in Active Directory. In may cases, this capability is sufficient to accomplish the administrator's goals. |
|
Consent for Alternate Windows Administration |
|
After an OU administrator requests an "exception" for a user whose affiliations do not match even one of the OU's affiliations, the user will be sent an email message indicating that the OU administrator seeks permission to administer the user's Windows account. (The admin will be cc'd on the email message to the user.) By clicking on a link in the email, the user should be presented with the "Consent for Alternate Windows Administration" application. The user will first be asked to identify themselves by entering their U-M uniqname and Kerberos password. Once they are authenticated, the user will be presented with an explanation of the "exception" process, and can either accept or reject the request. |
|
Any U-M user with proper credentials can access the "Consent for Alternate Windows Administration" application, however if the user is not in the "exception-wait" list, they are merely presented with a message indicating that no current exceptions are pending for them. |
|
A users entry in the "exception-wait" list will expire after two weeks. During that time, the user will can accept the exception request at any time, even if they have previously rejected it. |
Information Technology Central Services at the University of Michigan
|
|
|
