#47397 Account policy plugin fails to lock user when policy is created for individual users to lock based to createtimestamp.
Closed: wontfix None Opened 10 years ago by nkinder.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 974361

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Account policy plugin fails to lock user when policy is created for individual
users to lock based to createtimestamp.

Issue
Account policy plugin fails to lock user when policy is created for individual
users to lock based to createtimestamp.
Customer wants to lock users based on createtimestamp, He has a some group of
users which should get blocked after x days of creation. Each group has
different accountInactivityLimit time.

Steps to Reproduce:
1. Configure account policy plugin.

dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: no
stateattrname: createTimestamp
altstateattrname: createTimestamp
specattrname: acctPolicySubentry
limitattrname: accountInactivityLimit
accountInactivityLimit: 600000

2. configure cos entries for different group of users.

dn: cn=AccountPolicy,dc=example,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: extensibleObject
objectClass: accountpolicy
accountInactivityLimit: 200
cn: AccountPolicy

dn: cn=AccountPolicy1,dc=example,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: extensibleObject
objectClass: accountpolicy
accountInactivityLimit: 400
cn: AccountPolicy1

dn: cn=AccountPolicy2,dc=example,dc=com
objectClass: top
objectClass: ldapsubentry
objectClass: extensibleObject
objectClass: accountpolicy
accountInactivityLimit: 600
cn: AccountPolicy2

# u1, People, example.com
dn: uid=u1,ou=People,dc=example,dc=com
acctpolicysubentry: cn=AccountPolicy,dc=example,dc=com

# u2, People, example.com
dn: uid=u2,ou=People,dc=example,dc=com
acctpolicysubentry: cn=AccountPolicy1,dc=example,dc=com

# u3, People, example.com
dn: uid=u3,ou=People,dc=example,dc=com
acctpolicysubentry: cn=AccountPolicy2,dc=example,dc=com

Actual results:
Users are not getting locked.

Expected results:
Users should get locked.

Additional info:
With configuration like above, binding using a user updates createtimestamp
instead of lastlogintime.

dn: uid=u2,ou=People,dc=example,dc=com
createtimestamp: 20130512000015Z

If I configure it like below, i.e. To block users with lastlogintime &
createtimestamp but configure lastlogintime to not update, then too binding a
user updates lastlogintime & user disable post-porns.

dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: no
stateattrname: lastlogintime
altstateattrname: createTimestamp
specattrname: acctPolicySubentry
limitattrname: accountInactivityLimit
accountInactivityLimit: 600000

fixed together with ticket 47395, patch provided there: https://fedorahosted.org/389/ticket/47395

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

7 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/734

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)

3 years ago

Login to comment on this ticket.

Metadata