Windows XP & 7 fail authentication to ACS 5.3

Unanswered Question
Aug 27th, 2012
User Badges:

Greetings


Here is the scenario

previously using freeradius and no issues existed with windows clients connecting to the wireless.


The SSID has wpa/wpa2, 802.1x authentication


Installed ACS 5.3

configured Store for LDAP - we don't use AD so don't recommend it

allowing PEAP-GTC as PEAP-MSCHAP2 is unsupported

uploaded a valid sign Certificate for our organization to be used for EAP


all MAC clients work and most mobile devices, user receives the cert and click accept and then they are prompted for Username and Password


However all  windows clients XPSP2, XPSP3, Windows 7 fail to connect


first error was

Windows was unable to find a certificate on local machine to use to validate network.


I would expect that the acs would provide the cert like the MAC devices at this point, that doesn't seem to be the case.


I exported the cert from acs and imported into the XPSP3 machine and placed it into Trusted Root CA

I tried almost every store listed as well.


After the import

The error is unable to connect to network.


ACS reports

While trying to negotiate a TLS handshake with the client, ACS received  an unexpected TLS alert message. This might be due to the supplicant not  trusting the ACS server certificate for some reason. ACS treated the  unexpected message as a sign that the client rejected the tunnel  establishment.


It also lists the username as the organization in the Cert and PEAP(null)


for the windows client I have

auth as WPA2

Data Encryption as AES

on the Authentication tab

EAP type > Protected EAP

authenticate as computer unchecked

authenticate as guest unchecked

under EAP properties button

Validate server cert - checked

Trusted Root CA - the organizations cert - checked

do not prompt user - unchecked

select auth method - smart card or other cert - selected - since mschapv2 is not supported for the ldap store

clicked configure

use a certificate on this computer - checked

use simple cert selection - checked

Validate server cert - checked

Trusted Root CA - checked the org cert

use different user - unchecked

enable fast reconnect - unchecked


What I would like to see

The user selects the ssid > is prompted to accept cert from acs > accepts > user is prompted for their ldap login creds > user is authenticated


Any insight would be greatly appreciated



15004  Matched rule

15012  Selected Access Service - RBLDAP Network Access

11507  Extracted EAP-Response/Identity

12300  Prepared EAP-Request proposing PEAP with challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

12302  Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated

12318  Successfully negotiated PEAP version 0

12800  Extracted first TLS record; TLS handshake started.

12805  Extracted TLS ClientHello message.

12806  Prepared TLS ServerHello message.

12807  Prepared TLS Certificate message.

12810  Prepared TLS ServerDone message.

12305  Prepared EAP-Request with another PEAP challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

12304  Extracted EAP-Response containing PEAP challenge-response

12305  Prepared EAP-Request with another PEAP challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

12304  Extracted EAP-Response containing PEAP challenge-response

12318  Successfully negotiated PEAP version 0

12812  Extracted TLS ClientKeyExchange message.

12804  Extracted TLS Finished message.

12801  Prepared TLS ChangeCipherSpec message.

12802  Prepared TLS Finished message.

12816  TLS handshake succeeded.

12310  PEAP full handshake finished successfully

12305  Prepared EAP-Request with another PEAP challenge

11006  Returned RADIUS Access-Challenge

11001  Received RADIUS Access-Request

11018  RADIUS is re-using an existing session

12304  Extracted EAP-Response containing PEAP challenge-response

12511  Unexpectedly received TLS alert message; treating as a rejection by the client

11504  Prepared EAP-Failure

11003  Returned RADIUS Access-Reject

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jagdeep Gambhir Mon, 08/27/2012 - 20:12
User Badges:
  • Red, 2250 points or more

Simon,


Have you installed complete cert chain on the xp client we are authenticating with? It needs to have both CA and Intermediate CA intellaed in trusted store.


Do we have any patch installed?



Regards,

~JG

Andrew MacTaggart Mon, 08/27/2012 - 20:42
User Badges:

Hi jagdeep


I patched the machine yesterday. so it's upto date


we have a wild card cert *.orgname

Instead of using a self generated cert on the acs - I imported the org cert.

it was issued by

UTN-USERFirst-Hardware

I just selected this option as well

normally when I use this cert for ssl servers, client has accept it. This works for Mac os x 10.6 and 10.7 as well as ipads and iphones. Just the windows are trying to either use the machine name and local windows account or the cert org as the username.


I exported this cert from the acs and imported it to winxp



I get the same TLS error

While trying to negotiate a TLS handshake with the client, ACS received  an unexpected TLS alert message. This might be due to the supplicant not  trusting the ACS server certificate for some reason. ACS treated the  unexpected message as a sign that the client rejected the tunnel  establishment.


it lists the username as the org name in the cert


which seems wrong to me.


What I want is it to work like the apple systems


connect to ssid

get presented with cert from acs

accept that cert

get prompted for username and passwd

get connected


I have click and selected all sorts of options for the wireless connector.


This really needs to be simple, because we don't manage these devices and they don't belong to any domain


A

Andrew MacTaggart Mon, 08/27/2012 - 21:30
User Badges:

Says it's fixed


Anyway the wildcard cert works fine for MAC OS devices except IPhone4s running IOS 5 - which is easy to fix by creating a profile and importing the cert manually.


It seems to me that something is not right with the microsoft wireless client

Andrew MacTaggart Mon, 08/27/2012 - 22:17
User Badges:

a bit of an update


I downloaded the Intel ProSet tool and used it instead of the microsoft zero config tool and the windows xp connects straight away. The PEAP settings seemed to be better in the intel software.


This is not an ideal solution because we will have many users with different version of windows needing to connect and the hardware will be different from machine to machine.


Cheers

Andrew MacTaggart Tue, 08/28/2012 - 20:24
User Badges:

I need some suggestions or solutions to this issue


Basically If you configure acs to use LDAP as the identity store, then the microsoft supplicant can not use the EAP/MSCHAP2.


You can select PEAP and configure Trusted Root CA with an imported CERT but there are no options to send the true USERNAME to the acs - instead the MS client sends the organization the cert was issued to


If you choose not to verify the cert the MS client sends the computername/user as the USERNAME


The only way around this is not to use the MS supplicant


You must use a 3rd party  - which most are not free and depending on the version of windows may be different versions


It seems to me that others must have experienced this issue.


Overview of PEAP


PEAP is a client-server security architecture that you use to encrypt  EAP transactions, thereby protecting the contents of EAP  authentications. PEAP uses server-side public key certificates to  authenticate the server.


It then creates an encrypted SSL/TLS tunnel between the client and the  authentication server. The ensuing exchange of authentication  information to authenticate the client is then encrypted and user  credentials are safe from eavesdropping.


PEAP is similar to EAP-TLS but uses a different client authentication  method. PEAP provides authentication, by using server certificates, a  TLS tunnel and client authentication through that encrypted tunnel.  Unlike EAP-TLS, PEAP requires the client to use another EAP type, like  EAP-MSCHAPv2.


PEAP authentications always involve two phases:


In  phase1, the end-user client authenticates ACS. This action requires a  server certificate and authenticates ACS to the end-user client,  ensuring that the user or machine credentials sent in phase two are sent  to a AAA server that has a certificate issued by a trusted CA. The  first phase uses a TLS handshake to establish an SSL tunnel between the  end-user client and the AAA server.




Note Depending  on the end-user client involved, the CA certificate for the CA that  issued the ACS server certificate is likely to be required in local  storage for trusted root CAs on the end-user client computer.



In  the second phase, ACS authenticates the user or machine credentials by  using an EAP authentication protocol. The SSL tunnel that was created in  phase1 protects the EAP authentication.


The inner-method authentication type that is negotiated during phase 2  can be either EAP-MSCHAPv2, EAP-GTC or EAP-TLS. The combination of the  outer PEAP method with a specific inner EAP method is denoted using  brackets (); for example, PEAP(EAP-MSCHAPv2) or PEAP(EAP-GTC).


An improvement in security that PEAP offers is identity protection. This  improvement is the potential for protecting the username in all PEAP  transactions. After phase one of PEAP, all data is encrypted, including  username information that is usually sent in clear text.


The Microsoft PEAPv0 client does not provide identity protection; the  Microsoft PEAPv0 client sends the username in clear text in phase one of  PEAP authentication.


In ACS 5.3, PEAP is encapsulated in RADIUS protocol. Inner-method EAP messages are encapsulated in an EAP-TLV method.



ACS 5.3 supports these PEAP supplicants:


Microsoft Built-In Clients 802.1x XP (PEAPv0 only)


Microsoft Built-In Clients 802.1x Vista (PEAPv0 only)


Microsoft Built-In Clients 802.1x Windows 7


CSSC v.4.0


CSSC v.5


Funk Odyssey access client (latest version)


Intel Supplicant 12.4.x


acs using LDAP DB Store does not support EAP/MSCHAP2


https://supportforums.cisco.com/thread/2164913

Tarik Admani Wed, 08/29/2012 - 23:06
User Badges:
  • Green, 3000 points or more

Simon,


Can you clear up the following statements:


You can select PEAP and configure Trusted Root CA with an imported  CERT but there are no options to send the true USERNAME to the acs -  instead the MS client sends the organization the cert was issued to


Are you referring to eap-tls? Which cert are you trying to send?


If you choose not to verify the cert the MS client sends the computername/user as the USERNAME


If the requests is coming in as host/computer.domain then you can disable this setting in the supplicant to force it to user auth only.


You can download the cisco anyconnect NAM with no charge if you meet the following requirements:


http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect31/administration/guide/ac04namconfig.html#wp1221438


Licensing and Upgrading Requirements


The AnyConnect Network Access Manager is licensed without charge for use  with Cisco wireless access points, wireless LAN controllers, switches,  and RADIUS servers. No AnyConnect Essentials or Premium license is  required. A current SmartNet contract is required on the related Cisco  equipment.


Here is some configuration information regarding the client using the network profile editor.


http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect31/administration/guide/ac04namconfig.html


Thanks,

Tarik Admani
*Please rate helpful posts*

Andrew MacTaggart Thu, 08/30/2012 - 20:05
User Badges:

Hello Tarik


to answer the first question:

Yes it can't get past the eap-tls stage - the acs close the connection

in the acs logs I see "*.myorg.com" as the username with validate cert on

we have a company wildcard cert issued by Trusted Root CA in UTAH associated with Novell.


Acs says the client had an issue with the communication or did not respond correctly so the eap-tls was terminated


if I don't validate i see

"computername/windowsusername" as the username - which does not exist in LDAP

I don't see and option to disable this setting in the windows supplicant to force it to user auth only


My CCO account won't let me download even the free stuff or trial versions, I have contacted the vendor the account is registered through for a fix.


I am thinking that anyconnect may be my only option at this point.

because although intel proset works for my test machine, users may have different hardware.

The ideal situation would be if the MS supplicant worked like the MAC supplicant

Andrew MacTaggart Thu, 08/30/2012 - 20:59
User Badges:

I would like to add the error messages


While trying to negotiate a TLS handshake with the client, ACS received  an unexpected TLS alert message. This might be due to the supplicant not  trusting the ACS server certificate for some reason. ACS treated the  unexpected message as a sign that the client rejected the tunnel  establishment.


Ensure that the ACS server certificate is trusted by the client, by  configuring the supplicant with the CA certificate that signed the ACS  server certificate. It is strongly recommended to not disable the server  certificate validation on the client!


I exported the cert from the acs as well trying to use the original cert

I imported into trusted root CA, personal, enterprise etc....

Andrew MacTaggart Fri, 08/31/2012 - 00:41
User Badges:

Cisco TAC replied.


From what I understand you are using PEAP-GTC with ACS and an LDAP backend.
You seem to have a few issues:
                 1. Your client does not trust your server certificate. The CA which issued the ACS certificate must be trusted by the client. This is how TLS works, both parties must trust the same CA in order to bring up a connection. You can bypass the certificate check on the client side by disabling server certificate validation. This will allow self-signed certificates, or untrusted certificates to be used to build the outer PEAP tunnel
                 2. You are trying to do PEAP-GTC with a Windows supplicant. Windows built-in supplicant does not support GTC - it can only do TLS or MSCHAPv2 as the inner method-, so you will need to use another supplicant. Anyconnect NAM is a possible solution.


Number seems strange to me. I imported the cert, if I open the browser to the acs, the mgmt uses the same cert, I get no warnings or anything. I have to assume that the cert is being trusted.


for #2 these are the protocols I am allowing.

Attachment: 
Tarik Admani Sat, 09/01/2012 - 00:46
User Badges:
  • Green, 3000 points or more

Can you post the message of the warning, I wonder if there maybe confusion as to the message. I have seen this issue before where the message will not ask the client to trust the cert but in turn would be a warning message to the client regarding the identity of the radius server (when you click details it will show the trusted cert with no warning message).


Thanks,



Tarik Admani
*Please rate helpful posts*

Andrew MacTaggart Sun, 09/02/2012 - 20:51
User Badges:

Hi Thanks for the response after much thought on the matter


in the MS client the message says clickhere to select a certificate or other credentials for connection to the network XXXX


clicking just creates a loop of accepting the trusted cert over and over again


What I realized was that I was missing some understanding on how the MS client is trying to work with the acs.


So in my scenario


ACS with LDAP STORE does not support PEAP/MSCHAP2, which I knew

Didn't know that MS client does not support PEAP-GTC - but kind of figured it out.

Didn't understand all the requirements to get EAP-TLS to work and specifically how to configure the ms wireless client.

I basically need a CA

Need to generate a client side cert with the username embedded with in

Need to generate a server side cert for the ACS

configure them both to verify to the CA server.

This is a lot of work for .05 of the clients for our environment and is not very straight forward from a users perspective.


Here is some of the info that has started me down the right path


https://supportforums.cisco.com/docs/DOC-17512


and


http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_white_paper09186a008009256b.shtml#wp39392


As of this moment - I am still working on this.

Tarik Admani Mon, 09/03/2012 - 00:31
User Badges:
  • Green, 3000 points or more

Once you configure your CA you can choose autoenrollment feature so that all machines and users that connect to the domain are issued a certificate which takes the strain out of creating certs...


Good luck!


Tarik Admani
*Please rate helpful posts*

Andrew MacTaggart Mon, 09/03/2012 - 00:46
User Badges:

I will have to figure out how to get autenrollment working with freebsd.


I was able to get the securew2 windows client supplicant to work with PEAP EAP-GTC. as another option.


Cheers

Andrew MacTaggart Wed, 09/05/2012 - 23:18
User Badges:

Greetings


Just a follow up.


I am still working out the CA solution

but in the mean time:

So it was recommended that I give the cisco secure mobility client a go.

So I installed NAM and local policy editor on win xp sp3


I created a profile for the wireless network using PEAP-GTC

not many examples around so I tried to figure it out.

Got the profile installed because after reboot it auto selects the correct SSID and attempts to login.


I have restricted the cisco anyconnect to PEAP EAP-GTC and It tells the ACS it wants to use MSCHAPV2


Have I misconfigured the profile? am I missing something?


The issue now is authentication fails

error

12750 Failed to negotiate EAP for inner method because EAP-MSCHAP not allowed under PEAP configuration in Access Service.

The supplicant of the client sent an EAP-Response/NAK packet rejecting  the EAP-based protocol previously proposed for the inner method, and  requesting to use EAP-MSCHAP instead. However, EAP-MSCHAP is not allowed  under PEAP configuration in the Allowed Protocols section of the  relevant Access Service.

Actions

This Discussion

Related Content