Я исправил gitlab, чтобы он работал таким образом, и задокументировал этот процесс в https://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account/
Я без зазрения совести копирую сюда инструкции для полноты картины.
Примечание. Последний раз это руководство тестировалось с gitlab 8.2, установленным из исходных кодов.
В этом руководстве описывается, как изменить установку Gitlab для использования учетных данных пользователей для аутентификации на сервере LDAP. По умолчанию Gitlab использует анонимную привязку или специального запрашивающего пользователя, чтобы запросить сервер LDAP о существование пользователя до аутентификации с ее собственными учетными данными. Однако по соображениям безопасности многие администраторы отключают анонимную привязку и запрещают создание специальных запрашивающих пользователей LDAP.
В этом руководстве мы предполагаем, что у нас есть настройка gitlab на gitlab.example.com и сервер LDAP, работающий на ldap.example.com, а у пользователей есть DN следующей формы: CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com.
Патчинг
Чтобы Gitlab работал в таких случаях, нам необходимо частично изменить его механизм аутентификации в отношении LDAP.
Во-первых, мы заменяем модуль omniauth-ldap этим производным. Для этого мы применяем следующий патч к 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"
Теперь нам нужно выполнить следующие действия:
sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deploymentsudo -u git -H bundle install --deployment --without development test mysql aws
Эти команды получат измененный модуль omniauth-ldap в gitlab/vendor/bundle/ruby/2.x.x/bundler/gems. Теперь, когда модуль получен, нам нужно изменить его, чтобы использовать DN, которого ожидает наш сервер LDAP. Мы достигаем этого, исправляя lib/omniauth/strategies/ldap.rb в gitlab/vendor/bundle/ruby/2.x.x/bundler/gems/omniauth-ldap с помощью:
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
С помощью этого модуля gitlab использует учетные данные пользователя для привязки к серверу LDAP и запроса его, а также для аутентификации самого пользователя.
Однако это будет работать только до тех пор, пока пользователи не будут использовать ssh-ключи для аутентификации с помощью Gitlab. При аутентификации с помощью ssh-ключа по умолчанию Gitlab запрашивает сервер LDAP, чтобы узнать, является ли соответствующий пользователь (все еще ) действительный пользователь или нет. На этом этапе мы не можем использовать учетные данные пользователя для запроса сервера LDAP, поскольку пользователь не предоставил их нам. В результате мы отключаем этот механизм, позволяя пользователям с зарегистрированными ssh-ключами, но удаленными с сервера LDAP, по-прежнему использовать наш Gitlab настройка. Чтобы такие пользователи не могли по-прежнему использовать вашу настройку Gitlab, вам придется вручную удалить их ssh-ключи из любые учетные записи в вашей настройке.
Чтобы отключить этот механизм, мы исправляем gitlab/lib/gitlab/ldap/access.rb:
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
Конфигурация
В gitlab.yml используйте что-то вроде следующего (измените в соответствии с вашими потребностями):
#
# 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's (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 '[email protected]' 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's custom filter syntax.
#
user_filter: '(&(objectclass=user)(objectclass=person))'
person
zakkak
schedule
03.01.2016
