Chapter 40. 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:
40.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:
$ kinit admin
Create a user named provisionator with the privileges to add 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 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"
- Verify that the provisionator exists in IdM:
$ ipa user-find provisionator --all --raw -------------- 1 user matched -------------- dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com uid: provisionator [...]
Create a user, activator, with the privileges to manage user accounts.
Add the activator user account:
$ ipa user-add activator --first=activation --last=account --password
Grant the activator user the required privileges by adding the user to the default
User Administrator
role:$ ipa role-add-member --users=activator "User Administrator"
Create a user group for application accounts:
$ ipa group-add 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:
$ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
Optional: Verify that the password policy exists in IdM:
$ ipa pwpolicy-show application-accounts Group: application-accounts Max lifetime (days): 10000 Min lifetime (hours): 0 History size: 0 [...]
Add the provisioning and activation accounts to the group for application accounts:
$ ipa group-add-member application-accounts --users={provisionator,activator}
Change the passwords for the user accounts:
$ kpasswd provisionator $ kpasswd activator
Changing the passwords is necessary because new IdM users passwords expire immediately.
Additional resources:
40.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.
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:
# ipa-getkeytab -s server.idm.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 of 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
Reload the new configuration:
# systemctl daemon-reload
Enable
ipa-activate-all.timer
:# systemctl enable ipa-activate-all.timer
Start
ipa-activate-all.timer
:# systemctl start ipa-activate-all.timer
Optional: Verify that the
ipa-activate-all.timer
daemon is running:# 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.
40.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
-
The
Procedure
On the external server, create an LDIF file that contains information about the new user:
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
Transfer the LDIF file from the external server to the IdM server:
$ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/ Password: add-stageidmuser.ldif 100% 364 217.6KB/s 00:00
Use the
SSH
protocol to connect to the IdM server as provisionator:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
On the IdM server, obtain the Kerberos ticket-granting ticket (TGT) for the provisionator account:
[provisionator@server ~]$ kinit provisionator
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:~]$ 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"
40.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
-
The
Procedure
Use the
SSH
protocol to connect to the IdM server using your IdM identity and credentials:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
Obtain the TGT of the provisionator account, an IdM user with a role to add new stage users:
$ kinit provisionator
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:# 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.
Enter the
dn
of the user you are adding:dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Enter add as the type of change you are performing:
changetype: add
Specify the LDAP object class categories required to allow the correct processing of the user life cycle:
objectClass: top objectClass: inetorgperson
You can specify additional object classes.
Enter the
uid
of the user:uid: stageuser
Enter the
cn
of the user:cn: Babs Jensen
Enter the last name of the user:
sn: Jensen
Press
Enter
again to confirm that this is the end of the entry:[Enter] adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
- 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:$ 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
-
Note that the user is explicitly disabled by the
nsaccountlock
attribute.
-
Note that the user is explicitly disabled by the