11.6. Using an External Provisioning System for Users and Groups
Identity Management supports configuring your environment, so that an external solution for managing identities is used to provision user and group identities in IdM. This section describes an example of such configuration. The example includes:
11.6.1. Configuring User Accounts to Be Used by the External Provisioning System
This procedure shows how to configure two IdM user accounts to be used by the external provisioning system. By adding the accounts to a group with an appropriate password policy, you enable the external provisioning system to manage user provisioning in IdM.
- Create a user,
provisionator
, with the privileges to add stage users. The user account will be used by the external provisioning system to add new stage users.- Add the
provisionator
user account:$ ipa user-add provisionator --first=provisioning --last=account --password
- Grant the
provisionator
user the required privileges.Create a custom role,System Provisioning
, to manage adding stage users:$ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
Add theStage User Provisioning
privilege to the role. This privilege provides the ability to add stage users:$ ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
Add theprovisionator
user to the role:$ ipa role-add-member --users=provisionator "System Provisioning"
- Create a user,
activator
, with the privileges to manage user accounts. The user account will be used to automatically activate stage users added by the external provisioning system.- Add the
activator
user account:$ ipa user-add activator --first=activation --last=account --password
- Grant the
activator
user the required privileges.Add the user to the defaultUser Administrator
role:$ ipa role-add-member --users=activator "User Administrator"
- Create a user group for service and application accounts:
$ ipa group-add service-accounts
- Update the password policy for the group. The following policy prevents password expiration and lockout for the account but compensates the potential risks by requiring complex passwords:
$ ipa pwpolicy-add service-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=20 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
- Add the provisioning and activation accounts to the group for service and application accounts:
$ ipa group-add-member service-accounts --users={provisionator,activator}
- Change the passwords for the user accounts:
$ kpasswd provisionator $ kpasswd activator
Changing the passwords is necessary because passwords of new IdM users expire immediately.
Additional resources:
- For details on adding new users, see Section 11.2.1, “Adding Stage or Active Users”.
- For details on granting users the privileges required to manage other user accounts, see Section 11.5, “Allowing Non-admin Users to Manage User Entries”.
- For details on managing IdM password policies, see Chapter 28, Defining Password Policies.
11.6.2. Configuring IdM to Automatically Activate Stage User Accounts
This procedure shows how to create a script for activating stage users. The system runs the script automatically at specified time intervals. This ensures that new user accounts are automatically activated and available for use shortly after they are created.
Important
The procedure assumes that the new user accounts do not require validation before the script adds them to IdM. For example, validation is not required when the users have already been validated by the owner of the external provisioning system.
It is sufficient to enable the activation process on only one of your IdM servers.
- Generate a keytab file for the activation account:
# ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
If you want to enable the activation process on more than one IdM server, generate the keytab file on one server only. Then copy the keytab file to the other servers. - Create a script,
/usr/local/sbin/ipa-activate-all
, with the following contents to activate all users:#!/bin/bash kinit -k -i activator ipa stageuser-find --all --raw | grep " uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
- Edit the permissions and ownership for the
ipa-activate-all
script to make it executable:# chmod 755 /usr/local/sbin/ipa-activate-all # chown root:root /usr/local/sbin/ipa-activate-all
- Create a
systemd
unit file,/etc/systemd/system/ipa-activate-all.service
, with the following contents:[Unit] Description=Scan IdM every minute for any stage users that must be activated [Service] Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all ExecStart=/usr/local/sbin/ipa-activate-all
- Create a
systemd
timer,/etc/systemd/system/ipa-activate-all.timer
, with the following contents:[Unit] Description=Scan IdM every minute for any stage users that must be activated [Timer] OnBootSec=15min OnUnitActiveSec=1min [Install] WantedBy=multi-user.target
- Enable
ipa-activate-all.timer
:# systemctl enable ipa-activate-all.timer
Additional resources:
- For more information on
systemd
unit files, see the Managing Services with systemd Unit Files chapter of the System Administrator's Guide.
11.6.3. Configuring the LDAP Provider of the External Provisioning System to Manage the IdM Identities
This section shows templates for various user and group management operations. Using these templates, you can configure the LDAP provider of your provisioning system to manage IdM user accounts. For example, you can configure the system to inactivate a user account after the employee has left the company.
Managing User Accounts Using LDAP
You can add new user entries, modify existing entries, move users between different life cycle states, or delete users by editing the underlying Directory Server database. To edit the database, use the
ldapmodify
utility.
The following LDIF-formatted templates provide information on what attributes to modify using
ldapmodify
. For detailed example procedures, see Example 11.2, “Adding a Stage User with ldapmodify
” and Example 11.3, “Preserving a User with ldapmodify
”.
- Adding a new stage user
- Adding a user with UID and GID automatically assigned:
dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: user_login sn: surname givenName: first_name cn: full_name
Adding a user with UID and GID statically assigned:dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: posixaccount uid: user_login uidNumber: UID_number gidNumber: GID_number sn: surname givenName: first_name cn: full_name homeDirectory: /home/user_login
You are not required to specify any IdM object classes when adding stage users. IdM adds these classes automatically after the users are activated.Note that the distinguished name (DN) of the created entry must start withuid=user_login
. - Modifying existing users
- Before modifying a user, obtain the user's distinguished name (DN) by searching by the user's login. In the following example, the user_allowed_to_read user in the following example is a user allowed to read user and group information, and password is this user's password:
# ldapsearch -LLL -x -D "uid=user_allowed_to_read,cn=users,cn=accounts,dc=example, dc=com" -w "password" -H ldap://server.example.com -b "cn=users, cn=accounts, dc=example, dc=com" uid=user_login
To modify a user's attribute:dn: distinguished_name changetype: modify replace: attribute_to_modify attribute_to_modify: new_value
To disable a user:dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: TRUE
To enable a user:dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: FALSE
To preserve a user:dn: distinguished_name changetype: modrdn newrdn: uid=user_login deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
Updating thenssAccountLock
attribute has no effect on stage and preserved users. Even though the update operation completes successfully, the attribute value remainsnssAccountLock: TRUE
. - Creating a new group
- To create a new group:
dn: cn=group_distinguished_name,cn=groups,cn=accounts,dc=example,dc=com changetype: add objectClass: top objectClass: ipaobject objectClass: ipausergroup objectClass: groupofnames objectClass: nestedgroup objectClass: posixgroup cn: group_name gidNumber: GID_number
- Modifying groups
- Before modifying a group, obtain the group's distinguished name (DN) by searching by the group's name.
# ldapsearch -YGSSAPI -H ldap://server.example.com -b "cn=groups,cn=accounts,dc=example,dc=com" "cn=group_name"
To delete an existing group:dn: group_distinguished_name changetype: delete
To add a member to a group:dn: group_distinguished_name changetype: modify add: member member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
To remove a member from a group:dn: distinguished_name changetype: modify delete: member member: uid=user_login,cn=users,cn=accounts,dc=example,dc=com
Do not add stage or preserved users to groups. Even though the update operation completes successfully, the users will not be updated as members of the group. Only active users can belong to groups.
Example 11.2. Adding a Stage User with ldapmodify
To add a new
stageuser
user using the standard interorgperson
object class:
- Use
ldapmodify
to add the user.# ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE SASL SSF: 56 SASL data security layer installed. dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example changetype: add objectClass: top objectClass: inetorgperson cn: Stage sn: User adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example"
- Consider validating the contents of the stage entry to make sure your provisioning system added all required POSIX attributes and the stage entry is ready to be activated. To display the new stage user's LDAP attributes using the ipa stageuser-show --all --raw command. Note that the user is explicitly disabled by the
nsaccountlock
attribute:$ ipa stageuser-show stageuser --all --raw dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=example uid: stageuser sn: User cn: Stage has_password: FALSE has_keytab: FALSE nsaccountlock: TRUE objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person
Example 11.3. Preserving a User with ldapmodify
To preserve
user
by using the LDAP modrdn
operation:
- Use the
ldapmodify
utility to modify the user entry.$ ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin@EXAMPLE SASL SSF: 56 SASL data security layer installed. dn: uid=user1,cn=users,cn=accounts,dc=example changetype: modrdn newrdn: uid=user1 deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=example"
- Optionally, verify the user has been preserved by listing all preserved users.
$ ipa user-find --preserved=true --------------- 1 user matched --------------- User login: user1 First name: first_name Last name: last_name ... ---------------------------- Number of entries returned 1 ----------------------------