LDAP 'user_filter' does not function GitLab 6.7-6.8

When I comment out the 'uid' line in my gitlab.yml ldap config and add a 'user_filter' line, login attempts result in a 500 error. We just upgraded from 6.6 to 6.7

Here is the relevant bit from production.log:

Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2014-04-03 10:26:18 -0500
ArgumentError (uid or filter MUST be provided):
vendor/bundle/ruby/2.0.0/gems/gitlab_omniauth-ldap-1.0.4/lib/omniauth-ldap/adaptor.rb:38:in `validate'
vendor/bundle/ruby/2.0.0/gems/gitlab_omniauth-ldap-1.0.4/lib/omniauth-ldap/adaptor.rb:41:in `initialize'
vendor/bundle/ruby/2.0.0/gems/gitlab_omniauth-ldap-1.0.4/lib/omniauth/strategies/ldap.rb:38:in `new'
vendor/bundle/ruby/2.0.0/gems/gitlab_omniauth-ldap-1.0.4/lib/omniauth/strategies/ldap.rb:38:in `callback_phase'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:226:in `callback_call'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:182:in `call!'
vendor/bundle/ruby/2.0.0/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:164:in `call'
...

If I edit config/devise.rb to add

      filter:      Gitlab.config.ldap['user_filter']

to the configuration there, I now get 'Access denied for your LDAP account'

From production.log:

Redirected to https://git2-svr/users/sign_in
Filter chain halted as :ldap_security_check rendered or redirected
Completed 302 Found in 33ms (ActiveRecord: 6.9ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2014-04-07 11:24:34 -0500

Through experimenting with the Cookbook, I've determined some useful information. Given the above configuration fix:

1. User filters do not work in a clean 6.7 installation.
2. They work correctly in a clean 6.8.rc1 installation.
3. They do not work in a clean 6.7 upgraded to 6.8.rc1. This case results in the same 'Access denied' error.

Additional information: user filters do not work in a clean 6.8.1 that has been migrated from MySQL to PostgreSQL.

The culprit appears to be database migrations. Either a version upgrade or a DBMS migration breaks LDAP user filters.

The uid attribute in the LDAP settings is required. What sort of filter were you trying to create @travis.a.odom ?

Here's my filter: user_filter: '(&(sAMAccountName=%{username})(memberOf:1.2.840.113556.1.4.1941:=CN=z-SG-Company Git Access,OU=AT - EMPLOYEES Jabber Git Accounts,OU=AT - Employees,DC=ARM,DC=DOMAIN))

As stated, this works fine in a new 6.8 install with the 'uid' line commented out. If that is supposed to be required, that suggests more issues exist. I've tried tracing the code, but I've discovered this is a difficult task in Ruby.

From the omniauth-ldap readme:

:filter is the LDAP filter used to search the user entry. It can be used in place of :uid for more flexibility. %{username} will be replaced by the user name processed by :name_proc.'

@travis.a.odom GitLab has its own LDAP code and user filter; GitLab LDAP user filters are incompatible with omniauth-ldap. !79 (merged) broke existing user_filter configurations in GitLab.

For your use case, I would expect the settings to look like this:

ldap:
  uid: 'sAMAccountName'
  user_filter: '(memberOf:1.2.840.113556.1.4.1941:=CN=z-SG-Company Git Access,OU=AT - EMPLOYEES Jabber Gi...)'
  # other settings

I have just tested what I wrote above (ActiveDirectory, recursive group membership query as user filter) on GitLab 6.9.0 after locally reverting !79 (merged); it worked for me.

When testing, I found that the behavior in this case was the same with or without the filter - e.g. a user whom the filter would deny was still given access, just as if no filter had been added.

Also, with 'uid' commented and without !79 (merged), an error must have either uid or filter is generated. Either un-commenting 'uid' or adding !79 (merged) resolves that error condition. This behavior is consistent with the requirements of omniauth-ldap, which may be confusing me, given that I can see at least some of the code uses net-ldap directly for filter validation.

I was unable to create a working filter without that fix, so I find this response very surprising. I will try to re-confirm the behavior I saw with both 'uid' and 'user_filter' configured.

Ok, #297 (closed) and the commit message on 7dfb678d together largely explain what's going on. I changed my filter as suggested there (which I now see mirrors your suggestion) and it does work correctly.

Official documentation I will leave as an exercise for the implementer.

Status changed to closed

@travis.a.odom glad to hear your filter is working now!

I found out about this in the first place because of this issue: https://github.com/gitlabhq/gitlabhq/issues/6700#issuecomment-44218384

My impression right now is that the up-to-one-hour delay on LDAP user filter changes is making this so confusing. I am working on documentation improvements.

Fixed with 6.9.2 https://github.com/gitlabhq/gitlabhq/commit/08bd91a1811831ca8ba2b0725a01b43f621816cf

There is improved documentation for the user_filter in de717a33.

mentioned in commit d1fa13d7

Mentioned in commit d1fa13d7

mentioned in merge request !14785