Chapter 14. Syncing LDAP groups
As an administrator with the dedicated-admin
role, you can use groups to manage users, change their permissions, and enhance collaboration. Your organization may have already created user groups and stored them in an LDAP server. OpenShift Dedicated can sync those LDAP records with internal OpenShift Dedicated records, enabling you to manage your groups in one place. OpenShift Dedicated currently supports group sync with LDAP servers using three common schemas for defining group membership: RFC 2307, Active Directory, and augmented Active Directory.
For more information on configuring LDAP, see Configuring an LDAP identity provider.
You must have dedicated-admin
privileges to sync groups.
14.1. About configuring LDAP sync
Before you can run LDAP sync, you need a sync configuration file. This file contains the following LDAP client configuration details:
- Configuration for connecting to your LDAP server.
- Sync configuration options that are dependent on the schema used in your LDAP server.
- An administrator-defined list of name mappings that maps OpenShift Dedicated group names to groups in your LDAP server.
The format of the configuration file depends upon the schema you are using: RFC 2307, Active Directory, or augmented Active Directory.
- LDAP client configuration
- The LDAP client configuration section of the configuration defines the connections to your LDAP server.
The LDAP client configuration section of the configuration defines the connections to your LDAP server.
LDAP client configuration
url: ldap://10.0.0.0:389 1 bindDN: cn=admin,dc=example,dc=com 2 bindPassword: <password> 3 insecure: false 4 ca: my-ldap-ca-bundle.crt 5
- 1
- The connection protocol, IP address of the LDAP server hosting your database, and the port to connect to, formatted as
scheme://host:port
. - 2
- Optional distinguished name (DN) to use as the Bind DN. OpenShift Dedicated uses this if elevated privilege is required to retrieve entries for the sync operation.
- 3
- Optional password to use to bind. OpenShift Dedicated uses this if elevated privilege is necessary to retrieve entries for the sync operation. This value may also be provided in an environment variable, external file, or encrypted file.
- 4
- When
false
, secure LDAP (ldaps://
) URLs connect using TLS, and insecure LDAP (ldap://
) URLs are upgraded to TLS. Whentrue
, no TLS connection is made to the server and you cannot useldaps://
URL schemes. - 5
- The certificate bundle to use for validating server certificates for the configured URL. If empty, OpenShift Dedicated uses system-trusted roots. This only applies if
insecure
is set tofalse
.
- LDAP query definition
- Sync configurations consist of LDAP query definitions for the entries that are required for synchronization. The specific definition of an LDAP query depends on the schema used to store membership information in the LDAP server.
LDAP query definition
baseDN: ou=users,dc=example,dc=com 1 scope: sub 2 derefAliases: never 3 timeout: 0 4 filter: (objectClass=person) 5 pageSize: 0 6
- 1
- The distinguished name (DN) of the branch of the directory where all searches will start from. It is required that you specify the top of your directory tree, but you can also specify a subtree in the directory.
- 2
- The scope of the search. Valid values are
base
,one
, orsub
. If this is left undefined, then a scope ofsub
is assumed. Descriptions of the scope options can be found in the table below. - 3
- The behavior of the search with respect to aliases in the LDAP tree. Valid values are
never
,search
,base
, oralways
. If this is left undefined, then the default is toalways
dereference aliases. Descriptions of the dereferencing behaviors can be found in the table below. - 4
- The time limit allowed for the search by the client, in seconds. A value of
0
imposes no client-side limit. - 5
- A valid LDAP search filter. If this is left undefined, then the default is
(objectClass=*)
. - 6
- The optional maximum size of response pages from the server, measured in LDAP entries. If set to
0
, no size restrictions will be made on pages of responses. Setting paging sizes is necessary when queries return more entries than the client or server allow by default.
LDAP search scope | Description |
---|---|
| Only consider the object specified by the base DN given for the query. |
| Consider all of the objects on the same level in the tree as the base DN for the query. |
| Consider the entire subtree rooted at the base DN given for the query. |
Dereferencing behavior | Description |
---|---|
| Never dereference any aliases found in the LDAP tree. |
| Only dereference aliases found while searching. |
| Only dereference aliases while finding the base object. |
| Always dereference all aliases found in the LDAP tree. |
- User-defined name mapping
- A user-defined name mapping explicitly maps the names of OpenShift Dedicated groups to unique identifiers that find groups on your LDAP server. The mapping uses normal YAML syntax. A user-defined mapping can contain an entry for every group in your LDAP server or only a subset of those groups. If there are groups on the LDAP server that do not have a user-defined name mapping, the default behavior during sync is to use the attribute specified as the OpenShift Dedicated group’s name.
User-defined name mapping
groupUIDNameMapping: "cn=group1,ou=groups,dc=example,dc=com": firstgroup "cn=group2,ou=groups,dc=example,dc=com": secondgroup "cn=group3,ou=groups,dc=example,dc=com": thirdgroup
14.1.1. About the RFC 2307 configuration file
The RFC 2307 schema requires you to provide an LDAP query definition for both user and group entries, as well as the attributes with which to represent them in the internal OpenShift Dedicated records.
For clarity, the group you create in OpenShift Dedicated should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Dedicated group by their e-mail, and use the name of the group as the common name. The following configuration file creates these relationships:
If using user-defined name mappings, your configuration file will differ.
LDAP sync configuration that uses RFC 2307 schema: rfc2307_config.yaml
kind: LDAPSyncConfig apiVersion: v1 url: ldap://LDAP_SERVICE_IP:389 1 insecure: false 2 bindDN: cn=admin,dc=example,dc=com bindPassword: file: "/etc/secrets/bindPassword" rfc2307: groupsQuery: baseDN: "ou=groups,dc=example,dc=com" scope: sub derefAliases: never pageSize: 0 groupUIDAttribute: dn 3 groupNameAttributes: [ cn ] 4 groupMembershipAttributes: [ member ] 5 usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never pageSize: 0 userUIDAttribute: dn 6 userNameAttributes: [ mail ] 7 tolerateMemberNotFoundErrors: false tolerateMemberOutOfScopeErrors: false
- 1
- The IP address and host of the LDAP server where this group’s record is stored.
- 2
- When
false
, secure LDAP (ldaps://
) URLs connect using TLS, and insecure LDAP (ldap://
) URLs are upgraded to TLS. Whentrue
, no TLS connection is made to the server and you cannot useldaps://
URL schemes. - 3
- The attribute that uniquely identifies a group on the LDAP server. You cannot specify
groupsQuery
filters when using DN forgroupUIDAttribute
. For fine-grained filtering, use the whitelist / blacklist method. - 4
- The attribute to use as the name of the group.
- 5
- The attribute on the group that stores the membership information.
- 6
- The attribute that uniquely identifies a user on the LDAP server. You cannot specify
usersQuery
filters when using DN for userUIDAttribute. For fine-grained filtering, use the whitelist / blacklist method. - 7
- The attribute to use as the name of the user in the OpenShift Dedicated group record.
14.1.2. About the Active Directory configuration file
The Active Directory schema requires you to provide an LDAP query definition for user entries, as well as the attributes to represent them with in the internal OpenShift Dedicated group records.
For clarity, the group you create in OpenShift Dedicated should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Dedicated group by their e-mail, but define the name of the group by the name of the group on the LDAP server. The following configuration file creates these relationships:
LDAP sync configuration that uses Active Directory schema: active_directory_config.yaml
kind: LDAPSyncConfig apiVersion: v1 url: ldap://LDAP_SERVICE_IP:389 activeDirectory: usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never filter: (objectclass=person) pageSize: 0 userNameAttributes: [ mail ] 1 groupMembershipAttributes: [ memberOf ] 2
14.1.3. About the augmented Active Directory configuration file
The augmented Active Directory schema requires you to provide an LDAP query definition for both user entries and group entries, as well as the attributes with which to represent them in the internal OpenShift Dedicated group records.
For clarity, the group you create in OpenShift Dedicated should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Dedicated group by their e-mail, and use the name of the group as the common name. The following configuration file creates these relationships.
LDAP sync configuration that uses augmented Active Directory schema: augmented_active_directory_config.yaml
kind: LDAPSyncConfig apiVersion: v1 url: ldap://LDAP_SERVICE_IP:389 augmentedActiveDirectory: groupsQuery: baseDN: "ou=groups,dc=example,dc=com" scope: sub derefAliases: never pageSize: 0 groupUIDAttribute: dn 1 groupNameAttributes: [ cn ] 2 usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never filter: (objectclass=person) pageSize: 0 userNameAttributes: [ mail ] 3 groupMembershipAttributes: [ memberOf ] 4
- 1
- The attribute that uniquely identifies a group on the LDAP server. You cannot specify
groupsQuery
filters when using DN for groupUIDAttribute. For fine-grained filtering, use the whitelist / blacklist method. - 2
- The attribute to use as the name of the group.
- 3
- The attribute to use as the name of the user in the OpenShift Dedicated group record.
- 4
- The attribute on the user that stores the membership information.
14.2. Running LDAP sync
Once you have created a sync configuration file, you can begin to sync. OpenShift Dedicated allows administrators to perform a number of different sync types with the same server.
14.2.1. Syncing the LDAP server with OpenShift Dedicated
You can sync all groups from the LDAP server with OpenShift Dedicated.
Prerequisites
- Create a sync configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
To sync all groups from the LDAP server with OpenShift Dedicated:
$ oc adm groups sync --sync-config=config.yaml --confirm
NoteBy default, all group synchronization operations are dry-run, so you must set the
--confirm
flag on theoc adm groups sync
command to make changes to OpenShift Dedicated group records.
14.2.2. Syncing OpenShift Dedicated groups with the LDAP server
You can sync all groups already in OpenShift Dedicated that correspond to groups in the LDAP server specified in the configuration file.
Prerequisites
- Create a sync configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
To sync OpenShift Dedicated groups with the LDAP server:
$ oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
NoteBy default, all group synchronization operations are dry-run, so you must set the
--confirm
flag on theoc adm groups sync
command to make changes to OpenShift Dedicated group records.
14.2.3. Syncing subgroups from the LDAP server with OpenShift Dedicated
You can sync a subset of LDAP groups with OpenShift Dedicated using whitelist files, blacklist files, or both.
You can use any combination of blacklist files, whitelist files, or whitelist literals. Whitelist and blacklist files must contain one unique group identifier per line, and you can include whitelist literals directly in the command itself. These guidelines apply to groups found on LDAP servers as well as groups already present in OpenShift Dedicated.
Prerequisites
- Create a sync configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
To sync a subset of LDAP groups with OpenShift Dedicated, use any the following commands:
$ oc adm groups sync --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync <group_unique_identifier> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync <group_unique_identifier> \ --whitelist=<whitelist_file> \ --blacklist=<blacklist_file> \ --sync-config=config.yaml \ --confirm
$ oc adm groups sync --type=openshift \ --whitelist=<whitelist_file> \ --sync-config=config.yaml \ --confirm
NoteBy default, all group synchronization operations are dry-run, so you must set the
--confirm
flag on theoc adm groups sync
command to make changes to OpenShift Dedicated group records.
14.3. Running a group pruning job
An administrator can also choose to remove groups from OpenShift Dedicated records if the records on the LDAP server that created them are no longer present. The prune job will accept the same sync configuration file and whitelists or blacklists as used for the sync job.
For example:
$ oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
$ oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm
14.4. LDAP group sync examples
This section contains examples for the RFC 2307, Active Directory, and augmented Active Directory schemas.
These examples assume that all users are direct members of their respective groups. Specifically, no groups have other groups as members. See the Nested Membership Sync Example for information on how to sync nested groups.
14.4.1. Syncing groups using the RFC 2307 schema
For the RFC 2307 schema, the following examples synchronize a group named admins
that has two members: Jane
and Jim
. The examples explain:
- How the group and users are added to the LDAP server.
- What the resulting group record in OpenShift Dedicated will be after synchronization.
These examples assume that all users are direct members of their respective groups. Specifically, no groups have other groups as members. See the Nested Membership Sync Example for information on how to sync nested groups.
In the RFC 2307 schema, both users (Jane and Jim) and groups exist on the LDAP server as first-class entries, and group membership is stored in attributes on the group. The following snippet of ldif
defines the users and group for this schema:
LDAP entries that use RFC 2307 schema: rfc2307.ldif
dn: ou=users,dc=example,dc=com objectClass: organizationalUnit ou: users dn: cn=Jane,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jane sn: Smith displayName: Jane Smith mail: jane.smith@example.com dn: cn=Jim,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jim sn: Adams displayName: Jim Adams mail: jim.adams@example.com dn: ou=groups,dc=example,dc=com objectClass: organizationalUnit ou: groups dn: cn=admins,ou=groups,dc=example,dc=com 1 objectClass: groupOfNames cn: admins owner: cn=admin,dc=example,dc=com description: System Administrators member: cn=Jane,ou=users,dc=example,dc=com 2 member: cn=Jim,ou=users,dc=example,dc=com
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
rfc2307_config.yaml
file:$ oc adm groups sync --sync-config=rfc2307_config.yaml --confirm
OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
rfc2307_config.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1 openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com 2 openshift.io/ldap.url: LDAP_SERVER_IP:389 3 creationTimestamp: name: admins 4 users: 5 - jane.smith@example.com - jim.adams@example.com
- 1
- The last time this OpenShift Dedicated group was synchronized with the LDAP server, in ISO 6801 format.
- 2
- The unique identifier for the group on the LDAP server.
- 3
- The IP address and host of the LDAP server where this group’s record is stored.
- 4
- The name of the group as specified by the sync file.
- 5
- The users that are members of the group, named as specified by the sync file.
14.4.2. Syncing groups using the RFC2307 schema with user-defined name mappings
When syncing groups with user-defined name mappings, the configuration file changes to contain these mappings as shown below.
LDAP sync configuration that uses RFC 2307 schema with user-defined name mappings: rfc2307_config_user_defined.yaml
kind: LDAPSyncConfig apiVersion: v1 groupUIDNameMapping: "cn=admins,ou=groups,dc=example,dc=com": Administrators 1 rfc2307: groupsQuery: baseDN: "ou=groups,dc=example,dc=com" scope: sub derefAliases: never pageSize: 0 groupUIDAttribute: dn 2 groupNameAttributes: [ cn ] 3 groupMembershipAttributes: [ member ] usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never pageSize: 0 userUIDAttribute: dn 4 userNameAttributes: [ mail ] tolerateMemberNotFoundErrors: false tolerateMemberOutOfScopeErrors: false
- 1
- The user-defined name mapping.
- 2
- The unique identifier attribute that is used for the keys in the user-defined name mapping. You cannot specify
groupsQuery
filters when using DN for groupUIDAttribute. For fine-grained filtering, use the whitelist / blacklist method. - 3
- The attribute to name OpenShift Dedicated groups with if their unique identifier is not in the user-defined name mapping.
- 4
- The attribute that uniquely identifies a user on the LDAP server. You cannot specify
usersQuery
filters when using DN for userUIDAttribute. For fine-grained filtering, use the whitelist / blacklist method.
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
rfc2307_config_user_defined.yaml
file:$ oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm
OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
rfc2307_config_user_defined.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com openshift.io/ldap.url: LDAP_SERVER_IP:389 creationTimestamp: name: Administrators 1 users: - jane.smith@example.com - jim.adams@example.com
- 1
- The name of the group as specified by the user-defined name mapping.
14.4.3. Syncing groups using RFC 2307 with user-defined error tolerances
By default, if the groups being synced contain members whose entries are outside of the scope defined in the member query, the group sync fails with an error:
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
This often indicates a misconfigured baseDN
in the usersQuery
field. However, in cases where the baseDN
intentionally does not contain some of the members of the group, setting tolerateMemberOutOfScopeErrors: true
allows the group sync to continue. Out of scope members will be ignored.
Similarly, when the group sync process fails to locate a member for a group, it fails outright with errors:
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry". Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
This often indicates a misconfigured usersQuery
field. However, in cases where the group contains member entries that are known to be missing, setting tolerateMemberNotFoundErrors: true
allows the group sync to continue. Problematic members will be ignored.
Enabling error tolerances for the LDAP group sync causes the sync process to ignore problematic member entries. If the LDAP group sync is not configured correctly, this could result in synced OpenShift Dedicated groups missing members.
LDAP entries that use RFC 2307 schema with problematic group membership: rfc2307_problematic_users.ldif
dn: ou=users,dc=example,dc=com objectClass: organizationalUnit ou: users dn: cn=Jane,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jane sn: Smith displayName: Jane Smith mail: jane.smith@example.com dn: cn=Jim,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jim sn: Adams displayName: Jim Adams mail: jim.adams@example.com dn: ou=groups,dc=example,dc=com objectClass: organizationalUnit ou: groups dn: cn=admins,ou=groups,dc=example,dc=com objectClass: groupOfNames cn: admins owner: cn=admin,dc=example,dc=com description: System Administrators member: cn=Jane,ou=users,dc=example,dc=com member: cn=Jim,ou=users,dc=example,dc=com member: cn=INVALID,ou=users,dc=example,dc=com 1 member: cn=Jim,ou=OUTOFSCOPE,dc=example,dc=com 2
To tolerate the errors in the above example, the following additions to your sync configuration file must be made:
LDAP sync configuration that uses RFC 2307 schema tolerating errors: rfc2307_config_tolerating.yaml
kind: LDAPSyncConfig apiVersion: v1 url: ldap://LDAP_SERVICE_IP:389 rfc2307: groupsQuery: baseDN: "ou=groups,dc=example,dc=com" scope: sub derefAliases: never groupUIDAttribute: dn groupNameAttributes: [ cn ] groupMembershipAttributes: [ member ] usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never userUIDAttribute: dn 1 userNameAttributes: [ mail ] tolerateMemberNotFoundErrors: true 2 tolerateMemberOutOfScopeErrors: true 3
- 1
- The attribute that uniquely identifies a user on the LDAP server. You cannot specify
usersQuery
filters when using DN for userUIDAttribute. For fine-grained filtering, use the whitelist / blacklist method. - 2
- When
true
, the sync job tolerates groups for which some members were not found, and members whose LDAP entries are not found are ignored. The default behavior for the sync job is to fail if a member of a group is not found. - 3
- When
true
, the sync job tolerates groups for which some members are outside the user scope given in theusersQuery
base DN, and members outside the member query scope are ignored. The default behavior for the sync job is to fail if a member of a group is out of scope.
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
rfc2307_config_tolerating.yaml
file:$ oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm
OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
rfc2307_config.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com openshift.io/ldap.url: LDAP_SERVER_IP:389 creationTimestamp: name: admins users: 1 - jane.smith@example.com - jim.adams@example.com
- 1
- The users that are members of the group, as specified by the sync file. Members for which lookup encountered tolerated errors are absent.
14.4.4. Syncing groups using the Active Directory schema
In the Active Directory schema, both users (Jane and Jim) exist in the LDAP server as first-class entries, and group membership is stored in attributes on the user. The following snippet of ldif
defines the users and group for this schema:
LDAP entries that use Active Directory schema: active_directory.ldif
dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users
dn: cn=Jane,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jane
sn: Smith
displayName: Jane Smith
mail: jane.smith@example.com
memberOf: admins 1
dn: cn=Jim,ou=users,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: testPerson
cn: Jim
sn: Adams
displayName: Jim Adams
mail: jim.adams@example.com
memberOf: admins
- 1
- The user’s group memberships are listed as attributes on the user, and the group does not exist as an entry on the server. The
memberOf
attribute does not have to be a literal attribute on the user; in some LDAP servers, it is created during search and returned to the client, but not committed to the database.
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
active_directory_config.yaml
file:$ oc adm groups sync --sync-config=active_directory_config.yaml --confirm
OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
active_directory_config.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1 openshift.io/ldap.uid: admins 2 openshift.io/ldap.url: LDAP_SERVER_IP:389 3 creationTimestamp: name: admins 4 users: 5 - jane.smith@example.com - jim.adams@example.com
- 1
- The last time this OpenShift Dedicated group was synchronized with the LDAP server, in ISO 6801 format.
- 2
- The unique identifier for the group on the LDAP server.
- 3
- The IP address and host of the LDAP server where this group’s record is stored.
- 4
- The name of the group as listed in the LDAP server.
- 5
- The users that are members of the group, named as specified by the sync file.
14.4.5. Syncing groups using the augmented Active Directory schema
In the augmented Active Directory schema, both users (Jane and Jim) and groups exist in the LDAP server as first-class entries, and group membership is stored in attributes on the user. The following snippet of ldif
defines the users and group for this schema:
LDAP entries that use augmented Active Directory schema: augmented_active_directory.ldif
dn: ou=users,dc=example,dc=com objectClass: organizationalUnit ou: users dn: cn=Jane,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: testPerson cn: Jane sn: Smith displayName: Jane Smith mail: jane.smith@example.com memberOf: cn=admins,ou=groups,dc=example,dc=com 1 dn: cn=Jim,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: testPerson cn: Jim sn: Adams displayName: Jim Adams mail: jim.adams@example.com memberOf: cn=admins,ou=groups,dc=example,dc=com dn: ou=groups,dc=example,dc=com objectClass: organizationalUnit ou: groups dn: cn=admins,ou=groups,dc=example,dc=com 2 objectClass: groupOfNames cn: admins owner: cn=admin,dc=example,dc=com description: System Administrators member: cn=Jane,ou=users,dc=example,dc=com member: cn=Jim,ou=users,dc=example,dc=com
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
augmented_active_directory_config.yaml
file:$ oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm
OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
augmented_active_directory_config.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1 openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com 2 openshift.io/ldap.url: LDAP_SERVER_IP:389 3 creationTimestamp: name: admins 4 users: 5 - jane.smith@example.com - jim.adams@example.com
- 1
- The last time this OpenShift Dedicated group was synchronized with the LDAP server, in ISO 6801 format.
- 2
- The unique identifier for the group on the LDAP server.
- 3
- The IP address and host of the LDAP server where this group’s record is stored.
- 4
- The name of the group as specified by the sync file.
- 5
- The users that are members of the group, named as specified by the sync file.
14.4.5.1. LDAP nested membership sync example
Groups in OpenShift Dedicated do not nest. The LDAP server must flatten group membership before the data can be consumed. Microsoft’s Active Directory Server supports this feature via the LDAP_MATCHING_RULE_IN_CHAIN
rule, which has the OID 1.2.840.113556.1.4.1941
. Furthermore, only explicitly whitelisted groups can be synced when using this matching rule.
This section has an example for the augmented Active Directory schema, which synchronizes a group named admins
that has one user Jane
and one group otheradmins
as members. The otheradmins
group has one user member: Jim
. This example explains:
- How the group and users are added to the LDAP server.
- What the LDAP sync configuration file looks like.
- What the resulting group record in OpenShift Dedicated will be after synchronization.
In the augmented Active Directory schema, both users (Jane
and Jim
) and groups exist in the LDAP server as first-class entries, and group membership is stored in attributes on the user or the group. The following snippet of ldif
defines the users and groups for this schema:
LDAP entries that use augmented Active Directory schema with nested members: augmented_active_directory_nested.ldif
dn: ou=users,dc=example,dc=com objectClass: organizationalUnit ou: users dn: cn=Jane,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: testPerson cn: Jane sn: Smith displayName: Jane Smith mail: jane.smith@example.com memberOf: cn=admins,ou=groups,dc=example,dc=com 1 dn: cn=Jim,ou=users,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: testPerson cn: Jim sn: Adams displayName: Jim Adams mail: jim.adams@example.com memberOf: cn=otheradmins,ou=groups,dc=example,dc=com 2 dn: ou=groups,dc=example,dc=com objectClass: organizationalUnit ou: groups dn: cn=admins,ou=groups,dc=example,dc=com 3 objectClass: group cn: admins owner: cn=admin,dc=example,dc=com description: System Administrators member: cn=Jane,ou=users,dc=example,dc=com member: cn=otheradmins,ou=groups,dc=example,dc=com dn: cn=otheradmins,ou=groups,dc=example,dc=com 4 objectClass: group cn: otheradmins owner: cn=admin,dc=example,dc=com description: Other System Administrators memberOf: cn=admins,ou=groups,dc=example,dc=com 5 6 member: cn=Jim,ou=users,dc=example,dc=com
When syncing nested groups with Active Directory, you must provide an LDAP query definition for both user entries and group entries, as well as the attributes with which to represent them in the internal OpenShift Dedicated group records. Furthermore, certain changes are required in this configuration:
-
The
oc adm groups sync
command must explicitly whitelist groups. -
The user’s
groupMembershipAttributes
must include"memberOf:1.2.840.113556.1.4.1941:"
to comply with theLDAP_MATCHING_RULE_IN_CHAIN
rule. -
The
groupUIDAttribute
must be set todn
. The
groupsQuery
:-
Must not set
filter
. -
Must set a valid
derefAliases
. -
Should not set
baseDN
as that value is ignored. -
Should not set
scope
as that value is ignored.
-
Must not set
For clarity, the group you create in OpenShift Dedicated should use attributes other than the distinguished name whenever possible for user- or administrator-facing fields. For example, identify the users of an OpenShift Dedicated group by their e-mail, and use the name of the group as the common name. The following configuration file creates these relationships:
LDAP sync configuration that uses augmented Active Directory schema with nested members: augmented_active_directory_config_nested.yaml
kind: LDAPSyncConfig apiVersion: v1 url: ldap://LDAP_SERVICE_IP:389 augmentedActiveDirectory: groupsQuery: 1 derefAliases: never pageSize: 0 groupUIDAttribute: dn 2 groupNameAttributes: [ cn ] 3 usersQuery: baseDN: "ou=users,dc=example,dc=com" scope: sub derefAliases: never filter: (objectclass=person) pageSize: 0 userNameAttributes: [ mail ] 4 groupMembershipAttributes: [ "memberOf:1.2.840.113556.1.4.1941:" ] 5
- 1
groupsQuery
filters cannot be specified. ThegroupsQuery
base DN and scope values are ignored.groupsQuery
must set a validderefAliases
.- 2
- The attribute that uniquely identifies a group on the LDAP server. It must be set to
dn
. - 3
- The attribute to use as the name of the group.
- 4
- The attribute to use as the name of the user in the OpenShift Dedicated group record.
mail
orsAMAccountName
are preferred choices in most installations. - 5
- The attribute on the user that stores the membership information. Note the use of
LDAP_MATCHING_RULE_IN_CHAIN
.
Prerequisites
- Create the configuration file.
-
You have access to the cluster as a user with the
dedicated-admin
role.
Procedure
Run the sync with the
augmented_active_directory_config_nested.yaml
file:$ oc adm groups sync \ 'cn=admins,ou=groups,dc=example,dc=com' \ --sync-config=augmented_active_directory_config_nested.yaml \ --confirm
NoteYou must explicitly whitelist the
cn=admins,ou=groups,dc=example,dc=com
group.OpenShift Dedicated creates the following group record as a result of the above sync operation:
OpenShift Dedicated group created by using the
augmented_active_directory_config_nested.yaml
fileapiVersion: user.openshift.io/v1 kind: Group metadata: annotations: openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400 1 openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com 2 openshift.io/ldap.url: LDAP_SERVER_IP:389 3 creationTimestamp: name: admins 4 users: 5 - jane.smith@example.com - jim.adams@example.com
- 1
- The last time this OpenShift Dedicated group was synchronized with the LDAP server, in ISO 6801 format.
- 2
- The unique identifier for the group on the LDAP server.
- 3
- The IP address and host of the LDAP server where this group’s record is stored.
- 4
- The name of the group as specified by the sync file.
- 5
- The users that are members of the group, named as specified by the sync file. Note that members of nested groups are included since the group membership was flattened by the Microsoft Active Directory Server.
14.5. LDAP sync configuration specification
The object specification for the configuration file is below. Note that the different schema objects have different fields. For example, v1.ActiveDirectoryConfig has no groupsQuery
field whereas v1.RFC2307Config and v1.AugmentedActiveDirectoryConfig both do.
There is no support for binary attributes. All attribute data coming from the LDAP server must be in the format of a UTF-8 encoded string. For example, never use a binary attribute, such as objectGUID
, as an ID attribute. You must use string attributes, such as sAMAccountName
or userPrincipalName
, instead.
14.5.1. v1.LDAPSyncConfig
LDAPSyncConfig
holds the necessary configuration options to define an LDAP group sync.
Name | Description | Schema |
---|---|---|
| String value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#types-kinds | string |
| Defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#resources | string |
|
Host is the scheme, host and port of the LDAP server to connect to: | string |
| Optional DN to bind to the LDAP server with. | string |
| Optional password to bind with during the search phase. | v1.StringSource |
|
If | boolean |
| Optional trusted certificate authority bundle to use when making requests to the server. If empty, the default system roots are used. | string |
| Optional direct mapping of LDAP group UIDs to OpenShift Dedicated group names. | object |
| Holds the configuration for extracting data from an LDAP server set up in a fashion similar to RFC2307: first-class group and user entries, with group membership determined by a multi-valued attribute on the group entry listing its members. | v1.RFC2307Config |
| Holds the configuration for extracting data from an LDAP server set up in a fashion similar to that used in Active Directory: first-class user entries, with group membership determined by a multi-valued attribute on members listing groups they are a member of. | v1.ActiveDirectoryConfig |
| Holds the configuration for extracting data from an LDAP server set up in a fashion similar to that used in Active Directory as described above, with one addition: first-class group entries exist and are used to hold metadata but not group membership. | v1.AugmentedActiveDirectoryConfig |
14.5.2. v1.StringSource
StringSource
allows specifying a string inline, or externally via environment variable or file. When it contains only a string value, it marshals to a simple JSON string.
Name | Description | Schema |
---|---|---|
|
Specifies the cleartext value, or an encrypted value if | string |
|
Specifies an environment variable containing the cleartext value, or an encrypted value if the | string |
|
References a file containing the cleartext value, or an encrypted value if a | string |
| References a file containing the key to use to decrypt the value. | string |
14.5.3. v1.LDAPQuery
LDAPQuery
holds the options necessary to build an LDAP query.
Name | Description | Schema |
---|---|---|
| DN of the branch of the directory where all searches should start from. | string |
|
The optional scope of the search. Can be | string |
|
The optional behavior of the search with regards to aliases. Can be | string |
|
Holds the limit of time in seconds that any request to the server can remain outstanding before the wait for a response is given up. If this is | integer |
| A valid LDAP search filter that retrieves all relevant entries from the LDAP server with the base DN. | string |
|
Maximum preferred page size, measured in LDAP entries. A page size of | integer |
14.5.4. v1.RFC2307Config
RFC2307Config
holds the necessary configuration options to define how an LDAP group sync interacts with an LDAP server using the RFC2307 schema.
Name | Description | Schema |
---|---|---|
| Holds the template for an LDAP query that returns group entries. | v1.LDAPQuery |
|
Defines which attribute on an LDAP group entry will be interpreted as its unique identifier. ( | string |
| Defines which attributes on an LDAP group entry will be interpreted as its name to use for an OpenShift Dedicated group. | string array |
|
Defines which attributes on an LDAP group entry will be interpreted as its members. The values contained in those attributes must be queryable by your | string array |
| Holds the template for an LDAP query that returns user entries. | v1.LDAPQuery |
|
Defines which attribute on an LDAP user entry will be interpreted as its unique identifier. It must correspond to values that will be found from the | string |
|
Defines which attributes on an LDAP user entry will be used, in order, as its OpenShift Dedicated user name. The first attribute with a non-empty value is used. This should match your | string array |
|
Determines the behavior of the LDAP sync job when missing user entries are encountered. If | boolean |
|
Determines the behavior of the LDAP sync job when out-of-scope user entries are encountered. If | boolean |
14.5.5. v1.ActiveDirectoryConfig
ActiveDirectoryConfig
holds the necessary configuration options to define how an LDAP group sync interacts with an LDAP server using the Active Directory schema.
Name | Description | Schema |
---|---|---|
| Holds the template for an LDAP query that returns user entries. | v1.LDAPQuery |
|
Defines which attributes on an LDAP user entry will be interpreted as its OpenShift Dedicated user name. The attribute to use as the name of the user in the OpenShift Dedicated group record. | string array |
| Defines which attributes on an LDAP user entry will be interpreted as the groups it is a member of. | string array |
14.5.6. v1.AugmentedActiveDirectoryConfig
AugmentedActiveDirectoryConfig
holds the necessary configuration options to define how an LDAP group sync interacts with an LDAP server using the augmented Active Directory schema.
Name | Description | Schema |
---|---|---|
| Holds the template for an LDAP query that returns user entries. | v1.LDAPQuery |
|
Defines which attributes on an LDAP user entry will be interpreted as its OpenShift Dedicated user name. The attribute to use as the name of the user in the OpenShift Dedicated group record. | string array |
| Defines which attributes on an LDAP user entry will be interpreted as the groups it is a member of. | string array |
| Holds the template for an LDAP query that returns group entries. | v1.LDAPQuery |
|
Defines which attribute on an LDAP group entry will be interpreted as its unique identifier. ( | string |
| Defines which attributes on an LDAP group entry will be interpreted as its name to use for an OpenShift Dedicated group. | string array |