[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Not getting password expiry warnings on login
I haven't had any success adding pwdChangedTime to accounts - and it seems you've assisted others with that issue - with the result being "ya can't do that".
http://www.openldap.org/lists/openldap-software/200706/msg00298.html
So, how do I add pwdChangedTime to accounts?
I'm being advised here to do so, but the only success I've had so far is painful: delete the entry, and use slapadd.
Thanks,
- chris
PS:
Yes, I've read the man page for ldapmodify - I see mention of some 'general extensions flag - but it doesn't make sense to me.
I've also seen mention of a '-k' flag, but it's not an option with the version of ldapsearch compiled with openldap 2.4.
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Tuesday, March 30, 2010 3:57 AM
To: openldap-technical@openldap.org
Cc: Chris Jacobs
Subject: Re: Not getting password expiry warnings on login
On Tuesday, 30 March 2010 00:09:42 Chris Jacobs wrote:
> STRANGE.
>
> I'd just decided to 'heck with this' and work out some process that will
> send emails - removing the 'need' for this feature.
>
> So I modified the policy to 184 days (max value for any 6 months), set the
> password warning to 1 second less than that, and viola! When I login with
> my test account it now tells me my password will expire in 183 days.
>
> Is that the trick? Previously, I'd set my expiration to 60 minutes...
>
> ALSO: when I asked my coworker to login to check it out - he wasn't getting
> the notice.
Most likely he had last changed his password before ppolicy was enabled, as
such his account's entry probably has not pwdChangedTime, ppolicy can't
calculate the password age.
> Investigating further, I notice that his account was setup a long time ago
> - and things are done differently now.
>
> His account objectclasses:
> objectClass: account
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: top
>
> Mine (Test account):
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: top
>
> If I attempt to modify his account to remove the objectclass account and
> add inetOrgPerson, ldap complains: "Mar 29 22:51:36 ldapmaster1
> slapd[32653]: entry failed schema check: structural object class
> modification from 'account' to 'inetOrgPerson' not allowed"
>
You can't change structuralObjectclass, and account and inetOrgPerson are the
structuralObjectclasses in question. If you want to change this (which in
itself isn't the cause of your problem), you will have to delete and recreate.
Most likely this will fix your problem as you will have a newly modified
userPassword attribute (but, any other way of updating userPassword would fix
the password expiry problem).
> At the same time, my LDAP browser (apache DS) also adds
> organizationalPerson and person objectclasses to his account - which
> smbldap-useradd (the tool we've historically used to add accounts) hasn't
> been doing.
Irrelevant.
> If I simply attempt to add just the inetOrgPerson class, and not remove
> account - slapd complains slightly differently: "Mar 29 23:05:22
> ldapmaster1 slapd[32653]: entry failed schema check: invalid structural
> object class chain (account/inetOrgPerson)"
See above.
> I suspect, and would love verification/clarification/clue-by-fours:
> 1) I'm going to need to change how we add users - suggestions for a
> 'better' CLI method?
Not necessarily.
> 2) I'm probably going to need to scrub these accounts
> so that they're created correctly - likely through a slapcat - modify
> output - wipe db (or delete entry) - slapadd (replace slapcat/add with
> ldapmodify if that's your pref).
No, update userPassword. E.g., something which does more or less:
ldapsearch "(&(userPassword=*)(!(pwdChangedTime=*)))" userPassword|ldapmodify
>
> Am I about on target?
>
> - chris
>
> PS: I haven't seen /anywhere/ what objectclasses are required for certain
> 'features' to work correctly - why not? If that's a
> limitation/requirement you'd expect someone to mention it...
Since it isn't, it isn't ...
Regards,
Buchan
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.