#2967 Intermittent attribute retrieval failure from AD
Closed: wontfix 4 months ago by pbrezina. Opened 4 years ago by rootwyrm.

Discovered on CentOS 6.7 with sssd 1.12.4-47; confirmed as 100% reproducible across 3 systems. ID provider upstream is Active Directory, Win2012R2 running 2012R2 functional.
Issue does not reproduce in sssd 1.13.0-40 or 1.11.7_3 (FreeBSD.)

Symptom:

[root@testboxa pam.d]# getent passwd wyrm
wyrm:*:201112:201115:Phillip R. Jaenke:/:
[root@testboxa pam.d]# sss_cache -E
[root@testboxa pam.d]# getent passwd prj
wyrm:*:201112:201115:Phillip R. Jaenke:/nethome/prj:/bin/sh

[root@testboxa ~]# ldapsearch -H ldap://cthun.dragonnorth.int/ -Y GSSAPI -N -b "dc=dragonnorth,dc=int" "(&(objectClass=user)(sAMAccountName=wyrm))"
... SANITIZED ...
msDS-SupportedEncryptionTypes: 24
uidNumber: 10000
gidNumber: 10000
gecos: Phillip R. Jaenke
unixHomeDirectory: /nethome/wyrm
unixShellLinux: /bin/bash
unixShellAIX: /bin/ksh93
loginShell: /bin/sh

The problem is then triggered when the user logs in.

testboxa login: wyrm
Password:

Last login: Tue Mar  1 08:56:25 on tty2
-sh-4.1$ pwd
/

[root@testboxa pam.d]# getent passwd wyrm
wyrm:*:201112:201115:Phillip R. Jaenke:/:

/etc/sssd/sssd.conf:

[sssd]
domains = dragonnorth.int
config_file_version = 2
services = nss, pam

[nss]

[pam]

[domain/dragonnorth.int]
        debug_level = 9

        dyndns_update = true
        dyndns_iface = eth0

        id_provider = ad
        auth_provider = ad
        access_provider = ad
        chpass_provider = ad

        krb5_realm = DRAGONNORTH.INT
        krb5_renewable_lifetime = 7d
        krb5_renew_interval = 4h

        ldap_sasl_mech = GSSAPI
        ldap_sasl_authid = TESTBOXA$@DRAGONNORTH.INT
        ldap_schema = ad

        ldap_id_mapping = true
        ldap_idmap_autorid_compat = true
        ad_enable_gc = true
        enumerate = true

Truncated level 9 debug log of getent failure attached. This appears to be isolated to CentOS 6.7, sssd 1.12.4-47. I cannot reproduce on any other system using an identical configuration.


truncated level 9 log of getent when exhibiting described failure mode
sssd_1.12.4_getent_failure.log

Debug Logs, nss level=10 / domain level=10
sssd_2967_log0.tar.gz

Since RHEL-6 will rebase to 1.13, I wonder if running 1.13 would be an option for you? We have a test repo with 1.13 packages already. I mean, no downstream will be shipping 1.12 soon, so I'm not sure how much time we should put into triaging this ticket..

Replying to [comment:1 jhrozek]:

Since RHEL-6 will rebase to 1.13, I wonder if running 1.13 would be an option for you? We have a test repo with 1.13 packages already. I mean, no downstream will be shipping 1.12 soon, so I'm not sure how much time we should put into triaging this ticket..

I definitely agree this isn't a code fix issue unless there's an actual bug causing inconsistent behavior as opposed to a consistent limitation.

Unfortunately, successfully reproduced using the test repository. Still can't get reproduction with 1.13.0-40 on CentOS 7.2. Logs attached as sssd_2967_log1.tar.gz

[root@testboxa sssdlog]# rpm -qa |grep sssd
sssd-client-1.13.3-15.el6.unsupported_preview.x86_64
sssd-krb5-common-1.13.3-15.el6.unsupported_preview.x86_64
sssd-ad-1.13.3-15.el6.unsupported_preview.x86_64
sssd-krb5-1.13.3-15.el6.unsupported_preview.x86_64
sssd-1.13.3-15.el6.unsupported_preview.x86_64
python-sssdconfig-1.13.3-15.el6.unsupported_preview.noarch
sssd-common-1.13.3-15.el6.unsupported_preview.x86_64
sssd-common-pac-1.13.3-15.el6.unsupported_preview.x86_64
sssd-ipa-1.13.3-15.el6.unsupported_preview.x86_64
sssd-ldap-1.13.3-15.el6.unsupported_preview.x86_64
sssd-proxy-1.13.3-15.el6.unsupported_preview.x86_64
sssd-tools-1.13.3-15.el6.unsupported_preview.x86_64

Need to update ticket to reflect this is now confirmed to happen in 1.13.4 as well. So it is happening in all versions tested to date, but only on CentOS 6.7 so far.

Latest logs from 1.13 test using
https://copr.fedorainfracloud.org/coprs/lslebodn/latest-1.13/ as requested by @lslebodn (also emailed cache ldb privately.) Logs attached as sssd_logs_lslebodn-1.13_03082016.tar.gz

Did not even successfully login before seeing failure in 'getent passwd wyrm':

[root@testboxa sssd]# service sssd start
Starting sssd:                                             [  OK  ]
[root@testboxa sssd]# sss_cache -E
[root@testboxa sssd]# sss_cache -E
[root@testboxa sssd]# sss_cache -E
[root@testboxa sssd]# getent passwd wyrm
wyrm:*:201112:201115:Phillip R. Jaenke:/:

Packages:

[root@testboxa db]# rpm -qa | grep sss
sssd-client-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
sssd-common-pac-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
sssd-ad-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
libsss_idmap-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
sssd-common-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
sssd-krb5-common-1.13.4-0.20160308.1737.git5db9995.el6.x86_64
[root@testboxa db]# rpm -qa | grep samba
samba4-libs-4.0.0-67.el6_7.rc4.x86_64
samba4-common-4.0.0-67.el6_7.rc4.x86_64
samba4-client-4.0.0-67.el6_7.rc4.x86_64

Lukas agreed to own this ticket.

owner: somebody => lslebodn

Lukas asked to put the ticket into the 1.14 backlog bucket on the Mar-17 triage.

milestone: NEEDS_TRIAGE => SSSD 1.14 backlog

Fields changed

rhbz: => todo

Fields changed

selected: => May

Since 1.14 is in maintenance mode and the backlog bucket is not being looked at really, I'm moving the ticket into future releases now..although I suspect patches welcome might fit even better.

Lukas, what do you think? Feel free to move the patch yourself..

milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)

Metadata Update from @rootwyrm:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD Future releases (no date set yet)

3 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 months ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 months ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4008

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata