Remote Access using RADIUS, DAP with LDAP attributes

[alexanderchance]

Hello,

I am deploying MFA for one of my customers using FTD managed by FMC version 7.0 and wondering if it is possible to do the following setup:

Using RADIUS for MFA-token, and then use DAP looking at LDAP attributes such as "memberof" to then restrict users based on their AD-membership. I have the RADIUS and LDAP configuration done and I am just trying to make it all work together.

Thank you in advance
Alexander

[tvotna]

Yes, this should work in 7.0.

[alexanderchance]

I figured as much, do you know how the configuration would look like? I have tried using both RADIUS and LDAP as authc servers but that doesn't seem to work as intended. I only need the LDAP attributes to use them when DAP is applied and not really any authc or authz.

[tvotna · Accepted solution]

To be honest, I misread your original question. So, you authenticate users via RADIUS (OTP) and want to control VPN access by checking their AD group membership. This is typically done by configuring LDAP authorization and using LDAP attribute-maps. In the attribute-map you can, for example, map memberOf attribute to a group-policy and assign necessary attributes by configuring them in this group-policy (allow or block access or assign DACL, etc.). There is a problem with this approach though: memberOf is a multi-valued attribute, so the mapping can be unexpected when the user belongs to multiple AD groups. Instead of memberOf some other AD attribute can be used for mapping, which is 100% reliable, but this requires setting of this attribute in the AD for each AD user. FTD supports LDAP attribute-maps in authorization since 6.7 if I'm not mistaken.

Now, if you want to use DAP instead of LDAP attribute-maps for some reason, e.g. to check endpoint security state (e.g. if AS/AV is present on the endpoint, etc.) and at the same time take into consideration AD group membership, things become more complicated. Since authentication is done by RADIUS, you still need to configure LDAP authorization if you want to use aaa.ldap.memberOf in DAP matching criteria. Also, I'm note sure if group membership received from AAA authorization phase is propagated to DAP. DAP evaluation of AAA attributes always happens after authentication and authorization, but I'm still not 100% sure. Debug dap 255 should help understand.

Or, instead of LDAP authorization, your RADIUS server used during authentication phase should return RADIUS attributes to be used in the DAP AAA matching criteria. E.g. the RADIUS server should be integrated with AD somehow to fetch AD group membership and send it to the firewall. E.g. it can BIND as admin user and then do LDAP SEARCH in AD for the authenticating user the same way as ASA/FTD does LDAP authorization. Obviously, some other AD attribute can also be used in this case, instead of AD group membership. On the firewall you can use this RADIUS attribute in the DAP AAA matching criteria as follows:

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/cluster/ftd_dap_usecases.html

For RADIUS attributes, DAP defines the Attribute ID = 4096 + RADIUS ID. For example, the RADIUS attribute "Access Hours" has a Radius ID = 1, therefore DAP attribute value = 4096 + 1 = 4097. The RADIUS attribute "Member Of" has a Radius ID = 146, therefore DAP attribute value = 4096 + 146 = 4242.

HTH

[tvotna]

Lastly, OTP RADIUS can be used for user authentication and ISE for user authorization (in authorize-only mode) and posture. On the ISE you can create authorization rules to check both tunnel-group the user connects to and AD group the user belongs to as well as device posture.

[alexanderchance]

Thank you @tvotna for the in-depth explanation, it really helped me understand what my options are in regards to this setup, and I have to rethink the solution based on this.