On (14/01/16 12:42), Stephen Gallagher wrote: >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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
