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.

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.