Hi list,
I realize I'm trying to use the ppolicy overlay a little differently from how it was designed to be used. The problem is that the ppolicy overlay is the closest thing I have found.
My use case:
1) I want to be able to disable users. I can do this by setting: pwdAccountLockedTime: 000001010000Z
That works. Great!
2) I want to be able to set a date in the future when a user account will expire / deactivate.
I was hoping to be able to set "pwdAccountLockedTime" to a date in the future and after that date the user account would be locked.
Unfortunately this isn't the case. ppolicy seems to lock out every account that has the "pwdAccountLockedTime" attribute set to a valid value.
Reading the source code for ppolicy I find an interesting block in the function "account_locked()" at line 356:
/* Still in the future? not yet in effect */ if (now < then) return 0;
This leads me to believe that the author's intension may have been to allow what I want to do.
Perhaps is there another attribute I need to set in order to tweek ppolicy to do wat I want. Here's how the default policy looks like:
dn: cn=passwordDefault,ou=Policies,ou=local objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMinLength: 0 pwdInHistory: 0 pwdMaxFailure: 0 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdLockoutDuration: 0 pwdAllowUserChange: FALSE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: FALSE pwdSafeModify: FALSE
All help greatly appreciated! TIA, Mikael
On 4/1/19 5:32 PM, Mikael Bak wrote:
- I want to be able to disable users. I can do this by setting:
pwdAccountLockedTime: 000001010000Z
I'd recommend to use another attribute and define a ACL on attrs=userPassword for that.
- I want to be able to set a date in the future when a user account
will expire / deactivate.
I was hoping to be able to set "pwdAccountLockedTime" to a date in the future and after that date the user account would be locked.
Reading the source code for ppolicy I find an interesting block in the function "account_locked()" at line 356:
/* Still in the future? not yet in effect */ if (now < then) return 0;
This leads me to believe that the author's intension may have been to allow what I want to do.
Note that semantics for 'pwdAccountLockedTime' are defined herein:
https://tools.ietf.org/html/draft-behera-ldap-password-policy
It does not mean what you want to achieve.
For Æ-DIR I defined custom meta attributes aeStatus, aeExpiryStatus, aeNotAfter etc.
https://www.ae-dir.com/docs.html#schema-at-aeStatus
Ciao, Michael.
Hi Michael,
On 2019. 04. 01. 18:07, Michael Ströder wrote:
On 4/1/19 5:32 PM, Mikael Bak wrote:
- I want to be able to disable users. I can do this by setting:
pwdAccountLockedTime: 000001010000Z
I'd recommend to use another attribute and define a ACL on attrs=userPassword for that.
Yes, I can do that, but I did not find any obvious choise of attribute for this in the included schemas. What attribute do you recommend for this?
- I want to be able to set a date in the future when a user account
will expire / deactivate.
I was hoping to be able to set "pwdAccountLockedTime" to a date in the future and after that date the user account would be locked.
Reading the source code for ppolicy I find an interesting block in the function "account_locked()" at line 356:
/* Still in the future? not yet in effect */ if (now < then) return 0;
This leads me to believe that the author's intension may have been to allow what I want to do.
Note that semantics for 'pwdAccountLockedTime' are defined herein:
https://tools.ietf.org/html/draft-behera-ldap-password-policy
It does not mean what you want to achieve.
Thanks for the link to the ppolicy draft.
As I said, I realize ppolicy is probably not the best choise for what I want to do. Unfortunately I did not find any other overlay module that does what I would like to do. Are there any?
I'm very curious to know what others do in this situation.
For Æ-DIR I defined custom meta attributes aeStatus, aeExpiryStatus, aeNotAfter etc.
Thanks for the info. How do handle the expiry in Æ-DIR? I have not found a way to construct an ACL that can have "today" or "now" as a search parameter.
I'm quite new to LDAP, so a little help is greatly appreciated. Thanks, Mikael
On 4/2/19 8:31 AM, Mikael Bak wrote:
On 2019. 04. 01. 18:07, Michael Ströder wrote:
I'd recommend to use another attribute and define a ACL on attrs=userPassword for that.
Yes, I can do that, but I did not find any obvious choise of attribute for this in the included schemas. What attribute do you recommend for this?
One candidate is 'organizationalStatus':
https://tools.ietf.org/html/rfc4524#section-2.19
But you would need to define your own custom object class.
For Æ-DIR I defined custom meta attributes aeStatus, aeExpiryStatus, aeNotAfter etc.
Thanks for the info. How do handle the expiry in Æ-DIR? I have not found a way to construct an ACL that can have "today" or "now" as a search parameter.
Last time something like this was discussed here: https://www.openldap.org/lists/openldap-technical/201402/msg00186.html
I'd love to see this implemented: https://tools.ietf.org/html/draft-pluta-ldap-srv-side-current-time-match-01
Until then Æ-DIR uses a small CRON job for updating 'aeStatus' if 'aeNotAfter' is reached and 'aeExpiryStatus' is set.
Ciao, Michael.
El 1/4/19 a las 18:07, Michael Ströder escribió:
Note that semantics for 'pwdAccountLockedTime' are defined herein:
https://tools.ietf.org/html/draft-behera-ldap-password-policy
It does not mean what you want to achieve.
For Æ-DIR I defined custom meta attributes aeStatus, aeExpiryStatus, aeNotAfter etc.
I'm curious... how do you use these attributes to enforce the user doesn't authenticate outside of this range? Does openldap check it? Is responsibility of the application authenticating?
openldap-technical@openldap.org
-
Michael Ströder -
Mikael Bak -
Ángel L. Mateo