How to configure Kerberos SSO

Elaborated by:

Gerardo Lastra

PS engineer

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [1] Proprietary and Confidential
Contents
Overview ...........................................................................................................................................3
Nomenclature ....................................................................................................................................4
Kerberos overview..............................................................................................................................5
Kerberos/PAN-OS SSO flow .................................................................................................................6
Previous requirements........................................................................................................................8
Kerberos server ..............................................................................................................................8
Firewall/endpoint side ....................................................................................................................8
Configuration .....................................................................................................................................9
1. Keytab Generation -Kerberos server-............................................................................................9
2. Keytab Import -Firewall- ............................................................................................................ 12
3. PAN-OS Service configuration .................................................................................................... 13
3.1 Global Protect...................................................................................................................... 13
3.2 Captive Portal ...................................................................................................................... 15
3.3 PAN-OS webUI..................................................................................................................... 15
Troubleshooting ............................................................................................................................... 16
Firewall ........................................................................................................................................ 16
Endpoint ...................................................................................................................................... 17
Kerberos server ............................................................................................................................ 18
Validation ........................................................................................................................................ 19
FAQ ................................................................................................................................................. 19
Do I need to troubleshoot connectivity between the firewall and the KDC?...................................... 19
Can I use a single service account for all my SSO services?............................................................... 19
How do I know the realm name? ................................................................................................... 20
I’m getting a realm mismatch when I try to import the keytab, what can I do? ................................. 20
The keytab was imported successfully but I’m unable to see the 401 redirect or the WWW-
authenticate: Negotiate header in the packet captures. .................................................................. 20
I’m getting a generic error “_krb_accep_sec_context(pan_authd_kerberos_sso.c): This may be cause
by (1) time diff between KDC and this box; (2) Wrong encryption method is used to encrypt….......... 20
I’m getting a generic error "Your imported key tab file is not valid, please double check its source" .. 21
Resources ........................................................................................................................................ 21

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [2] Proprietary and Confidential
Overview
This document is intended to be a complete guide on how to deploy Kerberos SSO for the PAN-OS services
that support it. This guide covers Global Protect, Captive portal and Web UI administration.

The first section is dedicated to keytab file generation. The keytab file is generated on the Kerberos Key-
Distribution Center server and is necessary for all PAN-OS services reliant upon Kerberos authentication.
This file must be generated by the Kerberos server administrator.

The second section covers the process of importing the keytab file into the firewall. This must be done by
a firewall administrator.

The third section covers the specific PAN-OS service configurations. These changes require a firewall
administrator. They typically require and endpoint administrator to test the changes from the perspective
of the user-base, as firewall administrators and Net/Sec Ops team members typically have elevated
permissions in the production environment.

It is also important to understand that Kerberos SSO is tied to a Fully Qualified Domain Name (FQDN).
This FQDN is referenced in the generation of the keytab file and in the security certificate(s) associated
with the service(s). It is necessary to ensure there are DNS A or AAAA records for your services, and that
they resolve to the FQDN used in keytab file generation.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [3] Proprietary and Confidential
Nomenclature

TGT – Kerberos “Ticket Granting Ticket.” This is a user's initial ticket from the Authentication Service (AS)
and is typically generated when a user logs on to their workstation. The TGT is used to request service
tickets from the Ticket Granting Service (TGS) server. The AS and TGS are typically hosted on the same
server. This ticket is encrypted and can only be used by the TGS to grant new authentication tickets to the
end-user.

KDC - Key Distribution Center. This is the Kerberos server responsible for distributing tickets to
authenticated systems. The AS and TGS are typically both hosted on this server. The KDC is commonly a
Windows Active Directory server in most environments. It is possible that the KDC could be a Linux or
Unix based system. For these instances, you will need to refer to the documentation of the Kerberos
daemon running on these systems for keytab file generation instructions.

SSO – Single-Sign-On. Refers to the capability of signing onto a system or service with one set of
credentials, and having that initial login be applicable to other services that require authentication
through the use of cryptographic tokens derived from the initial set of credentials. Kerberos is a
commonly used SSO mechanism.

KVNO - Key Version Number. The KVNO is a field on the KRB_AP_REQ that indicates what version of the
key has been used to encrypt the service ticket. See Figure 1 in Kerberos Overview.

KRB_TGS_REQ - Kerberos ticket-granting service request. See Figure 1 in Kerberos Overview.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [4] Proprietary and Confidential
Kerberos overview
The Kerberos protocol—like Kerberos/Cerberus the guard in Greek Mythology—has three heads:

- A client: a user’s compute device

- A server: in the context of this document – PAN-OS Global protect, the admin Web UI, or captive
portal-based authentication
- A trusted third party to mediate between the other two. The trusted intermediary in the Kerberos
protocol is the KDC.

When a client wants to connect to a server, the client sends an authentication request to the AS server
(usually the KDC) in the form of a KRB_AS_REQ (Kerberos Authentication Service Request) packet. The AS
responds with a success or failure message in the KRB_AS_REP packet. If a success is returned, the client
sends a KRB_TGS_REQ (Kerberos Ticket Granting Service Request) packet to request a session ticket. The
KDC responds with a KRB_TGS_REP and distributes a unique, short-term session key for the two parties
to use when they authenticate each other. The server's copy of the session key is encrypted in the server's
long-term key. The client's copy of the session key is encrypted in the client's long-term key. Since both
keys were generated using symmetric encryption, the session ticket on the client can be verified by the
service when the KRB_AP_REQ (Kerberos Application Request) packet is sent to the server. The
KRB_AP_REP contains the authentication success / failure message.

Figure 1. Kerberos exchange and message summary

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [5] Proprietary and Confidential
Kerberos/PAN-OS SSO flow

Client - Firewall

1. The client will try to connect to a PAN-OS service – Globalprotect, Admin Web UI or Captive
Portal—sending an HTTP GET request. See Figure 2.
2. If SSO is enabled in the authentication profile used for the PAN-OS service and the keytab was
generated and imported correctly, the firewall will respond with an HTTP 401 code with a WWW-
authenticate: Negotiate header. This only occurs if the FQDN of the service and the FQDN used in
the keytab generation are an exact match.

Client - KDC

3. The client must have a TGT. These are typically requested and granted by the KDC when the user
logs on to the domain. The TGT is used to send a KRB_TGS_REQ. To get the ticket, the client
presents the TGT, an authenticator, and the name of the target server (the Server Principal Name
or SPN).
4. The Kerberos ticket-granting service response (KRB_TGS_REP). The TGS examines the TGT and the
authenticator. If these are acceptable, the TGS creates a service ticket. The client's identity is
taken from the TGT and copied to the service ticket. Then the ticket is sent to the client. See Figure
3.

Client – Firewall

5. Kerberos application server request (KRB_AP_REQ). After the client has the service ticket, the
client sends the ticket and a new authenticator to the target server, requesting access. The server
will decrypt the ticket, validate the authenticator, and for Windows services, create an access
token for the user based on the SIDs in the ticket. If the ticket can be validated through the
imported keytab in the firewall the user will be logged to the PAN-Os service -Figure 3-

Figure 2. Initial Flow: Endpoint - Firewall

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [6] Proprietary and Confidential
Figure 3. Kerberos Ticket Generation flow

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [7] Proprietary and Confidential
Prerequisites
Domain / Kerberos server
• Service Accounts – Keytab files are generated on a 1:1 basis for each FQDN requiring access. For
example, if there is a Global Protect configuration with 1 portal and 1 gateway and each has a
different FQDN (portal.example.com and gateway.example.com) — 2 service accounts are
needed.

Firewall/endpoint side
• Configure and verify that the services work correctly without Kerberos SSO. That means that
users can manually log in.

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Internal-GlobalProtect-
Only/ta-p/54099

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/user-id/map-ip-addresses-to-
users/map-ip-addresses-to-usernames-using-captive-portal/configure-captive-portal

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [8] Proprietary and Confidential
Configuration
Keytab Generation -Kerberos server-
1. The keytab is generated using a strong encryption method: AES-256, make sure that all service
accounts have ONLY AES-256 for Kerberos authentication checked. Active directory users and
computers -> locate account -> right click -> properties -> Account -> account options

Figure 4. Select "users and Computers"

Figure 5. Right click on service account and select "Properties"

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [9] Proprietary and Confidential
Figure 6. Account options for Kerberos encryption

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [10] Proprietary and Confidential
 2. Set the principal name as HTTP/<FQDN> for each service account, where <FQDN> is either a
PAN-OS service domain name. Use the following commands to set/check them
a. setspn -s HTTP/<FQDN> <accountname>
b. setspn -l <accountname>

Figure 7. Example setpsn -s command to set the principal name for a service account

Figure 8. Example setpsn -l command to review principal name for a service account

3. Generate keytab: 1 per service account. The majority of Kerberos issues are due to a incorrectly
generated keytab files, so make sure all the used data is correct.

Use the following command to generate the keytab on the KDC using the command prompt. It will
require principal name in the format <PAN-OS service FQDN>@<Kerberos REALM> and service
account. Command syntax is extremely important here. The Kerberos realm MUST be all capital
letters. The keytab will be generated on the working directory used in the windows Command prompt.

a. ktpass /out <filename.keytab> /princ HTTP/<FQDN>@<REALM> /mapuser

<domain>\<username> /pass <password> /crypto AES256-SHA1 /ptype
KRB5_NT_PRINCIPAL

Figure 9. Example ktpass command to generate kerberos Keytab

4. Export the generated keytabs from the server.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [11] Proprietary and Confidential
Keytab Import -Firewall-
1. Import the generated keytab on the respective authentication profile used in the PAN-OS service.
Keep in mind that you might have to create multiple profiles if more than 1 FQDN is in use.
a. Device -> Authentication profile -> click on name -> Single Sign on -> Import keytab

Figure 10. Import generated keytab on Firewall authentication profile

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [12] Proprietary and Confidential
PAN-OS Service configuration

Global Protect
For Global Protect no further firewall configuration is needed. Just make sure that an authentication
profile with a keytab is used in both portal and gateway. In addition, validate the following corner cases
are functioning with the implemented configuration.

Corner Case 1: Non-domain windows computers

By default, the global protect client won’t fall back to the authentication method defined in the profile.
Typically, this is LDAP username/password. Therefore, non-domain machines won’t be able to login into
the portal using Global Protect. A customer has asked to change this default behavior on case 00965718
but there hasn’t been an official response. To avoid this issue, you’ve 2 options:

1. Using msiexec to install Global Protect

msiexec.exe /i GlobalProtect.msi KRBAUTHFAILFALLBACK=”yes”

https://www.paloaltonetworks.com/documentation/80/globalprotect/globalprotect-admin-
guide/globalprotect-clients/deploy-agent-settings-transparently/deploy-agent-settings-to-windows-
clients/deploy-scripts-using-msiexec

2. Changing the registry key after installation

Location
HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings

Name
krb-auth-fail-fallback

Value
yes
https://www.paloaltonetworks.com/documentation/80/globalprotect/globalprotect-admin-
guide/globalprotect-clients/deploy-agent-settings-transparently/customizable-agent-settings/agent-
behavior-options#id51e0e000-9cce-425d-a4fd-e7fe51e1c8fb

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [13] Proprietary and Confidential
Corner Case 2: Kerberos SSO with third party credential providers

Usually Kerberos SSO is used when the Global Protect client cannot get username/password from the
windows login. This is usually caused by a third-party provider, such as Deepnet, not allowing them to
wrap the credentials as described in the link below. If this is the case change the setting “Use single Sign-
On (Windows only)” to “No.” Otherwise, upon Kerberos SSO failure the machine will try to submit the
saved credentials, which are empty, and authentication will fail with the following error on the Global
Protect client “Debug(2747): Auth failed empty password for gateway gateway.test.com”

https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Single-Sign-on-SSO-for-
GlobalProtect/ta-p/112186

Figure 11. Disable single sign on Portal configuration for required deployments

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [14] Proprietary and Confidential
Captive Portal
Since captive portal interacts with the endpoint web-browser make sure the following things are
covered:

1. Captive portal is configured in redirect mode.

2. Captive portal is redirecting to an FQDN and not to an IP address.
3. The web-browser is not presenting a certificate error when the is redirected to the captive
portal FQDN (https://FQDN:6082 )
4. Verify Kerberos SSO is being accepted in the web browser. If you’re configuring Trusted sites,
make sure that both http://FQDN and https://FQDN are added.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-
browsers-for-Kerberos-NTLM

PAN-OS Web UI
1. Since the Web UI interacts with a web-browser, verify Kerberos SSO is being accepted. If you’re
configuring Trusted sites, make sure that both https://<MGT-FW-IP> is added.
https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-
browsers-for-Kerberos-NTLM
2. Make sure that the authentication profile with the keytab is used as authentication method for
a locally created administrator.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [15] Proprietary and Confidential
Troubleshooting
Firewall
Place a packet capture between the interface and the GlobalProtect endpoint and check
if the firewall is returning an HTTP 401 code with a WWW-authenticate: Negotiate header.
This is the firewall presenting the browser challenge for Kerberos SSO.

Figure 12. Packet capture must display "WWW-authenticate: Negotiate header"

1. Check the authentication logs for errors

a. >tail follow yes mp-log authd.log

Figure 13. Error messages in authd.log

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [16] Proprietary and Confidential
Endpoint
1. Check if the Kerberos server is granting tickets for both portal and gateway and if they’re matching
the encryption type used for the keytab -AES-256- and the Kerberos realm. If they were granted
long time ago purge the tickets and login again. This should initiate a new browser challenge and
keytab file generation.
a. On the CMD use >klist
b. >Klist purge

Figure 14. klist command shows granted tickets

Figure 15. klist purge will purge all Kerberos tickets on the endpoint

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [17] Proprietary and Confidential
Kerberos server
1. Check that the KVNO for the service account and the one used in the keytab are the SAME. Since
the keytab will only try to decrypt tickets with the same version, every time that a new keytab is
generated the KVNO increases by 1 -since windows server 2008-.
a. Ktpass /in <filename.keytab>
b. dsquery * -filter sAMAccountName=<accountname> -attr msDS-KeyVersionNumber

Figure 16. ktpass command that shows the kvno for a generated keytab

Figure 17. dsquery commands that show the current kvno for a service account

2. The Kerberos version used to grant tickets can also being seen in a PCAP between the
GlobalProtect client and the Kerberos server. New tickets use the service account KVNO.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [18] Proprietary and Confidential
Validation
1. Check authentication in the firewall system logs, the description must include Kerberos SSO.

Figure 18. System logs showing kerberos authentications

FAQ
Do I need to troubleshoot connectivity between the firewall and the KDC?
No, the firewall and the KDC won’t ever talk for Kerberos SSO to work. The keytab is all the firewall
needs to validate the tickets received from the client, it will use it to decrypt.

The endpoint must have connectivity to both KDC and firewall dataplane interface where the
portal/gateways are configured.

Can I use a single service account for all my SSO services?

No. A service account per fqdn/service/SPN is required. The basis for that is every time that a keytab is
generated the KVNO increases by 1 -since windows 2008- and since you must generate a keytab per SPN
only the last one will be valid.

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [19] Proprietary and Confidential
How do I know the realm name?
Usually Kerberos admin knows this information otherwise try checking the cached Kerberos tickets on a
windows computer using the klist command

Figure 19. klist command showing REALM name

I’m getting a realm mismatch when I try to import the keytab, what can I do?
A sanity check is performed making sure the introduced realm and the realm used for the keytab
generation match. Verify that in both cases the realm is using uppercases.

The keytab was imported successfully but I’m unable to see the 401 redirect or the
WWW-authenticate: Negotiate header in the packet captures.
Make sure that the FQDN used for the keytab generation matches the FQDN used for the internal
gateway, if they don’t match the Kerberos redirect won’t happen.

I’m getting a generic error “_krb_accep_sec_context(pan_authd_kerberos_sso.c): This

may be cause by (1) time diff between KDC and this box; (2) Wrong encryption method is
used to encrypt…
The 4 options may be causing the error.

1. Check clocks between KDC and the firewall

2. Compare the encryption method used to generate the keytab with the encryption method used
to grant the ticket for the endpoint -klist command on windows-
3. KVnO mismatch. Follow Kerberos server troubleshooting section.

4.Requested ticket and principal don’t match. Verify the endpoint has an internal DNS server and
he’s able to list the Kerberos servers doing a nslookup on the CMD on windows “nslookup -type=any
_kerberos._tcp ”

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [20] Proprietary and Confidential
I’m getting a generic error "Your imported key tab file is not valid, please double check its
source"
This has been seen when a you’re trying to load the keytab file in a firewall from panorama -changing
context- so either load the keytab login directly to the firewall webUI or push the authentication
profile with the keytab using a panorama template. Since this has been unable to reproduce if possible
open a TAC case for debugging.

Resources
Detailed explanation of how Kerberos works

https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

Keytab generation

https://technet.microsoft.com/en-us/library/cc753771(v=ws.11).aspx

Set, delete and view principal names for service accounts,

https://technet.microsoft.com/en-us/library/cc731241(v=ws.11).aspx

Check granted Kerberos tickets

https://technet.microsoft.com/en-us/library/hh134826(v=ws.11).aspx

Configure GlobalProtect with Kerberos SSO in Palo Alto Networks firewalls

https://www.paloaltonetworks.com/documentation/71/pan-os/newfeaturesguide/globalprotect-
features/kerberos-for-internal-gateway-for-windows

© 2017 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
©2017, Palo Alto Networks, Inc. [21] Proprietary and Confidential