Hi again, 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 } Thanks a lot for your help. Regards! 2015-07-07 15:10 GMT+02:00 Hatim CHIKHI <hatim.networking@gmail.com>:
Hi again,
I found the solution for the 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 }
Thanks a lot for your help.
Regards!
2015-07-06 17:26 GMT+02:00 Danner, Mearl [via FreeRADIUS] < ml-node+s1045715n5735140h71@n5.nabble.com>:
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users- bounces+jmdanner=[hidden email] <http:///user/SendEmail.jtp?type=node&node=5735140&i=0>] On Behalf Of Hatim CHIKHI Sent: Monday, July 06, 2015 10:10 AM To: FreeRadius users mailing list Subject: Re: LDAP search failed
myserver:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in dc=3Dad,dc=3D****,dc=3Dfr, with filter sAMAccountName=3Dhatim [ldap] rebind to URL ldap://***** [ldap] rebind to URL ldap://***** [ldap] rebind to URL ldap://***** [ldap] no uid attribute - access denied by default
Active Directory has no uid by default. The schema needs to be extended to provide it. And most provisioning software does not populate it even if it exists.
So this was the problem, I changed the value uid and set "sAMAccountName" and now it works. Thank you guys for you help.
I have an other question, the ldap search is taking too much time, more than 10 seconds. I don't know if there is a way to speed up the search??
Probably a back end problem, not Freeradius.
Do you get the same lag using a command line ldap search?
Could be chasing referrals. Try the GC port 3268 (3269 for ssl). Not all attributes are available in the Global Catalog unless specified in the schema. They can be exposed by one of your AD admins if needed.
Also make sure all the attributes in your search strings are indexed. If they aren't search returns can be slow in a large directory.
Thanks!
2015-07-06 16:10 GMT+02:00 Hatim CHIKHI <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5735140&i=1>>:
myserver:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in dc=3Dad,dc=3D****,dc=3Dfr, with
filter
sAMAccountName=3Dhatim [ldap] rebind to URL ldap://***** [ldap] rebind to URL ldap://***** [ldap] rebind to URL ldap://***** [ldap] no uid attribute - access denied by default
Active Directory has no uid by default. The schema needs to be extended to provide it. And most provisioning software does not populate it even if it exists.
So this was the problem, I changed the value uid and set "sAMAccountName" and now it works. Thank you guys for you help.
I have an other question, the ldap search is taking too much time, more than 10 seconds. I don't know if there is a way to speed up the search??
Thanks!
2015-07-03 18:05 GMT+02:00 Hatim CHIKHI <[hidden email] <http:///user/SendEmail.jtp?type=node&node=5735140&i=2>>:
When FreeRADIUS does the search for the user, it gets nothing.
Perhaps because the search string is broken?
But I get a result when I issue the search with ldapsearch
That doesn't look right. Where does that string come from? The 3D is added by gmail so it's not a problem
2015-07-03 15:25 GMT+02:00 Alan DeKok-2 [via FreeRADIUS] < [hidden email]
<http:///user/SendEmail.jtp?type=node&node=5735140&i=3>>:
On Jul 3, 2015, at 7:01 AM, Hatim CHIKHI <[hidden email] <http:///user/SendEmail.jtp?type=node&node=5735114&i=0>> wrote: > When I issue an ldap search I get many information about the user
I'm
> looking for but I'm not sure if the search is successful:
When FreeRADIUS does the search for the user, it gets nothing.
Perhaps because the search string is broken?
> In the radius logs, this time I'm getting this error: > > [ldap] performing user authorization for hatim > [ldap] expand: sAMAccountName=3D%{User-Name} -> sAMAccountName=3Dhatim > [ldap] expand: dc=3Dad,dc=3D****,dc=3Dfr -> dc=3Dad,dc=3D****,dc=3Dfr
That doesn't look right. Where does that string come from?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://freeradius.1045715.n5.nabble.com/LDAP-search-failed- tp5735079p5735114.html To unsubscribe from FreeRADIUS, click here
<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro =unsubscribe_by_code&node=2740692&code=aGF0aW0ubmV0d29ya2luZ0B nbWFpbC5jb218Mjc0MDY5MnwxNzU1NTY4NDU2>
. NAML
<http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro =macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.n aml.namespaces.BasicNamespace- nabble.view.web.template.NabbleNamespace- nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscrib ers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml- send_instant_email%21nabble%3Aemail.naml>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://freeradius.1045715.n5.nabble.com/LDAP-search-failed-tp5735079p5735140... To unsubscribe from FreeRADIUS, click here <http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2740692&code=aGF0aW0ubmV0d29ya2luZ0BnbWFpbC5jb218Mjc0MDY5MnwxNzU1NTY4NDU2> . NAML <http://freeradius.1045715.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
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. Ciao, Michael.
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.
Ciao, Michael.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html 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. take the below example:
sub.acme.corp -> acme.corp <-> brandx.corp <- sub.brandx.corp since my ID is in sub.acme.corp, i need to chase referrals (or walk the tree, as it has been called) to get kerberos tickets for services hosted in sub.brandx.corp (HTTP, etc). while this is not an everyday, run-of-the-mill configuration, it is found in the wild.
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. 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.
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. Probably an enum of - anonymous - url - config ? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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
participants (4)
-
Arran Cudbard-Bell -
Brendan Kearney -
Hatim CHIKHI -
Michael Ströder