cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4383
Views
5
Helpful
6
Replies

ISE to block mobile devices

nacbloud
Level 1
Level 1

I am new to ISE and have been reading up on profiling and posturing. I am wanting to come up with a configuration where ISE blocks certain mobile devices from getting network access. IE Apple or android. Would it be best to use profiling to identify the endpoint and apply a policy or use some sort of posturing configuration? Thoughts...

1 Accepted Solution

Accepted Solutions

Actually Jason this is a perfect use case for profiling if you are trying to deny by type of device. It is a simple 3 rule setup for your guest SSID:



1) If profiled as Android or iDevice then Access Reject.

2) If member of GuestEndpoints then grant Internet Access

3) Redirect to Guest Portal.



There are two flows you have to think of here. What does it look like the very first time a device connects:



1) Device connects and gets redirected to the guest portal.

2) Within the span of a few seconds ISE has collected the User Agent fields from the device and determined the device is an iDevice or Android. At this point, a CoA is sent because of a profile change and the device is then rejected from connected to the SSID. The CoA on reprofile has been broken since 2.3 (I feel like a broken record), but I have a feeling will be finally fixed pretty soon. So the user would continue through the portal process.

3) The user accepts the AUP policy. At that point a CoA is sent to the WLC. Thankfully this CoA works.

4) The device is run through the policy again and dropped because it is an Android or iDevice.



On subsequent connection attempts the device would get rejected right away. So worst case the user may see the portal the first time, but will never get connected to the Internet.


View solution in original post

6 Replies 6

paul
Level 10
Level 10

What are they trying to access the corporate SSID?  If so, I am guessing you are allowing PEAP Domain User authentication to your corporate SSID.  While you can block devices from connecting based on profiling the correct solution is to stop allowing PEAP Domain User authentication.  Typically, we only want to allow corporate devices onto the secure SSID and look to PEAP Computer or EAP-TLS to solve this challenge.  

I am trying to block access to the guest Network. I do not want guests with
certain device OS to join.

So I’m assuming you don’t want your corporate users to connect with their corporate machine?

Profiling is not the best way to do that since you don’t know what the devices profile is Until they hit the portal and just no way to stop them from using the portal.

The way control this is to not use a hotspot or a registration portal that allows employees to crate their own accounts. For example shelf registration with sponsor approval or sponsor created accounts would be a way to lock down the guest portal. Or you could provide an access code on the portal page that would be giving out by the lobby ambassador. This way only the guest could use it.

Another way to control this is to deploy any connect network access manager. A more powerful supplicant replacement for windows native. There is a feature of this module that only Ale A more powerful supplicant replacement for windows native. There is a feature of this module that only Allows connection to a corporate SS ID. When it’s in range it won’t allow connectivity to other wireless lans

Actually Jason this is a perfect use case for profiling if you are trying to deny by type of device. It is a simple 3 rule setup for your guest SSID:



1) If profiled as Android or iDevice then Access Reject.

2) If member of GuestEndpoints then grant Internet Access

3) Redirect to Guest Portal.



There are two flows you have to think of here. What does it look like the very first time a device connects:



1) Device connects and gets redirected to the guest portal.

2) Within the span of a few seconds ISE has collected the User Agent fields from the device and determined the device is an iDevice or Android. At this point, a CoA is sent because of a profile change and the device is then rejected from connected to the SSID. The CoA on reprofile has been broken since 2.3 (I feel like a broken record), but I have a feeling will be finally fixed pretty soon. So the user would continue through the portal process.

3) The user accepts the AUP policy. At that point a CoA is sent to the WLC. Thankfully this CoA works.

4) The device is run through the policy again and dropped because it is an Android or iDevice.



On subsequent connection attempts the device would get rejected right away. So worst case the user may see the portal the first time, but will never get connected to the Internet.


Great one thanks!

That sounds simple enough. I test this in a lab and let you know. Thanks
guys!!!