Default radiusd.conf and Auth-Type LDAP comment
Hi, This is just a comment on the default radiusd.conf provided information. In the authenticate section of the default radiusd.conf I can read about "Auth-Type LDAP": <quote> # Note that this means "check plain-text password against # the ldap database", which means that EAP won't work, # as it does not supply a plain-text password. </quote> While usually true, this assumption is a little confusing sometimes. Indeed, when EAP-TTLS uses PAP (not an EAP protocol I know) as its inside authentication protocol, a cleartext password is provided to Freeradius which is then able to use a simple ldap bind exchange to authenticate the user. Could we replace with something like that <quote> # Note that this means "check plain-text password against # the ldap database", which means that most EAP types won't work # as they do not supply a plain-text password (unless you use a # composite EAP scheme with and inner cleartext-enabled protocol # such as EAP-TTLS/PAP) </quote> But this is a little tricky... Or more simply: <quote> # Note that this means "check plain-text password against # the ldap database", which means that most EAP types won't work # as they do not supply a plain-text password # (an exception beeing EAP-TTLS with inner PAP authentication) </quote> The second one could be less confusing for people trying to setup EAP-TTLS/PAP on ldap directories but of course this is not a big deal... Thibault
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
While usually true, this assumption is a little confusing sometimes. Indeed, when EAP-TTLS uses PAP (not an EAP protocol I know) as its inside authentication protocol, a cleartext password is provided to Freeradius which is then able to use a simple ldap bind exchange to authenticate the user.
But you still can't force "Auth-Type := LDAP", because then the outer TTLS session will fail. I'm inclined to remove the LDAP "bind as user" entirely, or move it to a completely separate "ldap_bind" module. It's a major cause of problems, and it's rarely necessary. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
While usually true, this assumption is a little confusing sometimes. Indeed, when EAP-TTLS uses PAP (not an EAP protocol I know) as its inside authentication protocol, a cleartext password is provided to Freeradius which is then able to use a simple ldap bind exchange to authenticate the user.
But you still can't force "Auth-Type := LDAP", because then the outer TTLS session will fail.
I don't need to... In the authorize section I get something like this: authorize { eap files ldap } EAP beeing before files, it sets Auth-Type to EAP and when the files module tries to force "Auth-Type = LDAP" (not ":=") it stays with Auth-Type=EAP untill the inside PAP phase is reached. This is how it works (quite well) for me. ... but you've written a big part of the code so you already know this... I might have not caught what you are saying.
I'm inclined to remove the LDAP "bind as user" entirely, or move it
Pity... that's the best setup I found in my case :-(
to a completely separate "ldap_bind" module. It's a major cause of problems, and it's rarely necessary.
Well, I find it very usefull: * the inner PAP authentication is "processed" by the ldap module in which I don't need to define which password hashing method is used (I use at least CRYPT _and_ MD5 in the same directory for historical reasons) * I don't need to have freeradius _read_ the passwords from the directory: the DN identity defined in the ldap module can only have auth and read access to radius entries but not to the passwords (which in my point of view is more secure) Again, I might not have caught your meaning: Are you saying that in the future the standards ldap module will be only an authorization module, and that a new ldap_bind module could be used in the authenticate section ? Regards, Thibault
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
* the inner PAP authentication is "processed" by the ldap module in which I don't need to define which password hashing method is used (I use at least CRYPT _and_ MD5 in the same directory for historical reasons)
Version 2.0 has fixes that make it much easier to handle multiple hashing types in the same LDAP database.
* I don't need to have freeradius _read_ the passwords from the directory: the DN identity defined in the ldap module can only have auth and read access to radius entries but not to the passwords (which in my point of view is more secure)
If all you're doing is PAP, sure. Most wireless deployments use PEAP, and then people wonder why "bind as user" doesn't work. It's frustrating.
Again, I might not have caught your meaning: Are you saying that in the future the standards ldap module will be only an authorization module, and that a new ldap_bind module could be used in the authenticate section ?
I think it's a good idea. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
* the inner PAP authentication is "processed" by the ldap module in which I don't need to define which password hashing method is used (I use at least CRYPT _and_ MD5 in the same directory for historical reasons)
Version 2.0 has fixes that make it much easier to handle multiple hashing types in the same LDAP database.
Yes, I remember having read something about this in the list... I'm longing to test this release ;-)
* I don't need to have freeradius _read_ the passwords from the directory: the DN identity defined in the ldap module can only have auth and read access to radius entries but not to the passwords (which in my point of view is more secure)
If all you're doing is PAP, sure. Most wireless deployments use PEAP, and then people wonder why "bind as user" doesn't work. It's frustrating.
I understand (It's true that this list is nearly 30% about this kind of issue despite the faqs on this) :-(
Again, I might not have caught your meaning: Are you saying that in the future the standards ldap module will be only an authorization module, and that a new ldap_bind module could be used in the authenticate section ?
I think it's a good idea.
Why not indeed ... (as long as there's a new ldap_bind module to replace the ldap 'authentication' part ;-) ). Thanks for this reply and for this great opensource project. Regards, Thibault
On Fri 22 Sep 2006 10:52, Thibault Le Meur wrote:
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
* the inner PAP authentication is "processed" by the ldap module in which I don't need to define which password hashing method is used (I use at least CRYPT _and_ MD5 in the same directory for historical reasons)
Version 2.0 has fixes that make it much easier to handle multiple hashing types in the same LDAP database.
Yes, I remember having read something about this in the list... I'm longing to test this release ;-)
ftp://ftp.freeradius.org/pub/radius/CVS-snapshots It gets better every day. :-) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Fri 22 Sep 2006 10:52, Thibault Le Meur wrote:
Thibault Le Meur <Thibault.LeMeur@supelec.fr> wrote:
* the inner PAP authentication is "processed" by the ldap module in which I don't need to define which password hashing method is used (I use at least CRYPT _and_ MD5 in the same directory for historical reasons)
Version 2.0 has fixes that make it much easier to handle multiple hashing types in the same LDAP database.
Yes, I remember having read something about this in the list... I'm longing to test this release ;-)
ftp://ftp.freeradius.org/pub/radius/CVS-snapshots
Thanks, in fact I know that by using the developpment version I could have a test at the 2.0 branch, but I'm a little "frightened" to test it in my production environment... I think I'll use the CVS code on my backup server.
It gets better every day. :-)
I have no doubt about this ;-) Thibault
Thanks, in fact I know that by using the developpment version I could have a test at the 2.0 branch, but I'm a little "frightened" to test it in my production environment...
I just want to correct my words because I don't want users on the list to misunderstand my meaning: I think the CVS code is certainly enough stable now to be used, but I need to install my new radius server quickly and I don't currently have time to adapt my setup to the new 2.0 code.
I think I'll use the CVS code on my backup server.
I'll really do, because testing and reporting is also a way to contribute. Thanks to all developpers for this great work. Thibault
participants (3)
-
Alan DeKok -
Peter Nixon -
Thibault Le Meur