Bug 1534749

Summary:	Requesting an AD user's private group and then the user itself returns an emty homedir
Product:	Red Hat Enterprise Linux 7	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED ERRATA	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	fidencio, grajaiya, jhrozek, ksiddiqu, lslebodn, mkosek, mzidek, ndehadra, pbrezina, sgoveas, sumenon, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.16.2-1.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-30 10:41:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jakub Hrozek 2018-01-15 21:25:42 UTC

This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3615

If a group was being looked by using sysdb_search_by_name() in a MPG
domain, the code would search only for group objects -- but in a MPG
domain, there may be none, the groups are typically inferred from a user
object.

This could have caused issues e.g. for IPA code with the following
sequence:
```
getent group aduser
getent passwd aduser
```

The former would fail to add the fallback subdomain homedir and the latter
would then return a user entry without a homedir, with libc falling back to
the "/" homedir.

NOTE: The patch has no unit test. I'll add one when the approach is
confirmed as correct by another developer.

Comment 2 Lukas Slebodnik 2018-01-18 11:42:04 UTC

master:
* 6df34be3ee736d7a34e67c49c365077be849031a

Comment 7 Sudhir Menon 2018-08-16 09:16:09 UTC

Tested on RHEL7.6 using the below rpms

[root@vm-idm-028 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.6 Beta (Maipo)

[root@vm-idm-028 ~]# rpm -q ipa-server sssd samba pki-server pki-ca selinux-policy 389-ds-base
ipa-server-4.6.4-5.el7.x86_64
sssd-1.16.2-12.el7.x86_64
samba-4.8.3-4.el7.x86_64
pki-server-10.5.9-5.el7.noarch
pki-ca-10.5.9-5.el7.noarch
selinux-policy-3.13.1-215.el7.noarch
389-ds-base-1.3.8.4-10.el7.x86_64

[root@vm-idm-028 ~]# ipa trust-add --two-way=true
Realm name: ipaad2016.test
Active Directory domain administrator: administrator
Active Directory domain administrator's password: 
-------------------------------------------------------
Added Active Directory trust for realm "ipaad2016.test"
-------------------------------------------------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

[root@vm-idm-028 ~]# getent group administrator
administrator:*:1577600500:

[root@vm-idm-028 ~]# getent passwd administrator
administrator:*:1577600500:1577600500:Administrator:/home/ipaad2016.test/administrator:

Comment 9 errata-xmlrpc 2018-10-30 10:41:19 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.

https://access.redhat.com/errata/RHSA-2018:3158