cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1026
Views
4
Helpful
4
Replies

ISE: advising users that only EAP-TLS can be used

cpaquet
Level 1
Level 1

A large school board accepts only EAP-TLS connections.  This requirement is easily dissiminated to teachers, however not to students whose personal devices keep trying to connect using PEAP.   Once users connect with EAP-TLS, they are authenticated on AD.

1. Could we from the Switch port block PEAP but let EAP-TLS go through? I couldn't find a command for this.

2. If we can't stop PEAP requests from reaching ISE, could we treat the PEAP connections as CWA, but have a special Authorization Rule that would say if inner tunnel is PEAP then do CWA-nonEAP-TLS web authentication which would be a customized web page that would have a message instructing the students how to use EAP-TLS? would that make sense?

3. Do you have better suggestion how to either block PEAP before it reaches ISE or a way using ISE to let users know that they must use EAP-TLS, not PEAP if they wish to connect?

Thanks.

Cath.

1 Accepted Solution

Accepted Solutions

Typically when the eap handshake starts there is an agreement between the supplicant and the radius server on which eap types are negotiated. If you only have eap-tls suggested to the client and the supplicant is misconfigured and uses PEAP it should drop there.

You may want to consider strict exclusion policies so that if a client fails to authenticate after 3 tries you can exclude them for a few minutes.

You can create a splash page (redirect url) that when the authentication type mschapv2 and the authentications status set to "failed" a self help html page is presented to the end user to use eap-tls, keep in mind this port and ip will have to allowed in the redirect ACL.

What do you see in the failed attempts?

Thanks,

Tarik Admani
*Please rate helpful posts*

View solution in original post

4 Replies 4

Tarik Admani
VIP Alumni
VIP Alumni

Cath,

You can shut off the other protocols that  arent being used or you can set the preferred protocol as the first  method negotiated. In your Authentication Poilcy if you are using the  "Default Network Access Condition" then you can go to the Policy  Elements > Results > Conditions > Authentication > Default  Network Authentication and make your changes there.

Hope that helps

Tarik Admani
*Please rate helpful posts*

Hi Tarik,

Of course, I know about the Allowed Protocol which currently has only Host Lookup and EAP-TLS enabled.  But that technique, of not allowing PEAP in ISE Authentication policies, doesn't stop thousands of students devices from hitting ISE with PEAP traffic.  Students have heard that they are allowed to connect to the school network using dot1x, so they turn it on on their PC without regards of to which EAP flavour they are supposed to use.  Thus, the ISE box getitng hit with PEAP requests which it drops.  The school board would like to deal with that PEAP traffic. 

To alliviate this problem, of the ISE box getting constantly PEAP traffic from the same device over and over again in the course of a day, I was wondering:

1. can we stop PEAP traffic before it arrives to ISE?  is there a way for the switch to differentiate that it's a PEAP and not EAP-TLS and to drop it before passing it to ISE? I don't think so.

2. if the switch can't stop PEAP , how is the best way to have ISE process the PEAP traffic?   because if ISE only reject the PEAP traffic, it is constantly hit back that the same device sending over and over PEAP traffic to ISE. 

I suggested to the client the two following possible ways:

  a. authorization rule based on Network Access: Tunnel PEAP that provides CWA with customized webpage telling the students to use EAP-TLS and not PEAP (this technique is explained in para 2. of my original posting).

  b. create a blackhole VLAN where the students personal PC that are arriving with PEAP are put.  This VLAN doesn't go anywhere, but at least the PC has stopped hitting ISE with PEAP traffic for a few minutes, until the student decides to restart his/her connection.   

I also recommended to the client that they have a better technique to inform the students that only EAP-TLS is available, like posters on the wall, blast email, on School FB page, etc .  but information dissimination is not an IT problem, it's a communication problem. 

Looking forward to your suggestions.

Typically when the eap handshake starts there is an agreement between the supplicant and the radius server on which eap types are negotiated. If you only have eap-tls suggested to the client and the supplicant is misconfigured and uses PEAP it should drop there.

You may want to consider strict exclusion policies so that if a client fails to authenticate after 3 tries you can exclude them for a few minutes.

You can create a splash page (redirect url) that when the authentication type mschapv2 and the authentications status set to "failed" a self help html page is presented to the end user to use eap-tls, keep in mind this port and ip will have to allowed in the redirect ACL.

What do you see in the failed attempts?

Thanks,

Tarik Admani
*Please rate helpful posts*

Hi Tarik,

I'm doing design work with that customer, so i'm haven't seen their ISE logs. 

Customer doesn't want to change the exclusion timers out of concern that EAP-TLS staff would be locked out for too long if they have an issue with their EAP-TLS supplicant.

The splash page solution is exactly what I was suggesting to them.

Thanks.

Cath.