By: matt dillenkoffer user 10 Mar 2016 at 1:33 p.m. CST

11 Responses
matt dillenkoffer gravatar
Another question: can I just configure the Cache Refresh and leave the authentication configuration section alone to achieve my goal of authenticating based on the users located in an external ldap? Also in the Cache Refresh section what is the intended value for: Server IP Address it's not talked about in the documentation. Is it supposed to be the IP address of the Gluu server itself, or what?

By Aliaksandr Samuseu staff 10 Mar 2016 at 1:42 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Matt. > can I just configure the Cache Refresh and leave the authentication configuration section alone to achieve my goal of authenticating based on the users located in an external ldap? No, isn't possible. CR and oxAuth work in tandem to achieve it. CR creates cached user entries in Gluu's internal LDAP directory (by default), and oxAuth uses these cached entries on certain steps of its own workflows, but final authentication decision depends on LDAP Bind operation's success against the backend. Though you *can* configure CR without changing what source oxAuth will use when authenticating users (by default it's again Gluu's internal directory), but there is little sense in it, you'll get a bunch of unused user entries under "ou=people", that's all. Unless you'll write some custom authentication script that implements your own auth-n workflows. > what is the intended value for: Server IP Address it's not talked about in the documentation. Is it supposed to be the IP address of the Gluu server itself That's correct.

By Aliaksandr Samuseu staff 10 Mar 2016 at 1:50 p.m. CST

Aliaksandr Samuseu gravatar
One obstacle on the way of doing what you had in mind will be the fact that user entries that CR creates lack password attribute. So, you would need at least to write custom CR interception script which would set some passwords for these users. Or import password attributes from your backend, if it allows to do it (AD does not, for example) and their format can be used after importing like that (like, they are in cleartext) After resolving this, those entries won't be that much different from the ones you can create using Gluu's web UI. Can't say for sure whether or not you will be able to log in with them. But this is using the functionality the way it wasn't intended. You can try it at your own risk :) Feel free to let us know what the result is.

By matt dillenkoffer user 10 Mar 2016 at 1:59 p.m. CST

matt dillenkoffer gravatar
I want to do it the recommended way not some strange hybrid way. I just don't understand the working in tandem part. If Gluu can use a seperate LDAP to use for authentication why even have the CR? Can you send me screen shots of a CR and authentication config that work as an example. If I try to just configure authentication the baseDN never gets updated even though the test LDAP connection says successful. I know this stuff isn't supposed to be this hard. I'm sure once someone sees it configured correctly once it all makes sense but until then it's not as easy as one would hope.

By matt dillenkoffer user 10 Mar 2016 at 2:27 p.m. CST

matt dillenkoffer gravatar
Nevermind, I got it working, I had a filter that shouldn't have been there that was messing things up. Thanks for the help and the patients.

By Aliaksandr Samuseu staff 10 Mar 2016 at 2:42 p.m. CST

Aliaksandr Samuseu gravatar
> I just don't understand the working in tandem part You may check [this article](https://ox.gluu.org/doku.php?id=oxtrust:cache_refresh) (though I believe it may be a bit outdated, but in general it describes the workflow correctly). In short: CR is there to consolidate info from different backends into one cached entry that is used as source for attributes further on. But actual authentication will still happen with LDAP Bind against backend. I'm glad it's resolved. CR configuration may be tricky for the first time.

By matt dillenkoffer user 10 Mar 2016 at 3 p.m. CST

matt dillenkoffer gravatar
Well CR is working and i can search for users in Gluu and my legacy ldap users are there, still having trouble with auth config. After pointing the Gluu Server to my backend LDAP and testing LDAP connection successfully a few seconds later I see this in the wrapper.log. Note that the baseDN didn't change even though I updated it in the Authentication Configuration Section.... INFO | jvm 1 | 2016/03/10 20:47:08 | 2016-03-10 20:47:08,272 ERROR [org.gluu.site.ldap.LDAPConnectionProvider] Failed to create connection pool with properties: {baseDNs=o=gluu, certsDir=/etc/certs, useSSL=false, configurationEntryDN=ou=oxauth,ou=configuration,inum=@!5E88.9AD6.F20A.4B47!0002!1C74.F7A6,ou=appliances,o=gluu, binaryAttributes=objectGUID, servers=10.1.138.18:1024, confDir=, maxconnections=1000} INFO | jvm 1 | 2016/03/10 20:47:08 | LDAPException(resultCode=49 (invalid credentials), errorMessage='INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user : INFO | jvm 1 | 2016/03/10 20:47:08 | org.apache.directory.api.ldap.model.exception.LdapAuthenticationException: ERR_229 Cannot authenticate user INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.core.authn.AuthenticationInterceptor.bind(AuthenticationInterceptor.java:669) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:442) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:184) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:636) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:66) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.lang.Thread.run(Thread.java:745) INFO | jvm 1 | 2016/03/10 20:47:08 | INFO | jvm 1 | 2016/03/10 20:47:08 | INFO | jvm 1 | 2016/03/10 20:47:08 | BindRequest = INFO | jvm 1 | 2016/03/10 20:47:08 | MessageType : BIND_REQUEST INFO | jvm 1 | 2016/03/10 20:47:08 | Message ID : 1 INFO | jvm 1 | 2016/03/10 20:47:08 | BindRequest INFO | jvm 1 | 2016/03/10 20:47:08 | Version : '3' INFO | jvm 1 | 2016/03/10 20:47:08 | Name : anonymous INFO | jvm 1 | 2016/03/10 20:47:08 | ', diagnosticMessage='INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user : INFO | jvm 1 | 2016/03/10 20:47:08 | org.apache.directory.api.ldap.model.exception.LdapAuthenticationException: ERR_229 Cannot authenticate user INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.core.authn.AuthenticationInterceptor.bind(AuthenticationInterceptor.java:669) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:442) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:184) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:636) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:66) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.lang.Thread.run(Thread.java:745) INFO | jvm 1 | 2016/03/10 20:47:08 | INFO | jvm 1 | 2016/03/10 20:47:08 | INFO | jvm 1 | 2016/03/10 20:47:08 | BindRequest = INFO | jvm 1 | 2016/03/10 20:47:08 | MessageType : BIND_REQUEST INFO | jvm 1 | 2016/03/10 20:47:08 | Message ID : 1 INFO | jvm 1 | 2016/03/10 20:47:08 | BindRequest INFO | jvm 1 | 2016/03/10 20:47:08 | Version : '3' INFO | jvm 1 | 2016/03/10 20:47:08 | Name : anonymous INFO | jvm 1 | 2016/03/10 20:47:08 | ') INFO | jvm 1 | 2016/03/10 20:47:08 | at com.unboundid.ldap.sdk.LDAPConnection.bind(LDAPConnection.java:1837) INFO | jvm 1 | 2016/03/10 20:47:08 | at com.unboundid.ldap.sdk.LDAPConnectionPool.createConnection(LDAPConnectionPool.java:666) INFO | jvm 1 | 2016/03/10 20:47:08 | at com.unboundid.ldap.sdk.LDAPConnectionPool.<init>(LDAPConnectionPool.java:562) INFO | jvm 1 | 2016/03/10 20:47:08 | at com.unboundid.ldap.sdk.LDAPConnectionPool.<init>(LDAPConnectionPool.java:458) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.gluu.site.ldap.LDAPConnectionProvider.init(LDAPConnectionProvider.java:113) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.gluu.site.ldap.LDAPConnectionProvider.<init>(LDAPConnectionProvider.java:59) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.service.ldap.LdapConnectionService.<init>(LdapConnectionService.java:21) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.createConnectionProvider(AppInitializer.java:335) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.createBindConnectionProvider(AppInitializer.java:341) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.createAuthConnectionProviders(AppInitializer.java:300) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.createAuthConnectionProviders(AppInitializer.java:282) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.recreateLdapAuthEntryManagers(AppInitializer.java:248) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.reloadConfiguration(AppInitializer.java:179) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer.reloadConfigurationTimerEvent(AppInitializer.java:165) INFO | jvm 1 | 2016/03/10 20:47:08 | at sun.reflect.GeneratedMethodAccessor464.invoke(Unknown Source) INFO | jvm 1 | 2016/03/10 20:47:08 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.lang.reflect.Method.invoke(Method.java:606) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.async.AsynchronousInterceptor.aroundInvoke(AsynchronousInterceptor.java:52) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.xdi.oxauth.service.AppInitializer_$$_javassist_seam_1.reloadConfigurationTimerEvent(AppInitializer_$$_javassist_seam_1.java) INFO | jvm 1 | 2016/03/10 20:47:08 | at sun.reflect.GeneratedMethodAccessor463.invoke(Unknown Source) INFO | jvm 1 | 2016/03/10 20:47:08 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.lang.reflect.Method.invoke(Method.java:606) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.Component.callComponentMethod(Component.java:2275) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.core.Events.raiseEvent(Events.java:85) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.async.AsynchronousEvent$1.process(AsynchronousEvent.java:33) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.async.Asynchronous$ContextualAsynchronousRequest.run(Asynchronous.java:80) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.async.AsynchronousEvent.execute(AsynchronousEvent.java:27) INFO | jvm 1 | 2016/03/10 20:47:08 | at org.jboss.seam.async.ThreadPoolDispatcher$RunnableAsynchronous.run(ThreadPoolDispatcher.java:142) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) INFO | jvm 1 | 2016/03/10 20:47:08 | at java.lang.Thread.run(Thread.java:745)

By matt dillenkoffer user 10 Mar 2016 at 3:07 p.m. CST

matt dillenkoffer gravatar
Even after bouncing gluu it comes back up and still thinks the baseDN is o=gluu not ou=users,dc=trio,dc=giab which is what I set it to on the Auth Config section BaseDN* textbox INFO | jvm 1 | 2016/03/10 20:53:26 | 2016-03-10 20:53:26,436 INFO [org.xdi.oxauth.model.config.ConfigurationFactory] Loading configuration from LDAP... INFO | jvm 1 | 2016/03/10 20:53:27 | 2016-03-10 20:53:27,028 INFO [org.xdi.oxauth.model.config.ConfigurationFactory] Configuration loaded successfully. INFO | jvm 1 | 2016/03/10 20:53:27 | 2016-03-10 20:53:27,070 ERROR [org.gluu.site.ldap.LDAPConnectionProvider] Failed to create connection pool with properties: {baseDNs=o=gluu, certsDir=/etc/certs, useSSL=false, configurationEntryDN=ou=oxauth,ou=configuration,inum=@!5E88.9AD6.F20A.4B47!0002!1C74.F7A6,ou=appliances,o=gluu, binaryAttributes=objectGUID, servers=10.1.138.18:1024, confDir=, maxconnections=1000} INFO | jvm 1 | 2016/03/10 20:53:27 | LDAPException(resultCode=49 (invalid credentials), errorMessage='INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user : INFO | jvm 1 | 2016/03/10 20:53:27 | org.apache.directory.api.ldap.model.exception.LdapAuthenticationException: ERR_229 Cannot authenticate user

By matt dillenkoffer user 10 Mar 2016 at 3:21 p.m. CST

matt dillenkoffer gravatar
I even found the oxIDPAuthentication value in Gluu's openDJ ldap which has these values which for some reason the BaseDN value is not being used and the original o=gluu is being used.... {"type":"auth","name":"auth_ldap_server","level":0,"priority":0,"enabled":true,"version":1,"fields":[],"config":"{\"configId\":\"auth_ldap_server\",\"bindDN\":\"uid=admin,ou=system\",\"bindPassword\":\"lc0Oex7qiYA=\",\"servers\":[\"10.1.138.18:1024\"],\"maxConnections\":1000,\"useSSL\":false,\"baseDNs\":[\"ou=users,dc=trio,dc=giab\"],\"primaryKey\":\"cn\",\"localPrimaryKey\":\"cn\",\"useAnonymousBind\":false,\"enabled\":true,\"version\":0}"}

By matt dillenkoffer user 10 Mar 2016 at 3:24 p.m. CST

matt dillenkoffer gravatar
IDK at this point it really looks like a bug in Gluu, please tell me where I may be going wrong.

By matt dillenkoffer user 11 Mar 2016 at 8:34 a.m. CST

matt dillenkoffer gravatar
Aliaksandr, are you still working this ticket or do I need to submit a new one?

By Aliaksandr Samuseu staff 12 Mar 2016 at 8:29 a.m. CST

Aliaksandr Samuseu gravatar
Sorry, Matt, we have an issue with notifications on the boards atm, I forgot about the ticket and haven't been notified about your new posts either. But as you already have created a new ticket for that, I'm will close this one now.