04-30-2018 05:59 AM
I wanted to run a solution by the community to see if anyone sees a downside or a different way to do it.
I am working with Azure MFA for client VPN authentication but we want to get ISE involved. The Azure MFA RADIUS server doesn't seem to support RADIUS proxy servers so it won't pass back the Proxy-State AV pair that ISE requires when doing proxy mode RADIUS. I can get non-proxied RADIUS to work through ISE (token RADIUS server), but the MFA server requires all AV pairs to be passed from the ASA to fully work. So non-proxied is not an option.
So I thought about using the authorization feature on the ASA. The ASA will authenticate directly to Azure MFA RADIUS and authorize to ISE. RADIUS doesn't really have a concept of "authorization" like TACACS does. So when the request comes to ISE it tries to process a full authentication. There is no password in the packet so the authentication fails.
To get around the issue I set the authentication source to Internal Users, which we don't use, and told ISE to Continue on user not found. This allows ISE to process the authorization and everything works correctly. I can apply DACLs, SGTS, etc.
Anyone see an issue with this or am I missing something obvious.
Thanks.
Solved! Go to Solution.
04-30-2018 03:39 PM
Apologies as I did not realize that was an internal wiki. I don't see anything confidential so will re-post relevant parts here.
Originally posted by Ron Hinderer
PROBLEM DESCRIPTION
When using certificate based authentication in conjunction with Anyconnect VPN, the certificate authentication process terminates on the ASA. This is in contrast to EAP based certificate authentication whereby the Network Access Device passes the certificate through to ISE for validation. In the EAP scenario, ISE can perform detailed evaluation of certificate attributes and perform additional identity store lookups for group membership and discrete attributes. Since the ASA terminates the authentication process without passing the certificate to ISE, all attribute validation must be performed using the ASA built-in group policy capabilities and DAP. This leads to disjointed policy definitions for different access methods such as wired and wireless 802.1x. In addition, ISE offers a more robust policy capability versus the ASA built-in capabilities.
SOLUTION
Additional information apart from the username can be obtained by either:
As long as the actual identity store username appears at the beginning of the username value and is delimited by a predetermined character, the additional information can be evaluated in the Authorization Policy. The additional information must be stripped off before sending to the identity store. This can be accomplished using LDAP external identity configuration for the respective LDAP identity store. Examples of additional information to include; device type, personal or trusted.
Note: In order to prevent the possibility of unauthorized access using the “continue” identity source option, additional steps can be taken to lock this capability to a specific connection profile.
This can be accomplished by:
04-30-2018 03:39 PM
Apologies as I did not realize that was an internal wiki. I don't see anything confidential so will re-post relevant parts here.
Originally posted by Ron Hinderer
PROBLEM DESCRIPTION
When using certificate based authentication in conjunction with Anyconnect VPN, the certificate authentication process terminates on the ASA. This is in contrast to EAP based certificate authentication whereby the Network Access Device passes the certificate through to ISE for validation. In the EAP scenario, ISE can perform detailed evaluation of certificate attributes and perform additional identity store lookups for group membership and discrete attributes. Since the ASA terminates the authentication process without passing the certificate to ISE, all attribute validation must be performed using the ASA built-in group policy capabilities and DAP. This leads to disjointed policy definitions for different access methods such as wired and wireless 802.1x. In addition, ISE offers a more robust policy capability versus the ASA built-in capabilities.
SOLUTION
Additional information apart from the username can be obtained by either:
As long as the actual identity store username appears at the beginning of the username value and is delimited by a predetermined character, the additional information can be evaluated in the Authorization Policy. The additional information must be stripped off before sending to the identity store. This can be accomplished using LDAP external identity configuration for the respective LDAP identity store. Examples of additional information to include; device type, personal or trusted.
Note: In order to prevent the possibility of unauthorized access using the “continue” identity source option, additional steps can be taken to lock this capability to a specific connection profile.
This can be accomplished by:
04-30-2018 06:15 PM
Ahh yeah I thought of doing a similar with AD fail Auth but wanted to avoid and AD or LDAP query.
Sent from my iPhone
03-29-2019 12:06 PM
03-29-2019 06:58 PM - edited 03-29-2019 07:00 PM
New Features in ASA 9.2(1)/ASDM 7.2(1) has this feature ISE Change of Authorization
The ISE Change of Authorization (CoA) feature provides a mechanism to change the attributes of an authentication, authorization, and accounting (AAA) session after it is established. When a policy changes for a user or user group in AAA, CoA packets can be sent directly to the ASA from the ISE to reinitialize authentication and apply the new policy. An Inline Posture Enforcement Point (IPEP) is no longer required to apply access control lists (ACLs) for each VPN session established with the ASA.
When an end user requests a VPN connection the ASA authenticates the user to the ISE and receives a user ACL that provides limited access to the network. An accounting start message is sent to the ISE to register the session. Posture assessment occurs directly between the NAC agent and the ISE. This process is transparent to the ASA. The ISE sends a policy update to the ASA via a CoA “policy push.” This identifies a new user ACL that provides increased network access privileges. Additional policy evaluations may occur during the lifetime of the connection, transparent to the ASA, via subsequent CoA updates.
We introduced the following commands: dynamic-authorization, authorize-only, debug radius dynamic-authorization.
We modified the following commands: without-csd [anyconnect], interim-accounting-update [periodic [interval]].
We removed the following commands: nac-policy, eou, nac-settings.
We modified the following screen: Configuration > Remote Access VPN > AAA/Local Users > AAA Server Groups > Add/Edit AAA Server Group
09-24-2019 09:59 PM
Hi ,
any documents available on how to achieve this ?
Thanks
12-09-2019 06:17 AM
Just a note that this doesn't work on ACS 5.6. ACS did not honor the "continue" directive and just outright rejects the authentication for having a blank password, regardless of the identity store setting. LDAP authorization worked swimmingly however.
08-30-2023 09:18 PM
Can posture be implemented under this scenario?
08-31-2023 01:39 AM
Yes, just tested it.
However if you use always on VPN and/or cert auth for users you will posture the endpoints two times.
Better to apply posture only for the user connection if the above conditions apply.
10-17-2021 04:41 PM
Hi Paul,
Thanks for posting this. I am trying to achieve something similar but am not sure about the AuthZ policies.
We are using Okta for SAML authentication on the ASA where anyconnect users get authenticated.
I can see that I have to select ISE as the AuthZ server in the ASA group policy.
I am not clear on how to configure the ISE side. Do I need to add the ASA as a NAD with Radius checkbox ticked and a preshared key?
Or is adding the ASA as a NAD, on the ISE, not required?
Any direction would be appreciated.
Thanks,
Obaid
07-27-2023 09:36 AM
reviving this thread. Does anyone have videos on how to do this?
08-25-2023 05:20 AM - edited 08-25-2023 05:22 AM
I just configured this.
Created a separate AAA group on ASA for ISE where the authorize-only option is checked.
Assigned it to the respective tunnel-group's advanced/authorization section.
The tricky part was getting the correct username from the computer certificate. You can configure it at the same place.
I had to use a LUA script because only the following format was working to find the computer with an ISE AD query: host/hostname.domainname
LUA script to achieve it if the CN looks like this in the cerrtificate hostname.domainname:
return 'host/'..cert.subject.cn
On ASA you can check the script with this command: more disk0:/username_from_cert.xml
On ISE you dont need to do anything with the authentication policy part, create a new authorization rule where you query the tunnel-group name, AD membership (ie. DN, CN etc.), service type = authorize-only.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide