Chapter 12. Configuring IdM for external provisioning of users As a system administrator, you can configure Identity Management (IdM) to support the provisioning of users by an external solution for managing identities. Rather than use the ipa utility, the administrator of the external provisioning system can access the IdM LDAP using the ldapmodify utility. The administrator can add individual stage users from the CLI using ldapmodify or using an LDIF file . The assumption is that you, as an IdM administrator, fully trust your external provisioning system to only add validated users. However, at the same time you do not want to assign the administrators of the external provisioning system the IdM role of User Administrator to enable them to add new active users directly. You can configure a script to automatically move the staged users created by the external provisioning system to active users automatically. This chapter contains these sections: Preparing Identity Management (IdM) to use an external provisioning system to add stage users to IdM. Creating a script to move the users added by the external provisioning system from stage to active users. Using an external provisioning system to add an IdM stage user. You can do that in two ways: Add an IdM stage user using an LDIF file Add an IdM stage user directly from the CLI using ldapmodify 12.1. Preparing IdM accounts for automatic activation of stage user accounts This procedure shows how to configure two IdM user accounts to be used by an 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. In the following, the user account to be used by the external system to add stage users is named provisionator . The user account to be used to automatically activate the stage users is named activator . Prerequisites The host on which you perform the procedure is enrolled into IdM. Procedure Log in as IdM administrator: Create a user named provisionator with the privileges to add 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: Verify that the provisionator exists in IdM: Create a user, activator , with the privileges to manage user accounts. Add the activator user account: Grant the activator user the required privileges by adding the user to the default User Administrator role: Create a user group for 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: Optional: Verify that the password policy exists in IdM: Add the provisioning and activation accounts to the group for application accounts: Change the passwords for the user accounts: Changing the passwords is necessary because new IdM users passwords expire immediately. Additional resources: See Managing user accounts using the command line . See Delegating Permissions over Users . See Defining IdM Password Policies . 12.2. Configuring automatic activation of IdM 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 owner of the external provisioning system has already validated the users and that they do not require additional validation on the IdM side before the script adds them to IdM. It is sufficient to enable the activation process on only one of your IdM servers. Prerequisites The provisionator and activator accounts exist in IdM. For details, see Preparing IdM accounts for automatic activation of stage user accounts . You have root privileges on the IdM server on which you are running the procedure. You are logged in as IdM administrator. You trust your external provisioning system. Procedure 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 of 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: Reload the new configuration: Enable ipa-activate-all.timer : Start ipa-activate-all.timer : Optional: Verify that the ipa-activate-all.timer daemon is running: 12.3. Adding an IdM stage user defined in an LDIF file Follow this procedure to access IdM LDAP and use an LDIF file to add stage users. While the example below shows adding one single user, multiple users can be added in one file in bulk mode. Prerequisites IdM administrator has created the provisionator account and a password for it. For details, see Preparing IdM accounts for automatic activation of stage user accounts . You as the external administrator know the password of the provisionator account. You can SSH to the IdM server from your LDAP server. You are able to supply the minimal set of attributes that an IdM stage user must have to allow the correct processing of the user life cycle, namely: The distinguished name (dn) The common name (cn) The last name (sn) The uid Procedure On the external server, create an LDIF file that contains information about the new user: Transfer the LDIF file from the external server to the IdM server: Use the SSH protocol to connect to the IdM server as provisionator : On the IdM server, obtain the Kerberos ticket-granting ticket (TGT) for the provisionator account: Enter the ldapadd command with the -f option and the name of the LDIF file. Specify the name of the IdM server and the port number: 12.4. Adding an IdM stage user directly from the CLI using ldapmodify Follow this procedure to access access Identity Management (IdM) LDAP and use the ldapmodify utility to add a stage user. Prerequisites The IdM administrator has created the provisionator account and a password for it. For details, see Preparing IdM accounts for automatic activation of stage user accounts . You as the external administrator know the password of the provisionator account. You can SSH to the IdM server from your LDAP server. You are able to supply the minimal set of attributes that an IdM stage user must have to allow the correct processing of the user life cycle, namely: The distinguished name (dn) The common name (cn) The last name (sn) The uid Procedure Use the SSH protocol to connect to the IdM server using your IdM identity and credentials: Obtain the TGT of the provisionator account, an IdM user with a role to add new stage users: Enter the ldapmodify command and specify Generic Security Services API (GSSAPI) as the Simple Authentication and Security Layer (SASL) mechanism to use for authentication. Specify the name of the IdM server and the port: Enter the dn of the user you are adding: Enter add as the type of change you are performing: Specify the LDAP object class categories required to allow the correct processing of the user life cycle: You can specify additional object classes. Enter the uid of the user: Enter the cn of the user: Enter the last name of the user: Press Enter again to confirm that this is the end of the entry: Exit the connection using Ctrl + C . Verification Verify 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, enter the ipa stageuser-show --all --raw command: Note that the user is explicitly disabled by the nsaccountlock attribute. 12.5. Additional resources See Using ldapmodify to manage IdM users externally .

Commands:
kinit admin
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-find provisionator --all --raw -------------- 1 user matched -------------- dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com uid: provisionator [...]
ipa user-add activator --first=activation --last=account --password
ipa role-add-member --users=activator "User Administrator"
ipa group-add application-accounts
ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
ipa pwpolicy-show application-accounts Group: application-accounts Max lifetime (days): 10000 Min lifetime (hours): 0 History size: 0 [...]
ipa group-add-member application-accounts --users={provisionator,activator}
kpasswd provisionator kpasswd activator
ipa-getkeytab -s server.idm.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 daemon-reload
systemctl enable ipa-activate-all.timer
systemctl start ipa-activate-all.timer
systemctl status ipa-activate-all.timer ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled) Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.
dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com changetype: add objectClass: top objectClass: inetorgperson uid: stageidmuser sn: surname givenName: first_name cn: full_name
scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/ Password: add-stageidmuser.ldif 100% 364 217.6KB/s 00:00
ssh provisionator@server.idm.example.com Password: [provisionator@server ~]USD
[provisionator@server ~]USD kinit provisionator
~]USD ldapadd -h server.idm.example.com -p 389 -f add-stageidmuser.ldif SASL/GSSAPI authentication started SASL username: provisionator@IDM.EXAMPLE.COM SASL SSF: 256 SASL data security layer installed. adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
ssh provisionator@server.idm.example.com Password: [provisionator@server ~]USD
kinit provisionator
ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI SASL/GSSAPI authentication started SASL username: provisionator@IDM.EXAMPLE.COM SASL SSF: 56 SASL data security layer installed.
dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
changetype: add
objectClass: top objectClass: inetorgperson
uid: stageuser
cn: Babs Jensen
sn: Jensen
[Enter] adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
ipa stageuser-show stageuser --all --raw dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com uid: stageuser sn: Jensen cn: Babs Jensen has_password: FALSE has_keytab: FALSE nsaccountlock: TRUE objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person