Cisco ASA and PrivacyIDEA

I’m trying to understand how to integrate an ASA for VPN authentication with PrivacyIDEA. It looks like we would configure the Cisco ASA to use RADIUS for authentication.

Would the ASA send the auth request to PrivacyIDEA and then PrivacyIDEA would proxy the request to a RADIUS box to verify username/credentials and the PrivacyIDEA server would merely authenticate the token?

Would we use the [https://privacyidea.readthedocs.io/en/latest/application_plugins/rlm_perl.html](http://RADIUS plugin) or just configure the RADIUS server under WebGUI>System>RADIUS Servers?

The RADIUS server configuration in the WebUI is to be used to configure a RADIUS, which privacyIDEA sends authentication requests to. See https://privacyidea.readthedocs.io/en/latest/configuration/tokens/radius.html

If you want privacyIDEA to answer RADIUS requests you need of course the plugin (rlm_perl)

How you do it is up to you or to consultancy.

So the RADIUS server in the WebUI is for authenticating users that are logging into the PrivacyIDEA webui?

Based on your comment, it sounds like we would use the RADIUS plugin to authenticate user tokens. The question then would be, does the ASA send the auth request to the RADIUS server, which then proxies a token auth request to PrivacyIDEA, or does the ASA send the auth request to PrivacyIDEA which then proxies the credential auth portion of the request to the RADIUS server?

I realize you’ve probably already provided as much as you are going to provide Cornelinux (After-all, it IS your business), but I’m hoping someone out there can provide some clarity, or better yet, a guide on their implementation.

Start here, written by Cornelius some years ago but still true

Authenticating to ASA - physical or virtual - works very well, we use it for years.
It allowed us to get rid of RSA completely…

1 Like

Thanks Henry, I’m trying to understand how it authenticates the user. It appears that FreeRADIUS is handling the user authentication in that guide? We have an existing RADIUS server that would be performing authentication. I just want to add PrivacyIDEA’s 2FA to the mix.

I envisioned it as being similar to the ADFS plugin. A user attempts to log into an ADFS enabled site. The user is redirected to ADFS for credentials and then, once authenticated, they’re prompted a second time for their OTP. I’d be fine if it took username and pin+OTP as well, I just need the authenticating system to be our existing RADIUS box.

That is correct.
I believe you can use your own RADIUS server, but i have never done it…

That’s how it works now with FreeRADIUS and privacyIDEA server all-in-one…

EDIT:
privacyIDEA can have its own user database (plaintext, SQL) but “prefers” external ones (e.g. LDAP).
Hence, you should try to import your existing RADIUS server user database into privacyIDEA…

Also, privacyIDEA can forward an authentication request to an external RADIUS server
https://privacyidea.readthedocs.io/en/latest/configuration/tokens/radius.html

While I never got confirmation from @cornelinux, I was under the assumption that PrivacyIDEA only forwards RADIUS requests for authenticating the WebUI…although that wouldn’t really be forwarding a request in the traditional sense of the word…:thinking:

This part of the project has been put on hold but I’ll see if I can weasel our WAN group into some covert testing…

I haven’t tried the myriad options privacyIDEA offers…
In fact I used very few of them:

  • local and LDAP (imported) users
  • TOTP/HOTP soft tokens (FreeOTP app)
  • Yubikey 4 (with NFC)
  • waiting for the ownCloud app update to try push tokens.

We use it for users “in the field” to record/update sensitive information on a backend server.
They run AnyConnect (laptop, tablet) to connect to ASA with a public Outside IP address.
On the Inside it connects to the data server (Windows) and privacyIDEA server(Ubuntu).
After being authenticated using either Yubikey (primary) or soft token OTP (secondary),
the user gets access to the data server…

We are looking into replacing the data server with Nextcloud/ownCloud.
And the firewall with Sophos XG (has its own clients; can talk RADIUS).

privacyIDEA has been very good for us, we’ll keep using it…

never is a hard work for not answering within 18h without SLA! :-p

The RADIUS server you configure in the webui are ment for:

a) forwardning-on-user-has-no-token
b) for RADIUS tokens

They are used for normal authentication requests against privacIDEA. Not only the WebUI.

This is a nice feature for migration!

technically, never is accurate, lol. I’m kidding, I realize we are in very different timezones…but respond faster, SLA be damned! :rofl:

The migration system that is mentioned in the article you linked is pretty cool. However, we aren’t looking to replace our existing RADIUS setup. We currently use RADIUS to also identify and assign resource permissions based on AD group memberships. We are just looking to add PrivacyIDEA as a 2FA provider. I imagine the dataflow being something like one of the below

ASA–>Username/pin+OTP–>PrivacyIDEA–>Username–>RADIUS
or
ASA–>Username/pin+OTP–>RADIUS–>pin+OTP–>PrivacyIDEA

I would imagine that the first flow is the more probable method, going to RADIUS first would seem like a more complicated plugin to develop.

Since the user database originates in AD, just import it into privacyIDEA.
And use it to login to ASA with a second factor…

After this first step is done, do what you do now.

What RADIUS server do you have now? NPS?

privacyIDEA can do a cool job about mapping attributes in RADIUS responses.
I never published this video in the youtube channel, since it is such a choppy video. And I never had time to do it anew:

1 Like

I currently use an LDAP resolver to pull users into PrivacyIDEA from AD, so that’s already being done. I think I’m over-complicating things. If we have the ASA contact PrivacyIDEA directly, using a realm that applies specifically to our authorized VPN AD group, then that would work. I’ll be talking to our wan guys tomorrow to figure out how all the pieces fit together and may redesign the system.

I’m not sure what RADIUS implementation we are currently using but will find out.

Thanks for the input all, I will update the post with the path I end up taking.

Just got around to watching the video. It may be choppy at the beginning but it’s full of great information. Thanks for sharing.

1 Like

@wwalker – If interested, we just finished doing exactly, I think, what you want. What we have is:

  • Cisco ASA 5516 redundant pair, ASA 9.12.2
  • Cisco ASDM 7.12.2
  • Cisco AnyConnect 4.7

AnyConnect, rather than old-school IPsec RA, is needed because it seamlessly handles the 2nd-level prompting for MFA credentials. (We upgraded to those specific latest versions because the translation tables necessary for changing the UI prompts had bugs.)

Our PI server is v3.0.2, and we link to AD users using the LDAP resolver. We use freeRADIUS 2.2.8 with the Perl plugin. Understand that the freeRADIUS plugin is intended solely to translate PI requests to RADIUS and then give back RADIUS-compliant answers. You are not populating RADIUS with any data or forwarding to Windows NPS, etc.

We use the PI server configured with otppin=tokenpin and login_mode=privacyIDEA. It’s a bit misleading that the login_mode is a webui policy, because that policy actually applies to any login including an API request via the RADIUS plugin.

The magic happens when you configure your AnyConnect profile to use a secondary authentication model. The first username/password applies to your LDAP query that (presumably) is being sent to NPS for domain credentials. The secondary RADIUS auth is then used to query freeRADIUS for the associated MFA token. You can have a secondary username/password prompt, or, since you are resolving to the same LDAP that PI is using, prompt only for the password using the common samAccountName:

tunnel-group AnyConnectVPN general-attributes
 address-pool VPN-POOL
 authentication-server-group ANYCONNECT-LDAP
 secondary-authentication-server-group PrivacyIDEA use-primary-username
 default-group-policy AnyConnect_No-Access

The setup works great for single-step TOTP/HOTP, which was to be expected. But to really blow your mind, it also works with Email and U2F because of the RADIUS challenge-response support and the ability of the AnyConnect client to understand that handshake and provide the necessary 2nd-level prompts. (Make sure users configure a PIN on their C-R tokens, because that is what is needed to trigger the appropriate challenge.)

Actually the login_mode policy applies to all requests for the /auth API-endpoint. It does not apply to /validate/check requests.

Thanks for all the information. The original plan, because we are already using it for other services, was to use ADFS and the ADFS provider for PrivacyIDEA to secure the VPN connection. Unfortunately, we are running on EOL’d ASAs that do not support the required IOS for ADFS authentication. This also includes the version of AnyConnect you are using. We are limited to AnyConnect 3.1

However, after talking with the right people and figuring out how the whole thing is put together (our VPN connection that is), FreeRADIUS with the RADIUS plugin seems to be the perfect solution. I’ve got it up and running in a test environment and using a pin+Ubikey in AES mode is fantastic.

This also includes the version of AnyConnect you are using. We are limited to AnyConnect 3.1

Why?
The latest AnyConnect - 4.8 on Catalina Beta, 4.7 on Windows - can be used to connect to ASA-5505.
What Cisco ASA do you have that limits AnyConnect to 3.1?

I’ve got it up and running in a test environment and using a pin+Ubikey in AES mode is fantastic.

Same here. Push token would be even better…:slight_smile:

I dont recall which ASAs we are running, they’re bigger than the 5505s but I was told the client limitation is based on whatever licensing we paid for/are no longer paying…whichever scenario it is.

@bhoule, I’ve gotten my head around all the RADIUS integrations as it currently stands, but how is challenge-response setup? I assume this could be used with PI’s questionnaire keys as well? Is it just a policy configuration that says something like “If the request is coming from this IP, only use questionnaire?”