LDAP not working Failed to create LDAP connection pool! Result code: '91'

By: Ed Battye user 20 May 2020 at 9:06 a.m. CDT

7 Responses
Ed Battye gravatar
I have configured gluu to work LDAP, using cache refresh which works however when I try to use AD authentication I cannot get it to work no matter what I try. I have followed the guide and setup my AD server in Manage LDAP Connection and set this as the default authentication method for both authentication mode and oxtrust authentication mode however it hangs when you try to login and eventually times out leaving the below in the logs: ``` 2020-05-20 14:03:14,496 ERROR [Thread-667] [org.gluu.oxauth.service.AppInitializer] (AppInitializer.java:268) - Exception happened while reloading application configuration org.gluu.persist.exception.operation.ConfigurationException: Failed to create LDAP connection pool! Result code: '91' at org.gluu.persist.ldap.impl.LdapEntryManagerFactory.createEntryManager(LdapEntryManagerFactory.java:51) ~[oxcore-persistence-ldap-4.1.0.Final.jar:?] at org.gluu.persist.ldap.impl.LdapEntryManagerFactory.createEntryManager(LdapEntryManagerFactory.java:23) ~[oxcore-persistence-ldap-4.1.0.Final.jar:?] at org.gluu.persist.ldap.impl.LdapEntryManagerFactory$Proxy$_$$_WeldClientProxy.createEntryManager(Unknown Source) ~[oxcore-persistence-ldap-4.1.0.Final.jar:?] at org.gluu.oxauth.service.AppInitializer.createPersistenceAuthEntryManager(AppInitializer.java:394) ~[classes/:?] at org.gluu.oxauth.service.AppInitializer$Proxy$_$$_WeldSubclass.createPersistenceAuthEntryManager(Unknown Source) ~[classes/:?] at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222] at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:103) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:180) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.gluu.service.cdi.util.CdiUtil.getContextBean(CdiUtil.java:48) ~[oxcore-service-4.1.0.Final.jar:?] at org.gluu.oxauth.service.AppInitializer.recreatePersistenceAuthEntryManagers(AppInitializer.java:453) ~[classes/:?] at org.gluu.oxauth.service.AppInitializer$Proxy$_$$_WeldSubclass.recreatePersistenceAuthEntryManagers(Unknown Source) ~[classes/:?] at org.gluu.oxauth.service.AppInitializer.reloadConfiguration(AppInitializer.java:284) ~[classes/:?] at org.gluu.oxauth.service.AppInitializer.reloadConfigurationTimerEvent(AppInitializer.java:266) [classes/:?] at org.gluu.oxauth.service.AppInitializer$Proxy$_$$_WeldSubclass.reloadConfigurationTimerEvent$$super(Unknown Source) [classes/:?] at sun.reflect.GeneratedMethodAccessor131.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.1.2.Final.jar:3.1.2.Final] at org.gluu.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-4.1.0.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590) [?:1.8.0_222] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222] ``` The test ldap connectivity works and users are synced with the cache refresh so I have no reason to believe this is a connectivity issue. Eventually my local admin session times out and I can no longer login. I have tried multiple reboots and have reinstalled the whole server to no avail.
Ubuntu 18.04
closed

Answers

By Michael Schwartz Account Admin 20 May 2020 at 10:21 a.m. CDT

Copy
Michael Schwartz gravatar
Can you upload screenshots for how you configured LDAP authentication and paste the urls here (i.e. for the auth_ldap_server). It's probably something simple.

By Ed Battye user 20 May 2020 at 10:34 a.m. CDT

Copy
Ed Battye gravatar
https://ibb.co/ZLtzLrP https://ibb.co/g9wBPY2 https://ibb.co/0hhC0zL

By Michael Schwartz Account Admin 20 May 2020 at 10:41 a.m. CDT

Copy
Michael Schwartz gravatar
A few suggestions: 1. Remove the second server... the one labeled "auth_ldap_server" with cn=directory manager. 2. Change the name for the AD server from "Riverford_AD" back to "auth_ldap_server", and set this as the default. Changing the name is probably ok, but I'd keep it standard, see if it works, and then change it. 3. Don't map attribute names that are the same, e.g.. no need to map `cn` --> `cn`. This is not breaking anything, but it's wasting cycles.

By Ed Battye user 20 May 2020 at 10:51 a.m. CDT

Copy
Ed Battye gravatar
Thanks, tried the above but no dice. Still getting it taking a while before timing out with Failed to authenticate. Just doesn't seem to make sense as I've got the same setting in the cache refresh and that works fine

By Michael Schwartz Account Admin 20 May 2020 at 11:09 a.m. CDT

Copy
Michael Schwartz gravatar
LDAP code 91: ``` client-side result code that indicates that the LDAP client has lost either its connection or cannot establish a connection to the LDAP server. ``` 1. I would try port 389 without SSL (just as a test). If it works, there is an ssl problem... perhaps import the AD LDAP self-signed cert into the oxauth java truststore. This could explain why cache refresh works (oxTrust) but not authentication (oxAuth). 2. Are there logs that you have access to on the AD server? That could provide a hint as to why there is a connection error.

By Ed Battye user 21 May 2020 at 9:36 a.m. CDT

Copy
Ed Battye gravatar
Thanks Michael, you were on the right track with the SSL. I looked in the oxauth_persistence.log and could lots of handshake errors. The funny thing is I had tried disabling SSL before and it made no difference but what I discovered was turning SSL off in the interface made no difference to OxAuth, it kept trying to use SSL and port 636. I tried restarting the service, and the server but it still made no difference it insisted on using SSL. In the end I reverted to a backup from just after install and made sure I did not activate SSL and used 389 from the start and behold it works! Still evaluating the product at the moment but if we choose to use it we will have to revisit this problem but now happy to carry on with the setup.

By Michael Schwartz Account Admin 21 May 2020 at 11:17 a.m. CDT

Copy
Michael Schwartz gravatar
Normally AD uses a self-signed certificate. I use an LDAP browser to get it, then import it into the oxAuth java truststore, which I think is `/opt/jre/jre/lib/security/cacerts` You can use a tool like [KeyStoreExplorer](https://keystore-explorer.org/) to do this. The default JRE password is normally `changeit`.

Post an answer