[SSSD-users] Re: AD sudo rules have no values for attributes?
> On Apr 5, 2018, at 3:22 PM, Jakub Hrozek wrote: > > > >> On 5 Apr 2018, at 19:56, Max DiOrio 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). Quite simple, adding the value in ADUC says it already exists, but let’s you add it anyway. > >> 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 ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: AD sudo rules have no values for attributes?
> On 5 Apr 2018, at 19:56, Max DiOrio 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
[SSSD-users] Re: AD sudo rules have no values for attributes?
I fixed it. Here’s more from the sssd_domain log. A single line revealed the issue. When storing the DevTest rule it said a value is provided more than once. When I looked at the entry in AD, the attribute sudoUser had the same group entered twice. Once as %GS-Technology, once as %gs-technology. I’m guessing someone was thinking that the group lookup was case sensitive and entered it both ways to rule that out. 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? (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] Thanks! Max ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] AD sudo rules have no values for attributes?
I've got a few dozen servers using SSSD to authenticate and retrieve SUDO rules stored in AD and GPO. Everything works perfectly except for a new RHEL 6.8 server I brought up. sssd version 1.13.3 on both the working 6.8 and non-working 6.8 server. I literally copied the nsswitch, sssd.conf and pam.d configs between the two just to make sure I didn't typo anything. It authenticates fine and I can ssh into it, id account, do genet on the users and groups without a problem. But sudo fails. Looking at debug logs, I see it retrieving the 3 sudo rules we have stored in AD, however it's complaining that there are no sub-attributes in the rules when there clearly are. I'm guessing this is the source of my issues, but I have no idea why it's not working only on this one server. Any thoughts? Thanks! (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=fullaccess,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com]. (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoHost] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_result] (0x2000): Trace: sh[0xd42dc0], connected[1], ops[0xd677a0], ldap[0xd42800] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=DevTest,OU=sudoers,DC=internal,DC=ieeeglobalspec,DC=com]. (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoRunAsUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoCommand] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoUser] (Thu Apr 5 09:45:27 2018) [sssd[be[internal.ieeeglobalspec.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [sudoHost] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=a-mdiorio)(sudoUser=a-mdiorio)(sudoUser=#1002201106)(sudoUser=%Allowed\20RODC\20Password$ Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [@ internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'a-mdiorio' matched without domain, user is a-mdiorio (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [a-mdiorio] from [] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/internal.ieeeglobalspec.com/a-mdiorio] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [a-mdio...@internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [a-mdio...@internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [a-mdiorio] from [internal.ieeeglobalspec.com] (Thu Apr 5 09:45:34 2018) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb wi
