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: Section 11.6.1, "Configuring User Accounts to Be Used by the External Provisioning System" Section 11.6.2, "Configuring IdM to Automatically Activate Stage User Accounts" Section 11.6.3, "Configuring the LDAP Provider of the External Provisioning System to Manage the IdM Identities" 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: Grant the provisionator user the required privileges. Create a custom role, System Provisioning , to manage adding stage users: Add the Stage User Provisioning privilege to the role. This privilege provides the ability to add stage users: Add the provisionator user to the role: 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: Grant the activator user the required privileges. Add the user to the default User Administrator role: Create a user group for service and application 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: Add the provisioning and activation accounts to the group for service and application accounts: Change the passwords for the user accounts: 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: 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: Edit the permissions and ownership for the ipa-activate-all script to make it executable: Create a systemd unit file, /etc/systemd/system/ipa-activate-all.service , with the following contents: Create a systemd timer, /etc/systemd/system/ipa-activate-all.timer , with the following contents: 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: Adding a user with UID and GID statically assigned: 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 with uid= 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: To modify a user's attribute: To disable a user: To enable a user: To preserve a user: Updating the nssAccountLock attribute has no effect on stage and preserved users. Even though the update operation completes successfully, the attribute value remains nssAccountLock: TRUE . Creating a new group To create a new group: Modifying groups Before modifying a group, obtain the group's distinguished name (DN) by searching by the group's name. To delete an existing group: To add a member to a group: To remove a member from a group: 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. 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: 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. Optionally, verify the user has been preserved by listing all preserved users.

Commands:
ipa user-add provisionator --first=provisioning --last=account --password
ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"
ipa role-add-privilege "System Provisioning" --privileges="Stage User Provisioning"
ipa role-add-member --users=provisionator "System Provisioning"
ipa user-add activator --first=activation --last=account --password
ipa role-add-member --users=activator "User Administrator"
ipa group-add service-accounts
ipa pwpolicy-add service-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=20 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
ipa group-add-member service-accounts --users={provisionator,activator}
kpasswd provisionator kpasswd activator
ipa-getkeytab -s example.com -p "activator" -k /etc/krb5.ipa-activation.keytab
#!/bin/bash kinit -k -i activator ipa stageuser-find --all --raw | grep " uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate USD{uid}; done
chmod 755 /usr/local/sbin/ipa-activate-all chown root:root /usr/local/sbin/ipa-activate-all
[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
[Unit] Description=Scan IdM every minute for any stage users that must be activated [Timer] OnBootSec=15min OnUnitActiveSec=1min [Install] WantedBy=multi-user.target
systemctl enable ipa-activate-all.timer
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
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
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
dn: distinguished_name changetype: modify replace: attribute_to_modify attribute_to_modify: new_value
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: TRUE
dn: distinguished_name changetype: modify replace: nsAccountLock nsAccountLock: FALSE
dn: distinguished_name changetype: modrdn newrdn: uid= user_login deleteoldrdn: 0 newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=example
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
ldapsearch -YGSSAPI -H ldap:// server.example.com -b "cn=groups,cn=accounts,dc=example,dc=com" "cn= group_name "
dn: group_distinguished_name changetype: delete
dn: group_distinguished_name changetype: modify add: member member: uid= user_login ,cn=users,cn=accounts,dc=example,dc=com
dn: distinguished_name changetype: modify delete: member member: uid= user_login ,cn=users,cn=accounts,dc=example,dc=com
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"
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
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"
ipa user-find --preserved=true --------------- 1 user matched --------------- User login: user1 First name: first_name Last name: last_name ---------------------------- Number of entries returned 1 ----------------------------