|
Home > Archive > Radius Server > January 2006 > Cisco Aironet 1231 with IAS - Cannot authenticate Intel or Windows clients
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cisco Aironet 1231 with IAS - Cannot authenticate Intel or Windows clients
|
|
| Rad Billy 2006-01-05, 6:07 pm |
| Hello all,
I've just set up an IAS server on Win2k3 and a cisco Aironet 1231 AP.
I've setup an SSID with EAP as the Open authentication type. I am
using WPA with AES encryption.
I have several cisco Aironet clients with new cards and the latest ACU.
On these clients, I simply specified WPA2 encryption with PEAP and the
clients authenticate successfully to my IAS server and work on the
wireless network. Accounting on the radius server logs a success and
there is no problem. These machines are all running Win2k SP4.
However, I have additional machines running XP Pro SP2. These machines
have Intel 2200BG cards integrated. When I setup the Intel proset
utility with my SSID, WPA2 and PEAP, the machine fails to authenticate.
It connects to the AP and begins authentication then fails. I've also
disabled the Intel proset client and attempted to use the integrated
Wireless config in XP pro and that fails as well.
When either the intel or Windows clients attempt to authenticate, I
recieve the following event in event viewer:
---------------------------------------------------------------------------=
---
Event Type: Warning
Event Source: IAS
Event Category: None
Event ID: 2
Date: 1/5/2006
Time: 8:58:33 AM
User: N/A
Computer: monkey
Description:
User joshuaha was denied access.
Fully-Qualified-User-Name =3D fakedomain.local/HQ/Users/fake user
NAS-IP-Address =3D 172.21.230.53
NAS-Identifier =3D WAP123113
Called-Station-Identifier =3D 0016.469c.3310
Calling-Station-Identifier =3D 0013.ce54.64e5
Client-Friendly-Name =3D WAP123113
Client-IP-Address =3D 172.21.230.53
NAS-Port-Type =3D Wireless - IEEE 802.11
NAS-Port =3D 1703
Proxy-Policy-Name =3D Use Windows authentication for all users
Authentication-Provider =3D Windows
Authentication-Server =3D <undetermined>
Policy-Name =3D PEAP POLICY
Authentication-Type =3D PEAP
EAP-Type =3D <undetermined>
Reason-Code =3D 16
Reason =3D Authentication was not successful because an unknown user
name or incorrect password was used.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 21 03 07 80 !..=80
---------------------------------------------------------------------------=
---
The major difference in the event is that EAP-Type says "undetermined"
I've checked the RASTLS and RASCHAP debugs, but they are pretty
lengthy. I can post here if someone thinks they will help.
Any help will be greatly appreciated!!!
| |
| Ron Lowe 2006-01-05, 6:07 pm |
| "Rad Billy" <joshuahatten@gmail.com> wrote in message
news:1136480559.077472.276160@z14g2000cwz.googlegroups.com...
Hello all,
I've just set up an IAS server on Win2k3 and a cisco Aironet 1231 AP.
I've setup an SSID with EAP as the Open authentication type. I am
using WPA with AES encryption.
I have several cisco Aironet clients with new cards and the latest ACU.
On these clients, I simply specified WPA2 encryption with PEAP and the
clients authenticate successfully to my IAS server and work on the
wireless network. Accounting on the radius server logs a success and
there is no problem. These machines are all running Win2k SP4.
However, I have additional machines running XP Pro SP2. These machines
have Intel 2200BG cards integrated. When I setup the Intel proset
utility with my SSID, WPA2 and PEAP, the machine fails to authenticate.
It connects to the AP and begins authentication then fails. I've also
disabled the Intel proset client and attempted to use the integrated
Wireless config in XP pro and that fails as well.
When either the intel or Windows clients attempt to authenticate, I
recieve the following event in event viewer:
------------------------------------------------------------------------------
Event Type: Warning
Event Source: IAS
Event Category: None
Event ID: 2
Date: 1/5/2006
Time: 8:58:33 AM
User: N/A
Computer: monkey
Description:
User joshuaha was denied access.
Fully-Qualified-User-Name = fakedomain.local/HQ/Users/fake user
NAS-IP-Address = 172.21.230.53
NAS-Identifier = WAP123113
Called-Station-Identifier = 0016.469c.3310
Calling-Station-Identifier = 0013.ce54.64e5
Client-Friendly-Name = WAP123113
Client-IP-Address = 172.21.230.53
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 1703
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = PEAP POLICY
Authentication-Type = PEAP
EAP-Type = <undetermined>
Reason-Code = 16
Reason = Authentication was not successful because an unknown user
name or incorrect password was used.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 21 03 07 80 !..?
------------------------------------------------------------------------------
The major difference in the event is that EAP-Type says "undetermined"
I've checked the RASTLS and RASCHAP debugs, but they are pretty
lengthy. I can post here if someone thinks they will help.
Any help will be greatly appreciated!!!
I had this issue recently :-)
CISCO supplicant authenticated OK, but MS XP-SP2 supplicant
and other 3-rd party supplicants failed to authenticate.
As a test, on the windows native client, go into the wireless properties
and un-check the option to verify the server certificate.
Then, try again.
If this fixes the issue, then the problem is with trusting the server
certificate.
( It seems the cisco ACU is not fussy about the server cert. -
I've not investigated why that is the case. )
Be sure you have a good server cert, that is trusted by the clients.
Go to the IAS server, and go into your Remote Access Policy.
Edit Profile | Authentication tab | EAP methods;
Select PEAP, | Edit button;
Look at the certificate being issued.
Who is the issuer?
You need to ensure the Root Cert of the issuer is loaded on the clients.
If it's a purchased cert, it will probably already be trusted on the
clients.
If you have set up your own CA, then you must add the CA cert to the Root
Cert store on the clients.
Sometimes, I've seen IAS machines generate their own self-cert issued by
themselves when they can't determine that they have another valid cert to
use. Check the drop-down to issue a good cert which is trusted by the
clients.
I've had issues with IAS machines 'eating' their own certs issued by the
local CA, and then self-certifying themselves too. As I recall, I had to
fiddle manually with certificate templates to sort that out.
--
Best Regards
Ron Lowe
|
|
|
|
|