Child pages
  • LDAP Provisioning Plugin
Skip to end of metadata
Go to start of metadata

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 v2.0.0, the Plugin assumed that if an object class is enabled, it controls all attributes within that object class are within its control, even if they are not configured. However, this can cause problems (eg: if you are using an older version of an object class than what the Plugin supports, or if you have another application that you want to manage an attribute). As of v2.0.0, two modes are supported, selected via the Unconfigured Attribute Mode setting:

  • Ignore: Unconfigured (disabled) attributes within an enabled object class are ignored. Note that if you subsequently disable an attribute after having previously enabled it, existing values of that attribute will not be removed. You will need to manually clean them up. This is the default behavior beginning with Registry v2.0.0.
  • Remove: Unconfigured attributes within an enabled object class are removed. This is the default behavior prior to Registry v2.0.0.

Regardless of this setting, attributes associated with object classes not enabled are left alone (except as described in Operations, below).

LDAP Attribute Options

As of v3.2.0, Registry supports LDAP Attribute Options, mostly in accordance with voPerson recommendations. Enabling attribute options in the LDAP Provisioning Plugin requires support for attribute options to be enabled on your LDAP server. The specifics for doing so are beyond the scope of this document, but note that it may be necessary to specify which options are in use when doing so. For example, this global configuration directive is necessary with OpenLDAP (here using OLC/cn=config):

# Note lang- becomes undefined by default when using this directive
olcAttributeOptions: lang- app- internal prior role- scope- time-

As of version 2.4.47 OpenLDAP has a bug that prevents the value for olcAttributeOptions from being modified once set.

If LDAP Attribute Options are enabled and then subsequently disabled, the LDAP Provisioning Plugin may not be able to correctly rewrite existing LDAP entries. It may be necessary to manually clean up existing entries.

Operations

(warning) Versions prior to Registry v2.0.0 may not be consistent with this documentation.

Externally Managed Attributes are those not managed by this Plugin. This includes all attributes except:

  • Attributes enabled for export, within object classes enabled for export.
  • Attributes defined by LDAP Schema Plugins and enabled for export.
  • If Unconfigured Attribute Mode is Remove, all other defined attributes within object classes enabled for export (including those defined by Schema Plugins).


Registry CO Person Transaction

LDAP Action

Externally Managed Attributes

Add

Add entry to LDAP (if entry already exists it will be deleted and replaced)

Deleted

Edit

Update configured attributes only

Untouched

Status Set To Grace Period

No changes (unless attributes change as part of grace period)

Untouched

Status Set To Expired or Suspended

Update entry to maintain only Person attributes for referential integrity (no Role or Group attributes)

Untouched

Status Set Back To Active

Restore Role and Group attributes, or add entry to LDAP if not present

Untouched

Delete, or Status Set To Deleted (or any other status not specified above)

Remove entry from LDAP

Deleted

Manual Provision

If entry exists: Update configured attributes only
If entry does not exist: Add entry to LDAP

(warning) Attributes are subject to CO Person and Person Role Status
(warning) To completely erase and rewrite a record, an administrator must remove the record from LDAP (manually or by setting the person status to eg Deleted) before manually provisioning

Untouched

Registry CO Group Transaction

LDAP Action

Add

Write CO Group record (including memberships) to LDAP, but only if there is at least one member*

Edit

Write CO Group record (not including memberships) to LDAP, but only if there is at least one member*

Delete

Write CO Group record to changelog (attributes will be empty)

Manual Provision

Write CO Group record (not including memberships) to LDAP, but only if there is at least one member*

* 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

When using this plugin, it is recommended to add database encryption for the password column in the table cm_co_ldap_provisioner_targets.

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)
  • voPerson (must be enabled; see voperson.org)

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?

Attribute Options SupportedIntroduced

cn

person, posixAccount

cm_names

Only the primary name attached to the CO Person is exported

langv0.8

cn

groupOfNames

cm_co_groups name

(error)


v0.8.2
descriptiongroupOfNamescm_co_groups description(error)
v0.8.2
displayNameinetOrgPersoncm_names(error)langv2.0.0

eduPersonAffiliation

eduPerson

cm_co_person_roles affiliation (possibly mapped via cm_co_extended_types)

(tick)

rolev0.8
eduPersonEntitlementeduPersoncm_co_services (according to member cm_co_groups)(tick)
v2.0.0
eduPersonNicknameeduPersoncm_names(tick)langv2.0.0
eduPersonOrcideduPersoncm_identifiers identifier where type is orcid(tick)
v2.0.0

eduPersonPrincipalName

eduPerson

cm_identifiers identifier

(error)


v0.8
eduPersonPrincipalNamePrioreduPersoncm_identifiers identifier(tick)
v2.0.0
eduPersonScopedAffiliationeduPersoncm_co_person_roles affiliation (possibly mapped via cm_co_extended_types, with scope appended)(tick)rolev2.0.0
eduPersonUniqueIdeduPersoncm_identifiers identifier (with scope appended)(error)
v2.0.0

employeeNumber

inetOrgPerson

cm_identifiers identifier

(error)


v0.8

employeeType

(info) While not deprecated, as of v3.2.0 the use of voPersonAffiliation is recommended instead

inetOrgPerson

cm_co_person_roles affiliation

(tick)

rolev0.9.2

facsimileTelephoneNumber

organizationalPerson

cm_telephone_numbers

(tick)

rolev0.8

gecos

posixAccount

cm_names

(error)


v0.9

gidNumber

posixAccount

cm_identifiers identifier where type is gidNumber

(error)


v0.9

givenName

inetOrgPerson

cm_names given

Only the primary name attached to the CO Person is exported

langv0.8

hasMember

eduMember

cm_identifiers identifier

(tick)


v0.8.2

homeDirectory

posixAccount

cm_identifiers identifier where type is homeDirectory

(error)


v0.9

isMemberOf

eduMember

cm_co_groups name
(where cm_co_group_members member is true)

(tick)


v0.8

l

organizationalPerson

cm_addresses locality

(tick)

lang, rolev0.8
labeledURIinetOrgPersoncm_urls url and description (if set)(tick)
v3.1.0

loginShell

posixAccount

Currently hard coded

(error)


v0.9

mail

inetOrgPerson

cm_email_addresses mail

(tick)

rolev0.8

member

groupOfNames

cm_co_ldap_provisioner_dns DN

(tick)


v0.8.2

mobile

inetOrgPerson

cm_telephone_numbers

(tick)

rolev0.8

o

inetOrgPerson

cm_co_person_roles o

(tick)

rolev0.8

ou

organizationalPerson

cm_co_person_roles ou

(tick)

rolev0.8
ownergroupOfNamescm_co_ldap_provisioner_dns DN(tick)
v0.8.2

postalCode

organizationalPerson

cm_addresses postal_code

(tick)

lang, rolev0.8
pwdAccountLockedTimen/a (see pwdPolicy)cm_co_people status (set when status is Expired or Suspended)(error)
v2.0.0
roomNumberinetOrgPersoncm_addresses room(tick)lang, rolev0.9.4

sshPublicKey

ldapPublicKey

cm_ssh_keys

(tick)


v0.9

sn

person

cm_names family

Only the primary name attached to the CO Person is exported

langv0.8

st

organizationalPerson

cm_addresses state

(tick)

lang, rolev0.8

street

organizationalPerson

cm_addresses street

(tick)

lang, rolev0.8

telephoneNumber

organizationalPerson

cm_telephone_numbers

(tick)

rolev0.8

title

organizationalPerson

cm_co_person_roles title

(tick)

rolev0.8

uid

inetOrgPerson, posixAccount

cm_identifiers identifier

(tick)


v0.8

uidNumber

posixAccount

cm_identifiers identifier where type is uidNumber

(error)


v0.9
userPasswordpersoncm_passwords password where type is CRYPT, if Password Authenticator Plugin is enabled(tick)
v3.1.0
voPersonAffiliationvoPerson

cm_co_person_roles affiliation

(tick)

rolev3.2.0
voPersonApplicationUIDvoPerson

cm_identifiers identifier

If attribute options are enabled, see note below

(tick)appv3.2.0
voPersonAuthorNamevoPersoncm_names(tick)langv3.2.0
voPersonCertificateDNvoPersoncm_certificates subject_dn(tick)scopev3.2.0
voPersonCertificateIssuerDNvoPersoncm_certificates issuer_dn(tick)scopev3.2.0
voPersonExternalIDvoPersoncm_identifiers identifier(tick)
v3.2.0
voPersonIDvoPersoncm_identifiers identifier(tick)
v3.2.0
voPersonPolicyAgreementvoPersoncm_co_t_and_c_agreements(tick)timev3.2.0
voPersonSoRIDvoPersoncm_identifiers identifier(tick)
v3.2.0
voPersonStatusvoPerson

cm_co_people status

If attribute options are enabled, cm_co_person_roles status

Only if attribute options are enabledrolev3.2.0

posixAccount support is experimental and subject to change in a future release (CO-866). Note the posixAccount Object Class requires cn, uid, uidNumber, gidNumber, and homeDirectory, but the LdapProvisioner does not necessarily enforce this in the configuration.

For ldapPublicKey integration with OpenSSH, you may find this discussion helpful. Also note that recent releases of OpenSSH include a script that queries LDAP for authorized keys.

If attribute options are enabled, the export of voPersonApplicationUID changes so that an appropriate app- label can be appended. The value for the label is taken from Registry Services, and a matching Service must be identified in order for the identifier to be exported. If no matching Service is found, the identifier will not be exported. A Service is considered "matching" if it is configured with a Service Identifier Type of the same type as the identifier to be exported. If a match is found, the identifier will be exported with with the attribute option app-shortlabel, where shortlabel is the Short Label as configured within the Service.

In voPerson terms, uid should hold the General Application Identifier, and voPersonApplicationUID should hold Application Specific Identifiers.


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.

LDAP v3 Required

The LDAP Provisioning Plugin requires LDAP protocol v3 in order to rename an entry when its DN changes.

Adding Additional ObjectClasses

As of Registry v2.0.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.

Removing ObjectClasses

(warning) When removing an objectclass (whether via configuration or by disabling LDAP Schema Plugins), keep in mind you may receive schema compliance errors from the LDAP server. This can happen because (eg)

  1. COmanage had previously included an attribute foo in the objectclass fooclass.
  2. When the objectclass is deconfigured, COmanage will emit a list of objectclasses that no longer includes fooclass.
  3. However, the LDAP record still contains the attribute foo. COmanage does not touch this attribute because it is not configured to do so.
  4. The LDAP server complains because the record does not contain an objectclass that defines foo.

In this scenario, it will be necessary to manually clean up the LDAP records to remove foo before COmanage can update the record.

See Also

  • No labels