{"id":1617,"date":"2023-02-22T08:00:00","date_gmt":"2023-02-22T14:00:00","guid":{"rendered":"https:\/\/packitforwarding.com\/?p=1617"},"modified":"2023-02-21T20:18:59","modified_gmt":"2023-02-22T02:18:59","slug":"captive-portal-palo-alto","status":"publish","type":"post","link":"https:\/\/packitforwarding.com\/index.php\/2023\/02\/22\/captive-portal-palo-alto\/","title":{"rendered":"Captive Portals and Not So Captive Portals"},"content":{"rendered":"\n

A few years ago as I was first cutting my teeth in the Palo Alto firewall world, I had a customer request something “unique” and I created a one-off solution. The request was to have a stand-alone portal that the end-users could go to and log in to gain additional access to resources. The reason for this was BYOD and other non-managed devices that wouldn’t show up in User-ID through the normal User-ID agent polling Windows. The traditional captive portal wasn’t a good fit either as the customer didn’t want to purchase a 3rd party signed TLS certificate. So I pulled out some PHP and created a very simple portal that did an LDAP authentication and then used Palo Alto’s XML-API to send a username and IP pair to the firewall. This worked well until recently when that server started to have issues after upgrading to PHP 8.1. <\/p>\n\n\n\n

Opportunity!<\/h2>\n\n\n\n

I took the issues with the PHP application as a sign to do something better. By this point, I knew a lot more about the Palo Alto firewalls and decided it was time to try going through the captive portal documentation again and see what I could do. I set up a standard captive portal using the authentication policy. For the certificate, I used a certificate signed by the customer’s internal CA. I had an ulterior motive in getting the firewall set up as a SubCA so that we could implement SSL Decrypt. This all worked well, but it still didn’t give me the stand-alone portal that the customer’s users could just go to on their own… or did it?<\/p>\n\n\n\n

On a whim, I copied the URL that happened on the redirect and started playing with it. The default URL looks like this: <\/p>\n\n\n

\nhttps:\/\/FQDN:6082\/php\/uid.php?vsys=1&amp;rule=0&amp;token=AUFxGTIly7YWSbOPd3WWSaUquwU=&amp;url=https:\/\/example.com\n<\/pre><\/div>\n\n\n
So let’s take a look at this URL. The port isn’t “standard”, but everything else just looks like a PHP website that is passed a few values. Vsys is obviously there in case the Palo Alto firewall has multiple vsys operating. So by default, it will be 1 if there is only one vsys. The next parameter is rule. I’m fairly sure that this corresponds to the authentication rule and apparently is indexed starting at 0. The last two parameters are very much related to the redirection, so I thought why not just leave them off and see what happens? As it turns out it worked! Just passing the vsys and rule parameters created an entry in user-id.<\/p>\n\n\n\n
The next challenge was to get this to work without the BYOD devices needing to trust the internal CA. A Reddit post<\/a> gave me the secret sauce.<\/p>\n\n\n\n