| Version 4 (modified by lttoth@…, 9 years ago) (diff) |
|---|
Directory Account Administration
Original Author: Beth Mercer - 20081103
See also:
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 are examples of applications relying on directory authentication while OnBase? and Shibboleth exemplify relying on directory attributes.
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.
Banner Generated 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:
Sponsored Account Activation
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.
If there is an issue with claiming the sponsored account for any reason using ELMO, a backup plan includes using the AUTHSERV first_time page as an alternate method of account claiming:
Using AUTHSERV scripts for Activation
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.
########################################################
LEGACY CHANGE HISTORY - NOTE: All subsequent changes are recorded in TracWiki
########################################################
20081031 elm corrected typos 20081103 elm added "See also:" section with links to other security related docs
