====== Kerberos ======
===== Knowledgebase Articles =====
Two good articles on setting up Kerberos SSO for User ID / Access to the Internet are
* [[https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClUeCAK|here]].
* [[https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boBiCAI|here]].
===== KeyTab File =====
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
Windows 2022 keytab file generation
ktpass /princ DNS/ns1.example.com/@REALM /mapuser Infobloxsa /pass ######## /out b1ddi.keytab /ptype krb5_nt_principal /crypto ALL
older example
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).
===== Browser Settings =====
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.
===== Admin Access =====
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