Hi, David. Please provide screenshots of all your CR's configuration pages with all your settings. You can use any image hosting service you like to share them.

We don't have an image hosting service, so I am posting the settings below: **Cache Refresh tab** Refresh Method: Copy Source attribute to destination attribute: uid-->uid, cn-->displayName, sn-->sn, givenName-->givenName Polling Interval: 16 Server IP Address: 192.168.1.1 [note: not the actual IP address for the Gluu server] Snapshot Folder: /var/ox/identity/cr-snapshots Snapshots count: 10 Keep external persons: checked Load source data with limited search: not checked Search size limit: 1,000 Cache Refresh: Enabled **Customer Backend Key/Attributes tab** Key attribute: uid Object Class: person Source attribute: uid, givenName, sn, cn Custom LDAP filter: blank **Source Backend LDAP Servers tab** Name: DSTREE Use Anonymous Bind: blank Bind DN: cn=admin,o=unt Max connections: 500 Level: 0 Server: LDAPserver.edu:636 [note: not actual server name] Base DN: ou=people,o=edu Use SSL: checked **Inum LDAP Server tab** Default Inum Serer: unchecked Name: local_inum Bind DN: cn=directory manager, o=site Max connections: 10 Level: 0 Server: localhost:1636 Base DN: o=site Use SSL: checked

Thanks. >I confirmed there is connectivity between my Gluu server and the LDAP server by running a simple ldapsearch query from the Gluu server console and it worked fine Please provide the exact command you used for this test. We also need to know the exact version of your package, you can check with `# rpm -qi gluu-server-3.0.1`

ldapsearch -x -H ldaps://ldapserver.edu:636 -W -D cn=admin,o=edu "uid=xxxxx" I copied and pasted the command you supplied into the console, but the result I received was: package gluu-server-3.0.1 is not installed

Ok, please try `# rpm -qi gluu-server-3.0.0` then. Please note you need to run `rpm` outside of container

My apologies, I ran the command from the wrong server! Here are the results when I ran it from the correct server: Name : gluu-server-3.0.1 Version : 2 Release : 1.rhel7 Architecture: x86_64 Install Date: Mon 20 Mar 2017 02:41:37 PM CDT Group : Gluu Size : 1542093528 License : MIT Signature : RSA/SHA256, Fri 03 Mar 2017 02:02:58 PM CST, Key ID 5b76117e0544ba38 Source RPM : gluu-server-3.0.1-2-1.rhel7.src.rpm Build Date : Sun 26 Feb 2017 09:48:15 AM CST Build Host : rhel7-rpm Relocations : (not relocatable) Packager : Gluu support <support@gluu.org> Vendor : Gluu, Inc. Summary : Gluu chroot CE environment Description : Gluu base deployment for CE

A few tips: 1. `Source attribute to destination attribute`, you don't need to map anything if the attribute names are the same. 2. Do you see oxTrust making ldap requests to your backend server? Watch the logs when CR runs to make sure. Do you see any errors in the backend LDAP server logs? 3. Please also attach the oxtrust log file. There could be some hints there too. 4. Are you using a cache refresh interception script? This is not required, but I did see a message about the script.

Two other things you could also check, in addition to suggested by Michael: 1. If possible, try to use backend's LDAP port not protected by SSL (I guess it will be port 389). Don't forget to uncheck "Use SSL" checkbox in CR's settings. 2. Using tools like **Wireshark** or **tcpdump**, check whether any connection attempts to your backend are taking place at all.

Thanks for the added suggestions. Here's what I've been able to try so far: **1. Source to Destination attributes: **I deleted the mapping for the attributes named the same. This didn't affect the issue. **2. Logs:** I'll post the oxTurst log at the end of this posting. As for backend LDAP server logs, I was told, "There aren't any...The /db/ds/nds.log file only shows critical database issues, but doesn't not log activity. That's normal for eDirectory." **3. Interception Scripts: ** No, not using any cache refresh interception scripts that I'm aware of. I'm setting up Gluu in a dev/proof of concept environment and--so far--I'm only doing vanilla things. Later, we will probably try those but for now just attempting to connect to the LDAP database. Just to be clear, I'm assuming you mean the scripts you can set in Configuration/Manage Custom Scripts. The only scripts there are the samples that came with Gluu. I checked each tab to make sure all the scripts were disabled. There was one that was enabled (dynamic_permission under Dynamic Scope, I think)--not sure how it got enabled--but I disabled and re-ran cache refresh but it had no effect. **4. Disable SSL:** I tried the non-SSL port. I'll post the chache refresh log at the end of this message, but still no change. **5. Wireshark or tcpdump:** I see tcpdump is installed on the LDAP server. I'm assuming this is the server you want me to run it from and not the Gluu server? I'm not familar with tcpdump, so it'll take me a little while to understand it and run it with the correct parameters. I will post the results for that as soon as I can. But if you know the correct/useful settings to use, I'm all ears. **Oxtrust_Cache_Refresh log after hitting both Update and Update and Validate (SSL enabled)** 2017-03-23 10:22:04,146 ERROR [pool-2-thread-4] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1055) - Failed to connect to LDAP server using configuration DSTREE 2017-03-23 10:22:04,156 ERROR [pool-2-thread-4] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:268) - Skipping cache refresh due to invalid server configuration 2017-03-23 10:40:04,146 ERROR [pool-2-thread-8] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1055) - Failed to connect to LDAP server using configuration DSTREE 2017-03-23 10:40:04,153 ERROR [pool-2-thread-8] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:268) - Skipping cache refresh due to invalid server configuration 2017-03-23 10:45:45,602 ERROR [qtp2008017533-18] [org.gluu.oxtrust.action.ConfigureCacheRefreshAction] (ConfigureCacheRefreshAction.java:398) - Can't load Cache Refresh scripts. Using default script **OXTrust Log for same time period (SSL enabled)** 2017-03-23 10:25:33,809 ERROR [qtp2008017533-18] [org.jboss.seam.exception.Exceptions] (Exceptions.java:86) - handled and logged exception javax.servlet.ServletException: viewId:/authentication/manageCustomAuthentication.htm - View /authentication/manageCustomAuthentication.htm could not be restored. at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) ~[jsf-api-2.1.28.jar:2.1] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) ~[?:?] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) ~[?:?] at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:199) ~[?:?] at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:74) ~[?:?] at org.jboss.seam.web.RewriteFilter.process(RewriteFilter.java:98) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.web.RewriteFilter.doFilter(RewriteFilter.java:57) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) ~[jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) [jboss-seam-2.3.1.Final.jar:2.3.1.Final] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751) [jetty-servlet-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) [jetty-servlet-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [jetty-security-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) [jetty-servlet-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.Server.handle(Server.java:534) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) [jetty-server-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [jetty-io-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) [jetty-io-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [jetty-io-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [jetty-util-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [jetty-util-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [jetty-util-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [jetty-util-9.3.15.v20161220.jar:9.3.15.v20161220] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [jetty-util-9.3.15.v20161220.jar:9.3.15.v20161220] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_112] Caused by: javax.faces.application.ViewExpiredException: viewId:/authentication/manageCustomAuthentication.htm - View /authentication/manageCustomAuthentication.htm could not be restored. at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:205) ~[jsf-impl-2.1.28-jbossorg-1.jar:?] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) ~[jsf-impl-2.1.28-jbossorg-1.jar:?] at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) ~[jsf-impl-2.1.28-jbossorg-1.jar:?] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) ~[jsf-impl-2.1.28-jbossorg-1.jar:?] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) ~[jsf-api-2.1.28.jar:2.1] ... 51 more 2017-03-23 10:25:37,778 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:416) - authorizationCode : e3384935-add5-4442-8a03-f1f5041d380e 2017-03-23 10:25:37,779 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:419) - scopes : openid user_name profile email 2017-03-23 10:25:37,779 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:422) - clientID : @!2EA2.03B7.4E47.7F65!0001!6345.AFEB!0008!A747.BDC4 2017-03-23 10:25:37,780 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:445) - Sending request to token endpoint 2017-03-23 10:25:37,781 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:447) - redirectURI : https://gluudev.unt.edu/identity/authentication/authcode 2017-03-23 10:25:37,977 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:472) - Session validation successful. User is logged in 2017-03-23 10:25:38,060 INFO [qtp2008017533-10] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:513) - user uid:admin 2017-03-23 10:25:38,069 INFO [qtp2008017533-13] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:141) - Authenticating user 'admin' 2017-03-23 10:25:38,075 INFO [qtp2008017533-13] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:155) - User 'admin' authenticated successfully 2017-03-23 10:25:38,248 INFO [qtp2008017533-19] [org.gluu.oxtrust.ldap.service.OrganizationService] (OrganizationService.java:258) - Starting App version 3.0.1 2017-03-23 10:44:49,136 INFO [pool-2-thread-7] [org.gluu.oxtrust.config.OxTrustConfiguration] (OxTrustConfiguration.java:206) - Loading configuration from LDAP... 2017-03-23 10:45:49,137 INFO [pool-2-thread-10] [org.gluu.oxtrust.config.OxTrustConfiguration] (OxTrustConfiguration.java:206) - Loading configuration from LDAP... **Cache Refresh Log using default LDAP port (no SSL)** 2017-03-23 10:55:06,550 ERROR [qtp2008017533-17] [org.gluu.oxtrust.action.ConfigureCacheRefreshAction] (ConfigureCacheRefreshAction.java:398) - Can't load Cache Refresh scripts. Using default script **OXTrust log for same time period (no SSL)** 2017-03-23 10:55:19,136 INFO [pool-2-thread-9] [org.gluu.oxtrust.config.OxTrustConfiguration] (OxTrustConfiguration.java:206) - Loading configuration from LDAP...

This message seems very bad ``` Skipping cache refresh due to invalid server configuration ``` Maybe post a screenshot of your real configuration somewhere temporary so we can look at it.

Ok, I attempted a tcpdump for traffic between the Gluu server and LDAP server. It didn't pick up any traffic. So, I then used tcpdump to capture ANY traffic to and from the Gluu server but that didn't pick up anything either. I find this odd because the Gluu web interface works just fine, so it should be picking up traffic for that, right?

It sounds like a misconfiguration. Either the hostname is wrong, or there is some other kind of syntax error in the ldap connection details. You know the connection is open because you used ldapsearch from the gluu server to the ldap server.

Well, I'm starting to doubt that I had actually done that ldapsearch from the Gluu server as I tried it again but this time I get "ldapsearch: command not found" error. So, now I'm thinking that I had THOUGHT I had run it from the Gluu server, but really ran it from a different server (I've got 5+ remote connections going here at once, so every Putty session starts to look the same!) Unless this is another problem? Maybe it did work before but there's an issue now? I did find ldapsearch on the Gluu server in /opt/gluu-server-3.0.1/opt/opendj/bin and /opt/gluu-server-3.0.1/opt/symas/bin. So I ran the command again directly from each directory but I get "Please set OPENDJ_JAVA_HOME to the root of a Java 7 (or highter) installation or edit the java.properties file and then run the dsjavaproperties script to specify the java version to be used" and "error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory" errors respectively.

I like opendj ldapsearch: ``` /opt/opendj/bin/ldapsearch -h (host) -p 636 -Z -X -D " cn=admin,o=unt" -w -b "ou=people,o=edu" -s base "objectclass=*" ```

Hi, David. To proper use command line LDAP tools for any tests of Gluu's features, you must run it **from within your container**, it's not enough to run them just at that machine. Here is command that should work in your case (I use opendj's toolset as it's more familiar to me): `# /opt/opendj/bin/ldapsearch -h DAPserver.edu -p 389 -s sub -T -D 'cn=admin,o=unt' -j /tmp/.bpw -b 'ou=people,o=edu' -z 5 '(objectclass=*)'` (`/tmp/.bpw` is file with your backend's password) One thing I would check right away is whether DNS name of your backend can be resolved **from within the container**. Simple ping for its DNS name (I take it you specify your backend by DNS name in CR's configuration) is enough. If it can't be, you need to edit `/etc/resolv.conf` to match your network environment. If name is resolved, but you still can't do search from console, you need to find the reason why it is like that. Most likely it some basic networking issue.

Sorry, had to change the port in that command.

I must confess the whole container thing confuses me. I never know where to do what. At any rate, I think I did this right but I still get a command not found error. Here are my steps: ``` /sbin/gluu-serverd-3.0.1 login ``` This give me a prompt of: -bash-4.2# From here, I noticed I need to do a couple of 'cd ..' commands before I can see any root structure. Here's what I get with an 'ls' command:bin boot dev etc home install lib lib64 media mnt opt proc root run sbin srv sys tmp usr var I then do a 'cd /opt/opendj/bin' and this is what I see: ``` -bash-4.2# cd /opt/opendj/bin -bash-4.2# ls backendstat ControlPanel.app dsreplication ldapcompare ldapsearch list-backends rebuild-index stop-ds backup create-rc-script encode-password ldapdelete ldif-diff make-ldif restore verify-index base64 dsconfig export-ldif ldapmodify ldifmodify manage-account start-ds control-panel dsjavaproperties import-ldif ldappasswordmodify ldifsearch manage-tasks status ``` I see 'ldapsearch' there but, when I run the command, I get: ``` -bash-4.2# ldapsearch -bash: ldapsearch: command not found ```

>I must confess the whole container thing confuses me. Container is just a chroot environment, if it's easier for you to think about it like this. >I see 'ldapsearch' there but, when I run the command... You may need to do `./ldapsearch` instead. But better you should use my or Michael's commands from before **as they are**. The tool's executable is preceded by full path there and should work just fine. If it isn't, then there is something wrong with your container at this point. May be you should consider re-installation.

We assume you are "in" the container. For example: ``` # service gluu-server-3.0.1 login ```

Good Morning! I trust everyone had a pleasant weekend? As for me, my mind kept wondering back to this issue. Sorry, Linux isn't my native OS 'language,' so to speak, so I don't know what chroot is either. I looked it up, though, so I hope I now understand the gist of it at least. It seems to me this is a self contained environment. Does that mean it needs it's own IP address? And does it have it's own firewall rules set? I tried a 'service firewalld stop' command while logged into the container/chroot but that showed firewalld.service wasn't even loaded. Speaking of firewalls, I contacted out data comm team to make sure there were openings in our corp. firewall(s) between the Gluu server and the LDAP server (they are in separate datacenters). They gave me access to a tool I can use to monitor traffic that goes through the firewall. It turns out that ports 389 and 636 were closed between these servers and they opened the ports last Friday. However, I still cannot connect to the LDAP server. I tried another ldapsearch from the gluu server, this time logged into the container/chroot. I couldn't get the command to work when run from /opt/opendj/bin--that appears to be a different flavor of ldapsearch than I'm familiar with. It did run from /opt/symas/bin, though. And I remembered to use the ./ before the command this time! While the ldapsearch ran this time, I'm still getting a "can't contact LDAP server" error. Given that I'm not seeing any traffic from this server hitting the firewall between it and the LDAP server, I think there must be something wrong with the gluu server. I know there's connectivity to/from it because I can bring up the Gluu web interface just fine. Other than that, I'm at a loss.

>Does that mean it needs it's own IP address? And does it have it's own firewall rules set? Freshly installed Gluu CE package shouldn't create any issues with firewalls, unless this issue was already present in the host OS from the beginning. ip addresses and firewall rules are set in host OS's context, also, no need to change anything in the container. Firewall rules at the host OS are very unlikely to be a problem in your case. Usually they allow all outgoing connections. Again, unless there are some special rules in your environment (which is not related to Gluu itself) >Linux isn't my native OS 'language' If you wouldn't mind an advice - you should check some basic courses on Linux administration. In particular, RHCSA and similar course from RedHat are very good and friendly for beginners. DigitalOcean have a lot of very good Linux administration articles on their website too. We must limit our free Community Support in many ways to work within chosen business model, unfortunately. Like, we tend to stick to only Gluu-related issues. We motivate our users to do most of troubleshooting work themselves and resolve all issues related to their internal network infrastructure first. We also expect our users are familiar with basic Linux administration principles too. Inability to search your backend from within container using its ip address and SSL-less LDAP port almost always points to some networking issues, which is out of scope for community support. > Note: I edited the response to remove mention of the managed service. We actually don't offer a managed service any longer. However, each of our [VIP support offerings](http://gluu.org/pricing) include an allotted number of hours for support and consultative calls to resolve these types of issues over a GoTomeeting.

As your next step, you should check whether you can connect to tcp port 389 at your backend from the container. You can use tools like **nc/ncat/netcat, telnet, nmap** to check ports' availability (there are a lot of articles on how to use them for that). If they are not present in container, you can install it there the same way you install packages in the main OS (container uses its own set of packages). You also could ask your backend's admins to use monitoring tools like **tcpdump** and **Wireshark** to check whether connections from your box are reaching it.

Well, I got back from lunch today and had an email from our data comm guy indicating that he noticed traffic was getting through the firewall, so he contacted the LDAP server group and it turns out they hadn't opened the firewall on the LDAP server yet! He got them to open the port and...problem solved! Cache refresh now works! One final question, if you don't mind, before I close this ticket and start testing: Is Gluu designed so that any changes made to an account in the Gluu LDAP database will sync back to the source backend LDAP server(s)? Although I'm connecting Gluu to a test backend LDAP server, I don't want to accidentally make any changes to the accounts there, so I want to make sure I can turn off that feature, if it exists, before playing around with things. I don't recall anything in the documentation about this, but maybe I just missed it.

> Is Gluu designed so that any changes made to an account in the Gluu LDAP database will sync back to the source backend LDAP server(s)? I hasn't been till recently. It's still a new feature and it will be added in 3.0.2. [Github link](https://github.com/GluuFederation/oxTrust/issues/504) It will be an optional feature.

Excellent. That's exactly what we'd want. Thanks, guys, for all your help. Sorry you had to put up with so much that turned out to be a simple firewall issue. I'll be closing the ticket now. Oh, BTW, we defaintely will be purchasing a Gluu support model if my testing shows it will be useful in our organization (which I hope it does).

No problem, David. That's what we're here for. If you run into any other issues just let us know. And whenever you're ready to discuss VIP support just [schedule a meeting](http://gluu.org/booking). Thanks, and we hope to hear from you soon. Will