Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 878262 - ipa password auth failing for user principal name when shorter than IPA Realm name
ipa password auth failing for user principal name when shorter than IPA Realm...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.4
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
:
Depends On:
Blocks: 881827
  Show dependency treegraph
 
Reported: 2012-11-19 20:13 EST by Scott Poore
Modified: 2015-10-01 04:51 EDT (History)
7 users (show)

See Also:
Fixed In Version: sssd-1.9.2-25.el6
Doc Type: Bug Fix
Doc Text:
No documentation needed.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 04:40:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0508 normal SHIPPED_LIVE Low: sssd security, bug fix and enhancement update 2013-02-20 16:30:10 EST

  None (edit)
Description Scott Poore 2012-11-19 20:13:48 EST
Description of problem:

AD Trusted users where the full user@domain UPN is short than the IPA Realm name cannot ssh into IPA clients with password authentication.


[root@storm log]# kinit r2a1@ADLAB.QE
Password for r2a1@ADLAB.QE:
[root@storm log]# ssh -K -l r2a1@adlab.qe $(hostname)
Creating home directory for r2a1@adlab.qe.

-sh-4.1$ exit
logout
Connection to storm.ipa3.example.com closed.

[root@storm log]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: r2a1@ADLAB.QE

Valid starting     Expires            Service principal
11/19/12 13:40:03  11/19/12 23:40:26  krbtgt/ADLAB.QE@ADLAB.QE
        renew until 11/20/12 13:40:03
11/19/12 13:40:42  11/19/12 23:40:26  krbtgt/IPA3.EXAMPLE.COM@ADLAB.QE
        renew until 11/20/12 13:40:03
11/19/12 13:40:25  11/19/12 23:40:26  host/storm.ipa3.example.com@IPA3.EXAMPLE.COM
        renew until 11/20/12 13:40:03

[root@storm log]# kdestroy

[root@storm log]# ssh -l r2a1@adlab.qe $(hostname)
r2a1@adlab.qe@storm.ipa3.example.com's password:
Permission denied, please try again.
r2a1@adlab.qe@storm.ipa3.example.com's password:
Permission denied, please try again.
r2a1@adlab.qe@storm.ipa3.example.com's password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

^^^ the last attempt here, I also typed in another window and cut and pasted just to make certain I didn't have  a typo.

[root@storm log]# kinit r2a1@ADLAB.QE
Password for r2a1@ADLAB.QE:

^^^ cut and paste here from same buffer to make sure I had it right.

[root@storm log]# date
Mon Nov 19 13:41:45 EST 2012


/var/log/secure:

Nov 19 13:41:29 storm sshd[31308]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=storm.ipa3.example.com user=r2a1@adlab.qe
Nov 19 13:41:29 storm sshd[31308]: pam_sss(sshd:auth): received for user r2a1@adlab.qe: 4 (System error)
Nov 19 13:41:31 storm sshd[31308]: Failed password for r2a1@adlab.qe from 10.16.96.68 port 35721 ssh2
Nov 19 13:41:31 storm sshd[31309]: Connection closed by 10.16.96.68
Nov 19 13:41:31 storm sshd[31308]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=storm.ipa3.example.com  user=r2a1@adlab.qe


/var/log/sssd/sssd_ipa1.example.com.log:
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_dispatch] (0x4000): dbus conn: 25A7DE0
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo]
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [be_get_account_info] (0x0100): Got request for [3][1][name=r2a1]
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ipa_get_subdomain_account_info_send] (0x0400): Initgroups requests are not handled by the IPA provider but are resolved by the responder directly from the
 cache.
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup failed
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_dispatch] (0x4000): dbus conn: 25A7DE0
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [sbus_message_handler] (0x4000): Received SBUS method [pamHandler]
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [be_pam_handler] (0x0100): Got request with the following data
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): domain: adlab.qe
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): user: r2a1
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): service: sshd
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): tty: ssh
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): ruser:
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): rhost: storm.ipa3.example.com
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): authtok type: 1
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): authtok size: 10
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): newauthtok type: 0
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): newauthtok size: 0
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): priv: 1
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [pam_print_data] (0x0100): cli_pid: 31308
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x25c88d0

(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x25e6aa0

(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ldb] (0x4000): Destroying timer event 0x25e6aa0 "ltdb_timeout"

(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ldb] (0x4000): Ending timer event 0x25c88d0 "ltdb_callback"

(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [krb5_get_simple_upn] (0x4000): Using simple UPN [r2a1@ADLAB.QE].
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [krb5_auth_send] (0x0040): compare_principal_realm failed.
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed.
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][adlab.qe]
(Mon Nov 19 13:41:29 2012) [sssd[be[ipa3.example.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][adlab.qe]


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.   Setup IPA server with longer realm name like ipa1.example.com
2.   Setup AD server with shorter realm domain/realm name like ad.test
3.   Add AD User user@ad.test
4.   ssh -l user@ad.test <IPA server>
  
Actual results:
Fails like above


Expected results:
ssh in per norm.


Additional info:
Comment 2 Pavel Březina 2012-11-20 07:35:19 EST
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1658
Comment 3 Scott Poore 2012-11-20 11:24:43 EST
upstream fix seemed to work but, I had to restart sssd/winbind and it seems like I had to lookup the user (with wbinfo) before I could login successfully.  Is that expected behavior?
Comment 4 Jakub Hrozek 2012-11-20 15:05:43 EST
(In reply to comment #3)
> upstream fix seemed to work but, I had to restart sssd/winbind and it seems
> like I had to lookup the user (with wbinfo) before I could login
> successfully.  Is that expected behavior?

Sumit, I think you were discussing this issue with Scott on the IRC, is that right? Do you know what might be happening? In any way, I don't think that the problem is related to the too restrictive UPN/realm check, so I would prefer it to be tracked as a separate issue.
Comment 5 Sumit Bose 2012-11-20 15:46:08 EST
It is completely unrelated from my point of view. Scott, can you reproduce it?
Comment 7 Scott Poore 2012-11-26 11:47:31 EST
No I was unable to reproduce this when I tried previously.  If that behavior occurs again, we'll just open a separate bug and troubleshoot it that way.

Thanks
Comment 8 Steeve Goveas 2013-02-01 11:42:56 EST
[root@hp-bl480c-01 ~]# wbinfo --online-status
BUILTIN : online
IPALABEXAMPLE : online
ADLAB : online

[root@hp-bl480c-01 ~]# hostname 
hp-bl480c-01.ipalab.example.com

[root@hp-bl480c-01 ~]# kinit admin
Password for admin@IPALAB.EXAMPLE.COM: 

[root@hp-bl480c-01 ~]# ipa trust-find
---------------
1 trust matched
---------------
  Realm name: adlab.qe
  Domain NetBIOS name: ADLAB
  Domain Security Identifier: S-1-5-21-3655990580-1375374850-1633065477
  Trust type: Active Directory domain
----------------------------
Number of entries returned 1
----------------------------

[root@hp-bl480c-01 ~]# ssh -l tuser1@adlab.qe hp-bl480c-01.ipalab.example.com
tuser1@adlab.qe@hp-bl480c-01.ipalab.example.com's password: 
Your password will expire in 39 day(s).
Could not chdir to home directory /home/adlab.qe/tuser1: No such file or directory
-sh-4.1$ logout

[root@hp-bl480c-01 ~]# ssh -l fuser@adlab.qe hp-bl480c-01.ipalab.example.com
fuser@adlab.qe@hp-bl480c-01.ipalab.example.com's password: 
Your password will expire in 40 day(s).
Last login: Fri Feb  1 21:58:03 2013 from hp-bl480c-01.ipalab.example.com
-sh-4.1$ logout
Connection to hp-bl480c-01.ipalab.example.com closed.

[root@hp-bl480c-01 ~]# kinit fuser@ADLAB.QE
Password for fuser@ADLAB.QE: 

[root@hp-bl480c-01 ~]# ssh -K -l fuser@adlab.qe hp-bl480c-01.ipalab.example.com
Last login: Fri Feb  1 22:07:25 2013 from hp-bl480c-01.ipalab.example.com
-sh-4.1$ logout
Connection to hp-bl480c-01.ipalab.example.com closed.
Comment 9 errata-xmlrpc 2013-02-21 04:40:43 EST
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.

http://rhn.redhat.com/errata/RHSA-2013-0508.html

Note You need to log in before you can comment on or make changes to this bug.