I understand a bit more why people were bring up plain text passwords now. My radius server is being presented with peap ms-chapV2 credentials and I want it to receive authentication from my openldap server. It seems that the credentials in this format cannot be digested by openldap and acknowledged. The passwords in my openldap are encrypted as SHA Do I have this right? Is there an alternative. Maybe that FreeRadius 3.0.0 rc1 mentioned in one of the emails the other day? Thanks for your attention
On 10 Sep 2013, at 19:15, "Swenson, Chris" <cswenson@curry.edu> wrote:
I understand a bit more why people were bring up plain text passwords now.
My radius server is being presented with peap ms-chapV2 credentials and I want it to receive authentication from my openldap server.
What happened to that web gateway?
It seems that the credentials in this format cannot be digested by openldap and acknowledged. The passwords in my openldap are encrypted as SHA
Do I have this right? Is there an alternative.
* Use a different EAP method, OR * Rehash all your credentials to NT-Password format, OR * Harvest passwords and store them in Plaintext
Maybe that FreeRadius 3.0.0 rc1 mentioned in one of the emails the other day?
No. It's good but it's not magic. You need the plaintext password for comparison, there's no way to transform the MSHCAPV2 responses in the cleartext password or to a SHA1 password. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
-----Original Message----- From: freeradius-users-bounces+cswenson=curry.edu@lists.freeradius.org [mailto:freeradius-users-bounces+cswenson=curry.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Tuesday, September 10, 2013 3:07 PM To: FreeRadius users mailing list Subject: Re: free radius setup On 10 Sep 2013, at 19:15, "Swenson, Chris" <cswenson@curry.edu> wrote:
I understand a bit more why people were bring up plain text passwords now.
My radius server is being presented with peap ms-chapV2 credentials and I want it to receive authentication from my openldap server.
What happened to that web gateway?
my vague understanding of what I was getting into led to a misstatement.
It seems that the credentials in this format cannot be digested by openldap and acknowledged. The passwords in my openldap are encrypted as SHA
Do I have this right? Is there an alternative.
* Use a different EAP method, OR * Rehash all your credentials to NT-Password format, OR * Harvest passwords and store them in Plaintext
Maybe that FreeRadius 3.0.0 rc1 mentioned in one of the emails the other day?
No. It's good but it's not magic. You need the plaintext password for comparison, there's no way to transform the MSHCAPV2 responses in the cleartext password or to a SHA1 password.
Back to the drawing board for me. I may be back with more questions. Thanks
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 09/10/2013 02:15 PM, Swenson, Chris wrote:
I understand a bit more why people were bring up plain text passwords now.
My radius server is being presented with peap ms-chapV2 credentials and I want it to receive authentication from my openldap server.
It seems that the credentials in this format cannot be digested by openldap and acknowledged.
The passwords in my openldap are encrypted as SHA
Do I have this right?
Is there an alternative.
Maybe that FreeRadius 3.0.0 rc1 mentioned in one of the emails the other day?
Before you go any further you need to read and understand the material on this page: http://deployingradius.com/documents/protocols/compatibility.html -- John
Yes, I already saw that and this is why I am stuck. I am using Aruba 3000 Wireless controllers running the 6.2.X.X code. As I understand it when the laptop user selects the secure SSID they should be prompted for a username and password. This username and password will be presented to radius as peap MS-CHAPV2. Radius then needs to authenticate this against my Openldap where the passwords are encrypted as SHA, thus bad end. I could not find an encryption type in open ldap that would satisfy the chart. If it did work then I could take the info from radius accounting and pass it to our NAC control (Impulse Safe Connect) which will let the students onto the network after they pass some computer hygiene checks. I have a population of 2000 college students who have little idea of what security really is. And of course I am trying to do this on the typical budget provided by a non-profit such as my college is. Chris S. -----Original Message----- From: John Dennis [mailto:jdennis@redhat.com] Sent: Tuesday, September 10, 2013 6:09 PM To: FreeRadius users mailing list Cc: Swenson, Chris Subject: Re: free radius setup On 09/10/2013 02:15 PM, Swenson, Chris wrote:
I understand a bit more why people were bring up plain text passwords now.
My radius server is being presented with peap ms-chapV2 credentials and I want it to receive authentication from my openldap server.
It seems that the credentials in this format cannot be digested by openldap and acknowledged.
The passwords in my openldap are encrypted as SHA
Do I have this right?
Is there an alternative.
Maybe that FreeRadius 3.0.0 rc1 mentioned in one of the emails the other day?
Before you go any further you need to read and understand the material on this page: http://deployingradius.com/documents/protocols/compatibility.html -- John
On 10 Sep 2013, at 23:35, "Swenson, Chris" <cswenson@curry.edu> wrote:
Yes, I already saw that and this is why I am stuck. I am using Aruba 3000 Wireless controllers running the 6.2.X.X code. As I understand it when the laptop user selects the secure SSID they should be prompted for a username and password. This username and password will be presented to radius as peap MS-CHAPV2. Radius then needs to authenticate this against my Openldap where the passwords are encrypted as SHA, thus bad end. I could not find an encryption type in open ldap that would satisfy the chart.
On the registration page you use to 'activate' users accounts for the service, you get them to login. Once their password is verified against OpenLDAP you do an LDAP modify and store the plaintext version. This is exactly what we did at University of Sussex when we rolled out the service six years ago. We opted to store NT-Password hashes. These are not really any more secure than cleartext, but at least you don't accidentally see the user's output in any directory dumps or debug output. The alternative is getting your users to install something like SecureW2 (which I believe requires a license now), and using EAP-TTLS-PAP which submits the users password in plaintext, or I believe more recent flavours of Windows support EAP-TTLS too.
If it did work then I could take the info from radius accounting and pass it to our NAC control (Impulse Safe Connect) which will let the students onto the network after they pass some computer hygiene checks.
Sure or you can use the result of Phil's excellent work on SoH, and do the hygiene checks at the same time as authentication (if you do go with PEAP).
I have a population of 2000 college students who have little idea of what security really is.
Well that's a fairly small user base. You should be able to handle that load on any fairly recent desktop machine. Hell you might even be able to do it on a Rasberry Pi provided they don't re-auth too often.
And of course I am trying to do this on the typical budget provided by a non-profit such as my college is.
The majority of Universities in the UK and many smaller colleges implement Eduroam which require 802.1X authentication. It's not terribly expensive seeing as all the software is free... -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 09/10/2013 06:54 PM, Arran Cudbard-Bell wrote:
On the registration page you use to 'activate' users accounts for the service, you get them to login. Once their password is verified against OpenLDAP you do an LDAP modify and store the plaintext version. This is exactly what we did at University of Sussex when we rolled out the service six years ago.
We opted to store NT-Password hashes. These are not really any more secure than cleartext, but at least you don't accidentally see the user's output in any directory dumps or debug output.
And be sure to set ACL's (Access Control Lists) on the password attributes so that only the admin and the radius process can read them. -- John
The alternative is getting your users to install something like SecureW2 (which I believe requires a license now), and using EAP-TTLS- PAP which submits the users password in plaintext, or I believe more recent flavours of Windows support EAP-TTLS too.
If I remember correctly, when using EAP-TTLS-PAP, the top-level default_eap_type should be "ttls", and then the default_eap_type in the TTLS section should be "gtc" (which uses PAP by default). AFAIK (and please correct me if I'm wrong), you cannot set the TTLS default_eap_type setting to PAP. Regards Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 11/09/13 12:05, stefan.paetow@diamond.ac.uk wrote:
The alternative is getting your users to install something like SecureW2 (which I believe requires a license now), and using EAP-TTLS- PAP which submits the users password in plaintext, or I believe more recent flavours of Windows support EAP-TTLS too.
If I remember correctly, when using EAP-TTLS-PAP, the top-level default_eap_type should be "ttls", and then the default_eap_type in the TTLS section should be "gtc" (which uses PAP by default).
AFAIK (and please correct me if I'm wrong), you cannot set the TTLS default_eap_type setting to PAP.
That's because EAP-TTLS/PAP doesn't use EAP on the inner tunnel. Just PAP. So "default_eap_type" is irrelevant. You support EAP-TTLS/PAP by ensuring PAP is working in the inner tunnel - by populating a cleartext or hashed password and calling the "pap" module in the authorize/authenticate section, or other more specialised configs. EAP-TTLS/EAP-GTC is a different thing.
That's because EAP-TTLS/PAP doesn't use EAP on the inner tunnel. Just PAP. So "default_eap_type" is irrelevant.
You support EAP-TTLS/PAP by ensuring PAP is working in the inner tunnel - by populating a cleartext or hashed password and calling the "pap" module in the authorize/authenticate section, or other more specialised configs.
Phil, Your email made me look at this configuration again. Turns out that setting set_auth_type in the ldap module to "no", leaving copy_request_to_tunnel unset (i.e. set to the default "no"), and allowing LDAP authentication only in the inner tunnel made things work the same way as what it had been with gtc set. Thanks for that! Another thing to add to the cook book. :-) Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
participants (5)
-
Arran Cudbard-Bell -
John Dennis -
Phil Mayers -
stefan.paetow＠diamond.ac.uk -
Swenson, Chris