Oracle® Fusion Middleware Administrator's Guide for Oracle Virtual Directory 11g Release 1 (11.1.1) E10046-04 |
|
![]() Previous |
![]() Next |
This chapter describes Java plug-ins for Oracle Virtual Directory and includes the following topics:
Plug-ins allow you to extend Oracle Virtual Directory with compartmentalized functionality to meet specific business and technical requirements. You can use plug-ins to provide custom logic as part of a transaction or to connect to a custom data source. Oracle Virtual Directory supports two types of plug-ins: Java plug-ins and Python Mapping plug-ins.
Note: This chapter is specific to Java plug-ins for Oracle Virtual Directory, though from an operational perspective, Oracle Virtual Directory treats the two types of plug-ins equally. References to plug-ins in this chapter refer to Java plug-ins. See Chapter 5, "Understanding Oracle Virtual Directory Mapping" for information on mapping plug-ins. |
Oracle Virtual Directory includes several plug-ins for various purposes, including plug-ins for analysis, auditing, caching, and dynamic group presentation. You can also deploy plug-ins using different approaches and with full control over the positioning of the plug-in inside the virtual directory, including:
"Stringing-together" plug-ins to create combined and reusable functionality.
Deploying plug-ins at the "global" server level so the plug-in affects all requests and responses.
Deploying plug-ins at the adapter level so the plug-ins manipulate requests and responses for a particular adapter.
For example, you can deploy the Cache plug-in to run only on a particular Microsoft Active Directory server and only after a mapping has been run to perform translation of the Active Directory user to the standard inetOrgPerson objectclass.
Note:
|
Figure 4-1 shows the three layer architecture of the Oracle Virtual Directory plug-in framework:
Plug-ins are arranged to form chains. When Oracle Virtual Directory receives a request, the request passes through Oracle Virtual Directory in the following sequence (as shown in Figure 4-1):
The Global Service Interface (GSI), then to
The chain of global plug-ins, then to
The Adapter Service Interface (ASI), then to
The chain of adapter plug-ins.
Global plug-ins are called for all requests. For an inbound request, after all global plug-ins have been executed, the request goes to the ASI, which is the component of Oracle Virtual Directory where routing and adapter handling decisions are made. After the routing system has decided which adapters will be included in a request, the chosen adapter plug-ins are executed. Responses are generated by adapters and then sent back up the chain for further possessing and filtering.
Oracle Virtual Directory provides flexibility in determining whether a plug-in should be executed globally or within the context of a single adapter. In some situations, you may need to further restrict when a plug-in gets used. For example, an adapter is set-up to proxy a Microsoft Active Directory domain and points to DC=VAN,DC=Oracle,DC=com. Under that point in the directory tree, there is a CN=Users container and a CN=Groups container. You can add a namespace filter to any plug-in or mapping to apply them to only one part of the tree.
This topic describes the general purpose plug-ins included in Oracle Virtual Directory. The general purpose plug-ins extend Oracle Virtual Directory capabilities to perform special functions or mappings. This topic contains the following sections:
The HideEntriesByFilter plug-in allows you to control in fine detail which entries are returned by searches. Using its hideFilter
configuration parameter, the HideEntriesByFilter plug-in allows you to explicitly control which entries are returned. For example, you are using Oracle Virtual Directory as an address book directory and you want to display only the entries for customer service representatives, which have ou values of CSR. You could use the HideEntriesbyFilter plug-in with hideFilter set to ou=CSR so that when the adapter is searched, only the customer service representatives entries are returned.
The HideEntriesByFilter plug-in has the following configuration parameter:
The LDAP filter that controls which entries are restricted for searches. For example, if hideFilter
is set to (ou=Sales), then searches return only entries that contain ou=Sales. If hideFilter
is set to (!(ou=Sales)), then searches return only entries that do not contain ou=Sales.
The ChangeUserRDN plug-in allows you to rename or replace RDN values from the source directory to Oracle Virtual Directory. This plug-in is useful during LDAP directory migrations.
The ChangeUserRDN plug-in has the following configuration parameters:
Identifies the objectclass type that RDN renaming is performed on. The default setting is person.
True or False: Indicates whether or not the original RDN value (identified by the fromRDN
parameter) should be replaced by the new RDN value (identified by the toRDN
parameter). The default setting is true.
Identifies the original RDN attribute name from the source directory that will be replaced or renamed in Oracle Virtual Directory.
Identifies the new RDN attribute name that will be used in Oracle Virtual Directory and which replaces the attribute name identified by the fromRDN configuration parameter.
List of attributes with DNs to perform RDN renaming on. The default list of attributes is member, uniquemember, manager, owner, managedby.
The UPNBind plug-in allows you to bind using any configured username attribute, such as cn, SamAccountName, sn, uid, and so on, or username@suffix attributes, such as UserPrincipalName, Mail, and so on. This plug-in is useful for Active Directory-centric applications and can simplify application development by removing the requirement to look-up DNs.
Note: The UPNBind plug-in is supported only for deployment as a global plug-in—do not deploy the UPNBind plug-in on adapters. |
The UPNBind plug-in has the following configuration parameters:
Note: At a minimum, either the NameAttributes or NameAndSuffixAttributes configuration parameter must be set. |
Identifies a list of naming attributes to use for authenticating users. For example: cn, sn, uid, SAMAccountName.
A list of attributes in the form of name@suffix, such as UPN or mail, to use for authenticating users.
Determines how the UPNBind plug-in should process resulting entries when multiple users have same values for the NameAttributes and NameAndSuffixAttributes parameters. The following is a list and description of the supported values for the BindOption option. The default setting is QuickFail.
QuickFail: When multiple users have same values for configured attributes, the UPNBind plug-in displays a Found more than one user entry error and the LDAP bind fails.
FirstUser: The UPNBind plug-in binds as the first user and returns the result of that bind.
FirstSuccess: The UPNBind plug-in binds as the first user. If that bind fails, the UPNBind plug-in proceeds through the list of all users until it finds a successful bind.
Identifies the adapter to use for authentication. If the user entry is not present in the specified adapter, the LDAP bind fails with an Invalid Credentials message. This is an optional parameter. If you do not specify this parameter, the plug-in considers all the available adapters for authenticating the user. This parameter is useful for improving the plug-in's performance when you know which adapter is used for authentication.
Supported only for Join View Adapters, the ForkJoin plug-in allows you to search against the primary adapter and/or secondary adapters in a Join View. During LDAP search, when a search filter contains one or more attributes that are available only in secondary adapter, without this plug-in, Oracle Virtual Directory cannot return Joined entries that satisfies the filter, as the entire search filter is sent only to the primary adapter. Using the ForkJoin Plug-in, Oracle Virtual Directory can search on attributes only in the primary adapter, only in the secondary adapter, and in both the primary and secondary adapters.
For example, user data resides in multiple identity sources, with samaccountname, sn, givenname, employeenumber in Active Directory. However, the title attribute is stored in a Human Resources database. If Active Directory is configured as the primary adapter; Human Resources database as the secondary adapter; and if the ForkJoin plug-in is deployed, when an LDAP enabled application queries the user data based on samaccountname and/or title, Oracle Virtual Directory returns the entry that satisfies the filter and includes both Active Directory and the Human Resources database data.
The ForkJoin plug-in has the following configuration parameters:
Note: At a minimum, you must set either the SecondaryOnlyAttributes or PrimaryAndSecondaryAttributes configuration parameter to deploy the ForkJoin plug-in. |
A list of attributes that are present only in the secondary adapter and which the application can use in the search filter. The attributes identified by the SecondaryOnlyAttributes configuration parameter cannot also be identified by the PrimaryAndSecondaryAttributes configuration parameter.
A list of attributes that are present in both the primary and secondary adapters and which the application can use in the search filter. The attributes identified by the PrimaryAndSecondaryAttributes configuration parameter cannot also be identified by the SecondaryOnlyAttributes configuration parameter.
Supports the following settings:
Standard Join: Returns all entries that satisfy the search filter in the primary adapter after joining the corresponding entries in secondary adapters.
Left Outer Join: Returns all the entries in the primary adapter after joining with corresponding entries in secondary adapter (Standard Join), and returns entries from the secondary adapter that satisfy the join condition and which have a corresponding match in primary adapter. This is the equivalent to Left Outer Join in database terminology.
Full Outer Join: Returns all the entries in the primary adapter after joining with corresponding entries in secondary adapter (Standard Join); returns entries from the secondary adapter that satisfy the join condition and which have a corresponding match in primary adapter (Left Outer Join); and returns entries from the secondary adapter that satisfy the search filter but do not have a matching entry in primary adapter. This is the equivalent to Left Outer Join + Right Outer Join in database terminology.
Note: For conditional joins when Full Outer Join is configured, the entries in secondary adapter are mapped to entries in primary adapter without considering the filter in join condition. |
This section provides an example ForkJoin plug-in deployment. The following data resides in the primary adapter and secondary adapter. The primary adapter namespace is dc=primary and the secondary adapter namespace is dc=secondary.
Data in Primary Adapter | Data in Secondary Adapter |
---|---|
dn: cn=Rock, dc=primary objectclass: inetorgperson cn: Rock sn: Anne givenname: Anne rock telephonenumber: 54300 |
dn: cn=Rock, dc=secondary objectclass: inetorgperson cn: Rock sn: Anne title: Manager |
dn: cn=Sandy, dc=primary objectclass: inetorgperson cn: Sandy sn: Ketty manager: cn=Rock, dc=primary telephonenumber: 54301 |
dn: cn=Sandy, dc=secondary objectclass: inetorgperson cn: Sandy sn: Ketty title: SMTS |
dn: cn=Rivry,dc=primary objectclass: inetorgperson cn: Rivry sn: Rod title: Trainee manager: cn=Rock, dc=secondary telephonenumber: 54303 description: Trainee for dept 543 departmentNumber: 543 |
dn: cn=Rivry,dc=secondary objectclass: inetorgperson cn: Rivry sn: Rod title: Trainee |
dn: cn=Woods,dc=primary objectclass: inetorgperson cn: Woods sn: Tent description: User with no title |
dn: cn=Mounty,dc=secondary objectclass: inetorgperson cn: Mounty sn: Ret title: MTS - dept_sec |
The Join Condition is cn=cn
and the SecondaryOnlyAttributes parameter is set to title. An ldapsearch with a subtree scope and filter of (|(title=*e*)(sn=*e*))
is performed against the Join View Adapter.
The following are the search results for each type of JoinPolicy:
Standard Join:
cn=Rock,dc=Join sn=Anne cn=Rock title=Manager cn=Sandy,dc=Join sn=Ketty cn=Sandy title=SMTS cn=Woods,dc=Join sn=Tent cn=Woods
Left Outer Join:
cn=Rock,dc=Join sn=Anne cn=Rock title=Manager cn=Sandy,dc=Join sn=Ketty cn=Sandy title=SMTS cn=Woods,dc=Join sn=Tent cn=Woods cn=Rivry,dc=Join sn=Rod cn=Rivry title=Trainee
Full Outer Join:
cn=Rock,dc=Join sn=Anne cn=Rock title=Manager cn=Sandy,dc=Join sn=Ketty cn=Sandy title=SMTS cn=Woods,dc=Join sn=Tent cn=Woods cn=Rivry,dc=Join sn=Rod cn=Rivry title=Trainee cn=Mounty,dc=Join sn=Ret cn=Mounty title=MTS - dept_sec
The VirtualMemberof plug-in adds the memberof attribute to person entries. The values of this memberof attribute are the DNs of any groups the person entry belongs to. The VirtualMemberof plug-in is useful when applications want to see group membership, but do not want to perform a secondary search for the groups.
The VirtualMemberof plug-in has the following configuration parameters:
The DN of the base to search for groups containing person entries.
True or False: If set to True, the memberof attribute will be added to the entry only if it is explicitly requested as a returned attribute. The default value is True.
List of adapters containing group entries. This parameter helps minimize the scope of the search for groups.
The VirtualAttribute plug-in allows you to reuse attribute data in multiple attributes without deploying a mapping. For example, say a new application requires a person's full name to be used in their display, but instead of looking for cn, the application wants to use the displayname attribute—which does not exist in the adapter data. Using the VirtualAttribute plug-in, you can map displayname to the value of cn and have the cn attribute remain available for other applications that are looking for it. If the displayname attribute already exists in the adapter data, you can specify whether to add the values of cn to the existing values of displayname or to replace the values of displayname with the values of cn.
In addition to adding and replacing attribute values, the VirtualAttribute plug-in can also perform the functionality of ConditionalPublish mapping. That is, using the RemoveAttributes configuration parameter, you can identify attributes to virtually remove from entries before they are returned to the client.
Note: Constant values can be specified for the attributes that are added or replaced by the VirtualAttribute plug-in. |
The VirtualAttribute plug-in has the following configuration parameters:
Note: At a minimum, you must set either the AddAttribute or ReplaceAttribute configuration parameter. |
An optional parameter, ContainerDN identifies the containers the VirtualAttribute plug-in applies to. The VirtualAttribute plug-in is applicable for all entries under the containerDN which match the filter specified by the matchFilter parameter. This parameter can be repeated to specify multiple containerDNs. This parameter also restricts the VirtualAttribute plug-in to a certain branch within data exposed by the adapter. The default setting is "", or DSE—that is, if you do not set the ContainerDN parameter, the VirtualAttribute plug-in searches the entire directory tree.
An optional parameter, MatchFilter identifies the entries the VirtualAttribute plug-in applies to. The VirtualAttribute plug-in is applicable for all entries under containerDN that match the filter specified by the MatchFilter parameter. If you do not set the MatchFilter parameter, the VirtualAttribute plug-in is applicable for all the entries under the DNs identified by ContainerDN parameter.
A list of attributes to add to the entry and a value to assign to these virtual attributes. If an attribute identified by the AddAttribute parameter already exists in the entry, the VirtualAttribute plug-in appends the specified values to the existing set of values. The value can be either a constant or another attribute value.
You can set the AddAttribute parameter multiple times for the VirtualAttribute plug-in. The value you set for the AddAttribute parameter must be mutually exclusive, that is, different, from the ReplaceAttribute.
For example:
To add the values of the cn attribute to uid and displayName, set the value of the AddAttribute parameter to: uid=displayName=%cn%
To add the constant value Acme to the companyName attribute, set the value for AddAttribute parameter to: companyName=Acme
A list of attributes to add to the entry and a value to assign to these virtual attributes. If an attribute identified by the ReplaceAttribute parameter already exists in the entry, the VirtualAttribute plug-in replaces them using the value you supply. The value can be either a constant or another attribute value.
You can set the ReplaceAttribute parameter multiple times for the VirtualAttribute plug-in. The value you set for the ReplaceAttribute parameter must be mutually exclusive, that is, different, from the AddAttribute.
For example:
To replace the values of uid and displayName with the values of the cn attribute, the ReplaceAttribute parameter can be configured as: uid=displayName=%cn%
To replace the value of the companyName attribute with the constant value Acme, the ReplaceAttribute parameter can be configured as: companyName=Acme
Comma-separated list of attributes to virtually remove from entries that satisfy the MatchFilter under the specified ContainerDN.
This section provides an example VirtualAttribute plug-in deployment. Assume the following VirtualAttribute plug-in configuration parameters are set:
Configuration Parameter | Value |
---|---|
AddAttribute | uid=displayName=%cn% |
AddAttribute | certificate=Verisign |
ReplaceAttribute | title=%designation% |
RemoveAttributes | designation,uid |
Assume the original entry to be processed is:
dn: cn=john, dc=com cn: john cn: jsmith uid: 1234 certificate: selfsigned designation: SMTS title: Senior Software Engineer sn: smith objectclass: person objectclass: top
The following shows how the VirtualAttribute plug-in transforms the original entry:
After processing the AddAttributes configuration parameter, the entry is:
dn: cn=john, dc=com cn: john cn: jsmith uid: 1234 uid: john uid: jsmith displayName: john displayName: jsmith certificate: verisign certificate: selfsigned designation: SMTS title: Senior Software Engineer sn: smith objectclass: person objectclass: top
After processing the ReplaceAttributes configuration parameter, the entry is:
dn: cn=john, dc=com cn: john cn: jsmith uid: 1234 uid: john uid: jsmith displayName: john displayName: jsmith certificate: verisign certificate: selfsigned designation: SMTS title: SMTS sn: smith objectclass: person objectclass: top
After processing the RemoveAttributes configuration parameter, the entry is:
dn: cn=john, dc=com cn: john cn: jsmith displayName: john displayName: jsmith certificate: verisign certificate: selfsigned title: SMTS sn: smith objectclass: person objectclass: top
The Dump Transactions plug-in generates a record of all transactions for each LDAP operation and logs the record to the Oracle Virtual Directory console log. You can configure the Dump Transactions plug-in to run on any log level. The Dump Transactions plug-in is particularly useful for diagnosing mapping and integration efforts while logic flows through the Oracle Virtual Directory system. You can use the Dump Transaction plug-in to analyze issues on a specific adapter without setting the entire server log level to a more verbose level. Think of the Dump Transactions plug-in as a protocol analyzer for Oracle Virtual Directory.
The DynamicTree plug-in allows you to construct DNs in Oracle Virtual Directory using the attribute values of source directory entries that have parent entries which are real, virtual, or pointers to different real entries.
Note: The DynamicTree plug-in is supported only for deployment on adapters—do not deploy the DynamicTree plug-in as a global plug-in. |
This plug-in is useful for generating organization charts and reports in LDAP hierarchy format based on structural data contained in the source directory entry. The Dynamic Tree plug-in provides more flexibility than the DynamicEntry Tree plug-in because it allows you to browse the directory tree.
Consider the following figures and examples.
Note: In the following graphics, attribute values in the source directory appear in bold type. |
Figure 4-2 shows an example directory structure residing in the source directory:
Figure 4-3 shows an example of how the DynamicTree plug-in, with the parentEntryType parameter set to 1 and the attributeName parameter set to parentou, transforms the source directory's flat hierarchy shown in Figure 4-2 into a layered hierarchy in Oracle Virtual Directory.
Figure 4-4 shows another example directory structure residing in the source directory:
Figure 4-5 shows an example of how the DynamicTree plug-in, with the parentEntryType parameter set to 0 and the attributeName parameter set to l, creates a layered hierarchy in Oracle Virtual Directory based on the l attribute value in the source directory shown in Figure 4-4.
The DynamicTree plug-in has the following configuration parameter:
The attribute used to identify the entry's parent entry.
Identifies the type of parent entry. Supported values are 0 and 1. Select 0 for virtual parent entries, which are entries that Oracle Virtual Directory creates based on attribute values in the source directory. Select 1 for parent entries created by multiple ou containers.
The DynamicEntryTree is a general purpose plug-in that can be used to generate virtual directory tree hierarchy by using attributes found in entry leaf nodes. For example, if an adapter has a root of o=Airius.com and users are present as uid=scarter,ou=people,o=airius.com, the DynamicEntryTree plug-in can insert new hierarchy using data present in the entry of the user, such as: uid=scarter,ou=accounting,ou=people,o=airius.com.
The DynamicEntryTree plug-in has the following configuration parameter:
The DynamicEntryTree plug-in is configured by specifying matching patterns using the patterns configuration parameter. The syntax for the patterns parameter value is
attr[=entryattr[(SUPPRESS|value)]],...
For each DN component, an attribute name can have a value substituted with the attribute on the right side of the equals sign (=). If no substitution is required, then just the attribute is listed, which essentially refers to a matching component with the original DN. When a value is substituted, you can also further qualify what happens when entryattr has no value. You may either specify SUPPRESS to suppress the entry completely, or you may specify a default value within brackets after the entryattr name.
Multiple patterns can be defined by separating them with a |
. For example:
uid,ou=department(contract),ou|cn,ou=code(SUPPRESS)
This rule has two patterns. One pattern matches objects under the adapter root (o=airius.com) that have dn components matching uid,ou. Therefore, uid=scarter,ou=people,o=airius.com would be selected for mapping. Upon return, the department attribute would be checked for values. If none are present, the static text contract
is substituted. On a search, if base is set to uid=scarter,ou=accounting,ou=people,o=airius.com, the search will be modified so that the new base is uid=scarter,ou=people,o=airius.com and the filter will be modified with an additional anded term of ou=accounting.
The second pattern is intended to match child objects of o=airius.com that have a cn rdn component. When matched, if the entry has an attribute code, its value is substituted by creating cn=mygroup,ou=code12,o=airius.com. If the attribute code
is not present, the entry result will be suppressed due to the SUPPRESS keyword.
The FlatTree plug-in, as with the DynamicEntryTree, performs dynamic mapping of the virtual directory tree. The FlatTree plug-in compresses a directory source so that all entries appear directly under the root of the adapter.
FlatTree plug-in operates in two deployed modes:
as part of any existing adapter to flatten the existing namespace
as part of a Custom Adapter deployment
As part of a Custom Adapter deployment, you can use the FlatTree plug-in's adapter parameter to retrieve data from the designated adapter so that the data appears as part of the namespace of the Custom Adapter. When deployed this way, the adapter root object is not defined. This type of deployment can be useful if you want to overlay multiple adapters on top of a parent adapter without creating duplicate parent nodes.
The following is a list and description of the FlatTree plug-in configuration parameters:
Criteria defines an LDAP filter that restricts the entries that can be searched for through the FlatTree plug-in. For example, if criteria was set to objectclass=user, then only user objects would be returned through the FlatTree plug-in.
If the adapter parameter is not defined, the FlatTree plug-in assumes data will be retrieved through its parent adapter. When defined, the adapter parameter must be the name of another adapter in the Oracle Virtual Directory configuration and the FlatTree plug-in retrieves data from this adapter and maps the entries to its parent adapter's root. If the adapter parameter is defined the root object is not returned—only the child entries are returned.
The DynamicGroups plug-in enables Oracle Virtual Directory to process LDAP objectclasses that are both groupofuniquenames
and groupofurls
(referred to as a "dynamic group") and convert it into a virtual static group, or groupofuniquenames equivalent. The plug-in works by monitoring returned LDAP objects and detects objects where the memberurl attribute is present and the objectclass is both groupofuniquenames and groupofurls.
When detected, the plug-in automatically processes any memberurl values and adds the results to the uniquemember attribute. This dynamic object processing allows administrators to define groups that hold both static members and dynamic members while maintaining compatibility with applications that may not normally support the groupofurls objectclass.
Example 4-1 shows an example query when the Dynamic Groups plug-in is not enabled. Two groups are returned and the first group holds two static members and has a memberurl defining a particular directory subtree to also be members.
Example 4-1 Example Query When Dynamic Groups Plug-in Not Enabled
C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(memberurl=*)"
cn=test,ou=groups,ou=airius,o=yourcompany.com
cn=test
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(objectclass=person)(obj
ectclass=organizationalperson))
objectclass=groupofuniquenames
objectclass=groupofurls
objectclass=top
uniquemember=cn=Paul Jacobs,ou=People,ou=Airius,o=yourcompany.com
uniquemember=cn=Wendy Verbaas,ou=People,ou=Airius,o=YourCompany.com
cn=TestCheck,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=alt bind,o=yourcompany.com??sub?(&(userprincipalname=*))
objectclass=groupofuniquenames
objectclass=groupofurls
cn=TestCheck
Example 4-2 shows the results of the same query as in Example 4-1, however, the Dynamic Groups plug-in is enabled:
Example 4-2 Example Query When Dynamic Groups Plug-in is Enabled
C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(cn=test)"
cn=test,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(objectclass=person)(obj
ectclass=organizationalperson))
objectclass=groupofuniquenames
objectclass=groupofurls
objectclass=top
cn=test
uniquemember=cn=Paul Jacobs,ou=People,ou=Airius,o=yourcompany.com
uniquemember=cn=Wendy Verbaas,ou=People,ou=Airius,o=YourCompany.com
uniquemember=cn=Vipi Velasquez,ou=accounting,o=yourcompany.com
uniquemember=cn=Preston Pena-Fernandez,ou=accounting,o=yourcompany.com
uniquemember=cn=Andreas O'Hara,ou=accounting,o=yourcompany.com
uniquemember=cn=Chitra Guenette,ou=accounting,o=yourcompany.com
...
uniquemember=cn=Jim Ward,ou=accounting,o=yourcompany.com
Products such as policy servers often need to check whether a particular person is a member of a group, which can be a significant task if a group is very large or if the group is a dynamic group. However, the Dynamic Groups plug-in detects a membership test query by detecting the presence of both cn and uniquemember filter terms. When present, the Dynamic Groups plug-in processes the query differently by recognizing that the client wants to test a membership assertion. The plug-in modifies the results and returns only the single user being tested as the member, as shown in Example 4-3:
Example 4-3 Example Membership Test with the Dynamic Groups Plug-in
C:\>ldapsearch -D bindDN -q -b ou=groups,ou=airius,o=yourcompany.com -s
sub "(&(cn=TestCheck)(uniquemember=cn=Jim Ward,ou=accounting,o=yourcompany.com))"
cn=TestCheck,ou=groups,ou=airius,o=yourcompany.com
memberurl=ldap:///ou=accounting,o=yourcompany.com??sub?(&(userprincipalname=*))
objectclass=groupofuniquenames
objectclass=groupofurls
cn=TestCheck
uniquemember=cn=Jim Ward,ou=Accounting,o=YourCompany.com
The Cache plug-in provides a true cache for Oracle Virtual Directory—it is an in-memory copy of a LDAP search result set and is designed to improve the performance of repeated queries. For example, imagine a 3rd party portal server as part of a daily synchronization process that queries for all of the groups in the enterprise LDAP server (that is, Oracle Virtual Directory) three consecutive times. The cache plug-in can keep a copy of the result of the first search for re-use by LDAP clients. While it did result in a slightly faster result to the client application—more importantly it reduced the load of the enterprise source systems.
Oracle Virtual Directory is designed to function without the Cache plug-in and in many cases it is not necessary because many applications either cache results on their own, or because most enterprise source systems already cache data. Also, because Oracle Virtual Directory is often used in secure environments, keeping a cache exposes security elements, such as if an employee is terminated and their user result is still in the cache.
Note: If you use the Cache plug-in, the cache timeout should be kept small to avoid cache update problems in cases such as these. |
The Cache plug-in can greatly improve performance for applications where queries are highly repetitive and can be configured to run any where within Oracle Virtual Directory. The Cache plug-in can be executed globally or within the context of a single adapter, and can also be restricted to specific namespaces using namespace filtering.
If a query is repeated by the same user and the same attributes or a subset of attributes are requested, the cache will return its results instead Oracle Virtual Directory retrieving the information from the source. For example, consider the following two theoretical queries where the client changes the search attributes in Query 2:
Query 1
Bind as: "cn=Example User,cn=users,dc=mycompany,dc=com"
Base of: "dc=mycompany,dc=com"
Query of: "uid=jdoe"
Attributes: "cn,mail"
Query 2
Bind as: "cn=Example User,cn=users,dc=mycompany,dc=com"
Base of: "dc=mycompany,dc=com"
Query of: "uid=jdoe"
Attributes: "telephonenumber,manager"
By using the Cache plug-in, Oracle Virtual Directory does not treat Query 1 and Query 2 as two separate queries and does not search the back-end source twice. Oracle Virtual Directory requests all the attributes for matching entries in Query 1, but only returns the attributes requested by the client and keeps an in-memory copy of the search results in its cache.
Note: Oracle Virtual Directory retrieves only the attributes which the bound user has access to based on the back-end source repository Access Control Lists (ACLs), Oracle Virtual Directory ACLs, and adapter routing rules. |
The Cache plug-in can also be configured to allow cache hits to be shared between users. Sharing cache entries between users should not be used unless passcredentials
is not being passed to back-end sources and Oracle Virtual Directory is solely responsible for security enforcement.
Note: Careful planning should take place when sharing cache hits between users as it may then be possible for one user to see something they should not, since they may have access to a cache result from a more privileged user. |
The Cache plug-in periodically reviews the cache and checks for any expired results or entries that have been invalidated by a previous modify transaction. If the cache quota is exceeded, the Cache plug-in attempts to trim memory by purging the queries that were least recently used.
The following is a list and description of the Cache plug-in configuration parameters:
Controls whether or not the Cache plug-in silently requests all attributes. Supported values are 0 (disable) or 1 (enable). By default, the storeallattrs parameter is disabled (0).
Indicates whether or not cache results are shared between subjects. Supported values are 0 or 1. A value of 0 indicates results will be shared between subjects and a value of 1 indicates that results will not be shared between subjects. The default value is 1.
The amount of time (in seconds) between when the cache manager checks for expired queries. The default value is 60.
The maximum number of entries that may be cached at any one time. The default value is 10000.
The maximum age (or time), in seconds, that any query/entry can be stored in the cache. The default value is 600.
The maximum number of entries that may be cached for any particular query. The default setting is 1000.
When the maximum cache size is exceeded, this parameter indicates the amount by which the cache manager must reduce the balance. The default value is 10000.
Note: When necessary, trimming is done by purging expired queries first followed by queries in order of least recent use. |
Indicates whether or not to cache query results containing zero entries. Supported values are 0 and 1.
The ObjectClass Mapper plug-in is a general mapping plug-in that can make one objectClass, such as user, appear like another objectClass, such as inetOrgPerson. This ability is useful when an application is expecting a particular objectClass and attributes but the directory does not support that objectClass or attributes.
The ObjectClass Mapper plug-in can perform several different types of manipulation based on configuration parameters you select, including:
attribute mapping
objectclass mapping
adding attributes conditional on objectclass
removing attributes
filtering auxiliary classes
handling activation and deactivation
Where attribute mapping relationships occur, the prefix client-
indicates client side and source-
indicates data source side. For example, mapping Active Directory server user
to represent it as InetOrgPerson
would imply that Active Directory is the source side and InetOrgPerson
is the client side.
The following is a list and description of the ObjectClass Mapper plug-in configuration parameters:
The directory type to use when performing user activation. Supported values are SunOne, eDirectory, ADAM, and ActiveDirectory. For example:
Parameter Name: directoryType
Parameter Value: ActiveDirectory
Use the activationAttribute parameter when an application has no knowledge of the underlying directory's user activation system. The activationAttribute parameter informs Oracle Virtual Directory which incoming attribute contains the user activation flag, which is then mapped to a directory specific attribute and flag. For example:
Parameter Name: activationAttribute
Parameter Value: myuseraccountcontrol
Comma separated list of attribute values specified in activationAttribute
that indicate this user should be marked as inactive.
Comma separated list of attribute values specified in activationAttribute
that indicate this user should be marked as active.
An objectClass to be mapped in the form of client-ObjectClass=source-ObejctClass
. For example:
Parameter Name: mapObjectClass
Parameter Value: inetOrgPerson=user
You can use the mapObjectClass parameter multiple times for multiple mappings.
Adds attributes for a user during the add process. An optional objectclass value may be added to the configuration name to add the attribute only for certain objectclasses. For example, to add a userAccountControl attribute to only the user objectclass, use:
Parameter Name: addAttribute-user
Parameter Value: userAccountControl=546
Note: An attribute value may be referenced on the value side of the expression by supplying the attribute name surrounded by the percentage character (% ). For example:
Parameter Name: addAttribute-group Parameter Value: samaccountname=%cn% |
Comma-separated list of attributes that will be removed during the add operation and from all returned entries. A conditional objectclass value may be added to the name of the parameter to filter out attributes for a specific objectclass. For example:
Parameter Name: filterAttribute
Parameter Value: objectsid,memberof,samaccountname
An attribute to be mapped in the form of client-Attribute=source-attribute
. For example:
Parameter Name: mapAttribute
Parameter Value: uniqueMember=member
You can use the mapAttribute parameter multiple times for multiple mappings.
Comma separated list of objectclasses that must be removed on an add operation. An example is Microsoft Active Directory for Windows 2000 does not allow auxiliary object classes to be listed while adding an entry, while Microsoft Active Directory and ADAM for Windows Server 2003 does allow for auxiliary classes to be listed. For example:
Parameter Name: filterAuxiliaryClass
Parameter Value: person,myorgPerson
Comma-separated list of attributes that will be removed during the modify operation for a specific objectclass. For example:
Parameter Name: filterObjectClassOnModify
Parameter Value: objectsid,memberof,samaccountname
The Sub-Tree plug-in was originally developed to support early versions of IBM's Tivoli Access Manager product, which had a requirement where it stored policy information about a person's entry under the person's entry, thereby changing the person entry from its typical leaf model to be a branch. Some directories did not support such a model or did not want to populate their enterprise directory this way.
The Sub-Tree plug-in allows you to store these sub-tree entries in a different adapter while presenting the expected directory tree view to the application—in this case Tivoli Access Manager. The requirement to add entries under a normal leaf entry is uncommon. The more common case is to make a data-store appear as a branch under an existing data-store and any adapter can perform this by properly setting its root namespace value.
The following is a list and description of the Sub-Tree plug-in configuration parameters:
The adapter to store the user subtree objects in.
The location in the store adapter where you want to store the user subtree objects.
Identifies the subtree distinguished name (DN) component that the Sub-Tree plug-in should intercept and redirect to the store adapter. The default value is secAuthority=Default.
Numbered parameters that specify distinguished names (DN) under which user objects are found and the user object RDN. For example: 0=ou=People,o=Airius.com\:uid
The Performance Monitor plug-in allows you to monitor the performance of a specific adapter. To use the Performance Monitor plug-in, attach it to an adapter and then perform operations against that adapter. To view the adapter performance, you must perform a specific type of base level LDAP search on the adapter's root namespace with a filter of vdeSearchtime=*
.
The search will return results similar to Example 4-4, where all time measurements are in milliseconds:
Example 4-4 Example of Data Returned with the Performance Monitor Plug-In
dn: dc=demo,dc=com vdeNumSearches: 4 vdeNumEntries: 5 vdeMinSearchTime: 0 vdeMaxSearchTime: 16 vdeTotalSearchTime: 16 vdeAverageSearchTime: 4 vdeMinEntryTime: 0 vdeMaxEntryTime: 0 vdeTotalEntryTime: 0 vdeAverageEntryTime: 0 vdeMinSearchCompleteTime: 0 vdeMaxSearchCompleteTime: 203 vdeTotalSearchCompletionTime: 219 vdeAverageSearchCompletionTime: 54
Note: The Performance Monitor data is reset after the Oracle Virtual Directory server restarts. |
In some Oracle Virtual Directory environments users have duplicate accounts for more than one service they connect to using Oracle Virtual Directory adapters. Typically, building a Join View Adapter to unify multiple adapters and create a single virtual user entry would resolve this problem. However, there are circumstances where building a Join View Adapter is not an option. For example, there might be a directory for staff personnel and a directory for customers, but certain staff members have accounts in both directories for legitimate business purposes and you cannot create a Join View Adapter.
The UniqueEntry plug-in solves this problem by enabling you to rank various adapters by their authoritative source. For example, if you are attempting to determine which of the duplicate user identities is a staff account, then the staff directory is more relevant than the customer directory and you would place a higher priority on the staff directory adapter than the customer directory adapter.
When ranking adapter priorities, the lower the value of the numerical ranking is, the higher priority. For example, if you are searching two adapters and one adapter has a priority ranking of five and the other adapter has a priority ranking of ten, the adapter with the priority ranking of five is searched first, before the adapter with the priority ranking of ten.
Note: Do not apply the UniqueEntry plug-in at the adapter level—it should always be applied only as a Global plug-in. |
Do not deploy the Adapter Plug-in Version plug-in—it is for information only and has no server functionality. It provides the adapter version information that appears on the Oracle Directory Services Manager home page.
Oracle Virtual Directory includes plug-ins to simplify the integration with Enterprise User Security (EUS) and Oracle Net Services. This topic describes the plug-ins related to these integrations and contains the following sections:
Use the EUSActiveDirectory plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product and your user identities are stored in Microsoft Active Directory. The EUSActiveDirectory plug-in translates Active Directory attributes to a format that can be used by the Enterprise User Security database.
Use the EUSiPlanet plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product and your user identities are stored in Sun Java System Directory Server. The EUSiPlanet plug-in translates Sun Java System Directory Server attributes to a format that can be used by the Enterprise User Security database.
Use the EUSOID plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product and your user identities are stored in Oracle Internet Directory. The EUSOID plug-in translates Oracle Internet Directory attributes to a format that can be used by the Enterprise User Security database.
Use the EUSeDirectory plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product and your user identities are stored in Novell eDirectory. The EUSeDirectory plug-in translates Novell eDirectory attributes to a format that can be used by the Enterprise User Security database.
Use the EUSMemberDNMapping plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product. The EUSMemberDNMapping plug-in translates the distinguished name (DN) namespace for the Enterprise User Security database administrators group stored in an external repository to the same payload that Oracle Virtual Directory sends to the database.
The following is a list and description of the EUSMemberDNMapping plug-in configuration parameters:
The base DN in the remote external repository (Active Directory, Oracle Internet Directory, Sun Java System Directory Server) where the Enterprise User Security database administrators group is located.
The base DN of the name of the group that Oracle Virtual Directory exposes.
Note: Typically, the values for the remoteDomainDN and localDomainDn configuration parameters are identical. |
Use the EUSLockout plug-in only when integrating Oracle Virtual Directory with Oracle's Enterprise User Security database product. LDAP servers have the ability to lock a user account after several bind attempts fail. The EUSLockout plug-in allows the Oracle Virtual Directory-Enterprise User Security integration to utilize this lockout feature and enforce the back-end LDAP server's password lockout policy as follows:
An incorrect login to the Oracle Database records a login failure to the back-end LDAP server
A correct login to the Oracle Database resets the login failure count in the back-end LDAP server
Note: This functionality is not available for integrations that use Active Directory. |
A locked user account cannot be used to log in to the Oracle Database.
When you configure the EUSLockout plug-in, you must:
Create a directoryType parameter with a value according to your back-end LDAP server, such as ActiveDirectory for Active Directory, iPlanet for Sun Java System Directory Server, or eDirectory for Novell eDirectory.
Create a namespace using the name of your Oracle Virtual Directory-Enterprise User Security integration user container.
The following is a list and description of the EUSLockout plug-in configuration parameters:
The type of back-end directory server in the Oracle Virtual Directory-Enterprise User Security integration where the user identities are stored. Supported values are ActiveDirectory for Active Directory, iPlanet for Sun Java System Directory Server, or eDirectory for Novell eDirectory.
The Onames plug-in is used only when integrating Oracle Virtual Directory with Oracle Net Services. The plug-in removes entries that are specific to the source LDAP directory to facilitate the Oracle Virtual Directory-Oracle Net Services integration.
When Oracle database queries Oracle Virtual Directory in Enterprise User Security and Oracle Net Services integrations it expects LDAP schema to be in the same name as Oracle Internet Directory. However, Oracle Internet Directory and Oracle Virtual Directory store the LDAP schema differently. The SubschemaSubentry plug-in transparently redirects the Oracle database queries to allow Oracle Virtual Directory-Enterprise User Security or Oracle Virtual Directory-Oracle Net Services integrations to function.
Microsoft Active Directory has several features that many applications do not know how to handle. Oracle Virtual Directory includes multiple plug-ins to allow applications to use these unique features without affecting, recoding, or reconfiguring the application.
This topic describes the Microsoft Active Directory and Active Directory Application Mode (ADAM) plug-ins included in Oracle Virtual Directory and contains the following sections:
Active Directory and ADAM have special rules about how the password of a user may be updated by using LDAP, including:
Passwords may only be updated via secure SSL connection
If a user is updating their own password, the original password must be included in a modify delete with the new password being a modify add in the same modify operation.
Only an administrator may reset the password of a user without knowing the previous password.
Active Directory does not use the userPassword attribute—it uses the unciodePwd attribute which is in Unicode format.
The ActiveDirectory Password plug-in helps administrators with the Active Directory's password update rules when an application is not designed to use them and it is not advantageous to connect to Active Directory or ADAM via SSL for all operations. By configuring the ActiveDirectory Password plug-in on a non-SSL enabled adapter and pointing the plug-in to an SSL-enabled adapter, this plug-in allows a password update on Active Directory to work as a password update on an inetOrgPerson directory would.
Important: The ActiveDirectory plug-in must be configured only on an LDAP Adapter, typically against Microsoft Active Directory. |
The ActiveDirectory Password plug-in has the following configuration parameter:
The name of the adapter the ActiveDirectory Password plug-in will reroute requests to if they contain a userPassword attribute. The adapter identified must have its virtual root be the same as the current adapter and its Routing Visibility setting must be set as Internal. If the adapter parameter is not defined, the current adapter is used.
Indicates whether the password must be converted to the unicodePwd attribute (true), or not (false). Supported values are true or false. The default value is true.
Attributes in Active Directory and ADAM with more then 1000 values are returned 1000 at a time with a name that includes the range of values that were returned (or 1500 for Windows 2003). The range is returned to the client in the following format:
member;1-1000: somevalue
To get the next thousand entries, the client application must know to repeat the query and request the attribute member;1001-2000. This requires applications to handle Active Directory in a unique method when compared to other directory products.
The Active Directory Ranged Attributes plug-in detects attributes that Active Directory or ADAM has "ranged" and automatically retrieves all values. If the Active Directory Ranged Attributes plug-in is not enabled, the LDAP adapter's dn-attribute configuration option is not applied because the range of values are appended to the attribute name.
Important: The Active Directory Ranged Attributes plug-in determines what attributes on an adapter are marked as dn-attributes and performs the appropriate base mapping. You can only use the Active Directory Ranged Attributes plug-in as an adapter plug-in on an LDAP adapter. |
The InetAD plug-in combines the functionality of the ObjectClass Mapper Plug-In, Active Directory Ranged Attributes Plug-In, and ActiveDirectory Password Plug-In to allow one single plug-in to be configured to handle multiple unique Active Directory features.
The InetAD plug-in utilizes the ObjectClass Mapping plug-in because most LDAP directories use the inetOrgPerson and groupOfUniqueNames object classes for users and groups, while Active Directory uses the user and group objectClasses with attributes specific to Active Directory's NOS requirements.
The InetAD plug-in allows Oracle Virtual Directory to make an Active Directory or ADAM directory server appear to have inetOrgPerson schema. Based on the parameter configuration, the InetAD plug-in can rename attributes and object classes and add attributes for a user in Active Directory to have all needed attributes. If no configuration parameters are used, the InetAd plug-in makes an Active Directory user or group appear to be an inetOrgPerson or groupOfUniqueNames object class.
Note: Where attribute mapping relationships occur, theclient- prefix indicates client side and the source- prefix indicates data source side. For example, mapping Active Directory server user to represent it as InetOrgPerson would imply Active Directory is the source side and InetOrgPerson is the client side. |
The following is a list and description of the InetAD plug-in configuration parameters:
The directory type to use when performing user activation. Supported values are SunOne, eDirectory, ADAM, and ActiveDirectory. For example:
Parameter Name: directoryType
Parameter Value: ActiveDirectory
Use the activationAttribute parameter when an application has no knowledge of the underlying directory's user activation system. The activationAttribute parameter informs Oracle Virtual Directory which incoming attribute contains the user activation flag, which is then mapped to a directory specific attribute and flag. For example:
Parameter Name: activationAttribute
Parameter Value: myuseraccountcontrol
Comma separated list of attribute values specified in activationAttribute
that indicate this user should be marked as inactive.
Comma separated list of attribute values specified in activationAttribute
that indicate this user should be marked as active.
An objectClass to be mapped in the form of client-ObjectClass = AD-ObejctClass
. For example:
Parameter Name: mapObjectClass
Parameter Value: inetOrgPerson=user
You can use the mapObjectClass parameter multiple times for multiple mappings. The default values are groupOfUniqueNames=group, inetOrgPerson=user.
Adds attributes for a user during the add process. An optional objectclass value may be added to the configuration name to add the attribute only for certain objectclasses. For example, to add a userAccountControl attribute to only the user objectclass, use:
Parameter Name: addAttribute-user
Parameter Value: userAccountControl=546
Note: An additional attribute value may be substituted as an expression by supplying its name surrounded by the percentage character (%). The default configuration is:addAttribute-user: useraccountcontrol=544, addAttribute-group:samaccountname=%cn%, addAttribute-group: grouptype=-2147483646 |
Comma-separated list of attributes that will be removed during the add operation and from all returned entries. A conditional objectclass value may be added to the name of the parameter to filter out attributes for a specific objectclass. For example:
Parameter Name: filterAttribute
Parameter Value: objectsid,memberof,samaccountname
An attribute to be mapped in the form of client-Attribute=AD-attribute
. For example:
Parameter Name: mapAttribute
Parameter Value: uniqueMember=member
You can use the mapAttribute parameter multiple times for multiple mappings. The default values are "uniqueMember=member", "uid=samaccountname", "ntgrouptype=grouptype".
Comma separated list of objectclasses that must be removed on an add operation. Active Directory for Windows 2000 does not allow auxiliary object classes to be listed while adding an entry, while Microsoft Active Directory and ADAM for Windows Server 2003 does allow for auxiliary classes to be listed. The default value is person, organizationalPerson.
Comma-separated list of attributes that will be removed during the modify operation for a specific objectclass. For example:
Parameter Name: filterObjectClassOnModify
Parameter Value: objectsid,memberof,samaccountname
Indicates whether the password must be converted to the unicodePwd attribute (true), or false if not (ADAM). Supported values are true or false. The default value is true.
The name of the adapter this plug-in will reroute requests to if they contain userPassword
. The current adapter is used if the sslAdapter parameter is not set. The adapter identified by the sslAdapter parameter must have:
The same local base as the adapter the InetAD plug-in is configured on
Its Routing Visibility set to Internal
This topic describes the plug-ins designed for use when Oracle Virtual Directory is a connector target for Oracle Identity Manager integrations. This topic contains the following sections:
Note: Some of the UserManagement and Changelog plug-in configuration parameters must have identical values. |
The UserManagement plug-in provides data mapping for Oracle Identity Manager attributes, in particular, attributes needed by Oracle Fusion Applications, to LDAP directory servers.
The UserManagement plug-in has the following configuration parameters:
Comma separated list of language codes to be used in attribute language subtypes. This parameter is functional only when the directoryType parameter is set to ActiveDirectory.
True or False: Indicates whether or not Oracle Access Manager is deployed with Oracle Identity Manager. By default, Oracle Access Manager is not deployed, therefore the default setting for this parameter is false.
Note: The oamEnabled parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
Identifies the type of source LDAP directory server. Supported values are OID, ActiveDirectory, and SunOne. The default value is OID.
Note: The directoryType parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
The ssladapter parameter, which is operational only when the directoryType parameter is set to ActiveDirectory, identifies the name of the adapter the UserManagement plug-in will route requests to when userPassword
or unicodePwd
is contained in requests. If unicodePwd
is contained in the request, the request must also contain the useraccountControl attribute with a proper value.
The adapter identified by the ssladapter parameter must have:
The same local base as the adapter the UserManagement plug-in is configured on
Its Routing Visibility set to Internal
If no value is set for ssladapter, the current adapter is used by default.
Defines the attribute translation in the form of OVD-attribute=OIM-attribute, for example: orclGUID=objectGuid. You can set the mapAttribute configuration parameter multiple times to define translations for multiple attributes.
True or False. When the directoryType configuration parameter is set to ActiveDirectory, the mapPassword parameter controls whether or not to convert the user password to the unicodePwd attribute. The default value is false.
Defines the RDN attribute translation in the form of OVD-RDNattribute=OIM-RDNattribute, for example: uid=cn.
Identifies the maximum number of failed logins the source LDAP directory server requires to lock an account (as defined by the password policy effective on the user entries being exposed through the adapter on which this plug-in is deployed).
Defines the objectclass value translation in the form of OVD-objectclass=OIM-objectclass, for example: inetorgperson=user. You can set the mapObjectclass configuration parameter multiple times to define translations for multiple objectclasses.
Note: The mapObjectclass parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
In the form of attribute=value pairs, this parameter identifies attributes to be added before returning the get operation result. You can prefix the attribute name with objectclass,
to add the attribute and value to a specific objectclass. You can also surround a value with %
to reference other attributes. For example, specifying the value user,samaccountname=%cn%
assigns the value of cn to samaccountname when the entry objectclass=user. Specifying the value samaccountname=jdoe
adds attribute samaccountname with value jdoe to all the entries.
Oracle Virtual Directory provides the following changelog plug-ins to standardize changelog information from source directories into a suitable format for Oracle Identity Manager:
oidchangelog for use with Oracle Internet Directory
sunonechangelog for use with Sun Java System Directory Server.
adchangelog for use with Microsoft Active Directory
When deploying the sunonechangelog plug-in, you must:
Ensure change logging is enabled on the Sun Java System Directory Server.
Set both the adapter's Remote Base and Mapped Namespace to: cn=changelog
When deploying the adchangelog plug-in, you must:
Set the adapter's Remote Base to an empty value, that is, blank, nothing.
Set the adapter's Mapped Namesapce to: cn=changelog
Each of the changelog plug-ins have the following configuration parameters:
True or False: Indicates whether or not Oracle Access Manager is deployed with Oracle Identity Manager. By default, Oracle Access Manager is not deployed, therefore the default setting for this parameter is false.
Note: The oamEnabled parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
Identifies the type of source LDAP directory server. Supported values are OID, ActiveDirectory, and SunOne. The default value is OID.
Note: The directoryType parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
Defines the objectclass value translation in the form of Source-Directory-objectclass=OIM-objectclass, for example: inetorgperson=user. You can set the mapObjectclass configuration parameter multiple times to define translations for multiple objectclasses.
Note: The mapObjectclass parameter for the UserManagement plug-in and the changelog plug-in must have identical values. |
Identifies the maximum number of changelog entries to be returned with search filter of changenumber >=
integer
or changenumber <=
integer
. This parameter does not support changelog queries with complex filters using AND
| OR
of two or more filters.
Defines the attribute translation in the form of Source-Directory-attribute=OIM-attribute, for example: orclGUID=objectGuid. You can set the mapAttribute configuration parameter multiple times to define translations for multiple attributes.
Identifies the container to retrieve changes from. This parameter can be set multiple times to identify multiple containers to retrieve changes from.
Comma-separated list of attributes to always be retrieved from the source LDAP directory server, regardless of the return attributes list specified for changelog queries to Oracle Virtual Directory.
Comma-separated list of attributes to be added to the normalized changelog entry. For example, orclContainerOC=1, changelogSupported=1, where =1 indicates the changes retrieved from the source directory which support changelog.
True or False. This parameter enables or disables the mapping of the directory specific account attributes to Oracle Virtual Directory virtual account attributes.
Oracle Virtual Directory includes plug-ins to simplify the integration with Oracle Access Manager. This topic describes the plug-ins related to this integration and contains the following sections:
For Oracle Virtual Directory-Oracle Access Manager integrations only, the OAMPolicyControl plug-in is for applications that use LDAP for authentication and want to use Oracle Access Manager policy controls, but cannot integrate with Oracle Access Manager.
The OAMPolicyControl plug-in has the following configuration parameters:
Note: All of the following configuration parameters—except for useAccessAuthPolicy—are required to deploy the OAMPolicyControl plug-in. |
Identifies the proxy resource for Oracle Virtual Directory that the Oracle Access Manager server configures. For example: //host:port/ovd_proxy_resource.
Used for authentication against the Identity Server, the identityproxyid parameter identifies the value of the administrator's usernameAttribute.
Identifies the AccessSDK installation directory containing the required libraries. For example: AccessSDK_INSTALL_DIRECTORY/AccessServerSDK/.
Administrator password for authentication against Identity Server.
Identifies the URL corresponding to the listening endpoint of the Identity Server's um_modifyUser web service. For example: http://host:port/identity/oblix/apps/userservcenter/bin/userservcenter.cgi
Identifies the attribute configured to be the Login attribute of the Identity Server. For example, uid or genUserId.
An optional and case-insensitive parameter, useAccessAuthPolicy determines usage of the Oracle Access Manager server's authorization policies while accessing the proxy resource. Supported values are True and False. The default setting is False.