> On 5 Apr 2018, at 19:56, Max DiOrio <mdio...@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] _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
