Hi,
I was exploring account lockout functionality of password policy overlay. I would like to know how to reliably check whether particular account is locked or not (e.g. for use by a helpdesk application).
It looks like from the documentation that this is not possible to do by just examining the account LDAP entry. Is that right?
The locked account contains pwdAccountLockedTime that indicates the time when the account was locked. But I also need to determine whether the lock has not expired. For that I need the value of pwdLockoutDuration from the password policy. But how to determine what entry contains a default password policy? For that I need access to cn=config, right? So if my helpdesk application does not have access to the cn=config then I'm pretty much out of luck.
Is my thinking OK or have I overlooked something?
2016-06-15 14:17 GMT+02:00 Radovan Semancik radovan.semancik@evolveum.com:
Hi,
I was exploring account lockout functionality of password policy overlay. I would like to know how to reliably check whether particular account is locked or not (e.g. for use by a helpdesk application).
It looks like from the documentation that this is not possible to do by just examining the account LDAP entry. Is that right?
The locked account contains pwdAccountLockedTime that indicates the time when the account was locked. But I also need to determine whether the lock has not expired. For that I need the value of pwdLockoutDuration from the password policy. But how to determine what entry contains a default password policy? For that I need access to cn=config, right? So if my helpdesk application does not have access to the cn=config then I'm pretty much out of luck.
Is my thinking OK or have I overlooked something?
Well, if there is a default ppolicy configured, and yes you need to search it in cn=config, but it can also be a configuration parameter on your side. If there is not, the policy will be defined in pwdPolicySubentry, so you can directly request it.
You also need to take into account the value 000001010000Z in pwdAccountLockedTime which means the password is locked forever.
But we clearly lack of some operations that would allow to know the state of an account. This could be an interesting discussion if we work on a new ppolicy draft.
Clément.
Thanks Clement,
I'm glad that you confirmed that. I was afraid that I'm overlooking something essential here.
On 06/15/2016 10:14 PM, Clément OUDOT wrote:
Well, if there is a default ppolicy configured, and yes you need to search it in cn=config, but it can also be a configuration parameter on your side. If there is not, the policy will be defined in pwdPolicySubentry, so you can directly request it.
Yes, theoretically I can have configuration parameter on my side. But practically that is asking for trouble during operation and maintenance. If the pointer to default password policy in OpenLDAP changes I'm quite sure nobody will think about updating the configuration of my application.
You also need to take into account the value 000001010000Z in pwdAccountLockedTime which means the password is locked forever.
Sure. I have seen that in the docs.
But we clearly lack of some operations that would allow to know the state of an account. This could be an interesting discussion if we work on a new ppolicy draft.
Well, that's a bit more complex. It is not just an operation to check the status. But there are also usecases to search such accounts. E.g. statistics how many accounts are locked, look for locked accounts if an password attack is suspected, etc.
Le 16/06/2016 10:36, Radovan Semancik a écrit :
Thanks Clement,
I'm glad that you confirmed that. I was afraid that I'm overlooking something essential here.
On 06/15/2016 10:14 PM, Clément OUDOT wrote:
Well, if there is a default ppolicy configured, and yes you need to search it in cn=config, but it can also be a configuration parameter on your side. If there is not, the policy will be defined in pwdPolicySubentry, so you can directly request it.
Yes, theoretically I can have configuration parameter on my side. But practically that is asking for trouble during operation and maintenance. If the pointer to default password policy in OpenLDAP changes I'm quite sure nobody will think about updating the configuration of my application.
You also need to take into account the value 000001010000Z in pwdAccountLockedTime which means the password is locked forever.
Sure. I have seen that in the docs.
But we clearly lack of some operations that would allow to know the state of an account. This could be an interesting discussion if we work on a new ppolicy draft.
Well, that's a bit more complex. It is not just an operation to check the status. But there are also usecases to search such accounts. E.g. statistics how many accounts are locked, look for locked accounts if an password attack is suspected, etc.
Maybe a solution can be to rely on the pwdAccountLockedTime attribute presence and create a cronjob that will remove this attribute if the pwdLockoutDuration is over. Not very clean but seems a quick fix.
Radovan Semancik wrote:
I'm glad that you confirmed that. I was afraid that I'm overlooking something essential here.
On 06/15/2016 10:14 PM, Clément OUDOT wrote:
Well, if there is a default ppolicy configured, and yes you need to search it in cn=config, but it can also be a configuration parameter on your side. If there is not, the policy will be defined in pwdPolicySubentry, so you can directly request it.
Yes, theoretically I can have configuration parameter on my side. But practically that is asking for trouble during operation and maintenance. If the pointer to default password policy in OpenLDAP changes I'm quite sure nobody will think about updating the configuration of my application.
The caveat with reading cn=config is that you might not be allowed doing so. One would need fine-grained read ACLs to avoid e.g. revealing the rootpw hash to an application. Well, on my systems there is no rootpw hash but you get the idea.
AFAIK other LDAP servers (e.g. OpenDJ) has two operational attributes:
1. 'pwdPolicySubentry' is set in every entry and therefore always points to the effective (default) pwdPolicy entry.
2. Another attribute (IIRC 'ds-pwp-password-policy-dn') is for setting an individual pwdPolicy entry to be used for a particular entry overriding the default value.
I'd love to see something like this standardized and implemented in OpenLDAP.
Ciao, Michael.
On 06/16/2016 11:45 AM, Michael Ströder wrote:
The caveat with reading cn=config is that you might not be allowed doing so. One would need fine-grained read ACLs to avoid e.g. revealing the rootpw hash to an application. Well, on my systems there is no rootpw hash but you get the idea.
Yes. That's exactly my concern. I do not like the idea of letting ordinary LDAP clients access cn=config at all. So, it looks like there is currently no good solution for this.
AFAIK other LDAP servers (e.g. OpenDJ) has two operational attributes:
- 'pwdPolicySubentry' is set in every entry and therefore always points to the
effective (default) pwdPolicy entry.
- Another attribute (IIRC 'ds-pwp-password-policy-dn') is for setting an
individual pwdPolicy entry to be used for a particular entry overriding the default value.
I'd love to see something like this standardized and implemented in OpenLDAP.
I completely agree with that.
openldap-technical@openldap.org
-
Clément OUDOT -
Clément OUDOT -
Michael Ströder -
Radovan Semancik