Bug 1028422

Summary: sssd can't retrieve auto.master when using the "default_domain_suffix" option in
Product: Red Hat Enterprise Linux 6 Reporter: shridhar <sgadekar>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED ERRATA QA Contact: Kaushik Banerjee <kbanerje>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.4CC: ekeck, grajaiya, jgalipea, jkurik, kbanerje, lslebodn, masanari_iida, mkosek, nsoman, parsonsa, pbrezina, sgadekar, sgoveas
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sssd-1.11.5.1-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: The default_domain_suffix option should have been ignored in the autofs responder as it mostly concerns user entries and autofs has its own qualification method. Consequence: autofs maps could not be retrieved when the default_domain_suffix was enabled. Fix: The default_domain_suffix option is now ignored in the autofs responder. Result: autofs maps can be retrieved when the default_domain_suffix is enabled.
Story Points: ---
Clone Of:
: 1036157 (view as bug list) Environment:
Last Closed: 2014-10-14 04:47:07 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:
Bug Depends On:    
Bug Blocks: 1036157, 1036168, 1061410    
Attachments:
Description Flags
workaround patch none

Description shridhar 2013-11-08 12:08:30 UTC
Created attachment 821570 [details]
workaround patch

Description of problem:


I would like to preface this bug report that we are aware AD trusts are a tech preview, but this bug in sssd is present without an AD trust present.  It's just that the common use case, with an AD trust in place, is where the bug was exposed.  The "default_domain_suffix" option likely wouldn't be used any other time.  I have included the sosreport for the IPA server as well, but it's really not relevant as the bug is in sssd.  On to the bug report...

This bug is present in 6.4 and 6.5 beta.  The sosreport for ipaclient01 is from 6.5 beta.

We have hit a major issue with sssd regarding sssd, autofs and an IPA domain with an AD trust.  The problem lies within sssd, in that it can't retrieve autofs maps from an IPA domain that has an AD trust formed when the "default_domain_suffix" option is used.  It fails to retrieve the map and automount will segfault when sssd does not respond.

It appears that the "default_domain_suffix" option is being applied to the auto.master lookup, when it should only be applied to users.

Attempting to fully-qualify the auto.master entry in /etc/auto.master (e.g., +auto.master@linux.ad.priv) results in another sssd error, where it's confused that it got a response but no data.  I'm sure the Red Hat engineers will see this if they attempt the workaround I did.

The only way to work around this is to disable "default_domain_suffix".  This is not really acceptable since it's a user-facing change, requiring them to input their fully-qualified username.


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

Present in RHEL6.4 and RHEL6.5 beta version as well.
sssd-client-1.9.2-82.10.el6_4.x86_64
sssd-1.9.2-82.10.el6_4.x86_64


How reproducible:
 

Steps to Reproduce:
 - setup IPA
- setup AD
- form trust between IPA and AD, with the IPA domain being a subdomain (ipa.ad.priv and ad.priv)
- enable nss for automount in /etc/nsswitch.conf
- add the "default_domain_prefix" option in the [sssd] section of sssd.conf
- service sssd restart
- service autofs restart; automount -m
- automount -m will segfault, sssd will not pull the maps from IPA

Actual results:
it can't retrieve autofs maps from an IPA domain that has an AD trust formed when the "default_domain_suffix" option is used.  It fails to retrieve the map and automount will segfault when sssd does not respond.

relevant sssd log of the problem:
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x2000): sss_autofs_cmd_setautomntent
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_autofs_cmd_setautomntent] (0x0400): Got request for automount map named auto.master
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): default domain [AD.PRIV] is currently not know, trying to look it up.
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [setautomntent_send] (0x0010): Invalid name received [auto.master]
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_autofs_cmd_setautomntent_done] (0x2000): setautomntent done
(Wed Nov  6 08:52:06 2013) [sssd[autofs]] [sss_autofs_cmd_setautomntent_done] (0x0020): setautomntent_recv failed


Expected results:
It should retrieve autofs maps from IPA domain.

Additional info:
work around patch is attached

Comment 2 RHEL Product and Program Management 2013-11-11 13:07:23 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 Jakub Hrozek 2013-11-12 12:19:01 UTC
Thanks for the bug report and the patch. I think the patch is correct in general and I suspect we should limit the effect of default_domain_suffix on users and groups only.

I'll start a discussion upstream.

Comment 4 Jakub Hrozek 2013-11-12 12:34:09 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2146

Comment 5 Jakub Hrozek 2013-11-18 16:16:38 UTC
Hello,

the patch was accepted upstream -- thank you for reporting the bug and submitting a patch!

I wanted to check with you about two things:

1) Did the SSSD work for you in your setup with the patch? It did for me, but perhaps there was another change in your setup that is not present in my test environment. Please note I tested with pretty much vanilla IPA server, the RDNs were not qualified.

2) We might be releasing a 6.5.z update in the near future. If this bug is something that is blocking your environment, kindly work with Red Hat support on getting this bugzilla into the update.

Thanks again for submitting the patch!

Comment 6 Jakub Hrozek 2013-11-18 16:20:05 UTC
Fix was pushed upstream:
    sssd-1-11: f0f138891f0aacc592ec5c9660a0e32ab55cff37
    master: 620cbbcadd42627e55210045cac66c66df4f1243

Comment 7 Aron Parsons 2013-11-18 16:48:03 UTC
(In reply to Jakub Hrozek from comment #5)
> Hello,
> 
> the patch was accepted upstream -- thank you for reporting the bug and
> submitting a patch!
> 
> I wanted to check with you about two things:
> 
> 1) Did the SSSD work for you in your setup with the patch? It did for me,
> but perhaps there was another change in your setup that is not present in my
> test environment. Please note I tested with pretty much vanilla IPA server,
> the RDNs were not qualified.
> 
> 2) We might be releasing a 6.5.z update in the near future. If this bug is
> something that is blocking your environment, kindly work with Red Hat
> support on getting this bugzilla into the update.
> 
> Thanks again for submitting the patch!

Yes, the patch works with our AD trust setup; we've been running it for 2 weeks in two separate environments that have multiple automount locations each and various types of maps.

I will work with GSS to get this into RHEL 6.5.  We like to try and minimize the length of time we run patched RHEL packages to fix our bugs :-)

Comment 8 Jakub Hrozek 2013-11-18 20:24:04 UTC
(In reply to Aron Parsons from comment #7)
> I will work with GSS to get this into RHEL 6.5.  We like to try and minimize
> the length of time we run patched RHEL packages to fix our bugs :-)

Thanks; that's exactly why I gave the heads-up that there might be a 6.5 update coming up!

Comment 15 Steeve Goveas 2014-07-30 14:56:32 UTC
* On IPA server

[root@hp-ms-01-c21 ~]# ipa trust-find
---------------
1 trust matched
---------------
  Realm name: adtest.qe
  Domain NetBIOS name: ADTEST
  Domain Security Identifier: S-1-5-21-1910160501-511572375-3625658879
  SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10,
                          S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10,
                          S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  Trust type: Active Directory domain
----------------------------
Number of entries returned 1
----------------------------

[root@hp-ms-01-c21 ~]# ipa host-find hp-ms-01-c11 --pkey-only
--------------
1 host matched
--------------
  Host name: hp-ms-01-c11.testrelm.test
----------------------------
Number of entries returned 1
----------------------------

* On IPA client

[root@hp-ms-01-c11 ~]# grep automount /etc/nsswitch.conf
#automount:  files sss
automount:  sss files

[root@hp-ms-01-c11 ~]# grep -B3 "default_domain_suffix" /etc/sssd/sssd.conf 
[sssd]
services = nss, sudo, pam, ssh, autofs
config_file_version = 2
default_domain_suffix = adtest.qe

[root@hp-ms-01-c11 ~]# grep -A2 "\[autofs\]" /etc/sssd/sssd.conf 
[autofs]
debug_level = 10

[root@hp-ms-01-c11 ~]# service sssd restart
Stopping sssd: [  OK  ]
Starting sssd: [  OK  ]

[root@hp-ms-01-c11 ~]# service autofs restart
Loading autofs4: [  OK  ]
Starting automount: [  OK  ]

[root@hp-ms-01-c11 ~]# getent passwd administrator
administrator@adtest.qe:*:1148400500:1148400500::/home/adtest.qe/administrator:

[root@hp-ms-01-c11 ~]# ipa automountkey-add default auto.master --key=/new --info=auto.new
--------------------------
Added automount key "/new"
--------------------------
  Key: /new
  Mount information: auto.new
 
[root@hp-ms-01-c11 ~]# ipa automountkey-find default
Map: auto.master
------------------------
2 automount keys matched
------------------------
  Key: /-
  Mount information: auto.direct
 
  Key: /new
  Mount information: auto.new
----------------------------
Number of entries returned 2
----------------------------

[root@hp-ms-01-c11 ~]# automount -m
 
autofs dump map information
===========================
 
global options: none configured
 
Mount point: /-
 
source(s):
lookup_read_map: lookup(sss): getautomntent_r: No such file or directory
  failed to read map
 
 
Mount point: /new
 
source(s):
setautomntent: lookup(sss): setautomntent: No such file or directory
 
  instance type(s): sss
  map: auto.new
 
  no keys found in map

Verified in version
[root@hp-ms-01-c11 ~]# rpm -q sssd sssd-client
sssd-1.11.6-12.el6.x86_64
sssd-client-1.11.6-12.el6.x86_64

Comment 16 errata-xmlrpc 2014-10-14 04:47:07 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/RHBA-2014-1375.html

Comment 17 masanari iida 2014-11-27 09:28:06 UTC
On RHBA-2014-1375.html page,  libsss_autofs is not on the list.
And also this file is not on DVD image or Red Hat Network web site.
I checked out RHEL6.6 Technical note, but I couldn't find any special 
reason why the RPM was removed.

Comment 18 Lukas Slebodnik 2014-11-27 10:46:50 UTC
The packaging of sssd >= 1.10 was changed. The sss autofs plugin isn;t anymore in separate package. It was merged to the package sssd-common and thus it is  installed by default.


bash-4.1# rpm -q --provides sssd-common | grep autofs
libsss_autofs = 1.11.6-30.el6
libsss_autofs.so()(64bit)  
libsss_autofs.so(EXPORTED)(64bit)

You can still run "yum install libsss_autofs" because it is provided by package sssd-common.

bash-4.1# yum install libsss_autofs
Loaded plugins: fastestmirror
Determining fastest mirrors
 * base: bay.uchicago.edu
 * extras: mirror.us.leaseweb.net
 * libselinux: mirrors.mit.edu
 * updates: mirror.es.its.nyu.edu
Setting up Install Process
Resolving Dependencies
//few lines omitted.

Dependencies Resolved

================================================================================
 Package                Arch          Version                 Repository   Size
================================================================================
Installing:
 sssd-common            x86_64        1.11.6-30.el6           base        832 k
Installing for dependencies:
 c-ares                 x86_64        1.10.0-3.el6            base         75 k
 libbasicobjects        x86_64        0.1.1-11.el6            base         21 k
 libcollection          x86_64        0.6.2-11.el6            base         36 k
 libdhash               x86_64        0.4.3-11.el6            base         24 k
 libini_config          x86_64        1.1.0-11.el6            base         46 k
 libldb                 x86_64        1.1.13-3.el6            base        111 k
 libnl                  x86_64        1.1.4-2.el6             base        121 k
 libpath_utils          x86_64        0.2.1-11.el6            base         24 k
 libref_array           x86_64        0.1.4-11.el6            base         23 k
 libsss_idmap           x86_64        1.11.6-30.el6           base         98 k
 libtalloc              x86_64        2.0.7-2.el6             base         20 k
 libtdb                 x86_64        1.2.10-1.el6            base         33 k
 libtevent              x86_64        0.9.18-3.el6            base         26 k
 sssd-client            x86_64        1.11.6-30.el6           base        128 k

Transaction Summary
================================================================================
Install      15 Package(s)

Total download size: 1.6 M
Installed size: 4.0 M