Kerberos SSO for Captive Portal

cancel
Showing results for 
Search instead for 
Did you mean: 

Kerberos SSO for Captive Portal

L1 Bithead

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:

  • User cannot change password
  • Password never expires
  • This account supports Kerberos AES 256 bit encryption

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

 

jbworley_0-1641995839136.png

 

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.

jbworley_1-1641995839170.png

 

 

On the Palo, add a krb server profile listing all the DCs you want to include.

jbworley_2-1641995839174.png

 

 

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.

jbworley_16-1641997811010.png

 

 

On the Advanced tab, add the user group that has allow access (for this example, used “domain users”).

jbworley_4-1641995839178.png

 

 

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).

jbworley_5-1641995839180.png

 

 

Configure an interface management profile if needed and allow “ping” and “response pages”.

jbworley_6-1641995839181.png

 

 

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.

jbworley_7-1641995839182.png

 

jbworley_8-1641995839185.png

 

 

Create a DNS A record.

jbworley_9-1641995839199.png

 

 

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

jbworley_10-1641995839199.png

 

jbworley_11-1641995839201.png

 

 

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”.

jbworley_12-1641995839202.png

 

 

When I try to browse to https://www.slack.com, I get redirected to “cp.praktikl.com:6080” and the login prompt comes up.

jbworley_13-1641995839209.png

 

 

Once I log in, my mapping is created and I’m good to go.  You see the mapping is from “SSO”.

jbworley_14-1641995839212.png

 

jbworley_15-1641995839214.png

 

 

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.

1 REPLY 1

Community Team Member

@jbworley ,

 

Amazing stuff ! Thanks for sharing !

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Don't forget to hit that Like button if a post is helpful to you!
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!