Learn more about these different git repos.
Other Git URLs
It's really hard to notice this typo, and it's really vexing.
I cannot even override the bad (sudoRule) value (CentOS 6 sssd-1.9.2-82.el6.x86_64).
I don't think this is a bug. We only use sudoRule objectclass in the cache. Rules from the server are correctly downloaded using the sudoRole objectclass.
What bad behaviour are you seeing?
No response for a week, closing. Please reopen if you see a bug.
resolution: => invalid status: new => closed
I was busy. Sorry for not reacting.
On CentOS 6.4, if I don't set "ldap_sudorule_object_class = sudoRole" in /etc/sssd/sssd.conf, then sudoers could not be checked in LDAP (nsswitch.conf: sudoers: files sss). Up until recent upgrade, that was not needed.
Also debugging the request reveals, that sssd asks for objectClass=sudoRule.
"man 5 sudoers.ldap" says the object class's name is sudoRole: "objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME ’sudoRole’ SUP top STRUCTURAL"
Bests, Andor
resolution: invalid => status: closed => reopened
Hi Andor,
As is said earlier, we use sudoRole (as specified by sudo upstream) for LDAP searches and sudoRule (SSSD custom attribute) for cache searches. Are you seeing wrong searches hitting the server?
Can you set debug_level=6 (or higher) in [sudo] and [domain] sections of the SSSD, restart the SSSD and attach the logs?
Closing due to inactivity again.
resolution: => worksforme status: reopened => closed
Metadata Update from @tothandor: - Issue set to the milestone: NEEDS_TRIAGE
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/3131
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.