Would you like your user's Novell accounts set up automagically with little or no work on your part? If your answer is yes, read on.

Introduction
Process
Summary
Detailed Technical Description

Introduction
ITCS LANNOS has developed a solution for automating the provisioning and retirement of user accounts in the Michigan eDirectory Tree.  This solution uses affiliation information present in the University of Michigan Online Directory (UMOD) as the main factor for determining which people will have an account provisioned for them in a particular department's container.  The affiliation information in UMOD is updated frequently from a variety of sources.  UMOD groups managed by local administrators are used to manage any exceptions to the affiliation information.

During account creation, the following options are available and customizable to tailor to a unit's specific needs and desires:

• Default Password
• Password Requirements
• Default Group Membership
• Home Directory Creation
• Kerberos Login Method Configuration
• Login Disabled Flag
• Administrator Notification
• User Notification
• Other Attribute Population

Retirement of accounts due to affiliation changes are also customized to tailor to a unit's specific needs and desires.

Process
Little effort and time on the part of the local administrator is needed to begin using the service.  To begin, a local administrator needs to send an email to novell.support@umich.edu stating their interest in using the service.  A member of ITCS LANNOS will arrange a meeting where a brief interview will be conducted to determine what the unit's needs and desires are.  This meeting typically takes one hour and allows for interactive discussion of the options available and common choices made by local administrators.  Here is a list of most of the questions that are asked during this interview:

1. Which affiliations in UMOD should be used to determine who your users are?
2. Are all of your current user accounts using uniqnames?
   
3. Should accounts be created with logins enabled or disabled?
4. If an existing login disabled account is discovered during an account creation, should the user be set to logins enabled, or stay disabled?
   
5. Should a password be created during creation?  Random?  Identical initial password for everyone?
6. Should a user template object be referenced during object creation?
7. Do you use alias objects in your container?
8. Where should your user accounts be created in your container?
   
9. When a user's affiliation changes and a user is no longer considered to be your user, should the account be disabled, deleted, or untouched?
10. When a user's uniqname is deleted, should the account be disabled, deleted, or untouched?
    
11. What events should trigger administrator notifications?
12. What events should trigger user notifications?

One requirement for using this service is that the local administrator(s) must be presented with information about the types of privacy protection of directory information offered to Faculty, Staff, and Students, how to determine if someone has requested any of these protections, and what information they protect.  This presentation is provided by ITCS LANNOS and can either be presented during the interview meeting, adding about 30 minutes to the meeting, or at a different time.

Once the interview is complete, the local administrator will gather the necessary information and send it to ITCS LANNOS.  Once ITCS LANNOS has that information, they will build the solution in a test environment.  This test environment closely mimics the Michigan Tree.  Once the solution is believed to be ready, a complete test of the solution is performed and the local administrator is given an opportunity to review the results.

If the results are satisfactory, the solution is moved to the production environment.

Summary
In all, the time and effort required by a local administrator is limited to the following:

• One hour interview meeting
• Thirty-minute privacy protection presentation
• Gathering of required information
  
• Review of test results
• Maintenance of exception groups

ITCS LANNOS can provide contact information for local administrators that have been through the process and can offer first hand knowledge of the experience.

Detailed Technical Description
For a detailed technical description of the technology used to provide this solution, please click here...

To see the slides of a presentation outlining this project as presented at Novell Brainshare in April 2003, see Brainshare 2003 Powerpoint presentation.

If you have any questions, please feel free to email novell.support@umich.edu.

To offer constructive criticism, or provide other feedback about our site, click here.

Information Technology Central Services at the University of Michigan

ITCS Home  |  University of Michigan