Bug 1363690
| Summary: | ssh login permission denied when ldap/krb5 is enabled via authconfig | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Patrik Kis <pkis> | |
| Component: | krb5 | Assignee: | Robbie Harwood <rharwood> | |
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> | |
| Severity: | high | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.3 | CC: | dpal, grajaiya, jhrozek, lslebodn, mkosek, mzidek, pbrezina, pkis, rcritten, rharwood | |
| Target Milestone: | rc | Keywords: | Regression | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | http://krbdev.mit.edu/rt/Ticket/Display.html?id=8454 | |||
| Whiteboard: | ||||
| Fixed In Version: | krb5-1.14.1-26.el7 | Doc Type: | No Doc Update | |
| Doc Text: |
Issue was found in testing; no docs update needed. Following are kept for completeness and were docs for if we shipped without this fixed.
*ssh* login failures for user principals without pre-authentication enabled
When no pre-authentication is required for a Kerberos user principal, the responder is not called for the principal. This can lead for example to *ssh* login failures for the user on systems that have LDAP and Kerberos authentication enabled through the *authconfig* utility. Note that in this situation, the "getent passwd" command still retrieves the user identity as expected.
As a workaround, enable pre-authentication for the user principal on the key distribution center (KDC):
# kadmin.local
kadmin.local: modprinc +requires_preauth [principal]
Note that enabling pre-authentication is considered recommended practice in most situations.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1370622 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-03 20:26:04 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1362179, 1370622 | |||
|
Description
Patrik Kis
2016-08-03 11:12:52 UTC
(Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [sss_krb5_prompter] (0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1] EINVAL. (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [sss_krb5_prompter] (0x4000): Prompt [0][Password for sssdtester]. (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [get_and_save_tgt] (0x0020): 1296: [-1765328254][Cannot read password] (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [map_krb5_error] (0x0020): 1365: [-1765328254][Cannot read password] (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [k5c_send_data] (0x0200): Received error code 1432158218 (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [k5c_send_data] (0x4000): Response sent. (Wed Aug 3 09:24:16 2016) [[sssd[krb5_child[20057]]]] [main] (0x0400): krb5_child completed successfully Judging by the error messages, I wonder if this is a Kerberos bug someone reported to us on the sssd-users list earlier. You can see the whole thread here: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/D3C2DDA7EDIEPZLSWXE53TFY4GGAICRN/ But Sumit's response summed up what can be done to mitigate the issue: ~~~~~~~~~~~~~~~ Thanks I was able to reproduce the issue. After discussing it with a co-worker I opened http://krbdev.mit.edu/rt/Ticket/Display.html?id=8454 because we think it is originally an issue in the responder interface of MIT Kerberos. I would like to hear back from MIT before trying to fix the SSSD side. I'm pretty sure that authentication would work again if you enable pre-authentication for the user principals on the KDC # kadmin.local kadmin.local: modprinc +requires_preauth dave(a)LA-LA.LAN Is there a reason why pre-authentication is disabled? If not it is very, very, very recommended to enable it (not only to make SSSD work), see e.g. http://superuser.com/questions/200010/how-does-kerberos-preauthentication... for some explanations. bye, Sumit ~~~~~~~~~~~~~~~ Can you try if enabling preauthentication helps you as well? btw the upstream bug report was http://krbdev.mit.edu/rt/Ticket/Display.html?id=8454 I can confirm that preauth added for the test principal fixed the issue. Thank you for the investigation. (In reply to Patrik Kis from comment #9) > I can confirm that preauth added for the test principal fixed the issue. > Thank you for the investigation. Thanks, then I'm moving the bug report to krb5, because it should track the upstream report http://krbdev.mit.edu/rt/Ticket/Display.html?id=8454 Do we need to add requires/conflicts into sssd after fixing krb5? There is still a chance that someone would like to test sssd-1.14 on rhel7.2 (In reply to Lukas Slebodnik from comment #11) > Do we need to add requires/conflicts into sssd after fixing krb5? > There is still a chance that someone would like to test sssd-1.14 on rhel7.2 Since this issue is caused by patches that were only applied to 7.3 in RHEL, then I don't think so -- is it even possible to install 7.3 RPMs on a 7.2 system? I don't know how to solve this at the upstream level. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2591.html |