ISE assigns SGT but mapping does not show on switch

[Joseph Johnson]

The setup is ISE 2.3 Patch 2 and a 3850 running Denali 16.3.5. When a user authenticates, they are assigned SGT 10 correctly based on the ISE policies. This is verified when looking at show access-session int [interface] details. It was noted that even though the correct SGT is assigned, and the switch is receiving the correct matrix/role-based permissions (seen in show cts role-based permissions), the user can access the full network even though they should only be limited to 2 servers.

When I run the command show cts role-based sgt-map all, I do see a list of SGT mappings but it only includes CLI and INTERNAL. No LOCAL (dynamic) mappings show up in the list. So the above user, with SGT 10, is not added to the SGT mappings. I verified that device tracking was enabled and a binding was showing for the user's endpoint.

Is the lack of an SGT mapping (show cts role-based sgt-map all) the reason the SGACL is not being enforced? What would cause the dynamic SGT assignment to not show up in the SGT map?

[Rob Ingram]

Hi,

You are correct, the dynamically learnt SGT's should be visible when you run the command show cts role-based sgt-map all. This could be a cosmetic issue and packets could still be tagged correctly.

You could configure netflow monitor on the switch and include "match flow cts source group-tag" and "match flow cts destination group-tag", generate some traffic and see if the SGTs are actually being tagged in the packets.

I checked the release notes of the latest Denali firmware, there is a fix for a cts enforcement issue (though it doesn't exactly match your exact Denali version), the bug description is not very descriptive. I'd perform and upgrade first, if that doesn't work raise a TAC case.

How are you getting the Destination IP SGT mappings to the 3850? Or are all devices on the same switch?

HTH

[Joseph Johnson]

Static mappings for destinations are pushed via ISE to the CLI. Only 2 destinations are allowed, depending on switch location, and everything else hits deny IP. The static mappings are showing up properly when executing the show cts role-based sgt-map all command.

I will see if the customer can upgrade the switch. If not, or the upgrade doesn't seem to correct the issue, I will raise a TAC case as suggested.

Thanks.

[Joseph Johnson]

The TAC engineer had us try upgrading from 16.3.5 to 16.8.1a. After the upgrade, we see the same behavior where the SGT assignment occurs but it does not show up in the SGT map. I double checked the release notes for both 16.3 and 16.8. Both show that TrustSec 802.1x and TrustSec Critical Auth are not supported. I asked if that meant we couldn't use ISE for dynamic SGT assignment and SGACL enforcement. The TAC engineer said it should work but it's still not. I'm starting to think it really isn't supported.

[Rob Ingram]

Those release notes are not helpful. I can only assume when they say Cisco TrustSec 802.1x is no longer supported, they are referring to the command "cts dot1x" entered on an interface level. Previously it was recommended to use "cts manual", I assume this is what they are referring to here. So possibly they've just removed this command that they didn't want people to use.

Care to share your config so I can have a look?

Can you enable some trustsec debugging on the access layer switch and gather some output when a device is authenticated and assigned an SGT?