2. ユーザ管理

本章では、ユーザやグループ/組織といった利用者環境を構築・変更する方法について説明します。

2.1. ユーザリソース

ここでは、WebOTX Portalの利用者情報を管理するユーザリソースについて説明します。

ユーザリソースには、以下の情報が含まれます。

WebOTX Portalは、ログイン時の認証、アクセス権限に設定、認証連携などのタイミングで、ユーザリソースの情報を参照します。また、パスワードの変更時に、ユーザリソースの個人のパスワード情報を更新します。

ユーザリソースは、ディレクトリサーバ "SECUREMASTER/EnterpriseDirectoryServer"(EDS)に格納します。

Memo
WebOTX Portal V8.4からは、ディレクトリサーバに「サービス」のデータを保存しません。データベースに保存するようになりました。

2.1.1. ディレクトリサーバ

ここでは、ディレクトリサーバについて説明します。

ディレクトリとは、各種オブジェクトの情報を保持し、その情報の検索/更新手段などを提供する特殊なデータベースシステムです。 具体的な例をあげると、会社の組織や社員などの管理やネットワーク機器の管理といった特定の目的のためのデータベースです。 ディレクトリの情報モデルは、次の構成要素があります。


図2.1.1-1

ディレクトリサーバが使用するLDAP(Lightweight Directory Access Protocol)とは、 IETF(The Internet Engineering Task Force)で 規定されたインターネット標準のディレクトリアクセス用のプロトコルで、 X.500 シリーズで規定されているDAP(Directory Access Protocol)のサブセットとして規定されています。 LDAP ディレクトリサーバとは、LDAP によるアクセスを可能としているディレクトリサーバのことです。 次にLDAP のネーミングモデルについて簡単に説明します。 LDAP ではそれぞれのエントリに対して、DIT 上で同じ直接上位をもつ他のエントリと識別でき るよう、エントリを構成する一つ以上の属性の属性値を利用して 「相対識別子(RDN:Relative Distinguished Name)」を付与する必要があります。 そのエントリからDIT のルートへ上位のRDN を連結したものを、そのエントリの「識別名(DN:Distinguished Name)」といいます。 例えば、上記DIT 例の ”uid=00001” のエントリの場合のDN は ”uid=00001, ou=people, o=webotxportal, c=JP” となります。 このDN によってエントリを一意に識別することが可能となります。

WebOTX Portalでは、ディレクトリサーバとして「SECUREMASTER/EnterpriseDirectoryServer」(EDS)が使用されます。 WebOTX Portalから使用するEDSを、個人・グループ/組織・ロール、サービスの管理以外の目的には利用できません。

2.1.2. ユーザリソースの構成

ここでは、ディレクトリサーバ上のユーザリソースの構成について説明します。

ディレクトリでは、それぞれのエントリはツリー構造で階層的に管理されますが、 それぞれのエントリの特長により配下にエントリを持つものと持てないものがあります。

  1. グループ/組織
    グループあるいは組織を表現するためのクラスです。一般的な組織構造に合わせて、ツリー構造を持つことができます。DN「ou="group" ,o="webotxportal" , c="JP"」配下で管理します。
  2. 個人
    個人を表現するためのクラスです。ツリー構造を持ちません。ただし、例外としてその個人が本来の所属部署以外の部署にも所属している場合、個人のエントリの配下に兼務用エントリを持つことができます。
    DN「ou="people" ,o="webotxportal" , c="JP"」配下で管理します。
  3. ロール
    役割を表現するためのクラスです。ツリー構造を持ちません。 DN「ou="role" ,o="webotxportal" , c="JP"」配下で管理します。
  4. コンフィグ
    WebOTX Portal内部で使用するユーザアカウントおよび職位のテーブルが含まれます。 職位のテーブルを適宜変更してください。


図2.1.2-1

DN「c="JP"」は、Naming Context Prefix(NCP)と呼ばれ、ディレクトリのルートエントリを示します。EDSのインストール時やEDSのデータベースを初期化する際に指定します。
DN「o="webotxportal",c="JP"」は、WebOTX Portalのユーザリソースの最上位エントリです。
DN「ou="people",o="webotxportal",c="JP"」は、個人のエントリを格納するためのエントリです。
DN「ou="group",o="webotxportal",c="JP"」は、グループ/組織のエントリを格納するためのエントリです。
DN「ou="role",o="webotxportal",c="JP"」は、ロールのエントリを格納するためのエントリです。
DN「ou="config",o="webotxportal",c="JP"」は、WebOTX Portal内部で使用するユーザアカウントと各個人が持つ職位のコードと名前を対応付けるテーブルのエントリを格納するためのエントリです。

2.1.2.1. 個人のエントリ

個人のエントリの管理について説明します。個人のIDや名前などのほとんどの情報は、個人エントリに持ちます。
WebOTX Portalでは、個人が複数のグループ/組織に所属している場合を想定します。その場合、本来の所属グループ/組織を個人エントリに、兼務するグループ/組織の情報を兼務用エントリに持たせます。個人エントリは、ou="people"の直下に配置します。 兼務用エントリは、その個人エントリの下に配置します。個人エントリの例を以下に示します。


図2.1.2.1-1

例では、3人分の個人エントリがあります。個人エントリのRDN(Relative Distinguished Name:相対識別名)には、属性値uid(ユーザID)を使用します。 「uid=00001」、「uid=00002」、「uid=00003」のエントリは、そのユーザの名前や本務所属の情報などを属性として持ちます。 「uid=00003」のユーザは、兼務を持っているものとします。その場合、「uid=00003」のエントリ直下に属性値「extJobNumber」をRDNとするエントリを登録します。 兼務情報のエントリには、兼務での職位や兼務での所属先の情報を属性として登録します。

Caution
WebOTX Portalへのログインには、少なくとも個人のエントリと職位テーブルが必要です。

Caution
ユーザの本務情報が未設定の場合、そのユーザに設定されている職位は有効になりません。そのユーザは職位コードが0の職位として扱われます。

2.1.2.2. グループ/組織のエントリ

グループ/組織のエントリの管理について説明します。
WebOTX Portalでは、グループ/組織はツリー構造で作成します。ou="group"の直下には、最上位のグループ/組織のエントリを配置します。 最上位のグループ/組織のエントリを複数登録することができます。 グループ/組織エントリの例を以下に示します。


図2.1.2.2-1

例では、最上位のグループ/組織として二つのエントリがあります。グループ/組織エントリのRDNには、属性値groupid(グループID)を使用します。 「groupid=SALES」、「groupid=PRODUCT」のエントリは、そのグループ/組織の名前などを属性として持ちます。 「groupid=SALES」のグループ/組織は、下位組織をもっているものとします。その場合、「groupid=SALES」のエントリの直下にgroupidをRDNとするグループ/組織エントリを登録します。例では、「groupid=1stSales」、「groupid=2ndSales」をRDNとするエントリが「groupid=SALES」の直下のグループ/組織です。さらにその配下にグループ/組織が存在する場合、同様に「groupid=1stSales」や「groupid=2ndSales」の配下にgroupidをRDNとするエントリを登録します。

2.1.2.3. ロールのエントリ

役割(ロール)のエントリの管理について説明します。
ロールは、個人やグループ/組織がどのような仕事上の機能を果たすかを示すもので、WebOTX Portal上の操作を行う許可に関係します。 ロールをWebOTX Portalでは、ou="role"の直下に配置します。役割同士をツリー構造にすることはできません。 ロールエントリの例を以下に示します。


図2.1.2.3-1

例では、三つのロールエントリがあります。ロールエントリのRDNには、属性値roleid(ロールID)を使用します。 「roleid=OTXPORTAL_ADMIN」のエントリは、WebOTX Portalの環境構築時から登録されているもので、ポータルシステムの管理者の役割を示します。 このロールを割り当てられたユーザは、WebOTX Portalの中で特別なアクセス権限が与えられます。
必要に応じて、「roleid=manager」「roleid=employee」などのエントリを追加することができます。 その後必要に応じてロールを個人やグループ/組織に割り当てます。

2.1.2.5. コンフィグのエントリ

コンフィグのエントリの管理について説明します。
コンフィグはWebOTX Portal内部で使用するアカウントおよび職位のテーブルを配置するためのエントリです。 WebOTX Portal内部で使用するアカウントは、通常変更する必要はありません。 職位のテーブルは、職位のコードと職位の名前を属性値で指定します。 職位は、WebOTX Portalを使用されるお客様の組織によって異なりますので、テーブル内の属性値を適切な値に設定しておく必要があります。 コンフィグエントリを以下に示します。


図2.1.2.5-1

2.1.3. エントリの属性

ここでは、個人、グループ/組織、ロールおよびコンフィグの職位テーブルで使用可能な属性について説明します。

2.1.3.1. 属性一覧

ユーザリソースで使用できる属性の一覧を示します。

それぞれのエントリでは、下記の一覧に記載の属性を指定してください。
"必須属性"が○または●である属性は、エントリに必須です。
"複数指定"可能な属性は、一つのエントリに複数の属性値を指定できます。例えば、"assignedRole"という属性をエントリに複数登録し、それぞれの属性に値を設定できます。
"諸元"は属性のディレクトリ上の最大長です。
"ロケール指定"が○の属性は、属性値にロケール無し、英語ロケール(lang-en)、日本語ロケール(lang-ja)の三種類を使用できることを示しています。ロケール無しと英語ロケールには英語の名前を、日本語ロケールには日本語の名前を設定してください。WebOTX Portalは、WebOTX Portalの言語環境に対応するロケールの属性値が無い場合、ロケール無しの属性値を使用します。

Caution
"諸元"は、属性のオブジェクトクラス定義上の上限です。WebOTX Portalで使用する場合、"条件"に記載の文字種、長さに従ってください。

Caution
"会社名"、"会社ID"、"性別"は、ディレクトリ上の属性として設定できますが、WebOTX Portal V8.31では使用していませんので、設定する必要はありません。

表2.1.3.1-1
  属性 オブジェクトクラス 属性名 必須属性 複数指定 諸元 ロケール指定 条件
webotxportalエントリ 会社名 otxCompany cn   32768  

ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで (ANK、日本語混在不可)

属性が無い場合には既定値として「自社」(ロケールlang-ja)「MyCompany」(ロケール無しおよびlang-en)が使用される。

会社ID otxCompany companyid   32  

32文字まで(英大文字・数字)

属性が無い場合には既定値として「mycompanyid」が使用される。

個人エントリ             ユーザID inetOrgPerson uid   256   32文字まで(英大文字・数字)
ユーザパスワード person   userPassword     128   パスワード(ASCIIコードの0x21~0x7eの範囲の半角英数128文字以下)

姓(Family Name) person   sn(surname)   32768 ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで、(ANK、日本語混在不可)
名(Given Name) inetOrgPerson givenname     32768 ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで、(ANK、日本語混在不可)
ミドルネーム otxUser middlename     32768 ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで、(ANK、日本語混在不可)
メールアドレス inetOrgPerson mail     256   英数字、記号
本務所属部門のグループID otxUser mainBelongGroup     32   グループ/組織エントリのグループID(groupid)の仕様に順ずる
職位コード otxUser positionid   6   職位テーブルエントリのコードの値
管理している部門のグループID otxUser manageGroup   32   グループID(groupid)の仕様に順ずる
所有ロールID otxUser assignedRole   32   ロールエントリのロールIDの仕様に順ずる
利用サービスLogin情報 so21PersonExtendSO apLoginContext   1015   英数字、記号
サービスID so21PersonExtendSO apServiceID   32   サービスID(serviceID)の仕様に順ずる
パーソナライズ otxUser portalPersonalization     指定無し   ポータルのパーソナライズ利用可否 コードを指定。
0:パーソナライズ不可
1:パーソナライズ許可
性別 otxUser gender     1   性別をアルファベット1文字で指定する

M:男性
F:女性

本属性値が無い場合には、M:男性として扱う
兼務用エントリ    兼務番号 otxAdditionalUser extJobNumber   6   数字
兼務所属部門 otxAdditionalUser extBelongGroup   32   グループ/組織エントリのグループID(groupid)の仕様に順ずる
職位コード otxAdditionalUser positionid 6   職位テーブルエントリのコードの値
ユーザID otxAdditionalUser uid   256   16文字まで(英大文字・数字)
グループ/組織エントリ    グループ名 organizationalUnit ou   32768 ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで (ANK、日本語混在不可)
グループID otxGroup groupid   32   32(英大文字・数字)
所有ロールID otxGroup assignedRole   32   ロールエントリのロールIDの仕様に順ずる
パーソナライズ otxGroup portalPersonalization     指定無し   ポータルサイトのパーソナライズ利用可否コードを指定。
0: グループ/組織のパーソナライズ不可
1: 所属ユーザにパーソナライズを許可
2: グループ/組織のパーソナライズを許可
3: グループ/組織と所属ユーザのパーソナライズを許可
ロールエントリ  ロール名 organizationalRole cn   32768 ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで (ANK、日本語混在不可)
ロールID otxRole roleid   32   32文字まで(英大文字・数字)
職位テーブルエントリ 職位コード・ラベル対応データ so21ControlTable so21ControlItem   256 必ず「コード=ラベル」というフォーマットで登録してください。 コードは、00〜99の半角数字2桁で指定してください。

必須属性のうち、○はオブジェクトクラスの定義により必須であるもの、●はWebOTX Portal上で使用する上で必須であるものです。

Caution
上記で使用しているオブジェクトクラスには、WebOTX Portalで使用していない属性が含まれます。例えば、EDS運用管理ツールで個人エントリを作成するとき、構造型オブジェクトクラスのotxUserを選択すると、"telephoneNumber"の属性も指定できます。しかし、WebOTX Portalで使用していないため、それらの属性は無視します。

Caution
WebOTX Portalを使用するには、少なくとも個人エントリと職位テーブルエントリが必要です 。

2.1.3.2. 個人の属性

個人の属性について説明します。

WebOTX Portalでは、利用者自身のパスワードを自分で変更できます。そのため、userPassword属性に使用できる値は、上記のパスワードの属性条件に従います。

mainBelongGroup属性には、その個人が所属しているグループ/組織のグループIDを指定します。その個人が本務および兼務を持っている場合、本務のグループIDを指定してください。 positionid属性には、職位テーブルのso21ControlItem属性で指定する「コード=ラベル」のコードを指定します。

manageGroup属性には、その個人が管理者となっているグループ/組織のグループIDを指定します。グループ/組織がポータルサイトを持っている場合、管理者となっている個人は、そのポータルサイトを編集することができます。

assignedRole属性には、その個人に割り当てられるロールのIDを指定します。ロールは次の二つの用途に使用できます。まず、WebOTX Portalのアクセス権限設定でロールに対して何らかの権限が与えられていれば、そのロールが割り当てられた個人はその権限を持ちます。詳しくは、 [3. ポータルサイトの基本操作 > 3.10.アクセス権の設定 ]を参照してください。次に、ポートレットの中で、javax.servlet.http.HttpServletRequestインタフェースのisUserInRoleメソッドを使用することで、利用者がそのロールを割り当てられているかどうかを判定できます。
WebOTX Portalのインストール後の作業でEDSに登録される"OTXPORTAL_ADMIN"ロールは上記に加えて、EDSへのアクセス制御において特別なロールとして設定されています。詳しくは、[ 2.1.5. アクセス制御 ]を参照してください。

apLoginContext属性は、認証連携機能で使用する属性値です。

Caution
apLoginContextの設定は、ポータルログイン時に用いるユーザID/パスワードと異なるユーザID/パスワードにて連携先アプリケーションの認証を行う必要がある場合のみ設定を行います。

認証連携では、個人毎に異なるパラメータを利用してWebアプリケーションと認証連携することもできます。例えば、次のような場合が該当します。

このような場合、ディレクトリサービスの個人エントリのapLoginContext属性へ、連携対象のWebアプリケーション単位にて、認証連携時に必要な個人に依存するデータを格納することで実現できます。
apLoginContext属性の形式は次の通りです。

サービスID;名前=値

例を示します。

WebKeiri;txtuid=1122334455,txtpwd=password1

上記の場合、"WebKeiri"はサービスIDです。"txtuid"と”txtpwd”は項目名であり、"1122334455"と”password1”は項目の値です。

portalPersonalization属性は、個人が所有するポータルサイトを編集することができるかどうかを指定します。編集を許可させない場合には"0"を、許可させる場合には"1"を指定します。値が指定されていない場合、その個人が本務で所属しているグループ/組織のportalPersonalization属性に基づいて決定されます。

apServiceID属性は、認証連携ポートレットが参照する属性であり、どの業務アプリケーションにアクセスできるかを表現します。 本属性は、当該の個人が利用できるサービスのserviceID を示します。

Memo
portalPersonalization属性値は、アクセス権限機能のパーソナライズの利用可否判定値が"true"の場合に使用されます。 詳しくは、[ 運用ガイド > 6. コンフィグレーション > 6.1. 各種設定 > 6.1.5. アクセス権に関する設定]を参照してください。

2.1.3.2.1. 兼務の属性

個人が兼務を持つ場合、兼務のエントリを作成します。RDNとなる"extJobNumber"には、1,2などの数字を指定してください。 この属性は1つの個人エントリの中で重複を避けるためのものであり、この数字自体は意味を持ちません。異なる個人エントリで同じ数字を使用することは問題ありません。
extBelongGroup属性には、その個人が兼務で所属しているグループ/組織のグループIDを指定します。
positionid属性には、兼務先でその個人に割り当てられた職位コードを指定します。本務や他の兼務と重複することもできます。

2.1.3.3. グループ/組織の属性

グループ/組織の属性について説明します。

portalPersonalization属性は、そのグループ/組織が所有するポータルサイトを編集することができるかどうかを指定します。 編集を許可させない場合には"0"または"1"を、許可させる場合には"2"または"3"を指定します。値が指定されていない場合、編集は許可されません。

この値は、個人が自身の所有するポータルサイトを編集できるかどうかにも関係します。個人エントリにportalPersonalization属性が指定されておらず、その個人が本務所属するグループ/組織のportalPersonalization属性が"1"または"3"の場合、編集が許可されます。

assignedRole属性には、そのグループ/組織に割り当てるロールのIDを指定します。グループ/組織に割り当てられたロールは、そのグループ/組織に本務で直属する個人に対しても割り当てられているものとして扱われます。
例えば、グループ/組織「BU1」に対してロール「ROLE123」が割り当てられているとき、BU1に本務で直属する個人「00000」がWebOTX Portalにログインすると、ロール「ROLE123」に対して許可されているアクセスが可能です。
BU1に兼務で所属している個人にはROLE123の権利は与えられません。また、BU1の配下の部門、例えば「JH1-BU1」に本務または兼務で所属している個人にはROLE123の権利は与えられません。

2.1.3.4. ロールの属性

ロールの属性について説明します。ロールの意味については、[2.1.2.3. ロール]を参照してください。

ロールにつける名をcn属性で、ロールのIDをroleid属性で指定します。

2.1.3.5. 職位テーブルの属性

コンフィグの中の職位テーブルの属性について説明します。

コンフィグに属する職位テーブルのso21ControlItem属性には、必ず「コード=ラベル」というフォーマットで登録してください。 コードは、00〜99の半角数字2桁で指定してください。職位テーブルの例は、[ 2.1.4.4. 職位の登録、変更 ]を参照してください。

2.1.4. ユーザリソース操作

ここでは、個人、グループ/組織、ロール登録、変更、削除について説明します。

Memo
組織改変の場合には、組織名の変更や組織の移動のためグループ/組織エントリの更新や他のグループ/組織エントリ配下への移動を行います。新入社員を迎えた場合には、個人エントリの追加を行います。兼務が設定された場合には、その個人のエントリの下に兼務用エントリを追加します。昇格した場合には、その個人のエントリのpositionid属性値を変更します。

ユーザリソースの操作には、EDSのコマンドや運用管理ツールを使用します。入力データとして、LDIF (LDAP Data Interchange Format)ファイルやCSV (comma-separated values)ファイルを使用することができます。

Memo
EDSのedmodifyコマンドやedcsvコマンドで使用するLDIFやCSVファイルの中でエントリ記述や属性値を日本語で記述する場合、EDSコマンドを実行するOSに合わせた以下の文字コードを使用します。
・Windows … SJIS
・HP-UX … SJIS
・Solaris … EUC
・Linux … /etc/opt/nec/eds/edsccmd.conf のLANG値
また、UTF8をBase64符号化した文字列も使用できます。詳しくは、EDSのマニュアル「ユーティリティ利用の手引」「運用の手引き」を参照してください。

Memo
ユーザリソースの操作でエラーが発生した場合には、エラーメッセージやAccess.logなどで原因を調べ、対処してください。
複数のデータを登録、変更、削除する場合、エラーが発生するまでの正常な操作は完了している場合があります。
どこまで実施されているかは、エラーメッセージやAccess.log、または実際のデータをEDS運用管理ツールなどで参照することにより確認することができます。

ユーザリソースの更新に失敗した場合、EDSのコマンドや運用管理ツールはエラーメッセージを出力します。 例えば、更新対象のエントリが存在しない場合、EDSのedmodifyコマンドは次のようなメッセージをコンソールに出力します。

 ******** ERROR ********
  ldap_modify_ext_s()
  ldaperr: 指定されたオブジェクトは存在しません。(0x0020/0x8002040e)
  #1 DN:uid="00000A", ou="people" , o="webotxportal", c="JP"
  'errorusermodify.ldif'

  success entry count: 0

エラーが発生した場合には、DNは存在するオブジェクトを示しているか、属性名が間違っていないかなどを確認してください。

 

2.1.4.1. 個人の登録、変更、削除

個人の登録

個人を登録する場合、テキストエディタで以下のようなファイルを作成し、userinsert.ldif として保存します。
個人のエントリに対して使用できる属性の詳細については、[2.1.3.1. 属性一覧]および[2.1.3.2. 個人の属性]を参照してください。
ここでは、ユーザID"00000"の個人を登録しています。

dn: uid="00000", ou="people" , o="webotxportal", c="JP"
objectClass: person
objectClass: inetOrgPerson
objectClass: otxUser
objectClass: so21PersonExtendSO
objectClass: top
uid: 00000
userPassword: pwd00000
cn: Test00000 Userid00000
sn: Userid00000
sn;lang-ja: 名字00000
sn;lang-en: Family00000
givenname: Given00000
givenname;lang-ja: 名前00000
givenname;lang-en: given00000
middlename: middlename00000
middlename;lang-ja: ミドルネーム00000
middlename;lang-en: middle00000
mail:mail00000
manageGroup:BU1
assignedRole:ROLE00000
apServiceID: service01
apLoginContext: SERVICE01;UID=USER001,PASSWD=passxxxx,DBNAME=DB001,URL=http%3A%2F%2Fwww.nec.co.jp,OPTION=OPT001
portalPersonalization: 1
positionid: 1
mainBelongGroup:BU1

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。 edmodify コマンドは、起動時オプションを指定することができます。オプションを指定しない場合、対話形式モードになります。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -a -W -f userinsert.ldif

以下のように表示されれば成功です。

   -----------------------
   エントリをインポートしました。
   #1 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
   'userinsert.ldif'
   success entry count: 1
   

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、userinsert.csv として保存します。CSVファイルの形式の詳細については、EDSのマニュアル「ユーティリティ利用の手引」の「6.4 CSV形式の規則」を参照してください。

"dn","objectClass","objectClass","objectClass","objectClass","objectClass","uid","userPassword","cn","sn","sn;lang-ja","sn;lang-en","givenname","givenname;lang-ja","givenname;lang-en","middlename","middlename;lang-ja","middlename;lang-en","mail","manageGroup","assignedRole","apServiceID","apLoginContext","portalPersonalization","positionid","mainBelongGroup"
"uid=""00000"", ou=""people"" , o=""webotxportal"", c=""JP""","person","inetOrgPerson","otxUser","so21PersonExtendSO","top","00000","pwd00000","Test00000 Userid00000","Userid00000","名字00000","Family00000","Given00000","名前00000","given00000","middlename00000","ミドルネーム00000","middle00000","mail00000","BU1","ROLE00000","service01","SERVICE01;UID=USER001,PASSWD=passxxxx,DBNAME=DB001,URL=http%3A%2F%2Fwww.nec.co.jp,OPTION=OPT001","1","1","BU1"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsv コマンドは、起動時オプションを指定することができます。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -changetype add -f userinsert.csv -W

以下のように表示されれば成功です。

 -----------------------
  エントリを追加しました。
  #2 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
  'userinsert.csv'

  success entry count: 1
   
個人の変更

個人のエントリを変更する場合、テキストエディタで以下のようなファイルを作成し、usermodify.ldif として保存します。 ここでは、メールアドレスを変更しています。 1つのエントリに対して追加、更新、削除など複数の属性変更を行う場合、それぞれの変更の間にハイフン(-)の行を追加します。

dn: uid="00000", ou="people" , o="webotxportal", c="JP"
changetype: modify
replace: mail
mail:test@test.test.jp
-

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f usermodify.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #1 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
  'usermodify.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、usermodify.csv として保存します。

"dn","changetype","mail"
"uid=""00000"", ou=""people"" , o=""webotxportal"", c=""JP""","modrep","test@test.test.jp"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -f usermodify.csv -W

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #2 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
  'usermodify.csv'

  success entry count: 1
個人の削除

個人のエントリを削除する場合、テキストエディタで以下のようなファイルを作成し、userdelete.ldif として保存します。

dn: uid="00000", ou="people" , o="webotxportal", c="JP"
changetype: delete

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f userdelete.ldif

以下のように表示されれば成功です。

   -----------------------
  エントリを削除しました。
  #1 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
  'userdelete.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、userdelete.csv として保存します。

"dn","changetype"
"uid=""00000"", ou=""people"" , o=""webotxportal"", c=""JP""","del"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -f userdelete.csv -W

以下のように表示されれば成功です。

 -----------------------
  エントリを削除しました。
  #2 DN:uid="00000", ou="people" , o="webotxportal", c="JP"
  'userdelete.csv'

  success entry count: 1

2.1.4.2. グループ/組織の登録、変更、削除

ここでは、グループ/組織の登録、変更、削除について説明します。

グループ/組織の登録

グループ/組織を登録する場合、テキストエディタで以下のようなファイルを作成し、groupinsert.ldif として保存します。
グループ/組織のエントリに対して使用できる属性の詳細については、[2.1.3.1. 属性一覧]および[2.1.3.3. グループ/組織の属性]を参照してください。
ここでは、部門"BU1"のグループ/組織を登録しています。

dn: groupid="BU1",  ou="group" , o="webotxportal", c="JP"
objectClass: organizationalUnit
objectClass: otxGroup
objectClass: top
groupid: BU1
ou: TestGroupBU1
ou;lang-ja: テストグループBU1
ou;lang-en: GroupBU1
portalPersonalization: 2
assignedRole: ROLE00000

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -a -W -f groupinsert.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリをインポートしました。
  #1 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupinsert.ldif'

  success entry count: 1
   

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、groupinsert.csv として保存します。

"dn","objectClass","objectClass","objectClass","groupid","ou","ou;lang-ja","ou;lang-en","portalPersonalization","assignedRole"
"groupid=""BU1"",  ou=""group"" , o=""webotxportal"", c=""JP""","organizationalUnit","otxGroup","top","BU1","TestGroupBU1","テストグループBU1","GroupBU1","2","ROLE00000"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W  -changetype add -f groupinsert.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを追加しました。
  #2 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupinsert.csv'

  success entry count: 1
   
グループ/組織の変更

グループ/組織のエントリを変更する場合、テキストエディタで以下のようなファイルを作成し、groupmodify.ldif として保存します。 ここでは、日本語と英語の部門名を変更しています。 1つのエントリに対して追加、更新、削除など複数の属性変更を行う場合、それぞれの変更の間にハイフン(-)の行を追加します。

dn: groupid="BU1",  ou="group" , o="webotxportal", c="JP"
changetype: modify
replace: ou
ou: BU1 Department
ou;lang-ja: BU1部門
ou;lang-en: BU1 Department
-

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f groupmodify.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #1 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupmodify.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、groupinsert.csv として保存します。

"dn","changetype","ou","ou;lang-ja","ou;lang-en"
"groupid=""BU1"",  ou=""group"" , o=""webotxportal"", c=""JP""","modrep","BU1 Department","BU1部門","BU1 Department"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -f groupmodify.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #2 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupmodify.csv'

  success entry count: 1
   
グループ/組織の削除

グループ/組織のエントリを削除する場合、テキストエディタで以下のようなファイルを作成し、groupdelete.ldif として保存します。

dn: groupid="BU1",  ou="group" , o="webotxportal", c="JP"
changetype: delete

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f groupdelete.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリを削除しました。
  #1 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupdelete.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、groupdelete.csv として保存します。

"dn","changetype"
"groupid=""BU1"",  ou=""group"" , o=""webotxportal"", c=""JP""","del"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -f groupdelete.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを削除しました。
  #2 DN:groupid="BU1",  ou="group" , o="webotxportal", c="JP"
  'groupdelete.csv'

  success entry count: 1
   

 

2.1.4.3. ロールの登録、変更、削除

ここでは、ロールの登録、変更、削除について説明します。

ロールの登録

ロールを登録する場合、テキストエディタで以下のようなファイルを作成し、roleinsert.ldif として保存します。
ロールのエントリに対して使用できる属性の詳細については、[2.1.3.1. 属性一覧]および[2.1.3.4. ロールの属性]を参照してください。
ここでは、ロールID"ROLE00000"のロールを登録しています。

dn: roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
objectClass: organizationalRole
objectClass: otxRole
objectClass: top
roleid: ROLE00000
cn: TestRoleROLE00000
cn;lang-ja: テストロールROLE00000
cn;lang-en: RoleROLE00000

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -a -W -f roleinsert.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリをインポートしました。
  #1 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'roleinsert.ldif'

  success entry count: 1
   

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、roleinsert.csv として保存します。

"dn","objectClass","objectClass","objectClass","roleid","cn","cn;lang-ja","cn;lang-en"
"roleid=""ROLE00000"", ou=""role"" , o=""webotxportal"", c=""JP""","organizationalRole","otxRole","top","ROLE00000","TestRoleROLE00000","テストロールROLE00000","RoleROLE00000"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -changetype add -f roleinsert.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを追加しました。
  #2 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'roleinsert.csv'

  success entry count: 1
   
ロールの変更

ロールのエントリを変更する場合、テキストエディタで以下のようなファイルを作成し、rolemodify.ldif として保存します。 ここでは、日本語と英語のロール名を変更しています。 1つのエントリに対して追加、更新、削除など複数の属性変更を行う場合、それぞれの変更の間にハイフン(-)の行を追加します。

dn: roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
changetype: modify
replace: cn
cn: ROLE00000
cn;lang-ja: ロール00000
cn;lang-en: ROLE00000
-

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f rolemodify.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #1 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'rolemodify.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、rolemodify.csv として保存します。

"dn","objectClass","objectClass","objectClass","roleid","cn","cn;lang-ja","cn;lang-en"
"roleid=""ROLE00000"", ou=""role"" , o=""webotxportal"", c=""JP""","organizationalRole","otxRole","top","ROLE00000","TestRoleROLE00000","テストロールROLE00000","RoleROLE00000"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -f rolemodify.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを編集しました。
  #2 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'rolemodify.csv'

  success entry count: 1
ロールの削除

ロールのエントリを削除する場合、テキストエディタで以下のようなファイルを作成し、roledelete.ldif として保存します。

dn: roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
changetype: delete

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f roledelete.ldif

以下のように表示されれば成功です。

 -----------------------
  エントリを削除しました。
  #1 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'roledelete.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、roledelete.csv として保存します。

"dn","changetype"
"roleid=""ROLE00000"", ou=""role"" , o=""webotxportal"", c=""JP""","del"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -f roledelete.csv

以下のように表示されれば成功です。

 -----------------------
  エントリを削除しました。
  #2 DN:roleid="ROLE00000", ou="role" , o="webotxportal", c="JP"
  'roledelete.csv'

  success entry count: 1

2.1.4.4. 職位の登録、変更

ここでは、職位の登録、変更について説明します。

職位の登録

職位を登録する場合、テキストエディタで以下のようなファイルを作成し、positioninsert.ldif として保存します。 1つの職位コードに対して1つのラベルを指定します。
同じ職位コードに複数のラベルを指定しないでください。

dn: cn="Jobtable", ou="table", ou="config" , o="webotxportal", c="JP"
objectClass: so21ControlTable
objectClass: top
cn:Jobtable
so21ControlItem: 00=Staff
so21ControlItem: 01=Assistant Manager
so21ControlItem: 02=Manager
so21ControlItem: 03=Group Manager
so21ControlItem: 04=President
so21ControlItem;lang-en: 00=Staff
so21ControlItem;lang-en: 01=Assistant Manager
so21ControlItem;lang-en: 02=Manager
so21ControlItem;lang-en: 03=Group Manager
so21ControlItem;lang-en: 04=President
so21ControlItem;lang-ja: 00=担当
so21ControlItem;lang-ja: 01=主任
so21ControlItem;lang-ja: 02=課長
so21ControlItem;lang-ja: 03=部長
so21ControlItem;lang-ja: 04=社長

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。 edmodify コマンドはそのまま実行すると対話形式モードになります。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -a  -W -f positioninsert.ldif
以下のように表示されれば成功です。
 -----------------------
  エントリをインポートしました。
  #1 DN:cn="Jobtable", ou="table", ou="config" , o="webotxportal", c="JP"
  'positioninsert.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、positioninsert.csv として保存します。

"dn","objectClass","objectClass","cn","so21ControlItem","so21ControlItem","so21ControlItem","so21ControlItem","so21ControlItem"
"cn=""Jobtable"", ou=""table"", ou=""config"" , o=""webotxportal"", c=""JP""","so21ControlTable","top","Jobtable","00=担当","01=主任","02=課長","03=部長","04=社長"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -changetype add -f positioninsert.csv
以下のように表示されれば成功です。
 -----------------------
  エントリを追加しました。
  #2 DN:cn="Jobtable", ou="table", ou="config" , o="webotxportal", c="JP"
  'positioninsert.csv'

  success entry count: 1

 

職位の変更

職位を変更する場合、テキストエディタで以下のようなファイルを作成し、modtable.ldif として保存します。 1 つの職位コードに対して1 つのラベルを指定します。
同じ職位コードに複数のラベルを指定しないでください。
ldif ファイルによる更新では、全職位テーブルを置換します。
既存の職位テーブルに追加する場合であっても、全職位テーブルを指定してください。

dn: cn="Jobtable" ,ou="table" ,ou="config" ,o="webotxportal" , c="JP"
changetype: modify
replace: so21controlitem
so21controlitem: 00=Staff2
so21controlitem: 05=Staff1
so21controlitem: 10=Assistant Manager2
so21controlitem: 15=Assistant Manager1
so21controlitem: 20=Manager2
so21controlitem: 25=Manager1
so21controlitem: 30=Group Manager2
so21controlitem: 35=Group Manager1
so21controlitem: 40=Director2
so21controlitem: 45=Director1
so21controlitem: 50=President
so21controlitem;lang-en: 00=Staff2
so21controlitem;lang-en: 05=Staff1
so21controlitem;lang-en: 10=Assistant Manager2
so21controlitem;lang-en: 15=Assistant Manager1
so21controlitem;lang-en: 20=Manager2
so21controlitem;lang-en: 25=Manager1
so21controlitem;lang-en: 30=Group Manager2
so21controlitem;lang-en: 35=Group Manager1
so21controlitem;lang-en: 40=Director2
so21controlitem;lang-en: 45=Director1
so21controlitem;lang-en: 50=President
so21controlitem;lang-ja: 00=担当2
so21controlitem;lang-ja: 05=担当1
so21controlitem;lang-ja: 10=主任2
so21controlitem;lang-ja: 15=主任1
so21controlitem;lang-ja: 20=課長2
so21controlitem;lang-ja: 25=課長1
so21controlitem;lang-ja: 30=部長2
so21controlitem;lang-ja: 35=部長1
so21controlitem;lang-ja: 40=役員2
so21controlitem;lang-ja: 45=役員1
so21controlitem;lang-ja: 50=社長 -

EDSのedmodify コマンドを実行します。edmodifyの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。 edmodify コマンドはそのまま実行すると対話形式モードになります。

# edmodify -h localhost -p 389 -D cn=ldapadministrator,c=JP -W -f modtable.ldif
以下のように表示されれば成功です。
 -----------------------
  エントリを編集しました。
  #1 DN:cn="Jobtable" ,ou="table" ,ou="config" ,o="webotxportal" , c="JP"
  'modtable.ldif'

  success entry count: 1

CSVファイルを使用する場合、テキストエディタで以下のようなファイルを作成し、 modtable.csv として保存します。

"dn","changetype","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem","so21controlitem"
"cn=""Jobtable"" ,ou=""table"" ,ou=""config"" ,o=""webotxportal"" , c=""JP""","modrep","00=担当2","05=担当1","10=主任2","15=主任1","20=課長2","25=課長1","30=部長2","35=部長1","40=役員2","45=役員1","50=社長"

Caution
上記の例を流用する場合、1行が1エントリ単位になるように改行に注意してください。

EDSのedcsvコマンドを実行します。edcsvの詳細については、EDSのマニュアル「ユーティリティ利用の手引」を参照してください。

# edcsv -h localhost -p 389  -D "cn=ldapadministrator,c=JP" -W -f modtable.csv
以下のように表示されれば成功です。
 -----------------------
  エントリを編集しました。
  #2 DN:cn="Jobtable" ,ou="table" ,ou="config" ,o="webotxportal" , c="JP"
  'modtable.csv'

  success entry count: 1

設定後、WebOTXのドメインを再起動してください。再起動後に、職位テーブルの情報が反映されます。

Caution
職位コードは、00〜99の半角数字2桁で指定してください。必ず「コード=ラベル」という フォーマットで登録してください。

 

2.1.5. アクセス制御

ここでは、ユーザリソースのアクセス制御について説明します。

Caution
アクセス制御には、カスタマイズ可能な部分もありますが、意図しない情報が参照される可能性があるため、十分ご注意いただく必要があります。

ディレクトリに対するアクセス制御は、それぞれアクセス制御を行いたいエントリに付与します。 付与するアクセス制御情報(Access Control Information: ACI) には以下の3 種類があります。

それぞれについて、以下を設定できます。

ユーザリソースでは、エントリを含む配下全体に対するアクセス制御情報を主に利用しています。

デフォルトとして設定するACIについて記述します。

EDSにログインするユーザは、"一般ユーザ"、"ポータルシステム管理者"、"ldapadministrator"、"代表ユーザ"に分かれます。 ユーザリソースの個人エントリに含まれているユーザは一般利用者です。 ポータルシステム管理者は、ロール"OTXPORTAL_ADMIN"を割り当てられた個人であり、各エントリを参照でき、かつ更新することもできます。
EDSの管理者であるldapadministratorも各エントリを参照でき、かつ更新することもできます。
WebOTX Portal内部で使用する代表ユーザは、各エントリを参照できますが、更新することはできせん。

表2.1.5-1
  個人エントリ グループ/組織エントリ ロールエントリ
一般利用者 参照可・更新不可 参照可・更新不可 参照可・更新不可
ポータルシステム管理者 参照可・更新可 参照可・更新可 参照可・更新可
ldapadministrator 参照可・更新可 参照可・更新可 参照可・更新可
WebOTX Portal代表ユーザ 参照可・更新不可 参照可・更新不可 参照可・更新不可

個人エントリに含まれる属性のアクセス制御は、上記の個人エントリに従いますが、userpassword,portalpersonalization,aplogincontextについては、固有のアクセス制御を行います。

表2.1.5-2
  userpassword属性 portalpersonalization属性 aplogincontext属性
一般利用者 参照不可・更新不可 参照可・更新不可 参照不可・更新不可
(その個人エントリの所有者) 参照不可・更新可 参照可・更新不可 参照可・更新不可
ポータルシステム管理者 参照不可・更新可 参照可・更新可 参照可・更新可
ldapadministrator 参照不可・更新可 参照可・更新可 参照不可・更新不可
WebOTX Portal代表ユーザ 参照不可・更新不可 参照可・更新不可 参照不可・更新不可

一般利用者は、userpassword,aplogincontextを参照も更新もできません。portalpersonalizationは参照できますが、更新できません。
ただし、その個人エントリの所有者は、userpasswordの更新とaplogincontextの参照が可能です。
ポータルシステム管理者は、userpasswordを参照できませんが、更新は可能です。portalpersonalization、aplogincontextは参照も更新も可能です。
EDSの管理者であるldapadministratorは、userpasswordを参照できませんが、更新は可能です。portalpersonalizationは、参照も更新も可能です。aplogincontextは、参照も更新もできません。
WebOTX Portal内部で使用する代表ユーザは、userpassword,aplogincontextを参照も更新もできません。portalpersonalizationは参照できますが、更新できません。

2.1.6. レプリケーション設定

ここでは、ディレクトリサーバの構成変更により発生するレプリケーションの設定について説明します。

2.1.6.1. スレーブサーバの追加

スレーブサーバを追加するための手順について説明します。

手順概要

設定開始前の注意事項

EDSDBのコピー

以下の手順で、マスタサーバのEDSDB をスレーブサーバにコピーします。

  1. マスタサーバの以下のサービスを停止します。
    - EDS Replica

  2. 以下の手順で、マスタサーバのEDSDB を退避します。
    EDSDB バックアップ手順
    1. EDS 運用管理ツールにログインします。
    2. 「サーバ管理」 > 「データベース」 > 「DB 退避」
    3. 「退避フォルダ名」を指定して[OK]を押下します。
      「退避フォルダ名」に指定したフォルダ配下にEDSDB フォルダ配下のファイルがコピーされます。

  3. マスタサーバのchange.log ファイルをバックアップし、ファイルを空にします。
    デフォルトでは、以下のパスにあるログになります。

    {EDSインストール先}\EDS\LOG\Change.log

    EDS のサービス起動中はChange.log ファイルはロックされています。
    ファイルを空にするには、Change.log ファイルを開いて内容を削除し、Change.log ファイルを上書きで保存します。
    注意: この手順を行わないと、作業後にchange.log の内容が新規で追加したスレーブにレプリケーションされてしまいます。必ず実行してください。

  4. 追加するスレーブサーバの以下のサービスを停止します。

    - EDS Manager
    - EDS Protocol Server

  5. スレーブサーバのインストール先にEDSDB フォルダが存在していた場合は、EDSDBフォルダをリネームし、コピーしたマスタサーバのEDSDBに置換します。上書きではなく、必ず置換してください。
    EDSDB はデフォルトで以下のパスに存在します。

    {EDSインストール先}\EDSDB

    EDSDB のコピーは、すべてのスレーブサーバに実施してください。
    注意: EDSDB は上書きではなく、必ず置換してください。

  6. 停止した各サービスを起動します。
    すべてのスレーブサーバで、以下のサービスを起動してください。

    - EDS Manager
    - EDS Protocol Server

    ここでは、まだEDS Replica サービスの起動はしないでください。

マスタサーバでのレプリケーション設定

マスタサーバに対して、以下の手順でレプリケーション設定を実施してください。
シングルマスタ構成にのみ対応していますので、環境全体で1台のマスタサーバに対してのみ、実施してください。

  1. EDS 運用管理ツールを起動し、マスタサーバに対してldapAdministrator としてログインします。

  2. 「サーバ管理」 > 「レプリケーション」 > 「マスター設定」 を選択します。

  3. 更新差分ログ、ログファイル名に正しいパスが設定されていることを確認してください。 更新差分ログについては、参照しているパスに実際にログが出力されていることを確認してください。

  4. レプリケーション実行間隔を設定します。短すぎるとサーバ負荷があがってしまうため、10秒以上に設定することを推奨します。

  5. [追加]をクリックし、「マスター/スレーブの追加」の画面を表示します。

  6. 複製先設定
    「サーバ識別名」 : スレーブサーバの識別名を入力してください。

    「ホスト名」 : 問題なければ名前解決のオーバーヘッドを減らすためスレーブサーバのIPアドレスを指定してください。
    「ポート番号」 : スレーブサーバのポート番号を指定します。通常、389 になります。
    「サブツリー識別名」 :ツリー画面のサーバ名ノードの直下に表示されているノード [JP] を指定します。

  7. 接続設定
    「認証レベル」 : [ 保護つき簡易認証 ]を指定してください。
    「ユーザ名」 : ディレクトリ管理者(ldapAdministrator)のDN を指定します。
    cn=ldapAdministrator,c=JP
    「パスワード」 :ディレクトリ管理者(ldapAdministrator)のパスワードを指定します。
    「SSL通信設定」 :通常設定の必要はありません。

  8. 設定内容に問題がなければ [OK] をクリック、「 マスター/スレーブの追加 」 の画面を閉じます。 一覧にスレーブサーバが追加されていることを確認してください。すべてのスレーブサーバについて、設定を繰り返します。

  9. [パスワードポリシー情報を一元化する] のチェックボックスにチェックをつけます。

  10. [送信][適用]を順にクリックします。

  11. パスワードをレプリケーション実行間隔をまたずに、優先してレプリケーションを行いたい場合は、以下の設定をおこないます。
    1. 「サーバ管理」 > 「[レプリケーション」 を選択し、「優先属性型設定」画面を表示します。
    2. 属性型一覧から、以下の属性を選択し、[←追加]をクリックして、優先属性に追加します。
    3. [送信][適用]の順にクリックします。

スレーブサーバでのレプリケーション設定

スレーブサーバに対して、以下の手順でレプリケーション設定を実施してください。 スレーブサーバが複数台ある場合は、すべてのスレーブサーバに対して設定してください。

  1. EDS 運用管理ツールを起動し、スレーブサーバに対してldapAdministrator としてログインします。

  2. 「サーバ管理」 > 「レプリケーション」 > 「スレーブ設定」 を選択します。

  3. 「パスワードポリシー情報を一元化する」 のチェックボックスにチェックをつけます。

  4. 「サブツリー識別名」には[参照]を押して表示されたツリー画面のサーバ名ノードの直下に表示されているノード"JP"を選択します。

  5. マスター情報設定
    「 サーバ名 」 : 問題なければマスタサーバのIP アドレスを指定してください。
    「 ポート番号 」: マスタサーバのポート番号を指定します。通常、389 になります。
    設定内容を確認して、[追加]をクリックします。

  6. [送信]、[適用]、[閉じる]を、順にクリックします。

サービス起動

マスタサーバでレプリケーションサービスを起動します。以下の手順でサービスを起動してください。

  1. 先の「EDSDB のコピー」の手順で、マスタサーバの更新差分ログ(Change.log)の内容を空にしていることを確認します。
    レプリケーション設定の作業中に発生した更新内容が、更新差分ログ(Change.log)に出 力されるため、Change.log ファイルが新たに作成されています。レプリケーション設定の 作業開始前の記録が残っていないことを確認してください。
    「EDSDB のコピー」の手順で、ファイルを空にしていなかった場合は、ここでレプリケー ション設定の作業開始前の記録を削除してください。ファイルの内容を削除する前に、必 ずChange.log のバックアップを取ってください。
    EDS のサービス起動中はChange.log ファイルはロックされています。ファイルの内容を 削除するには、Change.log ファイルを開いて内容を変更し、Change.log ファイルを上書 きで保存します。

  2. マスタサーバのレプリケーションサービスに自動起動の設定を実施します。(すでに設定 済みの場合は、本作業をもう一度実施する必要はありません。)
  3. マスタサーバで以下のレプリケーションサービスを開始します。 EDS Replica
    注意: スレーブサーバでは、絶対にレプリケーションサービスを起動しないでください。スレーブサーバ側では、 EDS Replica サービスを [無効] に設定することを推奨します。

以上で、レプリケーション設定は終了です。
「WebOTX Portalのディレクトリサーバ設定の変更」の手順を参照し、WebOTX Portalのディレクトリサーバの設定を変更してください。

動作確認

Caution
このレプリケーションの設定情報は、EDSDB の中に記録されていることに注意してください。設定した後でEDSDB をスレーブにコピーすると、マスタサーバ設定もコピーされることになります。
その場合、「スレーブサーバでのレプリケーション設定」にある手順を再設定する必要があります。

2.1.6.2. スレーブサーバの削除

運用中のスレーブサーバを構成から削除するための手順について説明します。

手順概要

設定開始前の注意事項

マスタサーバでの設定

マスタサーバに対して、以下の手順で設定を実施してください。
シングルマスタ構成にのみ対応していますので、環境全体で1台のマスタサーバに対してのみ、
実施してください。

  1. マスタサーバの以下のサービスを停止します。
    EDS Replica

  2. EDS 運用管理ツールを起動し、マスタサーバに対してldapAdministrator としてログインします。
  3. 「サーバ管理」 > 「レプリケーション」 > 「マスター設定」 を選択します。
  4. 複製先設定の一覧で、構成から削除するスレーブサーバを選択し、[削除]をクリックします。
  5. [送信][適用]を順にクリックします。

スレーブサーバでの設定

構成から削除するスレーブサーバに対して、以下の手順で設定を実施してください。スレーブサーバをアンインストールする場合は、本設定は必要ありません。

  1. EDS 運用管理ツールを起動し、構成から削除するスレーブサーバに対してldapAdministrator としてログインします。
  2. 「サーバ管理」 > 「レプリケーション」 > 「スレーブ設定」 を選択します。
  3. 「パスワードポリシー情報を一元化する」のチェックを外します。
  4. マスター情報設定の一覧で、マスタサーバを選択し、[削除]をクリックします。
  5. [送信][適用]を順にクリックします。
  6. スレーブサーバの以下のサービスを停止します。
    EDS Manager
    EDS Protocol Server

サービスの起動と設定の確認

本手順で削除したスレーブサーバ以外に、構成内にスレーブサーバが残っている場合は、マスタサーバでレプリケーションサービスを起動します。以下の手順でサービスを起動してくださ い。

  1. マスタサーバで以下のレプリケーションサービスを開始します。

    EDS Replica

本手順でスレーブサーバを削除したことにより、構成内のディレクトリサーバがマスタサーバ1台のみとなった場合は、マスタサーバのレプリケーションサービスは停止したままとし、起動しないでください。以下の手順で、マスタサーバのレプリケーションサービスが自動起動しないこ とを確認してください。

  1. マスタサービスのサービス一覧で、EDS Replica サービスのプロパティを表示します。
  2. 全般タブのスタートアップの種類で、[ 手動 ]を選択します。すでに [ 手動] が選択されてい た場合は、変更しません。
  3. 回復タブの最初のエラーで、「何もしない」を選択します。すでに「何もしない」が選択されていた場合は、変更しません。
  4. [OK]でプロパティ画面を終了します。

以上で、設定は終了です。
[2.1.6.3. WebOTX Portalのディレクトリサーバ設定の変更]の手順を参照し、WebOTX Portalのディレクトリサーバの設定を変更してください。

動作確認

2.1.6.3. WebOTX Portalのディレクトリサーバ設定の変更

ディレクトリサーバの構成を変更した場合は、WebOTX Portalから接続するディレクトリサーバの設定を変更する必要があります。

EDSをマスタ−スレーブ構成とした場合、マスタサーバのIPアドレスとポート番号をotxadminコマンドで設定します。

otxadmin> set server.portal.directory-server.masterservername=EDSマスタサーバのIPアドレス
otxadmin> set server.portal.directory-server.masterserverport=EDSマスタサーバのポート番号

WebOTX Portalからユーザリソースの検索に使用するEDSのマスタサーバまたはスレーブサーバのIPアドレスとポート番号をotxadminコマンドで設定します。

otxadmin> set server.portal.directory-server.servername=EDSサーバのIPアドレス
otxadmin> set server.portal.directory-server.serverport=EDSサーバのポート番号

設定後、WebOTX Portalのドメインを再起動してください。

2.1.7. その他の運用支援

ここでは、その他の運用支援について説明します。

2.1.7.1. EDSの諸元

ここでは、EDSの諸元について説明します。

表2.1.7.1-1
DN の最大長 4096 バイト
OID の最大長 64 バイト
RDN 属性値の最大長 256 バイト
検索対象になる属性値の最大長 1015 バイト
付加可能な補助型クラスの数 64
オブジェクトクラス名の最大長 128 バイト
属性型名の最大長 128 バイト
クラス定義中の属性の最大数 256
データベース名の最大長 16バイト
エントリの最大数 10億
オプションの数 64
パスワードの最大長 128バイト
マルチサーバ名の最大長 12バイト
フィルタ中に指定する属性値の最大長 1024バイト

2.1.7.2. WebOTX Portalの諸元

ここでは、WebOTX Portalの諸元について説明します。

表2.1.7.2-1
最上位のグループ/組織の最大数 100
1階層のグループ/組織の最大数 20
グループ/組織の階層の最大数 29
1個人当り兼務の最大数 10
総ユーザ数 100,000
総グループ数 10,000
総ロール数 100
職位コードの範囲 00-99

2.1.7.3. サンプルデータ

ここでは、<WebOTX インストール先>\Portal\directoryserver\insertsampledata.batを実行することでEDSに登録されるsampledata.ldifについて説明します。 このデータを登録するとユーザID"00000"、パスワード"pwd00000"でWebOTX Portalにログインできるようになります。

表2.1.7.3-1
個人 DN: uid="00000" ,ou="people" ,o="webotxportal" , c="JP"
ユーザID: 00000
パスワード: pwd00000
姓(ロケール無し): Userid00000
姓(日本語ロケール): 名字00000
姓(英語ロケール): Family00000
名(ロケール無し): Given00000
名(日本語ロケール): 名前00000
名(英語ロケール): given00000
ミドル名(ロケール無し): middlename00000
ミドル名(日本語ロケール): ミドルネーム00000
ミドル名(英語ロケール): middle00000
所有ロール: OTXPORTAL_ADMIN
本務所属部門: BU1
管理している部門: BU1
職位コード: 1 (主任)
DN: extJobNumber="1" ,uid="00000" ,ou="people" ,o="webotxportal" , c="JP"
兼務所属部門: JH1-BU1
兼務先での職位コード: 1 (主任)
グループ/組織 DN: groupid="BU1" ,ou="group" ,o="webotxportal" , c="JP"
グループID: BU1
グループ名(ロケール無し): GroupBU1
グループ名(日本語ロケール): テストグループBU1
グループ名(英語ロケール): TestGroupBU1
所有ロール: ROLE00000
DN: groupid="JH1-BU1" ,groupid="BU1" ,ou="group" ,o="webotxportal" , c="JP"
グループID: JH1-BU1
グループ名(ロケール無し): GroupJH1-BU1
グループ名(日本語ロケール): テストグループJH1-BU1
グループ名(英語ロケール): TestGroupJH1-BU1
所有ロール: ROLE00000
ロール DN: roleid="ROLE00000" ,ou="role" ,o="webotxportal" , c="JP"
ロールID: ROLE00000
ロール名(ロケール無し): ROLE00000
ロール名(日本語ロケール): テストロールROLE00000
ロール名(英語ロケール): RoleROLE00000
職位テーブル DN: cn="Jobtable" ,ou="table" ,ou="config" ,o="webotxportal" , c="JP"
職位コードとラベル:
日本語ロケール
 00=担当
 01=主任
 02=課長
 03=部長
 04=社長
英語ロケール、ロケール無し
 00=Staff
 01=Assistant Manager
 02=Manager
 03=Group Manager
 04=President

2.1.7.4. EDSへのデータ転記

ここでは、WebOTX Portalが使用するEDSに対して、他のディレクトリサーバからデータを転記する場合の手順について説明します。

Active Directoryからのデータ転記

Active DirectoryからEDSへデータを転記する方法を説明します。

対象プラットフォーム

対象となるActive Directoryは以下のOSになります。

転記対象データ

Active Directoryからのデータ転記には、EDSのオプション機能である「AD Sync-R」オプションを使用します。
「AD Sync-R」オプションを使用して転記できるデータは、以下の通りです。

表2.1.7.4-1
転記対象 説明 転記可否
ツリー構造(ディレクトリ情報) Active DirectoryもEDSも「LDAP(Lightweight Directory Access Protocol)」準拠のディレクトリ・サービスなので、ディレクトリ情報を転記することができます。
ただし、Active Directoryで扱っていた「セキュリティグループ」や「配布グループ」についてはEDSでは使用できないため、転記することができません。
ユーザアカウント WebOTX Portalでは、Active Directoryのユーザ情報を対応する属性(項目)において、転記して使用することができます。
ユーザパスワード ユーザパスワードは、WebOTX Portalにログイン時の認証などに使用します。Active Directoryに登録しているパスワードと同じものをEDS上に転記することは可能です。
ただし、「AD Sync-R」オプションでは転記することはできず、「AD Sync-W」オプションを使用することで転記可能です。
グループポリシー グループポリシーとは、ユーザー環境やシステム設定を制御する機能です。たとえば、特定のプログラムが使用されないようスタートメニューに非表示にしたり、パスワードの有効期限を設定したりするなど、さまざまな制御設定が可能です。
ですが、EDSにはそのような制御機能は持っていないため、転記することはできません。
×
ユーザプロファイル ユーザプロファイルは、OSが使用する情報であり、WebOTX Portalでは使用しないため、転記の必要はありません。 ×
アクセス制御 Active Directoryのアクセス制御の設定をWebOTX Portalでは使用できません。アクセス制御の設定については、[ 2.1.ユーザリソース > 2.1.5.アクセス制御 ]を参照してください。 ×
転記手順

Active DirectoryのデータをEDSに転記するための手順について説明します。

  1. 「AD Sync-R」オプションをインストールします。
    インストール方法は「AD Sync-R」オプションのセットアップカードを参照ください。インストール先については特に指定はありません。

  2. 「AD Sync-R」オプションを使用してActive Directoryのユーザと組織エントリをEDSに転記する準備を行います。
    詳細な転記方法についてはEDSのマニュアル「オプション機能説明書」を参照ください。

    1. データ連携用スキーマをEDSに登録します。
    2. 環境設定ファイルを編集します。
    3. 必要に応じて、環境設定ファイルを暗号化します。
    4. ルールファイルを編集します。

  3. EDSのデータ連携コマンドのedsyncadを使用してActive DirectoryのデータをEDSに転記します。
    edsyncadは、ルールファイルを使用して、Active Directoryのどのエントリのどの属性をEDSのどのエントリのどの属性に転記するかを指定します。

    注意:「AD Sync-R」オプションを実行する前に、WebOTX Portalで使用するスキーマをEDSへ登録しておく必要があります。
    詳しくは、[ セットアップガイド > 3. インストール > 3.3. インストール後の作業 > 3.3.1. Windows > 3.3.1.1. EDS へ初期ユーザデータの投入 ]を参照してください。

  4. ユーザと所属グループの関係を設定します。
    WebOTX Portalにおけるユーザと所属グループの関係は転記できません。EDS運用管理ツールなどを用いて、各個人エントリの所属グループID(mainBelongGroup)にグループ/組織エントリのグループID(groupid)を記載してください。

  5. ユーザと所属ロールの関係を設定します。
    WebOTX Portalにおけるユーザと所属ロールの関係は転記できません。EDS運用管理ツールなどを用いて、各個人エントリの所有ロールID(assignedRole)にロールエントリのロールID(roleid)を記載してください。

  6. グループと所属ロールの関係を設定します。
    WebOTX Portalにおけるグループと所属ロールの関係は転記できません。EDS運用管理ツールなどを用いて、各グループ/組織エントリの所有ロールID(assignedRole)にロールエントリのロールID(roleid)を記載してください。

  7. Active Directoryから転記できない属性を補完します。
    EDS運用管理ツールなどを用いて、個別に登録してください。

個人エントリを転記する場合

個人エントリを転記する場合に編集するルールファイルの内容を説明します。


図2.1.7.4-1

図2.1.7.4-1のようなツリー構造の場合、表2.1.7.4-2に個人エントリを転記するため必要なマッピング設定項目を説明します。
マッピングするために必要な項目は6種類あります。転記対象を指定するDNFilter 、ObjectClassFilter 、AttributeTypeFilter 、マッピング対象を指定するDNMapping 、ObjectClassMapping、AttributeTypeMappingを決定する必要があります。

表2.1.7.4-2
ルールタイプ マッピング対象 説明
フィルタ設定    
DN サフィックス OU=group1,DC=nec,DC=co,DC=jp
CN=Users,DC=nec,DC=co,DC=jp
転記対象とするサブツリーの基底のDNを指定します。
本例では、group1配下とUsers配下の個人エントリを転記する場合の指定方法です。
オブジェクトクラス user 転記対象とするオブジェクトクラスを指定します。
個人エントリを転記する場合は、user固定で問題ありません。
属性型 cn 転記対象とする属性の型を指定します。
本例では、Active Directoryの個人エントリの属性CN、名前、アカウント名、電子メール、部署を指定しています。
givenName
sAMAccountName
mail
department
マッピング設定 Active Directoryのエントリ WebOTXで使用するEDSのエントリ  
DN DN サフィックス OU=group1,DC=nec,DC=co,DC=jp
CN=Users,DC=nec,DC=co,DC=jp
ou=people,o=webotxportal,c=JP
ou=people,o=webotxportal,c=JP
EDS側のサブツリーの基底のDNを指定し、転記先で変更する基底のDNを指定します。
本例では、people配下に転記する場合の指定方法です。
属性 cn uid EDS側のDNを構成する属性の型を指定し、転記先で変更する属性の型を指定します。
個人エントリのRDNがcnからuidに変更になるため、属性のマッピング指定を行います。
オブジェクトクラス user top,person,organizationalPerson, inetOrgPerson,otxUser, so21PersonExtendSO EDS側のオブジェクトクラスを指定し、転記先で変更するオブジェクトクラスを指定します。
オブジェクトクラスのマッピング指定は固定で構いません。
属性型 cn uid,cn EDS側の属性型を指定し、転記先で変更する属性型を指定します。
フィルタの属性に記載したが、ここでマッピングの指定をしない属性については、そのままの属性で転記されます。
sAMAccountName sn
department mainBelongGroup

Memo
Active Directoryのユーザが持っている属性一覧については、ADSIEditやスキーマ参照ツールを使用して確認することができます。

続いて、マッピング例に従って、マッピング情報を定義したルールファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<MappingRules RDNCompletion="ON">
    <DNFilter Action="include">
        <DN SuffixName="OU=group1,DC=nec,DC=co,DC=jp" />
        <DN SuffixName="CN=Users,DC=nec,DC=co,DC=jp" />
    </DNFilter>
    <ObjectClassFilter Action="include">
        <ObjectClass Name="user" />
    </ObjectClassFilter>
    <AttributeTypeFilter Action="include">
        <AttributeType Name="cn" />
        <AttributeType Name="givenName" />
        <AttributeType Name="sAMAccountName" />
        <AttributeType Name="mail" />
        <AttributeType Name="department" />
    </AttributeTypeFilter>
    <DNMapping>
        <DN SuffixName="OU=group1,DC=nec,DC=co,DC=jp" MappingTo="ou=people,o=webotxportal,c=JP" />
        <DN SuffixName="CN=Users,DC=nec,DC=co,DC=jp" MappingTo="ou=people,o=webotxportal,c=JP" />
        <AttributeType Name="cn" MappingTo="uid" />
    </DNMapping>
    <ObjectClassMapping>
        <ObjectClass Name="user" MappingTo="top,person,organizationalPerson,
                                              inetOrgPerson,otxUser,so21PersonExtendSO" />
    </ObjectClassMapping>
    <AttributeTypeMapping>
        <AttributeType Name="cn" MappingTo="uid,cn" />
        <AttributeType Name="sAMAccountName" MappingTo="sn" />
        <AttributeType Name="department" MappingTo="positionid" />
    </AttributeTypeMapping>
</MappingRules>

WebOTX Portalでは、これ以外にも個人エントリが使用する属性があります。それらについては、EDS運用管理ツールなどを利用して個別に登録する必要があります。
[ 2.1.ユーザリソース > 2.1.3.エントリの属性 > 2.1.3.1. 属性一覧 ]を参照して、不足している属性を必要に応じて登録してください。

グループ/組織エントリを転記する場合


図2.1.7.4-2

図2.1.7.4-2のようなツリー構造の場合、表2.1.7.4-3にグループ/組織エントリを転記するため必要なマッピング設定項目を説明します。
マッピングするために必要な項目は6種類あります。転記対象を指定するDNFilter 、ObjectClassFilter 、AttributeTypeFilter 、マッピング対象を指定するDNMapping 、ObjectClassMapping、AttributeTypeMappingを決定する必要があります。

表2.1.7.4-3
ルールタイプ マッピング対象 説明
フィルタ設定    
DN サフィックス OU=group1,DC=nec,DC=co,DC=jp
OU=group2,DC=nec,DC=co,DC=jp
OU=group3,DC=nec,DC=co,DC=jp
転記対象とするサブツリーの基底のDNを指定します。
本例では、group1、group2、group3を転記対象としています。
オブジェクトクラス organizationalUnit 転記対象とするオブジェクトクラスを指定します。
グループ/組織エントリを転記する場合は、organizationalUnit固定で問題ありません。
属性型 ou 転記対象とする属性の型を指定します。
本例では、Active Directoryの組織の属性OUを指定しています。
マッピング設定 Active Directoryのエントリ WebOTXで使用するEDSのエントリ  
DN DN サフィックス OU=group1,DC=nec,DC=co,DC=jp
OU=group2,DC=nec,DC=co,DC=jp
OU=group3,DC=nec,DC=co,DC=jp
groupid=group1,ou=group,o=webotxportal,c=JP
groupid=group2,ou=group,o=webotxportal,c=JP
groupid=group3,ou=group,o=webotxportal,c=JP
EDS側のサブツリーの基底のDNを指定し、転記先で変更する基底のDNを指定します。
本例では、group配下に転記する場合の指定方法です。
オブジェクトクラス organizationalUnit top,organizationalUnit,otxGroup EDS側のオブジェクトクラスを指定し、転記先で変更するオブジェクトクラスを指定します。
オブジェクトクラスのマッピング指定は固定で構いません。
属性型 ou groupid,ou EDS側の属性型を指定し、転記先で変更する属性型を指定します。

マッピング例に従って、マッピング情報を定義したルールファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<MappingRules RDNCompletion="ON">
    <DNFilter Action="include">
        <DN SuffixName="OU=group1,DC=nec,DC=co,DC=jp" />
        <DN SuffixName="OU=group2,DC=nec,DC=co,DC=jp" />
        <DN SuffixName="OU=group3,DC=nec,DC=co,DC=jp" />
    </DNFilter>
    <ObjectClassFilter Action="include">
        <ObjectClass Name="organizationalUnit" />
    </ObjectClassFilter>
    <AttributeTypeFilter Action="include">
        <AttributeType Name="ou" />
    </AttributeTypeFilter>
    <DNMapping>
        <DN SuffixName="OU=group1,DC=nec,DC=co,DC=jp" MappingTo="groupid=group1,ou=group,o=webotxportal,c=JP" />
        <DN SuffixName="OU=group2,DC=nec,DC=co,DC=jp" MappingTo="groupid=group2,ou=group,o=webotxportal,c=JP" />
        <DN SuffixName="OU=group3,DC=nec,DC=co,DC=jp" MappingTo="groupid=group3,ou=group,o=webotxportal,c=JP" />
    </DNMapping>
    <ObjectClassMapping>
        <ObjectClass Name="organizationalUnit" MappingTo="top,organizationalUnit,otxGroup" />
    </ObjectClassMapping>
    <AttributeTypeMapping>
        <AttributeType Name="ou" MappingTo="groupid,ou" />
    </AttributeTypeMapping>
</MappingRules>

WebOTX Portalでは、これ以外にもグループ/組織エントリが使用する属性があります。それらについては、EDS運用管理ツールなどを利用して個別に登録する必要があります。
[ 2.1.ユーザリソース > 2.1.3.エントリの属性 > 2.1.3.1. 属性一覧 ]を参照して、不足している属性を必要に応じて登録してください。

Caution
WebOTX Portalの認証サーバ連携機能では必要としませんが、単純にActive Directory上のアカウントとEDS上のアカウントの転記を取る場合には、パスワードの転記も必要となります。その場合、EDSのオプション機能である「AD Sync-W」オプションを使用することで、Active DirectoryからEDSへ転記が可能となります。
さらに、EDSのオプション機能である「AD Sync-F」オプションと組み合わせることで、Active DirectoryとEDSの間の双方向の同期が可能となります。

他の認証用EDSからの転記

WebSAM SECUREMASTER/EIMで使用しているEDSから転記する一例を説明します。

SECUREMASTER/EIMなどに含まれているEDSからデータを転記するには、EDSのオプション機能である「LDAP Sync」オプションを使用します。

SECUREMASTER/EIMで使用しているEDSからの転記できるものは、以下の通りです。

表2.1.7.4-4
リソース名 説明 転記可否
個人エントリ SECUREMASTER/EIMで登録しているユーザ情報を転記することができます。
グループ/組織エントリ SECUREMASTER/EIMで登録しているグループあるいは組織情報を転記することができます。
SECUREMASTER/EIMとWebOTX Portalの個人エントリと所属グループの関係は、共にユーザの属性が所持する構成であるため、個人エントリとグループ/組織エントリを転記することで、関係性は保持されます。
ロールエントリ SECUREMASTER/EIMで登録しているロール情報を転記することができます。
ただし、SECUREMASTER/EIMでは、ユーザと所属ロールの関係はロールエントリの属性が、WebOTX Portalでは、個人エントリが所持する構成であるため、個人エントリの属性に対して、所属ロールを設定しなおす必要があります。
サービスエントリ 認証連携で利用する情報は、SECUREMASTER/EIM上に存在しないので、転記する必要はありません。 ×
職位テーブルエントリ WebOTX Portal独自のエントリであるため、転記の必要はありません。 ×

LDAP Syncでは、ルールファイルを使用して、転記元のEDSのどのエントリのどの属性をWebOTX Portalが使用するEDSのどのエントリのどの属性にコピーするかを指定します。

個人エントリを転記する場合


図2.1.7.4-3

表2.1.7.4-5に個人エントリを転記するためのマッピングに必要な設定項目を示します。

表2.1.7.4-5
ルールタイプ マッピング対象 説明
フィルタ設定    
DN サフィックス ou=users,ou=edseidm,c=JP 転記対象とするサブツリーの基底のDNを指定します。
オブジェクトクラス eidmPerson 転記対象とするオブジェクトクラスを指定します。
属性型 uid 転記対象とする属性の型を指定します。
cn
givenName
eidmUnitCode
マッピング設定 SECUREMASTERで使用するEDSのエントリ WebOTXで使用するEDSのエントリ  
DN DN サフィックス ou=users,ou=edseidm,c=JP ou=people,o=webotxportal,c=JP EDS側のサブツリーの基底のDNを指定し、転記先で変更する基底のDNを指定します。
オブジェクトクラス eidmPerson person,organizationalPerson, inetOrgPerson,otxUser,so21PersonExtendSO EDS側のオブジェクトクラスを指定し、転記先で変更するオブジェクトクラスを指定します。
属性型 cn cn,sn EDS側の属性型を指定し、転記先で変更する属性型を指定します。
eidmUnitCode mainBelongGroup

マッピング例に従って、マッピング情報を定義したルールファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<MappingRules RDNCompletion="ON">
    <DNFilter Action="include">
        <DN SuffixName="ou=user,ou=edseidm,c=JP" />
    </DNFilter>
    <ObjectClassFilter Action="include">
        <ObjectClass Name="eidmPerson" />
    </ObjectClassFilter>
    <AttributeTypeFilter Action="include">
        <AttributeType Name="uid" />
        <AttributeType Name="cn" />
        <AttributeType Name="givenName" />
        <AttributeType Name="eidmUnitCode" />
    </AttributeTypeFilter>
    <DNMapping>
        <DN SuffixName="ou=user,ou=edseidm,c=JP" MappingTo="ou=people,o=webotxportal,c=JP" />
    </DNMapping>
    <ObjectClassMapping>
        <ObjectClass Name="eidmPerson" MappingTo="top,person,organizationalPerson,
                                              inetOrgPerson,otxUser,so21PersonExtendSO" />
    </ObjectClassMapping>
    <AttributeTypeMapping>
        <AttributeType Name="cn" MappingTo="cn,sn" />
        <AttributeType Name="eidmUnitCode" MappingTo="mainBelongGroup" />
    </AttributeTypeMapping>
</MappingRules>
グループ/組織エントリを転記する場合


図2.1.7.4-4

表2.1.7.4-6にグループ/組織エントリを転記するためのマッピングに必要な設定項目を示します。

表2.1.7.4-6
ルールタイプ マッピング対象 説明
フィルタ設定    
DN サフィックス ou=org,ou=data,ou=edseidm,c=JP 転記対象とするサブツリーの基底のDNを指定します。
オブジェクトクラス eidmOrganization 転記対象とするオブジェクトクラスを指定します。
属性型 eidmOrgCode 転記対象とする属性の型を指定します。
eidmOrgName
マッピング設定 SECUREMASTERで使用するEDSのエントリ WebOTXで使用するEDSのエントリ  
DN DN サフィックス ou=org,ou=data,ou=edseidm,c=JP ou=group,o=webotxportal,c=JP EDS側のサブツリーの基底のDNを指定し、転記先で変更する基底のDNを指定します。
属性 eidmOrgCode groupid EDS側のDNを構成する属性の型を指定し、転記先で変更する属性の型を指定します。
オブジェクトクラス eidmOrganization top,organizationalUnit,otxGroup EDS側のオブジェクトクラスを指定し、転記先で変更するオブジェクトクラスを指定します。
属性型 eidmOrgCode groupid EDS側の属性型を指定し、転記先で変更する属性型を指定します。
eidmOrgName ou

マッピング例に従って、マッピング情報を定義したルールファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<MappingRules RDNCompletion="ON">
    <DNFilter Action="include">
        <DN SuffixName="ou=org,ou=data,ou=edseidm,c=JP" />
    </DNFilter>
    <ObjectClassFilter Action="include">
        <ObjectClass Name="eidmOrganization" />
    </ObjectClassFilter>
    <AttributeTypeFilter Action="include">
        <AttributeType Name="eidmOrgCode" />
        <AttributeType Name="eidmOrgName" />
    </AttributeTypeFilter>
    <DNMapping>
        <DN SuffixName="ou=org,ou=data,ou=edseidm,c=JP" MappingTo="ou=people,o=webotxportal,c=JP" />
        <AttributeType Name="eidmOrgCode" MappingTo="groupid" />
    </DNMapping>
    <ObjectClassMapping>
        <ObjectClass Name="eidmOrganization" MappingTo="top,organizationalUnit,otxGroup" />
    </ObjectClassMapping>
    <AttributeTypeMapping>
        <AttributeType Name="eidmOrgCode" MappingTo="groupid" />
        <AttributeType Name="eidmOrgName" MappingTo="ou" />
    </AttributeTypeMapping>
</MappingRules>
ロールエントリを転記する場合


図2.1.7.4-5

表2.1.7.4-7にロールエントリを転記するためのマッピングに必要な設定項目を示します。

表2.1.7.4-7
ルールタイプ マッピング対象 説明
フィルタ設定    
DN サフィックス ou=role,ou=edseidm,c=JP 転記対象とするサブツリーの基底のDNを指定します。
オブジェクトクラス eidmRole 転記対象とするオブジェクトクラスを指定します。
属性型 cn 転記対象とする属性の型を指定します。
eidmRoleName
マッピング設定 SECUREMASTERで使用するEDSのエントリ WebOTXで使用するEDSのエントリ  
DN DN サフィックス ou=role,ou=edseidm,c=JP ou=role,o=webotxportal,c=JP EDS側のサブツリーの基底のDNを指定し、転記先で変更する基底のDNを指定します。
属性 cn roleid EDS側のDNを構成する属性の型を指定し、転記先で変更する属性の型を指定します。
オブジェクトクラス eidmRole top,organizationalRole,otxRole,otxExtRole EDS側のオブジェクトクラスを指定し、転記先で変更するオブジェクトクラスを指定します。
属性型 cn roleid EDS側の属性型を指定し、転記先で変更する属性型を指定します。
eidmRoleName cn

マッピング例に従って、マッピング情報を定義したルールファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<MappingRules RDNCompletion="ON">
    <DNFilter Action="include">
        <DN SuffixName="ou=role,ou=edseidm,c=JP" />
    </DNFilter>
    <ObjectClassFilter Action="include">
        <ObjectClass Name="eidmRole" />
    </ObjectClassFilter>
    <AttributeTypeFilter Action="include">
        <AttributeType Name="cn" />
        <AttributeType Name="eidmRoleName" />
    </AttributeTypeFilter>
    <DNMapping>
        <DN SuffixName="ou=role,ou=edseidm,c=JP" MappingTo="ou=role,o=webotxportal,c=JP" />
        <AttributeType Name="eidmOrgCode" MappingTo="groupid" />
    </DNMapping>
    <ObjectClassMapping>
        <ObjectClass Name="eidmRole" MappingTo="top,organizationalRole,otxRole,otxExtRole" />
    </ObjectClassMapping>
    <AttributeTypeMapping>
        <AttributeType Name="cn" MappingTo="roleid" />
        <AttributeType Name="eidmRoleName" MappingTo="cn" />
    </AttributeTypeMapping>
</MappingRules>

Memo
「LDAP Sync」オプションの詳細については、EDSのマニュアル「オプション機能説明書」を参照してください。

Caution
「LDAP Sync」オプションによる転記は差分転記です。そのため、転記元のEDSに既にエントリが存在する場合、転記先のWebOTX Portalが使用するEDSに予め転記対象のエントリを登録しておく必要があります。
エントリの登録方法については、次項の「その他のLDAPサーバからの転記」にある方法で実施してください。

その他のLDAPサーバからの転記

Active DirectoryやEDS以外のLDAPサーバからデータを転記する場合には、以下のように行います。

WebOTX PortalのEDSのスキーマに適合させるときには、以下の点に特に注意が必要です。

 

2.2. ユーザリソースのマルチテナント化

ここでは、WebOTX Portalの利用者情報を管理するユーザリソースのマルチテナント化について説明します。


図2.2-1

WebOTX Portal V8.4のユーザリソースはマルチテナントをサポートします。ユーザリソースの最上位DNは、シングルテナントの場合と同様に、"o=webotxportal,c=JP"です。その配下に、会社単位で会社エントリを作成します。
表2.2-1
  属性 オブジェクトクラス 属性名 必須属性 複数指定 諸元 ロケール指定 条件
会社エントリ 会社名 otxCompany cn   32768  

ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで (ANK、日本語混在不可)

会社ID otxCompany companyid   32  

32文字まで(英大文字・数字)

会社名 organization o   32768  

ロケール無しおよびlang-enの属性値:ANK:64文字まで
ロケールlang-jaの属性値:日本語:32文字まで (ANK、日本語混在不可)

会社エントリの配下に、シングルテナントの場合と同様に、ユーザ、グループ、ロール、コンフィグを作成します。ただし、"ou=config,o=webotxportal,c=JP"および"uid=portaluser,ou=config,o=webotxportal,c=JP"は、会社エントリの外に作成します。会社エントリのコンフィグには、職位テーブルのみを作成します。
各会社のロールエントリ配下に「roleid=OTXPORTAL_COMPANY_ADMIN」のエントリを作成することができます。そのロールを割り当てられたユーザは、会社管理者となります。会社管理者は、ポータルページエリアの「固定エリア」を編集することができます。 詳しくは、[ 3.11. 会社管理者サイトに対する操作 ]を参照してください。

Caution
会社ID(companyid)の文字数は、すべての会社で同じ数に設定してください。

 

2.3. ユーザリソースの任意スキーマ対応

ここでは、WebOTX Portal が接続するディレクトリサーバのスキーマ構成が [ 2.1.2. ユーザリソースの構成 ] に記載されているものと異なっている場合でも、そのディレクトリサーバを使用して WebOTX Portal を使用できるようにする方法について説明します。

2.3.1. 任意スキーマ機能の有効化

任意スキーマを有効化する方法について説明します。

  1. [ 6.1.4. ディレクトリサーバに関する設定 ] に記載された "WebOTX PortalユーザID" を、 接続先ディレクトリサーバに存在する WebOTX Portalユーザに相当するエントリの DN に設定してください。
    同様に "WebOTX Portalユーザパスワード" を、先のエントリのパスワードに設定してください。
  2. WebOTXドメイン(Advancedモードの場合はプロセルグループ)を停止してください。
  3. [ 6.2.13. 任意スキーマの設定 ] に記載された config.properties の com.nec.webotx.portal.directory.customSchema プロパティを true に設定してください。
    また、接続先ディレクトリサーバの認証方式が DIGEST-MD5 ではなく simple の場合は、 com.nec.webotx.portal.directory.authentication を simple に設定してください。
  4. [ 6.2.13. 任意スキーマの設定 ] に記載された CustomSchemaConfiguration.properties を作成してください。具体的な設定方法については、[ 2.3.2. 任意スキーマの設定方法 ] を参照してください。
  5. WebOTXドメイン(Advancedモードの場合はプロセルグループ)を起動してください。

2.3.2. 任意スキーマの設定方法

ここでは、接続先ディレクトリサーバのスキーマ構成に合わせて任意スキーマの設定を行う方法について説明します。

任意スキーマを設定するにあたって、[ 6.2.13. 任意スキーマの設定 ] に記載された CustomSchemaConfiguration.properties を作成する必要があります。CustomSchemaConfiguration.properties の設定項目は、大きく3つの種類に分かれています。

2.3.2.1. エントリの検索条件を定義する設定項目

この種類の設定項目に該当するプロパティ名を表 2.3.2.1-1 に示します。これらの設定項目をエントリの種類毎に分けて定義する必要があります。 エントリの種類は、プロパティ名の接頭辞(user, user.additional, office, role, positiontable, company)によって決定されます。

表 2.3.2.1-1
プロパティ名(接尾辞) 説明
*.baseDN エントリを検索するときの "検索ベースDN" を指定します。
*.scope エントリを検索するときの "検索スコープ" を指定します。指定可能なプロパティ値は以下の3種類です。
・base : 検索ベースDNのみを検索対象にします。
・one : 検索ベースDNの一つ下の階層のみを検索対象にします。
・sub : 検索ベースDNおよびその配下のエントリを検索対象にします
*.filter エントリを検索するときの "検索フィルタ" を指定します。
*.objectclass エントリのオブジェクトクラスを指定します。

ここで、図2.3.2.1-1 を例に、個人エントリとグループ/組織エントリの検索条件の設定を示します。


図2.3.2.1-1

user.baseDN = CN=Users,DC=portal,DC=local
user.scope = one
user.filter = (&(objectclass={user.objectclass})({user.id}=%s))
user.objectclass = exampleUser
user.id = cn

office.baseDN = CN=Groups,DC=portal,DC=local
office.scope = sub
office.filter = (&(objectclass={office.objectclass})({office.id}=%s))
office.objectclass = exampleGroup
office.id = cn

上記のように設定した場合、実際の動作時には { } で囲まれたプレースホルダが 表 2.3.2.1-2 のように展開されます。

表 2.3.2.1-2
プレースホルダ展開前 プレースホルダ展開後
{user.objectclass} exampleUser
{user.id} cn
{office.objectclass} exampleGroup
{office.id} cn

2.3.2.2. エントリの属性名を定義する設定項目

エントリの種類を示すプロパティ名の接頭辞(user, user.additional, office, role, positiontable, company)を持ち、 なおかつ baseDN, scope, filter, objectclass の接尾辞を持たないプロパティ名が、エントリの属性名を定義する設定項目に該当します。 これらのプロパティには、WebOTX Portal が動作するうえで参照しなければならない各エントリの属性の名前を定義します。 これにより、標準のスキーマ構成と異なる名前の属性であっても参照できるようになります。

2.3.2.3. あるエントリに関連する別のエントリを検索する条件を定義する設定項目

この種類の設定項目に該当するプロパティを表 2.3.2.3-1 に示します。 これらのプロパティは、"エントリの種類" と "検索の方向" の組み合わせ毎に定義する必要があります。 例えば、個人エントリを起点としてロールエントリを検索する場合、 Role.searching.dn.fromUser, Role.searching.scope.fromUser, Role.searching.filter.fromUser の項目に検索条件を指定します。 逆に、ロールエントリを起点として個人エントリを検索する場合、 User.searching.dn.fromRole, User.searching.scope.fromRole, User.searching.filter.fromRole の項目に検索条件を指定します。

表 2.3.2.3-1
プロパティ名 説明
*.searching.dn.from* あるエントリを起点として、そのエントリに関連する別のエントリを検索するときの "検索ベースDN" を指定します。
*.searching.scope.from* あるエントリを起点として、そのエントリに関連する別のエントリを検索するときの "検索スコープ" を指定します。指定可能なプロパティ値は、表2.3.2.1-1 の *.scope と同じです。
*.searching.filter.from* あるエントリを起点として、そのエントリに関連する別のエントリを検索するときの "検索フィルタ" を指定します。

検索条件の設定方法は、関連する2つのエントリがどのような方法で関連付けられているかによって決定されます。設定方法の例を以下に示します。

例1: エントリ同士を ID によって関連付ける場合

ここでは、2つのエントリが ID によって関連付けられている場合の設定方法を説明します。


図2.3.2.3-1

図2.3.2.3-1 に示した例では、 個人エントリとグループ/組織エントリが "グループ/組織エントリが持つ memberID 属性" によって関連付けられています。 memberID 属性には、個人エントリを一意に識別することのできる ID が格納されています。

グループ/組織エントリを起点として、関連のある個人エントリを検索するためには、 "全ての個人エントリ" を検索対象として、"検索起点のグループ/組織エントリが持つ memberID 属性と同じ ID を持っている" という条件を満たすような 個人エントリを検索するように条件を設定します。

逆に、個人エントリを起点として、関連のあるグループ/組織エントリを検索するためには、 "全てのグループ/組織エントリ" を検索対象として、"検索起点の個人エントリの ID と同じ memberID 属性を持っている" という条件を満たすような グループ/組織エントリを検索するように条件を設定します。

user.baseDN = CN=Users,DC=portal,DC=local
user.objectclass = exampleUser
user.id = cn

office.baseDN = CN=Groups,DC=portal,DC=local
office.objectclass = exampleGroup
office.ext.memberUser = memberID

# グループ起点でユーザを検索するための設定
User.searching.dn.fromGroup = {user.baseDN}
User.searching.scope.fromGroup = one
User.searching.filter.fromGroup = (&(objectclass={user.objectclass})({user.id}=[office.ext.memberUser]))

# ユーザ起点でグループを検索するための設定
Group.searching.dn.fromUser = {office.baseDN}
Group.searching.scope.fromUser = one
Group.searching.filter.fromUser = (&(objectclass={office.objectclass})({office.ext.memberUser}=[user.id]))

上記のように設定した場合、実際の動作時には { } および [ ] で囲まれたプレースホルダが 表 2.3.2.3-2 のように展開されます。

表 2.3.2.3-2
プレースホルダ展開前 プレースホルダ展開後
{user.baseDN} CN=Users,DC=portal,DC=local
{user.objectclass} exampleUser
{user.id} cn
[user.id] 検索起点となった個人エントリの cn 属性値
(例: U-001, U-002)
{office.baseDN} CN=Groups,DC=portal,DC=local
{office.objectclass} exampleGroup
{office.ext.memberUser} memberID
[office.ext.memberUser] 検索起点となったグループ/組織エントリの memberID 属性値
(例: U-001, U-002)
例2: エントリ同士を DN によって関連付ける場合

ここでは、2つのエントリが DN によって関連付けられている場合の設定方法について説明します。


図2.3.2.3-2

図2.3.2.3-2 に示した例では、 個人エントリとロールエントリが "ロールエントリが持つ assignedUserDN 属性" によって関連付けられています。 assignedUserDN 属性には、個人エントリを一意に識別することのできる DN が格納されています。

ロールエントリを起点として、関連のある個人エントリを検索するためには、 "検索起点のロールエントリが持つ assignedUserDN 属性値の DN" を検索対象とするように設定します。

逆に、個人エントリを起点として、関連のあるロールエントリを検索するためには、 "全てのロールエントリ" を検索対象として、"検索起点の個人エントリの DN と同じ assignedUserDN 属性を持っている" という条件を満たすような ロールエントリを検索するように条件を設定します。

user.objectclass = exampleUser

role.baseDN = CN=Roles,DC=portal,DC=local
role.objectclass = exampleRole
role.ext.assignedUser = assignedUserDN

# ロール起点でユーザを検索するための設定
User.searching.dn.fromRole = [role.ext.assignedUser]
User.searching.scope.fromRole = base
User.searching.filter.fromRole = (objectclass={user.objectclass})

# ユーザ起点でロールを検索するための設定
Role.searching.dn.fromUser = {role.baseDN}
Role.searching.scope.fromUser = one
Role.searching.filter.fromUser = (&(objectclass={role.objectclass})({role.ext.assignedUser}=[SelfDN]))

上記のように設定した場合、実際の動作時には { } および [ ] で囲まれたプレースホルダが 表 2.3.2.3-3 のように展開されます。

表 2.3.2.3-3
プレースホルダ展開前 プレースホルダ展開後
{user.objectclass} exampleUser
{role.baseDN} CN=Roles,DC=portal,DC=local
{role.objectclass} exampleRole
{role.ext.assignedUser} assignedUserDN
[role.ext.assignedUser] 検索起点となったロールエントリの assignedUserDN 属性値
(例: CN=U-001,CN=Users,DC=portal,DC=local)
[SelfDN] 検索起点となった個人エントリの DN
(例: CN=U-001,CN=Users,DC=portal,DC=local)
例3: エントリ同士がディレクトリツリー上で親子関係にある場合

ここでは、2つのエントリがディレクトリツリー上の親子関係によって関連付けられている場合の設定方法について説明します。


図2.3.2.3-3

図2.3.2.3-3 に示した例では、上位のグループ/組織エントリと下位のグループ/組織エントリがディレクトリツリー上で親子関係によって関連付けられています。

下位のグループ/組織エントリを起点として、上位のグループ/組織エントリを検索するためには、 "検索起点のエントリから見て上位階層のDN" を検索対象とするように設定します。

逆に、上位のグループ/組織エントリを起点として、下位のグループ/組織エントリを検索するためには、 "検索起点のエントリのDNから見て一つ下の階層" を検索対象とするように設定します。

office.objectclass = exampleGroup

# 下位グループ起点で上位グループを検索するための設定
SuperGroup.searching.dn.fromGroup = [UpperDN]
SuperGroup.searching.scope.fromGroup = base
SuperGroup.searching.filter.fromGroup = (objectclass={office.objectclass})

# 上位グループ起点で下位グループを検索するための設定
SubGroup.searching.dn.fromGroup = [SelfDN]
SubGroup.searching.scope.fromGroup = one
SubGroup.searching.filter.fromGroup = (objectclass={office.objectclass})

上記のように設定した場合、実際の動作時には { } および [ ] で囲まれたプレースホルダが 表 2.3.2.3-4 のように展開されます。

表 2.3.2.3-4
プレースホルダ展開前 プレースホルダ展開後
{office.objectclass} exampleGroup
[SelfDN] 検索起点となったグループ/組織エントリの DN
(例: CN=Sales の場合、CN=Sales,CN=Groups,DC=portal,DC=local)
[UpperDN] 検索起点となったグループ/組織エントリの一つ上の DN
(例: CN=1st-Sales の場合、CN=Sales,CN=Groups,DC=portal,DC=local)