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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
