[[PageOutline(2-5,content)]] = Cookbook: AccountManagerPlugin configuration = commented sample configurations for common and special use cases We'll collect some useful configuration examples here to give hints on proper use of available options. == Basic configuration/Kickstart == === !HtPasswdStore === === !HtDigestStore === === !SessionStore === {{{ [components] acct_mgr.admin.* = enabled acct_mgr.api.* = enabled acct_mgr.db.sessionstore = enabled acct_mgr.htfile.htdigeststore = disabled acct_mgr.htfile.htpasswdstore = disabled acct_mgr.http.httpauthstore = disabled acct_mgr.notification.* = enabled acct_mgr.pwhash.htdigesthashmethod = enabled acct_mgr.pwhash.htpasswdhashmethod = disabled acct_mgr.svnserve.* = enabled acct_mgr.svnserve.svnservepasswordstore = disabled acct_mgr.web_ui.* = enabled trac.web.auth.loginmodule = disabled [account-manager] hash_method = HtDigestHashMethod password_store = SessionStore }}} Create the first user through browser-based registration enabled by following additional lines in `components` section of `trac.ini`: {{{ [components] acct_mgr.web_ui.RegistrationModule = enabled }}} Don't add another `components` section, just the configuration line with 'enabled' into an existing `components` section. After user creation you may choose to disable registration by uncommenting the [AccountManagerPlugin#RegistrationModule RegistrationModule] setting above or changing it to: {{{ [components] ;need this for first user acct_mgr.web_ui.RegistrationModule = disabled }}} Or just use the plugins admin page form Trac's web interface, after you've given admin priviledges to the first user you created. === Award an existing user account for Trac admin === {{{ trac-admin /path/to/env permission add TRAC_ADMIN permission list }}} === Goodies === There are some misc options for `account-manager` section of `trac.ini` you may want to set/unset depending on your requirements: ||'''Option'''||'''Default Value'''||'''Recommendation'''||'''Available Since'''|| ||reset_password || True ||Disallow password reset if needed. ||acct_mgr-0.? || ||generated_password_length ||8 ||Useful only with reset enabled. Raise the bar for brute-force attacks on user passwords, if you feel this is needed. [AccountManagerPlugin#AccountGuard AccountGuard] might still be a more powerful alternative, see [#AccountLocking Account Locking] section below. ||acct_mgr-0.? || ||force_passwd_change ||True ||Useful only with reset enabled. Randomly generated passwords should be motivation enough to change them, but YMMV.||acct_mgr-0.? || == Advanced configurations == === Password Reset === === Account Locking === * new feature for acct_mgr-0.3 * available options (displayed with default values here): {{{ [components] acct_mgr.guard.accountguard = enabled }}} {{{ [account-manager] login_attempt_max_count = 0 user_lock_time = 0 user_lock_max_time = 86400 user_lock_time_progression = 1 }}} ==== Hard Lock-up ==== {{{ [account-manager] login_attempt_max_count = 5 user_lock_time = 0 }}} will have following effect: * lock account after 5 successive failed login attempts * no lock expiration, so release strictly requires administrator interaction ==== Fixed login delay ==== {{{ [account-manager] login_attempt_max_count = 3 user_lock_time = 30 }}} will have following effect: * lock account after 3 successive failed login attempts * timed account locked release 30 seconds after last failed login attempt * fixed delay time regardless of number of successive failed login attempts ==== Modestly progressing login delay ==== {{{ [account-manager] login_attempt_max_count = 2 user_lock_time = 15 user_lock_max_time = 0 user_lock_time_progression = 2 }}} will have following effect: * first account lock after 2 successive failed login attempts * timed account locked release after a time, that depends on failed login attempt history like so: Tab.: lock time progression (factor 2) ||attempt count ||delay time in seconds ^[1]^|| ||0 ||0 ||1 ||1 s || ||2 ||15 s || ||3 ||30 s || ||4 ||60 s || ||5 ||2 min || ||6 ||4 min || ||7 ||8 min || ||8 ||16 min || ||9 ||32 min || ||10 ||1h 4 min || ||.. ||.. || ||18 ||1 d 12 h 25 min|| ||.. ||.. || ||26 ||1 a 23 d || ||.. ||.. || ^[1]^ time after previous failed login attempt ==== Aggressively progressing, but limited login delay ==== {{{ [account-manager] login_attempt_max_count = 4 user_lock_time = 10 user_lock_max_time = 86400 user_lock_time_progression = 5 }}} will have following effect: * first account lock after 4 successive failed login attempts * timed account locked release after a time, that depends on failed login attempt history and is limited to max. 24 hours like so: Tab.: lock time progression (factor 2) ||attempt count ||delay time in seconds || ||0 ||0 || ||1 ||10 s || ||2 ||25 s || ||3 ||2 min 5 s || ||4 ||10 min 25 s || ||5 ||4 h 20 min || ||6 ||21 h 42 min || ||7 ||24 h ^[2]^|| ||8 ||24 h || ||9 ||24 h || ||.. ||.. || ^[2]^ limit kicking in here and an any further attempt