Been trying to figure out this issue for awhile, i got around it, until now as i only had one switch manufacturer in the network. Now that we have two switch manufactures using ISE, i need to differentiate between them so i can apply the correct authorization for the IP Phones attached to them.
What is configured:
If MAB request:
authenticate against internal DB.
Authorize ip phone if iphone + switch type A with credentials A
Authorize ip phone if iphone + switch type B with credentials B
switch Type A and switch type B are seen as valid attributes on the Ip Phone end point.
However in the radius logs i am seeing the authorization rules being bypassed and hitting the default permit.
If i strip out switch type A and switch type B then all the phones will hit the first rule which will only work with
one switch type.
Also note the switch type A and switch type B work perfectly in the dot1x policies.
Thoughts ? something i am missing / not understanding ?
A config snippet would help - not sure if I understand what the issue is.
If you want to differentiate between two switch manufacturers then I would say the brute force approach could be to create a Device Group for each vendor type, and assign that to the switch. Use that attribute during your authorization Policy.
If you want to be a bit more sophisticated, then you need to determine (and share here the details) how to treat vendor A differently to vendor B, with regards to the RADIUS attributes that are sent to ISE, and also the RADIUS attributes that you need send back. ISE has a neat feature called Network Device Profiles that allows you to abstract the vendor, such that you can use MAB and 802.1X in your Policy Sets without caring about the details under the hood. There are vendors already pre-defined e.g. HPE, Aruba. You can define your own vendor definitions. The details are defined up-front, and you tag each switch with the correct vendor type in the Network Devices config in ISE. Network Device Profiles helps ISE understand what RADIUS attributes are used to trigger a MAB, or 802.1X or CoA etc.
And finally, the results (attributes you return to the switch) have to also be tagged with the vendor type. There is an exception though - if you do not tag the Authorization Profiles (results) with a vendor type, then it will apply universally. E.g. a simple Access-Accept does not need to be tagged with a vendor type.
If you share more details then perhaps we can assist better