Bug 878262 - ipa password auth failing for user principal name when shorter than IPA Realm name
Summary: ipa password auth failing for user principal name when shorter than IPA Realm...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks: 881827
TreeView+ depends on / blocked
 
Reported: 2012-11-20 01:13 UTC by Scott Poore
Modified: 2020-05-02 17:06 UTC (History)
7 users (show)

Fixed In Version: sssd-1.9.2-25.el6
Doc Type: Bug Fix
Doc Text:
No documentation needed.
Clone Of:
Environment:
Last Closed: 2013-02-21 09:40:43 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 2700 None None None 2020-05-02 17:06:56 UTC
Red Hat Product Errata RHSA-2013:0508 normal SHIPPED_LIVE Low: sssd security, bug fix and enhancement update 2013-02-20 21:30:10 UTC

Description Scott Poore 2012-11-20 01:13:48 UTC
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 12:35:19 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1658

Comment 3 Scott Poore 2012-11-20 16:24:43 UTC
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 20:05:43 UTC
(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 20:46:08 UTC
It is completely unrelated from my point of view. Scott, can you reproduce it?

Comment 7 Scott Poore 2012-11-26 16:47:31 UTC
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 16:42:56 UTC
[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 09:40:43 UTC
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.