#47395 DS still observes altStateAttrName as createTimestamp when attribute is removed from the account policy
Closed: wontfix None Opened 9 years ago by nkinder.

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:

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

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 /

git merge bz974361
Updating 0c9e3b1..4aed9c6
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

commit ce4e813
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jul 31 09:53:03 2013 -0600

commit 2bd9ced
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jul 31 09:53:03 2013 -0600

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:

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.