Endpoint Visibility AuthZ Attribute not matching

[Cory Peterson]

Running ISE 2.3 patch 2 the endpoint visibility data is not matching up with the current live logs.

More specifically the attribute I am most concerned about at this time is the "AuthorizationPolicyMatchedRule" attribute is not matching the actual AuthZ policy that is being match when looking at the endpoint in the Live Logs or RADIUS authentication reports. 

I have also pulled the data using both ISEEAT and through the CLI with the same results. 

[hslai]

I do not think this is part of the significant attributes so it might not always get updated in ISE profiler.

[Nidhi]

Also, good to work with TAC to know the root cause and have a defect for tracking the issue. 

Thanks,

Nidhi

[paul]

There is already a bug for this:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb28481/?rfs=iqvred

I reported this in 2.1 and Hsing created a bug for me.  The bug says fixed but this is still not working correctly.  The biggest issue is we can't rely on Context Visibility to tell us the accurate last authorization profile the MAC address hit.  This is crucial in the monitor mode phase.  

[cjwolff]

I'm been working with the business unit for over a year on what sounds like the same issue.  If I understand the problem correctly there is a discontinuity between the context visibility database and a second database.  In my opinion, there is only one way to manage the deployment, that is through the radius livelogs and live sessions screens.  I feel your pain.

[paul]

Yes but the live logs aren't going to help you because you can't filter on Monitor-Catch-All authorization profile and expect that list to be accurate for things sitting at the Catch All rule. Especially with CPL where all devices are MAB'd all your valid 802.1x devices will hit the Catch All rule and look like issues when they are fine. The Live Session is better, but what if the device is currently on the network. Ideally, we need ISE to answer the question "What was the last authorization profile the MAC address hit". The Context Visibility is supposed to do that, but doesn't. I have a macro I wrote in 1.1 that I use to process RADIUS data and parse out the last hit authorization profile to give accurate Catch All hits, but that is only something I (and others at my company) use.

[cjwolff]

You're 100% on the mark. What you're describing is a fundamental failure in manageability of the enterprise through ISE. All we can keep doing is pushing the issue at all levels.

[Cory Peterson · Accepted solution]

This all revolves around the ability to find what endpoints are passing and which ones are not. Like many have stated above the difference in the two views is a huge pain point when doing monitor mode in preparation to move to enforcement mode.

Like Paul has done, I have also had to write my own tool to parse the data. 

I have written a python script that takes two reports and merges them using data from both that I want to see to help with troubleshooting the devices failing for whatever reason. I use ISEEAT to pull a full endpoint report(this matches context visibility) and also a report for the last 7 days of radius authentications(this report is growing to almost an 1gig CSV file).

All of the data is in the Context Visibility report but it is not accurate so we have to resort to custom scripts to meet this need that should be accurate. I have a case open on this also and it is definitely not corrected. 

[Willieh13]

Was this fixed in the 2.4 release?

[paul]

No this still hasn't been fixed.  Context Visibility is still unreliable as ever for certain data like the authorization policy hit.