Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 975243
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
Description of problem: It looks as though using "createTimestamp" as the "altstatenameattr" might be hardcoded (Rich confirmed in code): I removed altstatenameattr completely from my configuration and see the following in the errors log with plugin log level: --- acct-policy - acct_policy_start config: stateAttrName=lastLoginTime altStateAttrName=createTimestamp specAttrName=acctPolicySubentry limitAttrName=accountInactivityLimit alwaysRecordLogin=1 --- The config is still applying "altStateAttrName=createTimestamp" even though my account policy is set as follows: --- # ldapsearch -LLL -x -D cn='directory manager' -w redhat12 -b cn="Account Policy Plugin",cn=plugins,cn=config "cn=config" dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: config alwaysrecordlogin: yes stateattrname: lastLoginTime specattrname: acctPolicySubentry limitattrname: accountInactivityLimit --- Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create account lockout policy per section 14.5 of admin guide 2. Add new user to directory 3. Notice that there is no lastLoginTime attr on the user 4. Remove the altStateAttrName attribute from policy 5. Attempt to login with user *after* inactivity time has surpassed the value of the createTimestamp attr 6. Watch the login fail Actual results: Login does not succeed Expected results: Account logs in successfully and "lastLoginTime" attr is added to user Additional info:
There is also BZ 974361, which is also about Account Policy not working as expected
attachment 0001-Ticket-47395-47397-correct-behaviour-of-account-poli.patch
The problem with the patch is that it will break existing customers who expect the default behavior - silently fallback to using createTimestamp if lastLoginTime is not present. Instead, for people that want not fallback, they should specify that explicitly e.g.
altStateAttrName: 1.1
The LDAP attribute "1.1" is the "NULL" attribute - there isn't nor will ever be an attribute with that name or OID.
Then the logic would be something like this: {{{ newcfg->alt_state_attr_name = get_attr_string_val( e, CFG_ALT_LASTLOGIN_STATE_ATTR ); if( newcfg->alt_state_attr_name == NULL ) { newcfg->alt_state_attr_name = slapi_ch_strdup( DEFAULT_ALT_LASTLOGIN_STATE_ATTR ); } else if ( !strcmp( newcfg->alt_state_attr_name, "1.1" ) ) { slapi_ch_free_string( &newcfg->alt_state_attr_name ); / none - NULL / } / else use given value / }}}
ok, makes sense.
attachment 0001-Ticket-47395-47397-v2-correct-behaviour-of-account-p.patch
git merge bz974361 Updating 0c9e3b1..4aed9c6 Fast-forward ldap/servers/plugins/acctpolicy/acct_config.c | 13 ++++++++++++- ldap/servers/plugins/acctpolicy/acct_init.c | 2 +- ldap/servers/plugins/acctpolicy/acct_plugin.c | 18 +++++++++++++----- ldap/servers/plugins/acctpolicy/acct_util.c | 13 +++++++++++++ ldap/servers/plugins/acctpolicy/acctpolicy.h | 5 +++++ 5 files changed, 44 insertions(+), 7 deletions(-) $ git push origin master Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 2.39 KiB, done. Total 11 (delta 8), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 0c9e3b1..4aed9c6 master -> master
fix backported to 1.2.11, 1.3.0 and 1.3.1
389-ds-base-1.3.1 commit ce4e813 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 09:53:03 2013 -0600
389-ds-base-1.3.0 commit 2bd9ced Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 09:53:03 2013 -0600
389-ds-base-1.2.11 commit 12d47a2 Author: Rich Megginson rmeggins@redhat.com Date: Wed Jul 31 09:53:03 2013 -0600
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.2.11.22
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/732
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.