| Version 1 (modified by lttoth@…, 10 years ago) (diff) |
|---|
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:
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.
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:
Accounts can be activated/inactivated by authorized staff using the AUTHSERV activate CGI script/web page.
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.
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
