Increase LDAP plugin logging
-
LDAP Plugin already writes to the error log.
This is the http error log if I remember correctly.
/var/log/httpd/error_log or /var/log/apache2/error.log
-
Just had a recheck, it’s to the php log, on Ubuntu HTTP log and php log seem to be one in the same, on Redhat it appears to be /var/log/php-fpm/www-error.log
-
Here are our settings. I put incorrect info in the Bind DN so you can still see the format.
I’ve checked all the logs mentioned in this thread but there’s nothing in them that’s ldap related. Additionally, don’t have access to the central ldap server so I can’t inspect it’s logs.
When this ldap info is set and I try to login with my Active Directory account, that’s in the listed Admin Group, nothing happens. The login fields go blank and no error is displayed on the login page. I also can’t find any error information in the logs. I can still use the native fog account to login.Thanks for your help!
-
@jdmiller323 Three things that jump at me:
- LDAP Server port: I think there was a discussion about LDAP ports in the forums not too long ago. Not sure if using a port other than the defaults is causing trouble. Should not but I can’t promise you. Can you make sure it’s using the right port using tcpdump/wireshark?
- Admin Group: Seems like there is a space in that name. I can hear the bells ringing here.
- Bind DN: It has four times
dc=while the Search Base DN has only three. It’s totally valid, just want to point this out so you double check there is no typo in the bind DN.
-
Noticed port on original:
3268, is this the real port you’re connecting LDAP across?Here’s my config, yes the screen looks different, but functionally it is the same:
- Masked sensitive info with example, just in case.
- Cutoff but Non-Administrator Group is same as mobile group. You do not need this filled in. It makes little sense to have both group fields filled in with the exact same data. The admin group overrides the mobile
Notice, spaces in the admin ugroup is perfectly fine. I have multiple groups, by simply adding a comma so:
domain admins,desktop administrators… is perfectly fine.
-
You can only increase the debug log using checkpoints. You can use the error_log PHP function to debug the outputs.
-
@Tom-Elliott
Yes 3268 is the correct port. That’s the one corporate IT wants us to use. I’ve used it to configure LDAP on other applications so it does work.
At the bottom of your settings you have Display Name Attribute. I don’t have that option. How were you able to get that option? -
@jdmiller323 that’s a different version of fog GUI I’ve been working on. That part doesn’t exist for 1.5.x.
I think the port number is the problem though.
-
@jdmiller323 said in Increase LDAP plugin logging:
Yes 3268 is the correct port. That’s the one corporate IT wants us to use.
That’s fine. As I said there might be a bug in FOG with the port. Can you please use tcpdump/wireshark on your FOG server to see if it actually opens a TCP connection to the LDAP server on this port or not.
-
@jdmiller323 Finally found some more time to look into this again and do some testing. I don’t have AD/LDAP servers here to test with (might set one up if you still can’t make it work) but I have played with the LDAP plugin to figure out a few basic things:
- LDAP Server Port 3268 should work as expected - I added it through FOG settings, created a new LDAP connection using it and I can see TCP connections. So my first guess on port being an issue was wrong!
- LDAP Server Address is meant as a plain hostname or IP address instead of the LDAP schema name (e.g.
ldap://servername) used in many other places! So please useservername.intel.cominstead.
I am fairly sure the later one will help you make this work and I am working on a change in the code that will strip the schema if found in the string.
Update: Pushed a fix.
-
@jdmiller323 @jmvela2x Is this still causing you trouble or were you able to set it up?
