Red Hat Bugzilla – Bug 1097286
Expanding home directory fails when the request comes from the PAC responder
Last modified: 2015-10-01 04:50:35 EDT
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/2333 When a request for a user is a lookup by SID, typicaly when it comes from the PAC responder, we don't handle the request well and error out. This would be the symptoms: {{{ [apply_subdomain_homedir] (0x0040): Unsupported filter type: [4] }}}
Note that this is severe bug for Windows Server 2012 interoperability. Without the fix in place, no single sign-on is possible with SSSD. This largerly kills the benefit of Kerberos cross-forest trusts.
(In reply to Alexander Bokovoy from comment #1) > Note that this is severe bug for Windows Server 2012 interoperability. > Without the fix in place, no single sign-on is possible with SSSD. This > largerly kills the benefit of Kerberos cross-forest trusts. Clarification -- the bug *only* hits the SSSD in server mode, not the clients. But I agree this is a bad one and would prevent the AD admins from logging in to the IDM servers.
To reproduce, login with GSSAPI on the IPA client: ssh -k -l Administrator@AD.REALM `hostname`
Please add steps to reproduce/verify this issue
refreshed page and saw you already added steps - thanks :)
(In reply to Jakub Hrozek from comment #3) > To reproduce, login with GSSAPI on the IPA client: > > ssh -k -l Administrator@AD.REALM `hostname` Err, I'm sorry, I meant to say login with GSSAPI on the IPA *SERVER*.
when would response come from PAC responder, versus not from PAC responder? Also please include info about pkg versions for server and client, and /etc/redhat-release to help reproduce.
also - why is the user logging into the server? isn't a ad user typically logging into the client?
(In reply to Namita Soman from comment #7) > when would response come from PAC responder, versus not from PAC responder? > When logging with GSSAPI > Also please include info about pkg versions for server and client, and > /etc/redhat-release to help reproduce. RHEL7 latest as of today.
(In reply to Namita Soman from comment #8) > also - why is the user logging into the server? isn't a ad user typically > logging into the client? The AD admin might want to perform maintenance on the server.
Proposing for RHEL7 0day
Verified in version * Passwordless login on IPA Server [root@gizmo ~]# rpm -q sssd sssd-1.12.2-12.el7.x86_64 [root@gizmo ~]# grep ipa_server /etc/sssd/sssd.conf ipa_server = _srv_, ibm-x3620m3-01.steeve2011.test [root@gizmo ~]# kdestroy -A [root@gizmo ~]# echo Secret123 | kinit Administrator@ADTEST.QE Password for Administrator@ADTEST.QE: [root@gizmo ~]# ssh -K -l Administrator@adtest.qe ibm-x3620m3-01.steeve2011.test Creating home directory for Administrator@adtest.qe. -sh-4.2$ pwd /home/adtest.qe/administrator -sh-4.2$ id uid=1148400500(administrator@adtest.qe) gid=1148400500(administrator@adtest.qe) groups=1148400500(administrator@adtest.qe),1148400512(domain admins@adtest.qe),1148400513(domain users@adtest.qe),1148400518(schema admins@adtest.qe),1148400519(enterprise admins@adtest.qe),1148400520(group policy creator owners@adtest.qe) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -sh-4.2$ logout Connection to ibm-x3620m3-01.steeve2011.test closed. * Passwordless login on IPA client [root@gizmo ~]# ssh -K -l Administrator@adtest.qe `hostname` Creating home directory for Administrator@adtest.qe. -sh-4.2$ hostname gizmo.steeve2011.test -sh-4.2$ klist Ticket cache: KEYRING:persistent:1148400500:1148400500 Default principal: Administrator@ADTEST.QE Valid starting Expires Service principal 11/24/2014 02:18:03 11/24/2014 12:07:31 krbtgt/ADTEST.QE@ADTEST.QE renew until 11/25/2014 02:07:30
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/RHBA-2015-0441.html