Captive Portal authentication as a replacement for Checkpoint Client Auth

[johndickson]

Hello,

We're in the process of replacing a number of checkpoint firewalls with Palo Altos and we're looking at ways in which we can replace the current Client-Auth setup on Checkpoint where you telnet to the firewall directly, authenticate, and it then allows you access to the applications you require.

Obviously the solution is the captive portal setup on Palo Alto as the users are using a radius server for their authentication services (so user id via AD won't work), however none of the applications they're using are web based so we can't intercept the session, and from previous use of the captive portal you have to have a responsive web server to intercept and provide the captive portal login page.

Has anyone come across this before, can you authenticate directly to the Palo Alto firewall as with telnet on the Checkpoints? Or do I have to setup a dummy web server just to use as a target for them to be intercepted and authenticated against, prior to them accessing their non web applications?

Any suggestions much appreciated.

Regards,

John

[VinceM]

Hi,

For me, authent like you did with CheckPoint,is  not possible with palo.

Solution for you:

     - Captive portal: Match radius but only for htt and or https

     - vpn

          * Global protect: free in majority of cases and can be connected to radius but you have to deploy client. IF users are remote, good solution, if users are on                lan, can use internal gateway (https://live.paloaltonetworks.com/docs/DOC-3930) in this case, you need licence.

          * Other vendor: good solution, maybe client already deploy but only is users are remote.

Hope help.

v.

[goku123]

You can also explore the option of using the XML API on the userID agent to feed login/logoff messages from your RADIUS authentication logs. Although this will need some work externally with a custom script.

Some examples are available on the DevCenter community. The DevCenter would be an excellent resource if you decide to look into the XML API. A perl module is also available to help with this: https://live.paloaltonetworks.com/docs/DOC-1662

[cchristiansen]

Have you thought about using custom application signatures and then using those in your security policies, in conjunction with UserID?  Here is a document on Custom Apps:

Creating Custom Application Signatures

There are lots of other documents in the knowledgebase that can help you as well.

Good luck!

-chadd.

[johndickson]

Thanks for all your suggestions, it would appear as though there's no easy resolution for this, I think using a dummy website as a target for autheticating users based on a NAT on the existing firewall interface address might just be easier.

So instead of telnetting to IP 192.168.1.1 as they do with the Checkpoint, they'll just put in http://192.168.1.1 which will NAT to the dummy website behind the firewall and allow the captive portal to intercept for credentials and user identifcation, which upon authenticating passes the session through to the dummy site which just hosts a page showing "You have authenticated successfully".

Regards,

John

[johndickson]

Just as an update to this, I've managed to find out a few more things about the Captive Portal that might be useful for others.

Providing a mechanism for authenticating users where a web service is not available in the DMZ or network you wish to access: A bit of a bodge here, but you can make a direct request to the Palo Alto to authenticate you, and then perform a redirect on the destination of your chosing.

For example, https://10.1.1.1:6081/php/uid.php?vsys=1&url=http://www.google.co.uk

Where 10.1.1.1 is your Palo Alto interface address that's configured for User Identification, upon successfully authenticating the user is directed to http://www.google.co.uk out of their standard internet access, meaning that you have now authenticated on the firewall and can access the non web services.