LDAP search failed

[Michael Ströder]

Brendan Kearney wrote:
> On 07/07/2015 10:03 AM, Michael Ströder wrote:
>> Hatim CHIKHI wrote:
>>> I found the solution for the ldap slow search here:
>>> http://lists.freeradius.org/pipermail/freeradius-users/2013-January/064566.html
>>>
>>>
>>> There is just an option in the ldap configuration of freeradius that must
>>> be modified:
>>>
>>> ldap {
>>>     ...
>>>     chase_referrals = no
>>> }
>> I'd vote for this to be the default. Automagically chasing referrals is
>> useless in almost any case, especially because it's a broken concept. At least
>> I never had a LDAP deployment where this was safe to use - during the last 15+
>> years.
>
> in larger envirionments, where multiple domains are in play, referrals would
> need to be chased.  I work in such an environment with AD.  the parent domain
> to the domain my ID is in, has a two-way forest level trust with the parent
> domain of a partner domain.

I know this very well. But what to do in this case is proprietary MS stuff.

The problem is that nothing in LDAPv3 standard documents says that client-side
referral chasing should re-use the same bind identity possibly with same
client credentials when chasing a referral. In case of simple bind or
SASL/PLAIN it's even considered a security issue.

So it's up to the client developers to let the admin define a referral policy
regarding bind (or interactively ask the user in UI clients).

=> as you can see in so many discussions on mailing lists, forums etc.
client-side referral chasing causes many more issues than it solves.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150707/c5219730/attachment-0001.bin>