Current password check incorrect in user edit form

Hi

So in another issue I already told you what an acceptable form of input for support request is (i.e. the relevant config exported and anonymized). I request that you do that next time or I will close the ticket directly.

Since the configuration looks sane, I'd summarize your issue as follows: in exclusive mode, the current password is not verified against LDAP on the user edit form and thus changes are not possible.

I've tried reproducing this and am running into a similar error, thus I'm moving this to a bug. I will look into this but cannot promise a fix until after the holidays.

That sounds like fun...thanks for looking into that.

Yes you can definitely write your own custom form in the interim but it would probably be easier to just hook_form_alter() the user form to remove the current password requirement from core. It's a safety feature so I'd be nice to not have to remove it fully but would work for now.

Either version should support LDAPS just fine if you use the prefixes as the form description shows. Note that the certificates must be in order and trusted. I've seen weird issues in some sites where the domain server was using a valid but out-of-scope certificate issued by a custom org trust chain.

I am also experiencing this problem. I tried removing the current_password field using form_alter but it still shows the same error. It seems to be coming from ProtectedUserFieldConstraintValidator object. Were you suggesting that there is a way to interact with that object inside form_alter? Any guidance is appreciated.

I also tried setting the user's Drupal password to be the same as their LDAP password... But STILL the same error happens, even though the password is definitely correct no matter which system it's trying to check.

Can I safely say that modifying LDAP passwords from Drupal 8 is not yet supported / a work in progress?

Thanks.

I tried the reset password form too, as well as changing the user's password using an administrator account. These are 2 ways that I know to change a password without requiring it accept their current password. In both cases it accepted the form submission and indicated success. It said nothing about LDAP and I don't know that it attempted to do anything on the LDAP server. Afterwards, only the user's original LDAP password still worked... Despite the acceptance messages the new password didn't even work to login via Drupal.

Thanks for your feedback. Others have had success with sending passwords to LDAP but most have chosen to do so with a custom form to avoid issues with Core's form, which is still a work in progress in this issue.

@jmuzz I did not run into issues saving the password, were you possible using user binding? (That's a tricky scenario in either case.)

Anyway, attached is a partial solution to the problem whereby an incorrect field check from D7 is fixed and we are now keeping new and existing password in the CredentialsStorage where applicable. However, this does not yet actually validate the LDAP password but rather core's check is still in use.

I have not found an elegant way of overriding ProtectedUserFieldConstraintValidator to check against LDAP. Any help would be appreciated for this.

No I am not using user binding.

I believe I am close to finding the solution for my problem though. I think it will be very obvious to you but I do not know how to find this information.

The option for putting passwords on LDAP states that LDAP provisioning must be enabled for the field (pwd1.png)

I found where that would be done. (pwd2.png)

I don't know what the password token is called but the field description provides a link to https://www.drupal.org/node/1245736 . That page does not state what the password token is, but it does refer back to the module's test feature which is supposed to show all the available tokens. (pwd3.png)

The test does indeed show a large number of tokens, but none of them are clearly the password field on LDAP (pwd4.png)

Do you know what the token is? If so, it might be worth putting in the module documentation somewhere for people trying to set up LDAP when no experts are available, like the page with the sample note that provides all the questions to ask them.

Or even a recommendation for another solution if it can help avoid the issues with Core's form. I had done some googling around and the first few times I tried I could only find info about these big LDAP packages which do offer password reset functionality but as just a small part of a number of services / features. More recently I found an open source LDAP password reset web application that only does that, but it's really easy to miss it when trying to google for it.

https://github.com/ltb-project/self-service-password

Not sure if that is what you mean by a custom form, since it's completely independent from Drupal... If there is an even better way that would be cool too and I'd love to see more information about it.

Hi

The target LDAP token is the field in the directory server in which the password is saved. For example, unicodePwd is a common one in AD. I'd recommend that you try to first get syncing of users fields to LDAP working with something simpler before attempting to sync passwords.

When I was talking about a custom form I meant that others have written forms in form api and triggered functions in the LDAP module directly to circumvent what core is doing. We could add such a separate form to the LDAP module also but it would be a non-obvious solution to most site administrators, so I'd like to fix it generally, if at all possible.

Note that for sites where you do not need to update the password in the directory, you can just disable the current password check in ldap_authorization but, of course, this issue attempts to solve the remaining case.

I'm experiencing the same problem. In the mixed mode, when I try to change the password at /user/%/edit, I got this error:
Your current password is missing or incorrect; it's required to change...

In \Drupal\user\Entity\User::checkExistingPassword(), the old password (stored in LDAP) is checked again the hashed password in the database (why? this is LDAP-based authentication), thus the result is not correct.

Sorry, #16 duplicates #9. I didn't see that comment.

Working on a patch, to replace core mechanism with LDAP's one.

Here is a work in progress patch, but I set status to NR for attention to validate the approach.

- I use hook_entity_base_field_info_alter instead of hook_validation_constraint_alter because I want to add a proper constraint.
- LdapProtectedUserFieldConstraintValidator::validate() is not finished. I don't know how to work around it without adding an dependency.

Wrong path prefix.

The above patch allows to change password (it will be stored as plain text in LDAP, but we can work around it to choose a proper encoding function). The security password check is loosened, because it is removed now but given that the user is already connected, it does not expose an immediate risk. However I think it should be fixed before commit.

Add related issue that was marked as "won't fix" in D7. In D8 we don't have to swap out the file BTW.

New patch, which relies on https://www.drupal.org/project/ldap/issues/3007601#comment-12820068 to do LDAP password validation.

The approach looks good but I don't have the time to review and test this at the moment and still get into 3.x while currently refactoring.

Just a note to make sure to include https://www.drupal.org/project/ldap/issues/3007601#comment-12820068 if you are using this patch. Ran into issues by not using it :)

Because #3007601: Allow external use of password validation is marked as "Won't fix", this patch should work around it. I no longer work on the project though, sorry that I can't help to move it forward.

i am not able to apply below patch . Please help me on the same.

https://www.drupal.org/files/issues/2018-10-18/2928091-ldap-change-pwd-2...

I've just encountered this bug, which should definitely be considered a release blocker as it prevents users with LDAP linked accounts from making changes to their account email address or site local password, and the existence of mixed mode authentication and emailOption = allow configuration options implies both things should be possible.

There are quite a few possible combinations here in terms of which authentication mode, which binding and which sync events are in use that supporting every possible combination out-of-the-box is difficult at best.

Which is to say that I can agree with the current errors being stable blocking but I'm also considering just limiting that functionality to certain combinations and resolving the blocker that way and asking other combinations to be solved in other contrib modules or custom code.

Please advice how can we resolve password validation in User Edit Profile(Using Ldap Module)?

Please share steps or else provide patching to fix it.

Attached is an initial draft of this based on the work done by jcisio, still should have some tests added. Please test and provide feedback.

Would be great if someone could confirm this in the next week, I'd like to merge it soon for a release.

Not waiting any longer on feedback here, added a rudimentary test.

Create follow-up issues with detailed information if this doesn't work for you.

Have just been reviewing this, I think the only potential problem is mixed-mode operation, as the new validateCredentialsLoggedIn function only performs an ldap check - I don't see a call to User::checkExistingPassword either in this function or the the new constraint plugin. Probably best to pick that one up either in a specific follow-up or in 2698159 as part of the work to replace the LoginValidatorLoginForm class.

Per #38's comment I am seeing an error for manual Drupal users attempting to edit their own password on their user profile in a couple sites with the same set-up (Mixed Mode, no provisioning to LDAP).

TypeError: Argument 1 passed to Drupal\ldap_servers\LdapBaseManager::queryAllBaseDnLdapForUsername() must be of the type string, bool given, called in /var/www/example/web/modules/contrib/ldap/ldap_authentication/src/Controller/LoginValidatorLoginForm.php on line 123 in Drupal\ldap_servers\LdapBaseManager->queryAllBaseDnLdapForUsername() (line 390 of /var/www/example/web/modules/contrib/ldap/ldap_servers/src/LdapBaseManager.php)

Currently reviewing 2698159 and it doesn't seem to have this issue - still continuing testing there.