Created attachment 1263350 [details] AD numeric group sid Description of problem: When doing group lookup for user group SID number is displayed instead of Group name. We noticed this in the UI and in dbus-send, then it eventually works. We duplicated this on multiple appliances(which are gone) Must be a race condition, Alberto debugged with me and witnessed it. But it fixed itself without any changes. Capturing this for future reference. Version-Release number of selected component (if applicable): 5.6.3.3, 5.7.1.2 How reproducible: Steps to Reproduce: 1. Configure external auth for AD. 2. See Groups are numeric sid, not name 3. Actual results: Expected results: Additional info:
Verified still an issue in 5.7.2.0
Created attachment 1267308 [details] Sid's displayed in 5.7.2.0
Because this issue is not reproducible by engineering and dbus-send produces the same failure it is likely an SSSD issue. A quick search of Bugzilla produces some possible causes, including this one: https://bugzilla.redhat.com/show_bug.cgi?id=1072995 and this Fedora upstream issue: https://pagure.io/SSSD/sssd/issue/2274 The best way to proceed would be to enable debug logging for SSSD, by adding: "debug_level = 9" to each section of the sssd.conf file on a machine where this issue is observed. If this is an SSSD timing related issue the SSSD cache would need to be cleared between SSSD restarts. I full sssd restart "flush" can be achieved with the following commands: systemctl stop sssd sss_cache -E rm -f /var/lib/sss/db/* rm -f /var/log/sssd/sssd*.log systemctl restart sssd Please provide sssd logs on a system where this is observed.
[root@dhcp-8-197-223 sssd]# dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:test-user1 method return sender=:1.375 -> dest=:1.378 reply_serial=2 array [ string "s-1-5-21-2347313050-3178207562-1725954654-513.bos.redhat.com" string "s-1-5-21-2347313050-3178207562-1725954654-1140.bos.redhat.com" string "s-1-5-21-2347313050-3178207562-1725954654-1157.bos.redhat.com" string "s-1-5-21-2347313050-3178207562-1725954654-1176.bos.redhat.com" ] Just happened on Version: 5.8.0.12-rc1
Seems like we are hitting an SSSD issue
Yes, this might be an SSSD issue. At some point group might be written to the cache of SSSD with the SID as name. But at the same time the object should be marked as expired to make sure the right name is looked up before sending a result to the client. Please save the cache file /var/lib/sss/db/cache_* when you see the output with the SIDs and attach it to this ticket for further inspection. HTH bye, Sumit
(In reply to Sumit Bose from comment #18) > Yes, this might be an SSSD issue. At some point group might be written to > the cache of SSSD with the SID as name. But at the same time the object > should be marked as expired to make sure the right name is looked up before > sending a result to the client. > > Please save the cache file /var/lib/sss/db/cache_* when you see the output > with the SIDs and attach it to this ticket for further inspection. > > HTH > > bye, > Sumit btw I can reproduce this locally. Joe, since this is an SSSD issue, is it OK to move this bugzilla to the sssd component or should we file a new one against sssd and make this one blocked by the sssd one?
Sumit and Jakub, Thank you for the help! JoeV
There is an upstream ticket now: https://pagure.io/SSSD/sssd/issue/3392 and proposed patches: https://github.com/SSSD/sssd/compare/master...jhrozek:ifp_groupnames If you can let me know what sssd version you are running (rpm -q sssd-common) then I can build you a test package.
btw this is also tracked in bugzilla with https://bugzilla.redhat.com/show_bug.cgi?id=1449729
sssd-common-1.14.0-43.el7_3.14.x86_64
(In reply to Matt Pusateri from comment #25) > sssd-common-1.14.0-43.el7_3.14.x86_64 (Sorry for the late reply) This is the 7.3 baseline. Since the underlying code changed quite a bit in 7.4, the patches don't apply. But since the CFME-related enhancements were coded up on the 7.4 baseline, I would like to ask for testing using the following 7.4 test build instead of spending time on backporting the patches: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13225562
(In reply to Jakub Hrozek from comment #26) > (In reply to Matt Pusateri from comment #25) > > sssd-common-1.14.0-43.el7_3.14.x86_64 > > (Sorry for the late reply) > > This is the 7.3 baseline. Since the underlying code changed quite a bit in > 7.4, the patches don't apply. But since the CFME-related enhancements were > coded up on the 7.4 baseline, I would like to ask for testing using the > following 7.4 test build instead of spending time on backporting the patches: > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13225562 Matt, Can you please confirm this test build so we can close this BZ out if it works? Thank you, JoeV
Confirmed it resolves the issue.
(In reply to Matt Pusateri from comment #28) > Confirmed it resolves the issue. Can this be move to "Verified" then?
How are we going to track that it actually makes it into the appliance? I realize you don't want this in your queue. But for me it's not verified until it's actually in a build. I've verified the upstream bug.
attaching another affected customer - we also identified a sssd bug - sssd 1.15 seems like it would resolve it. It's in the beta channel only however right now. bz#1449729 seems to cover the sssd issue
Verified on 5.9.0.2 - External Auth - AD