Configuring and managing Identity Management

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

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   $ ipa help user | less

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

1. Enter about:config in the address bar to access the Mozilla Firefox preferences menu.
2. Enter security.tls.enable_post_handshake_auth in the search bar.
3. Click the toggle button to set the parameter to true.

1. Open the /etc/httpd/conf.d/ssl.conf configuration file.

2. Add -TLSv1.3 to the SSLProtocol option:

   SSLProtocol all -TLSv1 -TLSv1.1 -TLSv1.3

   Copy to Clipboard Toggle word wrap

3. Restart the httpd service:

   service httpd restart

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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. Open the IdM Web UI login dialog in your web browser.

2. Click the link for the 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

   Copy to Clipboard Toggle word wrap
   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

   Copy to Clipboard Toggle word wrap

   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 IdM admin privileges.

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

   

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

Procedure

1. Add a RADIUS proxy:

   $ ipa radiusproxy-add proxy_name --secret secret

   Copy to Clipboard Toggle word wrap

   The command prompts you for inserting the required information.

   The configuration of the RADIUS proxy requires the use of a common secret between the client and the server to wrap credentials. Specify this secret in the --secret parameter.

2. Assign a user to the added proxy:

   ipa user-mod radiususer --radius=proxy_name

   Copy to Clipboard Toggle word wrap

3. If required, configure the user name to be sent to RADIUS:

   ipa user-mod radiususer --radius-username=radius_user

   Copy to Clipboard Toggle word wrap

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 a 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. Optional: 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 one time password authentication.
4. Enter the new password twice for verification.

5. Click Reset Password.

   

Procedure

1. Initialize the credentials cache by running the following command:

   [root@client ~]# kinit -n @IDM.EXAMPLE.COM -c FILE:armor.ccache

   Copy to Clipboard Toggle word wrap

   Note that this command creates the armor.ccache file that you need to point to whenever you request a new Kerberos ticket.

2. Request a Kerberos ticket by running the command:

   [root@client ~]# kinit -T FILE:armor.ccache <username>@IDM.EXAMPLE.COM
   Enter your OTP Token Value.

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
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 <domain_name> --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

   Copy to Clipboard Toggle word wrap

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

   [user@client ~]$ ping <IP_address_of_the_database_server>

   Copy to Clipboard Toggle word wrap

   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.<domain>@<server_name>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   Copy to Clipboard Toggle word wrap

   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. To restrict SSSD to specific servers, define them in the sssd.conf configuration file using the following options:

   • 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=<idm_user>

      Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

   2. If LDAP server database is an AD server:

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

      Copy to Clipboard Toggle word wrap

   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 <idm_user>
   [user@client ~]$ id <idm_user>

   Copy to Clipboard Toggle word wrap

   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 have sudo privileges 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 <idm_user>

   Copy to Clipboard Toggle word wrap

   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/<domain_name>]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = <domain_name>
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

   Copy to Clipboard Toggle word wrap
3. Save and close the sssd.conf file.

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

   [root@server ~]# systemctl restart sssd

   Copy to Clipboard Toggle word wrap

Procedure

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

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 <idm_user>; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 15:33:49 EDT 2021

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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=idm_user@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=idm_user)(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

   Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

   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 <idm_user>; date
         Mon Mar 29 15:33:48 EDT 2021
         id: 'idm_user': no such user
         Mon Mar 29 15:33:49 EDT 2021

         Copy to Clipboard Toggle word wrap

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 using its fully qualified domain name (FQDN). This avoids the IdM client autodiscovering other IdM servers, thus limiting this test to just one client and one server.

   [domain/<idm_domain_name>]
   ipa_server = <idm_server_fqdn>
   ...

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   [root@client ~]# sssctl cache-expire -u <idm_user>

   Copy to Clipboard Toggle word wrap

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

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

   [root@server ~]# sssctl logs-remove

   Copy to Clipboard Toggle word wrap

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 <idm_user>; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idm_user does not exist
   Mon Mar 29 16:20:14 EDT 2021

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

       Copy to Clipboard Toggle word wrap

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

       Copy to Clipboard Toggle word wrap

    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 <idm_user>; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idm_user does not exist
          Mon Mar 29 16:20:14 EDT 2021

          Copy to Clipboard Toggle word wrap

Procedure

1. To review your SSSD log file, open the log file /var/log/sssd/sssd_<domain_name>.log using the less utility. For example:

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

Procedure

1. Change into the ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   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.

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   These commands require that you enter the IdM admin password.

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

   redhat

   Copy to Clipboard Toggle word wrap

7. Change the permissions to modify the file:

   $ chmod 0600 password_file

   Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

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

      ipaadmin_password: Secret123

      Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

Procedure

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

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

   Copy to Clipboard Toggle word wrap

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

   [ipaserver]
   server.idm.example.com

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

1. Log into ipaserver as IdM administrator:

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

1. Log into ipaserver as IdM administrator:

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

   Copy to Clipboard Toggle word wrap

2. Display the current shell:

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

   Copy to Clipboard Toggle word wrap

   The logged-in user is using the sh shell.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap

   When prompted, provide the vault file password.

Procedure

1. Navigate to your ~/MyPlaybooks/ directory:

   $ cd ~/MyPlaybooks/

   Copy to Clipboard Toggle word wrap
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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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_.$-]?

   Copy to Clipboard Toggle word wrap
   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
    ...

   Copy to Clipboard Toggle word wrap

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

   $ ipa help user-add

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   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"
   --------------------

   Copy to Clipboard Toggle word wrap