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 Management
Legacy AUTHSERV functions are in some cases still in place, but rarely, if ever used. Account creation functions have been shifted to Banner and an automated feed to EDIR LDAP. Account Claiming, activation, and password management has shifted to ELMO. De-activation of accounts has been replaced by removing permissions and roles, effectively prohibiting users from accessing those functions and systems for which they should no longer have access.
Each AUTHSERV function and its corresponding script or URL invocation is discussed below.
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. The act of claiming an account through ELMO activates the account.
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 are expected to be claimed for the purpose of accessing external applications. Sponsored accounts are managed via the following link:
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 may still include using the AUTHSERV first_time page as an alternate method of account claiming via the following URL:
Using AUTHSERV scripts for Activation
ou=people
In a review of the AUTH<instance> source code, it appears that accounts can still be activated/inactivated by authorized staff using the AUTHSERV activate CGI script/web page. In practice, that procedure is not used by Help Desk Staff. The corresponding URL is:
In addition, a nightly batch process looks for an inactivates directory accounts previously activated but still unclaimed after 14 days by executing the following script;
~iplanet/local/ldap/scripts/account_managementProd.ksh
ou=resource
Application accounts are created inactive via the AUTHSERV seed resource CGI script/ web page:
In the past, an individual with shell access to the "e" boxes activated application accounts by generating and running a script that establishes a known password (using Directory Manager credentials) and then changed that known password using the application account credentials. Today, the resource account is created without setting a password when seeded.
However, the legacy script remain and 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.
Account Locking
ou=people
Accounts for either people or applications can be locked via the AUTHSERV lock and administrative lock CGI scripts/web pages:
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.
Password Management
Although the password management scripts are still present on "E" boxes, they only change the EDIR LDAP password. All authentication to University of Alaska applications and services is managed through ELMO and validated by both AD and EDIR. Their is one case where passwords are reset local to EDIR only. There are times when inexplicably the Active Directory password and the EDIR password become out of sync (even if they ar ethe same password) and users can not access servers to set up EDUROAM, e.g. At that time, the reset capability is used so that synchronization is flagged as needed. This triggers the synchronization.
Otherwise, these scripts and URLs are not used.
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 may 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
However, these will only trigger the need for password synchronization Generally, these functions are exercised now by the Help Desk to assist users.
In the past, when using the old AUTHSERV pages, the user either changed a known password or reset an unknown/expired password. When reset, passwords were 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 prompted for that number and date and allowed 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.
########################################################
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
