Using Attributes to differentiate between different EAP types
I have configured a Freeradius server to work with PEAP using NTLM_AUTH. Everything worked fine and tested out perfectly. Since then I added a configuration for EAP_TTLS, which really just means I added a configured LDAP module ldap_myconfig into the inner-tunnel. Unfortunately the PEAP connection no longer works, but the TTLS does. PEAP is my default EAP type. So Im pretty sure the simplest fix is to just have a if operator and for something like If(rlm_eap_type == EAP/TTLS) { ldap_myconfig} The only problem is that I have not seen any such attribute for freeradius. I figure there should very well be something akin to that as a run time variable correct? Regards, Nathan Van Fleet
So I�m pretty sure the simplest fix is to just have a if operator and for something like
If(rlm_eap_type == �EAP/TTLS�)
{ ldap_myconfig}
Check that you haven't enabled access attribute in ldap configuration. That will reject users not in ldap.
The only problem is that I have not seen any such attribute for freeradius. I figure there should very well be something akin to that as a run time variable correct?
Have a look in dictionary.freeradius.internal. Ivan Kalik Kalik Informatika ISP
Ivan, After setting up FR successfully for wireless access/auth using WPA2-EAP_PEAP using the certs generated by ./bootstrap I decided to generate my own as detailed in CA the documentation. I created a CAs for Redhat(.pem) and WindowsXP clients (.der) substituting my company information in the appropriate places of the CA.cnf. For some unknown reason my self certs failed to work in either client. After trying this twice and have both attempts fail I regenerated the original CAs for example using ./bootstrap, the old CA.cnf file - they both worked for my clients (Linux/WinXP) Suggestions on debugging this process. Steven -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hi,
For some unknown reason my self certs failed to work in either client. After trying this twice and have both attempts fail I regenerated the original CAs for example using ./bootstrap, the old CA.cnf file - they both worked for my clients (Linux/WinXP)
you need to ensure all the old stuff is gone.. cd $place/raddb/certs make clean make destroycerts edit ca.cnf, server.cnf and client.cnf to ensure that everything matches and expects the same organisation etc then you can re-run the bootstrap and it'll be fine (or should be!) PS this is for a modern version - eg 2.1.6 alan
Yes, Before I tried for the second time to make self signed certs - I did use the command prompt command in the CA doc to delete everything *.pem. *.der, etc.
edit ca.cnf, server.cnf and client.cnf to ensure that everything matches and expects the same organisation etc... then you can re-run the bootstrap and it'll be fine
I thought you only needed to edit the ca.cnf if you needed to make self signed root certs for EAP-PEAP clients. I did not see any note that said you needed to make the same edits to the server.cnf and client.cnf's ?? Any way, If that is required I will give a go. Just so I am sure "what has to be changed" in the *.cnf's for this to work - please confirm by looking at what I intend to edit = * [ req ] prompt = no distinguished_name = certificate_authority default_bits = 2048 * input_password = whatever * output_password = whatever x509_extensions = v3_ca [certificate_authority] * countryName = FR * stateOrProvinceName = Radius * localityName = Somewhere * organizationName = Example Inc. * emailAddress = admin@example.com * commonName = "Example Certificate Authority" Steven -----Original Message----- From: Alan Buxey <A.L.M.Buxey@lboro.ac.uk> Subject: Re: Self Signed Certs Fail - pem/der Hi,
For some unknown reason my self certs failed to work in either client. After trying this twice and have both attempts fail I regenerated the original CA’s for “example” using ./bootstrap, the old CA.cnf file - they both worked for my clients (Linux/WinXP)
you need to ensure all the old stuff is gone.. cd $place/raddb/certs make clean make destroycerts edit ca.cnf, server.cnf and client.cnf to ensure that everything matches and expects the same organisation etc then you can re-run the bootstrap and it'll be fine (or should be!) PS this is for a modern version - eg 2.1.6 alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Steven Sprague <steven@sprague-enterprises.com> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
edit ca.cnf, server.cnf and client.cnf to ensure that everything matches and expects the same organisation etc... then you can re-run the bootstrap and it'll be fine
I thought you only needed to edit the ca.cnf if you needed to make self signed root certs for EAP-PEAP clients. I did not see any note that said you needed to make the same edits to the server.cnf and client.cnf's ??
Issuer details for ca and server certificates need to match. Same applies for clients if you are making those as well. Ivan Kalik Kalik Informatika ISP
I've checked and I'm not using that attribute. I checked the dictionary and it appears as if the attribute "EAP-Type" is what I'm looking for. However, it's an integer attribute and there is no information on what integer TTLS and PEAP are configured as. So I can't really guess at it. Is there anymore information about this attribute? Nathan Van Fleet
-----Original Message----- From: freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org [mailto:freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org] On Behalf Of Ivan Kalik Sent: Monday, September 14, 2009 5:05 PM To: FreeRadius users mailing list Subject: Re: Using Attributes to differentiate between different EAP types
So I�m pretty sure the simplest fix is to just have a if operator and for something like
If(rlm_eap_type == �EAP/TTLS�)
{ ldap_myconfig}
Check that you haven't enabled access attribute in ldap configuration. That will reject users not in ldap.
The only problem is that I have not seen any such attribute for freeradius. I figure there should very well be something akin to that as
a
run time variable correct?
Have a look in dictionary.freeradius.internal.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I've checked and I'm not using that attribute.
I checked the dictionary and it appears as if the attribute "EAP-Type" is what I'm looking for. However, it's an integer attribute and there is no information on what integer TTLS and PEAP are configured as. So I can't really guess at it.
Is there anymore information about this attribute?
Perhaps reading the dictionary to the end might help? Ivan Kalik Kalik Informatika ISP
Whoops, You're correct. Is this attribute inside something? Like "outer for" "outer.NAS-IP-Address"? Nathan Van Fleet Telecommunications Analyst Network Assessment and Integration IITS Concordia University (514) 848-2424 Extension:5434
-----Original Message----- From: freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org [mailto:freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org] On Behalf Of Ivan Kalik Sent: Tuesday, September 15, 2009 9:29 AM To: FreeRadius users mailing list Subject: RE: Using Attributes to differentiate between different EAP types
I've checked and I'm not using that attribute.
I checked the dictionary and it appears as if the attribute "EAP-Type" is what I'm looking for. However, it's an integer attribute and there is no information on what integer TTLS and PEAP are configured as. So I can't really guess at it.
Is there anymore information about this attribute?
Perhaps reading the dictionary to the end might help?
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
Alan Buxey -
Ivan Kalik -
Nathan McDavit-Van Fleet -
nmcdavit＠alcor.concordia.ca
-
Steven Sprague -
steven＠sprague-enterprises.com