cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1680
Views
10
Helpful
4
Replies

Authorization permissions in one or multiple authorization profiles

Johannes Luther
Level 4
Level 4

Hi board,

short question regarding authorization policy design:

In the past I assigned one authorization profile per authorization rule

Out of coincidence I saw that multiple authorization profiles may be assigned to one authorization rule.

 

I think this is cool, because someone could build a "modular" authorization toolbox:

E.g.

  • AuthZ profile: Reauth60 (Reauthentication every 60 minutes)
  • AuthZ profile: WLAN_QoSprofile_Gold (QoS-profile: Gold)
  • AuthZ profile: WLAN_QoSprofile_Silver (QoS-profile: Silver)
  • AuthZ profile: VLAN ID 100
  • AuthZ profile: VLAN ID 101

If I want to assign a WLAN client to VLAN 101 with QoS profile gold, the following profiles are used:

- WLAN_QoSprofile_Gold

- VLAN ID 100

 

However I have no idea how this works and the pro and cons regarding this approach. Examples:

  • What happens if in profile1 VLAN a is assigned and in profile2 VLANb and both profiles are included in one rule. What happens?
    • Both VLAN IDs are sent to the NAD? .. no idea what the NAD does in such a case
    • The first / last used authorization profile has priority?
    • ...
  • Are there any performance / best practice impacts?

Anybody knows that? Do you know a Cisco doc describing multiple profiles in one rule? How do you design your rules?

Thanks in advance!

Best regards

Johannes

 

1 Accepted Solution

Accepted Solutions

Johannes Luther
Level 4
Level 4

I tried it in ISE 2.1. First of all there is no possibility to order the authorization profiles in the permissions.

What obviously happens:

  • All profiles are combined in one authorization RADIUS packet
  • In case multiple values for the same attribute exists (e.g. multiple VLANs), the first matched attribute is sent to the NAD

 

I guess I'll start with this approach now to build a more modular ruleset. Furthermore it's more fault tolerant. For example if there is the policy to reauthenticate all dot1x clients every 2 hours, there is one profile for this purpose. The reauthentication timer is not hidden in multiple profiles. So there is a single source of truth :)

View solution in original post

4 Replies 4

anthonylofreso
Level 4
Level 4

I'm trying to think of an example where I would apply two auth z policies with the same common task, and I can't.

My thought would be any time you need to apply like common tasks with different results, that would be an additional rule in your policy set.

My assumption would be if you tried to overlap, ISE would apply your result in order (top - down) but without testing, I couldn't be certain. Maybe on read-only Friday I will test and get back to you.


@anthonylofreso wrote:

I'm trying to think of an example where I would apply two auth z policies with the same common task, and I can't.


Me neither - but I want to understand how the system reacts if this happens (e.g. due to a misconfiguration). I can test this as well, but I was hoping for a proper documentation :D

However, I'm with your assumption - I also guess the last one wins.

 

I'm curious: Are you using multiple AuthZ profiles in a single rule or not?

I am not. We primarily use AuthZ profiles to apply DACLs to interfaces.

To be honest, I hadn't noticed the +/- in the permissions column for multiple Auth Z policies. We've applied multiple common tasks (VLAN + DACL) but only via a single profile since they are check boxes.

I'd be curious to know what others use this functionality for

Johannes Luther
Level 4
Level 4

I tried it in ISE 2.1. First of all there is no possibility to order the authorization profiles in the permissions.

What obviously happens:

  • All profiles are combined in one authorization RADIUS packet
  • In case multiple values for the same attribute exists (e.g. multiple VLANs), the first matched attribute is sent to the NAD

 

I guess I'll start with this approach now to build a more modular ruleset. Furthermore it's more fault tolerant. For example if there is the policy to reauthenticate all dot1x clients every 2 hours, there is one profile for this purpose. The reauthentication timer is not hidden in multiple profiles. So there is a single source of truth :)