Learn more about these different git repos.
Other Git URLs
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]:
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
attachment sssd_2967_log1.tar.gz
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
attachment sssd_logs_lslebodn-1.13_03082016.tar.gz
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
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)
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
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.