Bug 1263735 - Could not resolve AD user from root domain
Could not resolve AD user from root domain
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
: Regression
Depends On:
  Show dependency treegraph
Reported: 2015-09-16 10:42 EDT by Jakub Hrozek
Modified: 2015-11-19 06:40 EST (History)
11 users (show)

See Also:
Fixed In Version: sssd-1.13.0-32.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-19 06:40:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-2015:2355 normal SHIPPED_LIVE Low: sssd security, bug fix, and enhancement update 2015-11-19 05:27:42 EST

  None (edit)
Description Jakub Hrozek 2015-09-16 10:42:20 EDT
This bug is created as a clone of upstream ticket:

There are more administrator users: id ''administrator @child1.sssdad.com'' and id ''administrator @sssdad.com''.

sssd is joined to the child domain.
config_file_version = 2
services = nss, pam
domains = child1.sssdad.com

default_shell = /bin/bash

debug_level = 0xFFF0
id_provider = ad
ad_domain = child1.sssdad.com
cache_credentials = True
krb5_store_password_if_offline = True
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u

but user from root domain ''administrator @sssdad.com'' cannot be resolved.
It might be cause by fact that user is stored in different domain
[root@ibm-x3650-03 sssd]# ldbsearch -H /var/lib/sss/db/cache_child1.sssdad.com.ldb "(name=Administrator)"
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la : /usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
asq: Unable to register control with rootdse!
# record 1
dn: name=Administrator,cn=users,cn=child1.sssdad.com,cn=sysdb
createTimestamp: 1437407347
fullName: Administrator
gecos: Administrator
gidNumber: 369600513
name: Administrator
objectClass: user
uidNumber: 369600500
objectSIDString: S-1-5-21-4212360905-986714573-1256250948-500
uniqueID: 16c36a5f-e2ec-49cd-a2ab-742b03d3adde
originalDN: CN=Administrator,CN=Users,DC=child1,DC=sssdad,DC=com
originalMemberOf: CN=Group Policy Creator Owners,CN=Users,DC=child1,DC=sssdad,
originalMemberOf: CN=Domain Admins,CN=Users,DC=child1,DC=sssdad,DC=com
originalMemberOf: CN=Administrators,CN=Builtin,DC=child1,DC=sssdad,DC=com
originalModifyTimestamp: 20150718152922.0Z
entryUSN: 768294
adUserAccountControl: 66048
nameAlias: administrator
lastUpdate: 1437407347
dataExpireTimestamp: 1437412747
distinguishedName: name=Administrator,cn=users,cn=child1.sssdad.com,cn=sysdb

# returned 1 records
# 1 entries
# 0 referrals
Comment 2 Jakub Hrozek 2015-09-22 07:49:41 EDT
Comment 4 Amith 2015-10-13 11:49:03 EDT
Verified the bug on SSSD Version: sssd-1.13.0-39.el7.x86_64

Steps followed during verification:

1. Add sssd client to child AD domain, lets say child.sssdad.com with parent as sssdad.com

2. Run getent on both the administrators, ie root domain and child domain.

3. With the latest build, root domain administrator should be resolved.

# getent passwd -s sss administrator@sssdad.com

# getent passwd -s sss administrator@child1.sssdad.com
Comment 5 errata-xmlrpc 2015-11-19 06:40:36 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.


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