Note: The article below describes a work-around. The Sun LDAP Connector is not an official connector for 389DS and other Netscape-family members.
- Introduction
- Useful plugins
- Retro changelog plugin
- MemberOf plugin
- LDIF
- IdentityIQ schema changes
- Provisioning policy
Introduction
389 Directory Server (389DS), also known as (variants) the RedHat Directory Server, Fedora Directory Server and CentOS Directory Server shares history with the Sun Dirctory Server. The latter has also known many names like Sun JES, SunOne, iPlanet and is currently known as the Oracle DSSE or Oracle Directory Server (not to be confused with the Oracle Internet Directory, which is a completely different product). All of these directory servers have a common ancestor: Netscape Directory Server, which in turn is a derivative of the University of Michigan "slapd" directory server (389 Directory Server - Wikipedia, the free encyclopedia).
The fact that 389-DS and Sun Directory Server share so much history, also makes them quite similar in appearance and use. The connector SunOne - Direct can be used almost one-on-one for the 389 Directory Server, with just a few modifications.
Useful plugins
Like its "family" 389 Directory Server has a number of plugins to extend functionality. Some of those can be very useful when connecting with IdentityIQ. The plugins can be enabled by making a few changes under cn=plugins, cn=config.
Retro changelog plugin
The Retro Changelog Plugin enables a way of storing changes that was used in some predecessors of the 389 Directory Server and several other (unrelated) directory servers as well. This allows 389 Directory Server's data to be replicated to directory server of other vendors or to previous versions that do not support the modern way of replicating data. When this plugin is enabled, all changes made to entries in 389 Directory Server will be written to separate records under cn=changelog. Every entry will have an incremental number. Thereby an external system can track the changes that have not yet been replicated.
To illustrate, a new "slave" is added to an LDAP environment and is to replicate from its "master". The master has 1456 changelog records already at the moment that the slave is instantiated. The slave will be fed with the current state at record 1456. After that the slave will have to read the changes from number 1457 and up. If the slave has processed up to 1480, while the counter on the master is at 1503, the sale will have a backlog of 23 records.
This same mechanism is used by IdentityIQ to implement delta aggregation. So, the first time that IdentityIQ aggregates the directory server, it will read the current changelog entry number and keep track of that number. When delta aggregation is not enabled, IdentityIQ will simply read all entries in the directory server. If delta aggregation is enabled, IdentityIQ will simply read the backlog and process those entries. Especially in very large environments, this can dramatically reduce the amount of time needed to aggregate from the directory server, making it possible to achieve near real-time aggregation.
MemberOf plugin
The MemberOf plugin enables a relation between the group's members attribute and the user's group membership attribute. If the group's list of member is updated, the attribute on the user will be updated, too. The exact attributes can be configured. The user's attribute should be memberOf and the group's should be uniqueMember.
After enabling this plugin, the relationship needs to be initialized, which can be done by running the script fixup-memberof.pl for the specified instance of the directory server. For the memberOf attribute to be allowed and visible, the users must have the object class inetUser added. This is a change we need to make to the provisioning as well. For existing entries, you need to add this object class value manually using a directory browser or an LDIF file.
[Also see: 389/RHDS memberOf plugin | onemoretech]
LDIF
The following LDIF can be used to enable the plugins mentioned above.
# Retro Changelog Plugin
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-
# MemberOf Plugin
dn: cn=MemberOf Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-
replace: memberofgroupattr
memberofgroupattr: uniqueMember
-
IdentityIQ schema changes
In the SunOne Directory Server default schema, the attribute used for groups that a user is a member of, is groups. In 389 Directory Server, out of the box, it is memberOf. This is a simple change to be made in the configuration of the application. On the Schema tab of the application, set the Group Attribute of the account schema to memberOf instead of groups.
In the attributes list of the account schema replace groups by memberOf.
Furthermore a small change needs to be made in the XML, through the debug interface: the attribute groupEntitlementAttr must be updated to contain memberOf.
<entry key="groupEntitlementAttr" value="memberOf"/>
Provisioning policy
The default provisioning policy already contains a number of attributes. These can be configured to fit your needs. By default provisioning to 389 Directory Server using this policy will result in a form to be filled in, but you can of course automate this by having IdentityIQ determine the right values using rules, scripts, static values or dependencies. In order to get the memberOf attribute working correctly, an extra attribute must be added to the policy: objectClass.
Create a new attribute in the account policy with the following parameters.
| Parameter | Value |
|---|---|
| Name | objectClass |
| Display Name | Object Classes |
| Type | String |
| Multivalued | True |
| Required | True |
| Review Required | False |
| Value |
Script: String [ ] objectClasses = {"inetOrgPerson", "organizationalPerson", "person", "top", "inetUser"};
|
