hi,
i want to force a password change for a user. therefor i set pwdreset: true but to change the password, bind attempts are still allowed. i thinks thats the reason why a user with pwdreset=true still can login to an apache webresource which is protected with ldap authentication. is there a way to prohibit that? i want the user to only allow the password change.
/thanks,chris
Christian Bösch wrote:
i want to force a password change for a user. therefor i set pwdreset: true but to change the password, bind attempts are still allowed. i thinks thats the reason why a user with pwdreset=true still can login to an apache webresource which is protected with ldap authentication. is there a way to prohibit that? i want the user to only allow the password change.
Strictly speaking: In case of pwdreset=TRUE the LDAP client has to 1. request and process the ppolicy controls and 2. lead the user to the password change dialogue. Most LDAP clients are not capable of doing so.
So if you simply want to avoid that such a user can login to such a service you could either 1. configure a client side search filter (&(uid=<user-id>)(!(pwdreset=TRUE))) or 2. define a server-side ACL which disallows even authc access to userPassword for for those LDAP clients.
Ciao, Michael.
On Wednesday, 15 February 2012 12:24:59 Michael Ströder wrote:
Christian Bösch wrote:
i want to force a password change for a user. therefor i set pwdreset: true but to change the password, bind attempts are still allowed. i thinks thats the reason why a user with pwdreset=true still can login to an apache webresource which is protected with ldap authentication. is there a way to prohibit that? i want the user to only allow the password change.
Strictly speaking: In case of pwdreset=TRUE the LDAP client has to 1. request and process the ppolicy controls and 2. lead the user to the password change dialogue. Most LDAP clients are not capable of doing so.
Well, I wouldn't necessarily say the problem is on the LDAP client side.
(AFAIK) Many protocols (e.g. HTTP, IMAP etc.) don't have the ability to communicate to the client that the user's password needs to be changed.
So if you simply want to avoid that such a user can login to such a service you could either
- configure a client side search filter
(&(uid=<user-id>)(!(pwdreset=TRUE))) or 2.
This would make sense for clients that can't communicate the need to change the password to the user.
define a server-side ACL which disallows even authc access to userPassword for for those LDAP clients.
This doesn't make sense, as it would prevent good clients from doing the right thing.
Regards, Buchan
Buchan Milne wrote:
On Wednesday, 15 February 2012 12:24:59 Michael Ströder wrote:
Christian Bösch wrote:
i want to force a password change for a user. therefor i set pwdreset: true but to change the password, bind attempts are still allowed. i thinks thats the reason why a user with pwdreset=true still can login to an apache webresource which is protected with ldap authentication. is there a way to prohibit that? i want the user to only allow the password change.
Strictly speaking: In case of pwdreset=TRUE the LDAP client has to 1. request and process the ppolicy controls and 2. lead the user to the password change dialogue. Most LDAP clients are not capable of doing so.
Well, I wouldn't necessarily say the problem is on the LDAP client side.
I didn't say this.
(AFAIK) Many protocols (e.g. HTTP, IMAP etc.) don't have the ability to communicate to the client that the user's password needs to be changed.
That's what I basically said.
So if you simply want to avoid that such a user can login to such a service you could either
- configure a client side search filter
(&(uid=<user-id>)(!(pwdreset=TRUE))) or 2.
This would make sense for clients that can't communicate the need to change the password to the user.
Yepp, but requires that you can define such a filter at the client-side.
define a server-side ACL which disallows even authc access to userPassword for for those LDAP clients.
This doesn't make sense, as it would prevent good clients from doing the right thing.
ACLs are powerful enough to distinguish various cases.
Ciao, Michael.
openldap-technical@openldap.org
-
Buchan Milne -
Christian Bösch -
Michael Ströder