Cisco ISE 2.6 - Multiple policy match or mutliple shell profiles?

[Dennis.de.Vries]

Hi,

We are looking for a solution for the following situation/goal;

RBAC:

Active-directory group membership (also nested one's) in two different domains (we got that sorted out via the "All_AD_Join_Points" group) are oure external identity sources that should give access to several different ADOM/VDOM's (FortiManager, FortiGate, FortiAnalyzer etc) depending on the membership of the account.

Use case:
We have customers A,B,C,D,E,F,...X,Y,Z. An administrator requires access to customer ADOM/VDOM A,G,P,Z to manage them with the corresponding rights (modify/read-only).

As far as I can see this is not possible within Cisco ISE. There are 2 problems;

1. After matching the first customer policy, in my example customer A, ISE will stop checking the rest of the policies and apply this matched policy and it's included shell-profile (where you set the ADOM/VDOM variable). So it is missing customer G, P, Z  on the device which he wants to manage.
2. You can only push one shell profile. Any other/newer shell profile will overwrite the old one. 

Currently I have added 2 ADOM/VDOM's in one shell profile and that works but this is not the way to go. Since we need this to be seperately per customer. A different administrator could require access to different customers and should not be able to access the one's he does not need.

Cisco TAC also told me that this is a limitation and not possible. But I just want to check the community if there is anyone out there with a customized smart solution for this. And if this is just not possible at all, are there any other products besides Cisco ISE that could possibly support our goal? I read somewhere that it was possible in version 2.2 to use multiple policy match, but I guess you would ran into the one shell-profile problem.

Thank you in advance for replying!

Gr.
Dennis

[Arne Bier]

Hello Dennis,

I don't know much about Fortigate and what ADOM/VDOM means in practice, but I was wondering if the customers can be identified somehow via ISE Device Groups - e.g. does each customer have its own IP address? Or is this some kind of multi-tenant solution?

Authentication is the easy part - lookup the user in one or more AD domains - I am sure that part you've figured out.

But the authorization is where you're stuck.

So we need to understand how the request comes into ISE: Is this RADIUS or TACACS+ ?

Does the Fortigate send any attributes during authentication that ISE can use to inform it about the context of the login?

If your admins are members of multiple customer support accounts (e.g. A, G, P , Z) then how do you suppose the Fortigate should know what the admin's intentions are about which one of those customers it wants to access? This is the part I don't understand. If you could explain that in more detail then perhaps we can find a solution.

A typical example from RADIUS/TACACS+ device admin is that we tag every device in ISE with a TYPE or a LOCATION.

e.g. for a Cisco switch in Building A we would use DEVICETYPE = Switch, LOCATION = BuildingA

And in the Policy Set logic we can use if/then to determine who/what/where we are dealing with and make decisions. You can even tag additional things that tell you more about a device, to allow you to make rules from complex. 

[Dennis.de.Vries]

Hi Arne,

Thanks for replying.

I realize now that I have not shared enough information around our situation to clarify things. Sorry about that. Let me explain our case a bit further;

FortiGate/FortiManager/FortiAnalyzer VDOM means Virtual DOMain. This means you can run multiple virtual instances on the device. So you have 1 firewall but actually can run e.g. 8 virtual firewalls (VDOM) on the device. We have this setup per customer to keep things seperated. That also counts for the FortiAnalyzer. The FortiManager works with ADOM, Administrative DOMain. You add the VDOM's under the ADOM to administer them all, they share the object database for example and other things.
The goal of all this is seperation per customer administrator in our company (we are a managed services company for other companies).

For that reason we want to allow an administrator to a specific ADOM and/or VDOM. And our goal is by doing that via RBAC on our Cisco ISE 2.6 (we will upgrade to version 3.0 this year FYI).

Our network devices (Forti***) communicate with ISE via TACACS+. We have divided them into groups and device type. Based on the device type we run the policy, do the authentication and then authorization.

As you said, we have the multiple domain search figured out. The only little sidenote (not for this discussion/question but just to share) is that we need to add the UPN suffix because our user name exists exactly the same in both domains. ISE recorgnizes which domain password you use, but authorization is confused about this as it receives the wrong username and then fails. We are going to create a rewrite policy for this, but that is a different topic

We are indeed stuck on the authorization part, as we can only match one policy and push one shell profile. As far as I know and can find.

The Fortigate uses attributes like: 
memberof
admin_prof
adom
service

More information about this can be found here:
https://community.fortinet.com/t5/FortiAnalyzer/Technical-Tip-How-to-configure-TACACS-for-authentication-and/ta-p/190839?externalID=FD41679

With "intentions" you mean, what rights do they have? We have 3 groups in place for that, read-only, admin, superadmin. Based on the active-directory membership that matches with the corresponding policy we give them the rights they need on the device.

This information is processed via the shell profile in the matched policy. e.g. memberof=read-only (mandatory), adom=A (mandatory) <- is the customer ADOM/VDOM.

We use the same tagging mechanism as you described.

I hope this additional information will give more insights for a possible solution in our case.

Thanks!

[Arne Bier]

that makes a lot more sense now - thanks.

Have you attempted this?

Note:
For the authorization override to work, make sure to enable the following setting:

#config system admin tacacs
    edit <server-name>
       set authorization enable
    next
end

If this setting is disabled, FortiManager/FortiAnalyzer will not send Authorization request to the TACACS+ server and the override options will not work.

I assume you have - but in any case, I think this is the trigger to ISE - it will request Authorization to ISE - and based on your ISE Policy Set, you can then return the particular attributes as shown in the table below:

[Dennis.de.Vries]

Hi Arne,

Thanks again for helping me on this.

The attributes are send correctly. So, indeed the authorization part works by itself. 

The problem we are facing is that we have several virtual instances on the device (ADOM/VDOM). And you can only push 1 authorization profile, if you push multiple, it will overwrite the old one.
I was able to set multiple ADOM/VDOM's in one shell profile by simply adding the required adom's:
Under Policy Elementes -> Results -> TACACS Profiles
Edit or create a new profile:
Custom attributes

Type: mandatory
Name: adom
Value: A (this is the adom/vdom example name)

Type: mandatory
Name: adom
Value: G (this is the adom/vdom example name)

Type: mandatory
Name: admin_prof
Value: Restricted_User (this is the local group on the device with specific rights, in this case read-only)

This is tested and works. The problem now is, that not all of our administrators require access to both ADOM/VDOM's. That is why we use active-directory groups memberships. So if an administrator like admin1 is member of active-directory group customer A, G, P, Z,  (so 4 shell profiles in this case) we want to give him access to the corresponding ADOM/VDOM's.
If a different administrator admin2 is member of customer groups A,P,R it should only have access to those specific ADOM/VDOM's.

I think this is technically achievable from ISE, but the feature of something like merging shell profiles based on active-directory group membership is simply not there. Maybe I should request this at the Cisco ISE development team. But if we are the only one's using it this way, they probably won't spent time on it, but I can always try.

If you, or anyone else in the community, have another idea or solution I am open to it.

[Arne Bier]

Hi Dennis,

I get it now - so it's impossible to know in advance, which combinations of customer profiles the admins would need, such that you can created them all in ISE (manually) and then assign them to Authorization Profiles based on AD Group membership.

I have an idea. It is possible to add custom AD User attributes to each admin's AD account, and then you could have one Authorization Profile for everyone, and get the exact customer list from AD itself.

Making an assumption that there is a max of 10 customers (in my example) - then if the AD user object can be amended to have attributes like Customer01, Customer02 ... Customer10 - each one can contain a string value {A, B, C ... Z} - then import those ten attributes into ISE and refer to them in you TACACS Authorization Profiles. It would work on the assumption that empty values (such as ado="") will either not be sent by ISE (because value from AD is empty) or the Fortigate simply ignores them.

The hardest part might be to change the AD schema to add the customer attributes in.

It would be nice if we had some kind of scripting point to allow some flexibility when constructing dynamic authorization profiles.

[Dennis.de.Vries]

Hi Arne,

Thanks again.

This does look like a possible solution for our use case.

We've (my colleague) found an article that describes the dynamic authorization profile a bit more in depth, similar to what you are proposing (we actually found this article thanks to you),let me share the link (for other readers too):

EDIT: while working on this with the link I shared below, I realized that the link is more about dACL (Dynamic ACL's). It is a bit in the same category but a different approach. I will continue to work like you described in your post Arne.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/212419-configure-per-user-dynamic-access-contro.html

/EDIT
I will configure this in our test environment and will let you know the result. I hope I will have the results latest by the end of next week. Our test environment currently only has 2 ISE nodes that are HA (config) partners and 2 active-directory domains joined, that is it. No policy objects or rules in place yet. So that will consume a bit of time too.

To be continued....

[Arne Bier]

Hi Dennis,

I am interested in this too because it's something a bit different than the usual questions we get. And I enjoy working with the RADIUS protocol for some weird reason

I have to admit, after thinking about it, adding additional, custom attributes to AD might not be as straightforward as I made it sound. I am not 100% sure but I think it requires updating the Windows AD Schema - not something you really want to do for just one small use-case.

If these attributes are only to be used to help ISE return the correct TACACS+ attributes, then you might as well create the admin user accounts in ISE, and use custom user attributes in ISE. Same concept as I mentioned before, but as the ISE admin, you can add custom user objects very easily.  ISE Menu: Administration > Identity Management > Settings > User Custom Attributes

I had a look in ISE 3.0 and there is no way to use Custom User attributes in TACACS+. I hope you haven't got your heart set on using TACACS for this purpose. Because you can use RADIUS instead - and in fact, it is a bit more flexible.

I read this article here that talks about the RADIUS attributes needed for FortiAnalyzer. It's VERY GOOD!

ISE doesn't come with any Fortinet RADIUS Dictionary included. But you can import the Dictionary if you look at this great article.

Once that is done, I found that I had to edit the dictionary slightly with one checkbox to allow multiple copies of the "Fortinet-Vdom-Name", since you want to return more than one of these in the RADIUS Authorization Profile.

And then construct the final RADIUS Authorization profile to return whatever a FortiAnalyzer needs, and listing all the possible user Customer attributes (many of which might be blank too).

By the way, if there are any missing RADIUS attributes in the custom Dictionary that you can download from the link above, then you can add them yourself. e.g. I didn't see any ADOM attribute - not sure if you need it - perhaps they use the Vdom attribute to mean both.

Below are the contents of such a custom RADIUS Dictionary that you can import into ISE as a file

VENDOR Fortinet 12356
BEGIN-VENDOR Fortinet
ATTRIBUTE Fortinet-Group-Name 1 string BOTH
ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr BOTH
ATTRIBUTE Fortinet-Vdom-Name 3 string BOTH
ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets BOTH
ATTRIBUTE Fortinet-Interface-Name 5 string BOTH
ATTRIBUTE Fortinet-Access-Profile 6 string BOTH
ATTRIBUTE Fortinet-SSID 7 string BOTH
ATTRIBUTE Fortinet-AP-Name 8 string BOTH
ATTRIBUTE Fortinet-FAC-Auth-Status 11 string BOTH
ATTRIBUTE Fortinet-FAC-Token-ID 12 string BOTH
ATTRIBUTE Fortinet-FAC-Challenge-Code 15 string BOTH
ATTRIBUTE Fortinet-Webfilter-Category-Allow 16 octets BOTH
ATTRIBUTE Fortinet-Webfilter-Category-Block 17 octets BOTH
ATTRIBUTE Fortinet-Webfilter-Category-Monitor 18 octets BOTH
ATTRIBUTE Fortinet-AppCtrl-Category-Allow 19 octets BOTH
ATTRIBUTE Fortinet-AppCtrl-Category-Block 20 octets BOTH
ATTRIBUTE Fortinet-AppCtrl-Risk-Allow 21 octets BOTH
ATTRIBUTE Fortinet-AppCtrl-Risk-Block 22 octets BOTH
ATTRIBUTE Fortinet-WirelessController-Device-MAC 23 integer BOTH
ATTRIBUTE Fortinet-WirelessController-WTP-ID 24 string BOTH
ATTRIBUTE Fortinet-WirelessController-Assoc-Time 25 string BOTH
ATTRIBUTE Fortinet-FortiWAN-AVPair 26 string BOTH
ATTRIBUTE Fortinet-FDD-Access-Profile 30 string BOTH
ATTRIBUTE Fortinet-FDD-Trusted-Hosts 31 string BOTH
ATTRIBUTE Fortinet-FDD-SPP-Name 32 string BOTH
ATTRIBUTE Fortinet-FDD-Is-System-Admin 33 string BOTH
ATTRIBUTE Fortinet-FDD-Is-SPP-Admin 34 string BOTH
ATTRIBUTE Fortinet-FDD-SPP-Policy-Group 35 string BOTH
ATTRIBUTE Fortinet-FDD-Allow-API-Access 36 string BOTH
ATTRIBUTE Fortinet-Fpc-User-Role 40 string BOTH
ATTRIBUTE Fortinet-Tenant-Identification 41 string BOTH
ATTRIBUTE Fortinet-Host-Port-AVPair 42 string BOTH
END-VENDOR Fortinet

[Dennis.de.Vries]

Hi Arne,

Thanks again for the extensive and detailed explanation, I really appreciate the way you are trying to think with me for a proper soloution.

I finally (had a busy week) had a talk with our architect about changing the AD scheme and the way we found a possible solution for this. But the architect declined the proposal since it would be to much manually managing the admin accounts and we have a lot of admins. That's why we want to keep it centralized managed via ISE and active-directory.

Which comes to the conclusion that we perhaps have to step away from our TACACS+ idea and go with what you already proposed; use RADIUS. I also found out that there are missing attributes for letting the FortiGate know which VDOM an admin is allowed to manage, while this is indeed already avalaible via RADIUS as you also showed in your example.

So, I will start configuring the RADIUS settings in our test environment and maybe will use RADIUS for all our FortiNet products. As the FortiAnalyzer and FortiManager do understand the adom=CUS01 but we run into the same problem with multiple VDOM's rights.

I will update my progress about this in this post.

To be continued.