Freeradius, Cisco SSC, eDirectory, EAP/(T)TLS Problem
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, we use Freeradius (1.1.0 from sles10) to provide 802.1x on all wired switches in the company. As backend we have Novell eDir where all users are stored. We also use per user vlans, which are stored in the eDir. This setup is working so far. Now we want to secure the authentification by ssl certificates (to protect the client from "foreign" server getting their credentials, and the "eDir" from "foreign" clients - to avoid brute force attacks). Our idea was: Using a "general" certificate to identify every supplicant/client and use this cert to protect the tunnel where user/pass is provided. We have configured a guest-vlan (2) on the cisco switch where all unauthentificated or "unknown" supplicants/clients get into. The next vlan (4) is for supplicants/clients which have the right cert installed, and last but not least the users own vlan (300). - From vlan 2 you're not allowed to do "anything" beside stageing the client (for new installations). At vlan 4 you may connect to a few servers (to get your box ready for production when no user is setup) and 300 is a fully working vlan. For now this works "a bit". It seems that you cannot use "just" a cert to get into the vlan 4 (you need user + user defined in users file, at least for the cisco client, who *needs* a user when using a cert..). Beside that, i noticed that when using a wrong ssl cert and user+pw (to get vlan300) freeradius *first* checks the edirectory, and THEN the eap/ttls stuff - shouldn't this be exactly the other way around? Our config looks like: radius.conf: modules { eap { default_eap_type = ttls ignore_unknown_eap_types = no tls { private_key_file = key certificate_file = cert CA_file = ca.crt } ttls { private_key_file = key certificate_file = cert CA_file = ca.cert default_eap_type = md5 copy_request_to_tunnel = yes use_tunneled_reply = yes } } ldap { server = "edir.company.lan" port = 636 identify = "cn=freeradius,o=admin" password = xxx basedn = "o=company" tls_mode = yes ... edir_account_policy_check = yes } files { # defaultstuff } } authorize { preprocess eap ldap } authenticate { eap Auth-Type LDAP { ldap } } post-auth { ldap Post-Auth-Type REJECT { ldap } } users: DEFAULT Auth-Type = LDAP Tunnel-Type := "VLAN", Tunnel-Medium-Type := "IEEE-802", Fall-Through = Yes DEFAULT Service-Type == Framed-User Framed-IP-Address = 255.255.255.254, Framed-MTU = 576, Service-Type = Framed-User, Fall-Through = Yes, DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP So why doesn't it check the tunnel (ssl) first and stops if the client has no valid cert? I think i just overlooked something... but i'm a bit puzzled now... Regards and thanks, Sven Michels -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6X6yQoCguWUBzBwRArY8AJ4/BiDsM4rnxoHfmYUkMNLKjOhGbgCcCtnM dzeTmRQRC7qB8QlhiVlOG6w= =vAqe -----END PGP SIGNATURE-----
Hi,
Beside that, i noticed that when using a wrong ssl cert and user+pw (to get vlan300) freeradius *first* checks the edirectory, and THEN the eap/ttls stuff - shouldn't this be exactly the other way around?
err, no, because you have told it to behave like this. change the order of the modules in authorize and athenticate sections of your config if you want it any other way! alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A.L.M.Buxey@lboro.ac.uk wrote:
Beside that, i noticed that when using a wrong ssl cert and user+pw (to get vlan300) freeradius *first* checks the edirectory, and THEN the eap/ttls stuff - shouldn't this be exactly the other way around?
err, no, because you have told it to behave like this. change the order of the modules in authorize and athenticate sections of your config if you want it any other way!
erm? so, the sections are used from down to top? *scratches head* Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6YYnQoCguWUBzBwRAuovAKCRUH7RZPg+0MSooVilGLZ+dfGj7QCfe2Y+ iu/uSPlXZN//NppDESm5jkw= =gTzR -----END PGP SIGNATURE-----
Hi,
erm? so, the sections are used from down to top? *scratches head*
no, IGNORE the modules seciton - that just configures the modules. LOOK at your config authorize { preprocess eap ldap } authenticate { eap Auth-Type LDAP { ldap } } here we can CLEARLY see that EAP is done before LDAP alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A.L.M.Buxey@lboro.ac.uk wrote:
no, IGNORE the modules seciton - that just configures the modules. LOOK at your config
authorize { preprocess eap ldap } authenticate { eap Auth-Type LDAP { ldap } }
here we can CLEARLY see that EAP is done before LDAP
exactly, yeah, but the log says the other way around. I get a ldap request, which succeeds and after that a tls NACK (due to no cert). I would expect its the other way around, shouldn't it? Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6hkeQoCguWUBzBwRAtkEAJwKsj5hFxre97zXRsZGaC4qWXsrSACeNeB3 rlf28a4T7Rk3IQqkRkEFx+Y= =YXGM -----END PGP SIGNATURE-----
Sven 'Darkman' Michels wrote:
here we can CLEARLY see that EAP is done before LDAP
exactly, yeah, but the log says the other way around. I get a ldap request, which succeeds and after that a tls NACK (due to no cert). I would expect its the other way around, shouldn't it?
Post the debug log. It lists which modules are being executed, and in what order. EAP uses *many* round trips. So you may be looking at the output from two different packets, and concluding that the processing is in a *different* order than in the config files. Read the debug log. It's *all* there. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Alan DeKok wrote:
Sven 'Darkman' Michels wrote:
here we can CLEARLY see that EAP is done before LDAP exactly, yeah, but the log says the other way around. I get a ldap request, which succeeds and after that a tls NACK (due to no cert). I would expect its the other way around, shouldn't it?
Post the debug log. It lists which modules are being executed, and in what order.
Will do so later. Busy day today, sorry :(
EAP uses *many* round trips. So you may be looking at the output from two different packets, and concluding that the processing is in a *different* order than in the config files.
Read the debug log. It's *all* there.
Ok, i'll doublecheck that. But just a note: if i use the wrong cert and see a NACK message in the log - then my ttls failed and i shouldn't see a ldap query at all...? Or do i missunderstand something here? I just want to make sure that my client is "my" client, and not a stranger. Thats why i want the eap stuff (to force all "signed" by the clients cert, and avoid password attacks and stuff like that). Thanks for your (quick) help so far. Many regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6m1aQoCguWUBzBwRAoPrAKCOmL1bNYMan8eZIfcCSansLFUlvwCfVbFA YjUDvyfJn8rN7P1JwA0RjMw= =IUrc -----END PGP SIGNATURE-----
Sven 'Darkman' Michels wrote:
Ok, i'll doublecheck that. But just a note: if i use the wrong cert and see a NACK message in the log - then my ttls failed and i shouldn't see a ldap query at all...?
It all depends on how you set up your configuration.
Or do i missunderstand something here? I just want to make sure that my client is "my" client, and not a stranger. Thats why i want the eap stuff (to force all "signed" by the clients cert, and avoid password attacks and stuff like that).
You can configure the LDAP queries to be run *only* after the TLS tunnel has been set up. See raddb/sites-available/inner-tunnel. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alan, Alan DeKok wrote:
It all depends on how you set up your configuration.
Hehe, yeah, figured that out... ;)
You can configure the LDAP queries to be run *only* after the TLS tunnel has been set up. See raddb/sites-available/inner-tunnel.
But this works only on freeradius 2.x, doesn't it? Actually i have 1.1.0 from SLES10... Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH6oFTQoCguWUBzBwRAm4JAKCT/VDKP3MsYF3ncdd/uKFzvO51WgCfWXSS 1Xi3/s5Ox5xRvaW+xjpvHf4= =E5vP -----END PGP SIGNATURE-----
Sven 'Darkman' Michels wrote:
But this works only on freeradius 2.x, doesn't it? Actually i have 1.1.0 from SLES10...
Download the binary Suse packages: http://freeradius.org/download.html 1.1.0 is *very* old. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Alan DeKok wrote:
Sven 'Darkman' Michels wrote:
But this works only on freeradius 2.x, doesn't it? Actually i have 1.1.0 from SLES10...
Download the binary Suse packages: http://freeradius.org/download.html
1.1.0 is *very* old.
i noticed that, too :/ I upgraded last night to 2.0.2 and migrated the config. Now it looks a bit better. My default server does the tls tunneling and my inner-tunnel server is handling the ldap stuff. The only problem i had was "where to force the client cert when using eap/tls" - for now i just put it into the the authorize {} block: authorize { ... eap { ok = return } update control { EAP-TLS-Require-Client-Cert = yes } ... } which seems to work except that the cisco client simply don't offer a cert when using ttls. As far as i know, this requirement is not often met at any client (you posted some note about a while ago...) so we're calling cisco today to clearify how we can do maschine and user authentification with forced clientcert (i can only do ttls for maschine AND user/pw auth and not doing like tls for maschine and ttls for user/pw - their client doesn't support that - the new client just crashes when the server requires a cert, horray ;). Thanks for your help so far - the main issue was the old freeradius as it seems... Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH61KRQoCguWUBzBwRAllMAJ9jP+KGH/6TboRMcUYAgi/SZN2aLgCfVw61 tQaYYdl4J63YABGefKO2q8s= =xS2p -----END PGP SIGNATURE-----
Sven 'Darkman' Michels wrote:
...The only problem i had was "where to force the client cert when using eap/tls"
EAP-TLS *always* uses a client cert.
which seems to work except that the cisco client simply don't offer a cert when using ttls. As far as i know, this requirement is not often met at any client (you posted some note about a while ago...)
Yes.
so we're calling cisco today to clearify how we can do maschine and user authentification with forced clientcert (i can only do ttls for maschine AND user/pw auth and not doing like tls for maschine and ttls for user/pw - their client doesn't support that - the new client just crashes when the server requires a cert, horray ;).
Nice!
Thanks for your help so far - the main issue was the old freeradius as it seems...
Yes. Upgrading is usually a good idea. Alan DeKok.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Sven 'Darkman' Michels