LDAP search failed

[Arran Cudbard-Bell]

> On 7 Jul 2015, at 12:10, Michael Ströder <michael at stroeder.com> wrote:
> 
> 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.

Yes, I agree it is a security issue. The current behaviour was inherited from rlm_ldap v1.

> 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.

There should be a knob to determine the source of the credentials used when chasing referrals.

Probably an enum of

- anonymous
- url
- config

?


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150707/9c85ba3d/attachment.sig>