Network Managers Meeting

May 3, 2001

Authentication

Decision:

Most of the containers are very close to being fully clean. I have been asked to ask you about the blocking of these containers. Originally, we decided that if a container were not 100% compliant, we would block the container. Since we are so close and feel that the percentage of affected users should be low….we would like to consider that if a container were reasonable close to clean and currently working on it.. that we not block that container and actually let the problem occur. The Problem that may occur will affect the compliant as well as the non-compliant user. When one user collides with another user, both users are prevented from accessing GEM or Blackboard. A collision occurs when two users (could be the same user) are using the same username and it is visible through LDAP. We would wait for a call from the user having the problem and then contact the problem area and force a resolution. The group as a whole decided that containers should be blocked if non-compliant as documented.

Any user present in your container listed as a “Student” will be a problem.

Any user present in your container listed as a “Both” are potential problems, as we need to know which of the two accounts is the primary account for this person as there is a duplicate account in the Students.USC container.

A user listed as registered (employee, student, both) does not mean that your job is complete, you must verify that the entry in your container is the person that the mainframe believes that is. (Columns E & G on the spreadsheet sent to you)

Any user in your container listed as “Not Registered”: while they are not currently an issue, they are potential problems and the first user to register an username is the user that gets to keep it. – Creates collisions potentially -

Passwords:

Random passwords will be assigned to new user objects only. Passwords will not be changed for existing users.

If your user is present in your container and your container is not blocked then his password does not need to be reset – baring other problems such as a collision. But it will not harm the user if a reset and change is performed

We will be “preloading” as much information into the tree as we can in preparation of the full load later this month.

All faculty and staff, identified in the HR database, are being added to the University's "USC" NDS (Novell Directory Services) authentication system (the USC NDS Tree) over the weekend of May 19/20. During this time do not expect that GEM, Blackboard or VIP to operate consistently, please wait until Monday (5/21). If you are still experiencing a problem, please call 7-1800 for assistance.

We will take some form of action if an administrator fails to continue to maintain a “clean” container. – Administrators must a users registered name in accordance with the mainframe SingleID database and register unregistered user names. We will be continuing to monitor the tree for verification and compliance.

What you should anticipate:

The affect on usernames is based primarily on “Preferred Usernames” that are visible to the authentication system (LDAP) and in the USC NDS tree.

For student users (only students) – should work as normal no change for access to Blackboard and GEM.

For student users (both) – you have either deleted the account from your container or moved the user object to a “Filtered” (Blocked) container. User will continue to use the password that they are familiar with for Blackboard and GEM

For employee users (only employees) – if they already had a userid in the USC NDS tree and their container (that the id is in) is not blocked – the user should be able to use his NDS password for access to Blackboard and GEM. Otherwise, an account has been created for their usage and they must reset and change the password both access to Blackboard and GEM is granted

For employee users (both) – you have informed us of this and we have arranged for the deletion of the duplicate account in the student container. The user may begin using his current NDS password for access to Blackboard or GEM

NOTE: In the event, that a user does not work, it could be that a collision has occurred – we cannot return this error to the user in Blackboard or GEM; VIP will return a useful message, we will require the error message as returned by the system to resolve you problem. We will make every attempt to work with the parties that have created this problem to resolve this situation in a timely manner once the user reports the problem to us (creates a ticket).

VIP will show any user what their preferred username is. It will not show what additional usernames are associated with the user – you can view this through the SingleID web page. VIP will allow user to “reset” their password to their SSN and expires the password immediately. VIP/GEM will allow a user to change their password from a known password to a new password.

There is the possibility that we will have associated the wrong accounts with mainframe data; this is due to an administrator not completing the verification process.

If you need additional information or assistance please contact us.

Contact information:

Bill Crayton

Leonard McAbee

John Watson

Jerry Allen

Addendum A

Attributes that will be updated by the ID load program

Note: Any attribute that is not present will be added if applicable.

Standard User Attributes		Syntax
Full Name	Not overwritten if present	SYN_CI_STRING
Given Name	Not overwritten if present	SYN_CI_STRING
Login Disabled	Logins enabled for Mainframe created accounts only	SYN_BOOLEAN
Surname (Last Name)	Overwritten if different from Mainframe	SYN_CI_STRING
USC Specific User Attributes		Size
USC:USCStatus (*)	Record Status ([1]Student; [2]Employee; [3]Both; [4 or 5]Other	Byte
USC:NETIDStatus	ID Accessibility Status (Active, Inactive, Disabled, XAdministratively Disabled)	Byte
USC:School	School (of current major)	3 bytes
USC:Major	Major	4 bytes
USC:HomeDept	Department of Pay Origin (employees only)	5 bytes
USC:CurReg	Currently Registered Flag (*Y/N)*	Byte
USC:PreferredID	Is this the preferred id Flag	Byte
USC:NextActionDate	Date next status change to occur	8 bytes
USC:EntryDate	Date object created by mainframe	8 bytes
USC:ChangeDate	Date of last mainframe attribute change	8 bytes
USC:SecurityID	Current USC ID reference number	12 bytes
USC:PreviousID	Previous USC ID Reference number	12 bytes (multi valued)

Standard User Attributes

Syntax

USC Specific User Attributes

Size