Hi,

I have to define "Auth-Type ldap" in authenticate section.

..well, yes.... however the initial part of your original post highlights a simply problem to solve... alan

My colleague meet some hard problems with FR 2.X, I am not clear about details. When I take over the job, I began it with the latest release. For security, the LDAP should not return attribute userPassword to freeradius. Thanks for your advice. 2014-02-26 16:51 GMT+08:00 <A.L.M.Buxey@lboro.ac.uk>:

Hi,

...

Is there a simple doc about configure ldap authenticate with freeraidus-3.0.1 ? I am confused about it.

any particular reason you are using the latest/feature release of FreeRADIUS? You will face issues like any pioneer on that platform.

if what you've done hasnt solved the issue then its likely to be another bug/issue with the new code - so long as you havent made ANY other changes to your config this should be easily reproducable. (you ARE feeding back the required attributes from LDAP as required too?)

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Quoth A.L.M.Buxey@lboro.ac.uk (26 Feb 2014, 10:41):

For security, the LDAP should not return attribute userPassword to

...

freeradius.

if the server doesnt get a password - if using LDAP as your source, then how is it supposed to authenticate the user?

LDAP authentication can be done either by performing an authenticated bind to the LDAP server - determine/lookup the relevant DN - supply the relevant credentials or by searching for the relevant LDAP object obtaining the relevant "password" attribute, and checking it. I would agree the former approach makes more sense. Directory services should not disclose user credentials (cf. shadow password files).

Is it not the FR send username & password to LDAP, then LDAP return success/fail back to FR ? If I have misunderstanding on common sense, forgive me. 2014-02-26 17:41 GMT+08:00 <A.L.M.Buxey@lboro.ac.uk>:

Hi,

...

For security, the LDAP should not return attribute userPassword to freeradius.

if the server doesnt get a password - if using LDAP as your source, then how is it supposed to authenticate the user?

alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On 26 Feb 2014, at 09:33, zz d <zzd7zzd@gmail.com> wrote:

My colleague meet some hard problems with FR 2.X, I am not clear about details. When I take over the job, I began it with the latest release.

Which is the correct approach to take.

For security, the LDAP should not return attribute userPassword to freeradius.

That's fine.

any particular reason you are using the latest/feature release of FreeRADIUS? You will face issues like any pioneer on that platform.

Please don't dissuade people from using (and therefore testing) the new code. For new deployments the v3.0.x branch should be used. v2.0.x is bug fix only. The only features which will be backported are to aid in supporting the code base. The only branch which should not be used (for now) is master, and even that is pretty stable. It hasn't diverged excessively from v3.0.x.

if what you've done hasnt solved the issue then its likely to be another bug/issue with the new code

It is *NOT* a bug in the new code. This question has been asked *SEVERAL* times on the list, and stack overflow.

Unknown value 'ldap' for attribute 'Auth-Type'

The values for Auth-Type are determined by the Auth-Type {} sections. If you have unknown value 'ldap', it means you are missing an Auth-Type ldap section. add authenticate { Auth-Type ldap { ldap } } Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

A.L.M.Buxey@lboro.ac.uk wrote:

if thats the view then the wording on freeradius.org needs to change - anyone who reads 'stable' and has eg ITIL framework etc will go for that release (2.2.x) and not the 'latest/feature' release.

We will continue to support v2.2.x for a few years. It's OK for people to use it.

..as I said..if he's done all that he's been told to do then its likely to be a bug/issue - in this case he hadnt done all he'd been told/instructed to do ;-)

People should avoid "Auth-Type = ldap". The ONLY reason to use it is for Active Directory, when the request has User-Password. For all other LDAP directories, FreeRADIUS should just grab the password from LDAP, and do the authentication itself.

I'd submitted a config change via github to make all this much easier for admins to see - which appears to have been rejected. which is a pity - as if you are now changing how the server/module works and dont put the relevant parts that people need into place then it becomes harder for the server to be configured correctly for purpose (and lets face it, for a lot of people this server is hard to configure anyway) - especially relating to this LDAP change in behaviour - other modules/configs have the required unlang present next to them to uncomment/use...just a few lines of code to stop many many similar queries about 3.x and LDAP ? think of the users.

The default configuration should work for nearly all LDAP servers. For Active Directory, they should probably be using ntlm_auth, which is also documented. Alan DeKok.

stefan.paetow@diamond.ac.uk wrote:

However, it should be properly documented for those who do not wish for FR to have the password, and rather use the bind method instead.

I recommend *not* doing that. If you don't trust FreeRADIUS with the password, you don't understand how RADIUS works.

I'm with Alan B. on this. If the LDAP bind method is clearly documented (even if it's just a "if you don't want FR to have the password and want to use bind, see this URL for more info" comment in the authorize and authenticate sections), then chances are that there will be less requests on the mailing list for help with how to authenticate against LDAP (except for those who don't bother reading the configuration files or the Wiki for that matter).

We can always hope that people read the configuration files they're editing. Alan DeKok.