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

[Sumit Bose]

On Thu, Sep 11, 2014 at 05:23:34PM +0200, Ludwig Krispenz wrote:
> 
> 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

SSSD uses the host keytab to do a SASL bind, so the DN should look like:
fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX .

HTH

bye,
Sumit

> >
> >
> >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.
> >
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel