Hi Steve, There is just one reason of this error ( `due to invalid server configuration` ). It's actually hard to found this but you need to check "every bit" of this config. Before everything... are you using OpenLDAP? If yes, a big "don't" :-) Install Gluu Server with OpenDJ; OpenLDAP create LOT of problems here in our stack.

OK...checking "dpkg -l | grep ldap": I've got these in the main server: ii ldap-utils 2.4.42+dfsg-2ubuntu3.3 amd64 OpenLDAP utilities ii libldap-2.4-2:amd64 2.4.42+dfsg-2ubuntu3.3 amd64 OpenLDAP libraries I've also got these inside the gluu-server-3.1.4 context: ii libaprutil1-ldap:amd64 1.5.4-1build1 amd64 Apache Portable Runtime Utility Library - LDAP Driver ii libldap-2.4-2:amd64 2.4.42+dfsg-2ubuntu3.2 amd64 OpenLDAP libraries I remove the OpenLDAP ones and install OpenDJ? Is there a config how-to with Gluu & OpenDJ? Looks like it's more involved than just adding utils via apt.

There might be some libs there.... ``` root@idp1:~# service gluu-server-3.1.4 login gluu-server-3.1.4 is running... logging in... root@idp1:~# dpkg -l | grep ldap ii libaprutil1-ldap:amd64 1.5.4-1build1 amd64 Apache Portable Runtime Utility Library - LDAP Driver ii libldap-2.4-2:amd64 2.4.42+dfsg-2ubuntu3.2 amd64 OpenLDAP libraries root@idp1:~# ``` - How to find out if OpenLDAP is there as your LDAP server? ( for my case, answer is no ) ``` root@idp1:~# service solserver status solserver: unrecognized service root@idp1:~# ``` - How to find if OpenDJ is there? ``` root@idp1:~# service opendj status Usage: /etc/init.d/opendj { start | stop | restart } root@idp1:~# ```

OK... so should Opendj be installed inside the gluu server chroot, or outside of it?

It's really complex to 'replace' existing LDAP of any Gluu Server. It's easier to re-install Gluu Server in new VM with OpenDJ. However, it's better to confirm if you have really have OpenDJ or OpenLDAP inside. Those commands I provided above should answer the question.

So if I understand correctly, the results below demonstrate that Gluu is running with OpenDJ, not OpenLDAP. Correct? If so, what's the next thing to look at as to why Cache Refresh isn't working? ``` root@vva-er-gluu:/home/eraccount# service gluu-server-3.1.4 login gluu-server-3.1.4 is running... logging in... mesg: ttyname failed: Success root@vva-er-gluu:~# service opendj status Usage: /etc/init.d/opendj { start | stop | restart } root@vva-er-gluu:~# service solserver status solserver: unrecognized service ```

Alright, cool. Fortunately I got same issue for one of our 'Managed customer' and here is what I did to found what's wrong where: ``` Problem in oxtrust_cache_refresh.log: 2018-10-25 21:52:21,041 ERROR [ForkJoinPool.commonPool-worker-1] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1080) - Failed to connect to LDAP server using configuration source 2018-10-25 21:52:21,082 ERROR [ForkJoinPool.commonPool-worker-1] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:283) - Skipping cache refresh due to invalid server configuration 2018-10-25 21:52:21,291 DEBUG [ForkJoinPool.commonPool-worker-1] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:181) - Allowing to run new process exclusively 1. 'Disabled' CR running from oxTrust. 2. Trying to telnet backend LDAP server:port. Opps telnet not installed. Let's install it. [root@idpprod01 ~]# telnet abcd.something.com 636 -bash: telnet: command not found [root@idpprod01 ~]# yum install telnet 3. OK, telnet good. [root@idpprod01 ~]# telnet abcd.something.com 636 Trying xxxxx... Connected to abcd.something.com. Escape character is '^]'. ^] telnet> quit Connection closed. [root@idpprod01 ~]# 4. See what's inside LDAP as Cache Refresh configuration. Run below command. Log into gluu-server container first, become user 'ldap' and then: /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "cn=directory manager" -w 'admin_pass' -b 'o=gluu' -T 'oxTrustConfCacheRefresh=*' oxTrustConfCacheRefresh 5. Checked bindDN user, baseDN/s. Now let's check password. I am taking 'bindPassword' value from above output and decoding it to make sure my password is correct: -bash-4.2# /opt/gluu/bin/encode.py -d 'encode_password_thing==' abcd1234 -bash-4.2# 6. If everything looks good then I am going to do a ldapsearch in backend: /opt/opendj/bin/ldapsearch -h backend_ldap_server -p 636 -Z -X -D "cn=hello,ou=gluu,o=org" -w 'binDN_password' -b 'baseDN_tree' 'objectclass=*' 7. Failed. I could not ldapsearch. Result: Turned out, my bindDN password is wrong.... ```

OK... there could be some sort of password problem... when I run the ldapsearch to pull out the LDAP server backend values, it includes this: "bindPassword":"5lDuQTxSthiyKYs435Rsv2D2pt2c1xKeTHYyCqSsHHw=" However, that's not the password I set. Is that just the encrypted hash? If so, then the password thing shouldn't be an issue, as I can log in successfully with the password I set and see data returned with this command, both inside and outside the Gluu chroot: /opt/opendj/bin/ldapsearch -h eres-dcd.eresources.com -D gluu-sync -w "password>" -b"dc=eresources,dc=com" -s sub "(objectClass=user)" givenName

>> "bindPassword":"5lDuQTxSthiyKYs435Rsv2D2pt2c1xKeTHYyCqSsHHw=" Yes, this is encrypted. I think you should compare this hashed pass with your clear text one just to confirm ( step 5 in my stated process ).

OK... I've successfully verified the Bind password using the decrypt-and-test-ldapsearch method. I can get a listing of users from LDAP with the bind user and password described in the settings, but I'm still getting this in the cache refresh log: 2018-10-29 14:32:22,214 ERROR [Thread-177722] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1080) - Failed to connect to LDAP server using configuration Eres-dcd 2018-10-29 14:32:22,226 ERROR [Thread-177722] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:283) - Skipping cache refresh due to invalid server configuration

Ok. Couple of things you can check : - Enhance log level of oxTrust ( Configuration > JSON config > oxTrust ) and see if you are getting any indication 'which exact' value of 'Source' ( in your case 'Eres-dcd' ) it can't read properly. - Change 'Eres-dcd' naming to 'source' only. - Get a full dump of your 'o=gluu' and share with us. - Send us all information screenshot from Cache refresh. >> I can get a listing of users from LDAP with the bind user and password described in the settings, but I'm still getting this in the cache Yes, two things are different. you can ldapsearch properly which means OpenDJ can read the backend tree. Your cache refresh can't read backend directory because it's not getting proper value in Cache Refresh config. Hard to find but easy to solve issue.

Questions: 1. Which logs other than /opt/gluu/jetty/identity/logs/oxtrust_cache_refresh.log should I be looking at? With log levels set to TRACE, I'm not seeing any such details in the cache refresh log. 2. I'm not sure what you mean by "Change eres-dcd to source only"? 3. Posted in next post 4. Links: https://photos.app.goo.gl/UcFKs2eEVHx4fk8P9 https://photos.app.goo.gl/8JhZBwdYUHqsXSye8 https://photos.app.goo.gl/8rTRDLj774bbq4bA9 https://photos.app.goo.gl/8rTRDLj774bbq4bA9

Full o=gluu response (password modified): ``` dn: ou=oxtrust,ou=configuration,inum=@!BD71.78A2.3E61.821D!0002!5089.4C19,ou=appliances,o=gluu oxTrustConfCacheRefresh: {"sourceConfigs":[{"configId":"Eres-dcd","bindDN":"CN=Gluu-sync,OU=Admins,DC=eresources,DC=com","bindPassword":"<pw>","servers":["eres-dcd.eresources.com:389"],"maxConnections":30,"useSSL":true,"baseDNs":["ou=Software,ou=eResources People,dc=eresources,dc=com"],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":false,"version":0,"level":0},{"configId":"Eres-dcg","bindDN":"CN=Gluu-sync,OU=Admins,DC=eresources,DC=com","bindPassword":"gNcmOcMjTzSMJCT3C8LjVw==","servers":["eres-dcg.eresources.com:389"],"maxConnections":30,"useSSL":true,"baseDNs":["ou=Software,ou=eResources People,dc=eresources,dc=com"],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":false,"version":0,"level":0}],"inumConfig":{"configId":"local_inum","bindDN":"cn=directory manager","bindPassword":"qa4g0Mv28aaa7bJsghUDjA==","servers":["localhost:1636"],"maxConnections":10,"useSSL":true,"baseDNs":["o=site"],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":true,"version":0,"level":0},"targetConfig":{"configId":null,"bindDN":null,"bindPassword":null,"servers":[],"maxConnections":0,"useSSL":false,"baseDNs":[],"primaryKey":null,"localPrimaryKey":null,"useAnonymousBind":false,"enabled":false,"version":0,"level":0},"ldapSearchSizeLimit":1000,"keyAttributes":["SamAccountName"],"keyObjectClasses":["person"],"sourceAttributes":["mail","givenName","sn"],"customLdapFilter":"(objectClass=user)","updateMethod":"copy","defaultInumServer":false,"keepExternalPerson":true,"useSearchLimit":false,"attributeMapping":[{"source":"SamAccountName","destination":"uid"},{"source":"givenName","destination":"cn"},{"source":"sn","destination":"sn"},{"source":"mail","destination":"mail"}],"snapshotFolder":"/var/ox/identity/cr-snapshots","snapshotMaxCount":10} ```

>> Which logs other than /opt/gluu/jetty/identity/logs/oxtrust_cache_refresh.log should I be looking at? With log levels set to TRACE, I'm not seeing any such details in the cache refresh log. It doesn't? It should have, I'll double check. >> I'm not sure what you mean by "Change eres-dcd to source only"? Sorry.. I meant.. just change the name from 'eres-dcd' to 'source'. I'll check your shared data and will suggest as much as I can. Thanks!

Hello Steve, So.. here are my suggestions: - I see that your backend is using non-SSL port ( 389 ) and 'Use SSL' feature is on. Please disable 'Use SSL' button. - Add one active directory first; say 'dcd' ... run Cache Refresh.. see if your data is coming properly or not. If everything is okay then add another one 'dcg' - You don't need 'enable' Manage Authentication for Cache Refresh running. - When you will enable 'Manage Authentication' section; make sure you do that in new browser; so if you are locked out.. you will be able to change it back to 'localhost:1636' again from previous browser.