Managing IdM users, groups, hosts, and access control rules

Procedure

1. Open a terminal and connect to the IdM server.

2. Enter ipa help topics to display a list of topics covered by help.

   $ ipa help topics

3. Select one of the topics and create a command according to the following pattern: ipa help [topic_name]. Instead of the topic_name string, add one of the topics you listed in the previous step.

   In the example, we use the following topic: user

   $ ipa help user

4. If the IPA help output is too long and you cannot see the whole text, use the following syntax:

   $ ipa help user | less

   You can then scroll down and read the whole help.

Procedure

1. Open a terminal and connect to the IdM server.

2. Enter ipa help commands to display a list of commands covered by help.

   $ ipa help commands

3. Select one of the commands and create a help command according to the following pattern: ipa help <COMMAND>. Instead of the <COMMAND> string, add one of the commands you listed in the previous step.

   $ ipa help user-add

Procedure

1. Open a terminal and connect to the IdM server.

2. Enter the command for adding a new user:

   $ ipa user-add

   The command runs a script that prompts you to provide basic data necessary for creating a user account.

3. In the First name: field, enter the first name of the new user and press the Enter key.
4. In the Last name: field, enter the last name of the new user and press the Enter key.

5. In the User login [suggested user name]: enter the user name, or just press the Enter key to accept the suggested user name.

   The user name must be unique for the whole IdM database. If an error occurs because that user name already exists, repeat the process with the ipa user-add command and use a different, unique user name.

Procedure

1. Open a terminal and connect to the IdM server.

2. Enter the ipa user-mod command, specify the user to modify, and any options, such as --password for adding a password:

   $ ipa user-mod euser --password

   The command runs a script where you can add the new password.

3. Enter the new password and press the Enter key.

Procedure

1. Open terminal and connect to the IdM server.

2. Add user login, user’s first name, last name and optionally, you can also add their email address.

   $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

   IdM supports user names that can be described by the following regular expression:

   [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?

   Note

   User names ending with the trailing dollar sign ($) are supported to enable Samba 3.x machine support.

   If you add a user name containing uppercase characters, IdM automatically converts the name to lowercase when saving it. Therefore, IdM always requires to enter user names in lowercase when logging in. Additionally, it is not possible to add user names which differ only in letter casing, such as user and User.

   The default maximum length for user names is 32 characters. To change it, use the ipa config-mod --maxusername command. For example, to increase the maximum user name length to 64 characters:

   $ ipa config-mod --maxusername=64
    Maximum username length: 64
    ...

   The ipa user-add command includes a lot of parameters. To list them all, use the ipa help command:

   $ ipa help user-add

   For details about ipa help command, see What is the IPA help.

Procedure

1. Open terminal and connect to the IdM server.

2. Activate the user account with the following command:

   $ ipa stageuser-activate user_login
   -------------------------
   Stage user user_login activated
   -------------------------
   ...

Procedure

1. Open terminal and connect to the IdM server.

2. Preserve the user account with the following command:

   $ ipa user-del --preserve user_login
   --------------------
   Deleted user "user_login"
   --------------------

   Note

   Despite the output saying the user account was deleted, it has been preserved.

Procedure

1. Open terminal and connect to the IdM server.

2. Delete the user account with the following command:

   $ ipa user-del user_login
   --------------------
   Deleted user "user_login"
   --------------------

Procedure

1. Open terminal and connect to the IdM server.

2. Activate the user account with the following command:

   $ ipa user-undel user_login
   ------------------------------
   Undeleted user account "user_login"
   ------------------------------

   Alternatively, you can restore user accounts as staged:

   $ ipa user-stage user_login
   ------------------------------
   Staged user account "user_login"
   ------------------------------

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Stage Users tab.

   Alternatively, you can add the user account in the Users → Active users, however, you cannot add user groups to the account.

3. Click the + Add icon.
4. In the Add stage user dialog box, enter First name and Last name of the new user.

5. Optional: In the User login field, add a login name.

   If you leave it empty, the IdM server creates the login name in the following pattern: The first letter of the first name and the surname. The whole login name can have up to 32 characters.

6. Optional: In the GID drop down menu, select groups in which the user should be included.
7. Optional: In the Password and Verify password fields, enter your password and confirm it, ensuring they both match.

8. Click on the Add button.

   

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Stage users tab.
3. Click the check-box of the user account you want to activate.

4. Click on the Activate button.

   

5. On the Confirmation dialog box, click OK.

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Active users tab.
3. Click the check-box of the user accounts you want to disable.

4. Click on the Disable button.

   

5. In the Confirmation dialog box, click on the OK button.

Procedure

1. Log in to the IdM Web UI.
2. Go to Users → Active users tab.
3. Click the check-box of the user accounts you want to enable.

4. Click on the Enable button.

   

5. In the Confirmation dialog box, click on the OK button.

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Active users tab.
3. Click the check-box of the user accounts you want to preserve.

4. Click on the Delete button.

   

5. In the Remove users dialog box, switch the Delete mode radio button to preserve.

6. Click on the Delete button.

   

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Preserved users tab.
3. Click the check-box at the user accounts you want to restore.

4. Click on the Restore button.

   

5. In the Confirmation dialog box, click on the OK button.

Procedure

1. Log in to the IdM Web UI.

   For details, see Accessing the IdM Web UI in a web browser.

2. Go to Users → Active users tab.

   Alternatively, you can delete the user account in the Users → Stage users or Users → Preserved users.

3. Click the Delete icon.
4. In the Remove users dialog box, switch the Delete mode radio button to delete.
5. Click on the Delete button.

Procedure

1. Create an inventory file, for example inventory.file, and define ipaserver in it:

   [ipaserver]
   server.idm.example.com

2. Create an Ansible playbook file with the data of the user whose presence in IdM you want to ensure. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml file. For example, to create user named idm_user and add Password123 as the user password:

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Create user idm_user
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: idm_user
         first: Alice
         last: Acme
         uid: 1000111
         gid: 10011
         phone: "+555123457"
         email: idm_user@acme.com
         passwordexpiration: "2023-01-19 23:59:59"
         password: "Password123"
         update_password: on_create

   You must use the following options to add a user:

   • name: the login name
   • first: the first name string
   • last: the last name string

   For the full list of available user options, see the /usr/share/doc/ansible-freeipa/README-user.md Markdown file.

   Note

   If you use the update_password: on_create option, Ansible only creates the user password when it creates the user. If the user is already created with a password, Ansible does not generate a new password.

3. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

Procedure

1. Create an inventory file, for example inventory.file, and define ipaserver in it:

   [ipaserver]
   server.idm.example.com

2. Create an Ansible playbook file with the data of the users whose presence you want to ensure in IdM. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml file. For example, to create users idm_user_1, idm_user_2, and idm_user_3, and add Password123 as the password of idm_user_1:

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Create user idm_users
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users:
         - name: idm_user_1
           first: Alice
           last: Acme
           uid: 10001
           gid: 10011
           phone: "+555123457"
           email: idm_user@acme.com
           passwordexpiration: "2023-01-19 23:59:59"
           password: "Password123"
         - name: idm_user_2
           first: Bob
           last: Acme
           uid: 100011
           gid: 10011
         - name: idm_user_3
           first: Eve
           last: Acme
           uid: 1000111
           gid: 10011

   Note

   If you do not specify the update_password: on_create option, Ansible re-sets the user password every time the playbook is run: if the user has changed the password since the last time the playbook was run, Ansible re-sets password.

3. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

Procedure

1. Create an inventory file, for example inventory.file, and define ipaserver in it:

   [ipaserver]
   server.idm.example.com

2. Create an Ansible playbook file with the necessary tasks. Reference the JSON file with the data of the users whose presence you want to ensure. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/README-user.md file:

1. Create the users.json file, and add the IdM users into it. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/README-user.md file. For example, to create users idm_user_1, idm_user_2, and idm_user_3, and add Password123 as the password of idm_user_1:

   {
     "users": [
      {
       "name": "idm_user_1",
       "first": "First 1",
       "last": "Last 1",
       "password": "Password123"
      },
      {
       "name": "idm_user_2",
       "first": "First 2",
       "last": "Last 2"
      },
      {
       "name": "idm_user_3",
       "first": "First 3",
       "last": "Last 3"
      }
     ]
   }

2. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

Procedure

1. Create an inventory file, for example inventory.file, and define ipaserver in it:

   [ipaserver]
   server.idm.example.com

2. Create an Ansible playbook file with the users whose absence from IdM you want to ensure. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml file. For example, to delete users idm_user_1, idm_user_2, and idm_user_3:

   ---
   - name: Playbook to handle users
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Delete users idm_user_1, idm_user_2, idm_user_3
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users:
         - name: idm_user_1
         - name: idm_user_2
         - name: idm_user_3
         state: absent

3. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

1. Log into ipaserver as administrator:

   $ ssh administrator@server.idm.example.com
   Password:
   [admin@server /]$

2. Request information about idm_user_1:

   $ ipa user-show idm_user_1
   ipa: ERROR: idm_user_1: user not found

   The user named idm_user_1 does not exist in IdM.

Procedure

1. Open the IPA Server tab.
2. Select the Configuration subtab.

3. Scroll to the User Options area.

   

4. Keep all the object classes listed in the Default IdM user object classes table.

   Important

   If any object classes required by IdM are not included, then subsequent attempts to add a user entry will fail with object class violations.

5. At the bottom of the users area, click Add for a new field to appear.

   

6. Enter the name of the user object class you want to add.
7. Click Save at the top of the Configuration page.

Procedure

1. Open the IPA Server tab.
2. Select the Configuration subtab.
3. Locate the Group Options area.

4. Keep the default IdM group object classes.

   Important

   If any group object classes required by IdM are not included, then subsequent attempts to add a group entry will fail with object class violations.

5. Click Add for a new field to appear.

   

6. Enter the name of the group object class you want to add.
7. Click Save at the top of the Configuration page.

Procedure

1. Open the IPA Server tab.
2. Select the Configuration subtab.

3. The User Options section has multiple fields you can review and edit.

   

4. For example, to change the default shell for future IdM users from /bin/sh to /bin/bash, locate the Default shell field, and replace /bin/sh with /bin/bash.

5. In the Group Options section, you can only review and edit the Group search fields field.

   

6. Click the Save button at the top of the screen.

   The newly saved configuration will be applied to future IdM user and group accounts. The current accounts remain unchanged.

Procedure

1. In the upper right corner, click User name → Change password.

   Figure 6.1. Resetting Password

   
2. Enter the current and new passwords.

Procedure

1. Select Identity → Users.
2. Click the name of the user to edit.

3. Click Actions → Reset password.

   Figure 6.2. Resetting Password

   

4. Enter the new password, and click Reset Password.

   Figure 6.3. Confirming New Password

   

Procedure

1. Generate a new password hash by using the pwdhash command. For example:

   # pwdhash -D /etc/dirsrv/slapd-IDM-EXAMPLE-COM password
   {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

   By specifying the path to the Directory Server configuration, you automatically use the password storage scheme set in the nsslapd-rootpwstoragescheme attribute to encrypt the new password.

2. On every IdM server in your topology, execute the following steps:

   1. Stop all IdM services installed on the server:

      # ipactl stop

   2. Edit the /etc/dirsrv/IDM-EXAMPLE-COM/dse.ldif file and set the nsslapd-rootpw attribute to the value generated by the pwdhash command:

      nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

   3. Start all IdM services installed on the server:

   # ipactl start

Procedure

1. On every Identity Management (IdM) server in the domain, make the following changes:

   1. Enter the ldapmodify command to modify LDAP entries. Specify the name of the IdM server and the 389 port and press Enter:

      $ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
      Enter LDAP Password:

   2. Enter the Directory Manager password.

   3. Enter the distinguished name for the ipa_pwd_extop password synchronization entry and press Enter:

      dn: cn=ipa_pwd_extop,cn=plugins,cn=config

   4. Specify the modify type of change and press Enter:

      changetype: modify

   5. Specify what type of modification you want LDAP to execute and to which attribute. Press Enter:

      add: passSyncManagersDNs

   6. Specify the administrative user accounts in the passSyncManagersDNs attribute. The attribute is multi-valued. For example, to grant the admin user the password resetting powers of Directory Manager:

      passSyncManagersDNs: \
      uid=admin,cn=users,cn=accounts,dc=example,dc=com

   7. Press Enter twice to stop editing the entry.

Procedure

1. Display the status of the user account to see the number of failed logins:

   $ ipa user-status example_user
   -----------------------
   Account disabled: False
   -----------------------
     Server: idm.example.com
     Failed logins: 8
     Last successful authentication: N/A
     Last failed authentication: 20220229080317Z
     Time now: 2022-02-29T08:04:46Z
   ----------------------------
   Number of entries returned 1
   ----------------------------

2. Display the number of allowed login attempts for a particular user:

   1. Log in to the IdM Web UI as IdM administrator.
   2. Open the Identity → Users → Active users tab.

   

   1. Click the user name to open the user settings.
   2. In the Password policy section, locate the Max failures item.
3. Compare the number of failed logins as displayed in the output of the ipa user-status command with the Max failures number displayed in the IdM Web UI. If the number of failed logins equals that of maximum allowed login attempts, the user account is locked.

Procedure

1. Display the currently enabled password plug-in features:

   # ipa config-show | grep "Password plugin features"
     Password plugin features: AllowNThash, KDC:Disable Last Success

   The output shows that the KDC:Disable Last Success plug-in is enabled. The plug-in hides the last successful Kerberos authentication attempt from being visible in the ipa user-status output.

2. Add the --ipaconfigstring=feature parameter for every feature to the ipa config-mod command that is currently enabled, except for KDC:Disable Last Success:

   # ipa config-mod --ipaconfigstring='AllowNThash'

   This command enables only the AllowNThash plug-in. To enable multiple features, specify the --ipaconfigstring=feature parameter separately for each feature.

3. Restart IdM:

   # ipactl restart

Procedure

1. Create an inventory file, for example inventory.file, and define the FQDN of your IdM server in the [ipaserver] section:

   [ipaserver]
   server.idm.example.com

2. Create your Ansible playbook file that defines the password policy whose presence you want to ensure. To simplify this step, copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml file:

   ---
   - name: Tests
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure presence of pwpolicy for group ops
       ipapwpolicy:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: ops
         minlife: 7
         maxlife: 49
         history: 5
         priority: 1
         lockouttime: 300
         minlength: 8
         minclasses: 4
         maxfail: 3
         failinterval: 5

   For details on what the individual variables mean, see Password policy attributes.

3. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Procedure

1. Apply the user name check to all new passwords suggested by the users in the managers group:

   $ ipa pwpolicy-mod --usercheck=True managers

   Note

   If you do not specify the name of the password policy, the default global_policy is modified.

2. Set the maximum number of identical consecutive characters to 2 in the managers password policy:

   $ ipa pwpolicy-mod --maxrepeat=2 managers

   A password now will not be accepted if it contains more than 2 identical consecutive characters. For example, the eR873mUi111YJQ combination is unacceptable because it contains three 1s in succession.

Verification

1. Add a test user named test_user:

   $ ipa user-add test_user
   First name: test
   Last name: user
   ----------------------------
   Added user "test_user"
   ----------------------------

2. Add the test user to the managers group:

   1. In the IdM Web UI, click Identity → Groups → User Groups.
   2. Click managers.
   3. Click Add.
   4. In the Add users into user group 'managers' page, check test_user.
   5. Click the > arrow to move the user to the Prospective column.
   6. Click Add.

3. Reset the password for the test user:

   1. Go to Identity → Users.
   2. Click test_user.
   3. In the Actions menu, click Reset Password.
   4. Enter a temporary password for the user.

4. On the command line, try to obtain a Kerberos ticket-granting ticket (TGT) for the test_user:

   $ kinit test_user

   1. Enter the temporary password.

   2. The system informs you that you must change your password. Enter a password that contains the user name of test_user:

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.

      Note

      Kerberos does not have fine-grained error password policy reporting and, in certain cases, does not provide a clear reason why a password was rejected.

   3. The system informs you that the entered password was rejected. Enter a password that contains three or more identical characters in succession:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:

   4. The system informs you that the entered password was rejected. Enter a password that meets the criteria of the managers password policy:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:

5. View the obtained TGT:

   $ klist
   Ticket cache: KCM:0:33945
   Default principal: test_user@IDM.EXAMPLE.COM
   
   Valid starting       Expires              Service principal
   07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

Procedure

1. Create your Ansible playbook file manager_pwpolicy_present.yml that defines the password policy whose presence you want to ensure. To simplify this step, copy and modify the following example:

   ---
   - name: Tests
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure presence of usercheck and maxrepeat pwpolicy for group managers
       ipapwpolicy:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: managers
         usercheck: True
         maxrepeat: 2
         maxsequence: 3

2. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/manager_pwpolicy_present.yml

Verification

1. Add a test user named test_user:

   $ ipa user-add test_user
   First name: test
   Last name: user
   ----------------------------
   Added user "test_user"
   ----------------------------

2. Add the test user to the managers group:

   1. In the IdM Web UI, click Identity → Groups → User Groups.
   2. Click managers.
   3. Click Add.
   4. In the Add users into user group 'managers' page, check test_user.
   5. Click the > arrow to move the user to the Prospective column.
   6. Click Add.

3. Reset the password for the test user:

   1. Go to Identity → Users.
   2. Click test_user.
   3. In the Actions menu, click Reset Password.
   4. Enter a temporary password for the user.

4. On the command line, try to obtain a Kerberos ticket-granting ticket (TGT) for the test_user:

   $ kinit test_user

   1. Enter the temporary password.

   2. The system informs you that you must change your password. Enter a password that contains the user name of test_user:

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.

      Note

      Kerberos does not have fine-grained error password policy reporting and, in certain cases, does not provide a clear reason why a password was rejected.

   3. The system informs you that the entered password was rejected. Enter a password that contains three or more identical characters in succession:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:

   4. The system informs you that the entered password was rejected. Enter a password that contains a monotonic character sequence longer than 3 characters. Examples of such sequences include 1234 and fedc:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:

   5. The system informs you that the entered password was rejected. Enter a password that meets the criteria of the managers password policy:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:

5. Verify that you have obtained a TGT, which is only possible after having entered a valid password:

   $ klist
   Ticket cache: KCM:0:33945
   Default principal: test_user@IDM.EXAMPLE.COM
   
   Valid starting       Expires              Service principal
   07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

Procedure

1. Open the epn.conf configuration file.

   # vi /etc/ipa/epn.conf

2. Update the notify_ttls option as required. The default is to notify users whose passwords are expiring in 28, 14, 7, 3, and 1 day(s).

   notify_ttls = 28, 14, 7, 3, 1

   NOTE

   You must also activate the ipa-epn.timer tool to ensure that emails are sent.

3. Configure your SMTP server and port:

   smtp_server = localhost
   smtp_port = 25

4. Specify the email address from which the email expiration notification is sent. Any unsuccessfully delivered emails are returned to this address.

   mail_from = admin-email@example.com

5. [Optional] If you want to use an encrypted channel of communication, specify the credentials to be used:

   • Specify the path to a single file in PEM format containing the certificate to be used by EPN to authenticate with the SMTP server:

     smtp_client_cert = /etc/pki/tls/certs/client.pem

     NOTE

     EPN is an SMTP client. The purpose of the certificate is client authentication, not secure SMTP delivery.

   • You can specify the path to a file that contains the private key. If not specified, the private key is taken from the certificate file.

     smtp_client_key = /etc/pki/tls/certs/client.key

   • If the private key is encrypted, specify the password for decrypting it.

     smtp_client_key_pass = Secret123!

6. Save the /etc/ipa/epn.conf file.

7. Run the EPN tool in dry-run mode to generate a list of the users to whom the password expiration email notification would be sent if you run the tool without the --dry-run option.

   ipa-epn --dry-run
   [
       {
        "uid": "user5",
        "cn": "user 5",
        "krbpasswordexpiration": "2020-04-17 15:51:53",
        "mail": "['user5@ipa.test']"
       }
   ]
   [
       {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
        }
   ]
   The IPA-EPN command was successful

   Note

   If the list of users returned is very large and you run the tool without the --dry-run option, this might cause an issue with your email server.

8. Run the EPN tool without the --dry-run option to send expiration emails to the list of all the users returned when you ran the EPN tool in dry-run mode:

   ipa-epn
   [
     {
        "uid": "user5",
        "cn": "user 5",
        "krbpasswordexpiration": "2020-10-01 15:51:53",
        "mail": "['user5@ipa.test']"
     }
   ]
   [
     {
       "uid": "user6",
       "cn": "user 6",
       "krbpasswordexpiration": "2020-12-17 15:51:53",
       "mail": "['user5@ipa.test']"
     }
   ]
   The IPA-EPN command was successful

9. You can add EPN to any monitoring system and invoke it with the --from-nbdays and --to-nbdays options to determine how many users passwords are going to expire within a specific time frame:

   # ipa-epn --from-nbdays 8 --to-nbdays 12

   Note

   If you invoke the EPN tool with the --from-nbdays and --to-nbdays options, it is automatically executed in dry-run mode.

Procedure

1. Open the EPN message template:

   # vi /etc/ipa/epn/expire_msg.template

2. Update the template text as required.

   Hi {{ fullname }},
   
   Your password will expire on {{ expiration }}.
   
   Please change it as soon as possible.

   You can use the following variables in the template.

   • User ID: uid
   • Full name: fullname
   • First name: first
   • Last name: last
   • Password expiration date: expiration
3. Save the message template file.

Procedure

1. Retrieve a Kerberos ticket as the IdM admin.

   [root@idmclient ~]# kinit admin

2. Add the /usr/sbin/reboot command to the IdM database of sudo commands:

   [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
   -------------------------------------
   Added Sudo Command "/usr/sbin/reboot"
   -------------------------------------
     Sudo Command: /usr/sbin/reboot

3. Create a sudo rule named idm_user_reboot:

   [root@idmclient ~]# ipa sudorule-add idm_user_reboot
   ---------------------------------
   Added Sudo Rule "idm_user_reboot"
   ---------------------------------
     Rule name: idm_user_reboot
     Enabled: TRUE

4. Add the /usr/sbin/reboot command to the idm_user_reboot rule:

   [root@idmclient ~]# ipa sudorule-add-allow-command idm_user_reboot --sudocmds '/usr/sbin/reboot'
     Rule name: idm_user_reboot
     Enabled: TRUE
     Sudo Allow Commands: /usr/sbin/reboot
   -------------------------
   Number of members added 1
   -------------------------

5. Apply the idm_user_reboot rule to the IdM idmclient host:

   [root@idmclient ~]# ipa sudorule-add-host idm_user_reboot --hosts idmclient.idm.example.com
   Rule name: idm_user_reboot
   Enabled: TRUE
   Hosts: idmclient.idm.example.com
   Sudo Allow Commands: /usr/sbin/reboot
   -------------------------
   Number of members added 1
   -------------------------

6. Add the idm_user account to the idm_user_reboot rule:

   [root@idmclient ~]# ipa sudorule-add-user idm_user_reboot --users idm_user
   Rule name: idm_user_reboot
   Enabled: TRUE
   Users: idm_user
   Hosts: idmclient.idm.example.com
   Sudo Allow Commands: /usr/sbin/reboot
   -------------------------
   Number of members added 1
   -------------------------

7. Optional: Define the validity of the idm_user_reboot rule:

   1. To define the time at which a sudo rule starts to be valid, use the ipa sudorule-mod sudo_rule_name command with the --setattr sudonotbefore=DATE option. The DATE value must follow the yyyymmddHHMMSSZ format, with seconds specified explicitly. For example, to set the start of the validity of the idm_user_reboot rule to 31 December 2025 12:34:00, enter:

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotbefore=20251231123400Z

   2. To define the time at which a sudo rule stops being valid, use the --setattr sudonotafter=DATE option. For example, to set the end of the idm_user_reboot rule validity to 31 December 2026 12:34:00, enter:

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotafter=20261231123400Z

Verification

1. Log in to the idmclient host as the idm_user account.

2. Display which sudo rules the idm_user account is allowed to perform.

   [idm_user@idmclient ~]$ sudo -l
   Matching Defaults entries for idm_user on idmclient:
       !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
       env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
       env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
       env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
       env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
       env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
       secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
   
   User idm_user may run the following commands on idmclient:
       (root) /usr/sbin/reboot

3. Reboot the machine using sudo. Enter the password for idm_user when prompted:

   [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
   [sudo] password for idm_user:

1. Add the AD users or groups to a non-POSIX external IdM group.
2. Add the non-POSIX external IdM group to an IdM POSIX group.

Procedure

1. Create the ad_users group that contains the ad_users_external group with the administrator@ad-domain member:

   1. Optional: Create or select a corresponding group in the AD domain to use to manage AD users in the IdM realm. You can use multiple AD groups and add them to different groups on the IdM side.

   2. Create the ad_users_external group and indicate that it contains members from outside the IdM domain by adding the --external option:

      [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
      -------------------------------
      Added group "ad_users_external"
      -------------------------------
        Group name: ad_users_external
        Description: AD users external map

      Note

      Ensure that the external group that you specify here is an AD security group with a global or universal group scope as defined in the Active Directory security groups document. For example, the Domain users or Domain admins AD security groups cannot be used because their group scope is domain local.

   3. Create the ad_users group:

      [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
      ----------------------
      Added group "ad_users"
      ----------------------
        Group name: ad_users
        Description: AD users
        GID: 129600004

   4. Add the administrator@ad-domain.com AD user to ad_users_external as an external member:

      [root@ipaserver ~]# ipa group-add-member ad_users_external --external "administrator@ad-domain.com"
       [member user]:
       [member group]:
        Group name: ad_users_external
        Description: AD users external map
        External member: S-1-5-21-3655990580-1375374850-1633065477-513
      -------------------------
      Number of members added 1
      -------------------------

      The AD user must be identified by a fully-qualified name, such as DOMAIN\user_name or user_name@DOMAIN. The AD identity is then mapped to the AD SID for the user. The same applies to adding AD groups.

   5. Add ad_users_external to ad_users as a member:

      [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
        Group name: ad_users
        Description: AD users
        GID: 129600004
        Member groups: ad_users_external
      -------------------------
      Number of members added 1
      -------------------------

2. Grant the members of ad_users the permission to run /usr/sbin/reboot on the idmclient host:

   1. Add the /usr/sbin/reboot command to the IdM database of sudo commands:

      [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
      -------------------------------------
      Added Sudo Command "/usr/sbin/reboot"
      -------------------------------------
        Sudo Command: /usr/sbin/reboot

   2. Create a sudo rule named ad_users_reboot:

      [root@idmclient ~]# ipa sudorule-add ad_users_reboot
      ---------------------------------
      Added Sudo Rule "ad_users_reboot"
      ---------------------------------
        Rule name: ad_users_reboot
        Enabled: True

   3. Add the /usr/sbin/reboot command to the ad_users_reboot rule:

      [root@idmclient ~]# ipa sudorule-add-allow-command ad_users_reboot --sudocmds '/usr/sbin/reboot'
        Rule name: ad_users_reboot
        Enabled: True
        Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------

   4. Apply the ad_users_reboot rule to the IdM idmclient host:

      [root@idmclient ~]# ipa sudorule-add-host ad_users_reboot --hosts idmclient.idm.example.com
      Rule name: ad_users_reboot
      Enabled: True
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------

   5. Add the ad_users group to the ad_users_reboot rule:

      [root@idmclient ~]# ipa sudorule-add-user ad_users_reboot --groups ad_users
      Rule name: ad_users_reboot
      Enabled: TRUE
      User Groups: ad_users
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------

Verification

1. Log in to the idmclient host as administrator@ad-domain.com, an indirect member of the ad_users group:

   $ ssh administrator@ad-domain.com@ipaclient
   Password:

2. Optional: Display the sudo commands that administrator@ad-domain.com is allowed to execute:

   [administrator@ad-domain.com@idmclient ~]$ sudo -l
   Matching Defaults entries for administrator@ad-domain.com on idmclient:
       !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
       env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
       env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
       env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
       env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
       env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
       secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
   
   User administrator@ad-domain.com may run the following commands on idmclient:
       (root) /usr/sbin/reboot

3. Reboot the machine using sudo. Enter the password for administrator@ad-domain.com when prompted:

   [administrator@ad-domain.com@idmclient ~]$ sudo /usr/sbin/reboot
   [sudo] password for administrator@ad-domain.com:

Procedure

1. Add the /usr/sbin/reboot command to the IdM database of sudo commands:

   1. Navigate to Policy → Sudo → Sudo Commands.
   2. Click Add in the upper right corner to open the Add sudo command dialog box.

   3. Enter the command you want the user to be able to perform using sudo: /usr/sbin/reboot.

      Figure 9.1. Adding IdM sudo command

      
   4. Click Add.

2. Use the new sudo command entry to create a sudo rule to allow idm_user to reboot the idmclient machine:

   1. Navigate to Policy → Sudo → Sudo rules.
   2. Click Add in the upper right corner to open the Add sudo rule dialog box.
   3. Enter the name of the sudo rule: idm_user_reboot.
   4. Click Add and Edit.

   5. Specify the user:

      1. In the Who section, check the Specified Users and Groups radio button.
      2. In the User category the rule applies to subsection, click Add to open the Add users into sudo rule "idm_user_reboot" dialog box.
      3. In the Add users into sudo rule "idm_user_reboot" dialog box in the Available column, check the idm_user checkbox, and move it to the Prospective column.
      4. Click Add.

   6. Specify the host:

      1. In the Access this host section, check the Specified Hosts and Groups radio button.
      2. In the Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "idm_user_reboot" dialog box.
      3. In the Add hosts into sudo rule "idm_user_reboot" dialog box in the Available column, check the idmclient.idm.example.com checkbox, and move it to the Prospective column.
      4. Click Add.

   7. Specify the commands:

      1. In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
      2. In the Sudo Allow Commands subsection, click Add to open the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box.
      3. In the Add allow sudo commands into sudo rule "idm_user_reboot" dialog box in the Available column, check the /usr/sbin/reboot checkbox, and move it to the Prospective column.
      4. Click Add to return to the idm_sudo_reboot page.

      Figure 9.2. Adding IdM sudo rule

      
   8. Click Save in the top left corner.

Verification

1. Log in to idmclient as idm_user.

2. Reboot the machine using sudo. Enter the password for idm_user when prompted:

   $ sudo /usr/sbin/reboot
   [sudo] password for idm_user:

Procedure

1. Retrieve a Kerberos ticket as the IdM admin.

   [root@idmclient ~]# kinit admin

2. Add the /opt/third-party-app/bin/report command to the IdM database of sudo commands:

   [root@idmclient ~]# ipa sudocmd-add /opt/third-party-app/bin/report
   ----------------------------------------------------
   Added Sudo Command "/opt/third-party-app/bin/report"
   ----------------------------------------------------
     Sudo Command: /opt/third-party-app/bin/report

3. Create a sudo rule named run_third-party-app_report:

   [root@idmclient ~]# ipa sudorule-add run_third-party-app_report
   --------------------------------------------
   Added Sudo Rule "run_third-party-app_report"
   --------------------------------------------
     Rule name: run_third-party-app_report
     Enabled: TRUE

4. Use the --users=<user> option to specify the RunAs user for the sudorule-add-runasuser command:

   [root@idmclient ~]# ipa sudorule-add-runasuser run_third-party-app_report --users=thirdpartyapp
     Rule name: run_third-party-app_report
     Enabled: TRUE
     RunAs External User: thirdpartyapp
   -------------------------
   Number of members added 1
   -------------------------

   The user (or group specified with the --groups=* option) can be external to IdM, such as a local service account or an Active Directory user. Do not add a % prefix for group names.

5. Add the /opt/third-party-app/bin/report command to the run_third-party-app_report rule:

   [root@idmclient ~]# ipa sudorule-add-allow-command run_third-party-app_report --sudocmds '/opt/third-party-app/bin/report'
   Rule name: run_third-party-app_report
   Enabled: TRUE
   Sudo Allow Commands: /opt/third-party-app/bin/report
   RunAs External User: thirdpartyapp
   -------------------------
   Number of members added 1
   -------------------------

6. Apply the run_third-party-app_report rule to the IdM idmclient host:

   [root@idmclient ~]# ipa sudorule-add-host run_third-party-app_report --hosts idmclient.idm.example.com
   Rule name: run_third-party-app_report
   Enabled: TRUE
   Hosts: idmclient.idm.example.com
   Sudo Allow Commands: /opt/third-party-app/bin/report
   RunAs External User: thirdpartyapp
   -------------------------
   Number of members added 1
   -------------------------

7. Add the idm_user account to the run_third-party-app_report rule:

   [root@idmclient ~]# ipa sudorule-add-user run_third-party-app_report --users idm_user
   Rule name: run_third-party-app_report
   Enabled: TRUE
   Users: idm_user
   Hosts: idmclient.idm.example.com
   Sudo Allow Commands: /opt/third-party-app/bin/report
   RunAs External User: thirdpartyapp
   -------------------------
   Number of members added 1

Verification

1. Log in to the idmclient host as the idm_user account.

2. Test the new sudo rule:

   1. Display which sudo rules the idm_user account is allowed to perform.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report

   2. Run the report command as the thirdpartyapp service account.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

Procedure

1. Add the /opt/third-party-app/bin/report command to the IdM database of sudo commands:

   1. Navigate to Policy → Sudo → Sudo Commands.
   2. Click Add in the upper right corner to open the Add sudo command dialog box.

   3. Enter the command: /opt/third-party-app/bin/report.

      
   4. Click Add.

2. Use the new sudo command entry to create the new sudo rule:

   1. Navigate to Policy → Sudo → Sudo rules.
   2. Click Add in the upper right corner to open the Add sudo rule dialog box.

   3. Enter the name of the sudo rule: run_third-party-app_report.

      
   4. Click Add and Edit.

   5. Specify the user:

      1. In the Who section, check the Specified Users and Groups radio button.
      2. In the User category the rule applies to subsection, click Add to open the Add users into sudo rule "run_third-party-app_report" dialog box.

      3. In the Add users into sudo rule "run_third-party-app_report" dialog box in the Available column, check the idm_user checkbox, and move it to the Prospective column.

         
      4. Click Add.

   6. Specify the host:

      1. In the Access this host section, check the Specified Hosts and Groups radio button.
      2. In the Host category this rule applies to subsection, click Add to open the Add hosts into sudo rule "run_third-party-app_report" dialog box.

      3. In the Add hosts into sudo rule "run_third-party-app_report" dialog box in the Available column, check the idmclient.idm.example.com checkbox, and move it to the Prospective column.

         
      4. Click Add.

   7. Specify the commands:

      1. In the Command category the rule applies to subsection of the Run Commands section, check the Specified Commands and Groups radio button.
      2. In the Sudo Allow Commands subsection, click Add to open the Add allow sudo commands into sudo rule "run_third-party-app_report" dialog box.

      3. In the Add allow sudo commands into sudo rule "run_third-party-app_report" dialog box in the Available column, check the /opt/third-party-app/bin/report checkbox, and move it to the Prospective column.

         
      4. Click Add to return to the run_third-party-app_report page.

   8. Specify the RunAs user:

      1. In the As Whom section, check the Specified Users and Groups radio button.
      2. In the RunAs Users subsection, click Add to open the Add RunAs users into sudo rule "run_third-party-app_report" dialog box.

      3. In the Add RunAs users into sudo rule "run_third-party-app_report" dialog box, enter the thirdpartyapp service account in the External box and move it to the Prospective column.

         
      4. Click Add to return to the run_third-party-app_report page.
   9. Click Save in the top left corner.

Verification

1. Log in to the idmclient host as the idm_user account.

2. Test the new sudo rule:

   1. Display which sudo rules the idm_user account is allowed to perform.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report

   2. Run the report command as the thirdpartyapp service account.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

Procedure

1. Open the /etc/sssd/sssd.conf configuration file.

2. Add the following entry to the [domain/<domain_name>] section.

   [domain/<domain_name>]
   pam_gssapi_services = sudo, sudo-i

3. Save and close the /etc/sssd/sssd.conf file.

4. Restart the SSSD service to load the configuration changes.

   [root@idmclient ~]# systemctl restart sssd

5. On RHEL 8.8 or later:

   1. Optional: Determine if you have selected the sssd authselect profile:

      # authselect current
      Profile ID: sssd

   2. If the sssd authselect profile is selected, enable GSSAPI authentication:

      # authselect enable-feature with-gssapi

   3. If the sssd authselect profile is not selected, select it and enable GSSAPI authentication:

      # authselect select sssd with-gssapi

6. On RHEL 8.7 or earlier:

   1. Open the /etc/pam.d/sudo PAM configuration file.

   2. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo file.

      #%PAM-1.0
      auth sufficient pam_sss_gss.so
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth

   3. Save and close the /etc/pam.d/sudo file.

Verification

1. Log into the host as the idm_user account.

   [root@idm-client ~]# ssh -l idm_user@idm.example.com localhost
   idm_user@idm.example.com's password:

2. Verify that you have a ticket-granting ticket as the idm_user account.

   [idmuser@idmclient ~]$ klist
   Ticket cache: KCM:1366201107
   Default principal: idm_user@IDM.EXAMPLE.COM
   
   Valid starting       Expires              Service principal
   01/08/2021 09:11:48  01/08/2021 19:11:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
   	renew until 01/15/2021 09:11:44

3. Optional: If you do not have Kerberos credentials for the idm_user account, delete your current Kerberos credentials and request the correct ones.

   [idm_user@idmclient ~]$ kdestroy -A
   
   [idm_user@idmclient ~]$ kinit idm_user@IDM.EXAMPLE.COM
   Password for idm_user@idm.example.com:

4. Reboot the machine using sudo, without specifying a password.

   [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

Procedure

1. Open the /etc/sssd/sssd.conf configuration file.

2. Add the following entries to the [domain/<domain_name>] section.

   [domain/<domain_name>]
   pam_gssapi_services = sudo, sudo-i
   pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit

3. Save and close the /etc/sssd/sssd.conf file.

4. Restart the SSSD service to load the configuration changes.

   [root@idmclient ~]# systemctl restart sssd

5. On RHEL 8.8 or later:

   1. Determine if you have selected the sssd authselect profile:

      # authselect current
      Profile ID: sssd

   2. Optional: Select the sssd authselect profile:

      # authselect select sssd

   3. Enable GSSAPI authentication:

      # authselect enable-feature with-gssapi

   4. Configure the system to authenticate only users with smart cards:

      # authselect with-smartcard-required

6. On RHEL 8.7 or earlier:

   1. Open the /etc/pam.d/sudo PAM configuration file.

   2. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo file.

      #%PAM-1.0
      auth sufficient pam_sss_gss.so
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth

   3. Save and close the /etc/pam.d/sudo file.
   4. Open the /etc/pam.d/sudo-i PAM configuration file.

   5. Add the following entry as the first line of the auth section in the /etc/pam.d/sudo-i file.

      #%PAM-1.0
      auth sufficient pam_sss_gss.so
      auth       include      sudo
      account    include      sudo
      password   include      sudo
      session    optional     pam_keyinit.so force revoke
      session    include      sudo

   6. Save and close the /etc/pam.d/sudo-i file.

Verification

1. Log into the host as the idm_user account and authenticate with a smart card.

   [root@idmclient ~]# ssh -l idm_user@idm.example.com localhost
   PIN for smart_card

2. Verify that you have a ticket-granting ticket as the smart card user.

   [idm_user@idmclient ~]$ klist
   Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
   Default principal: idm_user@IDM.EXAMPLE.COM
   
   Valid starting       Expires              Service principal
   02/15/2021 16:29:48  02/16/2021 02:29:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
   	renew until 02/22/2021 16:29:44

3. Display which sudo rules the idm_user account is allowed to perform.

   [idm_user@idmclient ~]$ sudo -l
   Matching Defaults entries for idmuser on idmclient:
       !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
       env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
       env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
       env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
       env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
       env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
       secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
   
   User idm_user may run the following commands on idmclient:
       (root) /usr/sbin/reboot

4. Reboot the machine using sudo, without specifying a password.

   [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

Procedure

1. Create an inventory file, for example inventory.file, and define ipaservers in it:

   [ipaservers]
   server.idm.example.com

2. Add one or more sudo commands:

   1. Create an ensure-reboot-sudocmd-is-present.yml Ansible playbook that ensures the presence of the /usr/sbin/reboot command in the IdM database of sudo commands. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml file:

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: /usr/sbin/reboot
            state: present

   2. Run the playbook:

      $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml

3. Create a sudo rule that references the commands:

   1. Create an ensure-sudorule-for-idmuser-on-idmclient-is-present.yml Ansible playbook that uses the sudo command entry to ensure the presence of a sudo rule. The sudo rule allows idm_user to reboot the idmclient machine. To simplify this step, you can copy and modify the example in the /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml file:

      ---
      - name: Tests
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present

   2. Run the playbook:

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

1. Log in to idmclient as idm_user.

2. Reboot the machine using sudo. Enter the password for idm_user when prompted:

   $ sudo /usr/sbin/reboot
   [sudo] password for idm_user:

Procedure

1. In a command line, enter the LDAP Data Interchange Format (LDIF) statement after the ldapmodify command.

   Example 10.1. Changing the telephone number for a testuser

   # ldapmodify -Y GSSAPI -H ldap://server.example.com
   dn: uid=testuser,cn=users,cn=accounts,dc=example,dc=com
   changetype: modify
   replace: telephoneNumber
   telephonenumber: 88888888

   Note that you need to obtain a Kerberos ticket for using -Y option.

2. Press Ctlr+D to exit the interactive mode.

3. Alternatively, provide an LDIF file after ldapmodify command:

   Example 10.2. The ldapmodify command reads modification data from an LDIF file

   # ldapmodify -Y GSSAPI -H ldap://server.example.com -f ~/example.ldif

Procedure

1. Log in as an IdM user with a role to preserve users:

   $ kinit admin

2. Enter the ldapmodify command and specify the Generic Security Services API (GSSAPI) as the Simple Authentication and Security Layer (SASL) mechanism to be used for authentication:

   # ldapmodify -Y GSSAPI
   SASL/GSSAPI authentication started
   SASL username: admin@IDM.EXAMPLE.COM
   SASL SSF: 256
   SASL data security layer installed.

3. Enter the dn of the user you want to preserve:

   dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com

4. Enter modrdn as the type of change you want to perform:

   changetype: modrdn

5. Specify the newrdn for the user:

   newrdn: uid=user1

6. Indicate that you want to preserve the user:

   deleteoldrdn: 0

7. Specify the new superior DN:

   newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com

   Preserving a user moves the entry to a new location in the directory information tree (DIT). For this reason, you must specify the DN of the new parent entry as the new superior DN.

8. Press Enter again to confirm that this is the end of the entry:

   [Enter]
   
   modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"

9. Exit the connection using Ctrl + C.

Procedure

1. Log in as IdM administrator:

   $ kinit admin

2. Create a user named provisionator with the privileges to add stage users.

   1. Add the provisionator user account:

   $ ipa user-add provisionator --first=provisioning --last=account --password

   1. Grant the provisionator user the required privileges.

      1. Create a custom role, System Provisioning, to manage adding stage users:

         $ ipa role-add --desc "Responsible for provisioning stage users" "System Provisioning"

      2. 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"

      3. Add the provisionator user to the role:

         $ ipa role-add-member --users=provisionator "System Provisioning"

      4. 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
        [...]

3. Create a user, activator, with the privileges to manage user accounts.

   1. Add the activator user account:

      $ ipa user-add activator --first=activation --last=account --password

   2. 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"

4. Create a user group for application accounts:

   $ ipa group-add application-accounts

5. 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

6. 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
   [...]

7. Add the provisioning and activation accounts to the group for application accounts:

   $ ipa group-add-member application-accounts --users={provisionator,activator}

8. Change the passwords for the user accounts:

   $ kpasswd provisionator
   $ kpasswd activator

   Changing the passwords is necessary because new IdM users passwords expire immediately.

Procedure

1. 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.

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 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

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. Reload the new configuration:

   # systemctl daemon-reload

7. Enable ipa-activate-all.timer:

   # systemctl enable ipa-activate-all.timer

8. Start ipa-activate-all.timer:

   # systemctl start ipa-activate-all.timer

9. 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.

Procedure

1. 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

2. 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

3. Use the SSH protocol to connect to the IdM server as provisionator:

   $ ssh provisionator@server.idm.example.com
   Password:
   [provisionator@server ~]$

4. On the IdM server, obtain the Kerberos ticket-granting ticket (TGT) for the provisionator account:

   [provisionator@server ~]$ kinit provisionator

5. 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"

Procedure

1. 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 ~]$

2. Obtain the TGT of the provisionator account, an IdM user with a role to add new stage users:

   $ kinit provisionator

3. 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.

4. 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

5. Enter add as the type of change you are performing:

   changetype: add

6. 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.

7. Enter the uid of the user:

   uid: stageuser

8. Enter the cn of the user:

   cn: Babs Jensen

9. Enter the last name of the user:

   sn: Jensen

10. 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"

11. Exit the connection using Ctrl + C.

1. A Kerberos client identifies itself to the KDC by authenticating as a Kerberos principal. For example, an IdM user performs kinit username and provides their password.
2. The KDC checks for the principal in its database, authenticates the client, and evaluates Kerberos ticket policies to determine whether to grant the request.
3. The KDC issues the client a ticket-granting ticket (TGT) with a lifecycle and authentication indicators according to the appropriate ticket policy.
4. With the TGT, the client requests a service ticket from the KDC to communicate with a Kerberized service on a target host.
5. The KDC checks if the client’s TGT is still valid, and evaluates the service ticket request against ticket policies.
6. The KDC issues the client a service ticket.
7. With the service ticket, the client can initiate encrypted communication with the service on the target host.

Procedure

1. To modify the global ticket policy:

   [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
     Max life: 28800
     Max renew: 86400

   In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).

2. Optional: To reset the global Kerberos ticket policy to the default installation values:

   [root@server ~]# ipa krbtpolicy-reset
     Max life: 86400
     Max renew: 604800

Procedure

1. For example, to set the IdM admin user’s maximum ticket lifetime to two days and maximum renewal age to two weeks:

   [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
     Max life: 172800
     Max renew: 1209600

2. Optional: To reset the ticket policy for a user:

   [root@server ~]# ipa krbtpolicy-reset admin

Procedure

1. For example, to allow the IdM admin user to renew a Kerberos ticket for two days if it was obtained with One-Time Password authentication, set the --otp-maxrenew option:

   [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
     OTP max renew: 172800

2. Optional: To reset the ticket policy for a user:

   [root@server ~]# ipa krbtpolicy-reset username

Procedure

1. Check if PKINIT is enabled on the server:

   # kinit admin
   
   Password for admin@IDM.EXAMPLE.COM:
   # ipa pkinit-status --server=server.idm.example.com
   1 server matched
   ----------------
   Server name: server.idm.example.com
   PKINIT status:enabled
   ----------------------------
   Number of entries returned 1
   ----------------------------

   If PKINIT is disabled, you will see the following output:

   # ipa pkinit-status --server server.idm.example.com
   -----------------
   0 servers matched
   -----------------
   ----------------------------
   Number of entries returned 0
   ----------------------------

   You can also use the command to find all the servers where PKINIT is enabled if you omit the --server <server_fqdn> parameter.

2. If you are using IdM without CA:

   1. On the IdM server, install the CA certificate that signed the Kerberos key distribution center (KDC) certificate:

      # ipa-cacert-manage install -t CT,C,C ca.pem

   2. To update all IPA hosts, repeat the ipa-certupdate command on all replicas and clients:

      # ipa-certupdate

   3. Check if the CA certificate has already been added using the ipa-cacert-manage list command. For example:

      # ipa-cacert-manage list
      CN=CA,O=Example Organization
      The ipa-cacert-manage command was successful

   4. Use the ipa-server-certinstall utility to install an external KDC certificate. The KDC certificate must meet the following conditions:

      • It is issued with the common name CN=fully_qualified_domain_name,certificate_subject_base.
      • It includes the Kerberos principal krbtgt/REALM_NAME@REALM_NAME.

      • It contains the Object Identifier (OID) for KDC authentication: 1.3.6.1.5.2.3.5.

        # ipa-server-certinstall --kdc kdc.pem kdc.key
        
        # systemctl restart krb5kdc.service

   5. See your PKINIT status:

      # ipa pkinit-status
        Server name: server1.example.com
        PKINIT status: enabled
        [...output truncated...]
        Server name: server2.example.com
        PKINIT status: disabled
        [...output truncated...]

3. If you are using IdM with a CA certificate, enable PKINIT as follows:

   # ipa-pkinit-manage enable
     Configuring Kerberos KDC (krb5kdc)
     [1/1]: installing X509 Certificate for PKINIT
     Done configuring Kerberos KDC (krb5kdc).
     The ipa-pkinit-manage command was successful

   If you are using an IdM CA, the command requests a PKINIT KDC certificate from the CA.

Procedure

1. Display the KVNO of the principals in the keytab you are verifying. In the following example, the /etc/named.keytab file has the key for the DNS/server1.idm.example.com@EXAMPLE.COM principal with a KVNO of 2.

   [root@server1 ~]# klist -ekt /etc/named.keytab
   Keytab name: FILE:/etc/named.keytab
   KVNO Timestamp           Principal
   ---- ------------------- ------------------------------------------------------
      2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
      2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)

2. Display the KVNO of the principal stored in the IdM database. In this example, the KVNO of the key in the IdM database does not match the KVNO in the keytab.

   [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
   DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3

3. Authenticate as the IdM admin account.

   [root@server1 ~]# kinit admin
   Password for admin@IDM.EXAMPLE.COM:

4. Retrieve an updated Kerberos key for the principal and store it in its keytab. Perform this step as the root user so you can modify the /etc/named.keytab file, which is owned by the named user.

   [root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab

Verification

1. Display the updated KVNO of the principal in the keytab.

   [root@server1 ~]# klist -ekt /etc/named.keytab
   Keytab name: FILE:/etc/named.keytab
   KVNO Timestamp           Principal
   ---- ------------------- ------------------------------------------------------
      4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
      4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)

2. Display the KVNO of the principal stored in the IdM database and ensure it matches the KVNO from the keytab.

   [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
   DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4

Procedure

1. Open the /etc/krb5.conf file for editing.

2. In the [realms] section, enter the URL of the KKDCP for the kdc, admin_server, and kpasswd_server options:

   [realms]
   EXAMPLE.COM = {
     kdc = https://kdc.example.com/KdcProxy
     admin_server = https://kdc.example.com/KdcProxy
     kpasswd_server = https://kdc.example.com/KdcProxy
     default_domain = example.com
   }

   For redundancy, you can add the parameters kdc, admin_server, and kpasswd_server multiple times to indicate different KKDCP servers.

3. Restart the sssd service to make the changes take effect:

   ~]# systemctl restart sssd

Procedure

1. Remove the ipaConfigString=kdcProxyEnabled attribute and value pair from the directory:

   # ipa-ldap-updater /usr/share/ipa/kdcproxy-disable.uldif
   Update complete
   The ipa-ldap-updater command was successful

2. Restart the httpd service:

   # systemctl restart httpd.service

Procedure

1. Add the ipaConfigString=kdcProxyEnabled attribute and value pair to the directory:

   # ipa-ldap-updater /usr/share/ipa/kdcproxy-enable.uldif
   Update complete
   The ipa-ldap-updater command was successful

2. Restart the httpd service:

   # systemctl restart httpd.service

Procedure

1. Set the use_dns parameter in the [global] section of the /etc/ipa/kdcproxy/kdcproxy.conf file to false.

   [global]
   use_dns = false

2. Put the proxied realm information into the /etc/ipa/kdcproxy/kdcproxy.conf file. For example, for the [AD.EXAMPLE.COM] realm with proxy list the realm configuration parameters as follows:

   [AD.EXAMPLE.COM]
   kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88
   kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464

   Important

   The realm configuration parameters must list multiple servers separated by a space, as opposed to /etc/krb5.conf and kdc.conf, in which certain options may be specified multiple times.

3. Restart Identity Management (IdM) services:

   # ipactl restart

Procedure

1. In the /etc/ipa/kdcproxy/kdcproxy.conf file, the [global] section, set the use_dns parameter to true.

   [global]
   configs = mit
   use_dns = true

   The configs parameter allows you to load other configuration modules. In this case, the configuration is read from the MIT libkrb5 library.

2. Optional: In case you do not want to use DNS service records, add explicit AD servers to the [realms] section of the /etc/krb5.conf file. If the realm with proxy is, for example, AD.EXAMPLE.COM, you add:

   [realms]
   AD.EXAMPLE.COM = {
       kdc = ad-server.ad.example.com
       kpasswd_server = ad-server.ad.example.com
   }

3. Restart Identity Management (IdM) services:

   # ipactl restart

Procedure

1. Optional: Display existing self-service rules with the ipa selfservice-find command.
2. Optional: Display details for the self-service rule you want to modify with the ipa selfservice-show command.
3. Use the ipa selfservice-mod command to edit a self-service rule.