This scenario documentation is in progress.
This scenario helps to understand how midPoint can create both standard LDAP groups (groupOfNames) and posixGroup LDAP groups as projections of midPoint roles. The roles can be assigned to users to provision either LDAP accounts (inetOrgPerson) with LDAP groups membership, or to extend the standard LDAP account with posixAccount auxiliary object class and make them members of posixGroups. One possible usage of posixAccounts and posixGroups can be central Linux access management (using LDAP accounts) and limiting access to specific Linux servers using specific LDAP groups with PAM.
In this scenario, the posixGroups will be created for this purpose (that's why the "Unix" is used in the metarole name), but the actual Linux server configuration is outside of the scope of this story.
This sample assumes OpenLDAP installation.
The directory tree structure in OpenLDAP is pretty simple:
The standard LDAP groups will be created in ou=groups container while the posixGroups will be created in ou=unixGroups container. Account will be created in ou=people (flat, no further structure). All these containers are assumed to exist.
The roles created in midPoint can be provisioned as either LDAP groupOfNames or posixGroup objects, based on the metarole assigned to the role. Creating midPoint role with "LDAP Group Metarole" metarole assigned will create new group in "ou=groups" container. Creating midPoint role with "LDAP Unix Group Metarole" assigned will create new group in "ou=unixgroups" container. In both cases, the name of the group (cn) will be set to the value of "identifier" role attribute. This means that "name" of the role can be anything, only "identifier" will be used for provisioning the group.
The metaroles contain also higher order inducements so that assigning the newly created roles to the users will create LDAP account and put it to the corresponding group. The "LDAP Unix Group Metarole" will additionally extend the LDAP account with "posixAccount" auxiliary object class (and its mandatory attributes). This means that we can have either standard LDAP accounts with standard group memberships, or extend the standard LDAP accounts with auxiliary objectClass "posixAccount" just by assigning a midPoint role which has "LDAP Unix Group Metarole" assigned! We can also reverse the operation and remove the auxiliary objectClass "posixAccount" (and all its attributes) from the account by unassigning the midPoint role which has "LDAP Unix Group Metarole" assigned. At any time, midPoint user has only one projection - LDAP account; just the objectClass and the attributes differ.
You can create any number of roles, but the whole logic is always in the two metaroles. Nowhere else. This means, the solution is perfectly managable; and the metaroles work as "role templates".
Another interesting feature is how the uidNumber and gidNumber attributes are generated when creating posixGroup object and posixAccount object in LDAP. These attributes are required and must be unique. So midPoint Sequences are used.
TODO more here with fragments?
|OpenLDAP ACI||https://github.com/Evolveum/midpoint/blob/master/samples/stories/unix-ldap/aci.ldif||ACI for OpenLDAP user management for this sample. Update as you wish.|
|Sequences||https://github.com/Evolveum/midpoint/tree/master/samples/stories/unix-ldap/other||Sequences to generate unique UID/GID numbers.|
|Resources||https://github.com/Evolveum/midpoint/blob/master/samples/stories/unix-ldap/resources/ldap-posix.xml||Configuration for source and target systems. Connection properties, schema handling and synchronization configuration.|
|Roles||https://github.com/Evolveum/midpoint/tree/master/samples/stories/unix-ldap/roles||Meta roles for creating standard LDAP groups and posixGroups.|
|OpenLDAP posix||LDAP||Target Resource|
Target resource. Organizational structure allows separate containers for each customer accounts and groups.
|user accounts||account||default||Standard inetOrgPerson LDAP accounts (stored in ou=people,dc=example,dc=com)|
|LDAP groups||entitlement||ldapGroup||Standard groupOfNames LDAP groups (stored in ou=groups,dc=example,dc=com)|
|LDAP groups||entitlement||unixGroup||posixGroup LDAP groups (stored in ou=unixgroups,dc=example,dc=com)|
Before testing, install OpenLDAP, setup the ACI using the aci.ldif file and import all the configuration from the files above to midPoint:
The following sections describe scenarios prepared for this sample.
name, e.g. "LDAP Group Wiki Users"
identifier(this will become the group's
cnattribute), e.g. "wiki-users"
name, e.g. "LDAP Unix Group - Access to Athena"
identifier(this will become the group's
cnattribute), e.g. "athena-users"
extension/gidNumberattribute. This is done in the metarole's focus mapping named "sequenceGID".
name, e.g. jsmith
givenName, e.g. John
familyName, e.g. Smith
Everything for provisioning standard LDAP accounts is contained in the metarole "LDAP Group Metarole". So all you need is to do is create roles which will have projections - groupOfNames; and to create users and assign them the newly created roles.
extension/uidNumberattribute.This is done in the metarole's focus mapping named "sequenceUID" in the higher order inducement (so it will apply to the User, not Role).
extension/uidNumberattribute. This is intentionally the same value as
uidNumber(primary user group).
Everything for provisioning posixAccount accounts is contained in the metarole "LDAP Unix Group Metarole". So all you need is to do is create roles which will have projections - posixGroups; and to create users and assign them the newly created roles.