LDAP User: Password field disabled Makes use case of Provisioning Passwords from Drupal to LDAP unusable

Ditto. I'm looking to achieve the same configuration as synth3tk. I tried disabling ldap authentication and that enables the form elements for changing passwords, but doesn't seem to work and doesn't look to be updating ldap. Also, without ldap authentication I'll have a few thousand users that won't be able to login. Would I need to somehow synch those passwords to Drupal? Pre-provision all those accounts before making the site live?

I'm using the same ldap directory to authenticate users for multiple web-based applications. I would prefer to use Drupal to handle password reset; we really like the 'one-time login' URL.

I am having a related but similar issue, with a more specific use case which I would nonetheless think is common:

1. I would like to use LDAP Authentication -- only users who already exist in my pre-populated directory can log in to Drupal. No other users can create accounts.

2. I would like, once the accounts are connected, to use LDAP User's mapping power to push back password changes to the LDAP server -- i.e. users can change their LDAP password through Drupal without the use of a secondary management page.

It seems like this use case isn't compatible with how the module is presently constructed -- you can get one but not both. Is that correct or am I missing something?

I'm looking for the same set-up as Kazanir and synth3tk.

Marking as a bug, then, since something clearly isn't working correctly.

Here's my setup - one central LDAP server, users can log in using LDAP credentials, if user account does not exist in Drupal on login it will be created. Also, users can sign up on Drupal side and will then populated in LDAP. LDAP passwords are using sha password hashes. User first/last name are synced to Drupal when the user authenticates; username/email/first/last/password are pushed to LDAP when the user is created or updated.

I made this work with some improvements to the existing module. Things I had to change:
1. make password field visible and not disabled on profile form
2. alter how the static password is set in ldap_user module
3. alter ldap_server tokens to avoid empty or random password being generated and synced to LDAP

Something to be aware of though - changing a password requires knowing what the user's Drupal password is. Since the passwords aren't stored in plain text anywhere and they cannot be synced from LDAP (sha vs md5) this will require user to use the forgot password functionality to reset Drupal password and LDAP password. While the user logs in with LDAP password they need Drupal password to change the password down the road or update email (if it's allowed).

nonsie, can you be a bit more specific with what you did to accomplish your setup?

Thanks.

thanks for picking through this and developing a patch. I committed this (http://drupalcode.org/project/ldap.git/commitdiff/cb3dede7d354e4a6c0bd9f...).

Could everyone working with passwords test this out?

Just guessing, but I suspect the lines that remove the password in this patch (http://drupalcode.org/project/ldap.git/commitdiff/cb3dede7d354e4a6c0bd9f...) may be the issue. Do you have the same problem if you comment them out?

Here's is the patch that I believe corrects #14. I see 2 issues

1. The password tokens weren't implemented correctly. If another token besides password.user-random and password.random needs to be implemented, we should do that. Perhaps password.user-null which is the user's password when available, otherwise empty. We might want to ad a modifier syntax also like password.user-random;md5 so deal with that case.

2. removing the password so it doesn't get double hashed should be done a different way, not by emptying it out in hook_user_update. Whatever is hashing it 2 x is the issue. Other modules may need the password to be there.

I committed #18, but we should still get #13 functionality working (if this breaks it).

I forgot to say thanks for working on this! I appreciate the time spent on improving this module.

About #21 - in my version this was taken care of by the following lines in the patch

This sets the password to the current Drupal password instead of setting it to random like it used to do.
I found the easiest way to debug passwords to add some debug code to ldap_user_ldap_provision_pwd(). This explains when passwords get get set or retrieved and what the values are.

Also, this might help some - in my case LDAP passwords were with SHA password schemes so I had to use hook_ldap_entry_pre_provision_alter() to generate SHA password from Drupal passwords.

Upon a little investigation it appears that:

1) The Drupal-side "check current password before allowing update" only checks the stored Drupal-side password, which was unset.

2) If I forcibly set the password of my test user (using uid 1 account), it works, but does not synch to LDAP (despite those settings allegedly being set to happen on user entity update.)

3) Once this is done, the test user can use the above password to change their own password, but it still only applies to the Drupal side and doesn't propagate to LDAP.

Has anyone gotten this working with Active Directory? I've tried several versions of these patches and I'm still getting "Server is unwilling to perform" errors. The only thing I can see that's likely to stand in the way is the password getting sent to the "unicodePwd" attribute.

Sounds like a separate issue. Might want to open a new ticket.

#13 is headed in the right direction. Since there is no hook to get at the unhashed password, we need to deal with each form that might contain a password. A patch that does that as well as checks which form_id is being submitted (for additional certainty that it is a password form) would be greate to wrap this up.

Just to be sure we're all on the same bandwagon here, we also want the user to not need to enter the old password when changing the password, yes? Otherwise the email recovery system doesn't work.

I'm also on Active Directory and unable to get it to respond so I'm not sure what level of functionality everyone else is seeing.

Sorry I can't do more to contribute - it's slightly beyond my skill set. I'll happily test anything though.

I'm not trying to muddy the waters here, but I just noticed that I had my dn set wrong for the PROVISIONING FROM DRUPAL TO LDAP MAPPPINGS. I'm using active directory, so I had to grab my first and last name fields that I set up for users, so my mapped dn is:

cn=[field.field_first_name] [field.field_last_name],ou=members,dc=aps,dc=lan

I have Pwd: User or Random mapping to [unicodePwd]

I have Email mapping to [mail].

My users all authenticate just fine and are added to proper groups, but whenever I enable the Provisioning from Drupal to LDAP, I get the following errors:

php: Notice: Undefined variable: old_value_is_scalar in LdapServer::removeUnchangedAttributes() (line 461 of /var/www/sites/all/modules/ldap/ldap_servers/LdapServer.class.php).

ldapServer: LDAP Server ldap_modify(cn=John Jingle,ou=members,dc=aps,dc=lan) in LdapServer::modifyLdapEntry() Error Server ID = primary, LDAP Err No: 50 LDAP Err Message: Insufficient access

ldapUser:LDAP entry on server primary not synched because error. username=jjingle, uid=16

I'm puzzled by the insufficient access one because I know the bind is working.

I submit all this because I wonder if this inability to provision to LDAP is the underlying cause of the inability to update the password.

Can someone articulate how to replicate this and a patch that works against current dev. This thread is all over the place and needs to be summarized. I've retitled this issue to give it the focus it originally had.

I know I'm driving you crazy, but I think I'm on to something this time. The user password for Active Directory is unicodePwd and it has to be encoded in UTF-16. I looked back through LDAPInterface.inc in the old LDAP Integration module (in the Includes directory) and found this:

****************************

function writeAttributes($dn, $attributes) {
foreach ($attributes as $key => $cur_val) {
if ($cur_val == '') {
unset($attributes[$key]);
$old_value = $this->retrieveAttribute($dn, $key);
if (isset($old_value)) {
ldap_mod_del($this->connection, $dn, array($key => $old_value));
}
}
//Encodes password for use in Active Directory
if ($key == "unicodePwd") {
$cur_val = "\"" . $cur_val . "\"";
$attributes[$key] = mb_convert_encoding($cur_val, "UTF-16LE");
}
if (is_array ($cur_val)) {
foreach ($cur_val as $mv_key => $mv_cur_val) {
if ($mv_cur_val == '') {
unset($attributes[$key][$mv_key]);
}
else {
$attributes[$key][$mv_key] = $mv_cur_val;
}
}
}
}

********************

Note that it is making this conversion. I don't see this functionality anywhere in the new module. It needs to make this conversion when it provisions to LDAP.

Well this is challenging (I spent all day on it and still no luck). Do you know a way I can determine if it's actually converting the string to UTF-16? It also has to be in quotes, but I've got that bit sorted out.

Re: #38 -- I just deployed a working version of this that has some updates from the dev:

1. I added a "User Only" option for passwords, some code for this was present but non-functional and didn't have a UI option; I updated and fixed it. This means that, if enabled, LDAP should never try to synch a randomized password to the directory. I ran into this as a problem when running a Feeds import on the directory caused Drupal to synch back a random password for EVERYONE (since it wasn't part of a user login form.)

2. I also fixed the "user editing password form" use case as I documented above.

There should probably be documentation about the need for a service account with full powers to change anyone's password (assuming a service account is used rather than user-based binding) as well as the apparent need to pick No Encryption for passwords.

In addition, an outstanding issue is that if a user changes their password and for whatever reason the synch to LDAP fails, Drupal will still have changed its copy of the user's password, resulting in a mismatch where the password needed to log in (LDAP authentication) is different than the password needed to change the password in the user/%/edit screen (which is the Drupal variant.)

A reset password link can fix this, but this possibility is frighteningly bad user experience and if there is any way to prevent it we probably should do so.

I will do a diff later today and post a patch against the current dev, which is what I started from yesterday.

Ok, I threw this together since the dev has changed since I updated and I'm far, far, far from being competent with Git. The only changes should be pretty obvious and it should apply to the current dev version.