Been working through options for gathering userID data on non-domain-joined machines lately, so here's another complete option using Kerberos (krb) SSO.
Create a user in AD (my example, username: krb.palo), check the boxes for:
NOTE: this account is only a member of “Domain Users”, no special privileges
NOTE: this screen capture was taken after running the console commands, so the "User logon name" already shows the SPN
Issue the “setspn” and “ktpass” commands/parameters in the AD server to generate a krb keytab file.
Examples:
(your CP URL) (AD user)
setspn -s HTTP/cp.praktikl.com krb.palo
(your CP URL) (AD domain) (AD user) (AD user pwd)
ktpass /princ HTTP/cp.praktikl.com@PRAKTIKL.COM /mapuser PRAKTIKL\krb.palo /pass !QAZ2wsx /out (*TRUNCATED*)
(Location to save keytab file)
c:\users\domain.admin\desktop\portal.keytab /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1
You can see the file created on the desktop above the console window.
On the Palo, add a krb server profile listing all the DCs you want to include.
On the Palo, create a new authentication profile of kerberos type with the realm and domain (use the netbios name for "User Domain" to ensure proper recording by the FW, if you include “.com, .gov, etc”, format will be “domain.com\user”). Username Modifier didn't seem to make a difference, but still used the "down-level" logon format. In the Single Sign On section, import the keytab file generated on the AD server.
On the Advanced tab, add the user group that has allow access (for this example, used “domain users”).
Next, under “Device/User Identification”, configure the Captive Portal. Check the enable box, tweak the timer values if needed, add the kerberos auth profile, and set up a redirect to a URL (in this case, cp.praktikl.com). You’ll need a DNS record for this and an L3 interface on the firewall for it to connect (will configure that in a next). Also, add in an SSL/TLS Service Profile with a cert containing SAN entries for the URL (using cert w/ *.praktikl.com).
Configure an interface management profile if needed and allow “ping” and “response pages”.
Set up an L3 interface to terminate the redirect (keep it in the same zone as the internal zone for boundary traffic and add the Interface management profile previously created). Create a separate virtual router with a static quad-zero route and add the new interface to it.
Create a DNS A record.
Lastly, create the Authentication Policy. Set the zones according to the traffic, set the user to “any”, set the ports to whatever you need (http/https), add the URL category for the traffic you want to authenticate, and then choose the “default-browser-challenge” option to prompt the user for creds.
NOTE: Destination URL needs to be decrypted
For testing, verify there is no user cache for the test user/IP you plan to use. In this case, I’m coming from 192.168.3.7. Since I do not have an IP-user-mapping, it is “unknown”.
When I try to browse to https://www.slack.com, I get redirected to “cp.praktikl.com:6080” and the login prompt comes up.
Once I log in, my mapping is created and I’m good to go. You see the mapping is from “SSO”.
The default userID timeout is 60 mins, and the default auth policy cache timeout is 60 mins as well.
An interesting byproduct of this method: you're authenticating against your kerberos realm, so in the case of active directory, you are literally authenticating via the domain, and if using agents pointed to active directory, the agent will populate a IP-user-mapping too.
Also, if you're using username/password for login, use the down-level logon format "DOMAIN\USER" versus user principal name "user@domain.com". This will ensure your IP-user-mapping entries stay consistent and are able to line up with groups acquired via ldap.
