FirstClassディレクトリサービスについて
ご利用の組織でLDAPサーバを使用してユーザ管理をしている場合は、FirstClassディレクトリサービスを利用すると、ディレクトリ情報の管理作業をFirstClassと分担させることができます。FirstClassディレクトリサービスはFirstClassのオプションのコンポーネントで、以下の作業を実行できます。
・FirstClassディレクトリを外部LDAPバージョン3のサーバ(LDAPサーバ)から管理する
・LDAPバージョン3が利用可能なクライアント(LDAPクライアント)を使用して、FirstClassのディレクトリ情報を体系的、階層的に表示(ツリー表示)する
・FirstClassにログインを試みるユーザをLDAPサーバで認証する
注意
このヘルプは、階層化や名前付けの規則などのLDAPに関する概念に精通していることを前提とします。精通していない場合は、LDAPに関する全般的な情報をインターネットで調査するか、所属する組織のLDAPサーバ管理者にご相談ください。いずれにしても、LDAPサーバ管理者との密接な連携のもとに、LDAPサーバとの連動が正しく行われるようにFirstClass環境を設定する必要があります。
FirstClassディレクトリサービスは、FirstClassサーバとLDAPサーバの間で機能するものです。FirstClassディレクトリサービスをインストールするマシンは、FirstClassサーバと同じマシンでも別のマシンでもかまいません。FirstClassディレクトリサービスでは、下図のように、FirstClassサーバにある情報とLDAPサーバにある情報を相互に複製できます。
複製は、FirstClassディレクトリサービスの実行モードに従って制御されます。実行モードには、LDAPモード、ユーザ複製モード、および認証のみモードがあります。
FirstClassディレクトサービスを実行しているマシンが停止すると、FirstClassディレクトリサービスは、マシンの再起動後に、中断した箇所から処理を再開します。
名前の重複の禁止
公開メールリストの名前は複製しないことをお勧めします。FirstClassディレクトリサービスは、公開メールリストをユーザごとに個別に扱います。これは、公開メールリストの保存場所がFirstClassのディレクトリではなく[Mail List]フォルダであるためです。名前が重複したメールリストを利用できるのは、FirstClassディレクトリサービスのスタンドアロンモードにおいて、一定の条件を満たした場合だけです。
ユーザ名は重複しても問題ありません。異なる複数の組織単位に同じユーザ名がある場合、各ユーザ名はLDAPツリー表示で異なる場所に表示されます。そのため、FirstClassの従来のディレクトリ表示より見分けやすくなります。FirstClassディレクトリサービスは、このツリー表示をユーザIDと名前で管理しているため、同じ組織単位に重複するユーザ名が存在していても問題はありません。
また、重複する組織単位名を同じLDAPツリーに表示させることもできます。例えば、ある企業にある2つの支店の両方に[管理者]組織単位を表示できます。
FirstClassディレクトリサービスを実行できるユーザ
FirstClassディレクトリサービスは、FirstClassの管理者だけ設定および実行できます。ただし、クラスタリングされている場合などは、副管理者も設定と実行が可能です。
管理者のデスクトップに、[Groups]、[Mail Lists]、および[Gateways]の各フォルダのエイリアスが置かれている必要があります。
対応するオブジェクト
FirstClassディレクトリサービスと連動して利用できるもの |
対応するサーバまたはコンテンツ |
LDAPバージョン3のサーバ |
Sun Microsystems社のiPlanet Directory Server |
|
Microsoft社のActive Directory |
|
OpenLDAP(SLAPD)ディレクトリサーバ |
|
Mac OS XのOpen Directory |
OpenTextコンテンツサーバ(認証のみ) |
LDAPバージョン3対応のクライアント |
FirstClassのディレクトリに登録されている以下の内容 |
レギュラーユーザ |
|
リモートユーザ |
|
リモート名 |
|
公開メールリスト |
|
組織単位(OU) |
LDAPデータ交換フォーマット(LDIF:LDAP Data Interchange Format)ファイル |
複製されるオブジェクトは以下の通りです。
LDAPオブジェクトクラス |
FirstClassのディレクトリエントリの種類 |
organizationalPerson |
レギュラーユーザとリモートユーザ |
person |
リモート名 |
organizationalUnit |
組織単位(FirstClassの[レベル6 課]組織単位) |
コンテナ |
組織単位(FirstClassの[レベル1 同盟]組織単位) |
groupOfNames |
公開メールリスト |
groupOfUniqueNames |
公開メールリスト |
posixGroup |
組織単位 |
複製される情報は以下の通りです。
LDAP属性 |
FirstClassのディレクトリエントリの情報 |
surname |
名前3 |
commonName |
名前1 名前2 名前3 |
givenName |
名前1 |
名前2 |
名前2 |
telephoneNumber |
電話 |
facsimileTelephoneNumber |
FAX |
postalAddress |
住所 |
userPassword |
パスワード |
organizationalUnitName |
グループ(組織単位)の名前 |
mail |
エイリアス |
userid |
ユーザID |
member |
メールリストのエントリ |
uniqueIdentifier |
クライアントID |
uniqueMember |
メールリストのエントリ |
associatedDomain |
グループ(組織単位)のドメイン名 |
memberUid |
ユーザID |
user-specified custom attribute |
ユーザ設定ID |
対応するLDAPコマンド
対応しているLDAPバージョン3のコマンドは以下の通りです。
・ADD
・DELETE
・MODIFY
・SEARCH
MODIFY DNコマンド
このコマンドは、ユーザ、コンタクト、および公開メールリスト(リーフノード)だけに対応します。このコマンドの利用対象は以下の通りです。
・汎用のLDAPのAPI(ASN.1でエンコードしたModify DNコマンド)。ただし、クライアント駆動型でLDAPバージョン3に対応した標準のMODIFY DNコマンドであること。
・LDIFファイルのインポートと、標準的のLDIFフォーマットでエンコードしたMODIFY DNコマンド。
・スキャン用複製エンジン(Active DirectoryおよびFirstClassディレクトリサービスの汎用LDAP複製エンジン)。
複製エンジンのスキャニングでは、MODIF DNコマンドの検出が、コリレータ属性を使用して行われます。
SEARCHコマンド
SEARCHフィルタには、以下の制限事項があります。
・以下のLDAP属性だけが検索可能です。
・commonName
・givenName
・mail
・surname
・userid
・modifyTimeStamp
・FirstClassディレクトリサービスが対応するオブジェクトクラスはすべて検索できます。
・要求するリターン属性は、FirstClassディレクトリサービスが対応する属性になります。
・APPROXIMATEフィルタとEXTENSIBLEフィルタには対応しません。
ディレクトリ階層
ご存知の通り、LDAPでは、ディレクトリエントリには厳密な階層構造が要求されます。FirstClassでは、ユーザグループに組織単位(OU)を割り当てることで、この階層化を実行できます。
LDAPモードでのFirstClassディレクトリサービスのご利用にあたっては、必ず以下の点をご確認ください。
・所属する組織の階層に合致するユーザグループを組織単位に割り当てている
組織単位が割り当てられていないグループだけに所属するディレクトリエントリは、FirstClassディレクトリのツリー表示のルート階層に配置されます。
・組織単位の各階層をグループに割り当てる際、論理性と一貫性が保たれるようにしている
FirstClassディレクトリサービスは、先に受け取った情報から順次ツリー表示を作成します。したがって、一貫性のない階層情報を持つエントリが後から発生しても、そのエントリは無視されます。
・ユーザまたは公開メールリストが所属するユーザグループを正しい階層順にし、最上層のグループを最初に作成している
ユーザグループに権限を設定する場合は、階層による制約が起こることに注意してください。FirstClassサーバ側では、グループが登録された順番にユーザ権限が適用されます。一方、FirstClassディレクトリサービス側では、ディレクトリのツリー表示順に権限が適用されます。この2つの違いによって、矛盾が起こる可能性があります。FirstClassディレクトリサービスの実行モードによっては、このような矛盾を回避できます。
階層の例
下の図は、ある会社の管理者グループの階層構造を表しています。
ある社員(深田理沙)が人事課で働いているとします。彼女が所属するユーザグループは、[ユーザ情報]フォームで次の順番に登録されています。
[All Users]グループ
[Regular Users]グループ
[人事部]グループ
[人事課]グループ
[人事部]グループには、[人事課]グループに割り当てる組織単位(OU)より上位の階層にある組織単位を割り当てます。[All Users]グループと[Regular Users]グループはFirstClassディレクトリサービスによって無視されるため、これらのグループに組織単位を割り当てる必要はありません。
FirstClassディレクトリのルートDN(ルート識別名)は、以下のように設定されます。
ou=Administration,o=Husky Planes,c=CA
その結果、深田理沙のDN(識別名)は以下のようになります
cn=深田理沙,ou=人事課,ou=人事部,ou=総務グループ,o=株式会社○○,c=JP
LDAPツリー表示
FirstClassディレクトリサービスをLDAPクライアントに接続すると、以下のようなツリーが表示されます。
FirstClassディレクトリサービスは、以下の分岐を作成します。
・Contacts
個人アドレス帳に登録されているすべてのメンバーを表示します。
・Subscription_Lists
すべてのメンバーリストを表示します。リストごとに、メンバーのDN(識別名)が一覧表示されます。
・Account_Lists
すべてのposixGroupを一覧表示します。これらのグループはメンバーリストとして複製されます。リストごとに、メンバーのユーザIDが一覧表示されます。
Account_Listsは、posixGroupの情報を取得するようにFirstClassディレクトリサービスを設定している場合にのみ表示されます。
各ユーザが確認できる内容
ログインするユーザ |
確認できる内容 |
管理者 |
すべて |
レギュラーユーザ |
ツリー全体。ただし、Account_Listsの内容は確認できません。 |
匿名ユーザ |
ツリー全体。ただし、一覧の内容およびユーザの詳細情報は確認できません。 |
|