Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter GarethHW

    (@gjhw)

    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.

    Thread Starter GarethHW

    (@gjhw)

    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).

    Thread Starter GarethHW

    (@gjhw)

    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!

    Thread Starter GarethHW

    (@gjhw)

    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! 🙂

    Thread Starter GarethHW

    (@gjhw)

    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 7 years, 10 months ago by GarethHW.
Viewing 5 replies - 1 through 5 (of 5 total)