LDAP Users: Password encryption token options available for Provisioning to LDAP of drupal password.

A little background on encryption will clear this up. MD5 is a hash and only works in one direction. Blowfish is a two way encryption and can be decrypted. To use a service account to bind to ldap, the actual password must be sent. That is it can be stored in a two way encryption, but must be converted to clear text before binding.

If you want drupal to be the identity management system, the following will work:
- use ldap user to provision ldap accounts and have the ldap be the authentication/authorization provider for the other apps
- use CAS or Shib provider drupal modules if any are up to speed. Then have the other apps be consumers of shib or CAS...or perhaps OAuth.

These are just off the top of the head thoughts.

I am trying to understand #3 above. However, it does not make clear taht how does ldap_user encrypt the password stored in LDAP server. It is always storing in pain text format.

#3 is about not having drupal store the passwords or the ldap module use the passwords at all.

For resetting passwords in ldap based on the drupal user password, the following would need to be done:

1. use ldap user to synch to ldap
2. add some functionality to the user edit form so it synched to ldap on changes to password
3. add some a mapping that includes encryption

I believe there are some code and issues for 2 and 3, but I don't think they are fully implemented or tested. If anyone is using such functionality they should chime in.

If the md5 password from drupal is what is desired in ldap, 2 and 3 are not needed.

@johnbarclay thanks for the reply in #5.

If the md5 password from drupal is what is desired in ldap, 2 and 3 are not needed.

It means that step 1 in #5 above should be enough to store a hashed password in remote LDAP server. But, in step 1, how should the mapping be set in LDAP user module to sync the md5 or sha hash of the drupal password to LDAP server. I know that hashes are also not very secure and prone to dictionary/brute force attacks but the ldapserver may be protected to a certain extent by using firewall to allow connections only from certain ip addresses.

At the moment the mapping I have on user module config page is -Password:User or Random -> [userPassword] but this stores password in clear text on ldap server. Do I need to use any other token instead of Password:User or Random.

Well I have now been able to set up automatic conversion of the plaintext password sent by drupal to SSHA hash using the password policy overlay in openldap server.

#9 you just need to enable the password policy module and over lay included in the ldap server. You then need to create a default password policy (directory entry) applicable to database storing drupal users. For help you need to following links:

http://grungelabs.com/guides/2012/06/08/ha-openldap-debian/
http://www.openldap.org/doc/admin24/overlays.html (section 12.10 titled password policies)

Following is my defult password policy:

dn: cn=passwordDefault,ou=policies,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: pwdPolicy
cn: passwordDefault
pwdAttribute: userPassword
sn: passwordDefault
pwdAllowUserChange: TRUE
pwdCheckQuality: 0
pwdExpireWarning: 0
pwdFailureCountInterval: 1800
pwdGraceAuthNLimit: 0
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdMaxAge: 0
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE

Please note that in order for it to work drupal needs to send clear text password.

It was working for me till I updated the latest dev version (17 March 2013) which contains a password patch) which now sends an SHA password on update (rather than clear text password) and my password policy is rejecting hashed passwords (because it will only receive clear text password and hash it itself to SSHA -the open ldap default hash). See http://drupal.org/node/1838896#comment-7186054 and my comment at #21 in the same post.

I think the ldap should only send passwords (in clear text) and send only user supplied passwords when the passwords are actually being updated. It should not any password be sent at all when any thing other than password is being updated. There may be a better way.

I also believe the hashed version of the password should be optional and the default cleartext also. A patch against 7.x-2.x-dev that added and implemented the hashed vpassword option would be useful. It should just be an option in the pulldown. See also
#1718200: LDAP User: Create options for setting password in provisioning of ldap entries
#1884922: LDAP User: Password field disabled Makes use case of Provisioning Passwords from Drupal to LDAP unusable

I think the easiest way to do #13 is use a token:

[password.user-random.to-md5]

along with the attached patch. The patch is untested, but I believe its the simplest way to make the tokens do conversion.

@johnbarclay when can we have the next password provisioning patch/commit which is preventing password/mail update on frontend. As said above the following workflow may be suitable:

1) new account created on drupal - clear text version of new password sent to ldap. (option for sending hash may be a good idea)
2) account details other than the password is updated (password field blank) - no password should should be sent to ldap at all. (I am unable to understand the concept of random here)
3) only password updated (other fields unchanged) - clear text version of changed password entered by user be sent to ldap. (again option for sending hash may be a good idea)

I don't know what may be the scenario when the password is changed on ldap. May be authentication password entered by the user be used to upadate the password on drupal. Howeever thimay not be relevant when drupal is being used to create or update accounts.

With the tokens, these scenarios are easy to do as long as the password is stored and available in ldap_user_ldap_provision_pwd().

Attached is another patch which supports a [password.user] token which will be the user password or none at all. [password.user.md5] would be the same in md5.

To avoid confusion, lets keep this issue for the token behavior. As far as #15 I can only speak to specific features. My focus is currently on the authorization aspect and test coverage. The only reason I'm working on password stuff now is the patch http://drupal.org/node/1884922#comment-7183854. When I see patches, I try to follow up on them.

Here's the attachment. Keep in mind that you should not use the user-random token if you are synching to ldap on update. It will always produce a random password unless the user is changing their password.

I committed this http://drupalcode.org/project/ldap.git/commitdiff/f980886de019dca5f353ea...

[password.user] is functional now. [password.user.md5] also works.

What are plans for rolling out a beta4?

Its a chicken and egg thing. If I release a beta4, I'll get more testing, but I prefer to fix known bugs before releasing a beta.

I'm still working through the issues at http://drupal.org/node/1115704#comment-7050144.

Maybe after the authorization stuff a beta4 should be published. I just finished the simpletest coverage for og authorization.

I've been struggling with password.user returning a null value regardless.

Looking at the code, only $pwd is being set, not a $value - thus not being included in the final token array.

I've added a line so that $value is set to $pwd, unless it is blank, in which case we set NULL - which I believe is the intended functionality based on viewed threads.

Thanks. #23 looks correct to me. Please test. I'll get it in the next commit.

This is committed. Thanks. Leaving this open for a bit in case there are still issues.

This was reverted and then recommitted because of some issues with other patches. Its still in 7.x-2.x-dev. See http://drupalcode.org/project/ldap.git/commitdiff/0736c42ed3b9a5e2728699...

Hi John,

This seems to be the most recent issue about this so posting it here instead of a new issue.
I am currently working on a D6 > D7 conversion, I started with a clean D7 using 7.x-2.0-beta5 (also checked the dev for this issue).

I had some problems converting my passwords to md5 and found the following token in this thread "[password.user] is functional now. [password.user.md5] also works." (#20).

According to the code this should be "to-md5".

        case 'to-md5':
          $value = md5($value);
          break;

In my case I used "[password.user.to-md5]", this did not result in md5 password.

In the code I found the following:

    $parts = explode('.', $token_key);
    $attr_type = $parts[0];
    $attr_name = $parts[1];
    $attr_conversion = (isset($parts[2])) ? $parts[1] : 'none';
    $value = FALSE;

It seems $attr_conversion = 'user' instead of $attr_conversion = 'to-md5'
This can be fixed by using $attr_conversion = (isset($parts[2])) ? $parts[2] : 'none';

Can you review this post and leave a comment on it?
If needed I can make the patch for this.

This is correct. A patch is welcome. Thanks.

There's still another change needed. As above, an MD5-hashed string is generated and written to LDAP, but it's still being stored as "plaintext".

The value of the password attribute in LDAP (at least, OpenLDAP) should look like:
{MD5}O61q8PpLgzMN5i4Zk47pgQ==
but since it's missing the "{MD5}" part, it's stored in LDAP as plain text.
I changed:

case 'to-md5':
          $value = "{md5}" . md5($value);

to:

case 'to-md5':
          $value = "{MD5}" . base64_encode( pack( "H*", md5( $value ) ) );

(PHP returns a Hex encoded string, and we need to convert that before putting it into LDAP. See http://www.openldap.org/faq/data/cache/347.html)

Hey guys! Tank you very much for your programming skills!

I'm trying to get Drupal to LDAP MD5 working on my installation, but it don't work.
Is there anything I'm doing wrong? In the attachment i add my PROVISIONING FROM DRUPAL TO LDAP MAPPINGS settings.

I'm Running Drupal 7.23 and LDAP 7.x-2.0-beta5+24-dev

Thank you very much for every help!

Best Regards Elias

Sorry, wrong screen shot!

Can someone verify #30 is correct? I'd like to commit that.

#30 is committed to 7.x-2.0-dev. Thanks.

I needed another patch to get this working:
modules/ldap/ldap_servers/ldap_servers.tokens.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/ldap/ldap_servers/ldap_servers.tokens.inc b/modules/ldap/ldap_servers/ldap_servers.tokens.inc
index 3b8061d..8fd551f 100644
--- a/modules/ldap/ldap_servers/ldap_servers.tokens.inc
+++ b/modules/ldap/ldap_servers/ldap_servers.tokens.inc
@@ -389,7 +389,7 @@ function ldap_servers_token_tokenize_user_account($user_account, $token_keys = '
$parts = explode('.', $token_key);
$attr_type = $parts[0];
$attr_name = $parts[1];
- $attr_conversion = (isset($parts[2])) ? $parts[1] : 'none';
+ $attr_conversion = (isset($parts[2])) ? $parts[2] : 'none';
$value = FALSE;
$skip = FALSE;

thanks. #36 is committed.