Two good articles on setting up Kerberos SSO for User ID / Access to the Internet are

• here.
• here.

You will need to create a service account on the active directory domain. You need a service account for each gateway you are using (e.g. if you are using a redirect FQDN for Captive Portal and a couple of GlobalProtect gateways, you will need that number of service accounts. This is because a service account is required for each SPN (server Principle Name).

Make sure that these accounts have AES 128 and AWS 256 encryption supported under their account options in AD.

You will need to do this for each FQDN you are using.

setspn -s http/hostname.example.local example.local\kerberosuser

You should see output like this

>setspn -s http/redirect.example.local kerberosuser1
Checking domain DC=EXAMPLE,DC=LOCAL

Registering ServicePrincipalNames for CN=kerberos user1,CN=Users,DC=EXAMPLE,DC=LOCAL
        http/redirect.example.local
Updated object

ktpass -princ http/redirect.domain.local@DOMAIN.LOCAL -mapuser DOMAIN\kerberosuser -pass Password123 -crypto aes256-sha1 -ptype KRB5_NT_PRINCIPAL -out keytabfile.keytab

>ktpass -princ http/redirect.example.local@EXAMPLE.LOCAL -mapuser EXAMPLE\kerberosuser1 -pass Password123 -crypto aes256-sha1 -ptype KRB5_NT_PRINCIPAL -out keytabfile_redirect.keytab
Targeting domain controller: server1.EXAMPLE.LOCAL
Successfully mapped http/redirect.example.local to kerberosuser1.
Password successfully set!
Key created.
Output keytab to keytabfile_redirect.keytab:
Keytab version: 0x502
keysize 94 http/redirect.example.local@EXAMPLE.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0x1234567890987654321abcdefabcdef123456789098765432123456789098765)

(If you need to remove a mapping, run the following)

setspn -d http/hostname.example.local example.local\kerberosuser

You can list mappings with

setspn -l example.local\kerberosuser

You will need to import the generated file keytabfile.keytab into the Kerberos Authentication Profile

Let us say you are just doing User-ID, you will need to enable Response Pages on the data plane interface nearest the source traffic (e.g. the interface for the trusted zone). You 'may' need to enabled User-ID on the interface that has the IP associated with FQDN being used for captive portal. I found that on some systems, it didn't matter where it was and what I blocked, SSO would still work. Not sure why. However, you may need to enable User-ID on the IP interface (Interface Managment Profile) and TCP-6080.

You will also need to create an A and a PTR record for the FQDN in local DNS (e.g. redirect.domain.local ↔ 10.1.1.1).

Make sure that captive portal settings are set to redirect and not transparent.

Make sure that the captive portal certificate is a trusted signed certificate for the FQDN and IP.

Remember to create an authentication policy rule and make sure that the service includes HTTPS as well at HTTP. Authenticaiton enforcement should be set to

default-browser-challenge

. You will need to configure

When Kerberos succeeds, you get a system log (type:general, event:general, severity:informational). Description is 'SSO authentication succeeded for user: username@DOMAIN.LOCAL on 10.1.1.1, vsys1' (where 10.1.1.1 is the user's source IP)

If it fails, you get a system log (type:auth, event:auth-fail, severity:medium). Description is ( description contains 'Kerberos SSO authentication failed for user \'\'. Reason: Kerberos single-sign-on failed. From: ::ffff:10.1.1.1.' )

admin@firewall> show user ip-user-mapping all

IP                                            Vsys                From    User                             IdleTimeout(s) MaxTimeout(s)
--------------------------------------------- ------------------- ------- -------------------------------- -------------- -------------
10.1.1.1.                                     vsys1               SSO     DOMAIN\userame                   85             85    
Total: 1 users

For authenticating, the end client browser will interact with TCP 6080 on the firewall. This is not encrypted. If you set the redirect on the trust interface, you will see no traffic in the logs. To see traffic in the logs, you need to use a loopback.

Bear in mind that access to TCP 6080 on the firewall will bypass any and all security policy rules that you have set on the firewall.

I found the command was incorrect and I had to use the following to create the KEYTAB file.

ktpass -princ http/domaincontroller1.mydomain.local@MYDOMAIN.LOCAL mapuser MYDOMAIN\kerberosuser -pass myPassword -crypto aes256-sha1  -ptype KRB5_NT_PRINCIPAL -out keytabfile.keytab -mapop set

I found that the “SSO” bit didn't work as I still had to log in by the web browser. However, my authentication did survive a browser close/re-open.

When setting the kerberos realm in the Authentication Profile, use something like MYDOMAIN.LOCAL (not just MYDOMAIN).

It is important to remember to configure the browser to do SSO with the FQDN being used.

E.G. If you are redirecting on the firewall to

redirect.domain.local

then you need to open up Internet Explorer and go

Internet Options->Security->Local intranet->Sites->Advanced

Add

http://redirect.domain.local

(note that this is unencrypted) and click Close→OK→OK.

Do not forget that if you want to do admin SSO in addition to user-ID, you will need to set up a new Key Tab for it as it will use a differnet FQDN. Also, you will need to add the FQDN of the firewall interface to the Internet Options list as shown above.

You may need to run the following command if Admin SSO doesn't work.

klist purge