LDAP Plugin Troubles

[aparker]

[Wed Mar 15 11:01:20.401092 2017] [php7:notice] [pid 1887] [client 10.2.20.21:53857] , referer: http://fogurl/fog/management/index.php

[Tom Elliott]

@aparker Is samaccountname actually set to arparker on the ldap server?

It’s making it that far, so connectivity speaking it’s working properly. At least from what I can see.

The sprintf, while not “useful” shouldn’t be preventing issues. If you’re running 1.3.4 on all, then this error should present the same way on all systems.

For what it’s worth I’ve found and hopefully corrected the issue of what you’ve presented here.

[aparker]

@Tom-Elliott It is, yes. It’s the same domain across all sites and FOG servers, so samaccountname will match across all sites and domain controllers. Authentication via that same account works on the other two servers, but not this one.

[george1421]

samaccountname is essentially the NT style account name.

According to the error message the search DN MyDN (which I assume has been obfuscated) didn’t contain the user arparker

Make sure you have the search scope setup correctly of subtree and below

[george1421]

You’ve compared the two FOG server’s settings line by line and to two ldap setups are the same, except for the ldap server being used? Have you change the non-working fog server ldap server to another site’s that is working (just to rule out the DC being at fault)?

[aparker]

@george1421 You are correct, I did obfuscate the DN. The actual DN does match that of the OU containing the group we are searching on.

I’ve compared the configs side by side via the GUI, but was curious where these settings actually get written to compare what is actually being saved. Where are these settings saved?

Great idea on the LDAP server, I haven’t tried that. I had been pointing it to the FQDN of the domain and letting DNS pick the closest DC. I’ll try pointing it a DC that I know works and see how that goes.

[george1421]

@aparker The settings are saved in the mysql/mariadb database, in the LDAPServers table.

Do you/are you using any non-ascii characters (umlaut or accent characters) in the search DN or user accounts?

As for the ldap server value, we have not tested using the fqdn of your AD. In my case I always used the IP address of the closest AD/DC server that way I “know” which server its querying.

[aparker]

@george1421 No non-ascii characters in the DN or user account. I just tested a known good LDAP server, but still no dice. I even went so far as to change one of the working FOG servers from the domain FQDN to the IP of a local DC and confirmed it worked. I then used that same DC in the non-working FOG LDAP config, but authentication still fails.

[george1421]

@aparker I just sent you an IM (little talk bubble on FOG Forum tool tray).

And your apache error log is still throwing the same error?

Is there any firewall between the fog server and AD?

But if that was the case, the ldap plugin should have thrown a different error before this point.

[aparker]

@george1421 George hooked me up after sending him a screenshot. Turned out to be something incredibly simply on my part–search scope was set to “Base and Subtree” instead of “Subtree and below”. I seriously compared these side by side I don’t know how many times, but my brain was not seeing that difference for some reason.

Really appreciate the help!