LDAP Provisioning Plugin

The LDAP Provisioning Plugin is designed to provision Registry data into an LDAP server.

Understanding LDAP Attribute Management

LDAP attributes are grouped into collections called object classes. The LDAP Provisioning Plugin supports several object classes, and various attributes within those object classes. Depending on the object class, it may possible to select some (but not all) attributes within an object class for export. The Plugin assumes full control over any enabled attribute within an object class.

Prior to v1.1.0, Registry assumed that if an object class is enabled, it controls all attributes within that schema are within its control, even if they are not specif

Operations

 Versions prior to Registry v1.1.0 may not be consistent with this documentation.

* The groupOfNames schema requires at least one member. If there are no members of a group, the Provisioner will delete the group.

Note that adding or deleting group memberships will trigger edit provisioning on both the affected CO Person and the affected CO Group.

Configuration

The LDAP Provisioning Plugin automatically converts the internal Registry data model into the following LDAP object classes:

• person
• organizationalPerson
• inetOrgPerson
• eduPerson (must be enabled)
• eduMember (must be enabled)
• groupOfNames (must be enabled)
• posixAccount (experimental, must be enabled)
• ldapPublicKey (must be enabled)

When configuring the Plugin, you can select which object classes to use and which attributes within those object classes to export to LDAP. When attributes come from data model attributes that are typed, a specific type can be selected, or all types can be selected. When multiple values are not supported, the first obtained value will be exported. Unless otherwise noted, only attributes attached to the CO Person record are exported. (Org Identity attributes are not.)

Attributes are mapped as follows:

Attribute	Object Class	Data Model	Multiple Values Exported?	Introduced
cn	person	cm_names	Only the primary name attached to the CO Person is exported	v0.8
cn	groupOfNames	cm_co_groups name		v0.8.2
description	groupOfNames	cm_co_groups description		v0.8.2
displayName	inetOrgPerson	cm_names		v1.1.0
eduPersonAffiliation	eduPerson	cm_co_person_roles affiliation (possibly mapped via cm_co_extended_types)		v0.8
eduPersonEntitlement	eduPerson	cm_co_services (according to member cm_co_groups)		v1.1.0
eduPersonNickname	eduPerson	cm_names		v1.1.0
eduPersonOrcid	eduPerson	cm_identifiers identifier where type is orcid		v1.1.0
eduPersonPrincipalName	eduPerson	cm_identifiers identifier		v0.8
eduPersonPrincipalNamePrior	eduPerson	cm_identifiers identifier		v1.1.0
eduPersonScopedAffiliation	eduPerson	cm_co_person_roles affiliation (possibly mapped via cm_co_extended_types, with scope appended)		v1.1.0
eduPersonUniqueId	eduPerson	cm_identifiers identifier (with scope appended)		v1.1.0
employeeNumber	inetOrgPerson	cm_identifiers identifier		v0.8
employeeType	inetOrgPerson	cm_co_person_roles affiliation		v0.9.2
facsimileTelephoneNumber	organizationalPerson	cm_telephone_numbers		v0.8
gecos	posixAccount	cm_names		v0.9
gidNumber	posixAccount	cm_identifiers identifier where type is gidNumber		v0.9
givenName	inetOrgPerson	cm_names given	Only the primary name attached to the CO Person is exported	v0.8
hasMember	eduMember	cm_identifiers identifier		v0.8.2
homeDirectory	posixAccount	cm_identifiers identifier where type is homeDirectory		v0.9
isMemberOf	eduMember	cm_co_groups name (where cm_co_group_members member is true)		v0.8
l	organizationalPerson	cm_addresses locality		v0.8
loginShell	posixAccount	Currently hard coded		v0.9
mail	inetOrgPerson	cm_email_addresses mail		v0.8
member	groupOfNames	cm_co_ldap_provisioner_dns DN		v0.8.2
mobile	inetOrgPerson	cm_telephone_numbers		v0.8
o	inetOrgPerson	cm_co_person_roles o		v0.8
ou	organizationalPerson	cm_co_person_roles ou		v0.8
owner	groupOfNames	cm_co_ldap_provisioner_dns DN		v0.8.2
postalCode	organizationalPerson	cm_addresses postal_code		v0.8
pwdAccountLockedTime	n/a (see pwdPolicy)	cm_co_people status (set when status is Expired or Suspended)		v1.1.0
roomNumber	inetOrgPerson	cm_addresses room		v0.9.4
sshPublicKey	ldapPublicKey	cm_ssh_keys		v0.9
sn	person	cm_names family	Only the primary name attached to the CO Person is exported	v0.8
st	organizationalPerson	cm_addresses state		v0.8
street	organizationalPerson	cm_addresses street		v0.8
telephoneNumber	organizationalPerson	cm_telephone_numbers		v0.8
title	organizationalPerson	cm_co_person_roles title		v0.8
uid	inetOrgPerson, posixAccount	cm_identifiers identifier		v0.8
uidNumber	posixAccount	cm_identifiers identifier where type is uidNumber		v0.9

Configuring DNs

Base DNs must be configured for each LDAP Provisioning Target. A People Base DN is mandatory. A Group Base DN is only required if the groupOfNames objectclass is enabled.

For People entries, an identifier label and type must be selected which will be used to create the person-specific portion of the DN. Be sure to pick an identifier that will always be defined for all people, as the Plugin will be unable to export records for which it cannot generate a DN. You may wish to use an identifier that you have configured Registry to assign automatically. The selected identifier must also be exported as part of the record (the Plugin will do this automatically if you don't configure it).

For Group entries, the name of the group is placed into cn and used to construct the DN. Thus, all Groups will have DNs of the form cn=Group Name,Group Base DN.

If an element of a DN changes for a CO Person or a CO Group, the Plugin will automatically assign a new DN and rename the entry the next time the entry is provisioned.

Adding Additional ObjectClasses

As of Registry v1.1.0, populating object classes and attributes other than those described above is supported via LDAP Schema Plugins.

Adding Additional ObjectClasses (Externally Managed)

You may write to LDAP via other services or applications to maintain attributes that are not managed by COmanage Registry. For example, you might use a mailing list manager to maintain list memberships in LDAP, or you might use the Grouper Provisioning Plugin and Grouper's PSP to provision group memberships from Grouper to LDAP.

As of Registry v1.0.3, it is possible to specify additional objectClasses as part of a Person or Group record in order to allow for the external management of a portion of the record. Note the following considerations:

1. The objectClass must have no required attributes, since the LDAP Provisioning Plugin will write the initial record with no awareness as to the characteristics of the schema. If the objectClass has any required attributes, the record will fail to be written due to schema violation. (Supporting schemas with required attributes can be done via LDAP Schema Plugins).
2. Be aware of the implications of the operations described above. For example, if the LDAP Provisioning Plugin decides to delete an entry from LDAP, the attributes managed by external applications in that entry will also be deleted.

See Also

• cm_co_ldap_provisioner_targets
• cm_co_ldap_provisioner_attributes
• cm_co_ldap_provisioner_dns