web-dev-qa-db-ja.com

Gitlab LDAP認証をデバッグする方法は？

GitlabでLDAP認証を構成しようとしています。私の構成は次のようなものです：

ldap:
    enabled: true
    Host: 'ldap.example.com'
    base: 'ou=People,o=example.com'
    port: 636
    uid: 'uid'
    method: 'ssl' # "ssl" or "plain"
    bind_dn: 'cn=gitlab,ou=Apps,o=example.com'
    password: 'password'
    allow_username_or_email_login: true

私はそれを以下でテストしました：

ldapsearch  -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldaps://ldap.example.com:636 -w "password" -x "([email protected])"

上記の行は機能しますが、LDAPを使用してログインしようとすると、常に「無効な資格情報」を取得しました。

これをトラブルシューティングして、この問題の根本的な原因を絞り込むにはどうすればよいですか？

09/09を編集：

ここに私がproduction.logで見つけたいくつかのものがあります：

Started GET "/users/sign_in" for 127.0.0.1 at 2013-09-23 17:42:58 -0300
Processing by Devise::SessionsController#new as HTML
  Rendered devise/sessions/_new_ldap.html.haml (1.7ms)
  Rendered devise/sessions/_new_base.html.haml (1.8ms)
  Rendered devise/sessions/_oauth_providers.html.haml (0.0ms)
  Rendered devise/sessions/new.html.haml within layouts/devise (4.2ms)
  Rendered layouts/_head.html.haml (1.6ms)
  Rendered layouts/_flash.html.haml (0.1ms)
Completed 200 OK in 9ms (Views: 6.9ms | ActiveRecord: 0.0ms)
Started POST "/users/auth/ldap/callback" for 127.0.0.1 at 2013-09-23 17:43:00 -0300
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"â", "authenticity_token"=>"AwqZsVHRqOeZr+GLWWeGM7MyOAdk7cFl8/rZgbVRU+8=", "username"=>"[email protected]", "password"=>"[FILTERED]"}
Redirected to http://example.com/users/sign_in
Completed 302 Found in 3ms (ActiveRecord: 0.0ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2013-09-23 17:43:00 -0300
Processing by Devise::SessionsController#new as HTML
  Rendered devise/sessions/_new_base.html.haml (2.8ms)
  Rendered devise/sessions/_oauth_providers.html.haml (0.1ms)
  Rendered devise/sessions/new.html.haml within layouts/devise (3.7ms)
  Rendered layouts/_head.html.haml (1.7ms)
  Rendered layouts/_flash.html.haml (0.1ms)
Completed 200 OK in 9ms (Views: 6.6ms | ActiveRecord: 0.0ms)
Started GET "/" for 127.0.0.1 at 2013-09-23 18:50:08 -0300
Processing by DashboardController#show as HTML
Completed 401 Unauthorized in 1ms

編集：私はようやく答えを得ました：deviseの設定は "@"の後のすべてを取り除いていました。正確な名前を思い出すことはできませんが、マシンにアクセスできるとすぐに投稿できます。ログをldap oauth login。

ldapgitlab
17
Filipe Rodrigues

OP kidbombメンション ：

Deviseの設定は "@"の後のすべてを取り除きました。
LDAPにログを追加することでこれを発見しましたoauthログイン。

LDAPサーバーがldapからもアクセス可能かどうかを確認します（ldaps://ではありません）。

ldapsearch  -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldap://ldap.example.com:389 -w "password" -x "([email protected])"

はいの場合は、gitlab.yml設定ファイルldap.methodを「ssl」から「plain」に変更してみてください。

目的は、LDAPサーバーへの接続に使用される証明書がここで問題であるかどうかを検証することです。

Ldap：//（証明書なし）を介してサーバーに接続できる場合は、少なくとも回避策が提供されます。

そうでない場合（ldaps://を実行する必要があります）、LDAPサーバーに関連付けられている証明書をさらに詳しく調査する必要があります。

openssl s_client -connect ldap.example.com:636  2>/dev/null < /dev/null

（ここでは-CAFileまたは-CAPathを使用していません。CAが/etc/ssl/openssl.cnfに記載されているデフォルトの場所にあると想定しています）

そのコマンドの出力の最後にある場合、メッセージは次のとおりです。

error:num=21:unable to verify the first certificate

つまり、発行者から証明書を取得する必要があります。
「 シェルプロンプトからSSL証明書を確認する方法 」を参照してください。

9
VonC

シナリオの解決策を見つけたようですが、GitLabとLDAPで認証の問題が発生した他の人のために、いくつかの追加のトラブルシューティング手順を含めると思いました。

  • GitLabのLDAPレイクチェックを実行して、問題を特定します。 https://docs.gitlab.com/ce/administration/raketasks/ldap.html#check。使用しているGitLabインストールドキュメントに記載されているより包括的なものもあります。
  • SELinuxを使用している場合は、permissiveモードに設定します。
  • GitLabでApacheを使用している場合：LDAP-Apache Directory Studioをインストールして、接続を確立してみます。それができない場合は、おそらくconfig.ymlファイルに問題があります。まずベースから見ていきます。
  • Tcpdumpを実行し、.pcapファイルを検査のためにWireSharkにインポートします。
  • LDAPサーバーとGitLabサーバーのログを確認する
2
Ty Hitzeman

LDAP資格情報で構成されたgitlabsがありましたが、誰かがログインすると、「500内部サーバーエラー」メッセージが表示されました。しかし、/ etc/gitlab/gitlab.rbを正しくフォーマットすると、問題は解消したようです。使用しているgitlabのバージョンに応じて、ldap変数をフォーマットする方法はいくつかあるようです： 7.3.2.omnibus および master 。

2
alexkb