WebOTX Manual V10.4 (第4版) 目次を表示

---

3. ユーザ管理

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

3.1. ユーザリソース

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

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

• 個人
• グループ/組織
• ロール
• コンフィグ

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

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

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

3.1.1. ディレクトリサーバ

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

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

• エントリ
  オブジェクトを表現するものです。例えば、会社、組織、社員といったものがエントリになります。 このエントリは複数の属性を持っています。
  
  
• 属性
  オブジェクトの一部分を表現するためのもので、属性ごとにその型が定義されています。"common name"など、ディレクトリサーバで標準的に提供されている属性の場合は、"Directory String"などの型が定義されており、その型のデータを属性値として格納することができます。また属性値には単一値しか格納できないものと、複数の値を格納できるも のがあります。
  
  
• ディレクトリ情報ツリー（DIT：Directory Information Tree）
  オブジェクトの階層関係を表現するものです。例えば、会社における組織や社員の階層関係を 表現することができます。WebOTX Portalで使用するDITの例を以下に示します。

ディレクトリサーバが使用する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を、個人・グループ/組織・ロール、サービスの管理以外の目的には利用できません。

3.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内部で使用するユーザアカウントおよび職位のテーブルが含まれます。 職位のテーブルを適宜変更してください。
   

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内部で使用するユーザアカウントと各個人が持つ職位のコードと名前を対応付けるテーブルのエントリを格納するためのエントリです。

3.1.2.1. 個人のエントリ

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

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

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

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

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

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

例では、最上位のグループ/組織として二つのエントリがあります。グループ/組織エントリの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とするエントリを登録します。

3.1.2.3. ロールのエントリ

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

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

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

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

3.1.3. エントリの属性

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

3.1.3.1. 属性一覧

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

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

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

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

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

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

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

3.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アプリケーションと認証連携することもできます。例えば、次のような場合が該当します。

• ポータルへのログイン時とは異なるユーザIDを利用して、認証連携する。
• ポータルへのログイン時とは異なるパスワードを利用して、認証連携する。

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

サービスID;名前=値

• サービスIDとセミコロン(';')に続けて、Webアプリケーションが認証時に必要とするパラメータ名とパラメータ値を、名前=値の形式で指定します。
• パラメータ名・パラメータ値には1バイト文字のみを指定してください。
• パラメータ名・パラメータ値に英数字以外の文字や日本語・特殊文字が含まれる場合は、パラメータ名・パラメータ値をURLエンコードしてください。たとえば、名前が"name1"で、データとして"abc,xyz"という文字列を指定したい場合、パラメータ値のカンマ',' （0x2c） をURLエンコードして、
  name1=abc%2Cxyz
  と書く必要があります。
• パラメータが複数ある場合には、1バイト文字のカンマ ',' （0x2c）で区切ります。
• 同一名称のパラメータを複数設定することはできません。
• パラメータ値として以下の文字列を指定した場合は、現在ポータルにログインしているユーザ情報に置換されます。
  
  <USERID> ログインユーザのユーザＩＤに置換
  <PASSWORD> ログインユーザのパスワードに置換
  <NEXTURL> 連携対象アプリケーション情報の登録時、serviceURLで指定した実行用ページのURLアドレスに置換
  

例を示します。

WebKeiri;txtuid=1122334455,txtpwd=password1

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

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

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

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

兼務の属性

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

3.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の権利は与えられません。

3.1.3.4. ロールの属性

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

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

3.1.3.5. 職位テーブルの属性

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

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

3.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は存在するオブジェクトを示しているか、属性名が間違っていないかなどを確認してください。

3.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

3.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
   

3.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

3.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桁で指定してください。必ず「コード=ラベル」という フォーマットで登録してください。

3.1.5. アクセス制御

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

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

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

• エントリそのものに対するアクセス制御情報
• エントリを含む配下全体に対するアクセス制御情報
• 直下のサブエントリに対するアクセス制御情報

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

• 誰に（どのエントリに対して）
• どの属性に対して
• どのような権利を（検索、参照、更新など）与えるか

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

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

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

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

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

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

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

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

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

手順概要

• 設定開始前の注意事項
  設定を開始する前に、注意事項の確認を実施します。
  
  
• EDSDB のコピー
  マスタサーバのEDSDB をすべてのスレーブサーバにコピーします。
  
  
• マスタサーバでのレプリケーション設定
  マスタサーバ一台でレプリケーション設定を実施します。
  
  
• スレーブサーバでのレプリケーション設定
  すべてのスレーブサーバでレプリケーション設定を実施します。
  
  
• サービスの起動
  レプリケーションサービスの起動を行います。
  
  
• 動作確認
  レプリケーション設定の動作確認を行います。
  

設定開始前の注意事項

• 設定可能な構成は、マスタサーバを一台、スレーブサーバを複数台とするシングルマスタ構成のみです。マスタサーバを複数台とするマルチマスタ構成には対応していません。
• レプリケーションの設定作業中に、更新操作は実施しないでください。
• 設定作業を実施する前に、ログを採取してください。
  
  {EDSインストール先}\LOG\配下のファイルすべて
  
  設定で問題が発生した場合に、調査で必要になる場合があります。
  必ずすべてのサーバ(マスタ、スレーブ)で採取してください。
• 設定作業を実施する前に、以下の手順ですべてのサーバ（マスタ、スレーブ）のEDSDBのバックアップをとっておいてください。
  
  EDSDB バックアップ手順
  
  1. EDS 運用管理ツールにログインします。
  2. 「サーバ管理」 > 「データベース」 > 「DB 退避」
  3. 「退避フォルダ名」を指定して[OK]を押下します。
     「退避フォルダ名」に指定したフォルダ配下にEDSDB フォルダ配下のファイルがコピーされます。

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. 属性型一覧から、以下の属性を選択し、[←追加]をクリックして、優先属性に追加します。
• userpassword
• aploginContext
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. マスタサーバのレプリケーションサービスに自動起動の設定を実施します。(すでに設定 済みの場合は、本作業をもう一度実施する必要はありません。)
• マスターサービスのサービス一覧で、EDS Replica サービスのプロパティを表示します。
• 全般タブのスタートアップの種類で、「自動」を選択します。
• 回復タブの最初のエラーで、 [サービスを再起動する] を選択し、サービスの再起動の欄に、[3(分後に行う)]を 設定します。
• [OK]でプロパティ画面を終了します。
  
  
3. マスタサーバで以下のレプリケーションサービスを開始します。 EDS Replica
   注意： スレーブサーバでは、絶対にレプリケーションサービスを起動しないでください。スレーブサーバ側では、 EDS Replica サービスを [無効] に設定することを推奨します。
   

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

動作確認

• レプリケーション設定の動作確認は、実際に更新を実施して、マスタサーバで更新を行った後、 スレーブサーバのChange.log のサイズが変わることを確認してください。
• レプリケーションに何らかの問題が発生した場合には、マスタサーバの{EDS インストール先}\LOG フォルダ配下のreplica.log に出力されます。replica.log にエラーが出力されていないことを確認してください。

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

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

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

手順概要

• 設定開始前の注意事項
  設定を開始する前に、注意事項の確認を実施します。
  
  
• マスタサーバでの設定
  マスタサーバでスレーブサーバの指定を削除します。
  
  
• スレーブサーバでの設定
  構成から削除するスレーブサーバで設定を実施します。
  
  
• サービスの起動と設定の確認
  レプリケーションサービスの起動(停止)を行います。
  
  
• 動作確認
  レプリケーション設定の動作確認を行います。

設定開始前の注意事項

• 以下の手順でマスタサーバを構成から削除することはできません。
  
  
• レプリケーションの設定作業中に、更新操作は実施しないでください。
  
  
• 構成から削除するEDS にアクセスするサービスが存在しないことを確認してください。各 サービスの設定については、それぞれのサービスの設定手順を確認してください。
  
  
• 設定作業を実施する前に、ログを採取しておいてください。
  
  {EDSインストール先}\LOG\配下のファイルすべて
  
  設定で問題が発生した場合に、調査で必要になる場合があります。
  必ずすべてのサーバ(マスタ、スレーブ)で採取してください。
  
  
• 設定作業を実施する前に、以下の手順ですべてのサーバ（マスタ、スレーブ）のEDSDBのバックアップをとっておいてください。
  EDSDB バックアップ手順
  
  1. EDS 運用管理ツールにログインします。
  2. 「サーバ管理」>「データベース」>「DB 退避」
  3. 「退避フォルダ名」を指定して[OK]を押下します。
     「退避フォルダ名」に指定したフォルダ配下にEDSDB フォルダ配下のファイルがコピーされます。

マスタサーバでの設定

マスタサーバに対して、以下の手順で設定を実施してください。
シングルマスタ構成にのみ対応していますので、環境全体で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のディレクトリサーバの設定を変更してください。

動作確認

• スレーブサーバの削除の手順により、構成に残ったディレクトリサーバの動作に問題がないことを確認します。構成に残ったディレクトリサーバがレプリケーション構成をとっている場合、動作確認として、実際に更新を実施して、マスタサーバで更新を行った後、スレー ブサーバのChange.log のサイズが変わることを確認してください。
• レプリケーションに何らかの問題が発生した場合には、マスタサーバの{EDS インストー ル先}\LOG フォルダ配下のreplica.log に出力されます。replica.log にエラーが出力されていないことを確認してください。

3.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のドメインを再起動してください。

3.1.7. その他の運用支援

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

3.1.7.1. EDSの諸元

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

3.1.7.2. WebOTX Portalの諸元

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

3.1.7.3. サンプルデータ

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

3.1.7.4. EDSへのデータ転記

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

Active Directoryからのデータ転記

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

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

• Windows Server 2016

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

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へ登録しておく必要があります。
   詳しくは、Windowsの場合は [インストールガイド(Windows版) > 3. インストール方法 > WebOTX Portalのインストール後の作業] の「EnterpriseDirectoryServerへ初期ユーザデータの投入」]を、Linuxの場合は [インストールガイド(Linux版) > 4. インストール > 4.3. インストール後の作業 > 4.3.6. 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-2に個人エントリを転記するため必要なマッピング設定項目を説明します。
マッピングするために必要な項目は6種類あります。転記対象を指定するDNFilter 、ObjectClassFilter 、AttributeTypeFilter 、マッピング対象を指定するDNMapping 、ObjectClassMapping、AttributeTypeMappingを決定する必要があります。

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-3にグループ/組織エントリを転記するため必要なマッピング設定項目を説明します。
マッピングするために必要な項目は6種類あります。転記対象を指定するDNFilter 、ObjectClassFilter 、AttributeTypeFilter 、マッピング対象を指定するDNMapping 、ObjectClassMapping、AttributeTypeMappingを決定する必要があります。

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

<?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からの転記できるものは、以下の通りです。

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

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

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

<?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-6にグループ/組織エントリを転記するためのマッピングに必要な設定項目を示します。

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

<?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-7にロールエントリを転記するためのマッピングに必要な設定項目を示します。

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

<?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サーバからデータを転記する場合には、以下のように行います。

• まずLDAPサーバのデータをLDIFやCSVなどで出力します。
• つぎに内容をWebOTX Portalのスキーマに適合するように変換します。この変換方法は、LDAPサーバのスキーマに合わせて自製する必要があります。
• 変換したLDIFやCSVをEDSのedmodifyコマンド等で投入します。

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

• オブジェクトクラスの違い
• 属性の違い
• データ長の違い
• データ形式の違い
  文字列か数値かなど
• 階層構造の違い
  エントリが階層構造になっているか、上位エントリ直下にすべて配置されるフラットな構造になっているか
• 日本語を使用している場合には、文字コードの違い

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

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

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

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

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

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

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

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

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

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

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

• エントリの検索条件を定義する設定項目
• エントリの属性名を定義する設定項目
• あるエントリに関連する別のエントリを検索する条件を定義する設定項目

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

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

ここで、図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 のように展開されます。

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

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

3.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つのエントリがどのような方法で関連付けられているかによって決定されます。設定方法の例を以下に示します。

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

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

図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: エントリ同士を DN によって関連付ける場合

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

図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 のように展開されます。

例3: エントリ同士がディレクトリツリー上で親子関係にある場合

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

図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 のように展開されます。