On 7 Jul 2015, at 18:13, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 7 Jul 2015, at 12:10, Michael Ströder <michael@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.h...
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.
Added use_referral_credentials as an option in v3.1.x. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2