まだ試していませんが、これまでに作成したLDAPに対する認証と、構成ファイルの情報から、このユーザーアカウントは、LDAPが匿名のバインドと検索をサポートしていない場合にのみ必要になるようです。
bind_dnだから私は2つのエントリを残してpasswordコメントアウトし、それが機能するかどうか試してみます。
アップデート
LDAP-AutehnticationをGitlabに実装しましたが、かなり簡単です。
-fileには、 。gitlab.ymlというセクションがありldapます。
そこで、LDAPに接続するための情報を提供する必要があります。すべてのフィールドを指定する必要があるようです。フォールバックのデフォルトはないようです。ユーザーDNの取得に匿名バインディングを使用する場合は、およびに空の文字列を指定bind_dn しpasswordます。それらをコメントアウトすることはうまくいかないようです！少なくとも501エラーメッセージが表示されました。
詳細については、https：//github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-authおよび（より古くなっていますが、まだ役立つ）https://github.com/intridea/omniauth-ldapを参照してください。
このように動作するようにgitlabにパッチを適用し、 https： //foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account/でプロセスを文書化しました。
私は恥知らずにここの指示を自己完結のためにコピーします。
注：このチュートリアルは、ソースからインストールされたgitlab8.2で最後にテストされました。
このチュートリアルは、ユーザーのクレデンシャルを使用してLDAPサーバーで認証するようにGitlabインストールを変更する方法を説明することを目的としています。デフォルトでは、 Gitlabは匿名バインディングまたは特別なクエリユーザーに依存して、自分の資格情報でユーザーを認証する前に、ユーザーの存在についてLDAPサーバーに問い合わせます。ただし、セキュリティ上の理由から、多くの管理者は匿名バインディングを無効にし、特別なクエリLDAPユーザーの作成を禁止しています。
このチュートリアルでは、gitlab.example.comにgitlabセットアップがあり、ldap.example.comでLDAPサーバーが実行されており、ユーザーの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。モジュールがフェッチされたので、LDAPサーバーが期待するDNを使用するようにモジュールを変更する必要があります。これは、次のパッチ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サーバーにバインドしてクエリを実行し、ユーザー自身を認証します。
ただし、これは、ユーザーがGitlabでの認証にsshキーを使用しない場合にのみ機能します。ssh-keyを介して認証する場合、デフォルトでは、GitlabはLDAPサーバーにクエリを実行して、対応するユーザーが（まだ）有効なユーザーであるかどうかを確認します。この時点では、ユーザーが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 'jane.doe@example.com' 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))'
GitLabはomniauthを使用して、複数のログインソース（LDAPを含む）を管理します。
したがってomniauth、LDAP接続を別の方法で管理するために何らかの方法で拡張できる場合は、別のソースからパスワードを取得できます。これにより、設定ファイルのldapセクションに
上記のパスワードを保持することを回避できます。gitlab.yml