ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド
11g リリース1(11.1.1)
B65032-02
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

6 ディレクトリ同期の構成

この章では、ディレクトリ同期の構成方法と、マッピング・ルールの書式設定方法について説明します。内容は次のとおりです。


関連項目:

Oracle Enterprise Manager Fusion Middleware Controlの使用方法は、第3章「Oracle Directory Integration Platformの管理」を参照してください。

6.1 Oracle Directory Integration Platformでのコネクタの登録

コネクタをデプロイする前に、Oracle Directory Integration Platformで使用しているOracleバックエンド・ディレクトリにコネクタを登録してください。この登録には、ディレクトリにエントリとして格納される同期プロファイルの作成作業が含まれます。Oracle Enterprise Manager Fusion Middleware Controlを使用したディレクトリ同期プロファイルの作成方法は、「同期プロファイルの作成」を参照してください。

同期プロファイル・エントリの属性は、オブジェクト・クラスorclodiProfileに属します。ただし、orclodiplastappliedchangenumber属性のみはorclchangesubscriberオブジェクト・クラスに属します。

プラットフォーム関連のクラスと属性には、オブジェクト識別子の接頭辞2.16.840.1.113894.7が割り当てられます。

Oracleバックエンド・ディレクトリがOracle Internet Directoryである場合は、ディレクトリ内で、次のコンテナの下に様々な同期プロファイル・エントリが作成されます。

cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory

たとえば、OracleHRAgentという名前のコネクタが、次のようにディレクトリに格納されます。

orclodipagentname=OracleHRAgent,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory

Oracleバックエンド・ディレクトリがOracle Unified DirectoryまたはOracle Directory Server Enterprise Editionである場合は、ディレクトリ内で、次のコンテナの下に様々な同期プロファイル・エントリが作成されます。

cn=subscriber profile,cn=changelog subscriber,cn=Directory Integration Platform, <suffix>

<suffix>には、Oracle Unified DirectoryまたはOracle Directory Server Enterprise EditionでのDIP構成中にユーザーが入力した内容が入ります。

6.2 同期プロファイルのテンプレート

Oracle Directory Integration Platformをインストールすると、次のような様々なディレクトリ・タイプとの同期のためのテンプレート・プロファイルが作成されます。

テンプレート・プロファイルの作成に使用されるプロパティ・ファイルとマッピング・ファイルは、$ORACLE_HOME/ldap/odi/confディレクトリにあります。

6.3 接続詳細の構成

サード・パーティ・ディレクトリの接続詳細は、Oracle Enterprise Manager Fusion Middleware Controlを使用して同期プロファイルを作成または編集することで構成できます。インストール時に作成されたサンプルの同期プロファイルのいずれかを使用するには、正しい接続詳細を指定する必要があります。接続詳細の指定に加えて、サード・パーティ・ディレクトリのユーザー・アカウントに、ユーザーおよびグループ情報の読取りに必要な権限があることを確認する必要もあります。

インストール時に用意されたテンプレート・プロパティ・ファイルに基づいて、プロファイルを作成することもできます。これを行う場合、プロファイルのodip.profile.condirurlプロパティおよびodip.profile.condiraccountプロパティに接続詳細を指定する必要があります。パスワードを要求されます。

接続詳細の指定に加えて、サード・パーティ・ディレクトリのユーザー・アカウントに、ユーザーおよびグループ情報の読取りに必要な権限があることを確認する必要もあります。

各サード・パーティ・ディレクトリでは、削除されたエントリを取得するために、異なる構成が必要です。tombstoneエントリを読み取るために必要なtombstoneの構成および権限を設定するには、サード・パーティ・ディレクトリのマニュアルを参照してください。たとえば、Microsoft Active Directoryでは、ユーザー・アカウントに、変更の監視対象となっているフォレストのすべてのドメインに対して、ディレクトリ変更をレプリケートする権限があることを確認する必要もあります。これは、次のいずれかの方法により実行できます。

この権限を管理者以外のユーザーに付与するには、Microsoft Help and Support(http://support.microsoft.com/)の記事「How to Grant the 'Replicating Directory Changes' Permission for the Microsoft Metadirectory Services ADAM Service Account」の「More Information」の項の指示に従います。

ディレクトリ同期プロファイルの最も重要な部分のいくつかには、表6-1に示すプロパティに指定する接続詳細が含まれます。

表6-1 接続詳細のプロパティ

プロパティ 説明

odip.profile.condirurl

接続ディレクトリのURL

  • LDAPディレクトリに接続するには、host:portの形式を使用します。

  • SSLモードで接続するには、host:port:1の形式を使用します。

  • データベースに接続するには、host:port:sidの形式を使用します。

odip.profile.condiraccount

サード・パーティ・ディレクトリへの接続に使用される識別名またはアカウント名



注意:

  • 指定するアカウント情報には、接続するディレクトリでの十分な権限が必要です。

  • LDIFまたはタグ付きデータ形式を使用している場合には、アカウント名は不要です。

  • パスワードを要求されます。


6.4 マッピング・ルールの構成

この項では、マッピング・ルールの構成方法を説明します。内容は次のとおりです。

マッピング・ルール属性を使用して、ソースから宛先へエントリを変換する方法を指定します。Oracleバックエンド・ディレクトリは、ソースまたは宛先のいずれかである必要があります。エントリを変換する際のマッピング・ルールには、ドメイン・ルール、属性ルールおよびリコンシリエーション・ルールの3種類があります。これらのマッピング・ルールにより、識別名マッピング、属性レベル・マッピングおよびリコンシリエーション・ルールを指定できます。リコンシリエーション・ルールは、Novell eDirectoryとOpenLDAPでのみ使用されます。リコンシリエーション・ルールの詳細は、第22章「Novell eDirectoryまたはOpenLDAPとの統合」を参照してください。


注意:

Oracle Databaseに接続するマッピング・ルールの構成の詳細は、「Oracle Databaseの表との同期」の章の第9.2項「マッピング・ファイルの準備」を参照してください。

マッピング・ルールは固定の表形式で編成され、その形式に忠実に従う必要があります。マッピング・ルールの各セットは、DomainRulesまたはAttributeRulesという語のみを含む行と3つの番号記号(###)のみを含む行の間にあります。

DomainRules
srcDomainName1: [dstDomainName1]: [DomainMappingRule1]
srcDomainName2: [dstDomainName2]: [DomainMappingRule2]
[DomainExclusionList]
srcDomainForExclusion1
srcDomainforExclustion2
###
AttributeRules
srcAttrName1:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:[dstAttrName1]:
[DstAttrType]:[DstObjectClass]:[AttrMappingRule1]
srcAttrName1,srcAttrName2:[ReqAttrSeq]:[SrcAttrType]:[SrcObjectClass]:
[dstAttrName2]:[DstAttrType]:[DstObjectClass]:[AttrMappingRule2]
[AttributeExclusionList]
exclusionAttribute1
exclusionAttribute2
###

この例のsrcAttrName1srcAttrName2を拡張するには、それぞれ改行なしで1行に記述する必要があります。

6.4.1 識別名マッピング

この項では、Oracleバックエンド・ディレクトリと接続ディレクトリ間のエントリのマップ方法を説明します。マッピングがOracleバックエンド・ディレクトリとLDAPディレクトリ間のものである場合、複数のマッピング・ルールを作成できます。キーワードDomainRulesのみを含んでいる行の後に、ドメイン・ルールの指定が表示されます。各ドメイン・ルールは、コロン区切りのコンポーネント(表6-2で説明されている)で示されます。

表6-2 ドメイン・ルールのコンポーネント

コンポーネント名 説明

SrcDomainName

関係のあるドメインまたはコンテナの名前。LDAPおよびLDIF以外のソースには、NONLDAPを指定します。

DstDomainName

宛先に関係のあるドメイン名。このコンポーネントは、宛先ディレクトリ内のエントリのコンテナが、ソース・ディレクトリでのコンテナと異なる場合に指定します。

SrcDomainNameに割り当てられた値がLDAPまたはLDIFドメインの場合、このフィールドも同じ値を継承します。ただし、SrcDomainNameに割り当てられた値がLDAPまたはLDIFドメイン以外の場合、エントリの作成場所となるコンテナを指定する必要があります。

未指定の場合、このフィールドは有効な状態にあるSrcDomainNameの値を継承します。LDAPおよびLDIF以外の宛先には、NONLDAPを指定します。インポートとエクスポートは、常にOracleバックエンド・ディレクトリを参照するため、NONLDAP:NONLDAPの組合せは許可されません。

DomainMappingRule

このルールは、ソース・ドメイン名またはAttributeRulesに指定されている属性(あるいはその両方)から、宛先識別名を構成するために使用されます。このフィールドの形式は、通常、cn=%,l=%,o=oracle,dc=comです。これらの指定は、エントリをディレクトリ内の異なるドメインまたはコンテナに配置するために使用されます。LDAP以外のソースの場合、このルールにより、ディレクトリにエントリを追加できるようターゲット識別名を構成する方法を指定します。

このフィールドは、Oracleバックエンド・ディレクトリへのインポート、またはLDIFファイルまたは他の外部LDAP準拠ディレクトリへのエクスポートの場合にのみ有効です。このコンポーネントは、宛先ディレクトリ内のエントリのいずれかの識別名が、ソース・ディレクトリのエントリの識別名と異なる場合に指定します。

このコンポーネントは、LDAPからLDIF、LDAPからLDAP、またはLDIFからLDAPへの同期の場合はオプションです。未指定の場合、ソース・ドメイン名と宛先ドメイン名は同じと考えられます。


例6-1 識別名マッピングの例

Distinguished Name Rules
%USERBASE INSOURCE%:%USERBASE ATDEST%:

USERBASEは、サード・パーティ・ディレクトリのユーザーおよびグループのマップ元のコンテナを指します。通常、これは、サード・パーティ・ディレクトリ・ドメインのルートの下にあるusersコンテナです。

例6-2 1対1識別名マッピングの例

1対1のマッピングを行う場合は、サード・パーティ・ディレクトリのDNがOracleバックエンド・ディレクトリのものと一致する必要があります。この例では、サード・パーティ・ディレクトリの識別名がOracleバックエンド・ディレクトリのDNに一致します。具体的には、次の条件を満たしている必要があります。

  • サード・パーティ・ディレクトリのホストはus.mycompany.comドメインにあり、したがって、サード・パーティ・ディレクトリ・ドメインのルートはus.mycompany.comです。ドメインの下にあるuserコンテナのDN値は、cn=users,dc=us,dc=mycompany,dc=comになります。

  • Oracleバックエンド・ディレクトリのデフォルトのレルム値は、dc=us,dc=mycompany,dc=comです。このデフォルトのレルムには、DN値がcn=users,dc=us,dc=mycompany,dc=comusersコンテナが自動的に含まれます。

サード・パーティ・ディレクトリのDNがOracleバックエンド・ディレクトリのDNと一致するため、ディレクトリ間の1対1識別名マッピングが行われます。

dc=us,dc=mycompany,dc=comの下のcn=usersコンテナのみを同期化する場合、ドメイン・マッピング・ルールは次のとおりです。

Distinguished Name Rules
cn=users,dc=us,dc=mycompany,dc=com:cn=users,dc=us,dc=mycompany,dc=com 

このルールでは、cn=users,dc=us,dc=mycompany,dc=comの下のすべてのエントリが同期化されます。ただし、このコンテナの下で同期化されるオブジェクトのタイプは、識別名マッピング・ルールに従う属性レベルのマッピング・ルールによって決まります。

cn=users,dc=us,dc=mycompany,dc=comの下のエントリcn=groups,dc=us,dc=mycompany,dc=comを同期化する場合、ドメイン・マッピング・ルールは次のとおりです。

cn=groups,dc=us,dc=mycompany,dc=com:cn=groups,cn=users,dc=us,dc=mycompany,dc=com

6.4.1.1 ドメインの除外

マップ・ファイルにDomainExclusionListヘッダーを挿入して、ブートストラップや同期化の際に除外するドメインを識別できます。DomainExclusionListにリストされたドメインは、ブートストラップおよび同期化の際に除外されます。


注意:

domainexclusionlistにリストされた識別名(DN)は、ソース・ディレクトリのコンテナのDNを識別しています。

次に、除外するドメインの例を含むDomainExclusionListヘッダーの例を示します。

DomainExclusionList
OU=myou,OU=test,DC=mycompany,DC=com
OU=mynewou,OU=test,DC=mycompany,DC=com

例6-3「DomainExclusionListヘッダーおよびAttributeExclusionListヘッダーを使用したマップ・ファイルの例」は、DomainExclusionListヘッダーを含むマップ・ファイルの例を示しています。この例では、RDN OU=myou, OU=rfi6894748, DC=imtest, DC=com and OU=mynewou, OU=rfi6894748, DC=imtest, DC=comが除外されます。

6.4.2 属性レベル・マッピング

キーワードAttributeRulesのみを含んでいる行の後に、属性ルールの指定が表示されます。属性ルールは、エントリのプロパティ値がどのように2つのLDAPディレクトリ間で関係するかを指定します。たとえば、一方のディレクトリのユーザー・オブジェクトのcn属性を、別のディレクトリのgivennameオブジェクトにマップできます。同様に、一方のディレクトリのグループ・オブジェクトのcn属性を、別のディレクトリのdisplayname属性にマップできます。各属性ルールは、コロン区切りのコンポーネント(表6-3で説明されている)で示されます。属性ルール指定の末尾は、3つの番号記号(###)の行です。

表6-3 属性ルールのコンポーネント

コンポーネント名 説明

SrcAttrName

LDAP準拠ディレクトリのリポジトリの場合、このパラメータは変換する属性の名前を意味します。

Oracle Databaseのリポジトリの場合、このパラメータは、SrcClassNameで指定された表のColumnNameを意味します。

他のリポジトリの場合、このパラメータは適切に解釈されます。

ReqAttrSeq

ソース属性を宛先に渡す必要があるかどうかを示します。エントリをOracleバックエンド・ディレクトリと接続ディレクトリ間で同期化する場合は、一部の属性を同期キーとして使用する必要があります。このフィールドは、指定した属性がキーとして使用されているかどうかを示します。使用されている場合は、属性の変化には関係なく、その属性の値がソースから抽出されます。

属性を相手側に常に渡す必要がある場合は、このフィールドに0(ゼロ)以外の整数値を指定します。

SrcAttrType

このパラメータは、整数、文字列、バイナリなど、属性の型を意味し、マッピング・ルールの妥当性をチェックします。

SrcObjectClass

共有している属性のソースがLDAP準拠ディレクトリの場合は、このパラメータによって、その属性が所属しているオブジェクト・クラスの名前が指定されます。

共有属性のソースがOracle Databaseのリポジトリの場合、このパラメータは表名を意味し、指定は必須です。他のリポジトリの場合、このパラメータは無視されます。

DstAttrName

オプションの属性。未指定の場合は、SrcAttrNameが使用されます。

LDAP準拠ディレクトリの場合、このパラメータは宛先の属性の名前を意味します。

Oracle Databaseのリポジトリの場合、このパラメータは、SrcClassNameで指定された表のColumnNameを意味します。

他のリポジトリの場合、このパラメータは適切に解釈されます。

DstAttrType

このパラメータは、整数、文字列、バイナリなど、属性の型を意味します。ソースおよび宛先の属性型の互換性を保証する責任は管理者にあります。Oracle Directory Integration Platformはこの互換性を保証しません。

DstObjectClass

LDAP準拠ディレクトリの場合、このパラメータは、属性が所属するオブジェクト・クラスを意味します。このパラメータはオプションです。

Oracle Databaseのリポジトリの場合、このパラメータは表名を意味し、指定は必須です。

他のリポジトリの場合、このパラメータは無視されます。

AttrMapping Rule

次の演算子とファンクションを持つオプションの算術式:

演算子: +および|

ファンクション:

  • toUpper(string): あらゆるものを大文字に変換します。

  • toLower(string): あらゆるものを小文字に変換します。

  • trunc(String,char): 指定した文字が最初に出現する箇所以降の文字列を切り捨てます。

  • truncl(String,char): 文字列で、指定した文字が最初に出現する箇所より左側の部分をすべて切り捨てます。

  • truncr(String,char): 文字列で、指定した文字の右側の部分をすべて切り捨てます。

  • bin2b64(byte[]): バイナリ値をBase64に変換します。

  • b642bin(String): Base64エンコード値をバイナリに変換します。

  • dnconvert(dnvalue): ドメイン・マッピング・ルールに基づいてDNを変換します。

未指定の場合は、ソース属性値が宛先属性の値としてコピーされます。リテラルは一重引用符('')または二重引用符("")で指定できます。


同期プロファイルにマッピング・ルールを入力する場合、厳密に正しい形式になるようにファイルを編集します。


注意:

マッピング・ファイルに属性およびオブジェクト・クラスが定義される際、スキーマに定義されているそれぞれの属性およびオブジェクト・クラスはソース・ディレクトリに入っているとみなされます。

同期用に親コンテナが選択されると、マッピング・ルールに一致するすべての子も同様に同期化されます。子コンテナを選択して同期から排除することはできません。


6.4.2.1 属性の除外

マップ・ファイルにAttributeExclusionListヘッダーを挿入して、ブートストラップや同期化の際に除外する属性を識別できます。AttributeExclusionListにリストされた属性は、ブートストラップおよび同期化の際に除外されます。

次に、除外する属性の例を含むAttributeExclusionListヘッダーの例を示します。

AttributeExclusionList
facsimileTelephoneNumber
telephonenumber

例6-3は、DomainExclusionListおよびAttributeExclusionListの両ヘッダーを含むマップ・ファイルの例を示しています。この例では、RDN OU=myou, OU=rfi6894748, DC=imtest, DC=com and OU=mynewou, OU=rfi6894748, DC=imtest, DC=comの下にあるエントリは除外され、フィルタ処理されたすべてのエントリからfacsimileTelephoneNumber属性およびtelephonenumber属性が除外されます(つまり、これらの属性は含まれません)。

例6-3 DomainExclusionListヘッダーおよびAttributeExclusionListヘッダーを使用したマップ・ファイルの例

DomainRules
ou=rfi6894748, DC=imtest, DC=com : ou=rfi6894748, cn=users, dc=us, dc=oracle, dc=com:
DomainExclusionList
OU=myou,OU=rfi6894748,DC=imtest,DC=com
OU=mynewou,OU=rfi6894748,DC=imtest,DC=com
###
AttributeRules
# attribute rule common to all objects
objectguid: :binary: :orclobjectguid:string: :bin2b64(objectguid)
ObjectSID: :binary: :orclObjectSID:string:orclADObject:bin2b64(ObjectSID)
distinguishedName: : : :orclSourceObjectDN: :orclADObject
# USER ENTRY MAPPING RULES
# attribute rule for mapping windows LOGIN id
sAMAccountName,userPrincipalName: : :user:orclSAMAccountName: :orclADUser:toupper(truncl(userPrincipalName,'@'))+"$"+sAMAccountname
# attribute rule for mapping Active Directory LOGIN id
userPrincipalName: : :user:orclUserPrincipalName: :orclADUser:userPrincipalName
# Map the userprincipalname to the nickname attr by default
userPrincipalName: : :user:uid: :inetorgperson:userPrincipalName
# Map the SamAccountName to the nickname attr if required
# If this rule is enabled, userprincipalname rule needs to be disabled
#sAMAccountName: : :user:uid: :inetorgperson
# Assign the userprincipalname to Kerberaos principalname
userPrincipalName: : :user:krbPrincipalName: :orcluserv2:trunc(userPrincipalName,'@')+'@'+toupper(truncl(userPrincipalName,'@'))
# This rule is mapped as SAMAccountName is a mandatory attr on AD
# and sn is mandatory on OID. sn is not mandatory on Active Directory
SAMAccountName: : :user:sn: : person:
# attributes to map to cn - normally this is the given name
cn: : :person:cn: :person:
AttributeExclusionList
facsimileTelephoneNumber
telephonenumber

6.4.3 新しいマッピング・ファイルの手動作成

同期プロファイルを作成および構成する際に、Oracle Enterprise Manager Fusion Middleware Controlを使用して同期マッピング・ルールを作成することをお薦めします。「同期プロファイルの作成」で説明するように、マッピング・ルールは「マッピング」タブで作成します。次の情報は、マッピング・ファイルを手動で(つまりOracle Enterprise Manager Fusion Middleware Controlを使用しないで)作成する必要がある場合に参照するためのものです。

新規マッピング・ファイルを手動で作成するには、次のようにします。

  1. ソース・ディレクトリ内で同期に関係のあるコンテナを指定します。

  2. ソース・コンテナ内のオブジェクトのマッピング先である宛先コンテナを指定します。指定されたコンテナがディレクトリ内に存在することを確認します。

  3. 宛先ディレクトリ内に作成されるエントリの識別名作成ルールを決定します。LDAPからLDAPへの場合、マッピングは通常1対1です。LDAP以外からLDAPへの場合は、ドメインの識別名構成ルールが必要です。たとえば、タグ付きファイルまたはHuman Resourcesエージェントからの同期の場合、マッピング・ルールの形式はuid=%,dc=mycompany,dc=comになります。その場合、Oracle Human Resourcesから適用されるすべての変更にuid属性が存在する必要があります。手順6で指定するとおり、必須属性としてuid属性を指定する必要があります。

  4. ディレクトリ間で同期化するオブジェクト(ソースおよび宛先ディレクトリ内の関連オブジェクト・クラス)を指定します。通常、ディレクトリ間で同期化されるオブジェクトには、ユーザー、グループ、組織単位、組織およびその他のリソースがあります。これらのオブジェクトを識別するには、ディレクトリで使用されている実際のオブジェクト・クラスを識別します。

  5. ディレクトリ間で同期化する各種オブジェクトのプロパティ(LDAPコンテキストの属性)を指定します。オブジェクトの属性すべてを同期化する必要はありません。同期化対象のユーザー・プロパティは、cnsnuidおよびmailです。

  6. マッピング・ルールを定義します。各マッピング・ルールの形式は次のとおりです。

    <srcAttrName>:<ReqdFlag>:<srcAttrType>:<SrcObjectClass>: <dstAttrName>:<dstAttrType>:<dstObjectClass>: <Mapping Rule>
    
    
    

    マッピング・ルールを定義するときは、必ず次のことを確認してください。

    • 必須属性にはそれぞれ順序番号が付いていること。たとえば、手順3uid属性が必須として指定された場合は、<ReqdFlag>のかわりに1の値を割り当てます。

    • 関連オブジェクト・クラスは、それぞれ宛先ディレクトリ上にスキーマ定義を持つこと。

    • 宛先オブジェクト・クラス内の必須属性は、すべてソースから割り当てられた値を持つこと。様々なLDAP実装は標準に完全に準拠していないこともありますが、これは標準オブジェクト・クラスにも当てはまります。

    ソース・オブジェクト・クラスに属する属性のすべてを1つの宛先オブジェクト・クラスに割り当てる必要はありません。ソース・オブジェクト・クラスの各種の属性は、異なる宛先オブジェクト・クラスに属する様々な属性に割り当てることができます。

    属性がバイナリ値をとる場合は、<attrtype>フィールドでbinaryとして指定します。

マッピング・ルールには柔軟性があります。1対多と多対1の両方のマッピングを組み込むことができます。

  • 1対多

    接続ディレクトリの1つの属性を、Oracleバックエンド・ディレクトリの多数の属性にマップできます。たとえば、接続ディレクトリのある属性がAddress:123 Main Street/MyTown, MyState 12345であるとします。Oracleバックエンド・ディレクトリのこの属性を、LDAP属性homeAddressおよびLDAP属性postalAddressの両方にマップできます。

  • 多対1

    接続ディレクトリの複数の属性をOracleバックエンド・ディレクトリの1つの属性にマップできます。たとえば、Oracle Human Resourcesディレクトリでは、firstname=Annelastname=Smithの2つの属性を使用してAnne Smithを表すとします。これらの2つの属性は、Oracleバックエンド・ディレクトリの1つの属性cn=Anne Smithにマップできます。ただし、双方向同期では、逆方向のマッピングはできません。たとえば、cn=Anne Smithを複数の属性にマップすることはできません。


関連項目:

この章の終わりにあるマッピング・ファイルの例

6.4.4 サポートされている属性マッピング・ルールと例

サポートされている属性マッピング・ルールは、次のとおりです。

  • 連結演算子(+): 2つの文字列属性を連結します。

    次のようなマッピング・ルールについて考えてみます。

    Firstname,lastname:  :  :  : givenname:  : inetorgperson: firstname+lastname
    

    たとえば、ソースのFirstnameJohnLastNameDoeの場合、このルールによって、宛先のgivenname属性は、JohnDoeという値になります。

  • OR演算子(|): 2つの文字列属性の値の1つを宛先に割り当てます。

    次のようなマッピング・ルールについて考えてみます。

    Fistname,lastname : : : :givenname: :inetorgperson: firstname | lastname
    

    この例では、firstnameの値が存在する場合は、それがgivennameに割り当てられます。firstname属性が存在しない場合、lastnameの値がgivennameに割り当てられます。両方の値が空である場合、値は割り当てられません。

  • bin2b64 ( ): ソース・ディレクトリのバイナリ値をBase64のエンコード値として宛先ディレクトリに保存します。通常、次のように使用します。

    objectguid: : : :binary: :orclobjectguid: orcladuser:bin2b64(objectguid)
    

    (objectguid)の値を検索する必要がある場合、これは必須です。

  • tolower(): 文字列属性値を小文字に変換します。

    firstname: : : :givenname: :inetorgperson: tolower(firstname)
    
  • toupper(): 文字列属性値を大文字に変換します。

    firstname: : : :givenname: :inetorgperson: toupper(firstname)
    
  • trunc(str,char): 指定したcharが最初に出現する箇所以降の文字列を切り捨てます。

    mail : : : : uid : : inetorgperson : trunc(mail,'@')
    

    たとえば、ソースのmailJohn.Doe@acme.comの場合、このルールによって、宛先のuid属性は、John.Doeという値になります。

  • truncl(str, char): 指定したcharの最初の出現まで(最初の出現を含む)文字列を切り捨てます。次に例を示します。

    mail : : : : uid : : inetorgperson : truncl(mail,'@')
    
  • truncr(str, char): 文字列内の指定したcharの右側をすべて切り捨てます。次に例を示します。

    mail : : : : uid : : inetorgperson : truncr(mail,'@')
    
  • dnconvert(str): ドメイン・マッピングが使用される場合に、DNタイプ属性を変換します。

    この例は、次のドメイン・マッピング・ルールを前提としています。

    DomainRules
    cn=srcdomain:cn=dstdomain:
    

    次に例を示します。

    uniquemember : : : groupofuniquenames : uniquemember : :groupofuniquenames : dnconvert(uniquemember)
    

    この場合、ソースのuniquemembercn=testuser1,cn=srcdomainの場合、宛先のuniquememberは、cn=test user1,cn=dstdomainになります。

  • リテラル:

    Userpassword: : :person: userpassword: :person: 'welcome1'
    

6.4.5 例: タグ付きファイル・インタフェース用のマッピング・ファイル

前述の説明に基づいて、ここではタグ付きファイル・インタフェースを使用して、Oracle Human Resourcesデータベース表からユーザー・エントリをインポートするためのマッピング・ファイルの例を示します。ソースはLDAP以外のディレクトリです。このサンプル・ファイルはインストール時に提供され、$ORACLE_HOME/ldap/odi/conf/oraclehragent.map.masterにあります。

DomainRules
NONLDAP:dc=myCompany,dc=com:uid=%dc=myCompany,dc=com
AttributeRules
firstname: : : :cn: :person
email : : : :cn: :person: trunc(email,'@')
email : 1 : :uid: :person:trunc(email,'@')
firstname,lastname: : : :cn: :person: firstname+","+lastname
lastname,firstname: : : :cn: :person: lastname+","+firstname
firstname,lastname: : : :sn: :person: lastname | firstname
EmployeeNumber: : : :employeenumber: :inetOrgperson
EMail: : : :mail: :inetOrgperson
TelephoneNumber1: : : :telephonenumber: :person
TelephoneNumber2: : : :telephonenumber: :person
TelephoneNumber3: : : :telephonenumber: :person
Address1: : : :postaladdress: :person
state: : : :st: :locality
street1: : : :street: :locality
zip: : : :postalcode: :locality
town_or_city: : : :l: :locality
Title: : : :title: :organizationalperson
#Sex: : : :sex: :person
###

前述のように、マッピング・ファイルは、キーワードおよびドメインと属性の一連のマッピング・ルール・エントリで構成されています。この例のマッピング・ファイルには、ドメイン・ルールNONLDAP:dc=myCompany,dc=com:cn=%,dc=myCompany,dc=comが含まれています。

  • このルールは、ソース・ドメインがNONLDAPで、ソース・ドメインがないことを示しています。

  • 宛先ドメイン(:dc=myCompany,dc=com)は、このプロファイルが処理するすべてのディレクトリ・エントリが、ドメインdc=myCompany,dc=comにあることを示しています。同期化を開始する前に、ドメインが存在することを確認してください。

  • ドメイン・マッピング・ルール(:uid=%,dc=myCompany,dc=com)は、ソースからのデータが、このドメイン・マッピング・ルールで構成した識別名を持つディレクトリ内のエントリを参照することを示しています。この場合のuidは、常にNULL以外の値を持つ宛先属性の1つである必要があります。同期化するエントリに対応するデータがNULL値の場合、マッピング・エンジンは、そのエントリを無効と判断し、次のエントリに進みます。ディレクトリでエントリを正確に識別するには、uidが単一値であることも必要です。

  • タグ付きファイルの場合、ソース・エントリは同期化対象のオブジェクトのタイプを示すオブジェクト・クラスを持ちません。SrcObjectClassフィールドは空白です。

  • 宛先がOracleバックエンド・ディレクトリであるオブジェクトは、それぞれオブジェクト・クラスを持つ必要があります。

  • emailは、マッピング・ファイル例では必須属性として指定されています。それは、uid属性がemail属性から導出されているためです。同期化を成功させるには、タグ付きファイルに指定されているすべての変更に、次のとおりemail属性を指定する必要があります。

    Email : 1 : : :uid : : person : trunc(email,'@')
    
  • 場合によっては、複数値属性の名前を使用して識別名のRDNを構成する必要があります。たとえば、cn=%,l=%,dc=myCompany,dc=com(cnは複数値属性)の識別名でエントリを構成する場合、DomainMappingRuleは、rdn,l=%,dc=myCompany,dc=com(rdnは、NULL値以外の宛先属性の1つ)のような形式になります。これをサポートする典型的なマッピング・ファイルは、次のような形式です。

    DomainRules
    NONLDAP:dc=us,dc=myCompany,dc=com:rdn,l=%,dc=us,dc=myCompany,dc=com
    AttributeRules
    firstname: : :cn: :person
    email : : : :cn: :person: trunc(email,'@')
    email : 1: : :rdn: :person: 'cn='+trunc(email,'@')
    firstname,lastname: : : :cn: :person: firstname+","+lastname
    lastname,firstname: : : :cn: :person: lastname+","+firstname
    firstname,lastname: : : :sn: :person: lastname | firstname
    EmployeeNumber: : : :employeenumber: :inetOrgperson
    EMail: : : :mail: :inetOrgperson
    TelephoneNumber1: : : :telephonenumber: :person
    TelephoneNumber2: : : :telephonenumber: :person
    TelephoneNumber3: : : :telephonenumber: :person
    Address1: : : :postaladdress: :person
    Address1: : : :postaladdress: :person
    Address1: : : :postaladdress: :person
    state: : : :st: :locality
    street1: : : :street: :locality
    zip: : : :postalcode: :locality
    town_or_city: 2 : : :1: :locality
    Title: : : :title: :organizationalperson
    #Sex: : : :sex: :person
    ###
    

6.4.6 例: LDIFインタフェース用のマッピング・ファイル

統合プロファイルのサンプルは、Oracle Directory Integration Platformインストールの一部として作成されます。統合プロファイルのサンプルの作成に使用されるプロパティ・ファイルは、$ORACLE_HOME/ldap/odi/samplesディレクトリにあります。


注意:

接続されているOracle Databseのインポート・マッピング・ファイルのサンプルは、第9.4.2項「マッピング・ファイルの構成」を参照してください。

次にインポート・マッピング・ファイルの例を示します。

インポート・マッピング・ファイル例

DomainRules
dc=mycompany.oid,dc=com:dc=mycompany.iplanet,dc=com
AttributeRules
# Mapping rules to map the domains and containers
o: : :organization: o: :organization
ou: : :organizationalUnit: ou: : organizationalUnit
dc: : :domain:dc: :domain
# Mapping Rules to map users
uid : : :person: uid: :inetOrgperson
sn: : :person:sn: :person
cn: : :person:cn: :person
mail: :inetorgperson: mail: :inetorgperson
employeenumber: :organizationalPerson: employeenumber: :organizationalperson
c: : :country:c: :country
l: : :locality: l: :locality
telephonenumber: :organizationalPerson: telephonenumber: :organizationalperson
userpassword: : :person: userpassword: :person
uid: : :person: orcldefaultProfileGroup: :orclUserV2
# Mapping Rules to map groups
cn: : :groupofuniquenames:cn: :groupofuniquenames
member: : :groupofuniquenames:member: :orclgroup
uniquemember: : :groupofuniquenames:uniquemember: :orclgroup
owner: : :groupofuniquenames:owner: :orclgroup
# userpassword: :base64:userpassword: :binary:

この例では、ソース・ドメインと宛先ドメインの両方が、ドメイン・マッピング・ルール・セクションで指定されています。この例では、ソース・ドメインと宛先ドメインは同じです。ただし、コンテナが宛先ディレクトリにある場合は、異なる宛先ドメインを指定できます。

また、この例では、属性ルールがユーザー属性マッピング・ルールとグループ属性マッピング・ルールの2つのセクションに分かれています。マッピング・ルールにオブジェクト・クラスを指定すると、あるオブジェクトの特定の属性を一意にマップできます。

6.4.7 マッピング・ルールの更新

マッピング・ルールは、新規ルールの追加、既存ルールの変更またはorclodipAttributeMappingRules属性に指定されているマッピング・ルール・セットからの一部のルールの削除によって、カスタマイズできます。通常、これらの操作を実行するには、マッピング・ルールが指定されているファイルを指定するか、または使用するOracleバックエンド・ディレクトリのドキュメントの説明に従い、ldapsearchコマンドを使用してファイルの属性値を格納します。

6.4.7.1 エントリのマッピング・ルール・ファイルへの追加

新規エントリをマッピング・ルール・ファイルに追加するには、そのファイルを編集して、レコードをファイルに追加します。これには、次のようにします。

  1. Oracleバックエンド・ディレクトリにマップする必要がある接続ディレクトリの属性名とオブジェクト・クラスを識別します。

  2. Oracleバックエンド・ディレクトリ内の対応する属性名およびマップ先のオブジェクト・クラスを識別します。

  3. 属性値に対して実行する必要がある変換を示すマッピング・ルール要素を生成します。

  4. managesyncprofilesコマンドを使用して、属性マッピング・ルール・ファイルを同期プロファイルにロードします。

    たとえば、ソース・ディレクトリ内のあるエントリの電子メール属性を宛先の固有識別子にマップする必要がある場合は、次のようになります。

    Email:  :  : inetorgperson: uid: : person:
    

6.4.7.2 マッピング・ルール・ファイル内のエントリの変更

マッピング・ルール・ファイル内の変更するエントリを特定した後、属性値の変換に必要なマッピング・ルール要素を生成します。

6.4.7.3 エントリのマッピング・ルール・ファイルからの削除

マッピング・ルール・ファイル内の削除するエントリを特定した後、エントリをファイルから削除するか、エントリの前に番号記号(#)を付けてそのエントリをコメント化することができます。


関連項目:


6.5 カスタム・プラグインを使用したマッピングの拡張

カスタム・プラグインを使用してマッピング機能を拡張できます。新しいマッピング操作用のプラグインをサポートするために、oracle.ldap.odip.util.mapapi.IMapOperation Javaインタフェースが定義されています。このトピックには次の項が含まれ、マッピング機能を拡張するカスタム・プラグインに対するOracle Directory Integration Platformのサポートが説明されています。

6.5.1 マッピング・プラグインの作成

カスタム・プラグインを使用してマッピング機能を拡張するには、oracle.ldap.odip.util.mapapi.IMapOperationインタフェースを実装する必要があります。それには、evaluateメソッドを次のように実装することが必要です。

Vector evaluate(Vector operands);

operands引数はベクターです。operandsベクターの要素は、マッピング・ルールで指定されたプラグイン呼出しに基づいて、次のいずれかになります。

  • 値のベクター(プラグインの引数として渡される属性)

  • 文字列(文字列リテラルはプラグインの引数として渡される)

  • 文字(文字リテラル)

戻り型はベクターです。このベクターのすべての要素は文字列またはバイト配列であることが必要です。単一の文字列を戻すには、サイズ1の新規ベクターを作成し、そのベクターに文字列を追加する必要があります。この制限は、複数値属性を許可するために強制されます。

次に例を示します。

cn,sn: : :person:description: :person:PLUGIN#MyPlugin(cn, sn, “Mr”)

プラグイン・クラスMyPluginは、Vector evaluate(Vector operands)メソッドを実装する必要があります。このマッピング・ルールのプラグイン呼出しにより、operandsの要素は次のようになります。

  • 要素1は、cnのすべての値を含むベクターです(cnに1つの値しかない場合も含む)。

  • 要素2は、snのすべての値を含むベクターです(snに1つの値しかない場合も含む)。

  • 要素3は、文字列リテラル「Mr」です。

6.5.2 マッピング・プラグインの評価制約

  • 属性に複数の値がある場合、対応するプラグインは、ベクターに格納されているすべての属性値に対して一度のみ呼び出されます。属性値ごとに呼び出されるわけではありません。

  • 空の文字列リテラル(" ")または文字リテラル(' ')は無視されます。

  • プラグイン呼出しに従って、evaluate()メソッドのVector operandsに含まれる各要素のタイプを識別し、適宜処理する必要があります。

  • プラグインと既存のマッピング・ルールの演算子またはファンクションの組合せはサポートされません。たとえば、次の組合せはマッピング・ルールとしてサポートされません。

    Plugin#MyPlugin(cn, sn) + givenanme 
    toupper(Plugin#(MyPlugin(cn,sn))
    Plugin#TempPlugin1(cn) + Plugin#TempPlugin2(sn)
    
  • 異なる属性ルールのマッピング・プラグイン呼出しを同じ呼出しシグネチャにすることをお薦めします。次の例は、Mypluginが異なる呼出しシグネチャを持つため、非常に間違いやすく、推奨されません。

    sn: : :person:givenname: :person:PLUGIN#Myplugin(sn,"Mr")
    cn: : :person:description: :person:PLUGIN#Myplugin(cn)
    

6.5.3 マッピング・プラグインの追加

マッピング・プラグインをOracle Directory Integration Platformに追加するには、次のようにします。

  1. 実行中の場合は、Oracle Directory Integration PlatformをホストしているWebLogic管理対象サーバーを停止します。

  2. マッピング・プラグインのJARファイルを、Oracle Directory Integration Platformアプリケーションが展開されたパスの/APP-INF/lib/ディレクトリにコピーします。次に例を示します。

    MW_HOME/user_projects/domains/DOMAIN_NAME/servers/MANAGED_SERVER_NAME/tmp/
    _WL_user/DIP_VERSION_NUMBER/RANDOM_CHARACTERS/APP-INF/lib/
    
  3. Oracle Directory Integration PlatformをホストするWebLogic管理対象サーバーを起動します。

6.5.4 マッピング・プラグインのアプリケーション

この項では、マッピング・プラグインの様々なアプリケーションについて説明します。内容は次のとおりです。

6.5.4.1 新規のマッピング操作のサポート

アプリケーションでは、マッピング・フレームワークで内部的にサポートされていない独自のマッピング操作を実装できます。

条件付きマッピングのサポート

条件付き属性マッピングのサポート

条件に基づく属性マッピングをサポートできます。たとえば、credential属性が存在する場合はorclisenabledENABLEDに設定し、存在しない場合はorclisenabledDISABLEDに設定するようにマッピング・ルールを作成できます。このロジックは、プラグインを実装してこの値を割り当てることでサポートできます。このマッピング・ルールは、次のようになります。

credential: : :UserType:orclisenabled::orcluserv2:PLUGIN#ConditionalAttrBasedOnPresence(credential)

すべてのカスタム・プラグインで、属性マッピング・ルールにPLUGIN#キーワードを含める必要があります(この場合はConditionalAttrBasedOnPresence)。

条件付き識別名マッピングのサポート

条件に基づくDNコンテナ・マッピングをサポートできます。たとえば、部門がSalesのユーザーをou=sales,dc=acme,dc=comにマップし、部門がITのユーザーをou=IT,dc=acme,dc=comにマップするとします。このマッピングをサポートするには、次のようにします。

  • DomainRulesセクションに、次のような構成ルールを指定します。

    NONLDAP:dc=acme,dc=com:cn=%,ou=%,dc=acme,dc=com
    
  • AttributeRulesセクションに、ouをマップするためのプラグイン操作を含む次のようなルールを指定します。

    department: : :UserType:ou: :orcluserv2:ConditionalOUMapping(department)
    

6.5.4.2 複数のリテラル値のサポート

現在のマッピング・フレームワークでサポートされるのは、属性に対して単一のリテラル値を指定することのみです。しかし、属性に複数のデフォルト値を指定できる場合は、複数のリテラル値を指定することが必要になります。たとえば、Microsoft Exchangeの場合、複数の値を指定できるshowInAddressBook属性が存在します。これも、プラグインを使用して実装できます。

6.5.5 プラグインの使用例

この項では、プラグインの使用例を示します。

例1: 属性マッピング・ルール

cn: : :person:initials: :person:PLUGIN#PluginSamp1(cn)

例1: 対応するプラグインの実装

Vector evaluate(Vector operands)
{
Vector all_cnValues = (Vector)operands.get(0);
Vector result =  new Vector();
        ….
               ….
              //All the elements of this result must be strings.
              return result;    
}

例2: 属性マッピング・ルール

cn: : :person:givenname: :person:PLUGIN#Myplugin(cn,"Mr")

例2: 対応するプラグインの実装

Vector evaluate(Vector operands)
{
Vector all_cnValues = (Vector)operands.get(0);
String strOperand = (String)operands.get(1);
Vector result =  new Vector();
 
for(int i=0; i<all_cnValues.size(); i++)
{
String cnValue = (String) all_cnValues.get(i);
String givenNameNewValue = strOperand + cnValue;
result.add(givenNameNewVlaue);
                }
              //All the elements of this result must be strings.
              return result;
}

例3: 属性マッピング・ルール

mail: : :inetorgperson:mail: :inetorgperson: Plugin#MyPlugin(mail, '@')

例3: 対応するプラグインの実装

Vector evaluate(Vector operands)
{
                Vector all_mailValues = (Vector) operands.get(0);
                Character charOperand = (Character) operands.get(1);
                char charOperandValue = charOperand.charValue();
Vector result =  new Vector();
        ….
               ….
               ….
        return result;
}

例4: 属性マッピング・ルール

cn,sn,mail: : :inetorgperson:description: :inetorgperson Plugin# MyPlugin(cn, sn, mail)

例4: 対応するプラグインの実装

Vector evaluate(Vector operands)
{
                Vector all_cnValues = (Vector) operands.get(0);
                Vector all_snValues = (Vector) operands.get(1);
                Vector all_mailValues = (Vector) operands.get(2);

                Vector result = new Vector();
                …
                …
                …

                return result;
}

6.6 一致フィルタの構成

デフォルトで、コネクタにより、同期用に構成されたコンテナ内のすべてのオブジェクトに対する変更が取得されます。しかし、ユーザーおよびグループに対する変更のみなど、特定のタイプの変更のみを同期化する場合があります。マッピング・ルールにより、エントリをあるディレクトリから別のディレクトリに変換する方法を指定できますが、ディレクトリ間で同期化されるオブジェクトをフィルタ処理することもできます。

接続ディレクトリからの変更をOracleバックエンド・ディレクトリにインポートする前に、同期プロファイルで変更を「接続されたディレクトリ一致フィルタ」(orclODIPConDirMatchingFilter)属性を使用してフィルタ処理できます。同様に、Oracleバックエンド・ディレクトリから接続ディレクトリにエクスポートする前に、変更を「OID一致フィルタ」(orclODIPOIDMatchingFilter)属性を使用してフィルタ処理できます。

どちらの属性の場合も、次の項で説明されているように、接続ディレクトリに対して、LDAP検索により増分変更を取得するか、または変更ログに変更を格納するかのいずれかのフィルタを指定できます。

6.6.1 LDAP検索による変更のフィルタ処理

変更ログをサポートしていない接続ディレクトリの場合、LDAP検索の実行によりエントリの最新のフットプリントが取得されます。objectclass=*を指定して実行されるLDAP検索では、所定のツリーまたはサブツリー内のエントリがすべて返されるため、同期に関係のあるオブジェクトのみを取得するには、LDAPフィルタ構文を使用してフィルタを指定する必要があります。たとえば、検索フィルタをorclOdipConDirMatchingFilter属性に割り当てることができます。フィルタは、searchfilter=LDAP_SEARCH_FILTERと指定します。

次の例では、組織単位、グループおよびユーザーを取得し、コンピュータは取得しないLDAP検索フィルタを作成します。

searchfilter=(|(objectclass=group)(objectclass=organizationalUnit)
(&(objectclass=user)(!(objectclass=computer))))

6.6.2 変更ログからの変更のフィルタ処理

変更ログに変更を格納する接続ディレクトリの場合、Oracle Directory Integration Platformに用意されている次の単純な演算子を使用すれば、「接続されたディレクトリ一致フィルタ」(orclODIPConDirMatchingFilter)または「OID一致フィルタ」(orclODIPOIDMatchingFilter)に一致フィルタを指定できます。

  • =(等しい演算子)

  • !(等しくない演算子)


注意:

LDAPまたはLDAP以外のディレクトリで、変更ログから増分変更が取得される場合は、前述の演算子を使用できます。

LDAP検索を使用して増分変更を取得する接続ディレクトリでは、前述の演算子を使用することもできますが、指定できるのは単一の式のみです。そうでない場合、検索は失敗します。


フィルタをsearchfilter=CHANGELOG_SEARCH_FILTERと指定します。

たとえば、次のフィルタを使用すると、プロファイルimp1またはプロファイルimp2によって変更が行われた場合、同期が行われません。

searchfilter=(|(!(modifiersname=orclodipagentname=imp1,cn=subscriber
profile,cn=changelog subscriber,cn=oracle internet
directory))(!(modifiersname=orclodipagentname=imp2,cn=subscriber
profile,cn=changelog subscriber,cn=oracle internet directory)))

変更を変更ログに格納する接続ディレクトリの場合、一致フィルタで同期化できるのは、変更ログに現れる属性についてのみです。変更ログにない属性を一致フィルタに含めると、検索操作は失敗します。このため、一致フィルタの使用は、変更ログに増分変更を格納する接続ディレクトリに限られます。

6.7 ファイルの場所とネーミング

表6-4に、同期時に使用される各種のファイルの場所を示します。デフォルトでは、ファイル・ベースのインタフェース(タグ付き/LDIF)が同期に使用される場合、次の場所でファイルの読取りと書込みが行われます。

表6-4 ファイルの場所と名前

ファイル ファイル名

インポート・データ・ファイル

$ORACLE_HOME/ldap/odi/data/import/Profile_Name.dat

エクスポート・データ・ファイル

$ORACLE_HOME/ldap/odi/data/export/Profile_Name.dat


たとえば、Oracle Human Resourcesプロファイルのデータ・ファイル名はoraclehrprofile.datです。