ISE - Dynamic Variable Substitution

[mgraves]

I have been reading up on Dynamic Variable Substitution within ISE.  I have seen how the VLAN can be dynamically set.  I see that there are 2 to 3 av-pairs that need to be set: sgt-name, security-group-tag and vn.

Is it possible to set the Security Group using this method?  Has anyone been able to accomplish this?

[howon · Accepted solution]

Yes, it is possible. You can create authorization profile that populates user attribute with the tag value and the VLAN ID that maps to VN and assign it to the session. In regards to the tag, you can't simply enter the tag ID as the attribute, it has to be populated in the attribute as Cisco VSA with 'cts:security-group-tag-0008-01' for tag 8 for instance. For assigning VLAN ID, refer to:

Dynamic Attribute with ISE: VLAN Assignment

[mgraves]

Unfortunately that was my conclusion.  Thanks

[jedavis]

That was a great demo.  Very informative

But how about something like this.  I have several ASAs and I want to have users authenticate to gain access through firewall only if the user has group membership that is tied directly to a the specific firewall they are authenticating from.  For example, I have firewalls named:

AAA-ASA

BBB-ASA

CCC-ASA

Then there are AD groups associated with each firewall named something like AAA Network Access, BBB Network Access, etc.  A user may have membership in one or several of these AD groups.  So the brute force method is:

If device-name = "AAA-ASA" check "AAA Network Access" membership

If device-name = "BBB-ASA" check "BBB Network Access" membership

etc...

How can I write the policy so that I plug in a variable name and check once?  Something like

$Site = substring(device-name, 1, 3)

check ${Site}+" Network Access" membership

Can that be accomplished?  The variable wouldn't necessarily need to come from the device name.  Maybe some other RADIUS attribute.

[howon]

Can you elaborate, still not clear on what the goal is? Also, can you share how many FW there are? Depending on the number it maybe easier to manually create rule per FW.

[jedavis]

There are 30 - 40 firewalls.

The goal is to maintain a single AD group that governs access to network resources.  So in DOMAIN-A there is a group that is used to permit access to DOMAIN-A resources.  But I want users from DOMAIN-B to also be able to authenticate and gain access to those DOMAIN-A resources.  Now I could just create a group within DOMAIN-B to permit access to those DOMAIN-A resources.  But now I have users within groups that are scattered across domains.  If I want to see who has access to DOMAIN-A resources I need to check a group in each domain, and I would like to stay away from that.

Any ideas?

Thanks!

[howon]

Not sure if you can achieve that in a simple manner if group membership is used. If you don't mind writing tunnel group that user should get in one of the user attribute, you could send back an attribute to lock the user to specific tunnel group name.

1. Designate attribute just like the video, but populate it with tunnel group name
2. Create AuthZ profile with advanced attribute "CVPN3000/ASA/PIX7x-Tunnel-Group-Lock (85) = AD1:{Attribute_For_Tunnel}" > ISE will dynamically pull tunnel group name from AD and send it back to ASA
3. Adjust policy to send back Authorization profile created above

[jedavis]

Your suggestion is a little outside my comfort zone but I think I somewhat understand what you are suggesting.  The problem is that the users do not have a one-to-one relationship with the network resources they access.  In other words, USER1 in DOMAIN-A may have access to resources in one or many of the other domains.

But I did get this working.

1. Create AD groups DOMAIN-B\DOMAIN-B_access-group and DOMAIN-A\DOMAIN-B_access-group.  These are both universal AD groups (though I think that the DOMAIN-A\DOMAIN-B_access-group can probably be local - I haven't tested yet).
2. Place DOMAIN-A\USER-A in into group DOMAIN-B\DOMAIN-B_access-group
3. Nest group DOMAIN-B\DOMAIN-B_access-group within group DOMAIN-A\DOMAIN-B_access-group.

So now my authorization policy checks to see if DOMAIN-A\USER-A is in group DOMAIN-A\DOMAIN_B_access-group. And it succeeds.  So what does this do for me?  It allows me to place all users with access to DOMAIN-B resources into a the single group DOMAIN-B\DOMAIN-B_access-group.  And similarly for all of the other domains in the forest.  Domain admins for each domain can control access to their own resources.  All ISE AAA operations are performed against DOMAIN-A.

So to summarize, each domain may have contain many different sites.  A universal group will be created for each site in the domain that site is a member of.  This universal group will contain only users, but may contain users from any domain in the forest.

DOMAIN-A will also contain a single local group for each site within the other domains.  This local group will only contain the nested universal group for that site.  The sole purpose of this container group is to allow AD authentication and authorization using DOMAIN-A for any user, from any site to gain access to resources at any other site.

Thanks for you help with this!