LDAP Plugin Troubles
-
Server
- FOG Version: 1.3.4
- OS: Ubuntu Server 16.10
Description
Within the last month I’ve built and deployed two other nearly identical FOG servers in two other sites, both of which are successfully using the LDAP plugin to authenticate against the same Active Directory domain. I’ve built a third FOG server today, also using essentially the same identical configuration. However with this build, I’m having issues authenticating to Active Directory with the LDAP plugin. All three FOG servers are authenticating to the same domain (albeit to different domain controllers in different sites). I’ve double and triple checked the LDAP plugin config on the non-working server, going so far as to literally copy/paste the settings from the two working configs directly into the new server. I’m confident the settings are correct and match a known-good configuration.
I’m seeing the following messages in the Apache error log (I’ve anonymized the DN path and FOG URL):
[Wed Mar 15 11:00:22.444705 2017] [php7:notice] [pid 1500] [client 10.2.20.21:53840] Plugin LDAP::authLDAP() Search results returned false. Search DN: MyDN; Filter: (&(|(objectcategory=person)(objectclass=person))(samaccountname=arparker)), referer: http://fogurl/fog/management/index.phpI’m not seeing any of these errors on the FOG server in the other two working sites. Any thoughts on what might be going on here?
EDIT: For some reason only one line from the error log is being displayed on the forum, despite the preview showing it correctly. I’m replying with the other two lines from the error log.
-
@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!
-
[Wed Mar 15 11:01:20.401032 2017] [php7:warn] [pid 1887] [client 10.2.20.21:53857] PHP Warning: sprintf(): Too few arguments in /var/www/fog/lib/plugins/ldap/class/ldap.class.php on line 829, referer: http://fogurl/fog/management/index.php -
[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 -
@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.
-
@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.
-
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 arparkerMake sure you have the search scope setup correctly of
subtree and below -
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)?
-
@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.
-
@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.
-
@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.
-
@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.
-
@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!
