cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1383
Views
15
Helpful
9
Replies

Endpoint Visibility AuthZ Attribute not matching

Cory Peterson
Contributor
Contributor

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. 

 

 

1 Accepted Solution

Accepted Solutions

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. 

View solution in original post

9 Replies 9

hslai
Cisco Employee
Cisco Employee

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

Nidhi
Cisco Employee
Cisco Employee

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

 

Thanks,

Nidhi

paul
Advocate
Advocate

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.  

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.

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.


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.

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. 

Was this fixed in the 2.4 release?

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: