web-dev-qa-db-ja.com

SonarQube LDAP認証が読み込まれているようですが、ドメインユーザー経由のログインは許可されません

LDAP認証プラグイン(v1.4)を使用してSonarQube(v4.1)をセットアップしようとしましたが、ドメインユーザーに対して認証することができません。私の設定は次のように設定されています:

#########################
# LDAP configuration
#########################
# General Configuration
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.downcase=true
sonar.authenticator.createUsers=true

ldap.authentication=simple
ldap.realm=mydomain.co.uk
ldap.bindDn=CN=USERNAME,OU=developers,DC=mydomain,DC=co,DC=uk
ldap.bindPassword=PASSWORD

# User Configuration
#ldap.user.baseDn=OU=developers,DC=mydomain,DC=co,DC=uk
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

# Group Configuration
ldap.group.baseDn=CN=Domain Users,CN=Users,DC=adastra,DC=co,DC=uk
ldap.group.request=(&(objectClass=group)(member={dn}))

ログには、LDAP接続が正常に機能していると思われる次のメッセージが出力されます。

2014.01.20 16:12:32 INFO  [org.sonar.INFO]  Security realm: LDAP
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Auto discovery mode
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Detected server: ldap://dc02.mydomain.co.uk:389
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  User mapping: LdapUserMapping{baseDn=dc=mydomain,dc=co,dc=uk, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Group mapping: LdapGroupMapping{baseDn=CN=Domain Users,CN=Users,DC=mydomain,DC=co,DC=uk, idAttribute=cn, requiredUserAttributes=[dn], request=(&(objectClass=group)(member={0}))}
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapContextFactory]  Test LDAP connection on ldap://dc02.mydomain.co.uk:389: OK
2014.01.20 16:12:32 INFO  [org.sonar.INFO]  Security realm started

しかし、ローカルユーザーを使用しない限り、ユーザーにとっては機能しないようです。以下を設定してラッパーへのロギングを有効にする場合:

wrapper.console.loglevel=DEBUG

ログに次のエラーが表示されますが、あまり役に立ちません。 :)

2014.01.20 17:07:10 ERROR [Rails]  Error from external users provider: 
11
caveman_dick

私を正しい方向に向けることができた@aaronに感謝します!私の問題では、自動検出と接続していたフォレストの問題でした。 http://technet.Microsoft.com/en-us/library/cc978012.aspx によると、フォレストに接続するときは別のポートを使用して、フォレスト全体を検索できるようにする必要があります。たまたま接続したドメイン(自動検出モードでは正しくない可能性があります)。結局、私のために働いた構成は次のとおりでした:

# General Configuration
ldap.realm=mydomain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://dc.mydomain.com:3268 

# User Configuration
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

これは実際には非常に単純で、接続するためにユーザーアカウントを必要としません。これは、SIMPLE認証モードになっていることを意味します(他の方法では機能しないようです)が、内部のみのシステムであるため、問題ありません。

9
caveman_dick

SonarQubeLDAPプラグインをActiveDirectoryと連携させる作業を行いました。ネットワークの設定は人によって異なるため、構成をコピーして貼り付けるだけでは不十分な場合がよくあります。これが私の会社で正しい構成を理解するために使用したプロセスです:

documentation で述べられているように、この構成はファイルに含まれます。

SONARQUBE_HOME/conf/sonar.properties

次の行はそのままで必要です:sonar.security.realm=LDAP。その他の路線は会社ごとに異なります。

GUIツールを使用して構成をテストすることは私にとって役に立ちました。 Softerra LDAP Browser (LDAP Administratorの無料の読み取り専用バージョン)を使用しました。そのLDAPブラウザでは、

  1. 新しいプロファイルを作成します。
  2. [サーバーの検索]ボタンは、ldap.urlの決定に役立ちます。 ldap.url=ldap://dc01.mycompany.local:3268の線に沿った何かで終わる必要があります。注:別の回答で述べられているように、これはこの画面にリストされているポートとは異なるポートである必要がある場合があります。
  3. 今のところ、[ベースDN]ボックスは空白のままにすることができます。
  4. 認証には、現在ログオンしているユーザーを選択しました。
  5. 今のところ、フィルターは空白のままにすることもできます。
  6. [完了]をクリックすると、ADのトップレベルにアイテムが表示されます。
  7. F3は、クイック検索バーを切り替えます。
  8. 匿名認証を使用してSonarQubeをADに接続することはできないため、接続するSonarQubeサービスのユーザーを選択する必要があります。クイック検索でそのユーザーを検索します。
  9. CN(共通名)エントリが見つかります。それをダブルクリックして開きます。
  10. 識別名フィールドを見つけ、その値をコピーしてldap.bindDnとして使用します
  11. ldap.bindPasswordはそのユーザーのパスワードである必要があります。
  12. SonarQubeを正常に起動するにはこれで十分ですが、SonarQubeWebポータルにログインしようとしているユーザーを検索するには十分ではありません。そのためには、最初にサンプルの人(あなた自身など)を選びます。
  13. サンプルの人をもう一度クイック検索して、CNエントリを開きます
  14. それらのdistinguishedNameの値を取得し、「CN = {Their Name}」の部分を削除して、それをldap.user.baseDnに入れます。
  15. ldap.user.requestで決定する必要がある最後の部分。 ADで使用するSonarQubeドキュメントからの提案は私のために働きました:(&(objectClass=user)(sAMAccountName={login}))。それがあなたのために働かない場合に備えて、理由を説明させてください。 「{login}」は、SonarQubeがユーザー名に入力したものに置き換えられるため、リクエスト文字列(LDAPブラウザでは「Filter」と呼ばれます)は、基本的に、「user」と等しいobjectClassを持つすべてのエントリを検索するように指示します。それらのsAMAccountNameは、SonarQubeWebポータルのユーザー名テキストボックスに入力されたものと同じです。サンプルの個人情報内には、「objectClass」というフィールドが少なくとも1つ必要です。それらの1つは、値「user」を持つ必要があります。 sAMAccountNameのフィールドも必要です。 SonarQubeWebポータルのユーザー名テキストボックスにその値を使用します。
  16. その要求文字列が機能するかどうかをテストするには、LDAPブラウザ(Ctrl + F3)でディレクトリ検索を実行します。 ldap.user.baseDn値を「SearchDN」texboxに入れ、ldap.user.request値をFilter texboxに入れます(必ず手動で「{login}」をサンプルユーザー名に置き換えてください)。サンプル担当者のCNエントリを返す必要があります。
15
kevinpo

SonarQube 3.7.3を使用していて、機能する構成を添付しました。それがお役に立てば幸いです。

# General Configuration
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://...
ldap.bindDn=user
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=People,dc=company,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
3
Eddú Meléndez

私の修正

ログファイルの「ユーザーマッピング」出力行を使用して手動のldapsearchコマンドを構成し、ユーザーが正しく取得されていることを確認するまで、設定を入念に確認しました。

何らかの理由で、この設定を指定すると修正されました。

ldap.user.realNameAttribute=cn

どうして?

この属性はオプションであり、とにかくデフォルトでcnになっているはずですが、手動で指定した場合にのみ機能します。これはバグの可能性があります。

Ldapsearchを使用したデバッグ

ldapsearchを使用すると、アプリケーションクエリLDAPを直接バイパスできます。

この行のログファイルを調べました。

INFO  web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=DC=my-ad,DC=example,DC=com, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}

そして、次のようなldapsearchコマンドを作成しました。

ldapsearch -D CN=myldapuser,CN=Users,DC=my-ad,DC=example,DC=com -W -h my-ad.example.com -b "DC=my-ad,DC=example,DC=com" "(&(objectClass=user)(sAMAccountName=myuser))"
  • -Dは、バインドDN、基本的にLDAPのログインユーザー名を指定します
  • -Wは、ldapsearchがパスワードの入力を求めることを意味します
  • -hはLDAPURLを指定します
  • -bはログファイル行のbaseDNである必要があります
  • 最後の定位置パラメーターは、{0}を実際のユーザー名に置き換えた後のログファイル行からの要求値です。

実際のユーザー情報が返ってきたら、基本設定が正しいことを意味します。これは、他の問題が発生していることを示唆しています。

3
jtpereyda
2
Jirong Hu

ポート3268を使用することで、私はうまくいきました。 SonarQube5.0.1とActiveDirectoryで動作する構成は次のとおりです。

sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.createUsers=true

ldap.url=ldap://dc101.office.company.com:3268
ldap.bindDn=CN=Service Account,OU=Windows Service,OU=Accounts,OU=Resources,DC=office,DC=company,DC=com
ldap.bindPassword=PASSWORD

ldap.user.baseDn=DC=office,DC=company,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
0
Nathan

以前はどの解決策もうまくいきませんでしたが、これは:

# Configuration
sonar.realm=myreal.domain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://myreal.domain.com:389

ldap.bindDn=cn=CNUser,dc=domain,dc=com
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=people,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

#logeo lo que pasa
wrapper.console.loglevel=DEBUG

私のLDAPサーバーには認証が必要なので、それを避けることはできません。それがうまくいかない場合は、ldap.user.requestを指定しないようにしてください。すべてネットワークのLDAPサーバーの構成によって異なります。

0
EliuX