Please disregard the warning about the 42 groups that could not be found. Those are administrative groups within the LDAP server that are not searchable by anyone.

But what is worth mentioning is that the errors at the top of the Lookup:

No LDAP group membership reported.If the user is a member of some LDAP groups then the group membership settings are probably configured incorrectly.Email address inconsistent (login brian.murrell@example.com versus lookup null)User groups inconsistent (login versus lookup)

all go away if I put the very same credentials I was testing above into the Manager DN and Manager Password fields. This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests. Is that correct?

If so, that is not going to accurately reflect the LDAP settings in environments where uses have to bind to the LDAP server to do lookups.

This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests. Is that correct?

So Jenkins needs to do two kinds of validation of login details:

Validation of login details of a user when the user is logging in.

Validation of a user's group membership when the user is being logged in via API token, being logged in via SSH key, being impersonated by a job (Authorize project plugin) and various other situations (such as where some authorization strategy plugins want to show effective permissions of a user to the admin)

Your LDAP server does not allow anonymous lookup of the user / group details. So while you can login correctly and your permissions work for you while you are logged in... in actuality you have a broken configuration. Your API tokens will not work correctly. Your SSH key login will not work correctly. You will get all sorts of subtle bugs when using e.g. the Jenkins CLI.

The test button is correctly identifying these issues and giving you a scary warning.

What is at issue here is that it is claiming a lock-out when you were able to authenticate, it should be saying that:

The user "brian" may be unable to login with API tokens or SSH keys and will have inconsistent permissions when logging in with these or when jobs are running as this user.

The solution for your installation can take one of two forms:

Provide a Manager DN & password. This manager DN and password only needs to have permission to lookup users and groups on the LDAP server. It can even be in a DN that is not permitted to login as a regular user (for example this test uses uid=admin,ou=system as the manager DN but only logs in users from ou=people,o=sevenSeas)

Enable anonymous lookup of groups and users (not recommended but this is the other solution)

Now if you do not care about the API tokens, the SSH keys or having jobs run as users rather than as SYSTEM then you can probably safely ignore the warning, but a warning is the correct behaviour (the warning just needs some minor tweaking to reflect that you were able to authenticate and it is the "internal" authentication within Jenkins that will have issues)

Stephen Connolly
added a comment - 2017-06-19 08:23 This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests. Is that correct?
So Jenkins needs to do two kinds of validation of login details:
Validation of login details of a user when the user is logging in.
Validation of a user's group membership when the user is being logged in via API token, being logged in via SSH key, being impersonated by a job ( Authorize project plugin ) and various other situations (such as where some authorization strategy plugins want to show effective permissions of a user to the admin)
Your LDAP server does not allow anonymous lookup of the user / group details. So while you can login correctly and your permissions work for you while you are logged in... in actuality you have a broken configuration. Your API tokens will not work correctly. Your SSH key login will not work correctly. You will get all sorts of subtle bugs when using e.g. the Jenkins CLI.
The test button is correctly identifying these issues and giving you a scary warning.
What is at issue here is that it is claiming a lock-out when you were able to authenticate, it should be saying that:
The user "brian" may be unable to login with API tokens or SSH keys and will have inconsistent permissions when logging in with these or when jobs are running as this user.
The solution for your installation can take one of two forms:
Provide a Manager DN & password. This manager DN and password only needs to have permission to lookup users and groups on the LDAP server. It can even be in a DN that is not permitted to login as a regular user (for example this test uses uid=admin,ou=system as the manager DN but only logs in users from ou=people,o=sevenSeas )
Enable anonymous lookup of groups and users (not recommended but this is the other solution)
Now if you do not care about the API tokens, the SSH keys or having jobs run as users rather than as SYSTEM then you can probably safely ignore the warning, but a warning is the correct behaviour (the warning just needs some minor tweaking to reflect that you were able to authenticate and it is the "internal" authentication within Jenkins that will have issues)

Stephen Connolly
added a comment - 2017-06-19 08:39 Downgrading the priority from Critical to Trivial because:
The test button correctly identified a configuration issue
The warning message is just not correct

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/hudson/security/LDAPSecurityRealm.java
src/main/resources/jenkins/security/plugins/ldap/Messages.propertieshttp://jenkins-ci.org/commit/ldap-plugin/1b657e0fb88b718b9095a5eed43b8107d57c320a
Log:[FIXED JENKINS-43994] When the user can login but lookup fails report this as a potential issue for API tokens and SSH key base authentication of the user