I apologize for taking so long with this. I got side tracked and this fell to the back burner. I'll try and get you the dse.ldif file in the next day or so. In the mean time, I did see that a user logged in 3 times incorrectly and got accountUnlockTime set to 20150225212354Z, which was almost 6 hours in the future. Why would this be when I have our set up set to lock out for 30 minutes? Shouldn't it have been, if it locked at 20150225154500Z, set to 201502251615Z? Thanks, Harry -----Original Message----- From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of German Parente Sent: Friday, February 20, 2015 4:11 AM To: General discussion list for the 389 Directory server project. Subject: Re: Question about accountunlocktime ----- Original Message ----- > From: "harry devine" <harry.devine@xxxxxxx> > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Thursday, 19 February, 2015 9:10:56 PM > Subject: Re: Question about accountunlocktime > > I'm sorry I haven't gotten back sooner. I turned on the audit log and > have been monitoring it. I never see accountunlocktime get set, but I > know that I've had people not be able to log in, and in those cases, > they've always had some value in accountunlocktime. What I do to > "unlock" them is to You mean is that a user that had no "accountlocktime" attribute in its entry, after N failed logins, it arrives to have the attribute but this operation never appeared in the audit log ? > delete that attribute as well as the passwordRetryCount. Again, I was > under Only the latest is needed to unlock it. > the impression that once the user gets locked because of too many > failed attempts, it will unlock itself based on the > passwordLockoutDuration. In my case, this isn't working, but I don't really know how else I can prove it. > Could you send me your dse.ldif to my email address ? Thanks and regards, German. > Thanks, > Harry > > -----Original Message----- > From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx > [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of German > Parente > Sent: Wednesday, February 18, 2015 9:28 AM > To: General discussion list for the 389 Directory server project. > Subject: Re: Question about accountunlocktime > > > > ----- Original Message ----- > > From: "harry devine" <harry.devine@xxxxxxx> > > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > Sent: Wednesday, 18 February, 2015 2:35:37 PM > > Subject: Re: Question about accountunlocktime > > > > Not a problem. I looked at my settings, and the only thing that is > > different on those settings you gave was passwordChange is set to on > > for me, where yours is off. I also didn't have the audit log > > enabled, so I just enabled it and I'm going to monitor it for a > > while and see what happens. But what I can't figure out is why your > > setup works and mine doesn't. > > > > hi Harry, > > passwordChange is not related to account lock but to the ability to > change passwords by user itself. > > However, I have also tested with "passwordChange: on" and it's also > working for me. > > Could you please send the exact message you see to realize account is > still locked ? > > Thanks and regards, > > German. > > > Thanks, > > Harry > > > > -----Original Message----- > > From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx > > [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of > > German Parente > > Sent: Tuesday, February 17, 2015 9:36 AM > > To: General discussion list for the 389 Directory server project. > > Subject: Re: Question about accountunlocktime > > > > Hi Harry, > > > > sorry for long delay. The feature it working quite well for me. > > > > For instance, user0 binding three times with wrong password is locked: > > > > [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D > > "cn=user0,ou=people,o=redhat" -w wrong -b "o=redhat" cn=user0 > > ldap_bind: Invalid credentials (49) > > [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D > > "cn=user0,ou=people,o=redhat" -w wrong -b "o=redhat" cn=user0 > > ldap_bind: Invalid credentials (49) > > [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D > > "cn=user0,ou=people,o=redhat" -w wrong -b "o=redhat" cn=user0 > > ldap_bind: Invalid credentials (49) > > [root@rh6 ~]# ldapsearch -p 1389 -h localhost -D > > "cn=user0,ou=people,o=redhat" -w wrong -b "o=redhat" cn=user0 > > ldap_bind: Constraint violation (19) > > additional info: Exceed password retry limit. Please try later. > > > > I can see in audit logs after the third wrong bind: > > > > time: 20150217151208 > > dn: cn=user0,ou=people,o=redhat > > changetype: modify > > replace: passwordRetryCount > > passwordRetryCount: 3 > > - > > replace: accountUnlockTime > > accountUnlockTime: 20150217141508Z > > > > > > If I try to bind with right credentials: > > > > ldapsearch -p 1389 -h localhost -D "cn=user0,ou=people,o=redhat" -w > > user0 -b "o=redhat" cn=user0 > > ldap_bind: Constraint violation (19) > > additional info: Exceed password retry limit. Please try later. > > > > > > NOTE: in my case, passwordLockoutDuration: 180 > > > > So, more than three minutes later: > > > > ldapsearch -xLLL -p 1389 -h localhost -D > > "cn=user0,ou=people,o=redhat" -w > > user0 -b "o=redhat" cn=user0 > > [root@rh6 ~]# > > > > user0 arrives to bind ok. > > > > We can see in audit logs that the password retry count has been > > reset'd (we check accounts locked only if the retry count is greater > > than the max failures allowed). > > > > time: 20150217151719 > > dn: cn=user0,ou=people,o=redhat > > changetype: modify > > replace: passwordRetryCount > > passwordRetryCount: 0 > > - > > > > My settings: > > > > nsslapd-pwpolicy-local: on > > passwordChange: off > > passwordLockout: on > > passwordUnlock: on > > passwordLockoutDuration: 180 > > passwordResetFailureCount: 660 > > > > and > > > > passwordmaxfailure: 3 > > > > > > Thanks and regards, > > > > German. > > > > > > ----- Original Message ----- > > > From: "harry devine" <harry.devine@xxxxxxx> > > > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > Sent: Friday, 13 February, 2015 7:27:10 PM > > > Subject: Re: Question about accountunlocktime > > > > > > passwordunlock is set to On, and passwordunlockduration is set to 1800. > > > > > > Thanks, > > > Harry > > > > > > -----Original Message----- > > > From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx > > > [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of > > > German Parente > > > Sent: Friday, February 13, 2015 11:51 AM > > > To: General discussion list for the 389 Directory server project. > > > Subject: Re: Question about accountunlocktime > > > > > > Hi Harry, > > > > > > could you check the value of attribute type "passwordUnlock" under > > > cn=config ? > > > > > > thanks and regards, > > > > > > German. > > > > > > ----- Original Message ----- > > > > From: "harry devine" <harry.devine@xxxxxxx> > > > > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > > Sent: Friday, February 13, 2015 1:31:04 PM > > > > Subject: Re: Question about accountunlocktime > > > > > > > > OK, I get that. What I don't get is why it won't automatically > > > > UNLOCK after lockout duration. The accountunlocktime stays set > > > > forever, and as long as that's set, the user can't log in and > > > > one of the admins has to clear the accountunlock time attribute manually. > > > > > > > > Thanks, > > > > Harry > > > > > > > > -----Original Message----- > > > > From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx > > > > [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of > > > > William > > > > Sent: Thursday, February 12, 2015 9:54 PM > > > > To: General discussion list for the 389 Directory server project. > > > > Subject: Re: Question about accountunlocktime > > > > > > > > On Fri, 2015-02-13 at 01:49 +0000, harry.devine@xxxxxxx wrote: > > > > > Any insight on this???? > > > > > > > > > > > > > > > > > The value is utc. My current time is 13:16 UTC+10:30. When I > > > > lock the account I get: > > > > > > > > > > > > accountUnlockTime: 20150213031647Z > > > > > > > > Split up is > > > > > > > > 2015-02-13 0316.47 UTC > > > > > > > > Which is 1316 - 1030 = 0246 > > > > > > > > > > > > Add to this that my passwordLockoutDuration is 1800 aka 30 minutes: > > > > > > > > 0246 + 0030 = 0316. > > > > > > > > Thus: > > > > > > > > 2015-02-13 0316.47 UTC > > > > > > > > This is why you may see the accountUnlockTime in the past. > > > > > > > > -- > > > > 389 users mailing list > > > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > > > 389 users mailing list > > > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -- > > > 389 users mailing list > > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -- > > > 389 users mailing list > > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > > 389 users mailing list > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > > 389 users mailing list > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
