Procedure

1. To log in to IdM

   • under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as example_user on the local system:

     [example_user@server ~]$ kinit
     Password for example_user@EXAMPLE.COM:
     [example_user@server ~]$

     If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:

     [example_user@server ~]$ kinit
     kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials

   • using a Kerberos principal that does not correspond to your local user name, pass the required user name to the kinit utility. For example, to log in as the admin user:

     [example_user@server ~]$ kinit admin
     Password for admin@EXAMPLE.COM:
     [example_user@server ~]$

2. Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the example_user principal, which means that on this particular host, only example_user is currently allowed to access IdM services:

   $ klist
   Ticket cache: KEYRING:persistent:0:0
   Default principal: example_user@EXAMPLE.COM
   
   Valid starting     	Expires            	Service principal
   11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

Procedure

1. To destroy your Kerberos ticket:

   [example_user@server ~]$ kdestroy

2. Optionally, to check that the Kerberos ticket has been destroyed:

   [example_user@server ~]$ klist
   klist: Credentials cache keyring 'persistent:0:0' not found

Procedure

1. Copy the /etc/krb5.conf file from the IdM server to the external system. For example:

   # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf

   Warning

   Do not overwrite the existing krb5.conf file on the external system.

2. On the external system, set the terminal session to use the copied IdM Kerberos configuration file:

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

   The KRB5_CONFIG variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.

3. Copy the Kerberos configuration snippets from the /etc/krb5.conf.d/ directory to the external system.

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. Type an IdM server URL into the browser address bar. The name will look similarly to the following example:

   https://server.example.com

   You just need to change server.example.com with a DNS name of your IdM server.

   This opens the IdM Web UI login screen in your browser.

   

   • If the server does not respond or the login screen does not open, check the DNS settings on the IdM server to which you are connecting.

   • If you use a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.

     To avoid security exceptions, install a certificate signed by a certificate authority.

2. On the Web UI login screen, enter the administrator account credentials you added during the IdM server installation.

   For details, see Installing an Identity Management server: With integrated DNS, with an integrated CA.

   You can enter your personal account credentials as well if they are already entered in the IdM server.

   

3. Click Log in.

Procedure

1. To log in to IdM

   • under the user name of the user who is currently logged in on the local system, use kinit without specifying a user name. For example, if you are logged in as example_user on the local system:

     [example_user@server ~]$ kinit
     Password for example_user@EXAMPLE.COM:
     [example_user@server ~]$

     If the user name of the local user does not match any user entry in IdM, the authentication attempt fails:

     [example_user@server ~]$ kinit
     kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials

   • using a Kerberos principal that does not correspond to your local user name, pass the required user name to the kinit utility. For example, to log in as the admin user:

     [example_user@server ~]$ kinit admin
     Password for admin@EXAMPLE.COM:
     [example_user@server ~]$

2. Optionally, to verify that the login was successful, use the klist utility to display the cached TGT. In the following example, the cache contains a ticket for the example_user principal, which means that on this particular host, only example_user is currently allowed to access IdM services:

   $ klist
   Ticket cache: KEYRING:persistent:0:0
   Default principal: example_user@EXAMPLE.COM
   
   Valid starting     	Expires            	Service principal
   11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

Procedure

1. Open the IdM Web UI login dialog in your web browser.

2. Click the link for browser configuration on the Web UI login screen.

   

3. Follow the steps on the configuration page.

   

Procedure

1. Copy the /etc/krb5.conf file from the IdM server to the external system. For example:

   # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf

   Warning

   Do not overwrite the existing krb5.conf file on the external system.

2. On the external system, set the terminal session to use the copied IdM Kerberos configuration file:

   $ export KRB5_CONFIG=/etc/krb5_ipa.conf

   The KRB5_CONFIG variable exists only temporarily until you log out. To prevent this loss, export the variable with a different file name.

3. Copy the Kerberos configuration snippets from the /etc/krb5.conf.d/ directory to the external system.
4. Configure the browser on the external system, as described in Configuring the browser for Kerberos authentication.

Procedure

1. Log in to the IdM Web UI with your username and password.

2. Open the Identity → Users → Active users tab.

   

3. Click your username to open the user settings.
4. In the User authentication types, select Two factor authentication (password + OTP).
5. Click Save.

Procedure

1. Log in to the IdM Web UI with your user name and password.
2. To create the token in your mobile phone, open the Authentication → OTP Tokens tab.

3. Click Add.

   

4. In the Add OTP token dialog box, leave everything unfilled and click Add.

   At this stage, the IdM server creates a token with default parameters at the server and opens a page with a QR code.

5. Copy the QR code into your mobile phone.
6. Click OK to close the QR code.

Procedure

1. In the Identity Management login screen, enter your user name or a user name of the IdM server administrator account.
2. Add the password for the user name entered above.
3. Generate a one time password on your device.
4. Enter the one time password right after the password (without space).

5. Click Log in.

   If the authentication fails, synchronize OTP tokens.

   If your CA uses a self-signed certificate, the browser issues a warning. Check the certificate and accept the security exception to proceed with the login.

   If the IdM Web UI does not open, verify the DNS configuration of your Identity Management server.

Procedure

1. On the IdM Web UI login screen, click Sync OTP Token.

   

2. In the login screen, enter your username and the Identity Management password.
3. Generate one time password and enter it in the First OTP field.
4. Generate another one time password and enter it in the Second OTP field.

5. Optionally, enter the token ID.

   

6. Click Sync OTP Token.

Procedure

1. In the password expiration login screen, enter the user name.
2. Add the password for the user name entered above.

3. In the OTP field, generate a one time password, if you use the one time password authentication.

   If you do not have enabled the OTP authentication, leave the field empty.

4. Enter the new password twice for verification.

5. Click Reset Password.

   

1. The getent command triggers the getpwnam call from the libc library.
2. The libc library references the /etc/nsswitch.conf configuration file to check which service is responsible for providing user information, and discovers the entry sss for the SSSD service.
3. The libc library opens the nss_sss module.
4. The nss_sss module checks the memory-mapped cache for the user information. If the data is present in the cache, the nss_sss module returns it.
5. If the user information is not in the memory-mapped cache, the request is passed to the SSSD sssd_nss responder process.
6. The SSSD service checks its cache. If the data is present in the cache and valid, the sssd_nss responder reads the data from the cache and returns it to the application.
7. If the data is not present in the cache or it is expired, the sssd_nss responder queries the appropriate back-end process and waits for a reply. The SSSD service uses the IPA backend in an IdM environment, enabled by the setting id_provider=ipa in the sssd.conf configuration file.
8. The sssd_be back-end process connects to the IdM server and requests the information from the IdM LDAP Directory Server.
9. The SSSD back-end on the IdM server responds to the SSSD back-end process on the IdM client.
10. The SSSD back-end on the client stores the resulting data in the SSSD cache and alerts the responder process that the cache has been updated.
11. The sssd_nss front-end responder process retrieves the information from the SSSD cache.
12. The sssd_nss responder sends the user information to the nss_sss responder, completing the request.
13. The libc library returns the user information to the application that requested it.

1. The IdM client looks to its local SSSD cache for AD user information.
2. If the IdM client does not have the user information, or the information is stale, the SSSD service on the client contacts the extdom_extop plugin on the IdM server to perform an LDAP extended operation and requests the information.
3. The SSSD service on the IdM server looks for the AD user information in its local cache.
4. If the IdM server does not have the user information in its SSSD cache, or its information is stale, it performs an LDAP search to request the user information from an AD Domain Controller.
5. The SSSD service on the IdM server receives the AD user information from the AD domain controller and stores it in its cache.
6. The extdom_extop plugin receives the information from the SSSD service on the IdM server, which completes the LDAP extended operation.
7. The SSSD service on the IdM client receives the AD user information from the LDAP extended operation.
8. The IdM client stores the AD user information in its SSSD cache and returns the information to the application that requested it.

1. The authentication attempt with the ssh command triggers the libpam library.

2. The libpam library references the PAM file in the /etc/pam.d/ directory that corresponds to the service requesting the authentication attempt. In this example involving authenticating via the SSH service on the local host, the libpam library checks the /etc/pam.d/system-auth configuration file and discovers the pam_sss.so entry for the SSSD PAM:

   auth    sufficient    pam_sss.so

3. To determine which authentication methods are available, the libpam library opens the pam_sss module and sends an SSS_PAM_PREAUTH request to the sssd_pam PAM responder of the SSSD service.
4. If smart card authentication is configured, the SSSD service spawns a temporary p11_child process to check for a smart card and retrieve certificates from it.
5. If smart card authentication is configured for the user, the sssd_pam responder attempts to match the certificate from the smart card with the user. The sssd_pam responder also performs a search for the groups that the user belongs to, since group membership might affect access control.
6. The sssd_pam responder sends an SSS_PAM_PREAUTH request to the sssd_be back-end responder to see which authentication methods the server supports, such as passwords or 2-factor authentication. In an IdM environment, where the SSSD service uses the IPA responder, the default authentication method is Kerberos. For this example, the user authenticates with a simple Kerberos password.
7. The sssd_be responder spawns a temporary krb5_child process.
8. The krb5_child process contacts the KDC on the IdM server and checks for available authentication methods.

9. The KDC responds to the request:

   1. The krb5_child process evaluates the reply and sends the results back to the sssd_be backend process.
   2. The sssd_be backend process receives the result.
   3. The sssd_pam responder receives the result.
   4. The pam_sss module receives the result.
10. If password authentication is configured for the user, the pam_sss module prompts the user for their password. If smart card authentication is configured, the pam_sss module prompts the user for their smart card PIN.

11. The module sends an SSS_PAM_AUTHENTICATE request with the user name and password, which travels to:

    1. The sssd_pam responder.
    2. The sssd_be back-end process.
12. The sssd_be process spawns a temporary krb5_child process to contact the KDC.
13. The krb5_child process attempts to retrieve a Kerberos Ticket Granting Ticket (TGT) from the KDC with the user name and password the user provided.
14. The krb5_child process receives the result of the authentication attempt.

15. The krb5_child process:

    1. Stores the TGT in a credential cache.
    2. Returns the authentication result to the sssd_be back-end process.

16. The authentication result travels from the sssd_be process to:

    1. The sssd_pam responder.
    2. The pam_sss module.
17. The pam_sss module sets an environment variable with the location of the user’s TGT so other applications can reference it.

Procedure

1. Verify that the SSSD service and its processes are running.

   [root@client ~]# pstree -a | grep sssd
     |-sssd -i --logger=files
     |   |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
     |   |-sssd_be --domain example.com --uid 0 --gid 0 --logger=files
     |   |-sssd_ifp --uid 0 --gid 0 --logger=files
     |   |-sssd_nss --uid 0 --gid 0 --logger=files
     |   |-sssd_pac --uid 0 --gid 0 --logger=files
     |   |-sssd_pam --uid 0 --gid 0 --logger=files
     |   |-sssd_ssh --uid 0 --gid 0 --logger=files
     |   `-sssd_sudo --uid 0 --gid 0 --logger=files
     |-sssd_kcm --uid 0 --gid 0 --logger=files

2. Verify that the client can contact the user database server via the IP address.

   [user@client ~]$ ping <IP_address_of_the_database_server>

   If this step fails, check that your network and firewall settings allow direct communication between IdM clients and servers. See Using and configuring firewalld.

3. Verify that the client can discover and contact the IdM LDAP server (for IdM users) or AD domain controller (for AD users) via the fully qualified host name.

   [user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   If this step fails, check your Dynamic Name Service (DNS) settings, including the /etc/resolv.conf file. See Configuring the order of DNS servers.

   Note

   By default, the SSSD service attempts to automatically discover LDAP servers and AD DCs through DNS service (SRV) records. Alternatively, you can restrict the SSSD service to use specific servers by setting the following options in the sssd.conf configuration file:

   • ipa_server = <fully_qualified_host_name_of_the_server>
   • ad_server = <fully_qualified_host_name_of_the_server>
   • ldap_uri = <fully_qualified_host_name_of_the_server>

   If you use these options, verify you can contact the servers listed in them.

4. Verify that the client can authenticate to the LDAP server and retrieve user information with ldapsearch commands.

   1. If your LDAP server is an IdM server, like server.example.com, retrieve a Kerberos ticket for the host and perform the database search authenticating with the host Kerberos principal:

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>

   2. If your LDAP server is an Active Directory (AD) Domain Controller (DC), like server.ad.example.com, retrieve a Kerberos ticket for the host and perform the database search authenticating with the host Kerberos principal:

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>

   3. If your LDAP server is a plain LDAP server, and you have set the ldap_default_bind_dn and ldap_default_authtok options in the sssd.conf file, authenticate as the same ldap_default_bind_dn account:

      [user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<user_name>

   If this step fails, verify that your database settings allow your host to search the LDAP server.

5. Since the SSSD service uses Kerberos encryption, verify you can obtain a Kerberos ticket as the user that is unable to log in.

   1. If your LDAP server is an IdM server:

      [user@client ~]$ kinit <user_name>

   2. If LDAP server database is an AD server:

      [user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>

   If this step fails, verify that your Kerberos server is operating properly, all servers have their times synchronized, and that the user account is not locked.

6. Verify you can retrieve user information about the command line.

   [user@client ~]$ getent passwd <user_name>
   [user@client ~]$ id <user_name>

   If this step fails, verify that the SSSD service on the client can receive information from the user database:

   1. Review errors in the /var/log/messages log file.
   2. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for indications to the source of the issue.
   3. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting information you have gathered.

7. If you are allowed to run sudo on the host, use the sssctl utility to verify the user is allowed to log in.

   [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>

   If this step fails, verify your authorization settings, such as your PAM configuration, IdM HBAC rules, and IdM RBAC rules:

   1. Ensure that the user’s UID is equal to or higher than UID_MIN, which is defined in the /etc/login.defs file.
   2. Review authorization errors in the /var/log/secure and /var/log/messages log files.
   3. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for indications to the source of the issue.
   4. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting information you have gathered.

Procedure

1. Open the /etc/sssd/sssd.conf file in a text editor.

2. Add the debug_level option to every section of the file, and set the debug level to the verbosity of your choice.

   [domain/example.com]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = example.com
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

3. Save and close the sssd.conf file.

4. Restart the SSSD service to load the new configuration settings.

   [root@server ~]# systemctl restart sssd

Procedure

1. Enable detailed SSSD debug logging on the IdM server.

   [root@server ~]# sssctl debug-level 6

2. Invalidate objects in the SSSD cache for the user that is experiencing authentication issues, so you do not bypass the LDAP server and retrieve information SSSD has already cached.

   [root@server ~]# sssctl cache-expire -u idmuser

3. Minimize the troubleshooting dataset by removing older SSSD logs.

   [root@server ~]# sssctl logs-remove

4. Attempt to switch to the user experiencing authentication problems, while gathering timestamps before and after the attempt. These timestamps further narrow the scope of the dataset.

   [root@server sssd]# date; su idmuser; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 15:33:49 EDT 2021

5. (Optional) Lower the debug level if you do not wish to continue gathering detailed SSSD logs.

   [root@server ~]# sssctl debug-level 2

6. Review SSSD logs for information about the failed request. For example, reviewing the /var/log/sssd/sssd_example.com.log file shows that the SSSD service did not find the user in the cn=accounts,dc=example,dc=com LDAP subtree. This might indicate that the user does not exist, or exists in another location.

   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idmuser@example.com]
   ...
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idmuser)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com].
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request

7. If you are unable to determine the cause of the authentication issue:

   1. Collect the SSSD logs you recently generated.

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar

   2. Open a Red Hat Technical Support case and provide:

      1. The SSSD logs: sssd-logs-Mar29.tar

      2. The console output, including the time stamps and user name, of the request that corresponds to the logs:

         [root@server sssd]# date; id idmuser; date
         Mon Mar 29 15:33:48 EDT 2021
         id: ‘idmuser’: no such user
         Mon Mar 29 15:33:49 EDT 2021

Procedure

1. On the client: Open the /etc/sssd/sssd.conf file in a text editor.

2. On the client: Add the ipa_server option to the [domain] section of the file and set it to an IdM server. This avoids the IdM client autodiscovering other IdM servers, thus limiting this test to just one client and one server.

   [domain/example.com]
   ipa_server = server.example.com
   ...

3. On the client: Save and close the sssd.conf file.

4. On the client: Restart the SSSD service to load the configuration changes.

   [root@client ~]# systemctl restart sssd

5. On the server and client: Enable detailed SSSD debug logging.

   [root@server ~]# sssctl debug-level 6

   [root@client ~]# sssctl debug-level 6

6. On the server and client: Invalidate objects in the SSSD cache for the user experiencing authentication issues, so you do not bypass the LDAP database and retrieve information SSSD has already cached.

   [root@server ~]# sssctl cache-expire -u idmuser

   [root@client ~]# sssctl cache-expire -u idmuser

7. On the server and client: Minimize the troubleshooting dataset by removing older SSSD logs.

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

8. On the client: Attempt to switch to the user experiencing authentication problems while gathering timestamps before and after the attempt. These timestamps further narrow the scope of the dataset.

   [root@client sssd]# date; su idmuser; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 16:20:14 EDT 2021

9. (Optional) On the server and client: Lower the debug level if you do not wish to continue gathering detailed SSSD logs.

   [root@server ~]# sssctl debug-level 0

   [root@client ~]# sssctl debug-level 0

10. On the server and client: Review SSSD logs for information about the failed request.

    1. Review the request from the client in the client logs.
    2. Review the request from the client in the server logs.
    3. Review the result of the request in the server logs.
    4. Review the outcome of the client receiving the results of the request from the server.

11. If you are unable to determine the cause of the authentication issue:

    1. Collect the SSSD logs you recently generated on the IdM server and IdM client. Label them according to their hostname or role.

       [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar

       [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar

    2. Open a Red Hat Technical Support case and provide:

       1. The SSSD debug logs:

          1. sssd-logs-server-Mar29.tar from the server
          2. sssd-logs-client-Mar29.tar from the client

       2. The console output, including the time stamps and user name, of the request that corresponds to the logs:

          [root@client sssd]# date; su idmuser; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idmuser does not exist
          Mon Mar 29 16:20:14 EDT 2021

Procedure

1. To review your SSSD log file, open the log file using the less utility. For example, to view the /var/log/sssd/sssd_example.com.log:

   [root@server ~]# less /var/log/sssd/sssd_example.com.log

2. Review the SSSD logs for information about the client request.

   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1

   This sample output from an SSSD log file shows the unique identifiers RID#3 and RID#4 for two different requests.

Procedure

1. Create a directory for your Ansible configuration and playbooks in your home directory:

   $ mkdir ~/MyPlaybooks/

2. Change into the ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks

3. Create the ~/MyPlaybooks/ansible.cfg file with the following content:

   [defaults]
   inventory = /home/your_username/MyPlaybooks/inventory
   remote_user = admin

4. Create the ~/MyPlaybooks/inventory file with the following content:

   [eu]
   server.idm.example.com
   
   [us]
   replica.idm.example.com
   
   [ipaserver:children]
   eu
   us

   This configuration defines two host groups, eu and us, for hosts in these locations. Additionally, this configuration defines the ipaserver host group, which contains all hosts from the eu and us groups.

5. [Optional] Create an SSH public and private key. To simplify access in your test environment, do not set a password on the private key:

   $ ssh-keygen

6. Copy the SSH public key to the IdM admin account on each managed node:

   $ ssh-copy-id admin@server.idm.example.com
   $ ssh-copy-id admin@replica.idm.example.com

   These commands require that you enter the IdM admin password.

7. Create a password_file file that contains the vault password:

   redhat

8. Change the permissions to modify the file:

   $ chmod 0600 password_file

9. Create a secret.yml Ansible vault to store the IdM admin password:

   1. Configure password_file to store the vault password:

      $ ansible-vault create --vault-password-file=password_file secret.yml

   2. When prompted, enter the content of the secret.yml file:

      ipaadmin_password: Secret123

Procedure

1. Open the /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml Ansible playbook file for editing:

   ---
   - name: Playbook to handle global IdM configuration
     hosts: ipaserver
     become: no
     gather_facts: no
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Query IPA global configuration
       ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
       register: serverconfig
   
     - debug:
         msg: "{{ serverconfig }}"

2. Adapt the file by changing the following:

   • The password of IdM administrator.
   • Other values, if necessary.
3. Save the file.

4. 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 /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
   [...]
   TASK [debug]
   ok: [server.idm.example.com] => {
       "msg": {
           "ansible_facts": {
               "discovered_interpreter_
           },
           "changed": false,
           "config": {
               "ca_renewal_master_server": "server.idm.example.com",
               "configstring": [
                   "AllowNThash",
                   "KDC:Disable Last Success"
               ],
               "defaultgroup": "ipausers",
               "defaultshell": "/bin/bash",
               "emaildomain": "idm.example.com",
               "enable_migration": false,
               "groupsearch": [
                   "cn",
                   "description"
               ],
               "homedirectory": "/home",
               "maxhostname": "64",
               "maxusername": "64",
               "pac_type": [
                   "MS-PAC",
                   "nfs:NONE"
               ],
               "pwdexpnotify": "4",
               "searchrecordslimit": "100",
               "searchtimelimit": "2",
               "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023",
               "selinuxusermaporder": [
                   "guest_u:s0$xguest_u:s0$user_
               ],
               "usersearch": [
                   "uid",
                   "givenname",
                   "sn",
                   "telephonenumber",
                   "ou",
                   "title"
               ]
           },
           "failed": false
       }
   }

Procedure

1. Optional: Identify the current IdM CA renewal server:

   $ ipa config-show | grep 'CA renewal'
     IPA CA renewal master: server.idm.example.com

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

   [ipaserver]
   server.idm.example.com

3. Open the /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml Ansible playbook file for editing:

   ---
   - name: Playbook to handle global DNS configuration
     hosts: ipaserver
     become: no
     gather_facts: no
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     - name: set ca_renewal_master_server
       ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
         ca_renewal_master_server: carenewal.idm.example.com

4. Adapt the file by changing:

   • The password of IdM administrator set by the ipaadmin_password variable.
   • The name of the CA renewal server set by the ca_renewal_master_server variable.
5. Save the file.

6. 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 /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml

1. Log into ipaserver as IdM administrator:

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

2. Request the identity of the IdM CA renewal server:

   $ ipa config-show | grep ‘CA renewal’
   IPA CA renewal master:  carenewal.idm.example.com

   The output shows the carenewal.idm.example.com server is the new CA renewal server.

Procedure

1. Optional: Use the retrieve-config.yml Ansible playbook to identify the current shell for IdM users. See Retrieving IdM configuration using an Ansible playbook for details.

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

   [ipaserver]
   server.idm.example.com

3. Open the /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml Ansible playbook file for editing:

   ---
   - name: Playbook to ensure some config options are set
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
     # Set defaultlogin and maxusername
     - ipaconfig:
         ipaadmin_password: "{{ ipaadmin_password }}"
         defaultshell: /bin/bash
         maxusername: 64

4. Adapt the file by changing the following:

   • The password of IdM administrator set by the ipaadmin_password variable.
   • The default shell of the IdM users set by the defaultshell variable into /bin/sh.
5. Save the file.

6. 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 /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml

1. Log into ipaserver as IdM administrator:

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

2. Display the current shell:

   [admin@server /]$ echo "$SHELL"
   /bin/sh

   The logged-in user is using the sh shell.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Create a netbios-domain-name-present.yml Ansible playbook file.

3. Add the following content to the file:

   ---
   - name: Playbook to change IdM domain netbios name
     hosts: ipaserver
     become: no
     gather_facts: no
   
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
       - name: Set IdM domain netbios name
         ipaconfig:
           ipaadmin_password: "{{ ipaadmin_password }}"
           netbios_name: IPADOM

4. Save the file.

5. 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 inventory netbios-domain-name-present.yml

   When prompted, provide the vault file password.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Create a sids-for-users-and-groups-present.yml Ansible playbook file.

3. Add the following content to the file:

   ---
   - name: Playbook to ensure SIDs are enabled and users and groups have SIDs
     hosts: ipaserver
     become: no
     gather_facts: no
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
   
     tasks:
       - name: Enable SID and generate users and groups SIDS
         ipaconfig:
           ipaadmin_password: "{{ ipaadmin_password }}"
           enable_sid: true
           add_sids: true

   The enable_sid variable enables SID generation for future IdM users and groups. The add_sids variable generates SIDs for existing IdM users and groups.

   Note

   When using add_sids: true, you must also set the enable_sid variable to true.

4. Save the file.

5. 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 inventory sids-for-users-and-groups-present.yml

   When prompted, provide the vault file password.

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/ensure-users-present-ymlfile.yml file:

   ---
   - name: Ensure users' presence
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Include users.json
       include_vars:
         file: users.json
   
     - name: Users present
       ipauser:
         ipaadmin_password: "{{ ipaadmin_password }}"
         users: "{{ users }}"

3. 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/playbooks/user/users.json 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": "Alice",
       "last": "Acme",
       "password": "Password123"
      },
      {
       "name": "idm_user_2",
       "first": "Bob",
       "last": "Acme"
      },
      {
       "name": "idm_user_3",
       "first": "Eve",
       "last": "Acme"
      }
     ]
   }

4. 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. Optional. Use the ipa group-show command to confirm that the group includes the member you want to remove.

2. Remove a member from a user group by using the ipa group-remove-member command.

   Specify members to remove using these options:

   • --users removes an IdM user
   • --external removes a user that exists outside the IdM domain, in the format of DOMAIN\user_name or user_name@domain
   • --groups removes an IdM user group

   For example, to remove user1, user2, and group1 from a group called group_name:

   $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

Procedure

1. Click Identity → Groups, and select User Groups in the left sidebar.
2. Click Add to start adding the group.

3. Fill out the information about the group. For more information about user group types, see The different group types in IdM.

   You can specify a custom GID for the group. If you do this, be careful to avoid ID conflicts. If you do not specify a custom GID, IdM automatically assigns a GID from the available ID range.

   
4. Click Add to confirm.

Procedure

1. Click Identity → Groups and select User Groups.
2. Select the group to delete.
3. Click Delete.
4. Click Delete to confirm.

Procedure

1. Click Identity → Groups and select User Groups in the left sidebar.
2. Click the name of the group.

3. Select the type of group member you want to add: Users, User Groups, or External.

   
4. Click Add.
5. Select the check box next to one or more members you want to add.

6. Click the rightward arrow to move the selected members to the group.

   
7. Click Add to confirm.

Procedure

1. Click Identity → Groups and select User Groups in the left sidebar.
2. Click the name of the group.

3. Select the type of group member manager you want to add: Users or User Groups.

   
4. Click Add.
5. Select the check box next to one or more members you want to add.

6. Click the rightward arrow to move the selected members to the group.

   
7. Click Add to confirm.

Procedure

1. Select Identity → Groups.
2. Select User Groups in the left sidebar.
3. Click the name of the group you want to view.

4. Switch between Direct Membership and Indirect Membership.

   

Procedure

1. Click Identity → Groups and select User Groups in the left sidebar.
2. Click the name of the group.

3. Select the type of group member you want to remove: Users, User Groups, or External.

   
4. Select the check box next to the member you want to remove.
5. Click Delete.
6. Click Delete to confirm.

Procedure

1. Click Identity → Groups and select User Groups in the left sidebar.
2. Click the name of the group.

3. Select the type of member manager you want to remove: Users or User Groups.

   
4. Select the check box next to the member manager you want to remove.
5. Click Delete.
6. Click Delete to confirm.

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 user and group information:

   ---
   - name: Playbook to handle groups
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Create group ops with gid 1234
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: ops
         gidnumber: 1234
   
     - name: Create group sysops
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: sysops
         user:
         - idm_user
   
     - name: Create group appops
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: appops
   
     - name: Add group members sysops and appops to group ops
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: ops
         group:
         - sysops
         - appops

3. Run the playbook:

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

1. Log into ipaserver as administrator:

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

2. Display information about ops:

   ipaserver]$ ipa group-show ops
     Group name: ops
     GID: 1234
     Member groups: sysops, appops
     Indirect Member users: idm_user

   The appops and sysops groups - the latter including the idm_user user - exist in IdM.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Create an add-useridoverride-to-group.yml playbook with the following content:

   ---
   - name: Playbook to ensure presence of users in a group
     hosts: ipaserver
   
   
     - name: Ensure the ad_user@ad.example.com user ID override is a member of the admins group:
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: admins
         idoverrideuser:
         - ad_user@ad.example.com

   In the example:

   • Secret123 is the IdM admin password.
   • admins is the name of the IdM POSIX group to which you are adding the ad_user@ad.example.com ID override. Members of this group have full administrator privileges.
   • ad_user@ad.example.com is the user ID override of an AD administrator. The user is stored in the AD domain with which a trust has been established.
3. Save the file.

4. 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 inventory add-useridoverride-to-group.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 user and group member management information:

   ---
   - name: Playbook to handle membership management
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure user test is present for group_a
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: group_a
         membermanager_user: test
   
     - name: Ensure group_admins is present for group_a
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: group_a
         membermanager_group: group_admins

3. Run the playbook:

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

1. Log into ipaserver as administrator:

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

2. Display information about managergroup1:

   ipaserver]$ ipa group-show group_a
     Group name: group_a
     GID: 1133400009
     Membership managed by groups: group_admins
     Membership managed by users: test

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 user and group member management information:

   ---
   - name: Playbook to handle membership management
     hosts: ipaserver
   
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure member manager user and group members are absent for group_a
       ipagroup:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: group_a
         membermanager_user: test
         membermanager_group: group_admins
         action: member
         state: absent

3. Run the playbook:

   $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

1. Log into ipaserver as administrator:

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

2. Display information about group_a:

   ipaserver]$ ipa group-show group_a
     Group name: group_a
     GID: 1133400009

Procedure

1. Enter the ipa automember-add command to add an automember rule.

2. When prompted, specify:

   • Automember rule. This is the target group name.
   • Grouping Type. This specifies whether the rule targets a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.

   For example, to add an automember rule for a user group named user_group:

   $ ipa automember-add
   Automember Rule: user_group
   Grouping Type: group
   --------------------------------
   Added automember rule "user_group"
   --------------------------------
       Automember Rule: user_group

Procedure

1. Define one or more inclusive or exclusive conditions using the ipa automember-add-condition command.

2. When prompted, specify:

   • Automember rule. This is the target rule name. See Automember rules for details.
   • Attribute Key. This specifies the entry attribute to which the filter will apply. For example, uid for users.
   • Grouping Type. This specifies whether the rule targets a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.
   • Inclusive regex and Exclusive regex. These specify one or more conditions as regular expressions. If you only want to specify one condition, press Enter when prompted for the other.

   For example, the following condition targets all users with any value (.*) in their user login attribute (uid).

   $ ipa automember-add-condition
   Automember Rule: user_group
   Attribute Key: uid
   Grouping Type: group
   [Inclusive Regex]: .*
   [Exclusive Regex]:
   ----------------------------------
   Added condition(s) to "user_group"
   ----------------------------------
     Automember Rule: user_group
     Inclusive Regex: uid=.*
   ----------------------------
   Number of conditions added 1
   ----------------------------

   As another example, you can use an automembership rule to target all Windows users synchronized from Active Directory (AD). To achieve this, create a condition that that targets all users with ntUser in their objectClass attribute, which is shared by all AD users:

   $ ipa automember-add-condition
   Automember Rule: ad_users
   Attribute Key: objectclass
   Grouping Type: group
   [Inclusive Regex]: ntUser
   [Exclusive Regex]:
   -------------------------------------
   Added condition(s) to "ad_users"
   -------------------------------------
     Automember Rule: ad_users
     Inclusive Regex: objectclass=ntUser
   ----------------------------
   Number of conditions added 1
   ----------------------------

Procedure

1. Enter the ipa automember-find command.

2. When prompted, specify the Grouping type:

   • To target a user group, enter group.

   • To target a host group, enter hostgroup.

     For example:

   $ ipa automember-find
   Grouping Type: group
   ---------------
   1 rules matched
   ---------------
     Automember Rule: user_group
     Inclusive Regex: uid=.*
   ----------------------------
   Number of entries returned 1
   ----------------------------

Procedure

1. Enter the ipa automember-del command.

2. When prompted, specify:

   • Automember rule. This is the rule you want to delete.
   • Grouping rule. This specifies whether the rule you want to delete is for a user group or a host group. Enter group or hostgroup.

Procedure

1. Enter the ipa automember-remove-condition command.

2. When prompted, specify:

   • Automember rule. This is the name of the rule from which you want to remove a condition.
   • Attribute Key. This is the target entry attribute. For example, uid for users.
   • Grouping Type. This specifies whether the condition you want to delete is for a user group or a host group. Enter group or hostgroup.

   • Inclusive regex and Exclusive regex. These specify the conditions you want to remove. If you only want to specify one condition, press Enter when prompted for the other.

     For example:

   $ ipa automember-remove-condition
   Automember Rule: user_group
   Attribute Key: uid
   Grouping Type: group
   [Inclusive Regex]: .*
   [Exclusive Regex]:
   -----------------------------------
   Removed condition(s) from "user_group"
   -----------------------------------
     Automember Rule: user_group
   ------------------------------
   Number of conditions removed 1
   ------------------------------

Procedure

1. Enter the ipa automember-default-group-set command to configure a default automember group.

2. When prompted, specify:

   • Default (fallback) Group, which specifies the target group name.

   • Grouping Type, which specifies whether the target is a user group or a host group. To target a user group, enter group. To target a host group, enter hostgroup.

     For example:

     $ ipa automember-default-group-set
     Default (fallback) Group: default_user_group
     Grouping Type: group
     ---------------------------------------------------
     Set default (fallback) group for automember "default_user_group"
     ---------------------------------------------------
       Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

   Note

   To remove the current default automember group, enter the ipa automember-default-group-remove command.

Procedure

1. Click Identity → Automember, and select either User group rules or Host group rules.
2. Click Add.

3. In the Automember rule field, select the group to which the rule will apply. This is the target group name.

   
4. Click Add to confirm.
5. Optional: You can add conditions to the new rule using the procedure described in Adding a condition to an automember rule using IdM Web UI.

Procedure

1. Click Identity → Automember, and select either User group rules or Host group rules.
2. Click on the rule to which you want to add a condition.

3. In the Inclusive or Exclusive sections, click Add.

   
4. In the Attribute field, select the required attribute, for example uid.
5. In the Expression field, define a regular expression.

6. Click Add.

   For example, the following condition targets all users with any value (.*) in their user ID (uid) attribute.

   

Procedure

1. Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.

2. Optional: Click on a rule to see the conditions for that rule in the Inclusive or Exclusive sections.

   

Procedure

1. Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.
2. Select the check box next to the rule you want to remove.

3. Click Delete.

   
4. Click Delete to confirm.

Procedure

1. Click Identity → Automember, and select either User group rules or Host group rules to view the respective automember rules.
2. Click on a rule to see the conditions for that rule in the Inclusive or Exclusive sections.
3. Select the check box next to the conditions you want to remove.

4. Click Delete.

   
5. Click Delete to confirm.

Procedure

1. Click Identity → Automember, and select User group rules.

2. In the Default user group field, select the group you want to set as the default user group.

   

Procedure

1. Click Identity → Automember, and select Host group rules.

2. In the Default host group field, select the group you want to set as the default host group.

   

Procedure

1. Create a directory for your Ansible configuration and playbooks in your home directory:

   $ mkdir ~/MyPlaybooks/

2. Change into the ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks

3. Create the ~/MyPlaybooks/ansible.cfg file with the following content:

   [defaults]
   inventory = /home/your_username/MyPlaybooks/inventory
   
   [privilege_escalation]
   become=True

4. Create the ~/MyPlaybooks/inventory file with the following content:

   [ipaserver]
   server.idm.example.com
   
   [ipareplicas]
   replica1.idm.example.com
   replica2.idm.example.com
   
   [ipacluster:children]
   ipaserver
   ipareplicas
   
   [ipacluster:vars]
   ipaadmin_password=SomeADMINpassword
   
   [ipaclients]
   ipaclient1.example.com
   ipaclient2.example.com
   
   [ipaclients:vars]
   ipaadmin_password=SomeADMINpassword

   This configuration defines two host groups, eu and us, for hosts in these locations. Additionally, this configuration defines the ipaserver host group, which contains all hosts from the eu and us groups.

5. [Optional] Create an SSH public and private key. To simplify access in your test environment, do not set a password on the private key:

   $ ssh-keygen

6. Copy the SSH public key to the IdM admin account on each managed node:

   $ ssh-copy-id admin@server.idm.example.com
   $ ssh-copy-id admin@replica.idm.example.com

   You must enter the IdM admin password when you enter these commands.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Copy the automember-group-present.yml Ansible playbook file located in the /usr/share/doc/ansible-freeipa/playbooks/automember/ directory:

   $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-present.yml automember-group-present-copy.yml

3. Open the automember-group-present-copy.yml file for editing.

4. Adapt the file by setting the following variables in the ipaautomember task section:

   • Set the ipaadmin_password variable to the password of the IdM admin.
   • Set the name variable to testing_group.
   • Set the automember_type variable to group.
   • Ensure that the state variable is set to present.

   This is the modified Ansible playbook file for the current example:

   ---
   - name: Automember group present example
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure group automember rule admins is present
       ipaautomember:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: testing_group
         automember_type: group
         state: present

5. Save the file.

6. 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 inventory automember-group-present-copy.yml

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Copy the automember-hostgroup-rule-present.yml Ansible playbook file located in the /usr/share/doc/ansible-freeipa/playbooks/automember/ directory and name it, for example, automember-usergroup-rule-present.yml:

   $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-usergroup-rule-present.yml

3. Open the automember-usergroup-rule-present.yml file for editing.

4. Adapt the file by modifying the following parameters:

   • Rename the playbook to correspond to your use case, for example: Automember user group rule member present.
   • Rename the task to correspond to your use case, for example: Ensure an automember condition for a user group is present.

   • Set the following variables in the ipaautomember task section:

     • Set the ipaadmin_password variable to the password of the IdM admin.
     • Set the name variable to testing_group.
     • Set the automember_type variable to group.
     • Ensure that the state variable is set to present.
     • Ensure that the action variable is set to member.
     • Set the inclusive key variable to UID.
     • Set the inclusive expression variable to .*

   This is the modified Ansible playbook file for the current example:

   ---
   - name: Automember user group rule member present
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure an automember condition for a user group is present
       ipaautomember:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: testing_group
         automember_type: group
         state: present
         action: member
         inclusive:
           - key: UID
             expression: .*

5. Save the file.

6. 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 inventory automember-usergroup-rule-present.yml

Verification steps

1. Log in as an IdM administrator.

   $ kinit admin

2. Add a user, for example:

   $ ipa user-add user101 --first user --last 101
   -----------------------
   Added user "user101"
   -----------------------
     User login: user101
     First name: user
     Last name: 101
     ...
     Member of groups: ipausers, testing_group
     ...

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Copy the automember-hostgroup-rule-absent.yml Ansible playbook file located in the /usr/share/doc/ansible-freeipa/playbooks/automember/ directory and name it, for example, automember-usergroup-rule-absent.yml:

   $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-absent.yml automember-usergroup-rule-absent.yml

3. Open the automember-usergroup-rule-absent.yml file for editing.

4. Adapt the file by modifying the following parameters:

   • Rename the playbook to correspond to your use case, for example: Automember user group rule member absent.
   • Rename the task to correspond to your use case, for example: Ensure an automember condition for a user group is absent.

   • Set the following variables in the ipaautomember task section:

     • Set the ipaadmin_password variable to the password of the IdM admin.
     • Set the name variable to testing_group.
     • Set the automember_type variable to group.
     • Ensure that the state variable is set to absent.
     • Ensure that the action variable is set to member.
     • Set the inclusive key variable to initials.
     • Set the inclusive expression variable to dp.

   This is the modified Ansible playbook file for the current example:

   ---
   - name: Automember user group rule member absent
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure an automember condition for a user group is absent
       ipaautomember:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: testing_group
         automember_type: group
         state: absent
         action: member
         inclusive:
           - key: initials
             expression: dp

5. Save the file.

6. 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 inventory automember-usergroup-rule-absent.yml

Verification steps

1. Log in as an IdM administrator.

   $ kinit admin

2. View the automember group:

   $ ipa automember-show --type=group testing_group
    Automember Rule: testing_group

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Copy the automember-group-absent.yml Ansible playbook file located in the /usr/share/doc/ansible-freeipa/playbooks/automember/ directory:

   $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-absent.yml automember-group-absent-copy.yml

3. Open the automember-group-absent-copy.yml file for editing.

4. Adapt the file by setting the following variables in the ipaautomember task section:

   • Set the ipaadmin_password variable to the password of the IdM admin.
   • Set the name variable to testing_group.
   • Set the automember_type variable to group.
   • Ensure that the state variable is set to absent.

   This is the modified Ansible playbook file for the current example:

   ---
   - name: Automember group absent example
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure group automember rule admins is absent
       ipaautomember:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: testing_group
         automember_type: group
         state: absent

5. Save the file.

6. 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 inventory automember-group-absent.yml

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

2. Copy the automember-hostgroup-rule-present.yml Ansible playbook file located in the /usr/share/doc/ansible-freeipa/playbooks/automember/ directory:

   $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-hostgroup-rule-present-copy.yml

3. Open the automember-hostgroup-rule-present-copy.yml file for editing.

4. Adapt the file by setting the following variables in the ipaautomember task section:

   • Set the ipaadmin_password variable to the password of the IdM admin.
   • Set the name variable to primary_dns_domain_hosts.
   • Set the automember_type variable to hostgroup.
   • Ensure that the state variable is set to present.
   • Ensure that the action variable is set to member.
   • Ensure that the inclusive key variable is set to fqdn.
   • Set the corresponding inclusive expression variable to .*.idm.example.com.
   • Set the exclusive key variable to fqdn.
   • Set the corresponding exclusive expression variable to .*.example.org.

   This is the modified Ansible playbook file for the current example:

   ---
   - name: Automember user group rule member present
     hosts: ipaserver
     vars_files:
     - /home/user_name/MyPlaybooks/secret.yml
     tasks:
     - name: Ensure an automember condition for a user group is present
       ipaautomember:
         ipaadmin_password: "{{ ipaadmin_password }}"
         name: primary_dns_domain_hosts
         automember_type: hostgroup
         state: present
         action: member
         inclusive:
           - key: fqdn
             expression: .*.idm.example.com
         exclusive:
           - key: fqdn
             expression: .*.example.org

5. Save the file.

6. 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 inventory automember-hostgroup-rule-present-copy.yml

1. The IdM client sends user credentials to an IdM server as part of the bind operation.
2. The IdM server DS checks the user credentials.
3. The IdM server DS checks the user account to see if the user has a permission to perform the requested operation.

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.