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

[Simo Sorce]

On Thu, 2014-09-11 at 18:19 +0200, Sumit Bose wrote:
> 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 .

Other leagcy claints may be using accounts in sysaccounts or other
locations, this fix should not be about SSSD alone imo.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York