Pentaho BIサーバの認証に組織のActive Directoryを利用する。
公式のマニュアル
「=」記号はエスケープが必要
ここではActiveDirectoryのLDAP機能を利用する。ディレクトリの構造を把握して、適宜対応する。
${prefix}/pentaho-solutions/system/applicationContext-security-ldap.properties
contextSource.providerUrl=ldap\://[LDAPサーバのアドレス]\:389
contextSource.userDn=[バインド用のユーザ名]
contextSource.password=[バインド用のパスワード]
// 認証用にユーザを検索するベースツリー
userSearch.searchBase=OU\=people,DC\=example,DC\=jp
// 認証用のフィルタ{0}は入力されたユーザ名に置換される
userSearch.searchFilter=(sAMAccountName\={0})
populator.convertToUpperCase=false
// グループの設定
// グループのツリーをベースに検索し、member属性にユーザが含まれるものを検索する
populator.groupRoleAttribute=cn
populator.groupSearchBase=CN\=Users,DC\=example,DC\=jp
populator.groupSearchFilter=(member\={0})
populator.rolePrefix=
// グループ検索は検索ベースツリーのサブツリーも検索する
populator.searchSubtree=true
// BIサーバ内のファイルやディレクトリの権限設定画面で表示するロール（役割）の一覧を取得する
// 上記のグループ設定で用いたベースツリーでobjectClassがgroupのエントリを検索してリストにする
// ここではサブツリーが検索されないので注意。グループはあまり問題にはならない
allAuthoritiesSearch.roleAttribute=cn
allAuthoritiesSearch.searchBase=CN\=Users,DC\=example,DC\=jp
allAuthoritiesSearch.searchFilter=(objectClass\=group)
// BIサーバ内のファイルやディレクトリの権限設定画面で表示するユーザの一覧を取得する
// サブツリーが検索されないのでソースを一部修正（後述）
allUsernamesSearch.usernameAttribute=sAMAccountName
allUsernamesSearch.searchBase=OU\=people,DC\=example,DC\=jp
// 複数のOUに所属するユーザを一覧にしたい場合、サブツリーまで検索するようにしたうえで、
// グループの所属で必要なユーザをフィルタリングする。ここではmemberof属性を利用している
allUsernamesSearch.searchFilter=(&(sAMAccountName\=*)(|(memberof\=CN\=teacher_grp,OU\=research,DC\=example,DC\=jp)(memberof\=CN\=office_grp,OU\=office,DC\=example,DC\=jp)))
// 管理者のグループとユーザを設定
// 管理者ユーザとグループに設定すると、権限設定の一覧には登場しなくなるようだ
adminRole=CN\=abc_grp,CN\=Users,DC\=example,DC\=jp
adminUser=sAMAccountName\=admin_user,OU\=research,DC\=example,DC\=jp
マニュアルには記載されているが、特に変更しなくても動作するようだ。細かく権限設定をする際には必要かもしれない。
レポートデザイナー等からのパブリッシュなどもテストして、支障がないか確認する。
内部の認証サービスからLDAP認証に切り替える
${prefix}/pentaho-solutions/system/securities.properties
// providerをjackrabbitからldapに変更する provider=ldap
権限設定画面で表示するユーザの一覧を取得する設定「allUsernamesSearch」では検索ベースだけを検索し、サブツリーを検索しない。
一般的には、Pentahoを利用するユーザを特定のOUに入れたりするので、サブツリーを検索しなくても問題がないかもしれないが、設定した環境では利用ユーザが複数のOUに含まれており、検索する必要があった。AD側で対応することも検討したが、同一ユーザを複数のOUに所属させることはできず、エイリアスのような機能も無いようなので、上位からサブツリーを検索して所属グループ等で絞り込みをかけるしかない。そのためには、サブツリーを検索するように設定変更をする必要がある。ログイン時のユーザ検索では、サブツリーを検索するかどうかの設定項目があるのに、ユーザ一覧の検索では設定項目がなく、しかもサブツリーを検索しないのは謎だ。。。
以下のファイルに設定を加える。
${prefix}/pentaho-solutions/system/applicationContext-pentaho-security-ldap.xml
<!-- be sure to escape ampersands -->
<bean id="allUsernamesSearch"
class="org.pentaho.platform.plugin.services.security.userrole.ldap.search.GenericLdapSearch">
<constructor-arg index="0" ref="contextSource" />
<constructor-arg index="1">
<bean
class="org.pentaho.platform.plugin.services.security.userrole.ldap.search.LdapSearchParamsFactoryImpl">
<constructor-arg index="0" value="${ldap.allUsernamesSearch.searchBase}" />
<constructor-arg index="1" value="${ldap.allUsernamesSearch.searchFilter}" />
////////////////////////////////////////////////////////////
// この部分を追加
<constructor-arg index="2">
<bean class="javax.naming.directory.SearchControls">
<!-- 2 comes from http://java.sun.com/javase/6/docs/api/javax/naming/directory/SearchControls.html#SUBTREE_SCOPE -->
<property name="searchScope" value="2" />
</bean>
</constructor-arg>
////////////////////////////////////////////////////////////
</bean>
</constructor-arg>
<constructor-arg index="2">
<bean
class="org.pentaho.platform.plugin.services.security.userrole.ldap.transform.SearchResultToAttrValueList">
<constructor-arg index="0" value="${ldap.allUsernamesSearch.usernameAttribute}" />
</bean>
</constructor-arg>
</bean>
XMLの構造を慎重に確認しながら、constructor-arg要素を追加する。javaはよくわからないが、LDAPコネクションを作成する際のコンストラクタに適切なパラメータを渡すことで、検索のスコープを設定しているようだ。javaが理解できれば比較的容易に設定個所を特定できるのだろうが、かなり時間がかかった。一応、決め手のサイトは以下。