Skip to main content
Skyhigh Security

Configure Kerberos - Simplified Guide

Introduction

This guide includes only the basics for setting up Kerberos. No background or historical information will be found here. 

IMPORTANT: By the end of this guide, you should only have one user and keytab per domain for all of your Secure Web Gateways.

Use the Three-Headed Dog

A Kerberos setup tool has been created to make the setup process much easier. It will provide you with the commands to give to your Active Directory team. You can find the tool here: Secure Web Gateway: Three Headed Dog v1.0.3 (A Kerberos Setup Tool).

dog1.png

dog2.png

dog3.png

clipboard_eff9c5df040bf637cf052b7c7f4200e9e.png

Create User in Active Directory

This account will be treated as a service account so adjust accordingly.

create_user.JPG

password.JPG

Generate Keytab in Active Directory

When generating the keytab, the syntax is essential. The commands are case-sensitive. The syntax below is for Windows Server 2022, start a command prompt as administrator.

ktpass -princ HTTP/[fqdn-of-appliance_lowercase]@[DOMAIN_UPPERCASE] -mapuser[DOMAIN]\[USERNAME] -pass [PASSWORD] -ptype KRB5_NT_PRINCIPAL -crypto All -out[OUTPUT-FILENAME].keytab

Example:

ktpass -princ HTTP/proxy.domain.local@DOMAIN.LOCAL -mapuser domain\\swg-kerb-user -pass password -ptype KRB5_NT_PRINCIPAL -crypto all -out proxy.domain.local.keytab

 

Enable AES support in Active Directory (optional)

If you wish to enable AES support, do it after generating a keytab. If you adjust the AES support generate the keytab again. In my testing, if I enable AES support before generating a keytab, authentication will fail. Works fine by deleting the account and starting again.

properties.JPG

Set additional SPNs in Active Directory

Additional SPNs are necessary if you have multiple Secure Web Gateways, they are behind a load balancer, or there are multiple DNS names.

setspn -a HTTP/[fqdn-of-appliance] mwg-kerb-user

# Example:

setspn -a HTTP/load-balancer.domain.local swg-kerb-user

setspn -a HTTP/swg-alias.domain.local swg-kerb-user

# SOCKS Example:

setspn -a RCMD/proxy.domain.local swg-kerb-user

setspn -a RCMD/load-balancer.domain.local swg-kerb-user

setspn -a RCMD/swg-alias.domain.local swg-kerb-user

Upload keytab into the Web Gateway

Configuration > [Select your appliance] > Kerberos Administration. Upload the single keytab to each appliance.

keytab_import.JPG

Import Authentication Rules into Web Gateway

Use the ruleset from the Ultimate Kerberos Guide. Download ruleset here. The screenshot below shows Direct Proxy Authentication rules with NTLM Fallback, rules would be different for Authentication Server. We also assume you have already joined the Secure Web Gateway to the domain.

NTLM_fallback.JPG

Authentication with Kerberos and NTLM Fallback.xml

Common Issues

Proxy Settings

You must have the proxy settings set to use the FQDN (used in the keytab creation process). Do not use the IP.

clipboard_e56835465977028e22d3694c63dab2a6f.png

clipboard_e0f15ba78aaf5435401e59739d40edb17.png

Duplicate SPN

You probably created multiple user accounts after generating keytabs and forgot to delete them. To check the duplicate keytbs, run the command below on the Active Directory server. Replace SPN-SEARCH-STRING with the actual search string (e.g. proxy.domain.local).

ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"

User account / keytab version mismatch

You probably re-created the keytab or updated the account password, and now theversions are off.

Run the ldifde command again:

ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*SPN-SEARCH-STRING*)"

Example output (showing version 6):

> ldifde -f c:\dump.txt -l dn,sAMAccountName,msds-keyversionnumber,serviceprincipalname,userprincipalname -p subtree -r "(serviceprincipalname=*proxy.domain.local*)"

c:\dump.txt:

dn: CN=mwg-kerb-user,CN=Users,DC=domain,DC=local

changetype: add

sAMAccountName: mwg-kerb-user

userPrincipalName: HTTP/proxy.domain.local@domain.local

servicePrincipalName: HTTP/proxy.domain.local

servicePrincipalName: HTTP/mwg-alias.domain.local

msDS-KeyVersionNumber: 6

 

Compare the version listed in the ldifde output with the version in the keytab:

yum install krb5-workstation

klist -tek /etc/krb5.mwg.keytab

 

Example output (showing version 5):

[root@proxy ~]# klist -tek /etc/krb5.mwg.keytab

Keytab name: FILE:/etc/krb5.mwg.keytab

KVNO Timestamp Principal

---- ----------------- --------------------------------------------------------

5 12/31/69 18:00:00 HTTP/proxy.domain.local@DOMAIN.LOCAL (des-cbc-crc)

5 12/31/69 18:00:00 HTTP/proxy.domain.local@DOMAIN.LOCAL (des-cbc-md5)

5 12/31/69 18:00:00 HTTP/proxy.domain.local@DOMAIN.LOCAL (arcfour-hmac)

5 12/31/69 18:00:00 HTTP/proxy.domain.local@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)

5 12/31/69 18:00:00 HTTP/proxy.domain.local@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)

[root@proxy ~]#

Troubleshooting

If you have problems gather the following... (if you don't then we can't pinpoint your issue)

  • Flush DNS and purge Kerberos tickets:

ipconfig /flushdns

klist purge

  • Screenshot of proxy settings (if applicable)
  • ldifde output from Active directory server
  • klist output from Secure Web Gateway
  • Client-side Wireshark capture while reproducing whatever problem you are having.

Conclusion

By the end of all of this you should have one user and one keytab created (per domain) for all of your Secure Web Gateways. Authentication rules should be imported into Secure Web Gateway with NTLM Fallback in place.

  • Was this article helpful?