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:
私を正しい方向に向けることができた@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認証モードになっていることを意味します(他の方法では機能しないようです)が、内部のみのシステムであるため、問題ありません。
SonarQubeLDAPプラグインをActiveDirectoryと連携させる作業を行いました。ネットワークの設定は人によって異なるため、構成をコピーして貼り付けるだけでは不十分な場合がよくあります。これが私の会社で正しい構成を理解するために使用したプロセスです:
documentation で述べられているように、この構成はファイルに含まれます。
SONARQUBE_HOME/conf/sonar.properties
次の行はそのままで必要です:sonar.security.realm=LDAP
。その他の路線は会社ごとに異なります。
GUIツールを使用して構成をテストすることは私にとって役に立ちました。 Softerra LDAP Browser (LDAP Administratorの無料の読み取り専用バージョン)を使用しました。そのLDAPブラウザでは、
ldap.url=ldap://dc01.mycompany.local:3268
の線に沿った何かで終わる必要があります。注:別の回答で述べられているように、これはこの画面にリストされているポートとは異なるポートである必要がある場合があります。ldap.bindDn
として使用しますldap.bindPassword
はそのユーザーのパスワードである必要があります。ldap.user.baseDn
に入れます。ldap.user.request
で決定する必要がある最後の部分。 ADで使用するSonarQubeドキュメントからの提案は私のために働きました:(&(objectClass=user)(sAMAccountName={login}))
。それがあなたのために働かない場合に備えて、理由を説明させてください。 「{login}」は、SonarQubeがユーザー名に入力したものに置き換えられるため、リクエスト文字列(LDAPブラウザでは「Filter」と呼ばれます)は、基本的に、「user」と等しいobjectClassを持つすべてのエントリを検索するように指示します。それらのsAMAccountNameは、SonarQubeWebポータルのユーザー名テキストボックスに入力されたものと同じです。サンプルの個人情報内には、「objectClass」というフィールドが少なくとも1つ必要です。それらの1つは、値「user」を持つ必要があります。 sAMAccountNameのフィールドも必要です。 SonarQubeWebポータルのユーザー名テキストボックスにその値を使用します。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
ログファイルの「ユーザーマッピング」出力行を使用して手動のldapsearchコマンドを構成し、ユーザーが正しく取得されていることを確認するまで、設定を入念に確認しました。
何らかの理由で、この設定を指定すると修正されました。
ldap.user.realNameAttribute=cn
この属性はオプションであり、とにかくデフォルトでcnになっているはずですが、手動で指定した場合にのみ機能します。これはバグの可能性があります。
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))"
実際のユーザー情報が返ってきたら、基本設定が正しいことを意味します。これは、他の問題が発生していることを示唆しています。
新しいv1.5では、必要な行は1行だけです。
sonar.security.realm = LDAP
ポート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
以前はどの解決策もうまくいきませんでしたが、これは:
# 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サーバーの構成によって異なります。