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.