Hi, The aim and assumptions: -configure FR to authenticate users against OpenLDAP server, -FR would use EAP method, -passwords in LDAP are stored as SHA1, -according to http://deployingradius.com/documents/protocols/compatibility.html the only way to deal with LDAP auth is to use PAP or EAP-GTC. Since client forces EAP method we have no choice than EAP-GTC. Is that correct? -clients are EAP-GTC capable, -FR v2.2.6. After some hours in my lab I finished with the following FR config: 1) in eap.conf: -in eap general settings I set default_eap_type to "gtc" -in gtc section I put "auth_type = LDAP". 2) in sites-enabled/default: -authorize section - not touched, -authentication section - uncomment "Auth-Type LDAP { ldap }", And it is working fine! Now, the questions: a) I am afraid about your comments in gtc section. It stands that: # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. Can I use eap-gtc "alone" without PEAP/TTLS? Secure tunnel is delivered via IPsec connection so I do not bother about security in that case. What is your opinion? b) How would you configure FR to meet mentioned above requirements? Gabriel
On May 20, 2015, at 7:21 AM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
The aim and assumptions: -configure FR to authenticate users against OpenLDAP server, -FR would use EAP method, -passwords in LDAP are stored as SHA1, -according to http://deployingradius.com/documents/protocols/compatibility.html the only way to deal with LDAP auth is to use PAP or EAP-GTC. Since client forces EAP method we have no choice than EAP-GTC. Is that correct?
Yes.
-clients are EAP-GTC capable, -FR v2.2.6.
After some hours in my lab I finished with the following FR config: 1) in eap.conf: -in eap general settings I set default_eap_type to "gtc" -in gtc section I put "auth_type = LDAP".
That's probably not necessary. Just use "auth_type = PAP". And be sure to list "ldap" in the "authorize" section.
2) in sites-enabled/default: -authorize section - not touched, -authentication section - uncomment "Auth-Type LDAP { ldap }",
And it is working fine!
You're usually better off letting the PAP module do the authentication. But if it works, leave well enough alone.
Now, the questions: a) I am afraid about your comments in gtc section. It stands that: # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. Can I use eap-gtc "alone" without PEAP/TTLS?
Yes, but the passwords go over the network in the clear.
Secure tunnel is delivered via IPsec connection so I do not bother about security in that case. What is your opinion?
Can anyone ELSE on the network monitor the traffic in the IPSec connection? If so, they will be able to see everyone else's traffic.
b) How would you configure FR to meet mentioned above requirements?
Use RADIUS over TLS. But most clients don't support it. Alan DeKok.
That's probably not necessary. Just use "auth_type = PAP". And be sure to list "ldap" in the "authorize" section.
I tried this and it is not working. It did not even try to bind to LDAP as a user.
2) in sites-enabled/default: -authorize section - not touched, -authentication section - uncomment "Auth-Type LDAP { ldap }", And it is working fine!
You're usually better off letting the PAP module do the authentication.
I do not understand how could it work without uncomment "Auth-Type LDAP { ldap }" in the authenticate section. How would FR know to do LDAP auth without it?
But if it works, leave well enough alone.
Now, the questions: a) I am afraid about your comments in gtc section. It stands that: # Currently, this is only permitted inside of EAP-TTLS, # or EAP-PEAP. The module "challenges" the user with # text, and the response from the user is taken to be # the User-Password. # # Proxying the tunneled EAP-GTC session is a bad idea, # the users password will go over the wire in plain-text, # for anyone to see. Can I use eap-gtc "alone" without PEAP/TTLS?
Yes, but the passwords go over the network in the clear.
No, they do not. Strongswan is the EAP client in that case, IPsec protects communication between the clients and Strongswan server, additionally FR is installed on the same machine so TTLS does not add any value here.
Secure tunnel is delivered via IPsec connection so I do not bother about security in that case. What is your opinion?
Can anyone ELSE on the network monitor the traffic in the IPSec connection? If so, they will be able to see everyone else's traffic.
See above. Gabriel
On May 21, 2015, at 9:01 AM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
That's probably not necessary. Just use "auth_type = PAP". And be sure to list "ldap" in the "authorize" section.
I tried this and it is not working. It did not even try to bind to LDAP as a user.
That's the point.
2) in sites-enabled/default: -authorize section - not touched, -authentication section - uncomment "Auth-Type LDAP { ldap }", And it is working fine!
You're usually better off letting the PAP module do the authentication.
I do not understand how could it work without uncomment "Auth-Type LDAP { ldap }" in the authenticate section. How would FR know to do LDAP auth without it?
It doesn't. Perhaps you're missing something important. LDAP is a *database*. It's not an authentication server. FreeRADIUS is an authentication server. FreeRADIUS should pull the "known good" password from LDAP. Because LDAP is a database. Then, FreeRADIUS should do all of the calculations for the authentication method. And FreeRADIUS should authenticate the user. What happens when you have a cleartext password in LDAP, and FreeRADIUS receives an MS-CHAP request? With "Auth-Type = LDAP", it fails. Because LDAP doesn't do MS-CHAP. When you use LDAP as a database and FreeRADIUS as an authentication server, it succeeds. FreeRADIUS pulls the password from LDAP, and does the MS-CHAP calculations.
Yes, but the passwords go over the network in the clear.
No, they do not. Strongswan is the EAP client in that case, IPsec protects communication between the clients and Strongswan server, additionally FR is installed on the same machine so TTLS does not add any value here.
Anyone who can see traffic inside of the IPSec tunnel can see the EAP-GTC data, and the password. You can't just say "we use IPSec", and believe that all of the security problems are address. You have to *understand* what the systems are doing. Alan DeKok.
Not that easy to find out how all the things should be done :) I put in the title that we store passwords in LDAP database hashed by SHA1. According to my knowledge, LDAP won't return the "known good" password. Is that correct?
On May 21, 2015, at 9:22 AM, gabriel_skupien <gabriel_skupien@o2.pl> wrote:
Not that easy to find out how all the things should be done :)
I put in the title that we store passwords in LDAP database hashed by SHA1. According to my knowledge, LDAP won't return the "known good" password. Is that correct?
No. Perhaps I didn't explain that LDAP is a database? And that FreeRADIUS should be able to read the "known good" password from LDAP? Should I say that again? LDAP is a database. It supplies the "known good" password to FreeRADIUS. Which FreeRADIUS uses for authentication. Is that sufficient to make you believe it? Alan DeKok.
I believe :) Will it change something when I add that passwords are stored in LDAP as salted SHA1 not just SHA1?
All is clear now. The problem was at LDAP side where bindDN user did not have rights to read userPasswords. Ticket to be closed.
participants (2)
-
Alan DeKok -
gabriel_skupien