[Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't

[Ludwig Krispenz]

On 09/11/2014 05:03 PM, Martin Kosek wrote:
> Hello,
>
> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings
> cause older SSSD clients to fail as they get returned an LDAP deref call
> results without objectclass attribute and just with entryusn attribute. Details
> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be
> more tolerant in this case, it still breaks old clients which we should prevent.
>
> There are 2 ways how to fix I currently see:
>
> 1) Return objectclass for any entry, just like we do with operational attributes
>
> This would include adding "objectclass" to "System: Read Timestamp and USN
> Operational Attributes". However, I am rather cautious about this approach as
> even though objectclass does not usually carry a secret information, we could
> still leak some information about our DIT to unprivileged user.
yes, there is no need to open access up to anyone, it could be 
restricted to authenticated.

Do the users sssd uses to authenticate have a common dn pattern or are 
in a specific group ? You could open access only for them, or combine 
access with a targetfilter (objectclass=groupofnames) to further 
restrict access
>
>
> 2) Show objectclass+operational attributes in our Read ACIs
> Other way I see is to update *all* our Read permissions allowing reading
> objectclass attribute and also allow the chosen LDAP operational attribute.
> This would let the LDAP caller to always get either all these discussed
> attributes but none at all.
>
>
> Do we want to do this? Any other (better) idea how to approach it?
>
> Thank you.
>