Posted by synth3tk on January 10, 2013 at 8:24am
5 followers
| Project: | Lightweight Directory Access Protocol (LDAP) |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
It seems that I can authenticate against my openLDAP server, which stores the passwords as MD5.{MD5}blahblahblah
The problem is, as soon as I authenticate, Drupal seems to change it to cleartext. It's still the same password, just no encryption. I recompiled PHP with mcrypt, changed the encryption setting to Blowfish, but can't find where I can set/change the encryption type in LDAP's settings.
Comments
#1
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.
#2
Interesting. Thanks for the brief lesson on encryption.
Essentially what I'm trying to do is setup Drupal as the identity management system. This LDAP server is also being used to authenticate a Wordpress blog, Redmine installation, and a Google Apps domain, with plans to implement it in another Drupal install and (in the very long-term future) access to office PCs. I want to use an encryption method or setup that will be supported by all of these systems.
I know this is outside the scope of the module then, but what would be the recommended way to set this up? Would there be a way to have OpenLDAP automatically encrypt passwords on its end? Are there any other encryption modes that support two way? I'd rather not store the passwords in plain text.
#3
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.
#4
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.
#5
#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:
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.
#6
@johnbarclay thanks for the reply in #5.
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.
#7
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.
#8
#9
#7, can you elaborate? I'm itching to get this out the door ASAP.
#10
#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=comobjectClass: 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.
#11
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
#12
#10 Thanks. I setup password policy but never configured it much. I'll take a closer look at it once the password cleartext is working right.
#13
I'm still working on this, but I just realized after Googling that I really want hashing, not encryption. There's apparently a huge difference.
Still having difficulties implementing automatic hashing.
#14
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.
#15
@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.
#16
That last point is a good one, about the password being updated on LDAP before Drupal. As you stated, though, this isn't necessarily a problem for this specific issue ticket since the primary goal is updating through Drupal.
#17
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.
#18
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.
#19
#20
I committed this http://drupalcode.org/project/ldap.git/commitdiff/f980886de019dca5f353ea...
[password.user] is functional now. [password.user.md5] also works.
#21
What are plans for rolling out a beta4?
#22
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.
#23
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.
#24
Thanks. #23 looks correct to me. Please test. I'll get it in the next commit.
#25
This is committed. Thanks. Leaving this open for a bit in case there are still issues.
#26
#27
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...
#28
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.