OpenLDAP+FreeRadius Encryption
We're using currently using freeradius 2.x and migrating to a new server where we will be using 3.0.4. Our OpenLDAP server has plaintext passwords currently, but as I migrate the server over, I would like to encrypt and salt them (something like SSHA). Both the LDAP and Radius servers will be on the same box. The problem devices is our wireless clients made up of Macs and phones (Android and iPhone) and the traffic passes through a Cisco WLC. If I want to encrypt, then it seems I would have to use EAP-GTC along with PAP. The Macs seem to only want to authenticate with MSCHAPv2. I found on Android phones if I don't set the Phase 2 authentication, it only checks MSCHAPv2, however if I force it to use GTC, then it authenticates correctly. I did notice in the logs using GTC, it has the ability to display the encrypted password in the clear. Didn't do this with MSCHAPv2. So here are my questions: 1. Is there something I'm missing from what I've trying and seeing above? 2. Is GTC and PAP with encrypted passwords less secure than using MSCHAPv2 with Plain text passwords in LDAP (even though they are on the same box)? 3. Should Mac's be able to use GTC? I've read that with Cisco ISE, this can be force, but beyond that I couldn't come across any article discussing it. I'm having trouble finding the article or thread, but I had read before the best solution with OpenLDAP and FreeRadius is plain-text passwords in LDAP, MSCHAPv2 for authentication and ACL's on the ldap OU's. Is this the recommendation? I would also like to prevent the ability to sniff the passwords in whichever scenario is used.
On Feb 1, 2016, at 6:09 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
We're using currently using freeradius 2.x and migrating to a new server where we will be using 3.0.4.
Our OpenLDAP server has plaintext passwords currently, but as I migrate the server over, I would like to encrypt and salt them (something like SSHA). Both the LDAP and Radius servers will be on the same box.
The problem devices is our wireless clients made up of Macs and phones (Android and iPhone) and the traffic passes through a Cisco WLC.
If I want to encrypt, then it seems I would have to use EAP-GTC along with PAP. The Macs seem to only want to authenticate with MSCHAPv2. I found on Android phones if I don't set the Phase 2 authentication, it only checks MSCHAPv2, however if I force it to use GTC, then it authenticates correctly. I did notice in the logs using GTC, it has the ability to display the encrypted password in the clear. Didn't do this with MSCHAPv2.
So here are my questions: 1. Is there something I'm missing from what I've trying and seeing above?
iPhones can do TTLS-PAP which gives you the passwords in the clear. Comment out mschap in your EAP config to disallow negotiation of mschap, they'll try something else...
2. Is GTC and PAP with encrypted passwords less secure than using MSCHAPv2 with Plain text passwords in LDAP (even though they are on the same box)?
If you're serious about security EAP-TLS is the only method that's widely available and secure. PEAP and TTLS are pretty bad when used with PAP/GTC/MSCHAPv2 inners. They rely on the user correctly identifying the certificate presented by the RADIUS server as being genuine. It's not like HTTPS where you have at least have a domain you can check against the CN, with 802.1X you have nothing other than the SSID. If the user can't do that, then their password is effectively compromised. I heard rumours of an update to the EAP-PWD RFC that may allow salted passwords to be used. If that's correct, then the new version of EAP-PWD would be the only user-name/password based EAP method that was secure, and worked with hashed passwords.
3. Should Mac's be able to use GTC? I've read that with Cisco ISE, this can be force, but beyond that I couldn't come across any article discussing it.
Unsure, but in terms of functionality it's almost identical to TTLS-PAP which OSX does support. -Arran
Hi, I dont know if this is correct to do(arran or alan would comment on this), but if you change the default peap method to gtc rather than mschap both android and apple(keeping security as automatic) device work with gtc(ldap). BR, Anirudh Malhotra 8zero2 Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On 2 Feb 2016, 05:08 +0530, Arran Cudbard-Bell<a.cudbardb@freeradius.org>, wrote:
On Feb 1, 2016, at 6:09 PM, Greg Mischel Smith<gregms@gmail.com>wrote:
We're using currently using freeradius 2.x and migrating to a new server where we will be using 3.0.4.
Our OpenLDAP server has plaintext passwords currently, but as I migrate the server over, I would like to encrypt and salt them (something like SSHA). Both the LDAP and Radius servers will be on the same box.
The problem devices is our wireless clients made up of Macs and phones (Android and iPhone) and the traffic passes through a Cisco WLC.
If I want to encrypt, then it seems I would have to use EAP-GTC along with PAP. The Macs seem to only want to authenticate with MSCHAPv2. I found on Android phones if I don't set the Phase 2 authentication, it only checks MSCHAPv2, however if I force it to use GTC, then it authenticates correctly. I did notice in the logs using GTC, it has the ability to display the encrypted password in the clear. Didn't do this with MSCHAPv2.
So here are my questions: 1. Is there something I'm missing from what I've trying and seeing above?
iPhones can do TTLS-PAP which gives you the passwords in the clear.
Comment out mschap in your EAP config to disallow negotiation of mschap, they'll try something else...
2. Is GTC and PAP with encrypted passwords less secure than using MSCHAPv2 with Plain text passwords in LDAP (even though they are on the same box)?
If you're serious about security EAP-TLS is the only method that's widely available and secure.
PEAP and TTLS are pretty bad when used with PAP/GTC/MSCHAPv2 inners. They rely on the user correctly identifying the certificate presented by the RADIUS server as being genuine. It's not like HTTPS where you have at least have a domain you can check against the CN, with 802.1X you have nothing other than the SSID.
If the user can't do that, then their password is effectively compromised.
I heard rumours of an update to the EAP-PWD RFC that may allow salted passwords to be used. If that's correct, then the new version of EAP-PWD would be the only user-name/password based EAP method that was secure, and worked with hashed passwords.
3. Should Mac's be able to use GTC? I've read that with Cisco ISE, this can be force, but beyond that I couldn't come across any article discussing it.
Unsure, but in terms of functionality it's almost identical to TTLS-PAP which OSX does support.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 1, 2016, at 11:22 PM, Anirudh Malhotra <8zero2ops@gmail.com> wrote:
Hi,
I dont know if this is correct to do(arran or alan would comment on this), but if you change the default peap method to gtc rather than mschap both android and apple(keeping security as automatic) device work with gtc(ldap).
GTC in this case is the inner method. You can't use GTC as an outer method because it doesn't produce keying material. I believe there's an issue (Alan DeKok can confirm) in all released versions of FreeRADIUS that prevents a different EAP module being used for the inner tunnel. If you use v3.0.x or v3.1.x HEAD you should be able to configure an inner-eap instance of the EAP module, and set GTC as the default. -Arran
On Feb 2, 2016, at 9:51 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I believe there's an issue (Alan DeKok can confirm) in all released versions of FreeRADIUS that prevents a different EAP module being used for the inner tunnel.
No, it only affects people who proxy the inner EAP as non-EAP. And it mostly works even then. Alan DeKok.
Comment out mschap in your EAP config to disallow negotiation of mschap, they'll try something else...
That's what I would have thought, but when I try that, I get the following: (6) eap : Peer sent method Identity (1) (6) ERROR: eap : Tried to start unsupported method (26) (6) eap : Failed in EAP select (6) [eap] = invalid (6) } # authenticate = invalid (6) Failed to authenticate the user (6) Login incorrect (eap: Tried to start unsupported method (26)): [testuser<via Auth-Type = EAP>] (from client WLC port 0 via TLS tunnel) Happens on Android and Mac. I found that even if I set Android to use GTC, when I comment out the mschapv2 { } section in the eap config file, it fails. Looking at the debug on when it suceeds (without eapchapv2 commented out), it still uses eapchapv2 which makes me think that's why it fails. (6) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (6) authenticate { (6) eap : Peer sent method Identity (1) (6) eap : Calling eap_mschapv2 to process EAP data (6) eap_mschapv2 : Issuing Challenge ... (7) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (7) authenticate { (7) eap : Expiring EAP session with state 0xb11fa2d2b117b849 (7) eap : Finished EAP session with state 0xb11fa2d2b117b849 (7) eap : Previous EAP request found for state 0xb11fa2d2b117b849, released from the list (7) eap : Peer sent method NAK (3) (7) eap : Found mutually acceptable type GTC (6) (7) eap : Calling eap_gtc to process EAP data (7) eap_gtc : EXPAND Password: (7) eap_gtc : --> Password: (7) eap : New EAP session, adding 'State' attribute to reply 0xb11fa2d2b016a449
Did you try changing default peap version to gtc? BR, Anirudh Malhotra 8zero2 Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On 2 Feb 2016, 21:37 +0530, Greg Mischel Smith<gregms@gmail.com>, wrote:
Comment out mschap in your EAP config to disallow negotiation of mschap, they'll try something else...
That's what I would have thought, but when I try that, I get the following: (6) eap : Peer sent method Identity (1) (6) ERROR: eap : Tried to start unsupported method (26) (6) eap : Failed in EAP select (6) [eap] = invalid (6) } # authenticate = invalid (6) Failed to authenticate the user (6) Login incorrect (eap: Tried to start unsupported method (26)): [testuser<via Auth-Type = EAP>] (from client WLC port 0 via TLS tunnel)
Happens on Android and Mac. I found that even if I set Android to use GTC, when I comment out the mschapv2 { } section in the eap config file, it fails.
Looking at the debug on when it suceeds (without eapchapv2 commented out), it still uses eapchapv2 which makes me think that's why it fails. (6) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (6) authenticate { (6) eap : Peer sent method Identity (1) (6) eap : Calling eap_mschapv2 to process EAP data (6) eap_mschapv2 : Issuing Challenge ... (7) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (7) authenticate { (7) eap : Expiring EAP session with state 0xb11fa2d2b117b849 (7) eap : Finished EAP session with state 0xb11fa2d2b117b849 (7) eap : Previous EAP request found for state 0xb11fa2d2b117b849, released from the list (7) eap : Peer sent method NAK (3) (7) eap : Found mutually acceptable type GTC (6) (7) eap : Calling eap_gtc to process EAP data (7) eap_gtc : EXPAND Password: (7) eap_gtc : -->Password: (7) eap : New EAP session, adding 'State' attribute to reply 0xb11fa2d2b016a449 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 2, 2016, at 11:06 AM, Greg Mischel Smith <gregms@gmail.com> wrote:
Comment out mschap in your EAP config to disallow negotiation of mschap, they'll try something else...
That won't work. :( You should set "default_eap_type" to have the server start a particular EAP type. The client *should* either start that EAP type, or NAK it with a list of supported EAP types. In this case, you set "default_eap_type = mschapv2", but deleted the "mschapv2" from the "eap" section. That's confusing and wrong. Don't do that.
Happens on Android and Mac. I found that even if I set Android to use GTC, when I comment out the mschapv2 { } section in the eap config file, it fails.
Looking at the debug on when it suceeds (without eapchapv2 commented out), it still uses eapchapv2 which makes me think that's why it fails.
No. You told the server to start with EAP-MSCHAPv2. That's what it's doing. The client is NAKing that, and asking for GTC. Which should then work. But it's impossible to tell why it fails, because you didn't post the debug output where it fails. Alan DeKok.
You should set "default_eap_type" to have the server start a particular EAP type. The client *should* either start that EAP type, or NAK it with a list of supported EAP types.
In this case, you set "default_eap_type = mschapv2", but deleted the "mschapv2" from the "eap" section. That's confusing and wrong. Don't do that.
I had forgot to set the default in the PEAP section in this test (I had tried it before). In either case it doesn't work as it still provides the same error. But since Alan says that is a bad idea anyway, I left in the mschapv2 section in and I changed inside PEAP to "default_eap_type = gtc" in the eap file. Tunnel settings are both set to no (which I believe is default). Any other default settings I should try? When I have it like this, it just tries mschapv2, fails due to authentication problem (as my android puts it) and just keeps trying and failing. Again if I force it to use GTC on android, then it would work in this current config. rlm_ldap (ldap): Released connection (4) (7) [ldap] = ok (7) [expiration] = noop (7) [logintime] = noop (7) WARNING: pap : Auth-Type already set. Not setting to PAP (7) [pap] = noop (7) } # authorize = updated (7) Found Auth-Type = EAP (7) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (7) authenticate { (7) eap : Expiring EAP session with state 0x157f222d157738f9 (7) eap : Finished EAP session with state 0x157f222d157738f9 (7) eap : Previous EAP request found for state 0x157f222d157738f9, released from the list (7) eap : Peer sent method MSCHAPv2 (26) (7) eap : EAP MSCHAPv2 (26) (7) eap : Calling eap_mschapv2 to process EAP data (7) eap_mschapv2 : # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (7) eap_mschapv2 : Auth-Type MS-CHAP { (7) WARNING: mschap : No Cleartext-Password configured. Cannot create LM-Password (7) WARNING: mschap : No Cleartext-Password configured. Cannot create NT-Password (7) mschap : Creating challenge hash with username: testuser (7) mschap : Client is using MS-CHAPv2 (7) ERROR: mschap : FAILED: No NT/LM-Password. Cannot perform authentication (7) ERROR: mschap : MS-CHAP2-Response is incorrect (7) [mschap] = reject (7) } # Auth-Type MS-CHAP = reject (7) eap : Freeing handler (7) [eap] = reject (7) } # authenticate = reject (7) Failed to authenticate the user (7) Login incorrect (mschap: FAILED: No NT/LM-Password. Cannot perform authentication): [testuser/<via Auth-Type = EAP>] (from client WLC port 0 via TLS tunnel)
On Feb 2, 2016, at 12:11 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
Any other default settings I should try?
Tell the server what the "known good" password is for the user?
(7) eap_mschapv2 : Auth-Type MS-CHAP { (7) WARNING: mschap : No Cleartext-Password configured. Cannot create LM-Password (7) WARNING: mschap : No Cleartext-Password configured. Cannot create NT-Password (7) mschap : Creating challenge hash with username: testuser (7) mschap : Client is using MS-CHAPv2 (7) ERROR: mschap : FAILED: No NT/LM-Password. Cannot perform authentication
It's not like the server is TELLING YOU what's going wrong. Did you try configuring a Cleartext-Password for the user? No? Then how do you expect the server to authenticate the user? Did you try READING the instructions at the top of raddb/sites-available/inner-tunnel? No? Then go do that. If you can't get radtest to work as documented there, you won't be able to get PEAP to work. This is all documented. Alan Dekok.
On Tue, Feb 2, 2016 at 11:28 AM, Alan DeKok <aland@deployingradius.com> wrote:
(7) eap_mschapv2 : Auth-Type MS-CHAP { (7) WARNING: mschap : No Cleartext-Password configured. Cannot create LM-Password (7) WARNING: mschap : No Cleartext-Password configured. Cannot create NT-Password (7) mschap : Creating challenge hash with username: testuser (7) mschap : Client is using MS-CHAPv2 (7) ERROR: mschap : FAILED: No NT/LM-Password. Cannot perform authentication
It's not like the server is TELLING YOU what's going wrong.
Did you try configuring a Cleartext-Password for the user?
I'm sorry if I caused confusion, but getting this to work in plain/clear-text has never been an issue. Yes I've done plenty of radtest, I've read lots and lots of threads, but I was still having trouble and had specific questions so I came here. My desire is to use encrypted passwords in OpenLDAP and somehow make this work. GTC seems to be the only option but Android and Mac (in particular) keep trying to choose mschapv2. From the thread so far, I was getting the impression I should be able to make it work so that's what I was trying. Maybe I misunderstood, but I thought what was being said was to just set the default in the eap file in the PEAP section to GTC. But if I do an encrypted or unencrypted password, it tries mschapv2 first (despite the default in eap being set to GTC). Am what I'm doing practical and possible?
On Feb 2, 2016, at 4:06 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
I'm sorry if I caused confusion, but getting this to work in plain/clear-text has never been an issue. Yes I've done plenty of radtest, I've read lots and lots of threads, but I was still having trouble and had specific questions so I came here.
You should make it clear what you've done, and why. When you post a message where the server complains about "No Cleartext-Password", that makes it look like you haven't bothered reading the server output.
My desire is to use encrypted passwords in OpenLDAP and somehow make this work.
http://deployingradius.com/documents/protocols/compatibility.html This is pointed to from the Wiki, among other places.
GTC seems to be the only option but Android and Mac (in particular) keep trying to choose mschapv2.
Did you configure those systems to use GTC?
From the thread so far, I was getting the impression I should be able to make it work so that's what I was trying.
"Just make it work" is not a thing computers do.
Maybe I misunderstood, but I thought what was being said was to just set the default in the eap file in the PEAP section to GTC.
Yes. That works to set the default eap type. BUT the supplicant can ask for another EAP type.
But if I do an encrypted or unencrypted password, it tries mschapv2 first (despite the default in eap being set to GTC). Am what I'm doing practical and possible?
Yes. Configure the supplicant to use GTC. Configure the server to use GTC. If you just configure one end, it won't work. BOTH have to be set to use GTC. Alan DeKok.
On Tue, Feb 2, 2016 at 3:13 PM, Alan DeKok <aland@deployingradius.com> wrote:
GTC seems to be the only option but Android and Mac (in particular) keep trying to choose mschapv2.
Did you configure those systems to use GTC? If you just configure one end, it won't work. BOTH have to be set to use GTC.
On an Android phone, I can force it to use GTC and I can confirm it works. On a Mac, I can't figure out how to make it use GTC (though I've seen a screenshot of it online via freeradius discussion) so I know it is possible, I was just hoping someone on here either configured their mac to use GTC (via a MDM solution or something else). Judging by your last statement, the Mac is (sending?) mschap by default and it doesn't matter what freeradius is set to as it has to be configured on the Mac (or phones) to send/use GTC.
On Feb 2, 2016, at 5:15 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
On an Android phone, I can force it to use GTC and I can confirm it works. On a Mac, I can't figure out how to make it use GTC (though I've seen a screenshot of it online via freeradius discussion)
Apple updated their systems so that mere users cannot configure 802.1X / EAP. You *must* now use a mobile configuration tool. Alan DeKok.
On Tue, Feb 2, 2016 at 4:39 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 2, 2016, at 5:15 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
On an Android phone, I can force it to use GTC and I can confirm it works. On a Mac, I can't figure out how to make it use GTC (though I've seen a screenshot of it online via freeradius discussion)
Apple updated their systems so that mere users cannot configure 802.1X / EAP. You *must* now use a mobile configuration tool.
Alan DeKok.
I've been looking at the MDM solution Casper from Jamf (as I've used it before), however It's only options are: TLS, TTLS, LEAP, PEAP, EAP-FAST, EAP-SIM and EAP-AKA. Didn't seem to work either. Anyone have any luck with this or other MDM ideas? Again if EAP-GTC isn't a suggestion option, I'm open to others.
I've been looking at the MDM solution Casper from Jamf (as I've used it before), however It's only options are: TLS, TTLS, LEAP, PEAP, EAP-FAST, EAP-SIM and EAP-AKA. Didn't seem to work either. Anyone have any luck with this or other MDM ideas? Again if EAP-GTC isn't a suggestion option, I'm open to others.
Sorry, this might be a stupid question... Do you have any specific options in TTLS to set an inner auth method? If so, what precludes you from using EAP-TTLS (since that's supported by both the Android and Mac/iOS operating systems)? With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Greg i have tested apple phones on GTC if the default is set to gtc it does work! BR, Anirudh Malhotra 8zero2 Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On 3 Feb 2016, 15:10 +0530, Stefan Paetow<Stefan.Paetow@jisc.ac.uk>, wrote:
I've been looking at the MDM solution Casper from Jamf (as I've used it before), however It's only options are: TLS, TTLS, LEAP, PEAP, EAP-FAST, EAP-SIM and EAP-AKA. Didn't seem to work either. Anyone have any luck with this or other MDM ideas? Again if EAP-GTC isn't a suggestion option, I'm open to others.
Sorry, this might be a stupid question... Do you have any specific options in TTLS to set an inner auth method? If so, what precludes you from using EAP-TTLS (since that's supported by both the Android and Mac/iOS operating systems)?
With Regards
Stefan Paetow Moonshot Industry&Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet
jisc.ac.uk
Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, Feb 3, 2016 at 3:40 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Sorry, this might be a stupid question... Do you have any specific options in TTLS to set an inner auth method? If so, what precludes you from using EAP-TTLS (since that's supported by both the Android and Mac/iOS operating systems)?
Honestly, I haven't looked much at EAP-TTLS yet, but am starting to. If I understand correctly, this tends to be more certificate based authentication. We have a lot of personal cell phones. My presumption would be that we would have to load certificates onto these devices, is that correct? If that will get us around our problem, I'm open to that, but prefer not due to complexity. I'm just starting to look for documentations suggesting how to do this. It would be going through a Cisco WLC. I'm seeing EAP-TLS option on the WLC, but nothing specific with EAP-TTLS. And in all honesty, if freeradius isn't the best solution for what we're trying to do, if we need to purchase something like Cisco ACS, that would be on the table, I just know having OpenLDAP with plaintext passwords just isn't an option (even with ACL's on them).
On Feb 3, 2016, at 12:31 PM, Greg Mischel Smith <gregms@gmail.com> wrote:
Honestly, I haven't looked much at EAP-TTLS yet, but am starting to. If I understand correctly, this tends to be more certificate based authentication.
No. EAP-TLS requires client certs. EAP-TTLS does not.
We have a lot of personal cell phones. My presumption would be that we would have to load certificates onto these devices, is that correct?
No.
If that will get us around our problem, I'm open to that, but prefer not due to complexity. I'm just starting to look for documentations suggesting how to do this. It would be going through a Cisco WLC. I'm seeing EAP-TLS option on the WLC, but nothing specific with EAP-TTLS.
You shouldn't need to configure the access point for EAP-TLS versus EAP-TTLS. They should all just work.
And in all honesty, if freeradius isn't the best solution for what we're trying to do,
FreeRADIUS is a RADIUS server. It doesn't manage 802.1X configurations on user machines. FreeRADIUS does more, and is more flexible than any commercial RADIUS server.
if we need to purchase something like Cisco ACS, that would be on the table, I just know having OpenLDAP with plaintext passwords just isn't an option (even with ACL's on them).
http://deployingradius.com/documents/protocols/compatibility.html That table outlines the limitations for *all* RADIUS servers. These limitations are determined by the authentication method, not by the RADIUS server implementation. You will run into identical limitations with ACS. Their sales people may lie to you, but we won't. Alan DeKok.
On Wed, Feb 3, 2016 at 12:02 PM, Michael Ströder <michael@stroeder.com> wrote:
Greg Mischel Smith wrote:
I just know having OpenLDAP with plaintext passwords just isn't an option (even with ACL's on them).
Then the only possible method is EAP-TTLS with inner PAP independent of the RADIUS server. And it's not hard to setup.
Thank you for your suggestions/clarification Michael. I tested out EAP-TTLS yesterday and today and I finally got something working. Solution appears to be EAP-TTLS w/ GTC as the inner. When I tried the default of PAP as the inner, I found that the devices where were still trying to use mschapv2. However when GTC is set as the ttls default, mschapv2 works whether it is commented out or not. I've tested it on Mac, Android and iPhone and the only one that needed adjusting was Android as I had to change from default of PEAP to TTLS. I can leave the inner empty and it will auto choose GTC on Android. I feel it is finally working as is (without many modifications to the config), it is a very good feeling.
Thank you for your suggestions/clarification Michael. I tested out EAP-TTLS yesterday and today and I finally got something working.
Whoo!
Solution appears to be EAP-TTLS w/ GTC as the inner.
Brilliant! Good to know it now works. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
participants (6)
-
Alan DeKok -
Anirudh Malhotra -
Arran Cudbard-Bell -
Greg Mischel Smith -
Michael Ströder -
Stefan Paetow