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 [](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

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…

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

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


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