Paul Gilzow

oh, boy. this one is going to be fun to debug….

to get to line 491, you would have had to have a valid return (non boolean false) at line 490 for
$results = @ldap_search($connection, $baseDn, $filterQuery, $returnKeys)) !== false

A return of false would indicate a failure from ldap_first_entry and not just an empty return set.

Is there anything else in your logs that might shed some light on why the call to ldap_first_entry failed?

Can you try running this script (and adding in the necessary info) https://github.com/gilzow/simple-ldap-test/blob/master/ldap.php on your instance to help debug ?

• This reply was modified 1 year, 1 month ago by Paul Gilzow. Reason: mentioned wrong ldap method

I decided to go ahead and release 1.10.7 today as well which _does_ include the fixes for your issue.

Just a head’s up that I released v1.10.6 today which does _not_ address your issue (ie, if you update you’ll need to re-add the above lines), but a different one. Working up yet another release to address the PHP8.0 version but want to do so in such a way that those on PHP7.4 doesn’t break (since WordPress still supports 7.4).

v1.10.6 released with the above fixes. Going to go ahead and mark this as resolved.

ah-ha! found it!
as of version 6.0 of WordPress, the global variable $profileuser was removed. so in the function at line 1189, it was using a null value when trying to check to see if the current user is an ldap-authenticated user, and therefore always returning?true (ie showing the password reset button).

at line 1191, change
global $profileuser, $userdata;
to
global $user_id, $userdata;

then at line 1193, change
$editUserIsDirUser = get_user_meta($profileuser->ID, 'wpDirAuthFlag',true);
to
$editUserIsDirUser = get_user_meta($user_id, 'wpDirAuthFlag',true);

and finally, change line 1211 from
if ($userdata->ID == $profileuser->ID) {
to
if ($userdata->ID === $user_id) {

And see if that fixes it?

Big shout-out and gratitude to @silsbyc for the assistance!

Glad that worked. I need to try and remember how SVN works so I can go update it with these changes.!

oh, i think i found it.

line 1825, change
return sprintf($strMsg,$strUserID,$strSSOID,implode($arySiteMsgParts,', '),$strExtraMsg);
to
return sprintf($strMsg,$strUserID,$strSSOID, implode(', ', $arySiteMsgParts),$strExtraMsg);

and then line 2190, change
add_action('lostpassword_form',create_function('','echo get_site_option("dirAuthChangePassMsg");'));
to
add_action('lostpassword_form',function(){echo get_site_option("dirAuthChangePassMsg");});

And see if that fixes it.

Is there anything in your logs that may indicate the cause of the error?

And everything else is working without errors except adding a new LDAP user, correct?

I’m stumped at this point as I can’t recreate it. The only difference I can think of is my sites are all on v6.2.2 of WordPress since 6.3 isn’t available via johnpbloch/wordpress yet.

What version of WordPress are those sites on? I have one still on 5.9 I just tested but couldn’t replicate the issue there either.

I dont see anything immediately in the code that should conflict, but that doesn’t mean this isn’t the root issue. I added the plugin and network activated it, and I’m still not seeing the password fields in either my own profile or if i go to edit a user’s profile.

There *is* a “send password reset button if you’re a super-admin and are editing a user’s profile, but that does not show up for the user if they go to their profile.

I haven’t created any new roles though since I’m not sure what settings you have or haven’t enabled.

Do you have a dev/staging environment where you can temporarily disable that plugin to see if it’s causing the conflict?

Same thing if I try to edit a user’s profile as a Super-Admin: password reset fields are replaced with the Directory Auth message about not being able to change the password.

ok, converted my personal site into a multisite and tried the same thing: attempting to use the password reset from the login screen for a user that has the dirAuthFlag set to 1 results in an error that it can’t reset the password. If I log in and look at my profile, the password reset options are removed and replaced with the Directory Password Update heading and message as configured in the options.

By chance do you have any must-use plugins installed or any other plugins that deal with logging in, authentication, user profiles, etc?

so that’s good that it’s still enforcing AD authentication.

I grabbed the code and stripped it down to verify the sections of code I linked above are working properly on my test site, and so far, it’s removing the password reset option in the profile area AND it prevents me from trying to change my password from the login screen.

The only difference is that you mentioned your site is a multisite and my testing site is a single site. Let me set up a mutlisite and see if I can replicate this issue.

a couple of follow-up questions: if they attempt to reset their password in the profile area, does it succeed or do they get an error? If it succeeds, if they log out, can they log back in with the new password (ie bypassing directory authentication)?

Relevant section of code is here : https://plugins.trac.www.ads-software.com/browser/wpdirauth/trunk/wpDirAuth.php#L2207

It uses the filter show_password_fields to hide the password change fields and change the password reset message. And it uses the filter allow_password_reset to disallow a user marked as a dirAuth user to change their password. I don’t see any mention of changes with those two filters in the docs. The second one relies on wpDirAuthFlag being set to 1 in the user’s metadata. That same flag should be preventing them and you from resetting the password. Can you query your database for a known dirAuth user and look to see if that flag is set in their metadata?