Changes between Initial Version and Version 1 of LDAP_acct_mgmt

Timestamp:

02/04/15 17:10:01 (11 years ago)

Author:

lttoth@…

Comment:

--

LDAP_acct_mgmt

@@ +1 @@
+= 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.
+
+########################################################[[br]]
+LEGACY CHANGE HISTORY - NOTE: All subsequent changes are recorded in TracWiki[[br]]
+########################################################[[br]]
+
+20081028 elm    Expanded on processes for disabling updates particularly since change that allows userPassword, uakSecQuestion and uakSecResponse updates to bypass the registry.[[br]]
+20081031 elm    corrected typos
+20070815 sxelm updated to include password synchronization
+20070814 sxelm original doc