Hi, I've spent too much time trying to fix this issue and going nowhere... I am trying to make MACHINE auth working on Windows/CiscoWLC and Freeradius. I have no problem with USER auth. The certificate is fine, I've created it using xpextension. I've also tried a Windows-CA certificate. I've also tried MACHINE auth with IAS and it's working. I've upgraded the WLC to 7.0.0.116, I was at 6.0.199-4 before. Why is it working with USER auth but not MACHINE auth ? Could someone give me some direction ? Thanks! Here's some logs: rad_recv: Access-Request packet from host 10.10.1.1 port 32770, id=58, length=280 User-Name = "host/MININT-EC23NBT.domain.local" Calling-Station-Id = "b4-74-9f-9d-55-fb" Called-Station-Id = "00-25-84-23-52-60:SSID--Secure" NAS-Port = 1 Cisco-AVPair = "audit-session-id=0132800a0000005618faa74e" NAS-IP-Address = 10.10.1.1 NAS-Identifier = "Controller-WLC2125" Airespace-Wlan-Id = 5 Service-Type = Framed-User Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0202002801686f73742f4d494e494e542d454332334e42542e6373646573696c65732e71632e6361 Message-Authenticator = 0x5b1e2e25b76f1f348cb1bb62b94b2d43 server peap { # Executing section authorize from file /etc/raddb/sites-enabled/peap +- entering group authorize {...} [suffix] No '@' in User-Name = "host/MININT-EC23NBT.domain.local", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[preprocess] returns ok [eap] EAP packet type response id 2 length 40 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/peap +- entering group authenticate {...} [eap] EAP Identity [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] returns handled } # server peap Sending Access-Challenge of id 58 to 10.10.1.1 port 32770 EAP-Message = 0x010300061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd4ade9e4d4aef086c00dbb7516145db0 Finished request 232. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10.10.1.1 port 32770, id=59, length=395 User-Name = "host/MININT-EC23NBT.domain.local" Calling-Station-Id = "b4-74-9f-9d-55-fb" Called-Station-Id = "00-25-84-23-52-60:SSID--Secure" NAS-Port = 1 Cisco-AVPair = "audit-session-id=0132800a0000005618faa74e" NAS-IP-Address = 10.10.1.1 NAS-Identifier = "Controller-WLC2125" Airespace-Wlan-Id = 5 Service-Type = Framed-User Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0203008919800000007f160301007a0100007603014ea7fa1c69583120e18e33c7779ea4d03e42e8b960079d8f36ab746be5bb345a20512d0000ccfbf8a28c0c5d27fb46eac23b913c638cc133e76aa06671c2dca9bd0018002f00350005000ac013c014c009c00a003200380013000401000015ff01000100000a0006000400170018000b00020100 State = 0xd4ade9e4d4aef086c00dbb7516145db0 Message-Authenticator = 0xde1ff14a20623ba0cc79cb552d264947 server peap { # Executing section authorize from file /etc/raddb/sites-enabled/peap +- entering group authorize {...} [suffix] No '@' in User-Name = "host/MININT-EC23NBT.domain.local", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[preprocess] returns ok [eap] EAP packet type response id 3 length 137 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/peap +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS TLS Length 127 [peap] Length Included [peap] eaptls_verify returned 11 [peap] (other): before/accept initialization [peap] TLS_accept: before/accept initialization [peap] <<< TLS 1.0 Handshake [length 007a], ClientHello [peap] TLS_accept: SSLv3 read client hello A [peap] >>> TLS 1.0 Handshake [length 0031], ServerHello [peap] TLS_accept: SSLv3 write server hello A [peap] >>> TLS 1.0 Handshake [length 037c], Certificate [peap] TLS_accept: SSLv3 write certificate A [peap] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [peap] TLS_accept: SSLv3 write server done A [peap] TLS_accept: SSLv3 flush data [peap] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [peap] eaptls_process returned 13 [peap] EAPTLS_HANDLED ++[eap] returns handled } # server peap Sending Access-Challenge of id 59 to 10.10.1.1 port 32770 EAP-Message = 0x010403c6190016030100310200002d03014ea7fa24d1353592fe67e3ae98e501bbfbe366dc12f730a1d2ab15d1efcc9f3200002f000005ff01000100160301037c0b0003780003750003723082036e30820256a003020102020106300d06092a864886f70d01010505003075310b3009060355040613024341310b3009060355040813025143310c300a0603550407130345444e310c300a060355040a13034353493123302106092a864886f70d010901161474656368406373646573696c65732e71632e6361311830160603550403130f435349205061636b657466656e6365301e170d3131313032353233333930315a170d313131323234323333 EAP-Message = 0x3930315a3067310b3009060355040613024341310b3009060355040813025143310c300a060355040a1303435349311830160603550403130f435349205061636b657466656e63653123302106092a864886f70d010901161474656368406373646573696c65732e71632e636130820122300d06092a864886f70d01010105000382010f003082010a0282010100e8cae5b4a5b06ec6aea8b6e32c4490762772310d87985ea3d1bbf2632aafebd9b0ae70a615a77b3b8ef2dd985df3e54149b1d1bb0842e410c68dfa55ce176371db376a3bb1918d966ad140310224c4b510015ce15973537048a8e997bb2c7d21c2f57e99f90c1dbc3c584822f0d8bb EAP-Message = 0x1178343ddbcf2842aa1b17642bd60d545f3b505d1b1594e2981d472186df3b9132536b8a558f1836dd11039a3337886ab301b49de79ae5597f9958f030671aa3e47cae50f69e8008687492b3a97adc24111269da2585fc488943555520870007669e31550ea255fb9af4394cdae03ceadbffb29f2fafb0d16c47f57174fbaa4986e9749cdecb2fc33fd6886099f1538e670203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101050500038201010053b69c137577d12947a7f63b7617b0ace3133df2048831b206c42751a63d48c1ca0802fa0b3aee3df03a6030848f9ed9d8370a3901bf4498e829 EAP-Message = 0xba37da6f48fb4f6aec7fee62fe06d36a11c2a13f94f188c1165c2ea8d0865cd5283462ec76c3de3df37967d94d9224425b8ea7921f8033711b4430ef1943ff29db366b7a0e6bdab6ddcdede222e7f3642fb886a3eea1316ed7ede26b8aa1dcdc7b4bcb6fefae97ba9c0eec9750bd45cf29e93be3b58b2534ba203f11b9e9a4b05980c844cebf79044f17f3f08797d9b912de8fc1cec712e42c2c87189817d456bcb3469c0043306504f2d58e779fc810a75d8d5784b54ce4c351188d50cd052b618d28d0461516030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd4ade9e4d5a9f086c00dbb7516145db0 Finished request 233. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 10.10.1.1 port 32770, id=60, length=264 User-Name = "host/MININT-EC23NBT.domain.local" Calling-Station-Id = "b4-74-9f-9d-55-fb" Called-Station-Id = "00-25-84-23-52-60:SSID--Secure" NAS-Port = 1 Cisco-AVPair = "audit-session-id=0132800a0000005618faa74e" NAS-IP-Address = 10.10.1.1 NAS-Identifier = "Controller-WLC2125" Airespace-Wlan-Id = 5 Service-Type = Framed-User Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020400061900 State = 0xd4ade9e4d5a9f086c00dbb7516145db0 Message-Authenticator = 0x3f92eaba33074a895121d2885b384802 server peap { # Executing section authorize from file /etc/raddb/sites-enabled/peap +- entering group authorize {...} [suffix] No '@' in User-Name = "host/MININT-EC23NBT.domain.local", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[preprocess] returns ok [eap] EAP packet type response id 4 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/raddb/sites-enabled/peap +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS [peap] Received TLS ACK [peap] ACK handshake fragment handler [peap] eaptls_verify returned 1 [peap] eaptls_process returned 13 [peap] EAPTLS_HANDLED ++[eap] returns handled } # server peap Sending Access-Challenge of id 60 to 10.10.1.1 port 32770 EAP-Message = 0x010500061900 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd4ade9e4d6a8f086c00dbb7516145db0 Finished request 234. Going to the next request Waking up in 4.9 seconds. Cleaning up request 232 ID 58 with timestamp +4714 Cleaning up request 233 ID 59 with timestamp +4714 Cleaning up request 234 ID 60 with timestamp +4714 WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0xd4ade9e4d6a8f086 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Ready to process requests.
On 26/10/11 13:49, Bonald wrote:
WARNING: !! EAP session for state 0xd4ade9e4d6a8f086 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility
Did you follow the link? Did you read it? Most likely, you need to ensure your certificate CA is trusted by the machine store, as well as the user store(s)
Yes i've read it. Yes the certificate is trusted on the machine and the user store. It must be something else, using USER auth it's working. MACHINE auth is failling. On Wed, Oct 26, 2011 at 10:14 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/10/11 13:49, Bonald wrote:
WARNING: !! EAP session for state 0xd4ade9e4d6a8f086 did not finish! WARNING: !! Please read http://wiki.freeradius.org/Certificate_Compatibility
Did you follow the link? Did you read it?
Most likely, you need to ensure your certificate CA is trusted by the machine store, as well as the user store(s) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 26/10/11 14:24, Bonald wrote:
Yes i've read it. Yes the certificate is trusted on the machine and the user store.
It must be something else, using USER auth it's working. MACHINE auth is failling.
Well, I guess it's just broken then. Oh well. Seriously - it's important to understand that the CLIENT stops responding. FreeRADIUS can't do anything more in this case - the client has stopped sending EAPOL packets, so the client must think that something is wrong. You will have to debug the client. This is very very painful on Windows; it's hard to even find the EAPOL debugging options, let alone interpret the results. Good luck.
Phil Mayers wrote:
Seriously - it's important to understand that the CLIENT stops responding. FreeRADIUS can't do anything more in this case - the client has stopped sending EAPOL packets, so the client must think that something is wrong.
That's the main issue people have with RADIUS. The client is in charge of pretty much everything, and few people understand that. Q: Why does the client stop talking to the server? A: Because it doesn't like the response from the server Q: OK... *what* part of the response doesn't it like? A: Go ask the client Q: But I can't! What do I do? A: well... we don't know, either. Go ask Microsoft.
You will have to debug the client. This is very very painful on Windows; it's hard to even find the EAPOL debugging options, let alone interpret the results.
Yes. Everyone reading this list should understand CLIENT issues cause you to debug the CLIENT. If the server returns the wrong thing... you can fix the server. Fort pretty much everything else, blame the client. Alan DeKok.
This kind of Q&A thing helps no one here! Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
Date: Wed, 26 Oct 2011 15:36:19 +0200 From: aland@deployingradius.com To: freeradius-users@lists.freeradius.org Subject: Re: PEAP with Machine auth
Phil Mayers wrote:
Seriously - it's important to understand that the CLIENT stops responding. FreeRADIUS can't do anything more in this case - the client has stopped sending EAPOL packets, so the client must think that something is wrong.
That's the main issue people have with RADIUS. The client is in charge of pretty much everything, and few people understand that.
Q: Why does the client stop talking to the server? A: Because it doesn't like the response from the server
Q: OK... *what* part of the response doesn't it like? A: Go ask the client
Q: But I can't! What do I do? A: well... we don't know, either. Go ask Microsoft.
You will have to debug the client. This is very very painful on Windows; it's hard to even find the EAPOL debugging options, let alone interpret the results.
Yes. Everyone reading this list should understand CLIENT issues cause you to debug the CLIENT.
If the server returns the wrong thing... you can fix the server. Fort pretty much everything else, blame the client.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 26/10/11 14:47, Sergio NNX wrote:
This kind of Q&A thing helps no one here! Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
In earnest: What exactly would you like us to do? Be specific. Bear in mind that no-one is paid to offer help here. If you can reproduce the problem reliably, then do so. Carefully document the configs that work under 1.1.7, and fail under 2.1.12, including the client configuration. Give that information to the list, and I'm sure if people are interested, they will take a look. If no-one is interested, you should start investigating the problem yourself - FreeRADIUS is open source. If you lack the skills locally, hire a contractor. I will try to find some time today to test machine auth.
On 26/10/11 14:58, Phil Mayers wrote:
On 26/10/11 14:47, Sergio NNX wrote:
This kind of Q&A thing helps no one here! Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
In earnest: What exactly would you like us to do? Be specific. Bear in mind that no-one is paid to offer help here.
If you can reproduce the problem reliably, then do so. Carefully document the configs that work under 1.1.7, and fail under 2.1.12, including the client configuration. Give that information to the list, and I'm sure if people are interested, they will take a look.
If no-one is interested, you should start investigating the problem yourself - FreeRADIUS is open source. If you lack the skills locally, hire a contractor.
I will try to find some time today to test machine auth.
Sorry, this is long. tl;dr version - under Windows 7, if you import the CA certificate into the "Trusted Root Certification Authorities" hierarchy in the MMC "Certificates" snap-in, Windows 7 user- and machine-auth work just fine against an out-of-the-box FreeRADIUS 2.1.12 with only two minor changes. It works for me. === I have just tested machine auth on a Windows 7 client. Everything works as I expected. Using an out-of-the-box FreeRADIUS 2.1.12 install and default configs, I made two changes: 1. Edit "modules/mschap" to enable the "ntlm_auth" helper like so: ntlm_auth = "... --username=%{mschap:User-Name} ..." 2. Edit "clients.conf" to add an entry for the switch I then started FreeRADIUS, and it auto-generated the certificates. I then tried a sequence of things on the Windows client. First - open the "services" MMC snap-in, and start (and set to auto-start) the "Wired autoconfig" service Second - open the network adapter list, right-click on the wired adapter, and enable authentication using the default settings (PEAP, MSCHAP inner) except that I unchecked "use my windows domain login / password" I then enabled 802.1x on the port facing the machine. == 1st auth == Failed. Client did the TLS negotiation, and returned the following error to FreeRADIUS: [peap] <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca SSL: SSL_read failed inside of TLS (-1), TLS session fails. This is expected; we haven't yet imported the client cert into the certificate store. == 2nd auth == Copy the "ca.cer" file onto the client, double-click on it, follow the prompts using the defaults. This didn't work - the client did not import the cert, despite appearing to, so auth again failed. == 3rd auth == Open "mmc", add the "Certificates" snap-in for "My user account". In the snap-in, expand the "Trusted Root Certification Authorities" folder, and right click on the "Certificates" child - select "All Tasks", "Import...". Browse to the cert & import it. You will be prompted saying "Windows cannot verify ..." - click OK. You should now see the example cert in the list. Re-start the 802.1x auth (unplug/reconnect). You will be prompted for a username/password, as before - this time, auth will succeed. == 4th auth == Return to the network adapter settings. Right-click, select properties. Go to the Authentication tab, select "Additional settings", and tick the "Specify authentication mode" box, and select "Computer authentication" from the drop-down. The machine will re-authenticate and, as expected, fail with a bad CA alert: [peap] <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca == 5th auth == Return to the "mmc" window; add the "Certificates" snap-in for the computer account. Again, expand "Trusted Root Certification Authorities" and right-click on "Certificates" and select "All tasks", "Import..". Browse to the "ca.cer" and import it. Re-start authentication. Authentication will work.
On 26/10/11 16:14, Phil Mayers wrote:
Sorry, this is long.
tl;dr version - under Windows 7, if you import the CA certificate into the "Trusted Root Certification Authorities" hierarchy in the MMC "Certificates" snap-in, Windows 7 user- and machine-auth work just fine against an out-of-the-box FreeRADIUS 2.1.12 with only two minor changes.
It works for me.
I've also tested the "802.1x single sign-on" functionality in Windows 7. Again, with the certs in the appropriate place, this just works. The machine authenticates as itself - host/name.domain.com - and when you enter your username/password, it de-auths and re-auths as "DOM\user"
If you are using the default config then your eap.conf must have default_eap_type = md5 Try with peap. On Wed, Oct 26, 2011 at 12:14 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/10/11 14:58, Phil Mayers wrote:
On 26/10/11 14:47, Sergio NNX wrote:
This kind of Q&A thing helps no one here! Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
In earnest: What exactly would you like us to do? Be specific. Bear in mind that no-one is paid to offer help here.
If you can reproduce the problem reliably, then do so. Carefully document the configs that work under 1.1.7, and fail under 2.1.12, including the client configuration. Give that information to the list, and I'm sure if people are interested, they will take a look.
If no-one is interested, you should start investigating the problem yourself - FreeRADIUS is open source. If you lack the skills locally, hire a contractor.
I will try to find some time today to test machine auth.
Sorry, this is long.
tl;dr version - under Windows 7, if you import the CA certificate into the "Trusted Root Certification Authorities" hierarchy in the MMC "Certificates" snap-in, Windows 7 user- and machine-auth work just fine against an out-of-the-box FreeRADIUS 2.1.12 with only two minor changes.
It works for me.
===
I have just tested machine auth on a Windows 7 client. Everything works as I expected. Using an out-of-the-box FreeRADIUS 2.1.12 install and default configs, I made two changes:
1. Edit "modules/mschap" to enable the "ntlm_auth" helper like so:
ntlm_auth = "... --username=%{mschap:User-Name} ..."
2. Edit "clients.conf" to add an entry for the switch
I then started FreeRADIUS, and it auto-generated the certificates. I then tried a sequence of things on the Windows client.
First - open the "services" MMC snap-in, and start (and set to auto-start) the "Wired autoconfig" service
Second - open the network adapter list, right-click on the wired adapter, and enable authentication using the default settings (PEAP, MSCHAP inner) except that I unchecked "use my windows domain login / password"
I then enabled 802.1x on the port facing the machine.
== 1st auth ==
Failed. Client did the TLS negotiation, and returned the following error to FreeRADIUS:
[peap] <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca SSL: SSL_read failed inside of TLS (-1), TLS session fails.
This is expected; we haven't yet imported the client cert into the certificate store.
== 2nd auth ==
Copy the "ca.cer" file onto the client, double-click on it, follow the prompts using the defaults. This didn't work - the client did not import the cert, despite appearing to, so auth again failed.
== 3rd auth ==
Open "mmc", add the "Certificates" snap-in for "My user account". In the snap-in, expand the "Trusted Root Certification Authorities" folder, and right click on the "Certificates" child - select "All Tasks", "Import...". Browse to the cert & import it. You will be prompted saying "Windows cannot verify ..." - click OK.
You should now see the example cert in the list.
Re-start the 802.1x auth (unplug/reconnect).
You will be prompted for a username/password, as before - this time, auth will succeed.
== 4th auth ==
Return to the network adapter settings. Right-click, select properties. Go to the Authentication tab, select "Additional settings", and tick the "Specify authentication mode" box, and select "Computer authentication" from the drop-down.
The machine will re-authenticate and, as expected, fail with a bad CA alert:
[peap] <<< TLS 1.0 Alert [length 0002], fatal unknown_ca TLS Alert read:fatal:unknown CA TLS_accept: failed in SSLv3 read client certificate A rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
== 5th auth ==
Return to the "mmc" window; add the "Certificates" snap-in for the computer account. Again, expand "Trusted Root Certification Authorities" and right-click on "Certificates" and select "All tasks", "Import..". Browse to the "ca.cer" and import it.
Re-start authentication. Authentication will work. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 26/10/11 16:54, Bonald wrote:
If you are using the default config then your eap.conf must have default_eap_type = md5
Yes. The client NAKs the EAP-MD5 and asks for PEAP.
Try with peap.
Just to placate you, I have done so. It made no difference, except save one round-trip. User- and machine-based auth as well as single signon still both work. The default EAP type is just that - the default. If you have the client set up to use PEAP, it will NAK the MD5 and ask for EAP, and the server will honour it. Again: It is important that you understand authentication is driven by the CLIENT.
Hi,
This kind of Q&A thing helps no one here! I think it does...
Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others! Even more weird, we have had the same issue lately with one controller model, and not the other. We were using the same config on the client, on the server, and the same certs.
I also tend to blame the client tho, maybe EAP is now more strict on the server side? If you can point us a doc to enable the EAP debug under windows, I am sure many people (even myself) would be glad to troubleshoot.
Date: Wed, 26 Oct 2011 15:36:19 +0200 From: aland@deployingradius.com To: freeradius-users@lists.freeradius.org Subject: Re: PEAP with Machine auth
Phil Mayers wrote:
Seriously - it's important to understand that the CLIENT stops responding. FreeRADIUS can't do anything more in this case - the client has stopped sending EAPOL packets, so the client must think that something is wrong.
That's the main issue people have with RADIUS. The client is in charge of pretty much everything, and few people understand that.
Q: Why does the client stop talking to the server? A: Because it doesn't like the response from the server
Q: OK... *what* part of the response doesn't it like? A: Go ask the client
Q: But I can't! What do I do? A: well... we don't know, either. Go ask Microsoft.
You will have to debug the client. This is very very painful on Windows; it's hard to even find the EAPOL debugging options, let alone interpret the results.
Yes. Everyone reading this list should understand CLIENT issues cause you to debug the CLIENT.
If the server returns the wrong thing... you can fix the server. Fort pretty much everything else, blame the client.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
Francois Gaudreault wrote:
Even more weird, we have had the same issue lately with one controller model, and not the other. We were using the same config on the client, on the server, and the same certs.
Ouch. The whole EAP ecosystem is fragile to the point of insanity. There are times when I'm surprised it works at *all*.
I also tend to blame the client tho, maybe EAP is now more strict on the server side? If you can point us a doc to enable the EAP debug under windows, I am sure many people (even myself) would be glad to troubleshoot.
The server side of EAP has changed a bit... but not much. Most of the changes to EAP are really the SSL stuff inside of OpenSSL, which we don't control. Alan DeKok.
Even more weird, we have had the same issue lately with one controller model, and not the other. We were using the same config on the client, on the server, and the same certs. Ouch. The whole EAP ecosystem is fragile to the point of insanity.
There are times when I'm surprised it works at *all*. You bet. It was two controller from the same manufacturer, just different model/firmware :S
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
Sergio NNX wrote:
This kind of Q&A thing helps no one here!
Nonsense. Explaining WHAT is going on, and WHY it's difficult for us to help you is useful.
Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
You want me to spend more time contributing? Right... I don't need to sleep or eat. If what you say is true (older versions work), then *you* can contribute. Build each version of the server until you find that version X works, and version X+1 doesn't. I don't have the Windows machines for these tests, so I can't do them. Only you can. Go ahead. Contribute. Do what you ask others to do. I'm waiting. Alan DeKok.
Ok, I have been watching your discourse from afar and I have to say this:
This kind of Q&A thing helps no one here! ...
Two things. Number one, he IS answering your questions. He is just not GIVING you the answer. Number two, the gentleman in question is quite possibly the preeminent FreeRADIUS expert in the world. When he tells you something about FreeRADIUS, you should listen. Sorry, I am not trying to be too blunt. But when an expert speaks, you should listen. This is true in any area. Jake Sallee Godfather of Bandwidth System Engineer University of Mary Hardin-Baylor 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221 From: freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org [mailto:freeradius-users-bounces+jake.sallee=umhb.edu@lists.freeradius.org] On Behalf Of Sergio NNX Sent: Wednesday, October 26, 2011 8:47 AM To: freeradius-users@lists.freeradius.org Subject: RE: PEAP with Machine auth This kind of Q&A thing helps no one here! Many people are reporting the same issue on different platforms! I don't think the problem is either with the client or the certificates since I conducted some testing using the same client and the same certificates but an old FR version (1.1.7) and the tests pass. It's easier to blame something else but we could spend that time contributing to the solution and so helping others!
Date: Wed, 26 Oct 2011 15:36:19 +0200 From: aland@deployingradius.com<mailto:aland@deployingradius.com> To: freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org> Subject: Re: PEAP with Machine auth
Phil Mayers wrote:
Seriously - it's important to understand that the CLIENT stops responding. FreeRADIUS can't do anything more in this case - the client has stopped sending EAPOL packets, so the client must think that something is wrong.
That's the main issue people have with RADIUS. The client is in charge of pretty much everything, and few people understand that.
Q: Why does the client stop talking to the server? A: Because it doesn't like the response from the server
Q: OK... *what* part of the response doesn't it like? A: Go ask the client
Q: But I can't! What do I do? A: well... we don't know, either. Go ask Microsoft.
You will have to debug the client. This is very very painful on Windows; it's hard to even find the EAPOL debugging options, let alone interpret the results.
Yes. Everyone reading this list should understand CLIENT issues cause you to debug the CLIENT.
If the server returns the wrong thing... you can fix the server. Fort pretty much everything else, blame the client.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 26/10/11 14:24, Bonald wrote:
Yes i've read it. Yes the certificate is trusted on the machine and the user store.
It must be something else, using USER auth it's working. MACHINE auth is failling.
What is the client operating system and version, including service pack? Are you using the built-in operating system supplicant, or a 3rd-party supplicant?
On 26/10/11 17:15, Phil Mayers wrote:
On 26/10/11 14:24, Bonald wrote:
Yes i've read it. Yes the certificate is trusted on the machine and the user store.
It must be something else, using USER auth it's working. MACHINE auth is failling.
What is the client operating system and version, including service pack?
Are you using the built-in operating system supplicant, or a 3rd-party supplicant?
Also, if you can (unicast, if you want) show the "netsh lan show profile" output from a command prompt please?
Client is Windows7 w/SP1. Using Cisco PEAP it's working. When using Microsoft PEAP it's failing for machine auth. I am on WLAN "netsh wlan show profile" just shows my SSID That fixed my problem. I needed to check the correct CA in the protected PEAP properties. http://www.letu.edu/it/faq/article/AA-00414/0/What-should-I-do-if-I-get-the-... thanks On Wed, Oct 26, 2011 at 1:59 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/10/11 17:15, Phil Mayers wrote:
On 26/10/11 14:24, Bonald wrote:
Yes i've read it. Yes the certificate is trusted on the machine and the user store.
It must be something else, using USER auth it's working. MACHINE auth is failling.
What is the client operating system and version, including service pack?
Are you using the built-in operating system supplicant, or a 3rd-party supplicant?
Also, if you can (unicast, if you want) show the "netsh lan show profile" output from a command prompt please? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Correct me if I am wrong, but that should not be needed when you are not validating server certificate. That would mean windows is trying to validate server cert when doing machine auth even if the profile says otherwise?? On 11-10-26 2:36 PM, Bonald wrote:
Client is Windows7 w/SP1. Using Cisco PEAP it's working. When using Microsoft PEAP it's failing for machine auth.
I am on WLAN "netsh wlan show profile" just shows my SSID
That fixed my problem. I needed to check the correct CA in the protected PEAP properties. http://www.letu.edu/it/faq/article/AA-00414/0/What-should-I-do-if-I-get-the-...
thanks
On Wed, Oct 26, 2011 at 1:59 PM, Phil Mayers<p.mayers@imperial.ac.uk> wrote:
On 26/10/11 17:15, Phil Mayers wrote:
On 26/10/11 14:24, Bonald wrote:
Yes i've read it. Yes the certificate is trusted on the machine and the user store.
It must be something else, using USER auth it's working. MACHINE auth is failling. What is the client operating system and version, including service pack?
Are you using the built-in operating system supplicant, or a 3rd-party supplicant?
Also, if you can (unicast, if you want) show the "netsh lan show profile" output from a command prompt please? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Francois Gaudreault, ing. jr fgaudreault@inverse.ca :: +1.514.447.4918 (x130) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)
On 10/26/2011 07:53 PM, Francois Gaudreault wrote:
Correct me if I am wrong, but that should not be needed when you are not validating server certificate.
There are a few issues; let me try to lay them out. First: it seems you MUST install the CA on the client (in one or both of the user or machine store, depending on whether you're doing user or machine-based auth). Authentication will simply fail if you don't install the CA - although helpfully Windows does seem to send an "invalid CA" TLS alert. Second: If (and only if) you install the CA, then when you FIRST connect to a network, you will be shown the dialog box "The connection attempt could not be completed". In my testing, if you click "Continue", then windows will: a. Check the "Validate server certificate" b. Leave the "Connect to these servers" (hostname/CN) blank c. Check the box next to the CA cert That is, windows will "trust on first use" (TOFU) the *specific* CA for that *specific* connection profile (WLAN SSID or Wired "profile"). The text at the link given by the OP is misleading. The issue is not whether the CA is a "Trusted" CA on the machine/user store as a whole. It's whether it's trusted for *that specific connection* as a CA for signing the authentication server cert. I'm unsure whether the OP is clicking "Continue" at the prompt and it's failing, or if he's not clicking "Continue" or not even being presented with the option - but as I say, in my testing, TOFU works.
The weird thing is that I didn't see that popup On Wed, Oct 26, 2011 at 5:07 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 10/26/2011 07:53 PM, Francois Gaudreault wrote:
Correct me if I am wrong, but that should not be needed when you are not validating server certificate.
There are a few issues; let me try to lay them out.
First: it seems you MUST install the CA on the client (in one or both of the user or machine store, depending on whether you're doing user or machine-based auth). Authentication will simply fail if you don't install the CA - although helpfully Windows does seem to send an "invalid CA" TLS alert.
Second: If (and only if) you install the CA, then when you FIRST connect to a network, you will be shown the dialog box "The connection attempt could not be completed". In my testing, if you click "Continue", then windows will:
a. Check the "Validate server certificate" b. Leave the "Connect to these servers" (hostname/CN) blank c. Check the box next to the CA cert
That is, windows will "trust on first use" (TOFU) the *specific* CA for that *specific* connection profile (WLAN SSID or Wired "profile").
The text at the link given by the OP is misleading. The issue is not whether the CA is a "Trusted" CA on the machine/user store as a whole. It's whether it's trusted for *that specific connection* as a CA for signing the authentication server cert.
I'm unsure whether the OP is clicking "Continue" at the prompt and it's failing, or if he's not clicking "Continue" or not even being presented with the option - but as I say, in my testing, TOFU works. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 27/10/11 13:12, Bonald wrote:
The weird thing is that I didn't see that popup
That is very odd. I just tried this again; purged the CA from the User & Machine lists, deleted the wired 802.1x profile and re-connected. 1st time - no joy because the CA is unknown. Import the CA & retry and I get promoted to "Terminate" or "Connect". If I click "Connect", the 802.1x profile is altered to "trust" the CA. Maybe you have some windows Group Policy which is preventing you from being prompted?
Exactly, I have a GPO that's pushing some wireless profiles. When disabling this GPO I see the popup. On Thu, Oct 27, 2011 at 9:37 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 27/10/11 13:12, Bonald wrote:
The weird thing is that I didn't see that popup
That is very odd.
I just tried this again; purged the CA from the User & Machine lists, deleted the wired 802.1x profile and re-connected. 1st time - no joy because the CA is unknown. Import the CA & retry and I get promoted to "Terminate" or "Connect". If I click "Connect", the 802.1x profile is altered to "trust" the CA.
Maybe you have some windows Group Policy which is preventing you from being prompted? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 27/10/11 15:18, Bonald wrote:
Exactly, I have a GPO that's pushing some wireless profiles. When disabling this GPO I see the popup.
Sigh. I hate windows. I'm glad you've got it sorted out. If you find time to write some docs in the wiki that describe which GPO objects caused what behaviour, it might be useful for others in the future.
participants (6)
-
Alan DeKok -
Bonald -
Francois Gaudreault -
Phil Mayers -
Sallee, Stephen (Jake) -
Sergio NNX