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.
  1. 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.
    1. Add the provisionator user account:
      $ ipa user-add provisionator --first=provisioning --last=account --password
    2. 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 the Stage 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 the provisionator user to the role:
      $ ipa role-add-member --users=provisionator "System Provisioning"
  2. 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.
    1. Add the activator user account:
      $ ipa user-add activator --first=activation --last=account --password
    2. Grant the activator user the required privileges.
      Add the user to the default User Administrator role:
      $ ipa role-add-member --users=activator "User Administrator"
  3. Create a user group for service and application accounts:
    $ ipa group-add service-accounts
  4. 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
  5. Add the provisioning and activation accounts to the group for service and application accounts:
    $ ipa group-add-member service-accounts --users={provisionator,activator}
  6. 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:

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.
  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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
  6. Enable ipa-activate-all.timer:
    # systemctl enable ipa-activate-all.timer
Additional resources:

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 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:
# 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 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:
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:
  1. 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"
    
  2. 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:
  1. 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"
    
  2. 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
    ----------------------------