IP:User-Agent - When ISE collect this data?

[SHECHTER1]

Hi,

When does ISE collect IP:User-Agent data?

-Dan

[thomas]

When you 1) enable the Profiler HTTP Probe and 2) after an endpoint's web browser is redirected (Web-Auth, Guest or BYOD scenarios) to an ISE Policy Service Node (PSN)  so it may receive the HTTP User-Agent information and correlate for the endpoint profile. This is most useful with many phones and tablets to determine which OS and browser they are using to more accurately profile the device.

[SHECHTER1]

Hi Thomas,

Thanks for the answer.

I am trying to run a script on ubuntu, to send HTTP GET to ISE with a custome user agent.  Than I match it with a customer profile. It will be my own little posture check for unix machines.

With version 1.4 I noticed that onlt "wget -U myAgent ...." to port 80 works. No other port will set the user agent (8443/ 8905...)

With version 1.3, where I need this feature the most, ISE ignores the user agent no matter what.

Is theer a way to verify when exactly ISE will actually inspect the user agent, and when it would not? Also, how do I troubleshoot profiling? Can I start a debug on a probe?

-Dan

[thomas]

Only port 80 works for redirection to the ISE PSN because the endpoint's web request must redirected to ISE by the network device that the endpoint is connected through. Some devices may only do this for port 80/HTTP and some will also do it for 443/HTTPS (WLC 8.0+). The network devices aren't doing active traffic inspection like firewalls to detect HTTP on random ports like 8443/8905 as you were doing.  So this is a function of your network devices, not ISE.  8-)

As for Endpoint Profile debugging, after you connect or associate your endpoint, go to the ISE LiveLog > Right-click on your endpoint > select Endpoint Debug to see everything ISE knows about it.

[SHECHTER1]

At this point, I do not care about redirection.

What I am trying to do is to "feed" ISE with a custom user agent. Here is the follow I want to establish:

1. Create a profile condition on ISE which matches the following user agent : "myUserAgent"

2. Create a profile "myProfile" that matches the above and set the Certainty Factor to 100

3. Create authorization rule that matches the above "myProfile" and allow that workstations in the "myProfile" device group. Such workstations will be allowed in, no matter what their posture is.

Now I need to find a way to make ISE to act upon HTTP request, with User-Agnet="myUSerAgent", so ISE would profile it as "myProfile".

The way I was doing this was running a "wget -U myUserAgent <protocol>://<ise address> > /dev/null". This script will send HTTP GET to <ise address> with User-Agent="myUserAgent".

When trying this on ISE version 1.4, It was successful with protocol=http : wget -U myUSerAgent http://<ise address>".

It did not work with protocol=https or https+port 8905.

For ISE version 1.3, nothig worked. I verified with TCPDUMP on the ISE server that the above user agent did get to ISE1.3, but ISE1.3 had no reaction to this, and did not profiled the client to be "myProfile".

Now I don't really care about 1.3. I need this to work on 1.4 and on any future ISE release. So here is my question:

Would ISE ALWAYS, for ever and ever, inspect HTTP on port 80 to look for IP:User-Agent profile condition, or maybe I was just lucky and I shouldn't count on it?

[thomas · Accepted solution]

Sorry, but you must care about URL redirection or the UserAgent will never get correlated!  ISE needs the RADIUS Session-ID provided by the NAD upon redirection to correlate your IP from your HTTP GET to your RADIUS session and MAC address in order to update your Endpoint Profile in the Session Directory!

So here is how this needs to work...  (I'll assume you're doing this on a switch)

1) Connect your Linux box to a switchport with 802.1X+MAB configured. It doesn't matter if you do 802.1X or timeout and do MAB but the default authorization (ACL) must allow endpoint traffic to talk DHCP, DNS and to the ISE PSN(s) on port 8443 which is the default ISE web-authentication portal. Please see the HowTo: Universal Switch Config for best practice switchport configs.

2) Verify in the ISE LiveLog that there is an active Session with your Linux MAC address. If not, then you have misconfigured the switchport or RADIUS config and you will never get any endpoint profile data. ISE requires an active session before it will acquire and correlate endpoint attributes.

3) Open a normal web browser on your Linux endpoint to http://cisco.com or your favorite test domain. If you are successfully redirected to the ISE web-auth portal then the NAD redirection to ISE is working beautifully. Also note how the URL has changed to include a Session-ID! ISE uses this to correlate the User-Agent to the active RADIUS session from the NAD which contains your MAC address. if it does not work, you have a problem with your ACL or most likely your Redirect-ACL and that correlation cannot happen. Search the HowTo: Universal Switch Config Guide for ACL-WEBAUTH-REDIRECT for best practices and examples.

4) if everything above has worked you can NOW run your wget with custom UserAgent. Do a standard HTTP GET to http://cisco.com:80 or your favorite domain. Ensure wget will accept and follow HTTP redirects from the NAD. Dump the response and verify it's the ISE Web-Auth page. This is how your customer UserAgent should be correlated.

Do not perform an HTTP GET straight to http://ise-psn.domain.com:8443 because you will not get the redirect from the NAD that changes the URL to include the RADIUS Session-ID.

[SHECHTER1]

WOW, thanks for the detailed response.

I tried that in the lab. I noticed how the Session ID in the redirection correlates to "Audit Session ID".

But step 4 did not work! I had to explicitly send the HTTP GET to ISE:80.

Please noticed that in the redirection ACL, I allowed HTTP traffic to ISE server not to be redirected:

deny tcp any host <ise_ip_address> eq www.

Then ISE itself redirected me to /admin:443 and then the switch redirected me to the portal.

With your example, if the first GET to cisco.com:80 will not reach the ISE HTTP probe and will never get profiled. All ISE will see is traffic on port 8443. With my example, where I allow traffic to ISE on port 80, and deny the redirection to ISE server on that port, then ISE HTTP probe would get the clear text GET with my special User-Agent.

Now I have tested this without redirection. Right after dot1x login, I send the wget -U myUserAgnet to ise:80. Got 302, and then few more redirections to /admin:443. And I was profiled correctly!

Now I have made another test. I moved the ubuntu to another port, and noticed that the live session was "Terminated". Then I tried wget again, and the profile did not change.

So for now, my conclusions for being able to purporsly change the User-Agent reported by the Endpoint Identity  are:

• The Ubuntu IP address have to be listed under the Live Sessions, and not be in a  "Terminated" state.
• The Ubuntu should send the crafted wget -U myUserAgnet to ISE:80.

Now I sill wonder why it didn't worked in ISE version 1.3, and I wonder if this will work in 2.0 and future versions.

[thomas]

Glad to hear it worked for you, Schechter.

If the web browser redirection worked in Step 3 then the wget should behave identically.

[Craig Hyps]

As a follow up to this thread and hopefully to clarify some points...

By default, ISE will attempt to parse web traffic sent to it via redirection and since part of a RADIUS session is able to directly correlate client session to MAC address.  Realize that MAC address must be known to add an endpoint to database.  This is covered in the ISE Profiling Design Guide.  In the absence of redirection, ISE needs to know the IP address associated to a specific MAC address. If it only received an HTTP request, then it lacks the MAC address unless PSN was L2 adjacent to client.  Therefore, it is possible to get HTTP data that cannot be used for profiling if client IP to MAC binding does not exist in endpoint record.

If you enable the HTTP probe, we also allow ISE to parse non-redirect flows such as direct web requests to portal or else SPAN of HTTP traffic. In this case, ISE should properly parse the user agent for source IP--but IP to MAC Binding is still required to correlate it to an endpoint in database.

Craig