>> After authentication, oxTrust throws an error while grabbing the user info from the Gluu LDAP so that the only things I can do from the dashboard is attempt to login again or register. What kind of oxTrust error you are getting? I'm little not sure about this line. >> 2015-08-19 15:44:39,206 ERROR [org.gluu.oxtrust.action.Authenticator] Failed to find user '229c4526c3e2407ba14644421a700310' in ldap Are you using this big number to log into your Gluu Server? What's that? UID?

> What kind of oxTrust error you are getting? I'm little not sure about this line. It seems to be an error related to retrieving user details from the Gluu LDAP. But I'm not sure what could be causing the error as the user exists and is queryable by the Directory Manager. I wish I could give more information, but the error code that the LDAP throws is 1: > Caused by: LDAPSearchException(resultCode=1 (operations error), numEntries=0, numReferences=0, errorMessage='000020D6: SvcErr: DSID-031007DB, problem 5012 (DIR_ERROR), data 0 ') which only tells me it's some unknown internal error within OpenDJ. > Are you using this big number to log into your Gluu Server? What's that? UID? The back end system uses UUIDs as static unique keys, so this I translated to be the uid in the Gluu LDAP. cn is used to login and looks more like "bapple".

>> The back end system uses UUIDs as static unique keys, so this I translated to be the uid in the Gluu LDAP. cn is used to login and looks more like "bapple". Let's try to map 'cn' to 'UID' as this is used as primary_key to log into Gluu Server by default. Here is the [howto](http://www.gluu.org/docs/admin-guide/configuration/#manage-authentication).

Sounds good. But unfortunately I can't use the GUI to edit those attributes because of this issue. My admin account still exists; but since the Authentication Manager is pointed to my back end, that account fails to authenticate. I have tried looking through `/opt/tomcat/conf` to see if I can point the Authentication Manager to its default location (the Gluu Server) where admin's credentials are stored but can't seem to find where that connection is defined. If you could tell me where that file is, I'm sure I can change it with just a text editor.

Hi, Ben. I'm not completely sure that I've got your situation correctly, but if you already have reconfigured oxauth so it now authenticates logging in users against some back-end LDAP (not Gluu's internal LDAP db), you now will need to edit Gluu's configuration, which is stored in said LDAP db, directly. You will be particularly interested in node with DN inum=@!long_appliance_ID,ou=appliances,o=gluu (located in the userRoot context). Have a look at its oxIDPAuthentication attribute, that's where oxAuths configuration is stored. You will need to set different settings stored in this json object so that oxAuth once again started to use its own LDAP db for authentication. But there is a caveat: a bind password setting what doesn't store a password in cleartext. So unless you somehow can dig out encoded value of admin password for your installation's internal LDAP db, I'm not sure if it's possible to re-encode it again from cleartext string. May be Zico will be able to answer.

Almost forgot: most likely you will also need to set oxAuthenticationMode attribute (of the same node entry) to "internal"

That is exactly what I needed Aliaksandr. Thanks! I stored the encoded version of the password in case something like this happened and am able to log back in as the admin again. Anyway, I will try pointing the Authentication Manager at the back-end using "uid" as the primary local key like Zico suggested.

I used uid as the local primary key and made sure the uid of my user in the Gluu LDAP matched and was again given the same initial error. Here's the oxtrust.log: 2015-08-19 19:46:31,588 ERROR [org.gluu.oxtrust.action.Authenticator] Failed to find user 'bapple' in ldap org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to find entries with baseDN: ou=people,o=@!7DC3.15E9.3B48.C372!0001!3265.0234,o=gluu, filter: (&(&(objectClass=top)(objectClass=gluuPerson))(&(uid=bapple))) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:318) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:275) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:256) at org.gluu.oxtrust.ldap.service.AuthenticationService.getUserByUid(AuthenticationService.java:250) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) at org.gluu.oxtrust.ldap.service.AuthenticationService_$$_javassist_seam_47.getUserByUid(AuthenticationService_$$_javassist_seam_47.java) at org.gluu.oxtrust.action.Authenticator.findUserByUserName(Authenticator.java:254) at org.gluu.oxtrust.action.Authenticator.authenticate(Authenticator.java:165) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.SynchronizationInterceptor.aroundInvoke(SynchronizationInterceptor.java:35) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) at org.gluu.oxtrust.action.Authenticator_$$_javassist_seam_46.authenticate(Authenticator_$$_javassist_seam_46.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335) at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:348) at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58) at org.jboss.el.parser.AstValue.invoke(AstValue.java:96) at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:222) at org.jboss.seam.security.jaas.SeamLoginModule.login(SeamLoginModule.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) at javax.security.auth.login.LoginContext.login(LoginContext.java:595) at org.jboss.seam.security.Identity.authenticate(Identity.java:344) at org.jboss.seam.security.Identity.authenticate(Identity.java:332) at org.jboss.seam.security.Identity.login(Identity.java:259) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335) at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:348) at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58) at org.jboss.el.parser.AstValue.invoke(AstValue.java:96) at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:222) at org.jboss.seam.navigation.Page.preRender(Page.java:311) at org.jboss.seam.navigation.Pages.preRender(Pages.java:351) at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:565) at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:476) at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:147) at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:117) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:486) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:411) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:338) at org.jboss.seam.web.RewriteFilter.process(RewriteFilter.java:98) at org.jboss.seam.web.RewriteFilter.doFilter(RewriteFilter.java:57) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: LDAPSearchException(resultCode=1 (operations error), numEntries=0, numReferences=0, errorMessage='000020D6: SvcErr: DSID-031007DB, problem 5012 (DIR_ERROR), data 0 ') at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3657) at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020) at org.gluu.site.ldap.OperationsFacade.search(OperationsFacade.java:243) at org.gluu.site.ldap.OperationsFacade.search(OperationsFacade.java:200) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:313) ... 126 more 2015-08-19 19:46:31,589 ERROR [org.gluu.oxtrust.action.Authenticator] Person 'bapple' not found in LDAP I also tried the other way around (cn as the local primary key and uid as the primary key) and that just resulted in the user not authenticating (because my back-end does not use uid). I thought adding some screen shots might help a little. This is just to show that I am able to navigate to the login page and enter the user's credentials just fine.  After hitting login and getting authenticated, I am redirected to the dashboard which indicates that there was a login error (stack trace above).  Again, the user exists in the Gluu LDAP. I am able to query them using the same filter that oxTrust attempts to use. The underlying issue is this: > Caused by: LDAPSearchException(resultCode=1 (operations error), numEntries=0, numReferences=0, errorMessage='000020D6: SvcErr: DSID-031007DB, problem 5012 (DIR_ERROR), data 0 ') Any ideas what could be causing the problem?

Sorry, Ben, it seems I've lost a track of things. 1) You've succeeded in restoring administrative access to Gluu's web UI, am I correct? I.e., you at least able to log into web UI as default "admin" user, stored in internal LDAP db? 2) If answer to 1) is "Yes", then did you correctly pointed oxAuth to internal LDAP server? Please see attached screenshot for reference. 3) Are you trying to log in with some other user called "bapple" (i.e. it's not renamed default admin user or something), which is also stored in internal LDAP db, and you can't do this? If it so, then can I ask where this bapple user comes from? How it was created in the first place? Were you able to log in as this user before, and if you were, than when exactly you lost ability to do so? Can I also ask what version of Gluu you are using, and exact version of OS it's installed in?

1. Yes, I was able to login as the default admin user. 2. Also yes. 3. No, my goal is to use the external LDAP to authenticate users and "bapple" is one of those users. He does exist in the internal LDAP, but only because of the Cache Refresh mechanism. Before it's pointed out that I just said that I set the Authentication Manager to use the internal LDAP to authenticate my external users, I make sure to set the external LDAP as the source that the Authentication Manager uses before I attempt to login as "bapple". The set up is similar to the image provided [here](http://www.gluu.org/docs/articles/cache-refresh/) that I have also attached. My ultimate goal is to only use users from the external LDAP and to delete the default admin account as it will be useless at that point. I have not been able to fully log in as the "bapple" user yet because of the error I keep running into: > Caused by: LDAPSearchException(resultCode=1 (operations error), numEntries=0, numReferences=0, errorMessage='000020D6: SvcErr: DSID-031007DB, problem 5012 (DIR_ERROR), data 0 ') This happens **after** the user is authenticated from the external LDAP. This is a snippet from the oxauth.log file: 2015-08-19 20:29:35,237 DEBUG [org.xdi.oxauth.service.AuthenticationService] User authenticated: CN=bapple,OU=Users,OU=Corp,DC=omnitracs,DC=com Again, authentication is golden here. It's when the user tries to use the oxTrust application that I encounter the before mentioned problem. I have done some research and found that the error is a result of a bad base DN. The one used in the LDAP query is `ou=people,o=@!7DC3.15E9.3B48.C372!0001!3265.0234,o=gluu`, which is exactly correct for the internal LDAP. What I am wondering is if oxTrust is trying to pull user information from my external LDAP using that query. This would obviously result in an error since the external LDAP does not have the same directory structure. It is also concerning since the external LDAP also does not contain any gluu-specific user information (such as the Gluu Manager Group). Is there any way that I can confirm which LDAP oxTrust is attempting to pull user information from? And if oxTrust is trying to grab user information from the external LDAP, is there a way to only have authentication against the external and have oxTrust get information from the internal (which is updated via Cache Refresh)?

> No, my goal is to use the external LDAP to authenticate users and "bapple" is one of those users. He does exist in the internal LDAP, but only because of the Cache Refresh mechanism. Have you read CR-related docs in our wiki? Please have a look at it [here](http://www.gluu.org/docs/articles/cache-refresh/) If your oxAuth is currently configured like it's shown on my picture then it's impossible to use external LDAP. Accounts created in internal LDAP by CR don't contain passwords at all, they are here only for the sake of efficiency. You only can log in with them when oxAuth is switched to rely on external LDAP. But when you do this transition you will lose ability to log in with internal accounts, it's either one or the other (unless you are using special interception script). Please also note that it's a good practice to restart Gluu's service each time you are changing oxAuth's/CR's settings. May be it's still trying to use previous configuration? Could also you please login to Gluu's web UI and create a user here ("Users -> Add person")? Then try to log in with this user, and let me know was it successful or not.

And could you please answer this, too: > Can I also ask what version of Gluu you are using, and exact version of OS it's installed in?

I'm sorry, I've checked your first post, and noted you've already provided version of your Gluu package. Btw, you don't need to use beta anymore, as finalized CE 2.3.3-1 deb package has been recently released. If nothing prevents you from switching to it, how about try it and see whether or not it will help to resolve this issue?

Sorry about missing that last question. - Gluu version: 2.3.3 beta - OS: Ubuntu Server 14.04.3 - VM Software: Oracle VirtualBox I'd also like to apologize if I was not clear in my last post. I **know** that I can't use both internal and external users and that's **not** what I am trying to do. I **know** that passwords aren't stored in CR because it wouldn't be a good idea to grab passwords from the external LDAP. I have read the wiki many times before any of these posts and **know** that the information in the image you previously attached was for the internal LDAP. When I change the information in those fields to point to my external LDAP, oxAuth has no trouble authenticating those users defined in the external LDAP. But for some reason, oxTrust has been throwing the errors I have repeatedly mentioned. > Please also note that it's a good practice to restart Gluu's service each time you are changing oxAuth's/CR's settings. I have tried restarting the Gluu Server after switching oxAuth configurations and encountered the same error, so that doesn't seem to be the fix. > Could also you please login to Gluu's web UI and create a user here ("Users -> Add person")? Then try to log in with this user, and let me know was it successful or not. This was one of the first things I did after getting the server successfully installed and it was successful and still is as long as I am using the correct LDAP that user has been defined in.

Sorry just missed your post. I'll give the new package a try and let you know how it goes!

It's very likely it won't :) I actually have it installed in my test environment, just haven't had a chance to check CR and auth-n against external source yet. Now I had and I'm experiencing the same behaviour as you. I'll try to investigate a bit more, but it can be a bug in new release.

This is interesting issue.... Authentication happening but after authentication, it's failing. I wonder if there is any OC problem here or not. Let's tail oxauth.log while doing the authentication. Let's see if there is anything interesting there...

Isn't the wrapper log includes oxauth.log, too? It seems this is the cause of the issue: From the wrapper.log: > INFO | jvm 1 | 2015/08/20 12:10:15 | 2015-08-20 12:10:15,175 INFO [org.gluu.oxtrust.action.Authenticator] user uid:gluuadmin > INFO | jvm 1 | 2015/08/20 12:10:15 | 2015-08-20 12:10:15,244 INFO [org.gluu.oxtrust.action.Authenticator] Authenticating user 'gluuadmin' > INFO | jvm 1 | 2015/08/20 12:10:15 | 2015-08-20 12:10:15,244 DEBUG [org.gluu.oxtrust.ldap.service.AppInitializer] Created site LdapAuthEntryManager: org.gluu.site.ldap.persistence.LdapEntryManager@3b0758cd > INFO | jvm 1 | 2015/08/20 12:10:15 | 2015-08-20 12:10:15,273 ERROR [org.gluu.oxtrust.action.Authenticator] Failed to find user 'gluuadmin' in ldap > INFO | jvm 1 | 2015/08/20 12:10:15 | org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to find entries with baseDN: ou=people,o=@!B46D.09B7.AAB2.C330!0001!38B8.ED01,o=gluu, filter: (&(&(objectClass=top)(objectClass=gluuPerson))(&(uid=gluuadmin))) Now from a wireshark capture that was conducted at the same moment (note a timestamps on both): 10 1.297917000 192.168.238.102 192.168.238.10 LDAP 220 searchRequest(3) "ou=people,o=@!B46D.09B7.AAB2.C330!0001!38B8.ED01,o=gluu" wholeSubtree Frame 10: 220 bytes on wire (1760 bits), 220 bytes captured (1760 bits) on interface 0 Interface id: 0 Encapsulation type: Ethernet (1) Arrival Time: Aug 20, 2015 15:10:15.246556000 MSK ...(omitted for brevity)... Transmission Control Protocol, Src Port: 60086 (60086), Dst Port: ldap (389), Seq: 1, Ack: 1, Len: 154 Lightweight Directory Access Protocol LDAPMessage searchRequest(3) "ou=people,o=@!B46D.09B7.AAB2.C330!0001!38B8.ED01,o=gluu" wholeSubtree messageID: 3 protocolOp: searchRequest (3) searchRequest baseObject: ou=people,o=@!B46D.09B7.AAB2.C330!0001!38B8.ED01,o=gluu scope: wholeSubtree (2) derefAliases: neverDerefAliases (0) sizeLimit: 0 timeLimit: 0 typesOnly: False Filter: (&(&(objectClass=top)(objectClass=gluuPerson))(uid=gluuadmin)) attributes: 0 items 192.168.238.10 is my AD backend. So what happens here is it tries to search my backend as it would have been its own internal LDAP db. But the most peculiar part is that actual authentication already happened at the very beginning of the session - there already was a correct sequence of "LDAP request for subtree -> LDAP request for user object -> LDAP bind request with user's creds" and it was successful. So later on a second (and invalid) authentication attempt occurs, and it fails this time. I don't know wheter or not this double authentication is a normal workflow, though. Do you know it, Zico?

That's funny.. Trying to make a couple of screenshots for bug report I changed my installation to authenticate against backend LDAP db once more, and this time I was able to log in successfully with the same user.

Yes, it seems I've found how to circumvent it, but the issue still persists :)

Thanks for looking more into this. I tried upgrading my current gluu server (by just removing the beta and installing the new one), and some of the old configuration files persisted and created new problems. So I am currently in the process of starting again from a clean VM. In the meantime, can I ask what you did to circumvent the issue?

After installing the latest version on a clean VM, I was able to log into oxTrust with an external user. Thanks for you help Alaiksandr and Zico!

Well, I thought it was fixed. It seems that it only worked the first time I logged in as that user. After logging out and back in (with a different browser so that session information was different), I ran into the same errors.

I'm sorry, I was working on other issue. > In the meantime, can I ask what you did to circumvent the issue? That's kind of hard to explain briefly. I had a text file opened where I cached contents of oxIDPAuthentication attribute so I could switch between backend and internal LDAP as quick as possible. So it works like this: 1) While oxAuth pointed to internal db, log in as default admin, then log out. 2) Without changing anything move to login page and attempt to login with user account `from backend LDAP` (using correct credentials for it); of course, you will fail 3) Don't touch your browser now, and point oxAuth to backend LDAP by directly modifying mentioned LDAP attribute 4) Now attempt to log in with the same user account from back-end you used on step 2) That's definetely an intresting one :) Btw, thank you very much for insistently dragging our attention to this. It could be easily overlooked either way as all symptoms suggest a simple misconfiguration, and not a bug.