Client Auth Replacement

[David_C1]

Hi everyone,

We have been using Client Auth in our firewall policies just about forever. These rules are used to limit exposure to our most critical assets by requiring MFA (we use SecurID as the authenticator) before a user can access certain assets. These assets have a variety of different access methods - https, ssh, and a number of "non-standard" ports/interfaces.

I have heard the rumblings that Client Auth will someday go away, and I need an alternative that meets the following:

1. Requires MFA (SecurID) on part of the user

2. Supports protecting hosts that are not a web server/site

Captive portal looks like it could meet the first objective (leveraging Radius) but not the second. Any other suggestions? Am I missing an option?

Thanks,

Dave

[_Val_]

Client Auth is called legacy authentication for a reason. It is not developed for quite a few years. Moreover, legacy authentication is really bad for performance, as it disables acceleration templates.  

What you want to do is to use Identity Awareness. If client based, it covers both your points transparently. If you do not want to install IA clients, or if those PCs your users are accessing from are unmanaged, users can sign into IA portal before accessing protected assets. 

[David_C1]

Thanks Val,

We do use IA awareness (via AD Query) to control access to certain resources. We still use Client Auth because we can require a user to use MFA before accessing our most critical resources (and honestly, because IA has not been 100% reliable). If I can replicate this with Captive Portal, I will use that, but from what I see in the documentation:

Captive Portal is a simple method that authenticates users with a web interface. When users try to access a protected web resource, they enter authentication information in a form that shows in their web browser.

My bolding. Does this mean Captive Portal only works when trying to access something via http/https?

Thanks

Dave

[PhoneBoy]

When accessing a protected resource via http/https, if they are not identified, they can be redirected to captive portal, yes.
If it's not via http/https, that redirection can't happen, but they can use the captive portal via https to authenticate themselves and access the resource by whatever mechanism is required.
Which, incidentally, is no different than Client Authentication.

[_Val_]

As Dameon already answered, and mentioned before him :-), for non-Web services you will have to authenticate on Captive Portal explicitly. 

[David_C1]

Perfect, that's the answer I was hoping for. Thanks PhoneBoy (and everyone else who provided help).

Dave

[David_C1]

One follow up question --

Since we already use IA with AD Query, can AD Query to be used for certain IA rules, and for other rules can I force the use of manual Captive Portal (and RADIUS, with which I can leverage our SecurID MFA) for other rules?

Thanks

Dave

[PhoneBoy]

However the identities are acquired, be it AD Query, RADIUS, Captive Portal, they are represented by Access Roles.
Assuming the users who authenticate differently can be represented by different Access Roles, you should be able to do that.