Generate KeyTab file and enable Kerberos auth¶
In order to configure and enable Kerberos authenticator on Squid proxy navigate to Admin UI / Squid Proxy / Auth / Active Directory and click the Kerberos tab.
You will need to provide the following information.
This is usually the UPPERCASE letters of your Active Directory domain. For example.lan domain it will be EXAMPLE.LAN. Please note that Kerberos realm is always uppercase. Click the wizard button next to the field to try autodetection based on your DNS and DHCP settings.
Service Principal Name
The Service Principal Name (SPN) - is the Kerberos principal that will be used by the connecting browsers for authentication. It is usually constructed from the FQDN of the proxy and Kerberos realm automatically. For example, HTTP/proxy.example.lan@EXAMPLE.LAN. Click the wizard button next to the field to try autodetection based on your DNS and DHCP settings.
KeyTab for SPN
Here you must specify the keytab file that contains entries required to do the Kerberos authentication.
Please note, designated email@example.com user we created on the previous step, Service Principal Name and KeyTab file are three closely related entities. SPN is mapped to user firstname.lastname@example.org. Keytab is generated from both SPN and email@example.com user as follows.
Login as Administrator to your Domain Controller
Start the elevated Command Prompt
Change to disk C:
Run the following command (it must be on one line - here it is wrapped for better readability)
ktpass -princ HTTP/proxy.example.lan@EXAMPLE.LAN -mapuser squid@EXAMPLE.LAN -crypto AES256-SHA1 -pass Passw0rd -ptype KRB5_NT_PRINCIPAL -out krb5.keytab
The command will make
C:\krb5.keytab file and the output will look like the following. Note here the output is wrapped again for better readability. Also note the generated keytab has AES256-SHA1 encryption and vno is set to 3 (vno is version of the password so to say - it is incremented each time the password of the user is changed).
c:\>ktpass -princ HTTP/proxy.example.lan@EXAMPLE.LAN -mapuser squid@EXAMPLE.LAN -crypto AES256-SHA1 -pass Passw0rd -ptype KRB5_NT_PRINCIPAL -out krb5.keytab Targeting domain controller: dc1.diladele.lan Using legacy password setting method Successfully mapped HTTP/proxy.example.lan to squid. Key created. Output keytab to krb5.keytab: Keytab version: 0x502 keysize 87 HTTP/proxy.example.lan@EXAMPLE.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xa276729d03d19a94bd82ad7c37514436cdeddbe1be0d41d6d3e2780c69b8d5fc)
If you already have this SPN mapped to another user as indicated in the article Check the SPN is Mapped to One User Only key tab generation may fail with the following error.
Failed to set property 'servicePrincipalName' to 'HTTP/proxy.example.lan' on DN 'CN=squid,DC=example,DC=lan': 0x13. WARNING: Unable to set SPN mapping data.
Now set Enable Kerberos authenticator checkbox, specify
C:\krb5.keytab in the key tab browse button, set the SPN and click Save Changes.
After sucessful upload the application will perform various validation of the keytab, and will try to perform Kerberos authentication to the configured domain controller by running a series of Kerberos commands as indicated on Troubleshooting Squid Active Directory Integration. Output of these commands is shown on the Kerberos configuration page.
Technical information: Admin UI generates correct Kerberos conf file in
/opt/websafety/etc/krb5.conf based on the uploaded keytab, SPN and Kerberos realm. This configuration file is later used by the Kerberos authenticator to initialize Kerberos libraries. That is why it is possible to leave the default
The generated Kerberos configuration file will usually look like:
[libdefaults] default_realm = EXAMPLE.LAN default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
More technical information: excerpt from microsoft’s documentation for Active Directory … unlike Kerberos principal names, Windows account names are not multipart. Because of this, it is not possible to directly create an account of the name HTTP/proxy.example.lan in the Active Directory. Such a principal instance can be created through the service principal name mappings…
There should be ONLY one user mapped to a given SPN. If you have two or more different Active Directory users mapped to one SPN - Kerberos authentication will ALWAYS FAIL. For more information see blog entry at https://blogs.technet.microsoft.com/askds/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.