Distributed Computing Services			   George F. Willard III
MTU Request for Comments: 0003	       Michigan Technological University
Category: Informational				           February 2001


	 	    Michigan Technological University
	        Campus Login Namespace Management Policy


Status of this Memo

        This memo is a draft of the current and proposed (section 4)
        campus login namespace management policy.  Please send updates,
        suggestions, questions and comments to gfwillar@mtu.edu.
        Distribution of this memo draft is unlimited.


Copyright Notice

   Copyright (C) Michigan Technological University.  All Rights Reserved.


Table of Contents

   1.0   Introduction .............................................  1
   2.0   Login Creation ...........................................  2
         2.1   Prospective Students                                  2
	 2.2   Secondary Logins					     2
   3.0   Login Expiration .........................................  3
	 3.1   Role of the NID active table			     3
	 3.2   Deactivation of Services				     3
   4.0   Login Deletion ...........................................  3

1.  Introduction

This document outlines the procedures and policies regarding the addition,
expiration and deletion of campus logins for Michigan Technological University.














Willard                      Informational                       [Page 1]

RCF 0003        Campus Login Namespace Management Policy    February 2001


2.  Login Creation

Logins are typically generated by stored procedures in the Network Information
Database (NID) on the administrative database, admin1.  The login consists
of up to eight alphanumeric characters, formed from the first initial of the
user's first and middle name prepended to the first six characters of the
last name of the user.  In the case that the login already exists, the middle
initial is not included, and permutations of the user's initials and last name
are attempted until a unique login has been found.  Joe A. User's generated
login would be jauser, or juser if jauser was already assigned to another user.

Logins can also be changed by any MTU system administrator, with the
stipulation that the system administrators must contact IT-DCS or system
administrators that have active table entries for the login that the
administrator would like to change.  This helps to keep the login from becoming
unsynchronized among departments across campus.  Vanity logins or login changes
for students is generally discouraged, as discussed during academic forum
meetings, to help keep the login pattern consistent, but is at the discretion
of the student's departmental system administrator.


2.1 Prospective Students

Logins are batch generated for prospective and newly enrolled students before
the start of each semester.  The timing of the batch generation is determined
by the Student Affairs Office, with additional updates being incorporated until
the semester starts.   This allows for the generation of informational
handouts regarding e-mail address, computer login, and computer lab locations
to be given to the prospective students before they arrive at MTU.


2.2 Secondary Logins

A secondary login has the same capabilities of a regular, or primary login.
The login can be added to active tables, has a unique UID, and can receive
e-mail.  An example of a secondary login would be a special purpose "deptmaint"
account, or a student organization account like "wmtu".  Secondary logins may
only be generated by IT-DCS, and are associated to a responsible party via
RPIDM that determines who has responsibility for the account.  IT-DCS chooses
to retain control of secondary logins in order to reduce the number of
secondary logins, often accommodating similar functionality more effectively
via e-mail aliases.  












Willard                      Informational                       [Page 2]

RCF 0003        Campus Login Namespace Management Policy    February 2001

3.  Login Expiration

When a new login is generated, the deleted_on field in the NID login table
is set to NULL, indicating that the login should not be deactivated or deleted.
The login is then added to departmental active tables which indicate that the
login is active within the departmental domain.  When a login has been delete
from all active tables, the deleted_on field is set to the date of the last
removal from the active table.


3.1   Role of the NID active table

The expire_date field in the NID active table does not remove a login from
the active table when the expire_date has been reached.  The expire date is
intended to be an indicator to the system administrator to re-evaluate the
necessity of the login, or trigger local system scripts to deactivate or
disable the account.  A simple 'modify active set expire_date=DATE' can reset
this indicator, but at no time does the expiration trigger an event in the
NID.


3.2   Deactivation of Services

When a login has been removed from all of the active tables, the login will
no longer receive e-mail after six months from the delete_on date.  The login
will also be removed from the central directory services so that the login
may no longer use LDAP authentication or be listed in the PH white pages.
Logins may be deactivated at any time upon the request of an MTU system
administrator.


4.   Login Deletion

Once the deleted_on date of a login is two years old, the login will
be removed from the login table.  The login may be removed sooner upon
the request of an MTU system administrator.  This deletion of the login
permits the login and uid to be reused immediately after the deletion.




















Willard                      Informational                       [Page 3]