Oracle® Fusion Middleware Oracle Directory Integration Platform管理者ガイド 11g リリース1(11.1.1) B65032-03 |
|
前 |
次 |
この章では、ディレクトリ同期の構成方法と、マッピング・ルールの書式設定方法について説明します。内容は次のとおりです。
関連項目: Oracle Enterprise Manager Fusion Middleware Controlの使用方法は、第3章「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構成中にユーザーが入力した内容が入ります。
Oracle Directory Integration Platformをインストールすると、次のような様々なディレクトリ・タイプとの同期のためのテンプレート・プロファイルが作成されます。
Microsoft Active Directory 2003
Microsoft Active Directory Lightweight Directory Service(AD LDS)バージョン1(旧称Active Directory Application Mode(ADAM))
IBM Tivoli Directory Server 6.2
Sun Java System Directory Server 6.3(将来、Oracle Directory Server Enterprise Editionに変名される)
Oracle Directory Server Enterprise Edition 11.1.1.3(旧称Sun Java System Directory Server)
Novell eDirectory 8.8
OpenLDAP 2.2
Oracle Database
LDIFファイル
タグ付きファイル
テンプレート・プロファイルの作成に使用されるプロパティ・ファイルとマッピング・ファイルは、$ORACLE_HOME/ldap/odi/conf
ディレクトリにあります。
サード・パーティ・ディレクトリの接続詳細は、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 接続詳細のプロパティ
プロパティ | 説明 |
---|---|
|
接続ディレクトリのURL
|
|
サード・パーティ・ディレクトリへの接続に使用される識別名またはアカウント名 |
注意:
|
この項では、マッピング・ルールの構成方法を説明します。内容は次のとおりです。
マッピング・ルール属性を使用して、ソースから宛先へエントリを変換する方法を指定します。Oracleバックエンド・ディレクトリは、ソースまたは宛先のいずれかである必要があります。エントリを変換する際のマッピング・ルールには、ドメイン・ルール、属性ルールおよびリコンシリエーション・ルールの3種類があります。これらのマッピング・ルールにより、識別名マッピング、属性レベル・マッピングおよびリコンシリエーション・ルールを指定できます。リコンシリエーション・ルールは、Novell eDirectoryとOpenLDAPでのみ使用されます。リコンシリエーション・ルールの詳細は、第22章「Novell eDirectoryまたはOpenLDAPとの統合」を参照してください。
マッピング・ルールは固定の表形式で編成され、その形式に忠実に従う必要があります。マッピング・ルールの各セットは、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 ###
この例のsrcAttrName1
とsrcAttrName2
を拡張するには、それぞれ改行なしで1行に記述する必要があります。
この項では、Oracleバックエンド・ディレクトリと接続ディレクトリ間のエントリのマップ方法を説明します。マッピングがOracleバックエンド・ディレクトリとLDAPディレクトリ間のものである場合、複数のマッピング・ルールを作成できます。キーワードDomainRules
のみを含んでいる行の後に、ドメイン・ルールの指定が表示されます。各ドメイン・ルールは、コロン区切りのコンポーネント(表6-2で説明されている)で示されます。
表6-2 ドメイン・ルールのコンポーネント
コンポーネント名 | 説明 |
---|---|
|
関係のあるドメインまたはコンテナの名前。LDAPおよびLDIF以外のソースには、NONLDAPを指定します。 |
|
宛先に関係のあるドメイン名。このコンポーネントは、宛先ディレクトリ内のエントリのコンテナが、ソース・ディレクトリでのコンテナと異なる場合に指定します。
未指定の場合、このフィールドは有効な状態にある |
|
このルールは、ソース・ドメイン名または このフィールドは、Oracleバックエンド・ディレクトリへのインポート、またはLDIFファイルまたは他の外部LDAP準拠ディレクトリへのエクスポートの場合にのみ有効です。このコンポーネントは、宛先ディレクトリ内のエントリのいずれかの識別名が、ソース・ディレクトリのエントリの識別名と異なる場合に指定します。 このコンポーネントは、LDAPからLDIF、LDAPからLDAP、またはLDIFからLDAPへの同期の場合はオプションです。未指定の場合、ソース・ドメイン名と宛先ドメイン名は同じと考えられます。 |
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=com
のusers
コンテナが自動的に含まれます。
サード・パーティ・ディレクトリの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
マップ・ファイルにDomainExclusionList
ヘッダーを挿入して、ブートストラップや同期化の際に除外するドメインを識別できます。DomainExclusionList
にリストされたドメインは、ブートストラップおよび同期化の際に除外されます。
注意:
|
次に、除外するドメインの例を含む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
が除外されます。
キーワードAttributeRules
のみを含んでいる行の後に、属性ルールの指定が表示されます。属性ルールは、エントリのプロパティ値がどのように2つのLDAPディレクトリ間で関係するかを指定します。たとえば、一方のディレクトリのユーザー・オブジェクトのcn
属性を、別のディレクトリのgivenname
オブジェクトにマップできます。同様に、一方のディレクトリのグループ・オブジェクトのcn
属性を、別のディレクトリのdisplayname
属性にマップできます。各属性ルールは、コロン区切りのコンポーネント(表6-3で説明されている)で示されます。属性ルール指定の末尾は、3つの番号記号(###
)の行です。
表6-3 属性ルールのコンポーネント
コンポーネント名 | 説明 |
---|---|
|
LDAP準拠ディレクトリのリポジトリの場合、このパラメータは変換する属性の名前を意味します。 Oracle Databaseのリポジトリの場合、このパラメータは、 他のリポジトリの場合、このパラメータは適切に解釈されます。 |
|
ソース属性を宛先に渡す必要があるかどうかを示します。エントリをOracleバックエンド・ディレクトリと接続ディレクトリ間で同期化する場合は、一部の属性を同期キーとして使用する必要があります。このフィールドは、指定した属性がキーとして使用されているかどうかを示します。使用されている場合は、属性の変化には関係なく、その属性の値がソースから抽出されます。 属性を相手側に常に渡す必要がある場合は、このフィールドに0(ゼロ)以外の整数値を指定します。 |
|
このパラメータは、整数、文字列、バイナリなど、属性の型を意味し、マッピング・ルールの妥当性をチェックします。 |
|
共有している属性のソースがLDAP準拠ディレクトリの場合は、このパラメータによって、その属性が所属しているオブジェクト・クラスの名前が指定されます。 共有属性のソースがOracle Databaseのリポジトリの場合、このパラメータは表名を意味し、指定は必須です。他のリポジトリの場合、このパラメータは無視されます。 |
|
オプションの属性。未指定の場合は、 LDAP準拠ディレクトリの場合、このパラメータは宛先の属性の名前を意味します。 Oracle Databaseのリポジトリの場合、このパラメータは、 他のリポジトリの場合、このパラメータは適切に解釈されます。 |
|
このパラメータは、整数、文字列、バイナリなど、属性の型を意味します。ソースおよび宛先の属性型の互換性を保証する責任は管理者にあります。Oracle Directory Integration Platformはこの互換性を保証しません。 |
|
LDAP準拠ディレクトリの場合、このパラメータは、属性が所属するオブジェクト・クラスを意味します。このパラメータはオプションです。 Oracle Databaseのリポジトリの場合、このパラメータは表名を意味し、指定は必須です。 他のリポジトリの場合、このパラメータは無視されます。 |
|
次の演算子とファンクションを持つオプションの算術式: 演算子: +および| ファンクション:
未指定の場合は、ソース属性値が宛先属性の値としてコピーされます。リテラルは一重引用符('')または二重引用符("")で指定できます。 |
同期プロファイルにマッピング・ルールを入力する場合、厳密に正しい形式になるようにファイルを編集します。
注意: マッピング・ファイルに属性およびオブジェクト・クラスが定義される際、スキーマに定義されているそれぞれの属性およびオブジェクト・クラスはソース・ディレクトリに入っているとみなされます。 同期用に親コンテナが選択されると、マッピング・ルールに一致するすべての子も同様に同期化されます。子コンテナを選択して同期から排除することはできません。 |
マップ・ファイルに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
同期プロファイルを作成および構成する際に、Oracle Enterprise Manager Fusion Middleware Controlを使用して同期マッピング・ルールを作成することをお薦めします。「同期プロファイルの作成」で説明するように、マッピング・ルールは「マッピング」タブで作成します。次の情報は、マッピング・ファイルを手動で(つまりOracle Enterprise Manager Fusion Middleware Controlを使用しないで)作成する必要がある場合に参照するためのものです。
新規マッピング・ファイルを手動で作成するには、次のようにします。
ソース・ディレクトリ内で同期に関係のあるコンテナを指定します。
ソース・コンテナ内のオブジェクトのマッピング先である宛先コンテナを指定します。指定されたコンテナがディレクトリ内に存在することを確認します。
宛先ディレクトリ内に作成されるエントリの識別名作成ルールを決定します。LDAPからLDAPへの場合、マッピングは通常1対1です。LDAP以外からLDAPへの場合は、ドメインの識別名構成ルールが必要です。たとえば、タグ付きファイルまたはHuman Resourcesエージェントからの同期の場合、マッピング・ルールの形式はuid=%,dc=mycompany,dc=com
になります。その場合、Oracle Human Resourcesから適用されるすべての変更にuid
属性が存在する必要があります。手順6で指定するとおり、必須属性としてuid
属性を指定する必要があります。
ディレクトリ間で同期化するオブジェクト(ソースおよび宛先ディレクトリ内の関連オブジェクト・クラス)を指定します。通常、ディレクトリ間で同期化されるオブジェクトには、ユーザー、グループ、組織単位、組織およびその他のリソースがあります。これらのオブジェクトを識別するには、ディレクトリで使用されている実際のオブジェクト・クラスを識別します。
ディレクトリ間で同期化する各種オブジェクトのプロパティ(LDAPコンテキストの属性)を指定します。オブジェクトの属性すべてを同期化する必要はありません。同期化対象のユーザー・プロパティは、cn
、sn
、uid
およびmail
です。
マッピング・ルールを定義します。各マッピング・ルールの形式は次のとおりです。
<srcAttrName>:<ReqdFlag>:<srcAttrType>:<SrcObjectClass>: <dstAttrName>:<dstAttrType>:<dstObjectClass>: <Mapping Rule>
マッピング・ルールを定義するときは、必ず次のことを確認してください。
必須属性にはそれぞれ順序番号が付いていること。たとえば、手順3でuid
属性が必須として指定された場合は、<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=Anne
とlastname=Smith
の2つの属性を使用してAnne Smithを表すとします。これらの2つの属性は、Oracleバックエンド・ディレクトリの1つの属性cn=Anne Smith
にマップできます。ただし、双方向同期では、逆方向のマッピングはできません。たとえば、cn=Anne Smith
を複数の属性にマップすることはできません。
関連項目: この章の終わりにあるマッピング・ファイルの例 |
サポートされている属性マッピング・ルールは、次のとおりです。
連結演算子(+): 2つの文字列属性を連結します。
次のようなマッピング・ルールについて考えてみます。
Firstname,lastname: : : : givenname: : inetorgperson: firstname+lastname
たとえば、ソースのFirstname
がJohn
、LastName
がDoe
の場合、このルールによって、宛先の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,'@')
たとえば、ソースのmail
がJohn.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)
この場合、ソースのuniquemember
がcn=testuser1,cn=srcdomain
の場合、宛先のuniquemember
は、cn=test user1,cn=dstdomain
になります。
リテラル:
Userpassword: : :person: userpassword: :person: 'welcome1'
前述の説明に基づいて、ここではタグ付きファイル・インタフェースを使用して、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 ###
統合プロファイルのサンプルは、Oracle Directory Integration Platformインストールの一部として作成されます。統合プロファイルのサンプルの作成に使用されるプロパティ・ファイルは、$ORACLE_HOME/ldap/odi/samples
ディレクトリにあります。
次にインポート・マッピング・ファイルの例を示します。
インポート・マッピング・ファイル例
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つのセクションに分かれています。マッピング・ルールにオブジェクト・クラスを指定すると、あるオブジェクトの特定の属性を一意にマップできます。
マッピング・ルールは、新規ルールの追加、既存ルールの変更またはorclodipAttributeMappingRules
属性に指定されているマッピング・ルール・セットからの一部のルールの削除によって、カスタマイズできます。通常、これらの操作を実行するには、マッピング・ルールが指定されているファイルを指定するか、または使用するOracleバックエンド・ディレクトリのドキュメントの説明に従い、ldapsearch
コマンドを使用してファイルの属性値を格納します。
新規エントリをマッピング・ルール・ファイルに追加するには、そのファイルを編集して、レコードをファイルに追加します。これには、次のようにします。
Oracleバックエンド・ディレクトリにマップする必要がある接続ディレクトリの属性名とオブジェクト・クラスを識別します。
Oracleバックエンド・ディレクトリ内の対応する属性名およびマップ先のオブジェクト・クラスを識別します。
属性値に対して実行する必要がある変換を示すマッピング・ルール要素を生成します。
managesyncprofilesコマンドを使用して、属性マッピング・ルール・ファイルを同期プロファイルにロードします。
たとえば、ソース・ディレクトリ内のあるエントリの電子メール属性を宛先の固有識別子にマップする必要がある場合は、次のようになります。
Email: : : inetorgperson: uid: : person:
マッピング・ルール・ファイル内の削除するエントリを特定した後、エントリをファイルから削除するか、エントリの前に番号記号(#)を付けてそのエントリをコメント化することができます。
関連項目:
|
カスタム・プラグインを使用してマッピング機能を拡張できます。新しいマッピング操作用のプラグインをサポートするために、oracle.ldap.odip.util.mapapi.IMapOperation Javaインタフェースが定義されています。このトピックには次の項が含まれ、マッピング機能を拡張するカスタム・プラグインに対するOracle Directory Integration Platformのサポートが説明されています。
カスタム・プラグインを使用してマッピング機能を拡張するには、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」です。
属性に複数の値がある場合、対応するプラグインは、ベクターに格納されているすべての属性値に対して一度のみ呼び出されます。属性値ごとに呼び出されるわけではありません。
空の文字列リテラル(" ")または文字リテラル(' ')は無視されます。
プラグイン呼出しに従って、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)
マッピング・プラグインをOracle Directory Integration Platformに追加するには、次のようにします。
実行中の場合は、Oracle Directory Integration PlatformをホストしているWebLogic管理対象サーバーを停止します。
マッピング・プラグインの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/
Oracle Directory Integration PlatformをホストするWebLogic管理対象サーバーを起動します。
この項では、マッピング・プラグインの様々なアプリケーションについて説明します。内容は次のとおりです。
アプリケーションでは、マッピング・フレームワークで内部的にサポートされていない独自のマッピング操作を実装できます。
条件付きマッピングのサポート
条件に基づく属性マッピングをサポートできます。たとえば、credential
属性が存在する場合はorclisenabled
をENABLED
に設定し、存在しない場合はorclisenabled
をDISABLED
に設定するようにマッピング・ルールを作成できます。このロジックは、プラグインを実装してこの値を割り当てることでサポートできます。このマッピング・ルールは、次のようになります。
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)
現在のマッピング・フレームワークでサポートされるのは、属性に対して単一のリテラル値を指定することのみです。しかし、属性に複数のデフォルト値を指定できる場合は、複数のリテラル値を指定することが必要になります。たとえば、Microsoft Exchangeの場合、複数の値を指定できるshowInAddressBook属性が存在します。これも、プラグインを使用して実装できます。
この項では、プラグインの使用例を示します。
例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; }
デフォルトで、コネクタにより、同期用に構成されたコンテナ内のすべてのオブジェクトに対する変更が取得されます。しかし、ユーザーおよびグループに対する変更のみなど、特定のタイプの変更のみを同期化する場合があります。マッピング・ルールにより、エントリをあるディレクトリから別のディレクトリに変換する方法を指定できますが、ディレクトリ間で同期化されるオブジェクトをフィルタ処理することもできます。
接続ディレクトリからの変更をOracleバックエンド・ディレクトリにインポートする前に、同期プロファイルで変更を「接続されたディレクトリ一致フィルタ」(orclODIPConDirMatchingFilter
)属性を使用してフィルタ処理できます。同様に、Oracleバックエンド・ディレクトリから接続ディレクトリにエクスポートする前に、変更を「OID一致フィルタ」(orclODIPOIDMatchingFilter
)属性を使用してフィルタ処理できます。
どちらの属性の場合も、次の項で説明されているように、接続ディレクトリに対して、LDAP検索により増分変更を取得するか、または変更ログに変更を格納するかのいずれかのフィルタを指定できます。
変更ログをサポートしていない接続ディレクトリの場合、LDAP検索の実行によりエントリの最新のフットプリントが取得されます。objectclass=*
を指定して実行されるLDAP検索では、所定のツリーまたはサブツリー内のエントリがすべて返されるため、同期に関係のあるオブジェクトのみを取得するには、LDAPフィルタ構文を使用してフィルタを指定する必要があります。たとえば、検索フィルタをorclOdipConDirMatchingFilter
属性に割り当てることができます。フィルタは、searchfilter=
LDAP_SEARCH_FILTER
と指定します。
次の例では、組織単位、グループおよびユーザーを取得し、コンピュータは取得しないLDAP検索フィルタを作成します。
searchfilter=(|(objectclass=group)(objectclass=organizationalUnit) (&(objectclass=user)(!(objectclass=computer))))
変更ログに変更を格納する接続ディレクトリの場合、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-4に、同期時に使用される各種のファイルの場所を示します。デフォルトでは、ファイル・ベースのインタフェース(タグ付き/LDIF)が同期に使用される場合、次の場所でファイルの読取りと書込みが行われます。
表6-4 ファイルの場所と名前
ファイル | ファイル名 |
---|---|
インポート・データ・ファイル |
|
エクスポート・データ・ファイル |
$ORACLE_HOME/ldap/odi/data/export/Profile_Name.dat |
たとえば、Oracle Human Resourcesプロファイルのデータ・ファイル名はoraclehrprofile.dat
です。