Hello,
Many websites now provide a feature which allow users to reset their password on their own, without being helped by an administrator or another privileged person.
A website I'm working on is using drupal which is able to handle such a situation by sending a mail to the user. The body of this mail contains a specific url crafted by drupal so that when the user clicks on the link, drupal can automatically authenticate the user. This URL is only valid once.
If you try to integrate drupal with openldap, you'll find that openldap does not support such an authentication scheme. So you are either forced to create a privileged user in LDAP which is able to reset all users' passwords or live with it and give up this feature.
So I'm writing to this list to know if anyone already had a similar issue and which solution was found ? Would it be possible for openldap or an openldap overlay to implement such an authentication mechanism ? Is there any IETF draft about it (one can dream) ?
Vincent
Vincent Panel writes:
A website I'm working on is using drupal which is able to handle such a situation by sending a mail to the user. The body of this mail contains a specific url crafted by drupal so that when the user clicks on the link, drupal can automatically authenticate the user. This URL is only valid once.
If you try to integrate drupal with openldap, you'll find that openldap does not support such an authentication scheme. (...)
A new overlay seems the clean approach, but I think you can hack it with overlay ppolicy + access controls. Untested, but anyway:
Set up an entry with a temporary password with an unusual ppolicy state which a password change will undo, e.g. empty password history. Also set up the entry in a "login has failed" state. (Enough failures disables login). Then deny access if there is no pwdHistory (i.e. it's a temporary password) and last login succeeded:
access to attrs=userPassword filter=(!(|(pwdHistory=*)(pwdFailureTime=*))) by <drupal's DN> =w by * none
Of course you do lose the real function of pwdHistory. And remember that some other operations than Bind also can try to check the password. Bind, Compare, Search. I think pwdFailureTime is supposed to be updated then too. Hopefully you can prevent that by allowing write and auth access but not read/compare/search access to the password:
access to attrs=userPassword by self =w by <drupal's DN> =w by * =x
If you are prepared to require a bit more of LDAP clients that make password changes, you can have two password policies: One for entries with temporary passwords and one for the rest. Clients must take away the "temporary ppolicy" attribute when the change such passwords. Then you won't need to mess with pwdHistory.
Duh, I seem to be tired - I forgot you didn't want that privileged user, I focused on the "password works only once" part.
Well. _Something_ needs permission to create a temporary password. Presumably without removing the old one, otherwise anyone can sabotage anyone's password. Which probably kills the ppolicy idea since that gets confused by multiple passwords.
Maybe you could have a separate database or two with passwords, merged to the main one with the translucent overlay... Then the Drupal DN would at least play with its own database and not mess with the main database.
Another way would be to require clients to use SASL instead of Simple Bind. Then you can defer the problem to maintaining a SASL database of temporary password.
Just loose ideas, I'm not going to try harder to make sense now...
Hallvard B Furuseth wrote:
Duh, I seem to be tired - I forgot you didn't want that privileged user, I focused on the "password works only once" part.
Well. _Something_ needs permission to create a temporary password. Presumably without removing the old one, otherwise anyone can sabotage anyone's password. Which probably kills the ppolicy idea since that gets confused by multiple passwords. Maybe you could have a separate database or two with passwords, merged to the main one with the translucent overlay... Then the Drupal DN would at least play with its own database and not mess with the main database.
This password reset ticket database could be another part of the DIT. A regex-based ACL could implement password write access for the original user entry (e.g. based on same naming scheme). Also don't forget to clean up password reset tickets not used.
Ciao, Michael.
Ok, thanks for these interesting replies.
If the password of the temporary security-object you mention (in the password reset ticket database) is the URL sent by drupal, then it's probably as secure as the original drupal authentication scheme.
Many thanks !
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Michael Ströder -
Vincent Panel