How To Generate Kerberos Keytab for SSO
34858
Created On 02/25/19 23:18 PM - Last Modified 06/05/23 07:50 AM
Objective
The purpose of this article is to provide the steps required to generate a keytab for Kerberos SSO
Procedure
Generating Kerberos keytab on the Active Directory
Step 1: Create a new user under Managed Service Accounts or Users.
NOTE: The service account "User logon name" should use an actual domain and not an alternate UPN suffix.
Step 2: Select the "User cannot change password" and "Password never expires." By doing this, you avoid having to recreate the keytab file after the password has changed.
Step 3: Edit the Account Options and insure that the account has the following options selected:
1) Password never expires
2) User cannot change password
3) This account supports Kerberos AES 256-bit encryption
Step 4: Register an SPN for the HTTP service (GlobalProtect/Captive portal) using the below command on the AD server's command:
setspn -s HTTP/<FQDN for the portal> <Username for the service account>
setspn -s HTTP/portal.mylab.local pan-kerb
NOTE: The FQDN for the portal doesn't need to be a part of the domain, but it needs to have a DNS entry. Step 5: Generate the keytab file for portal authentication using the below command:
ktpass /princ HTTP/portal.mylab.local@AD6.OSALLAM.COM /mapuser AD6\pan-kerb /pass <password> /out portal.keytab /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1
ktpass /princ HTTP/<Portal FQDN>@<Kerberos Realm> /mapuser <NETBIOS name>\<Username> /pass <password> /out <Output File> /ptype KRB5_NT_PRINCIPAL /crypto <Encryption/hash Algorithm>
Portal FQDN = portal.mylab.local
Kerberos Realm = AD6.OSALLAM.COM (Must be all caps)
NETBIOS name = AD6
Service Account Username = pan-kerb
Encryption/Hash Algorithm = AES256-SHA1
Output file name can be anything
Step 6: Repeat the same steps for the gateway and if this is required for captive portal instead of GlobalProtect, then of course, you only need a single keytab. (If portal and gateway use the same DNS name, then you can use the same keytab file.)
Importing the keytab file to the firewall
Step 1: Once you have the keytab file generated, you can import it to the authentication profile used by GlobalProtect or Captive Portal.
Step 2: After completing the above steps, authentication with the firewall should happen without any user intervention, and you should see the service ticket using the klist command on the machine.
#1> Client: administrator @ AD6.OSALLAM.COM
Server: HTTP/portal.mylab.local @ AD6.OSALLAM.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 2/26/2019 9:01:05 (local)
End Time: 2/26/2019 18:56:45 (local)
Renew Time: 3/5/2019 8:56:45 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: WIN-B5K1S3H0N2R.ad6.osallam.com
#2> Client: administrator @ AD6.OSALLAM.COM
Server: HTTP/gateway.mylab.local @ AD6.OSALLAM.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 2/26/2019 8:57:16 (local)
End Time: 2/26/2019 18:56:45 (local)
Renew Time: 3/5/2019 8:56:45 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: WIN-B5K1S3H0N2R.ad6.osallam.comAdditional Information
A service account is required for each SPN, so if we have three gateways with three different FQDN names, then three service accounts are required. For more information about service principal names, see this article: https://docs.microsoft.com/en-us/windows/desktop/ad/service-principal-names
Make sure that there are no other service accounts that are using the same SPN, as it could cause issues with decrypting the Kerberos ticket on the firewall.
For information about the ktpass command, please reference this article: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass