[Freeipa-users] SSSD does not fetch Sudo Rules anymore

Zoske, Fabian f.zoske at euroimmun.de
Mon Mar 7 08:37:30 UTC 2016


Thank you for your explanation.

I looked in the sssd_<DOMAIN>.log and found the actual LDAP-Filter.
The problem seems to be the first part again: (&(objectclass=sudoRole)(entryUSN>=485025)(!(entryUSN=485025))).
In the LDAP-Tree I can't see any attribute named entryUSN.

Is this related to the problem?

Best regards,
Fabian

-----Ursprüngliche Nachricht-----
Von: Alexander Bokovoy [mailto:abokovoy at redhat.com] 
Gesendet: Montag, 7. März 2016 09:07
An: Zoske, Fabian
Cc: freeipa-users at redhat.com
Betreff: Re: [Freeipa-users] SSSD does not fetch Sudo Rules anymore

On Mon, 07 Mar 2016, Zoske, Fabian wrote:
>Hi,
>
>in our environment server (ipa-server-4.2.0-15.el7_2.6.x86_64 and
>sssd-1.13.0-40.el7_2.1.x86_64  on CentOS 7.2) and client
>(ipa-client-4.2.0-15.el7_2.6.x86_64 and sssd-1.13.0-40.el7_2.1.x86_64 
>on CentOS 7.2) SUDO rules doesn’t get fetched anymore.
>
>I debugged SSSD and SUDO and found out, that the first LDAP filter is
>(objectClass=sudoRule) and in our IPA-LDAP every rule has the class 
>“sudoRole” not “sudoRule”.
This has nothing to do with your problem. sudoRole is a known artefact from SUDO LDAP support -- the schema SUDO uses to store data in LDAP has this object class. SSSD searches in its own cache first and in that cache it uses an object class named sudoRule.

These are searches against different databases and they are perfectly fine.

>Is there a way to fix this behavior?
You need to find out what exactly is failing in your case, the 'difference' above is not a problem.

See https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

--
/ Alexander Bokovoy




More information about the Freeipa-users mailing list