[Freeipa-devel] [PATCH 0081] Skip referrals when converting LDAP result to LDAPEntry

[Tomas Babej]

On Thursday 25 of July 2013 15:53:23 Jakub Hrozek wrote:
> On Thu, Jul 25, 2013 at 03:39:59PM +0200, Tomas Babej wrote:
> > On Thursday 25 of July 2013 09:30:22 Jan Cholasta wrote:
> > > On 25.7.2013 09:11, Petr Spacek wrote:
> > > > On 25.7.2013 09:03, Alexander Bokovoy wrote:
> > > >> On Thu, 25 Jul 2013, Petr Spacek wrote:
> > > >>> On 24.7.2013 22:18, Tomas Babej wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> When converting the result obtained by python-ldap library,
> > > >>>> we need to skip unresolved referral entries, since they cannot
> > > >>>> be converted.
> > > >>>>
> > > >>>> https://fedorahosted.org/freeipa/ticket/3814
> > > >>>
> > > >>> I'm not sure if a simple 'skip it' approach is the right one.
> > > >>> Shouldn't it
> > > >>> print/log a warning at least? Do you know all implications? Are you sure
> > > >>> that this will not break something else silently?
> > > >>>
> > > >>> (BTW isn't the right approach to fix python-ldap? Or is it a quirk in
> > > >>> AD?)
> > > >> AD DC often answers with proper result and then several referrals to
> > > >> other internal resources to complement the search if you are asking for
> > > >> wide-open search (default). We are not interested in these referrals for
> > > >> various reasons, including the fact that we are looking at the
> > > >> authoritative DC and it has all the needed info.
> > > >>
> > > >> At best, we could define an option that forces us doing referral chasing
> > > >> to fetch remaining results but this is not something really needed right
> > > >> now.
> > > >
> > > > I understand that we don't need referrals now, but the question is
> > > > 'Could it break something? Silently? In the future?'.
> > > >
> > > > E.g. the option 'follow referrals' (defaulting to False) is IMHO much
> > > > much better.
> > > >
> > > > The point is that we don't need to implement referral chasing right now,
> > > > just thrown an exception if somebody tries to switch 'follow referrals'
> > > > option to True. IMHO this will prevent surprises in the future, because
> > > > it is absolutely clear that referrals are not followed.
> > > >
> > > 
> > > IMO a comment is good enough. I don't think adding options that aren't 
> > > used anywhere is a good thing to do.
> > > 
> > > Honza
> > > 
> > > -- 
> > > Jan Cholasta
> > 
> > I considered adding an options for that, but decided against it in the end
> > since it would have to bubble down through many layers, while, as Honza says,
> > not being used anywhere.
> > 
> > To make sure that this change does not cause problems, I think we agree to
> > scream at DEBUG level to the log if the referral entry is ignored, and
> > at WARNING level if the referral resolution is turned on in underlying library
> > on the connection level.
> > 
> > Tomas
> 
> For what it's worth, the SSSD ignores referrals completely when talking
> to AD. So disabling or ignoring referrals is the right thing to do here.

After some investigation I decided the correct approach here is to
scream at the debug level only, when referral is being ignored.

We cannot guide ourselves by the ldap.OPT_REFFERALS option of the underlying
connection simply because even if referral chasing is turned on (and therefore
we should not get any referrals from python-ldap, since they should have been
resolved), queries for AD can return referrals (AD returns them often as a way to
provide additional information AFAIU). This can also happen if we are not able
to authenticate to the referred server, or resolve the LDAP uri.

In case ignoring referrals ever breaks something, we can find the information
in the log at the debug level. Doing otherwise would be unnecessarily spamming
the log now.

Updated patch attached.

Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-tbabej-0081-2-Skip-referrals-when-converting-LDAP-result-to-LDAPEn.patch
Type: text/x-patch
Size: 1416 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130726/ff86e039/attachment.bin>