Configuring gitlab LDAP authentication without a special gitlab user

Question

I want to create Gitlab with our LDAP company as a demo. But unfortunately, I have to enter the administrator password in gitlab.yml to make gitlab access the LDAP service. Actually, the problem is administration, as they don’t want to set up another Gitlab-only account. Is there any way around this without filling in my own password? Is there a way to force Gitlab to establish an LDAP connection only with the provided user credentials?

Any ideas besides logging in anonymously?

Already published here .

Answer 1

I have not tried it yet, but from what I have created so far, for LDAP authentication and information from the configuration file, this user account seems only necessary when your LDAP does not support anonymous binding and search.

So, I would leave the two bind_dn and password entries commented out and try to work it or not.

UPDATE

I implemented LDAP-Autehntication on Gitlab, and it is pretty easy.

In gitlab.yml -file there is a section called ldap .

There you must provide information for connecting to your LDAP. It seems that all fields should be provided, there seems to be no fallback default! If you want to use anonymous binding to retrieve user DNs, enter an empty string for bind_dn and password . Commenting them out didn't seem to work! At least I got error 501.

More information can be found at https://github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-auth and (more outdated but still useful) https://github.com/intridea/omniauth-ldap

Answer 2

I ran gitlab to work this way and documented the process at http://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account.html

I shamelessly copy the instructions here for self-completion.

Note This tutorial was last tested with gitlab 8.2 installed from source.

This tutorial describes how to change your Gitlab installation to use user credentials for authentication with an LDAP server. From default, Gitlab uses an anonymous binding or a special request user to ask the LDAP server about the existence of the user before authenticating it with its own authority. For security reasons, however, many administrators disable anonymous binding and prevent the creation of special LDAP user requests.

In this tutorial, we assume that we have gitlab installed in gitlab.example.com and an LDAP server running on ldap.example.com, and users have the following DNs: CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com .

patches

To make Gitlab work in such cases, we need to partially modify its authentication mechanism with respect to LDAP.

First we replace the omniauth-ldap module with this output. to do this we will apply the following patch to gitlab/Gemfile :

 diff --git a/Gemfile b/Gemfile index 1171eeb..f25bc60 100644 --- a/Gemfile +++ b/Gemfile @@ -44,4 +44,5 @@ gem 'gitlab-grack', '~> 2.0.2', require: 'grack' # LDAP Auth # GitLab fork with several improvements to original library. For full list of changes # see https://github.com/intridea/omniauth-ldap/compare/master...gitlabhq:master -gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap" +#gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap" +gem 'gitlab_omniauth-ldap', :git => 'https://github.com/zakkak/omniauth-ldap.git', require: 'net-ldap', require: "omniauth-ldap" 

Now we need to do the following:

• sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
• sudo -u git -H bundle install --deployment --without development test mysql aws

These commands will receive the modified omniauth-ldap module in gitlab/vendor/bundle/ruby/2.xx/bundler/gems . Now that we have to modify the module to use the DN that our LDAP server expects. We do this by fixing lib/omniauth/strategies/ldap.rb in gitlab/vendor/bundle/ruby/2.xx/bundler/gems/omniauth-ldap with:

 diff --git a/lib/omniauth/strategies/ldap.rb b/lib/omniauth/strategies/ldap.rb index 9ea62b4..da5e648 100644 --- a/lib/omniauth/strategies/ldap.rb +++ b/lib/omniauth/strategies/ldap.rb @@ -39,7 +39,7 @@ module OmniAuth return fail!(:missing_credentials) if missing_credentials? # The HACK! FIXME: do it in a more generic/configurable way - @options[:bind_dn] = "CN=#{request['username']},OU=Test,DC=my,DC=example,DC=com" + @options[:bind_dn] = "CN=#{request['username']},OU=Users,OU=division,OU=department,DC=example,DC=com" @options[:password] = request['password'] @adaptor = OmniAuth::LDAP::Adaptor.new @options 

With this module, gitlab uses user credentials to bind to the LDAP server and request it, as well as to authenticate the user himself.

This, however, will only work until users use ssh-keys to authenticate with Gitlab . When authenticating with the default ssh key, Gitlab queries the LDAP server to find out if the corresponding user is (still) a valid user or not. At this point, we cannot use user credentials to query the LDAP server because the user did not provide them to us. As a result, we will disable this mechanism, mainly for users with registered ssh keys, but deleted from the LDAP server to use our Gitlab configuration. To prevent being able to still use the Gitlab setup, you will have to manually remove your ssh keys from any accounts in your setup.

To disable this mechanism, we gitlab/lib/gitlab/ldap/access.rb with:

 diff --git a/lib/gitlab/ldap/access.rb b/lib/gitlab/ldap/access.rb index 16ff03c..9ebaeb6 100644 --- a/lib/gitlab/ldap/access.rb +++ b/lib/gitlab/ldap/access.rb @@ -14,15 +14,16 @@ module Gitlab end def self.allowed?(user) - self.open(user) do |access| - if access.allowed? - user.last_credential_check_at = Time.now - user.save - true - else - false - end - end + true + # self.open(user) do |access| + # if access.allowed? + # user.last_credential_check_at = Time.now + # user.save + # true + # else + # false + # end + # end end def initialize(user, adapter=nil) @@ -32,20 +33,21 @@ module Gitlab end def allowed? - if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter) - return true unless ldap_config.active_directory + true + # if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter) + # return true unless ldap_config.active_directory - # Block user in GitLab if he/she was blocked in AD - if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter) - user.block unless user.blocked? - false - else - user.activate if user.blocked? && !ldap_config.block_auto_created_users - true - end - else - false - end + # # Block user in GitLab if he/she was blocked in AD + # if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter) + # user.block unless user.blocked? + # false + # else + # user.activate if user.blocked? && !ldap_config.block_auto_created_users + # true + # end + # else + # false + # end rescue false end 

Configuration

In gitlab.yml use something like the following (change your needs):

 # # 2. Auth settings # ========================== ## LDAP settings # You can inspect a sample of the LDAP users with login access by running: # bundle exec rake gitlab:ldap:check RAILS_ENV=production ldap: enabled: true servers: ########################################################################## # # Since GitLab 7.4, LDAP servers get ID (below the ID is 'main'). GitLab # Enterprise Edition now supports connecting to multiple LDAP servers. # # If you are updating from the old (pre-7.4) syntax, you MUST give your # old server the ID 'main'. # ########################################################################## main: # 'main' is the GitLab 'provider ID' of this LDAP server ## label # # A human-friendly name for your LDAP server. It is OK to change the label later, # for instance if you find out it is too large to fit on the web page. # # Example: 'Paris' or 'Acme, Ltd.' label: 'LDAP_EXAMPLE_COM' host: ldap.example.com port: 636 uid: 'sAMAccountName' method: 'ssl' # "tls" or "ssl" or "plain" bind_dn: '' password: '' # This setting specifies if LDAP server is Active Directory LDAP server. # For non AD servers it skips the AD specific queries. # If your LDAP server is not AD, set this to false. active_directory: true # If allow_username_or_email_login is enabled, GitLab will ignore everything # after the first '@' in the LDAP username submitted by the user on login. # # Example: # - the user enters '[e-mail]' and 'p@ssw0rd' as LDAP credentials; # - GitLab queries the LDAP server with 'jane.doe' and 'p@ssw0rd'. # # If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to # disable this setting, because the userPrincipalName contains an '@'. allow_username_or_email_login: false # To maintain tight control over the number of active users on your GitLab installation, # enable this setting to keep new users blocked until they have been cleared by the admin # (default: false). block_auto_created_users: false # Base where we can search for users # # Ex. ou=People,dc=gitlab,dc=example # base: 'OU=Users,OU=division,OU=department,DC=example,DC=com' # Filter LDAP users # # Format: RFC 4515 http://tools.ietf.org/search/rfc4515 # Ex. (employeeType=developer) # # Note: GitLab does not support omniauth-ldap custom filter syntax. # user_filter: '(&(objectclass=user)(objectclass=person))' 

Answer 3

GitLab uses omniauth to manage multiple input sources (including LDAP).

So, if you can extend omniauth some way to manage the LDAP connection in a different way, you can get the password from another source.
This will allow you to avoid saving the specified password in the ldap section of the gitlab.yml configuration file .