EDIR Account Management Processes and Associated Utilities

Account Creation

Creating an account generates a new EDIR LDAP record.

REGISTRY: EDIR Banner Extract (includes restore of previously purged entities)

employees with active assigments

students with current or preenrolled credit hours

AUTHSERV: Sponsor Account Page

Banner entities with recorded SSN not qualifying for EDIR Banner Extract (seed information must tie to Banner on SSN and birth date;

identical input ties to only one or no Banner entities, if multiples matches found, no EDIR record is created)

guest accounts (seed information never tied to Banner;

identical input generates multiple unique guest accounts)

Note: Birth date being added to matching criteria. Currently matching to Banner only on SSN.

Account Activation

Account activation establishes a default password, i.e., the presence of password signifies an "active" account.

Note: EDIR accounts are created with out passwords because we have not had the opportunity to create a robust account claiming page based on highly privileged information only the user is likely to know. Our "First Time" login page (sometimes refered to as account claiming) requires only that you know the users identifier (UID, UAUsername or UAUserID), last 4 of ssn and birth date. Those pieces of information are readily available to many people.

AUTHSERV/EDIR: Bulk Update Page

activate and silent activate functions (activate establishes default password only if password *not* already present)

reset and silent reset functions (including "trusted" form of function) (reset establishes default password whether or not password already present) (trusted reset clears password history first)

Notes: 1) The "silent" functionality was for UAA which did not want it's users receiving AUTHSERV/EDIR notifications. The non-silent versions will, under the appropriate circumstances, notify the user of the account activation or password reset.

2) The "trusted" functionality was implemented in support of support of (MAU)->AUTHSERV password synchronization (see Password Synchronization below).

AUTHSERV: Account Activation Page

calls bulk update page for noisy activate function

AUTHSERV: Password Reset Page

calls bulk update for noisy reset function

Account Inactivation

IInactivating an account removed passwords, so the absence of passwords signifies an "inactive" account).

AUTHSERV/EDIR: Bulk Update Page

purge attribute function for userPassword (removes userPassword, making account "inactive")

AUTHSERV: Account Activation Page

calls bulk update to purge userPassword

Account Claiming

EDIR, unlike ELMO, has the notion of claiming an account by changing the password from default to a user chosen password..

AUTHSERV: First Time Login Page

calls bulk update update function with default and new userPassword values (must successfully answer weak challenge questions)

Note: See note concerning Account Activation.

AUTHSERV: Log In with Password Change Page

calls bulk update update function with old (default) and new userPassword values

Account Locking/Unlocking?

AUTHSERV: Account Lock Page AUTHSERV: Administrative Lock Page

both call bulk update lock/unlock function (executes iPlanet ns-[in]activate script which enables/prevents directory BINDs;

writes/removes accountStatusFlag attribute value indicating type of lock)

accountStatusFlag=L (regular lock) accountStatusFlag=AL (admin lock)

Note: Only individuals with EDIRadmin role can add/remove administrative locks. The reason for the 2 types of locks originates from ZUAUSR in which a user might request his account be locked (as during sabatical - regular lock) or an administrative security action might be taken (prevent the user from having Oracle/UNIX access - admin lock).

Password Resets

AUTHSERV: Password Reset Page

calls bulk update for noisy reset function

AUTHSERV: Self Reset Page

calls bulk update for noisy reset function (must successfully complete private challenge/response dialog)

Password Changes

AUTHSERV: First Time Login Page AUTHSERV: Post Reset Login Page

calls bulk update update function with default and new userPassword values (must successfully answer weak challenge questions)

Note: See note concerning Account Activation.

AUTHSERV: Log In with Password Change Page

calls bulk update update function with old (default) and new userPassword values

Password Expiration Warning

AUTHSERV: (following successful authentication - MAU "style" specific behavior)

REGISTRY: Account Management Process

looks for passwords about to expire and unclaimed accounts (unclaimed: default password present 14 days after default password established) sends email warning, if mailRoutingAddress present, 14, 7, 3 and 1 days prior to password expiration calls bulk update purge function to inactivate (delete userPassword for) unclaimed accounts

Directory Purges

REGISTRY: Directory Purge Process

generates ldapdelete statements to drop the directory records for registry records with a record state of "BAD" or "INACTIVE"

Note: EDIR registry "record state" and EDIR directory account state are two different things. Registry record state is used to regulate account lifecyle. EDIR account state indicates whether or not a password is present and if the user is allowed to BIND to the directory.

Password Syncronization

Formerly, password synchronization occurred when via a password push received clear text value for new password. ELMO now handles all Banner active accounts. The AUTHSERV interface manages guest passwords, only.

UAA->AUTHSERV UAS(ELMO)->AUTHSERV

UAA and UAS have been granted resource credentials with helpDesk, passwordSync and twoStepBind EDIR roles. These credentials and their administrative access are used to push their MAU specific password down to our directory.

The password push is a three step process:

1) Resource credentials are used to reset userPassword to it's default value. This is done by calling the bulk update trusted reset function. During a trusted reset, passwordHistory is cleared to insure differences in recorded historys do not prevent the directory from accepting an otherwise good password.

2) Resource credentials are used to look up defaultPassword which is used in step 3.

3) The account holder's credentials (UID and defaultPassword) are used during call to the bulk update update function with old (default) and new userPassword values.

AUTHSERV->UAS(ELMO)

UAS has created a restricted access web page that can be called to push a new directory password to UAS. AUTHSERV calls this web page only on completion of a successful password *change* and only if the change request does not originate from the UAS->AUTHSERV password process. The call to the UAS web page is "blind"; we don't care if it fails and no status is returned to the end user.

Since all password changes (not resets) must be made as the account owner, we could not use the UAS resource credentials to identify when the UAS push process had originated the request. Instead, UAS has provided us with an IP/domain list to exclude from AUTHSERV->UAS password synchronization. Requests originating from those IPs/domains are assumed to have originated from the UAS(ELMO)->AUTHSERV synchronization. This prevents us from getting into a password change loop.

The AUTHSERV->(MAU) push process is designed to be extensible and so is parameter driven. The password push to UAS can be modified by editing UAS specific configuration parameters in "e":~ldapgw/AUTHPROD/config/runtime.cfg. Likewise, a push to UAA could be implemented by adding UAA specific configuration parameters to the same config file.

Note: The runtime.cfg file resides on each "e" box. AUTHSERV->(MAU) password push parameters must be added to runtime.cfg on every "e" box.

########################################################
LEGACY CHANGE HISTORY - NOTE: All subsequent changes are recorded in TracWiki
########################################################

20081028 elm Expanded on processes for disabling updates particularly since change that allows userPassword, uakSecQuestion and uakSecResponse updates to bypass the registry.
20081031 elm corrected typos 20070815 sxelm updated to include password synchronization 20070814 sxelm original doc