Changes between Version 5 and Version 6 of ALL__security_account_admin
- Timestamp:
- 11/24/14 14:45:40 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ALL__security_account_admin
v5 v6 35 35 36 36 37 == Account Creation == 37 == Account Management == 38 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. 38 39 39 === ou=people === 40 Each AUTHSERV function and its corresponding script or URL invocation is discussed below. 41 42 === Account Creation === 43 44 ==== ou=people ==== 40 45 Accounts for people are created via one of two mechanisms; the EDIR Banner Extract 41 46 process and the AUTHSERV sponsor_account CGI script/web page. The vast majority … … 48 53 entitled to sponsor accounts. 49 54 50 === ou=resource===55 ==== ou=resource ==== 51 56 Accounts utilized by applications are created only via the AUTHSERV seed_resource CGI 52 57 script/web page. Ultimately it is the update back-end which generates the resource 53 58 account after first confirming that the requesting party is entitled to request 54 resource account creation. .59 resource account creation. 55 60 61 === Account Activation & Inactivation === 56 62 57 58 == Account Activation & Inactivation == 59 60 === ou=people === 63 ==== ou=people ==== 61 64 The presence of a password signifies that an account is active. Prior to the advent 62 65 of ELMO, a directory account could not be claimed, and user known password established, 63 66 unless the account had first been activated (given a default password). With the 64 advent of ELMO, an account need no longer be activated prior to claiming. However, it 65 is still true that the old AUTHSERV form for account claiming - first_time - is 66 dependent on prior account activation. 67 advent of ELMO, an account need no longer be activated prior to claiming. The act of claiming an account through ELMO activates the account. 67 68 68 69 ==== Banner Generated Account Activation ==== … … 77 78 creation (i.e. given a default password). The reason is based on the historical need 78 79 for an account to be activated before it could be claimed and the fact that accounts 79 being sponsored were expected to be claimed for the purpose of accessing external80 applications. 80 being sponsored are expected to be claimed for the purpose of accessing external 81 applications. Sponsored accounts are managed via the following link: 81 82 82 83 https://authserv.alaska.edu/cgi-bin/sponsor_account … … 84 85 For the most part, these accounts too can be claimed via ELMO. 85 86 86 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:87 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: 87 88 88 89 https://authserv.alaska.edu/cgi-bin/first_time 89 90 90 91 ==== Using AUTHSERV scripts for Activation ==== 91 Accounts can be activated/inactivated by authorized staff using the AUTHSERV activate 92 CGI script/web page. 92 ===== ou=people ===== 93 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 94 CGI script/web page. In practice, that procedure is not used by Help Desk Staff. The corresponding URL is: 93 95 94 96 https://authserv.alaska.edu/cgi-bin/activate 95 97 96 98 In addition, a nightly batch process looks for an inactivates directory accounts 97 previously activated but still unclaimed after 14 days .99 previously activated but still unclaimed after 14 days by executing the following script; 98 100 99 101 ~iplanet/local/ldap/scripts/account_managementProd.ksh 100 102 101 === ou=resource===103 ===== ou=resource ===== 102 104 103 105 Application accounts are created inactive via the AUTHSERV seed resource CGI script/ 104 web page .106 web page: 105 107 106 108 https://authserv.alaska.edu/cgi-bin/seed_resource 107 109 108 An individual with shell access to the "e" boxes must activateapplication accounts110 In the past, an individual with shell access to the "e" boxes activated application accounts 109 111 by generating and running a script that establishes a known password (using Directory 110 Manager credentials) and then changes that known password using the application account 111 credentials. The same scripts are used to reset an application account password 112 Manager credentials) and then changed that known password using the application account 113 credentials. Today, the resource account is created without setting a password when seeded. 114 115 However, the legacy script remain and the same scripts are used to reset an application account password 112 116 should the password expire or be forgotten. For that reason, the scripts are named 113 117 with a reset_ prefix. … … 117 121 ''NOTE:'' Application account passwords are set initially to expire in 2020. 118 122 119 == Password Changes & Resets ==123 === Account Locking == = 120 124 121 === ou=people === 122 123 Account passwords for most people can be changed via the ELMO interface. This is 124 true whether the password is active or has expired, is known or is unknown. As 125 stated earlier about account claiming, some guest accounts will be unsuccessful 126 utilizing ELMO and will be directed to the old AUTHSERV password change or self 127 reset CGI scripts/web pages: 128 129 * https://authservtest.alaska.edu/cgi-bin/passwd_chg 130 * https://authservtest.alaska.edu/cgi-bin/self_reset 131 * https://authservtest.alaska.edu/cgi-bin/post_reset 132 133 When using the old AUTHSERV pages, the user either changes a known password or resets an 134 unknown/expired password. When reset, passwords are set to a default value based on a 135 number and date (generally SSN and birthdate) supplied to the account creation process. 136 The post reset page prompts for that number and date and allows the user to establish a 137 new password. 138 139 === ou=resource === 140 141 Application account passwords can be changed by the account holder only by using the old 142 EDIR change_passwd CGI script/web page. Application account password changes result in a 143 standard 400 day expiration, not the 2020 expiration established when the account is first 144 activated. It is the application account holder's responsibility to insure the password 145 is changed before expiration. 146 147 There is currently no mechanism by which an application accounts can perform a self reset 148 should a password expire or become forgotten. Expired application account passwords must 149 be reset/changed by an individual with shell access to the "e" boxes where the "reset_" 150 scripts are maintained. 151 152 == Account Locking == 153 154 === ou=people === 125 ==== ou=people ==== 155 126 156 127 Accounts for either people or applications can be locked via the AUTHSERV lock and … … 174 145 which results in the immediate suspension of account access. 175 146 176 === ou=resource===147 ==== ou=resource ==== 177 148 178 149 Existing forms for locking accounts were designed to support locking of people accounts 179 150 and do not currently support the locking of application accounts. 151 152 == Password Management == 153 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. 154 155 Otherwise, these scripts and URLs are not used. 156 ==== ou=people ==== 157 158 Account passwords for most people can be changed via the ELMO interface. This is 159 true whether the password is active or has expired, is known or is unknown. As 160 stated earlier about account claiming, some guest accounts will be unsuccessful 161 utilizing ELMO and may be directed to the old AUTHSERV password change or self 162 reset CGI scripts/web pages: 163 164 * https://authservtest.alaska.edu/cgi-bin/passwd_chg 165 * https://authservtest.alaska.edu/cgi-bin/self_reset 166 * https://authservtest.alaska.edu/cgi-bin/post_reset 167 168 However, these will only trigger the need for password synchronization Generally, these functions are exercised now by the Help Desk to assist users. 169 170 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 171 new password. 172 173 ==== ou=resource ==== 174 175 Application account passwords can be changed by the account holder only by using the old 176 EDIR change_passwd CGI script/web page. Application account password changes result in a 177 standard 400 day expiration, not the 2020 expiration established when the account is first 178 activated. It is the application account holder's responsibility to insure the password 179 is changed before expiration. 180 181 There is currently no mechanism by which an application accounts can perform a self reset 182 should a password expire or become forgotten. Expired application account passwords must 183 be reset/changed by an individual with shell access to the "e" boxes where the "reset_" 184 scripts are maintained. 185 180 186 181 187 ########################################################[[br]]
