Java Desktop System Configuration Manager, Release 1.1 インストールガイド

第 2 章 LDAP サーバー

この章では、Configuration Manager で使用するために LDAP サーバーを設定および配備する方法について説明します。

概念

Java Desktop System Configuration Manager フレームワーク内では、設定データはエンティティに関連付けられています。このエンティティとは、LDAP リポジトリ内のエントリのことであり、会社の組織構造の各要素に対応します。

認識されるエンティティは次のとおりです。

組織: 一般的には、階層全体の組織的 (部門、グループ、チーム) または地理的 (大陸、国、サイト) な単位を表します。
ユーザー: 階層全体のリーフノードを表します。その名前が示すように、通常はユーザーに対応します。
ドメイン: ネットワーク組織の論理編成単位を表します。
ホスト: 階層全体のリーフノードを表しますが、ネットワーク上のマシンも参照します。
役割: プロパティを表します。通常は、ユーザーの集合に適用される職務 (管理者、サイト管理) により区別されます。

組織とユーザーのエンティティがユーザーツリーを指定するのに対し、ドメインとホストのエンティティはホストツリーを指定します。この 2 つのツリーは独立していますが、フレームワーク内では同様の方法で操作されます。

組織およびドメインのエンティティとほかのエンティティの関係は、リポジトリ内におけるエントリの物理的な位置によって指定されます。つまり、組織およびドメインのエンティティには、ツリー内でこれら 2 つのエンティティの下に位置する任意のエントリを含めることができます。ユーザーまたはホストとその役割の関係は、ユーザーおよびホストのエントリの属性によって指定されます。

エンティティに関連付けられた設定データは、フレームワークによって管理される特殊なエントリに格納されます。これらのエントリは、エントリに関連付けられたサービス名およびサービスコンテナによって識別されます。

セットアップ

既存の LDAP サーバーを Configuration Manager で使用するには、以下を行う必要があります。

Configuration Manager が設定データを格納するときに使用する独自のオブジェクトクラスと属性をサポートするようにサーバーのスキーマを拡張します。
Configuration Manager がサポートするエントリと同様に、リポジトリ内のエントリに対するマッピング情報をカスタマイズして、サーバーに格納します。

展開ツール

既存の LDAP サーバーを Configuration Manager で使用するには、インストール CD にある次の展開ツールが必要です。

88apoc-registry.ldif: 設定データを格納するために必要なオブジェクトクラスと属性を導入するスキーマファイルです。
OrganizationMapping: LDAP エントリと Configuration Manager エントリ間のマッピングを記述するデフォルトのプロパティファイルです。
UserProfileMapping: LDAP ユーザーエントリ属性と Configuration Manager ユーザープロファイル属性間のマッピングを記述するデフォルトのプロパティファイルです。
createServiceTree: マッピングファイルを LDAP リポジトリに格納するスクリプトです。
deployApoc: LDAP サーバーのスキーマを拡張し、マッピングファイルを LDAP リポジトリに格納するスクリプトです。

スキーマ拡張

設定データは、そのデータが関連するエントリに接続するエントリツリーに格納されます。エントリツリーによって使用されるオブジェクトのクラスと属性を LDAP サーバーに格納するには、LDAP サーバースキーマの該当するオブジェクトとクラスを追加する必要があります。たとえば、提供されているスキーマ拡張ファイルは Sun Java^TM System Directory Server にオブジェクトとクラスを追加する際 LDIF フォーマットを使用します。オブジェクトとクラスをその他の LDAP サーバーに追加するには、そのサーバーで認識される形式を使用する必要があります。

組織のマッピング

LDAP エントリと Configuration Manager エントリ間のマッピングを指定するには、Organization マッピングファイルを編集する必要があります。さまざまなキーに、LDAP リポジトリのレイアウトに一致する値を指定する必要があります。

ユーザーエンティティは、すべてのエンティティで使用されるオブジェクトクラスと、リポジトリ全体で固有の値を持つ必要がある属性によって識別されます。管理アプリケーション内でのユーザーの表示方法に影響する名前の形式を指定できます。また、組織内のユーザーエントリでコンテナエントリを使用する場合に、オプションでそのコンテナエントリを指定できます。次に、キーの名前とその標準値を示します。

# すべてのユーザーエントリが使用するオブジェクトクラス
User/ObjectClass=inetorgperson
# ユーザーエントリの値がリポジトリ内で一意である属性
User/UniqueIdAttribute=uid
# ユーザーエントリの組織エントリ内にあるオプションのコンテナ
# 使用しない場合は、この行を削除すること
User/Container=ou=People
# 管理アプリケーションにおける表示名の形式
User/DisplayNameFormat=sn, givenname

役割のエンティティは、それが使用する可能性のあるオブジェクトクラスのリストと、対応する名前属性によって識別されます。これらのリストは、形式 <item1>,<item2>,...,<itemN> を使用して、整列する必要があります。つまり、リストでは命名属性と同数の項目を含め、n 番目の命名属性で n 番目のオブジェクトクラスを使用する必要があります。2 つのキーにより、役割とユーザーの関係、および役割とホストの関係が指定されます。VirtualMemberAttribute キーで指定する属性の値には、ユーザーまたはホストのエントリからクエリーできることが必要です。またこのキーには、エントリが属する役割の完全な DN を含める必要があります。MemberAttribute キーには、検索フィルタに適用するユーザーまたはホストのエントリの属性を指定する必要があります。またこのキーには、ユーザーまたはホストが属する役割の完全な DN を含める必要があります。VirtualMemberAttribute キーには Class Of Service 仮想属性を指定できるのに対し、MemberAttribute キーにはフィルタ内で使用可能な物理属性を指定する必要があります。次に、キーの名前とその標準値を示します。

# 役割のオブジェクトクラスのリスト
Role/ObjectClass=nsRoleDefinition
# 対応する命名属性の整列済みリスト
Role/NamingAttribute=cn
# ユーザーまたはホストの役割の DN を含む
# 物理的な属性 (フィルタで使用可能)
Role/MemberAttribute=nsRoleDN
# ユーザーまたはホストへのクエリーによって
# 自分が属する役割の DN が返される属性
Role/VirtualMemberAttribute=nsRole

組織のエンティティは、オブジェクトクラスから成る 2 つの整列済みリストと対応する命名属性により、役割に似た方法で識別されます。次に、キーの名前とその標準値を示します。

# 組織のオブジェクトクラスのリスト
Organization/ObjectClass=organization
# 対応する命名属性の整列済みリスト
Organization/NamingAttribute=o

ドメインのエンティティは、組織のエンティティと同様の方法で識別されます。次に、キーの名前とその標準値を示します。

# ドメインのオブジェクトクラスのリスト
Domain/ObjectClass=ipNetwork
# 対応する命名属性の整列済みリスト
Domain/NamingAttribute=cn

ホストのエンティティは、ユーザーのエンティティと同様の方法で識別されます。次に、キーの名前とその標準値を示します。

# すべてのホストエントリが使用するオブジェクトクラス
Host/ObjectClass=ipHost
# ホストエントリの値がリポジトリ内で一意である属性
Host/UniqueIdAttribute=cn
# ホストエントリのドメインエントリ内にあるオプションのコンテナ
# 使用しない場合は、この行を削除すること
Host/Container=ou=Hosts

ユーザープロファイルのマッピング

LDAP ユーザーエントリ属性と Configuration Manager ユーザーエントリ属性間のマッピングを指定するには、User Profile マッピングファイルを編集する必要があります。各キーは Configuration Manager ユーザー属性に対応します。ユーザーエントリ内の属性の名前に、組織のマッピングによって識別された値であるキーを割り当てることができます。User/DisplayNameFormat 設定で使用する属性は、User Profile マッピング内で割り当てることが必要です。次に、キーの名前とその標準値を示します。

# inetOrgPerson.givenName
org.openoffice.UserProfile/Data/givenname = givenname
# person.sn
org.openoffice.UserProfile/Data/sn = sn
# inetOrgPerson.initials
org.openoffice.UserProfile/Data/initials = initials
# organizationalPerson.street
org.openoffice.UserProfile/Data/street = street,postalAddress,streetAddress 
# organizationalPerson.l (city)
org.openoffice.UserProfile/Data/l = l
# organizationalPerson.st (state)
org.openoffice.UserProfile/Data/st = st
# organizationalPerson.postalCode
org.openoffice.UserProfile/Data/postalcode = postalcode
# country.c (country)
org.openoffice.UserProfile/Data/c = 
# organizationalPerson.o (company)
org.openoffice.UserProfile/Data/o = o,organizationName
# deprecated -- no LDAP corollary
org.openoffice.UserProfile/Data/position =
# organizationalPerson.title
org.openoffice.UserProfile/Data/title = title
# inetOrgPerson.homePhone
org.openoffice.UserProfile/Data/homephone = homephone
# organizationalPerson.telephoneNumber 
org.openoffice.UserProfile/Data/telephonenumber = telephonenumber
# organizationalPerson.facsimileTelephoneNumber
org.openoffice.UserProfile/Data/facsimiletelephonenumber = 
facsimiletelephonenumber,officeFax
# inetOrgPerson.mail
org.openoffice.UserProfile/Data/mail = mail

配備

マッピングファイルは、LDAP リポジトリの状態を反映するようにカスタマイズしたあと配備できます。LDAP サーバーのスキーマが必要なオブジェクトクラスと属性をすでに持っている場合、スクリプト createServiceTree を直接実行できます。それ以外の場合は、スクリプト deployApoc を実行する必要があります。

deployApoc スクリプトは、 Sun Java^TM System Directory Server で使用することを目的としています。このスクリプトは、提供されたスキーマ拡張ファイルを適切なディレクトリにコピーし、LDAP サーバーを動作させて、createServiceTree スクリプトを起動します。スキーマリポジトリ内にファイルをコピーしてサーバーを再起動するアクセス権を持つユーザーとしてこのスクリプトを実行することが必要です。また、このスクリプトの実行では、次の指定が必要になります。

./deployApoc <Directoy Server Directory>

<Directoy Server Directory> パラメータは、Directory Server インストールの slapd-<server name> サブディレクトリへのパスである必要があります。たとえば、デフォルトのディレクトリを使用して、サーバーの名前が myserver.mydomain であるインストールの場合、このディレクトリは /var/Sun/mps/slapd-myserver.mydomain になります。

createServiceTree スクリプトは、直接起動された場合も deployApoc スクリプトから起動された場合も、LDAP サーバーの位置 (ホスト名、ポート番号、およびベース DN) と管理権を持つユーザーの定義 (完全な DN とパスワード) をユーザーに確認します。次に、このスクリプトは LDAP サーバーにブートストラップサービスツリーを作成して、このツリーにマッピングファイルを格納します。このスクリプトは、任意のユーザーとして実行可能であり、次によって起動されます。

./createServiceTree

次に、以下の情報を入力するようにユーザーに求めます。

Host name (デフォルト: localhost): LDAP サーバーのホスト名
Port number (デフォルト: 389): LDAP サーバーのポート番号
Base DN: LDAP リポジトリのベース DN
User DN (デフォルト: cn=Directory Manager): ベース DN の下に新しいエントリを作成できるアクセス権を持つユーザーの完全な DN
Password: 当該ユーザーのパスワード

次の DN を持つエントリ:

ou=ApocRegistry,ou=default,ou=OrganizationConfig,ou=1.0,ou=ApocService,ou=services, <baseDN>

が 2 つのマッピングファイルの内容で作成されます。

上記のとおり、deployApoc スクリプトが実行する操作は、LDAP サーバーのインストールディレクトリ、レイアウト、およびスキーマ拡張プロシージャが Sun Java System Directory Server のものとほとんど一致すると仮定します。createServiceTree スクリプトを実行するためには、そのほかのディレクトリにも手作業でスキーマ拡張を行う必要があります。OpenLDAP と ActiveDirectory を使用する方法の詳細については、付録 C 「Configuration Manager による OpenLDAP と Active Directory の使用」を参照してください。

作成されたツリーは、エンティティに関連する設定データを格納するものと一致し、 Sun Java System Identity Server のサービス管理に使用されるツリーの構造に整列されます。

その他の考慮事項

Configuration Manager フレームワークでは、デスクトップからのユーザーまたはホストの識別子に関連する完全な DN を識別するために、LDAP サーバーへの接続を (読み取り/検索権付きで) 作成できることが必要です。そのため、匿名の接続を許容するようにリポジトリを設定するか、あるいは読み取り/検索権を持つ専用のユーザーを作成する必要があります。

管理アプリケーションは、エンティティの設定データを格納するためのサービスツリーをそのエンティティにマッピングされるエントリの下に作成します。したがって、管理目的で使用されるユーザーエントリには、管理対象となるエントリの下にサブエントリを作成する権限が必要です。

デスクトップクライアントからのユーザーに対するフレームワークの認証は、Anonymous および GSSAPI の 2 通りの方式により実行できます。Anonymous メソッドでは、デスクトップクライアントが LDAP サーバーからのデータの取得を試みたときにアカウント情報を提供しないので、リポジトリ全体で読み取り/検索の匿名アクセスを有効にする必要があります。GSSAPI メソッド (認証に Kerberos を使用) を使用する場合は、LDAP サーバーを『Sun Java^TM System Directory Server 5 2004Q2 管理ガイド』の「認証と暗号化の管理」の章で説明しているとおりに設定する必要があります。