Please double check your server's configuration ( BindDN, password, BaseDN, server address ). IDP is unable to read your backend AD.

What kind of LDAP server is it? Any logs from the LDAP server?

When I copy and past the above config into "ldapsearch" on the cli, it connects successfully. As for the kind of LDAP server and its logs, I'll have to talk to someone else internally and get back to you.

The logs from the backend LDAP server might provide the info as to why its not connecting, or if its even seeing the request. There is also an LDAP log for oxtrust. Check that if possible for error messages and post here. Also, what version of the Gluu Server are you using on what platform?

Hi, Jordan. > Server: <host>:389 > Base DN: dc=<host>,dc=lan That strongly implies you are trying to pull from MS AD, but are you sure you really have an entity with bind DN like this in it: > Bind DN: cn=Directory Manager ? That's more like a bind DN to use for openLDAP/OpenDJ and similar solutions. Make sure you are binding with a DN of a existing user account that have sufficient privileges to access branches you intrested in (better try it first with a domain admin account if it's available)

It appears to be a RedHat 389 Directory server. And yes, I'm able to connect on the command line with: ldapsearch -x -D "cn=Directory Manager" -W -H ldap://<host>.lan

1) When you click "Update" button at Cache Refresh configuration page, do you see message "Cache configuration updated", or similar one, at the top of the page? 2) Can you re-run this ldapsearch line again, with "-p 389" added, just to make sure the port is really accessible? You are running it from the same box where you have gluu installed, is it correct?

But I'd still like to see the oxtrust-ldap.log and the access and error logs snippet from Redhat DS. And the dc=...,dc=... is very common. Many LDAP seervers use it... Also, we really need to know the version of Gluu Server and the platform (centos / ubuntu).

> Any other info I can provide? You could set CR interval to 1minutes and try to monitor wrapper log for some time, paying attention to any suspicious warnings/errors in it with something like that: tail -F /opt/tomcat/logs/wrapper.log

I appreciate the quick feedback. Yes, clicking updates shows "Cache configuration updated" at the top. Running ldapsearch with port 389 works. And yes from same box as gluu-server. Version 2.3.3-1 on Ubuntu Server 14.04. I don't see oxtrust-ldap.log, but I tailed wrapper.log as Aliaksandr suggested and got: INFO | jvm 1 | 2015/08/28 22:14:32 | 2015-08-28 22:14:32,304 ERROR [org.gluu.site.ldap.LDAPConnectionProvider] Failed to create connection pool INFO | jvm 1 | 2015/08/28 22:14:32 | LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server devldap01.consolo.lan:389: java.io.IOException: Unable to establish a connection to server devldap01.consolo.lan/69._._.*:389 within the configured timeout of 100000 milliseconds.') That IP should be resolving to a 10.* address, and it _is_ when I just ssh into the server. But when I'm inside "sudo service gluu-server login" it resolves to one of our public IPs instead. /etc/resolv.conf in the chroot is different from the system's, so I copied the system's, restarted gluu, and that seems to have fixed it. I think there was a question about copying resolv.conf during the setup, but I think it defaulted to No. Guess I should have answered Yes? I don't think it's copying the attributes under "Attributes mapping", but I'll open a separate issue if I can't figure that out next week.

ok, that explains it. Good work... I'm closing the ticket.