Bug 1298634

Summary:	Cannot retrieve users after upgrade from 1.12 to 1.13
Product:	Red Hat Enterprise Linux 6	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	Pavel Březina <pbrezina>
Status:	CLOSED ERRATA	QA Contact:	Steeve Goveas <sgoveas>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0	CC:	dlavu, grajaiya, jhrozek, lslebodn, mkosek, mupadhye, mzidek, pbrezina, preichl, sgoveas, troels
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.13.3-5.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1299553 (view as bug list)		Environment:
Last Closed:	2016-05-10 20:26:34 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:
Bug Depends On:
Bug Blocks:	1299553

Description Jakub Hrozek 2016-01-14 15:34:22 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2906

In my organization, we're retrieving user/group information from Active Directory using the LDAP provider in SSSD.

(Since I know it's going to come up - we can't use the AD provider for technical + political reasons: my organization doesn't control the AD service we're using, and we don't have privileges to create host principals in the domain, which means we can't use winbind to join the domain; instead we just use simple LDAP queries to retreive user information.  Authentication is done using a separate MIT Kerberos domain (don't ask... also a complicated story).  Also, we used to support RHEL 5, which didn't even have the AD provider.)

After upgrading from SSSD 1.12 to 1.13 on RHEL/CentOS 7, user lookups have stopped working (but group lookups still work).

Following is what I see on test VMs that I've spun up to demonstrate the issue.

`sssd.conf`:

{{{
[sssd]
debug_level = 6
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]

[domain/LDAP]
debug_level = 9
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
sudo_provider = ldap
enumerate = false
cache_credentials = false
ldap_schema = rfc2307bis
ldap_uri = ldaps://ad.myuniversity.edu:636
ldap_search_base = dc=ad,dc=myuniversity,dc=edu
ldap_user_search_base = DC=ad,DC=myuniversity,DC=edu
ldap_user_object_class = user
ldap_user_name = sAMAccountName
override_homedir = 
shell_fallback = /bin/bash
ldap_group_search_base = OU=Unix Groups,OU=OIT - UnixOps,OU=SIS,OU=ITS,OU=Departments Schools and Colleges,DC=ad,DC=myuniversity,DC=edu
ldap_group_object_class = group
ldap_group_name = extensionAttribute15
ldap_id_use_start_tls = true
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_default_bind_dn = CN=oit-sac,ou=service accounts,dc=ad,dc=myuniversity,dc=edu
ldap_default_authtok = redacted
access_provider = ldap
ldap_access_filter = sAMAccountName=configman-test
min_id = 1
max_id = 0
krb5_realm = LOCAL
krb5_server = localhost
schema = rfc2307bis
ldap_user_gecos = displayName
ldap_user_home_directory = unixHomeDirectory
}}}

SSSD 1.13.0 on CentOS 7:

{{{
[vagrant@default-centos-71 ~]$ rpm -q sssd
sssd-1.13.0-40.el7_2.1.x86_64
[vagrant@default-centos-71 ~]$ date; sudo sss_cache -E
Mon Dec 21 18:56:01 UTC 2015
[vagrant@default-centos-71 ~]$ date; getent passwd configman-test
Mon Dec 21 18:56:09 UTC 2015
[vagrant@default-centos-71 ~]$ date; getent group facstaff
Mon Dec 21 19:04:17 UTC 2015
facstaff:*:829:
}}}

(`sssd_LDAP.log` attached)

I found it rather challenging to downgrade from SSSD 1.13 to 1.12 or 1.11 on CentOS 7, and I don't want to go through that effort again in order to obtain debug output, so instead here is a working example using SSSD 1.12 on CentOS 6 with an identical `sssd.conf`:

{{{
[vagrant@default-centos-66 ~]$ rpm -q sssd
sssd-1.12.4-47.el6_7.4.x86_64
[vagrant@default-centos-66 ~]$ date; sudo sss_cache -E
Mon Dec 21 19:02:07 UTC 2015
[vagrant@default-centos-66 ~]$ date; getent passwd configman-test
Mon Dec 21 19:02:16 UTC 2015
configman-test:*:451737:96:Configuration Management:/home/configman-test:/bin/bash
[vagrant@default-centos-66 ~]$ date; getent group facstaff
Mon Dec 21 19:02:59 UTC 2015
facstaff:*:829:
[vagrant@default-centos-66 ~]$ 
}}}

Comment 1 Lukas Slebodnik 2016-01-15 09:06:13 UTC

master:
* 468495d91d536603a1c485424275b6dcf2bb83de 

sssd-1-13:
* f3ee5909b553ca84639a31344616720423e53afe

Comment 2 Jakub Hrozek 2016-01-18 09:41:23 UTC

To reproduce:
- add a client of an AD server using id_provider=ldap
- do *not* disable referral chasing
- id an user

With the unpatched packages, the ID provider would go offline. With the patched packages, the referrals would be ignored as they should be and sssd would return the user entry.

Comment 5 Dan Lavu 2016-03-22 18:47:45 UTC

Verified against sssd-1.13.3-22.el6.x86_64, that the id provider does not go offline after an upgrade. 

root@dhcp207-194 ~]# id testuser001
uid=100055(testuser001) gid=10002(adgrp2) groups=10002(adgrp2),10004(adgrp1)

[root@dhcp207-194 ~]# rpm -qa | grep sssd
python-sssdconfig-1.12.4-47.el6.noarch
sssd-common-1.12.4-47.el6.x86_64
sssd-proxy-1.12.4-47.el6.x86_64
sssd-krb5-common-1.12.4-47.el6.x86_64
sssd-common-pac-1.12.4-47.el6.x86_64
sssd-ad-1.12.4-47.el6.x86_64
sssd-krb5-1.12.4-47.el6.x86_64
sssd-1.12.4-47.el6.x86_64
sssd-client-1.12.4-47.el6.x86_64
sssd-ipa-1.12.4-47.el6.x86_64

[root@dhcp207-194 sssd]# yum update sssd
Loaded plugins: product-id, search-disabled-repos, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package sssd.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd.x86_64 0:1.13.3-22.el6 will be an update
--> Processing Dependency: sssd-common = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-ldap = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-krb5 = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-ipa = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-common-pac = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-ad = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: sssd-proxy = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Processing Dependency: python-sssdconfig = 1.13.3-22.el6 for package: sssd-1.13.3-22.el6.x86_64
--> Running transaction check
---> Package python-sssdconfig.noarch 0:1.12.4-47.el6 will be updated
---> Package python-sssdconfig.noarch 0:1.13.3-22.el6 will be an update
---> Package sssd-ad.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-ad.x86_64 0:1.13.3-22.el6 will be an update
--> Processing Dependency: sssd-krb5-common = 1.13.3-22.el6 for package: sssd-ad-1.13.3-22.el6.x86_64
---> Package sssd-common.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-common.x86_64 0:1.13.3-22.el6 will be an update
--> Processing Dependency: sssd-client(x86-64) = 1.13.3-22.el6 for package: sssd-common-1.13.3-22.el6.x86_64
--> Processing Dependency: libsss_idmap(x86-64) = 1.13.3-22.el6 for package: sssd-common-1.13.3-22.el6.x86_64
--> Processing Dependency: libsss_idmap.so.0(SSS_IDMAP_0.5)(64bit) for package: sssd-common-1.13.3-22.el6.x86_64
---> Package sssd-common-pac.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-common-pac.x86_64 0:1.13.3-22.el6 will be an update
---> Package sssd-ipa.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-ipa.x86_64 0:1.13.3-22.el6 will be an update
--> Processing Dependency: libipa_hbac(x86-64) = 1.13.3-22.el6 for package: sssd-ipa-1.13.3-22.el6.x86_64
---> Package sssd-krb5.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-krb5.x86_64 0:1.13.3-22.el6 will be an update
---> Package sssd-ldap.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-ldap.x86_64 0:1.13.3-22.el6 will be an update
---> Package sssd-proxy.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-proxy.x86_64 0:1.13.3-22.el6 will be an update
--> Running transaction check
---> Package libipa_hbac.x86_64 0:1.12.4-47.el6 will be updated
---> Package libipa_hbac.x86_64 0:1.13.3-22.el6 will be an update
---> Package libsss_idmap.x86_64 0:1.12.4-47.el6 will be updated
---> Package libsss_idmap.x86_64 0:1.13.3-22.el6 will be an update
---> Package sssd-client.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-client.x86_64 0:1.13.3-22.el6 will be an update
---> Package sssd-krb5-common.x86_64 0:1.12.4-47.el6 will be updated
---> Package sssd-krb5-common.x86_64 0:1.13.3-22.el6 will be an update
--> Finished Dependency Resolution

################ SNIP 

Updated:
  sssd.x86_64 0:1.13.3-22.el6

Dependency Updated:
  libipa_hbac.x86_64 0:1.13.3-22.el6  libsss_idmap.x86_64 0:1.13.3-22.el6      python-sssdconfig.noarch 0:1.13.3-22.el6  sssd-ad.x86_64 0:1.13.3-22.el6
  sssd-client.x86_64 0:1.13.3-22.el6  sssd-common.x86_64 0:1.13.3-22.el6       sssd-common-pac.x86_64 0:1.13.3-22.el6    sssd-ipa.x86_64 0:1.13.3-22.el6
  sssd-krb5.x86_64 0:1.13.3-22.el6    sssd-krb5-common.x86_64 0:1.13.3-22.el6  sssd-ldap.x86_64 0:1.13.3-22.el6          sssd-proxy.x86_64 0:1.13.3-22.el6

Complete!


[root@dhcp207-194 sssd]# id testuser001
uid=100055(testuser001) gid=10002(adgrp2) groups=10002(adgrp2),10004(adgrp1)


[root@dhcp207-194 sssd]# rpm -qa | grep sssd
sssd-common-1.13.3-22.el6.x86_64
sssd-ipa-1.13.3-22.el6.x86_64
sssd-1.13.3-22.el6.x86_64
python-sssdconfig-1.13.3-22.el6.noarch
sssd-client-1.13.3-22.el6.x86_64
sssd-krb5-common-1.13.3-22.el6.x86_64
sssd-ad-1.13.3-22.el6.x86_64
sssd-ldap-1.13.3-22.el6.x86_64
sssd-proxy-1.13.3-22.el6.x86_64
sssd-common-pac-1.13.3-22.el6.x86_64
sssd-krb5-1.13.3-22.el6.x86_64

Comment 7 errata-xmlrpc 2016-05-10 20:26:34 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://rhn.redhat.com/errata/RHBA-2016-0782.html