It seems like I spend an awful lot of my time doing development work, following guides to see what others have done and then end up banging my head against the wall due to the guides being either out of date or updated software that has a few extra intricacies.
Today’s fun one is Authenticated Squid 3.1 with Kerberos, Winbind and LDAP fall back. The big issue for me is following the guide on SQUID here.
It was all smooth sailing until I had created the kerberos Keytab file and then I went to use mkstutil to use auto update:
msktutil –auto-update –verbose
No go, I get:
Error: gethostbyaddr failed — get_dc_host: Found Domain Controller: nysrv04.example.local — get_default_keytab: Obtaining the default keytab name: /etc/squid3/PROXY.keytab — create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-plXCQn — reload: Reloading Kerberos Context — finalize_exec: SAM Account Name is: testproxy-k$ — try_machine_keytab_princ: Trying to authenticate for testproxy-k$ from local keytab… — try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Cannot contact any KDC for requested realm) — try_machine_keytab_princ: Authentication with keytab failed — try_machine_keytab_princ: Trying to authenticate for host/testproxy.example.local from local keytab… — try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Cannot contact any KDC for requested realm) — try_machine_keytab_princ: Authentication with keytab failed — try_machine_password: Trying to authenticate for testproxy-k$ with password. — try_machine_password: Error: krb5_get_init_creds_keytab failed (Cannot contact any KDC for requested realm) — try_machine_password: Authentication with password failed — try_user_creds: Checking if default ticket cache has tickets… — try_user_creds: Error: krb5_cc_get_principal failed (No credentials cache found) — try_user_creds: User ticket cache was not valid. Error: could not find any credentials to authenticate with. Neither keytab, default machine password, nor calling user’s tickets worked. Try “kinit”ing yourself some tickets with permission to create computer objects, or pre-creating the computer object in AD and selecting ‘reset account’. — ~KRB5Context: Destroying Kerberos Context
Trying again using -k /etc/squid3/PROXY.keytab and I get more of the same. After some serious digging around, I ended up having to use this:
msktutil –auto-update –verbose –computer-name testproxy-k –server ls01.example.local -s HTTP/testproxy.example.local -k /etc/squid3/PROXY.keytab
and voila!