ISE Profiling Deployment

[Juliano Luz]

We are starting a ISE deployment to segregate mobile devices (Iphones and IPads, initially) from corporate notebooks. We have a single SSID and two separate vlans, one for mobile devices and another for corporate notebooks, assigned by ISE. We successfully setup profiling in lab environment, with a few devices, but when we put in production  we had problems with devices not being profiled correctly. Since devices are not profiled their access are denied. Since devices are denied the cannot be profiled because ISE doesn´t see any traffic (DHCP, HTTP) from clients.

What strategy are you using to deploy ISE profiling? Must I put ISE to listen our network for some time before segregating access?

[Eduardo Aliaga]

Profiling is never 100% accurate. What probes are you using ? If you deploy many simultaneous probes (for example Radius probe, dhcp probe, etc) you have more chances to profile accurately.

[Juliano Luz]

Hi, Eduardo,

I´m using DHCPSPAN, HTTP, RADIUS and NMAP SCAN probes. Profiling is working fine for most device types.  If the traffic get to ISE it´s correctly profiled. The problem is when device connects for the first time in network.

[Eduardo Aliaga]

What devices are you having trouble with ? Assuming you're using DHCP , then DHCP probe should work when connecting devices for the first time. Probably some devices are not matching the DHCP profile rules and you will have to fine tune those rules.

To see the whole picture, are you using 802.1x or guest portals?

[Juliano Luz]

I´m having problem to identify notebooks (the must be profiled as workstation).I think I have to change my strategy: I´m denying access if endpoints are profiled as unknown. I´m going to put the endpoint on a restricted segment first, so that it can be profiled. After profiled, user is moved to the correct network.

[Brian Schultz]

Did you ever come up with a solution to effectively profile wireless devices the first time they connect to the network.  In my environment, I have all probes enabled with a dhcp helper address pointed to the ISE server.  The first time a wireless device connects, it is typically unknown and hits the default authorization profile.  Then the second time the device connects, it correctly profiles based on device type (Android, Apple-iPhone, Blackberry, etc.).  My authorization profiles are changing Airespace ACL and VLAN based on wireless device type.  I also have the profiling endpoint policies set to create matching identity group. 

What is the consensus for profiling a wireless device correctly the first time it connects?  Is use of SPAN a requirement from the switch? 

[Nicholas Copeland]

It has to connect in order for ISE to profile it. You can set a rule to reauth after so many seconds if the device is unknown. It will then work properly or it will deny access based off your rule. Just make a rule that if device is unknown that is reauth after so many seconds.

Sent from Cisco Technical Support iPad App

[shoaibkhan]

There should be three phase deployment of ISE - monitor, authenticate and then enforce. You complete the profiling in monitor mode. All new devices (i.e. printers etc ) needs should be manually provision and then profiled for high security. Other option is to allow full access to "Unknown devices" and over time ISE will profile them - but remember profiling is BEST EFFORT service.

For wireless, there is no option of monitor mode so what you can do is to a allow guest access for "unknown device" and then issue CoA after they are profiled. (Provided you have 5508 WLC) If this is not an option then use separate authentication methods for the two SSIDs. Keep one for Full access and only accept EAP-TLS and other one could be webauth.

[edondurguti]

Hi

I've had the same problem with first time users being denied, that's due to ise not being able to profile before it denies.

I think they should come up with something that will profile devices then continue the authentication process.

Someone mentioned doing a re-auth for couple of seconds. (see attached pic how the authorization rule looks like), that could save you from people being denied for the first time, but if your device is never being profiled then it will just spin there all the time re-authenticating.

What you could do is also setup an unrouted VLAN and all the unknown devices stay there until profiled.

I've talked to cisco and they recommened the same thing so I guess that's it for now

What we have done before deploying ISE and it worked pretty good is I have forwarded all DHCP traffic to ISE before deploying ISE at that particular site, so DHCP forwarding ran for few days and I've already had their devices in my database and when I deployed it, it worked pretty neat

By forwarding all dhcp requests I mean:

We have Active Directory and DHCP servers centrally located, so in the router config I've added helper address to ISE ip address and that's it

Now WLC 7.3 has DHCP PROFILING and HTTP PROFILING options.

Http profiling sends first https packets to ISE and capturing USER-Agent string, that helps if you browse with safari, but if you use any other application that uses http traffic it will end up totally wrong.

example you connect with your iphone to wifi and open up VIBER, ISE will capture viber_blabla_smth as user agent and will not profile accurately.

Hope it helps

[hranevuts]

First of all, apologize for necro-ing this thread, but this is similar in my case

I have the same issue with Cisco IP Phones and Access Points

I did a trial and error and stumble upon the above workaround

there's no issue with profiled IP Phones and APs, but for new deployment, both of them are firstly recognized as Cisco-Device. Only after a while, ISE can profile them correctly as IP Phone. As for the AP, I have to customize the CF to higher value for ISE to profile them correctly

the problem is with the new devices, I created an Authorization Policy where if it's a Cisco-Device or Unknown, then do a re-auth every 10 sec. It did the trick, where the device is re-authenticated and assigned the correct authorization profile

the problem is, the switch interface keeps the radius reauthentication value (10sec) even when I didn't check the field in IP Phone Authorization Profile..

I could set it to the max which is 65535, but since we have a lot of IP Phones + APs (total is in the range of thousands), I suppose it's not wise to do a re-auth every 18 hours

the radius session timeout only dissapear if I bounce the switch port manually (shut, no shut) or if the switch interface goes down

this method obviously defeat the purpose of re-auth..

Not sure if this is a bug or intended to work this way?

Is there any way to disable radius reathentication once it re-authenticated to a different authorization profile?

thanks

[Nicholas Copeland]

hranevuts,

If the authorization rule states to re-auth then it will continue to do so. You will need an auth rule that matches before the re-auth rule that states something different. If you have enabled COA under system settings for profiling then you shouldn't have to have a re-auth rule for devices that profiled. But the rule you have works as well since all devices are unknown at first. You just need to have an auth rule that is captured before the re-auth rule so that once the device profile is discovered and the COA rule either bounces the port/reauth or your reauth rule takes effect the device is then captured by a new authorization rule.

If the switch isn't changing the authorization rule then you might have a bug of some sort. What model switch and version are you running? I generally run some version of 15.0 code levels on mos the switches I have used and have never run into that problem when a change of authorization happens.

[hranevuts]

I've created a different authZ profile above authZ profile with re-auth. I've seen that the new dACL has been pushed by the different rule. but the radius session time still remains from the previous one (the one with re-auth)

so the rule is like:

rule1 --> radius session timeout unchecked. rule 1 dACL

rule 2 -->  radius session timeout checked. rule 2 dACL

I know rule 1 has kicked in since ISE has pushed rule 1 dACL instead of rule 2 dACL, but the session rimeout from rule 2 sill remains..

that's why I suspected a bug..

the switch we're using is 3750X with 12.2(55) SE3

[vikasyad]

t totally depends on the probes you are using. May be the probes are not  configured properly.

Please review the below link for assistance which might be helpful:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns744/docs/howto_30_ise_profiling.pdf