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
