RH342 - ch09s06

Bookmark this page

Guided Exercise: Resolving Identity Management Issues

Resolve an issue related to LDAP user information and Kerberos authentication.

Outcomes

You should be able to diagnose and resolve issues with LDAP user information and Kerberos authentication.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command installs and configures the IdM client on servera for use in this exercise.

[student@workstation ~]$ lab start security-ldap

Instructions

The servera machine is a client to the IdM server for LDAP and Kerberos KDC services for user authentication. At your organization, remote users log in to the servera client machine with SSH keys instead of passwords. User home directories automatically mount at login.

The operator1 user reported that when remotely logging in to the servera machine, the connection prompts for a password and either times out after entering a password or immediately disconnects.

The system administrator provided you with the necessary information to troubleshoot the issue. Use RedHat123^ as the password for the operator1 and admin user accounts. Client systems and accounts are in the lab.example.com domain that the IdM server supports.

Re-create the issue.

From the workstation machine, attempt to log in to the operator1 account on the servera machine. The password prompt means that authentication is not working as expected and further investigation is necessary. Press Ctrl+C at any time to exit the authentication process.

The expected failure should look like this example:

[student@workstation ~]$ ssh operator1@servera
operator@servera's password: RedHat123^
Connection to servera closed by remote host.
Connection to servera closed.
[student@workstation ~]$

The failure might also appear as multiple password attempts until disconnection.

[student@workstation ~]$ ssh operator1@servera
Password: RedHat123^
Password: RedHat123^
Password: RedHat123^
operator1@servera's password: RedHat123^
Permission denied, please try again.
operator1@servera's password: RedHat123^
Received disconnect from 172.25.250.10 port 22:2: Too many authentication failures
Disconnected from 172.25.250.10 port 22
[student@workstation ~]$

Log in to the servera machine and switch to the root user.
The student account succeeds, which indicates that the IdM server is functioning, and that the issue might be limited to the operator1 user.
```
[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$ sudo -i
[sudo] password for student: student
[root@servera ~]#
```

Start the troubleshooting process by verifying the IdM server's Kerberos functions.
1. Verify that the IdM service is providing Kerberos tickets.
  Use the kinit admin command to authenticate and obtain Kerberos credentials. Use RedHat123^ as the password.
```
[root@servera ~]# kinit admin
Password for admin@LAB.EXAMPLE.COM: RedHat123^
[root@servera ~]#
```
2. Verify that the Kerberos ticket is created.
  The server's LDAP and Kerberos mechanisms appear to be functioning normally.
```
[root@servera ~]# klist
Default principal: admin@LAB.EXAMPLE.COM

Valid starting       Expires              Service principal
11/19/2021 00:12:27  11/19/2021 23:18:24  krbtgt/LAB.EXAMPLE.COM@LAB.EXAMPLE.COM
```

Next, diagnose SSSD operations.

Clear the SSSD log files on the servera machine and attempt to log in as the operator1 user to generate fresh logs. Search the log files for possible errors.

Enable detailed SSSD debug logging.
```
[root@servera ~]# sssctl debug-level 6
```
Invalidate all objects in the SSSD cache. Invalidating cache objects ensures that you do not bypass the LDAP database and retrieve SSSD already cached information.
```
[root@servera ~]# sss_cache -E
```

Clear previous SSSD logs to minimize the troubleshooting data set.

[root@servera ~]# sssctl logs-remove
Truncating log files...
[root@servera ~]#

Confirm that the /var/log/sssd/sssd_lab.example.com.log file is empty, or nearly empty. Run the sssctl logs-remove command again if the file is larger than 1000 bytes.
```
[root@servera ~]# ls -l /var/log/sssd/
total 4
...output omitted...
-rw-------. 1 root root    850 Nov 18 23:12 sssd_lab.example.com.log
...output omitted...
```
Attempt to switch to the operator1 user account while gathering timestamps before and after the attempt. These timestamps narrow the scope of the data set.
```
[root@servera ~]# date; su operator1; date
Thu Nov 18 23:13:19 EST 2021
su: user operator1 does not exist
Thu Nov 18 23:13:19 EST 2021
```

Review the SSSD logs for information about a failed request.

In the following log file, a request is made for the operator1 user with a data provider (DP) request type of Account. The search is based on a top-level domain component of .net, which is incorrect. The information from the system administrator indicates that the domain should be lab.example.com.

[root@servera ~]# cat /var/log/sssd/sssd_lab.example.com.log
...output omitted...
(2021-11-18 23:13:19): [be[lab.example.com]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=operator1@lab.example.com]
(2021-11-18 23:13:19): [be[lab.example.com]] [dp_attach_req] (0x0400): DP Request [Account #5]: New request. Flags [0x0001].
(2021-11-18 23:13:19): [be[lab.example.com]] [dp_attach_req] (0x0400): Number of active DP request: 1
(2021-11-18 23:13:19): [be[lab.example.com]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=lab,dc=example,dc=net]
(2021-11-18 23:13:19): [be[lab.example.com]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=operator1)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=lab,dc=example,dc=net].
(2021-11-18 23:13:19): [be[lab.example.com]] [sdap_get_generic_op_finished] (0x0400): Search result: No such object(32), no errmsg set
(2021-11-18 23:13:19): [be[lab.example.com]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
(2021-11-18 23:13:19): [be[lab.example.com]] [sysdb_search_by_name] (0x0400): No such entry
(2021-11-18 23:13:19): [be[lab.example.com]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
...output omitted...

Locate and fix the incorrect configuration.

Review the SSD configuration.

Check the contents of the /etc/sssd/sssd.conf file for a possible error in data provider entries. All domain entries should be in the lab.example.com domain.

[root@servera ~]# cat /etc/sssd/sssd.conf
[domain/lab.example.com]

id_provider = ipa
dns_discovery_domain = lab.example.net
ipa_server = _srv_, utility.lab.example.com
ipa_domain = lab.example.net
ipa_hostname = servera.lab.example.com
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
[sssd]
services = nss, pam, ssh, sudo

domains = lab.example.com
...output omitted...

Edit the incorrect values.
The dns_discovery_domain and ipa_domain key values are incorrect. These key values should represent the .com top-level domain component. Correct both entries and restart the sssd service.
The key values should match the following:
```
[root@servera ~]# cat /etc/sssd/sssd.conf
...output omitted...
dns_discovery_domain = lab.example.com
...output omitted...
ipa_domain = lab.example.com
...output omitted...
```
Restart the sssd service to implement the new configuration.
```
[root@servera ~]# systemctl restart sssd
```

Verify the operator1 user by attempting to log in again.
When functioning correctly, the user is not prompted for a password and has an automatically mounted home directory.
1. Return to workstation as the student user.
```
[root@servera ~]# exit
[student@servera ~]$ exit
[student@workstation ~]$
```
2. Log in to the servera system as the operator1 user.
```
[student@workstation ~]$ ssh operator1@servera
...output omitted...
[operator1@servera ~]$
```
3. Verify that the operator1 user has a home directory on the servera machine.
  If the working directory returned is the system's root directory, then the automatic home directory mount failed. The home directory appears correct.
```
[operator1@servera ~]$ pwd
/home/operator1
[operator1@servera ~]$
```
4. Return to workstation as the student user.
```
[operator1@servera ~]$ exit
[student@workstation ~]$
```

Finish

On the workstation machine, use the lab command to complete this exercise. This is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish security-ldap

Discuss Red Hat Enterprise Linux Diagnostics and Troubleshooting

Go to community

Welcome to the Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) group!

cschunke

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Enterprise Linux Diagnostics and Troubleshooting! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH342.Read more about Red Hat Enterprise Linux Diagnostics and Troubleshooting here.

445

Revision: rh342-8.4-6dd89bd

Click Create to build all of the virtual machines needed for the classroom lab environment. This may take several minutes to complete. Once created the environment can then be stopped and restarted to pause your experience.
When a lab is created, click Start to run all of the virtual machines in the classroom.
Click Stop to stop all the virtual machines from running. This will not delete your lab.
If you Delete your lab, you will remove all of the virtual machines in your classroom and lose all of your progress.

Virtual machine actions

Click Start to power on the virtual machine.
Click Shutdown to gracefully shut down the virtual machine, preserving disk contents.
Click Power off to forcefully shut down the virtual machine, while still preserving disk contents.
Click Open console to connect to the system console of the virtual machine in a new browser.

Auto-stop timer

The Red Hat Learning Subscription entitles you to set allotment of lab time.
To help conserving your allotted time, the lab environment uses automatic timers to stop or destroy your lab environment when the timer expires.

Click the Auto-stop button [+] to extend the time you would like to spend with the labs.
Click the Auto-destroy button [+] to add day(s) to the auto-destroy timer.

Auto-stop has a maximum of 11 hours, and auto-destroy has a maximum of 14 days.
Be careful to keep the timers set while you are working, so that your environment doesn't shut down unexpectedly.
We also suggest not to set the auto-timers unnecessarily high, which could waste your lab time allotment