On 01/14/2016 05:19 AM, Pavel Březina wrote:
> On 01/13/2016 03:45 PM, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 01/13/2016 07:25 AM, Pavel Březina wrote:
>>>
https://fedorahosted.org/sssd/ticket/2906
>>>
>>> Hi, I'm CCing Stephen as he is original author of the code.
>>>
>>> Without this patch I am not able to work with AD when
>>> ldap_referrals=true, with this patch it works. I'm not sure
>>> though if it is a correct fix or if we can find a better one.
>>>
>>> As the removed comment says the referrals should be processed
>>> by openldap so why aren't they?
>>
>> So, I never actually tested that particular code-path, I think.
>> Looking at the code now, I think I see the mistake.
>>
>> There are two cases where the openldap lookup can return
>> referrals. One is the case where the result code of the lookup is
>> LDAP_REFERRAL. That is the situation where the LDAP server has
>> responded that ALL results must come from somewhere else
>> (equivalent to HTTPs 304 code). However, there's also the case
>> where we get LDAP_SUCCESS which also has some referrals that may
>> contain *additional* results. This is the codepath that you're
>> hitting with this bug.
>>
>> Now, I have no idea why the openldap libraries actually return
>> the referral information on this codepath, since in theory it is
>> just supposed to follow it magically under the hood, but I have
>> some suspicions.
>>
>> Among many other abominations, AD's returned referral URIs are
>> often unfollowable. Instead of returning referrals to specific
>> systems, they return referrals whose hostname is simply the
>> domain in question. (Which means that the client is randomly sent
>> to one of the domain controllers that serve that domain).
>> However, Windows machines do some sort of magic under the hood in
>> order to have the TLS certificates actually work in that case. So
>> my guess here is that when openldap discovers it cannot
>> *actually* process the referral, rather than failing it just
>> returns it as extra information so the application can attempt to
>> solve it on its own.
>>
>> I should also note that OpenLDAP upstream discourages the use of
>> the internal referral chasing as it rarely works properly.
>>
>> In conclusion: go ahead and remove that section of code
>> entirely. While you're there, could you fix a minor memory bug as
>> well? I forgot to talloc_free(refs) on the success case. It's not
>> a major issue since it's allocated on a request that almost
>> certainly gets freed soon after this function returns, but since
>> the memory is no longer used after this (we don't return it),
>> it's a good convention to clear it here
>
> Patch is attached.
>
>
Ack and good catch!
master:
* 468495d91d536603a1c485424275b6dcf2bb83de
sssd-1-13:
* f3ee5909b553ca84639a31344616720423e53afe
LS