Changes between Version 1 and Version 2 of ALL__security_account_admin
- Timestamp:
- 11/20/14 15:58:10 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ALL__security_account_admin
v1 v2 1 20081103 elm Directory Account Administration 1 = Directory Account Administration = 2 Original Author: Beth Mercer - 20081103 2 3 3 4 See also: 4 5 5 https://donnelly.alaska.edu/docs/LDAP/ALL__security6 https://donnelly.alaska.edu/docs/LDAP/ALL__security_access_control6 [[ALL__security| Directory Related Security]] 7 [[ALL__security_access_control| EDIR/AUTHSERV Access Control]] 7 8 8 9 The Enterprise Directory is utilized not just as an electronic white pages, it 9 10 is also utilized to authentication and in some cases authorize user access to 10 external applications. The EDIR and AUTHSERV web gateways, MyUA and OnBase are 11 examples of external applications relying on directory authentication and 12 authorization. 11 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. 13 12 14 13 Directory records that can be used for authentication/authorization are those … … 16 15 differ from other directory records in that they have passwords used in binding 17 16 to the directory (the ability to bind successfully to the directory results in 18 successful authentication). People and application records reside in branches 17 successful authentication). 18 19 People and application records reside in branches 19 20 of the directory clearly identifiable ou= in the RDN: 20 21 21 uid=*,ou=people,dc=alaska,dc=edu22 uid=*,ou=resource,dc=alaska,dc=edu22 * uid=*,ou=people,dc=alaska,dc=edu 23 * uid=*,ou=resource,dc=alaska,dc=edu 23 24 24 25 Because ou=people and ou=resource directory records can be used for directory … … 29 30 bind to the directory: 30 31 31 uid=*,ou=routing,dc=alaska,dc=edu32 uid=*,ou=departments,dc=alaska,dc=edu33 uid=*,ou=group,dc=alaska,dc=edu32 * uid=*,ou=routing,dc=alaska,dc=edu 33 * uid=*,ou=departments,dc=alaska,dc=edu 34 * uid=*,ou=group,dc=alaska,dc=edu 34 35 35 36 36 ###################### 37 ## Account Creation ## 38 ###################### 37 == Account Creation == 39 38 40 # ou=people 41 39 === ou=people === 42 40 Accounts for people are created via one of two mechanisms; the EDIR Banner Extract 43 41 process and the AUTHSERV sponsor_account CGI script/web page. The vast majority … … 50 48 entitled to sponsor accounts. 51 49 52 # ou=resource 53 50 === ou=resource === 54 51 Accounts utilized by applications are created only via the AUTHSERV seed_resource CGI 55 52 script/web page. Ultimately it is the update back-end which generates the resource … … 58 55 59 56 60 #####################################61 ## Account Activation/Inactivation ##62 #####################################63 57 64 # ou=people 58 == Account Activation/Inactivation == 65 59 60 === ou=people === 66 61 The presence of a password signifies that an account is active. Prior to the advent 67 62 of ELMO, a directory account could not be claimed, and user known password established, … … 71 66 dependent on prior account activation. 72 67 68 ==== Banner Generated Account Activation ==== 73 69 Accounts for people generated via the EDIR Banner Extract are created inactive. 74 70 Those accounts are claimed and given a user known password via the UAS written and … … 77 73 https://elmo.alaska.edu 78 74 75 ==== Sponsored Account Activation ==== 79 76 Accounts for people generated via the AUTHSERV sponsor_account page are activated on 80 77 creation (i.e. given a default password). The reason is based on the historical need … … 85 82 https://authserv.alaska.edu/cgi-bin/sponsor_account 86 83 87 For the most part, these accounts too can be claimed via ELMO. However, there are known88 issues with claiming guest accounts via ELMO and those users are directed to use the old 89 AUTHSERV first_time page as an alternate method of account claiming:84 For the most part, these accounts too can be claimed via ELMO. 85 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: 90 87 91 88 https://authserv.alaska.edu/cgi-bin/first_time 92 89 90 ==== Using AUTHSERV scripts for Activation ==== 93 91 Accounts can be activated/inactivated by authorized staff using the AUTHSERV activate 94 92 CGI script/web page. … … 101 99 ~iplanet/local/ldap/scripts/account_managementProd.ksh 102 100 103 # ou=resource 101 === ou=resource === 104 102 105 103 Application accounts are created inactive via the AUTHSERV seed resource CGI script/ … … 117 115 See ~iplanet/local/ldap/schema/RESET/ for examples of those scripts. 118 116 119 NOTE:Application account passwords are set initially to expire in 2020.117 ''NOTE:'' Application account passwords are set initially to expire in 2020. 120 118 119 == Password Changes & Resets == 121 120 122 ############################# 123 ## Password Changes/Resets ## 124 ############################# 125 126 # ou=people 121 === ou=people === 127 122 128 123 Account passwords for most people can be changed via the ELMO interface. This is … … 142 137 new password. 143 138 144 # ou=resource 139 === ou=resource === 145 140 146 141 Application account passwords can be changed by the account holder only by using the old … … 155 150 scripts are maintained. 156 151 152 == Account Locking == 157 153 158 ##################### 159 ## Account Locking ## 160 ##################### 161 162 # ou=people 154 === ou=people === 163 155 164 156 Accounts for either people or applications can be locked via the AUTHSERV lock and … … 174 166 attribute: 175 167 176 accountStatusFlag=L (regular lock, writable by HelpDesk or EDIRadmin EDIRrole)177 accountStatusFlag=AL (administrative lock, writable by EDIRadmin EDIRrole)168 accountStatusFlag=L : regular lock, writable by HelpDesk or EDIRadmin EDIRrole 169 accountStatusFlag=AL : administrative lock, writable by EDIRadmin EDIRrole 178 170 179 171 Administrative locks are most likely placed on an account in the advent of a security action 180 172 which results in the immediate suspension of account access. 181 173 182 # ou=resource 174 === ou=resource === 183 175 184 176 Existing forms for locking accounts were designed to support locking of people accounts 185 177 and do not currently support the locking of application accounts. 186 178 187 ####################### 188 DOCUMENT CHANGE HISTORY 179 ########################################################[[br]] 180 LEGACY CHANGE HISTORY - NOTE: All subsequent changes are recorded in TracWiki 181 ########################################################[[br]] 189 182 190 183 20081031 elm corrected typos 191 184 20081103 elm added "See also:" section with links to other security related docs 192 185 193 # eof