GitLab Active Directory認証:結果も認証もありません


8

GitLab(VM上のUbuntu 14.04 amd64にインストールされたバージョン7.12.2、Omnibusセットアップ)でLDAP認証をセットアップしようとしています。gitlab.rbファイルを次のように編集しました。

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
 main: # 'main' is the GitLab 'provider ID' of this LDAP server
   label: 'LDAP'
   host: '********'
   port: 389
   uid: 'sAMAccountName'
   method: 'plain' # "tls" or "ssl" or "plain"
   bind_dn: 'CN=********,OU=********,OU=********,DC=********,DC=***'
   password: '********'
   active_directory: true
   allow_username_or_email_login: false
   block_auto_created_users: false
   base: 'DC=********,DC=***'
   user_filter: ''
EOS

これにより、「資格情報が無効なため、Ldapmainから認証できませんでした」という恐ろしい結果が生じます。エラー。ユーザー名(bind_dn変数内)について、「johnsmith@example.com」(ユーザー名に基づくメール)、「John Smith」(フルネーム)、および「johnsmith」(ユーザー名)を試しました。結果は常に同じです。パスワードに@記号が含まれています。私はそれを脱出する必要があるかどうか、またはどのようにしてよいかわかりません。

ログはこれを示しています:

Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"********", "password"=>"[FILTERED]"}
Redirected to http://192.168.56.102/users/sign_in
Completed 302 Found in 14ms (ActiveRecord: 3.6ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by SessionsController#new as HTML
Completed 200 OK in 20ms (Views: 8.3ms | ActiveRecord: 2.9ms)

そしてgitlab-rake gitlab:ldap:checkこれを示しています:

Checking LDAP ...

LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain

Checking LDAP ... Finished

しかし、Ubuntu VMからldapsearchを使用すると(同じ環境で)、たくさんの結果が得られます。

ldapsearch -x -h ******** -D "********@********.***" -W -b "OU=********,OU=********,DC=********,DC=***" -s sub "(cn=*)" cn mail sn dn

奇妙なことに、結果のDNは次のようになります。

dn: CN=John Smith,OU=********,OU=********,OU=********,DC=********,DC=***

つまり、そこに追加のOUがあります。ldapsearchコマンドにもがあることがわかります-s sub。これは、サブグループを検索することを意味すると思います。LDAPやActive Directoryの詳細については、あまり詳しくありません。

だから私は自分の基地に何かが足りないのだと思いますが、私は何がわかりません。また、ユーザーフィルターの問題である可能性もあります。これまでのところ必要なグーグルを実行しましたが、今はアイデアと解決策がありません。


1
のエントリbaseは少し短いようです。ldapsearchの結果からの完全なパス(すべてのOUを含む)をそこに置くとどうなりますか?
etagenklo 2015

@etagenklo:あなたは正しいです。私は他のいくつかの変更を行い、それを機能させることができました。後世の回答として掲載します。
siride

この答えが役に立つかもしれません:stackoverflow.com/a/54462889/6290553
Raktim Biswas '31 / 01/31

回答:


11

私は多くの異なる試みの後にこれを解決することができました。いくつかのメモ:

  • 最初の行を除くすべての行にインデント用のスペースが1つあることを確認してください。最初の行は "main:"と書かれており、インデントはまったくありません。
  • bind_dnは、バインドユーザーの完全なLDAPパスではなく、単にユーザー名です。私の場合は「xxx@example.com」です。
  • ベースは、Active DirectoryグループまたはDN、またはすべてのユーザーを含む、呼び出される名前である必要があります。

これが最終的なYAMLです。

main: # 'main' is the GitLab 'provider ID' of this LDAP server
 label: 'Active Directory'
 host: 'ad-server.example.com'
 port: 389
 uid: 'sAMAccountName'
 method: 'plain' # "tls" or "ssl" or "plain"
 bind_dn: 'user@example.com'
 password: 'password'
 active_directory: true
 allow_username_or_email_login: false
 block_auto_created_users: false
 base: 'OU=ABC,OU=XYZ,DC=example,DC=com'
 user_filter: ''

1
そんなに+1!これは私のために働いていたstackexchangeネットワーク全体での唯一の解決策です!
ノワール
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.