Changes between Initial Version and Version 1 of ALL__security_account_admin

Timestamp:

11/20/14 14:53:57 (10 years ago)

Author:

lttoth@…

Comment:

--

ALL__security_account_admin

@@ +1 @@
+20081103 elm          Directory Account Administration
+
+See also:
+
+        https://donnelly.alaska.edu/docs/LDAP/ALL__security
+        https://donnelly.alaska.edu/docs/LDAP/ALL__security_access_control
+
+The Enterprise Directory is utilized not just as an electronic white pages, it 
+is also utilized to authentication and in some cases authorize user access to 
+external applications.  The EDIR and AUTHSERV web gateways, MyUA and OnBase are 
+examples of external applications relying on directory authentication and 
+authorization.
+
+Directory records that can be used for authentication/authorization are those 
+associated with people or applications.  Records for people and applications 
+differ from other directory records in that they have passwords used in binding 
+to the directory (the ability to bind successfully to the directory results in 
+successful authentication).  People and application records reside in branches 
+of the directory clearly identifiable ou= in the RDN:
+
+        uid=*,ou=people,dc=alaska,dc=edu
+        uid=*,ou=resource,dc=alaska,dc=edu
+
+Because ou=people and ou=resource directory records can be used for directory 
+authentication, they are often referred to as "accounts".
+
+Additional branches of the directory exist to store other directory records 
+but those records are not associated with passwords and can not be used to 
+bind to the directory:
+
+        uid=*,ou=routing,dc=alaska,dc=edu
+        uid=*,ou=departments,dc=alaska,dc=edu
+        uid=*,ou=group,dc=alaska,dc=edu
+
+
+######################
+## Account Creation ##
+######################
+
+# ou=people
+
+Accounts for people are created via one of two mechanisms; the EDIR Banner Extract 
+process and the AUTHSERV sponsor_account CGI script/web page.  The vast majority 
+of people accounts originate from the Banner Extract and/or are tied to Banner 
+entities.  However, the web page for sponsoring accounts allows for the creation of 
+"guest" accounts; accounts that do not correspond to any Banner entity.
+
+Account sponsorship (including guest account creation) is ultimately performed at 
+the update back-end and only after first confirming that the requesting party is 
+entitled to sponsor accounts.
+
+# ou=resource
+
+Accounts utilized by applications are created only via the AUTHSERV seed_resource CGI
+script/web page.  Ultimately it is the update back-end which generates the resource 
+account after first confirming that the requesting party is entitled to request 
+resource account creation..
+
+
+#####################################
+## Account Activation/Inactivation ##
+#####################################
+
+# ou=people
+
+The presence of a password signifies that an account is active.  Prior to the advent
+of ELMO, a directory account could not be claimed, and user known password established,
+unless the account had first been activated (given a default password).  With the 
+advent of ELMO, an account need no longer be activated prior to claiming.  However, it 
+is still true that the old AUTHSERV form for account claiming - first_time - is 
+dependent on prior account activation.
+
+Accounts for people generated via the EDIR Banner Extract are created inactive.  
+Those accounts are claimed and given a user known password via the UAS written and 
+maintained ELMO interface:
+
+        https://elmo.alaska.edu
+
+Accounts for people generated via the AUTHSERV sponsor_account page are activated on 
+creation (i.e. given a default password).  The reason is based on the historical need 
+for an account to be activated before it could be claimed and the fact that accounts 
+being sponsored were expected to be claimed for the purpose of accessing external 
+applications. 
+
+        https://authserv.alaska.edu/cgi-bin/sponsor_account
+
+For the most part, these accounts too can be claimed via ELMO.  However, there are known 
+issues with claiming guest accounts via ELMO and those users are directed to use the old 
+AUTHSERV first_time page as an alternate method of account claiming:
+
+        https://authserv.alaska.edu/cgi-bin/first_time
+
+Accounts can be activated/inactivated by authorized staff using the AUTHSERV activate 
+CGI script/web page.
+
+        https://authserv.alaska.edu/cgi-bin/activate
+
+In addition, a nightly batch process looks for an inactivates directory accounts 
+previously activated but still unclaimed after 14 days.
+
+        ~iplanet/local/ldap/scripts/account_managementProd.ksh
+
+# ou=resource
+
+Application accounts are created inactive via the AUTHSERV seed resource CGI script/
+web page.
+
+        https://authserv.alaska.edu/cgi-bin/seed_resource
+
+An individual with shell access to the "e" boxes must activate application accounts 
+by generating and running a script that establishes a known password (using Directory 
+Manager credentials) and then changes that known password using the application account 
+credentials.  The same scripts are used to reset an application account password 
+should the password expire or be forgotten.  For that reason, the scripts are named 
+with a reset_ prefix.
+
+See ~iplanet/local/ldap/schema/RESET/ for examples of those scripts.
+
+NOTE: Application account passwords are set initially to expire in 2020.  
+
+
+#############################
+## Password Changes/Resets ##
+#############################
+
+# ou=people
+
+Account passwords for most people can be changed via the ELMO interface.  This is 
+true whether the password is active or has expired, is known or is unknown.  As 
+stated earlier about account claiming, some guest accounts will be unsuccessful 
+utilizing ELMO and will be directed to the old AUTHSERV password change or self 
+reset CGI scripts/web pages:
+
+        https://authservtest.alaska.edu/cgi-bin/passwd_chg
+        https://authservtest.alaska.edu/cgi-bin/self_reset
+        https://authservtest.alaska.edu/cgi-bin/post_reset
+
+When using the old AUTHSERV pages, the user either changes a known password or resets an 
+unknown/expired password.  When reset, passwords are set to a default value based on a 
+number and date (generally SSN and birthdate) supplied to the account creation process.  
+The post reset page prompts for that number and date and allows the user to establish a 
+new password.
+
+# ou=resource
+
+Application account passwords can be changed by the account holder only by using the old 
+EDIR change_passwd CGI script/web page.  Application account password changes result in a 
+standard 400 day expiration, not the 2020 expiration established when the account is first 
+activated.  It is the application account holder's responsibility to insure the password 
+is changed before expiration.  
+
+There is currently no mechanism by which an application accounts can perform a self reset 
+should a password expire or become forgotten.  Expired application account passwords must 
+be reset/changed by an individual with shell access to the "e" boxes where the "reset_" 
+scripts are maintained.
+
+
+#####################
+## Account Locking ## 
+#####################
+
+# ou=people 
+
+Accounts for either people or applications can be locked via the AUTHSERV lock and 
+administrative lock CGI scripts/web pages:
+
+        https://authservtest.alaska.edu/cgi-bin/lock
+        https://authservtest.alaska.edu/cgi-bin/admin_lock
+
+The difference between the two lock types is in the privilege necessary to add or remove 
+the lock.  Any one with the HelpDesk or EDIRadmin EDIRrole grants may establish or remove 
+a normal lock.  Only people with the EDIRadmin EDIRrole grant may establish or remove 
+an administrative lock.  The type of lock can be identified by the accountStatusFlag
+attribute:
+
+        accountStatusFlag=L     (regular lock, writable by HelpDesk or EDIRadmin EDIRrole)
+        accountStatusFlag=AL    (administrative lock, writable by EDIRadmin EDIRrole)
+
+Administrative locks are most likely placed on an account in the advent of a security action 
+which results in the immediate suspension of account access.
+
+# ou=resource
+
+Existing forms for locking accounts were designed to support locking of people accounts 
+and do not currently support the locking of application accounts.
+
+#######################
+DOCUMENT CHANGE HISTORY
+
+20081031 elm    corrected typos
+20081103 elm    added "See also:" section with links to other security related docs
+
+# eof