What else can cause a LDAP auth to fail, even when the test succeeds?

[Jordan Glassman]

There is a KB article that suggests disabling Crowd SSO:  https://confluence.atlassian.com/jirakb/ldap-test-succeeds-but-user-authentication-fails-365658590.html

However in my case, something else is the cause:

jira_1 | 2018-02-09 22:13:53,146 http-nio-8080-exec-16 DEBUG anonymous 1333x826x1 elscg1 172.19.0.1 /rest/gadget/1.0/login [c.a.crowd.directory.SpringLDAPConnector] Performing user search: baseDN = dc=example,dc=org - filter = (&(objectclass=inetorgperson)(cn=user))
ldap_1 | 5a7e1d21 conn=1018 op=47 SRCH base="dc=example,dc=org" scope=2 deref=3 filter="(&(objectClass=inetOrgPerson)(cn=user))"
ldap_1 | 5a7e1d21 conn=1018 op=47 SRCH attr=entryUUID mail displayName givenName cn sn
ldap_1 | 5a7e1d21 <= bdb_equality_candidates: (cn) not indexed
ldap_1 | 5a7e1d21 conn=1018 op=47 SEARCH RESULT tag=101 err=0 nentries=1 text=
jira_1 | 2018-02-09 22:13:53,151 http-nio-8080-exec-16 DEBUG anonymous 1333x826x1 elscg1 172.19.0.1 /rest/gadget/1.0/login [c.a.c.directory.ldap.SpringLdapTemplateWrapper] Timed call for search using searchexecutor com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$10@13d7cc88 took 4ms
jira_1 | 2018-02-09 22:13:53,151 http-nio-8080-exec-16 DEBUG anonymous 1333x826x1 elscg1 172.19.0.1 /rest/gadget/1.0/login [c.a.crowd.directory.SpringLDAPConnector] Authenticating user 'user' with DN 'cn=user,dc=example,dc=org'
ldap_1 | 5a7e1d21 conn=1030 fd=22 ACCEPT from IP=172.19.0.10:35900 (IP=0.0.0.0:389)
ldap_1 | 5a7e1d21 conn=1030 op=0 BIND dn="cn=user,dc=example,dc=org" method=128
ldap_1 | 5a7e1d21 conn=1030 op=0 BIND dn="cn=user,dc=example,dc=org" mech=SIMPLE ssf=0
ldap_1 | 5a7e1d21 conn=1030 op=0 RESULT tag=97 err=0 text=
ldap_1 | 5a7e1d21 conn=1030 op=1 UNBIND
ldap_1 | 5a7e1d21 conn=1030 fd=22 closed
jira_1 | 2018-02-09 22:13:53,166 http-nio-8080-exec-16 DEBUG anonymous 1333x826x1 elscg1 172.19.0.1 /rest/gadget/1.0/login [c.a.j.security.login.JiraSeraphAuthenticator] authenticate : 'user' does not exist and cannot be authenticated.
jira_1 | 09-Feb-2018 22:13:53.166 WARNING [http-nio-8080-exec-16] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI http://localhost:8080/rest/gadget/1.0/login, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

seraph-config.xml:

<!-- CROWD:START - If enabling Crowd SSO integration uncomment the following SSOSeraphAuthenticator and comment out the JiraSeraphAuthenticator below -->
 <!--
 <authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>
 -->
 <!-- CROWD:END -->

<!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration -->
 <authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/>
 <!-- CROWD:END -->

Message in UI: "Sorry, your username and password are incorrect - please try again."

LDAP settings:

User found by JIRA and passes auth test:

Using JIRA 7.4.2 via cptactionhank/docker-atlassian-jira, openldap via osixia/docker-openldap.

Thanks!

[Matt]

I don't think you can use the crowd SSO feature with just Jira. I think it was meant to use when implementing the crowd app as your SSO/IdP alongside Jira. Did you try and disable the crowd SSO in seraph per the article?

[Jordan Glassman]

Thanks for the reply.  Yes.  Crowd SSO is and was disabled.  Excerpt from `seraph-config.xml` included.

That's what I meant by "what else" could be causing this.  :)

[Matt]

That's my mistake! It was a late night, my apologies. 

Does the user info ever show attempted logins? Seems the membership config needs attention. I can try and configure the same on my local and let you know what I find. 

[Jordan Glassman]

The users listing in the above screenshot shows "never logged in" for the user "users". 

Is there somewhere else to check attempted logins?

Any help reproducing this and getting to the bottom would be greatly appreciated!