On 5 Apr 2018, at 19:56, Max DiOrio <mdiorio(a)gmail.com> wrote:
I’m guessing someone was thinking that the group lookup was case sensitive and entered it
both ways to rule that out.
I wonder if you know how did they manage to put the duplicate entries into AD? I tried
with ADSI edit and got an error about a duplicate attribute value. I suspect this might be
a bug in SSSD. If the domain is known to be case-insensitive, like AD and if the values
differ by case only, then the values can be just lowercased and sssd should write only the
single lowercase value (and then sssd-sudo knows to look up the rules in a
case-insensitive manner).
Ends up breaking the storing of the rules and it seems if one rule
fails to be stored, they all are. Not necessarily the best thing to do maybe?
In the typical case I would agree, but sudo also supports exclusion (“!command", run
any command except the specified one) which I think is quite a misfeature and then failing
to save a rule might cause to fail to save the exclusion..
I don’t know if anyone actually uses the exclusion, because, realistically, with LDAP it
would have to be used together with sudoOrder to make sure you get the right ordering of
rules. Maybe we could fix/extend SSSD so that if no sudoCommand contains the exclamation,
then we can be permissive in saving the rules. Would you mind opening an upstream ticket
for that? I’m not sure if it’s something any of the core developers would jump to fixing,
but it sounds to me like a nice task for someone looking to contribute to sssd :-)
(Thu Apr 5 13:30:44 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sysdb_store_custom]
(0x0020): Failed to store custom entry: Attribute or value exists(20)[attribute
'sudoUser': value #5 on
'name=DevTest,cn=sudorules,cn=custom,cn=internal.ieeeglobalspec.com,cn=sysdb'
provided more than once]