By: Neemesh Patel user 03 May 2016 at 9:10 a.m. CDT

12 Responses
Neemesh Patel gravatar
Hi, I'm in the process of trying to have Gluu use our LDAP server to lookup the accounts. I originally got myself into a mess which locked me out of the Gluu server by changing the settings in "manage authentication" to try and use our extenral LDAP server. Thanks to Gluu support I was able to undo this and get this back to using it's own internal LDAP openDJ and I could login once more. I was hoping for some help from the LDAP/Gluu guru's as before now, we never really used LDAP so I may not be understanding things correctly. We have an external LDAP server (not active directory, we use IBM Domino) which we want to use for user accounts. I can retrieve information from this if I test it via CLI:- - /opt/opendj/bin/ldapsearch -h 192.168.0.xx -p 389 -D "cn=directory manager" -w secret -b "o=companyID" "(uid=John Snow)" Where 192.168.0.xx is the IP address of the LDAP server, 389 is the port (at the moment it's all http, I will move things to https later but right now, I just wanted to focus on a more basic setup), "cn=directory manager" is a new user I added to our Domino directory to use for querying information, "secret" is the password associated with that account, "o=companyID" is the organisation we want to search and "uid=John Snow" is the user to pull information for. This returns information for that user so I believe the LDAP server is working along with those parameters used, so now it's the case of having this marry up with Gluu. What I now would like to do is have Gluu interface with the external LDAP server so it automatically pulls user accounts from there. I think this is where "cache refresh" comes in rather than the main "manage authentication" which I tried before and got myself into the mess. However I am struggling to get cache refresh working (it may be a fundamental understanding of LDAP I'm not grasping, so don't rule out the obvious). Using the information in https://www.gluu.org/docs/cache-refresh/#configuring-cache-refresh-from-oxtrust I have configured it as below but so far have been unable to login with users in our Domino LDAP server. Once I click "Update & Validate script" I get the message "Can't load Cache Refresh scripts. Using default script". - Is this an error or just an information message to inform me there is no custom Jython being used? Once this has been configured I can't find users from our external LDAP server in Gluu so something isn't configured correctly I'm sure. - Is there anything you can see that I may have configured wrong or have misunderstood? - Is there any additional logs that will confirm if the LDAP connection is failing? (oxtrust_cache_refresh.log simply says "ERROR [org.gluu.oxtrust.action.ConfigureCacheRefreshAction] (ajp-bio-127.0.0.1-8009-exec-20) Can't load Cache Refresh scripts. Using default script") Thanks! In cache refresh, I have changed the following (all other options are default):- 1) Cache Refresh - Refresh Method: Copy - Source attribute to destination mapping: mail -> mail, uid -> uid - Cache refresh: Enable 2) Customer backend key/attributes - Key attribute: mail - object class: person - source attribute: uid, mail, cn (all of these are individual fields which I create using the "add source attribute" link) 3) source backend ldap servers - Name: Company-LDAP - Use anonymous bind: False - Bind DN: cn=directory manager - Server: 192.168.0.xxx:389 - Base DN: o=companyID - Change Bind password: Secret - Use SSL: False

By Mohib Zico staff 03 May 2016 at 9:39 a.m. CDT

Mohib Zico gravatar
We are going to upload a complete CR tutorial video by this week, hopefully it will help you to configure CR. >> Once I click "Update & Validate script" I get the message "Can't load Cache Refresh scripts. Using default script". That's normal. You just need to use 'Update' button. 'Update and Validate Script' is for them who are using custom scripts ( i.e. calculating ePSA or some attribute like these ) in Cache Refresh. >> (oxtrust_cache_refresh.log simply says "ERROR [org.gluu.oxtrust.action.ConfigureCacheRefreshAction] (ajp-bio-127.0.0.1-8009-exec-20) Can't load Cache Refresh scripts. Using default script") That's not the error which might show you why your CR is failing. Check oxtrust_cache_refresh.log. >> Source attribute to destination mapping: mail -> mail, uid -> uid uid --> uid part is wrong. As I can see you are using 'mail' as primaryAttribute for your backend, so it would be 'mail --> uid' But you also might face another problem with that... because the value of mail and uid are different. ( Different in a sense that.. mail has @something.com and uid is only username )

By Neemesh Patel user 09 May 2016 at 4:03 a.m. CDT

Neemesh Patel gravatar
Hi, I tried changing it to mail -> uid as we're in development at the moment so I have some room to try things out. Didn't appear to make a difference so far and nothing is jumping out in the oxtrust_cache_refresh.log. In fact all the log says is > INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (localhost-startStop-1) Initializing CacheRefreshTimer... Even though the "pooling interval" is set to 15 minutes, the "initialzing cacheRefreshTimer" log entry is only appearing once when you restart the server. Shouldn't that log entry appear on each pooling interval (in this case, every 15 mins) or is that an incorrect assumption? To try and check if users are coming in, I am running the following CLI command (in case this is wrong for checking new users being imported): ``` /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "cn=directory manager" -w "secret" -b 'o=gluu' "(objectClass=*person)" ``` I can't see anything in the oxtrust_cache_refresh.log that indicates a failure or error to connect to the LDAP server or an error, is there another log I should be referrign to? Do you have an update on the CR tutorial as that I'm sure would be of great help to a novice like myself? Thanks

By Mohib Zico staff 09 May 2016 at 4:43 a.m. CDT

Mohib Zico gravatar
>> Even though the "pooling interval" is set to 15 minutes, the "initialzing cacheRefreshTimer" log entry is only appearing once when you restart the server. Shouldn't that log entry appear on each pooling interval (in this case, every 15 mins) or is that an incorrect assumption? Please make sure you have enabled the Cache Refresh. >> Do you have an update on the CR tutorial as that I'm sure would be of great help to a novice like myself? Yes it's in progress, will be published soon.

By Neemesh Patel user 09 May 2016 at 4:56 a.m. CDT

Neemesh Patel gravatar
> Please make sure you have enabled the Cache Refresh. I can confirm it is enabled. To enable it I set the option "cache refresh" to "enabled" under "configuration>cache refresh>cache refresh tab". > Yes it's in progress, will be published soon. Great, I look forward to it! Hopefully it will help me out and then I can stop bothering you all so much :) As for the question regarding the logs to look at, is there any other logs I can refer to on the system to try and troubleshoot or is oxtrust_cache_refresh.log the only one to refer to when trying to get cache refresh to work? Thanks

By Mohib Zico staff 09 May 2016 at 5:12 a.m. CDT

Mohib Zico gravatar
>> As for the question regarding the logs to look at, is there any other logs I can refer to on the system to try and troubleshoot or is oxtrust_cache_refresh.log the only one to refer to when trying to get cache refresh to work? That's the primary log for Cache Refresh. Other than that... we use wrapper.log, oxtrust_ldap_persistence, oxtrust_persistence and /var/ox/oxtrust/vds_snaphshots/ to troubleshoot CR issues.

By Neemesh Patel user 09 May 2016 at 6:35 a.m. CDT

Neemesh Patel gravatar
Thanks. I previosuly asked: > Even though the "pooling interval" is set to 15 minutes, the "initialzing cacheRefreshTimer" log entry is only appearing once when you restart the server. Shouldn't that log entry appear on each pooling interval (in this case, every 15 mins) or is that an incorrect assumption? You advised that I should double check that cache refresh is enabled which I believe it is. Should I take that as inferring that it should be logging "initialzing cacheRefreshTimer" on every pooling interval (every 15 mins)? If so, do you have any advice on why our installation isn't doing this and any troubleshooting steps to resolve it, as this could be related to our issue (i.e. cache refresh isn't running for some reason)? I'm not sure if this is related at all, but under "configuration>manage authentication>default authentication method tab", the authetication mode is set to "internal" instead of "Default". Just thought I would mention that in case it is related at all.

By Mohib Zico staff 09 May 2016 at 7:14 a.m. CDT

Mohib Zico gravatar
>> You advised that I should double check that cache refresh is enabled which I believe it is. Should I take that as inferring that it should be logging "initialzing cacheRefreshTimer" on every pooling interval (every 15 mins)? 'Initializing CacheRefreshTimer' is the very first message after a tomcat service restart. If your CR is enabled, you will see message from CR like 'Loading backend data...'. >> If so, do you have any advice on why our installation isn't doing this and any troubleshooting steps to resolve it, as this could be related to our issue (i.e. cache refresh isn't running for some reason)? Same what I told you before. :-) Check logs... >> I'm not sure if this is related at all, but under "configuration>manage authentication>default authentication method tab", the authetication mode is set to "internal" instead of "Default". Just thought I would mention that in case it is related at all. No, 'Manage Authentication' is different. Documentation is available [here](https://gluu.org/docs/oxtrust/configuration/#configuration)

By Neemesh Patel user 09 May 2016 at 7:46 a.m. CDT

Neemesh Patel gravatar
> 'Initializing CacheRefreshTimer' is the very first message after a tomcat service restart. If your CR is enabled, you will see message from CR like 'Loading backend data...'. The log entry "Loading backend data..." isn't appearing in our logs anywhere, just the first Initializing message. > Same what I told you before. :-) Check logs... > That's the primary log for Cache Refresh. Other than that... we use wrapper.log, oxtrust_ldap_persistence, oxtrust_persistence and /var/ox/oxtrust/vds_snaphshots/ to troubleshoot CR issues. I checked the logs you mentioned but there wasn't much to go on from what I could see. I turned the logging level up but still no dice (line below). ``` <logger name="edu.vt.middleware.ldap" level="ALL" /> ``` Is there a way to securely send you our server logs (rather than attaching them here to a public ticket as we don;t want them in the public realm) to see if there is anything I am overlooking (it may be easier for the experts to cast their eye over them)? If this is something we can do, which specific logs would you want me to send over (and how would I send them to you securely)? Thanks

By Neemesh Patel user 11 May 2016 at 7:44 a.m. CDT

Neemesh Patel gravatar
Hi, Just wondering if my previous enquiry regarding whether I could provide you with our server logs (providing we can get them to you securely rather than on a public ticket) would be possible to help diagnose why CR isn't working for us (whilst we wait on the CR tutorial)? Thanks

By Neemesh Patel user 16 May 2016 at 5:08 a.m. CDT

Neemesh Patel gravatar
Hi, Any chance someone could let me know if the previous enquiry from the 9th May is possible? Could also update on the status of the CR tutorial? Thanks Neemesh

By Mohib Zico staff 16 May 2016 at 6:57 a.m. CDT

Mohib Zico gravatar
Hello Neemesh, >> Just wondering if my previous enquiry regarding whether I could provide you with our server logs (providing we can get them to you securely rather than on a public ticket) Sorry... community support is limited to forums. >> Could also update on the status of the CR tutorial? If you meant video tutorial... we will inform you when it's done.

By Mohib Zico staff 16 May 2016 at 10:43 a.m. CDT

Mohib Zico gravatar
Three videos upload in our youtube [channel](https://www.youtube.com/user/GluuOrg).