Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2089

• Created at 2013-09-13 11:37:45 by tothandor
• Closed as Invalid
• Assigned to nobody

It's really hard to notice this typo, and it's really vexing.

Comments

Comment from tothandor at 2013-09-13 11:46:28

I cannot even override the bad (sudoRule) value (CentOS 6 sssd-1.9.2-82.el6.x86_64).

Comment from jhrozek at 2013-09-19 12:19:09

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?

Comment from jhrozek at 2013-09-26 01:30:18

No response for a week, closing. Please reopen if you see a bug.

resolution: => invalid
status: new => closed

Comment from tothandor at 2013-09-27 18:13:00

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

Comment from jhrozek at 2013-09-27 20:51:44

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?

Comment from jhrozek at 2013-10-03 12:37:09

Closing due to inactivity again.

resolution: => worksforme
status: reopened => closed

Comment from tothandor at 2017-02-24 14:41:45

Metadata Update from @tothandor:

• Issue set to the milestone: NEEDS_TRIAGE