Directory authentication initially succeeded, but no valid profile was found

That error would be thrown when ldap_get_entries returned 0 for the count of entries retrieved for ‘adltest’.

Can you put the contents of this file https://github.com/gilzow/simple-ldap-test/blob/master/ldap.php up on the same server, adjusting lines 10 – 30 to match your situation? This will allow us to remove the WordPress overhead and is easier to use to troubleshoot

Thanks for a speedy response! Here’s the output of ldap.php which is the same regardless of whether I use a user from the top level domain or the subdomain (as you can see everything appears to work!):

Simple LDAP Test
Trying to authenticate adltest…
Checking uid against regex pattern… success!
Checking user password against regex pattern, min/max lengths… success!
Setting up initial connection with dc1.corp.com… success!
Requesting switch to v3 of ldap protocol… success!
Requesting start_tls… success!
Attempting to bind with bind account (bindacct)… success!
Performing search for user using filter sAMAccountName=adltest… success!
Attempting to retrieve record for search match… success!
Attempting to retrieve user’s DN from search match… success!
Attempting to bind with user’s DN and password… success!
adltest authenticated successfully!

This makes me think that the code is looking for an attribute that is not (bt default) stored in the Global Catalogue.

• This reply was modified 6 years, 7 months ago by GarethHW.

Did you have the simpler code above check against the global catalogue as well? Or is it connecting to a specific DC?

The no profiles found error would have been generated at either the
Performing search for user using filter sAMAccountName=adltest… success!
line or at the
Attempting to retrieve record for search match… success!
line so I’m confused as to why it’s working for the simple script and not the plugin since they’re essentially the same…

As for values/properties the plugin is looking for, the default properties are

    'last_name'         =>  'sn',
    'first_name'        =>  'givenname',
    'email'             =>  'mail',

But you can override those via the wpdirauth_ldap_user_keys filter. Your hooked function will receive the above array. Make sure to return an associative array containing the same keys above mapped to the correct AD properties for your situation.

Hi Paul,

I too am confused why the sample script works, I could only assume that the code in the plugin had some extra step but obviously you would know better than I would.

With regard to the test script, I only targeted the global catalogue as targeting port 389 on a DC in the top level domain will never find users in the subdomain.

Just been having a chat with our Active Directory Architect and he is wondering how auth against the GC would work though as he says the users password is not stored there. Maybe this it’s whats giving me the issue?

Maybe I’m trying to fudge multi domain auth by using the GC rather than have a plugin try multiple domain controller / base DN combinations?

Be interested to know you thoughts whether I am just going about this all wrong! ??

the general flow is to search for the user that is attempting to auth (if your situation requires pre-binding, then that user binds first), get their DN, then attempt a second bind with the DN + password of the user attempting to auth. If the bind is successful, then the user is authenticated.

The error you posted in the beginning though indicates the user bind was successful and it’s looking up your properties.

Maybe I’m trying to fudge multi domain auth by using the GC rather than have a plugin try multiple domain controller / base DN combinations?

We have multiple domains in my set up and I connect/query against the GC specifically so I don’t have to know/list out the individual DCs. Since the plugin retrieves the user’s DN, you shouldn’t have to point to a specific domain. Did you try pointing the plugin to the global catalog to test?

It’s always possible you have discovered an edge case bug in the code. Let me know how pointing to the GC goes, and if it’s still broken I’ll send you an alt version with additional logging.

Well it’s good to know I’m not doing anything silly!

Throughout all tests I have been pointing at the GC on 3268, never 389 – can we try the additional logging?

Thanks for all your help with this!

to make it easier, i’m having it dump out data in the error message so we dont have to mess with turning on logs, finding them, etc. I say that because you don’t want to run this on a production server, or run it on a production server for longer than it takes to do a quick test.

Replace the contents of your current copy of wpDirAuth.php with the contents from this version: https://gist.github.com/gilzow/1c8c59baed120f938b4a36d84dbe6563

Try authenticating and then paste the results here, specifically the filter used (will be in square brackets []), and the array contents after “return from get_entries:”.

Hi Paul, here’s the results:

Directory authentication initially succeeded, but no valid profile was found (“get entries” procedure). [(samAccountName=adltest)]
return from get_entries:
array (
‘count’ => 0,
)

Additional info for you…
To make sure that there wasn’t anything totally messed up with the aus.corp.com subdomain, I changed the ldap server, base DN and bind DN and adltest could log in fine (of course, that then means users from corp.com then can’t).

I’m totally baffled. A count of 0 means that the query failed for the filter used for the controller you connected to. It’s possible the Bind DN you used doesn’t have permissions to search, or the adltest user is in a different domain than the one you connected to. Or has a different Base DN.

I want to make sure I’m clear: you used the exact same settings with the simple test script that you used with the plugin and it works with the simple script, but not the plugin?

Hi Paul,

Sorry for the delayed response.

Yes – I used the exact same settings, I double checked and I was able to repeat the outcome.

Due to pressures to get this up and running, I have ended up building a new webserver with PHP 7.0 and migrated the WordPress site to it. This has opened up other authentication plugins that I have been able to get working.

Thanks for all your help in trying to assist with this problem, as much as I would love to know why it wouldn’t work (I too am totally baffled) I can’t spend any more time on the troubleshooting.

Due to pressures to get this up and running, I have ended up building a new webserver with PHP 7.0 and migrated the WordPress site to it. This has opened up other authentication plugins that I have been able to get working.

TOTALLY understand.Sorry we weren’t able to figure it out.