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

FMC FTD RA VPN User Attribute Map

JGB_GtmK_CJoN
Level 1
Level 1

Cisco Community,

We have an FMC managing a set of FTD's serving as RA VPN concentrators.  We are using LDAP Attribute Maps to apply policy to user's Anyconnect VPN connections based on AD group MemberOf.  Everything is good except we came across a situation where a user is now a MemberOf two different AD groups that are part of our configuration.  Looking to solve the issue where this user's (and potentially others) VPN policy will match one Group Policy over the other. 

Under the Realm's LDAP Attribute Map, can we adjust the order of the LDAP Attribute Value Maps from Top - Down to select a hierarchical first match? 

For example:  

Let's say User-A is member of the top LDAP Attribute Map: IT-Operator --> Group Policy = IT-O (more restrictive) and is now also member of 2nd in line LDAP Attribute Map: IT-Superuser --> Group Policy = IT-S (less restrictive).  If we switch the IT-Superuser to the be 1st in line, will User-A get this policy instead of the IT-Operator policy when they establish a RA VPN connection?

(using this image to illustrate - swapping Blue & Red so that Red is 1st in line)

Sample LDAP Attribute Map.png

FMC & FTD's are on 7.2.5.

P.S.  

Hope it's OK, tagging some of the senior community members on this:

@Rob Ingram 

@Marius Gunnerud 

@MHM Cisco World 

@Marvin Rhoads 

Thanks in advance!

4 Replies 4

tvotna
Spotlight
Spotlight

What you're asking about is called "multi-valued attributes problem", when few <group> names are returned from AD via LDAP for the same user and they need to be matched against <group> names listed in the "ldap attribute-map": "map-value memberOf <group1> <group-policy1>", "map-value memberOf <group2> <group-policy2>", etc. This problem exists on ASA for decades, but nobody cares. FTD inherits this code from ASA, so the problem remains the same.

I'm not sure about the exact order of comparison, but it might not be trivial. It might be that all values received from AD are first matched against 1st "map-value" configuration line, then against 2nd, etc, but CSCub64284 disagrees. You actually need to open TAC case and ask engineer to provide details, which are available in internal notes of the bug CSCub64284. Also, I'm not sure if it is guaranteed that FTD generates CLI in the same order as you see those "value maps" on FMC or FDM screen. You can ask this question too.

Also, there is an enhancement request which has never been implemented:

CSCub12834 Enhancement - LDAP attribute mapping with explicit precedence

Because it has never been implemented (although code change could have been trivial), it is recommended to use another AD field, such as Department or something like this (a "single-value attribute"), and use it to map users to RA VPN group-policies. But in this case all users need to be assigned correct Department first.

Unlike LDAP attribute-maps, DAP supports multi-valued attributes. It takes [1st] CN from returned memberOf and finds all matching DAP records, then aggregates all "network-acl" values from them by priority and assigns resulting ACL to a user. This aggregation is obviously to assign ACL, it cannot be used to assign group-policy to a user. DAP is supported in FTD 7.0+, although I've never tried.

 

@tvotna thank you for the very helpful details!

I took a look at the CSC's.  It would be great for this to have a clean resolution - buildout would be efficient with predictable results.  I had 3 different resources provide guidance to the effect that 1st match is top-down on the FTD's, and I tried it but it did not work.  (I tried to transfer this thread to Sec FW but couldn't so I ended up getting some great insight on the 'sister' thread)

I'll let you know how the TAC engagement goes.

Question on DAP - Does DAP compliment an LDAP Attribute Map approach as described above or does it get used in place of? 

 

@JGB_GtmK_CJoN, DAP is not a replacement for LDAP attribute-maps. In its current form it can allow or block AnyConnect connections by evaluating endpoint security attributes, such as AV/AS/OS/hotfixes/AnyConnect version/user certificate/etc., and AAA attributes, such as username, memberOf, tunnel-group, group-policy, etc. Endpoint attributes are provided by hostscan package with OPSWAT library downloaded to endpoint from FTD. DAP has powerful matching facility (not only you can combine attributes with AND/OR conditions, but also can use Lua scripting), but it is very limited when it comes to assigning parameters to AnyConnect connection. You cannot assign group-policy with DAP, unless something has changed recently. You can only assign filter ACL and maybe few AnyConnect custom attributes.

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/740/management-center-device-config-74/objects-object-mgmt.html