This chapter describes the following information about using the connector with an LDAPv3 compliant directory server:
Note:
In this chapter, OpenLDAP server is used as an example of an LDAPv3 compliant target system. You will need to adapt the examples in this chapter to the LDAPv3 compliant directory server you are using.
To provide secure communications to the LDAPv3 target system, configure SSL between Oracle Identity Manager, the Connector Server, and the LDAPv3 target system.
For more information, see Configuring SSL for the Connector.
Note:
As a prerequisite, OpenLDAP server (or the LDAPv3 compliant directory server you are using) must be installed and configured. The examples in this chapter use the baseDN as dc=example,dc=com
and the administrator account as cn=admin,dc=example,dc=com
.
When you install the connector, create a new IT Resource instance named OpenLDAP with the parameters described in Table 8-1.
Table 8-1 Parameters of the IT Resource for the OpenLDAP Server Target System
Parameter | Description |
---|---|
host |
OpenLDAP server hostname or IP address. |
port |
OpenLDAP server port. |
ssl |
Specifies whether communication with the target system must be secured using SSL. Specify true or false, depending on how the OpenLDAP server is configured. |
Configuration Lookup |
Name of the lookup definition that stores configuration information used during reconciliation and provisioning. Specify Lookup.LDAP.Configuration. |
baseContexts |
Base contexts for operations on the target system. Sample value: "dc=example,dc=com" |
credentials |
Password you used during the OpenLDAP server setup. |
principal |
Bind DN for performing operations on the OpenLDAP server target system. Sample value: cn=admin,dc=example,dc=com |
This section describes these topics:
The main configuration lookup Lookup.LDAP.Configuration contains the configuration parameters you need to change for an OpenLDAP server.
First, set entryUUID
to uidAttribute
in the Lookup.LDAP.Configuration lookup, because OpenLDAP uses entryUUID
.
Note:
The Lookup.LDAP.Configuration contains many configuration properties that can change the behavior of the connector. See Lookup.LDAP.Configuration for more details on the configuration options. However, the most important configuration property is uidAttribute, which is explicitly mentioned in this section.
In order to make the provisioning work with the connector, configure the following lookup reconciliations, because these values are used in the provisioning forms:
This Job finds all existing organizational units on target resource and reconciles them into the lookup configured in the Lookup Name job parameter (by default Lookup.LDAP.Organization).
The Code Key Attribute job parameter specifies which LDAP attribute will be used as the value in the lookup's Code Key. The default value dn
doesn't need to be changed for OpenLDAP. Similarly, do not change the Decode Attribute job parameter, because the default value ou
is sufficient.
Note that the Object Type job parameter is set to OU
by default. The connector bundle translates this value to the organizationalUnit
object class, so the organization units defined in OpenLDAP must have the organizationUnit
object class assigned.
Therefore, you only need to set the IT Resource Name job parameter to OpenLDAP.
By running the task, the connector bundle will search using an LDAP filter like (&(objectClass=top)(objectClass=organizationalUnit))
, and the attributes dn
and ou
will be used respectively as the Code Key and Decode values in the Lookup.LDAP.Configuration lookup.
As in case of the previous lookup reconciliation job, the default parameters for this job should work sufficiently. Set the IT Resource Name parameter to OpenLDAP.
The (&(objectClass=top)(objectClass=groupOfUniqueNames))
LDAP filter will be used to find out all groups available on the OpenLDAP server.
This section contains the following topics:
The out-of-the-box configuration works sufficiently with OpenLDAP, and there is no need to change anything to make provisioning work.
When creating a new LDAP User resource object, Oracle Identity Manager uses the LDAP User process and triggers the Create User process task, which uses the adpLDAPCREATEOBJECT
adapter.
The adapter calls the ICProvisioningManager#createObject
method, which is a common implementation for all ICF based connectors. The ICProvisioningManager
finds and configures the ICF connector bundle, maps the form fields to ICF attributes based on the Lookup.LDAP.UM.ProvAttrMap lookup, and invokes the CreateApiOp#create
ICF method. The connector bundle code takes care of actually creating the object in OpenLDAP.
Note that Lookup.LDAP.UM.ProvAttrMap contains the following entry:
NsuniqueID:__UID__
Because you configured entryUUID
to be used as the UID
attribute, the Nsunique
form field attribute (configured as not visible) will be updated with the entryUUID
value by object creation. Similar mapping is present for all groups and organizational units, and this field is used in reconciliation matching rules.
Updating the resource object functions in a similar way. Note that LDAP User
process has the UD_LDAP_USR Updated
process task, which is triggered by making changes to multiple fields. Thus, all the changes are handled in one CreateApiOp#create
operation invocation.
LDAP User provisioning has out-of-the-box support for two multivalued attributes Group and Role, which means the following two child tables are defined in the UD_LDAP_USR
table:
UD_LDAP_GRP
for groups
UD_LDAP_ROL
for roles
Note:
The connector supports the notion of Role and Group, only if the target directory implements these features in the following standard way:
For role: A multivalued attribute is added in the User Object that represents the user's role.
For group: A multivalued attribute is added in the Group Object that represents the members of the group.
Because OpenLDAP doesn't support roles, only groups can be used.
If you need to add an LDAP attribute that is not supported out-of-the-box, follow the steps described in Extending the Functionality of the Connector.
Group provisioning is done in Oracle Identity Manager by provisioning the LDAP Group
resource object to the Oracle Identity Manager organization.
The connector uses groupOfUniqueNames
as the object class for groups. OpenLDAP requires the uniqueMember
attribute to be filled. Because the connector provides four attributes: container
, cn
, __NAME__
, and __UID__
as configured in Lookup.LDAP.Group.ProvAttrMap, the group provisioning ends up with an exception stating:
object class 'groupOfUniqueNames' requires attribute 'uniqueMember'
To resolve this issue, do one of the following:
Update the groupOfUniqueNames
object class schema in OpenLDAP so the uniqueAttribute
is not required. However, this is not recommended by OpenLDAP.
Configure Oracle Identity Manager to provide the uniqueMember
attribute value every time the group is created or updated by adding the following entry to Lookup.LDAP.Group.ProvAttrMap:
uniqueMember: uniqueMember='cn=admin,dc=example,dc=com'
This entry ensures that the admin user is member of every group provisioned by Oracle Identity Manager. Note that this might not be desirable for some deployments.
If you need to add an LDAP attribute that is not supported out-of-the-box, follow the steps described in Extending the Functionality of the Connector.
Organizational unit provisioning is done in Oracle Identity Manager by provisioning the LDAP Organisation Unit
resource object to the Oracle Identity Manager organization.
As already mentioned in Organizational Unit (OU) Lookup Reconciliation,, the connector uses the organizationalUnit
object class for organizational unit provisioning. There is no need to change any configuration to make OpenLDAP OU provisioning work.
If you need to add an LDAP attribute that is not supported out-of-the-box, follow the steps described in Extending the Functionality of the Connector.
This section contains the following topics:
The out-of-the-box configuration works sufficiently with OpenLDAP, so just set OpenLDAP as the IT Resource Name. By default the modifyTimestamp
attribute is configured as Incremental Recon Attribute
, which works with OpenLDAP.
Note that Lookup.LDAP.UM.ReconAttrMap contains the following entry:
NsuniqueID: __UID__
Because entryUUID
is configured as uidAttribute
, the entryUUID
value will be stored in the NsuniqueID
field. This field is also used in the reconciliation matching rule.
Note:
Check if your LDAPv3 server supports modifyTimestamp. If modifyTimestamp is not supported, delete Incremental Recon Attribute, and the schedule job will always run full reconciliation.
If you need to add a custom attribute for reconciliation, see Adding Custom Fields for Target Resource Reconciliation.
This jobs works out-of-the-box too. The only thing that needs to be done is to set IT Resource Name to OpenLDAP.
For trusted reconciliations, you must create a separate IT Resource, as follows:
Setting the IT Resource Name job parameter to OpenLDAP Trusted is sufficient to make this job work with OpenLDAP.
Setting the IT Resource Name job parameter to OpenLDAP is sufficient to make this job work with OpenLDAP.
Setting the IT Resource Name job parameter to OpenLDAP is sufficient to make this job work with OpenLDAP.
Setting the IT Resource Name job parameter to OpenLDAP is sufficient to make this job work with OpenLDAP.
Setting the IT Resource Name job parameter to OpenLDAP is sufficient to make this job work with OpenLDAP.
You cannot use the following reconciliation jobs with OpenLDAP, because OpenLDAP doesn't support changelog and roles:
Group Sync Reconciliation
Organizational Unit (OU) Sync Reconciliation
Role Lookup Reconciliation
Role Search Delete Reconciliation
Role Search Reconciliation
Role Sync Reconciliation
User Sync Reconciliation