Re: [squid-users] squid_kerb_auth for AD auth

Markus,

" If you see NTLM tokens in squid_kerb_auth then either you have not
created a keytab for squid--"

   Running on ubuntu I have the following into the upstart config file
/etc/init/squid.conf
   env KRB5_KTNAME=/etc/krb5.keytab
   And put it into /etc/environment so that the proxy user always has
this setting.
   And file permissions allow squid to read it:
   -rw-r----- 1 root proxy 545 Sep 6 10:15 /etc/krb5.keytab

  The keytab was generated as follows:
    net ads keytab CREATE -U myuser
    net ads keytab add -U myuser HTTP
    chgrp proxy /etc/krb5.keytab
    chmod 640 /etc/krb5.keytab

Running ktutil as the proxy user "rkt /etc/krb5.keytab" show a list of
9 entries with variations of the proxy hostname. So the proxy user can
read the keytab, and sees the same entries as root.

"... or the client can not get a HTTP/<squid> ticket from AD..."
How can I test that on the command line? Trying "kinit -V
HTTP/MYDOMAIN.NET" as the proxy user give the error "not found in
Kerberos database while getting initial credentials", but I dont
understand what I'm doing with than command :-)

There was no port 88 traffic on the client during a test right now,
may the kerberos part is cached,
Using the nice "follow tcp stream" in wireshark, the headers going
back and forward are as following, starting with the client:
GET http://mysite.ch/foo.html HTTP/1.1
> HTTP/1.1 407 Proxy Authentication Required
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: Negotiate
GET http://mysite.ch/foo.html HTTP/1.1
Proxy-Authorization: Negotiate
TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
> HTTP/1.1 407 Proxy Authentication Required
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: Negotiate

Wireshark is able to interpret that "Proxy-Authorization: Negotiate"
line as "NTLM Secure Service Provider", with a list of flag indicating
degrees of NTLM supported, and "Version 6.1 (Build 7601); NTLM Current
Revision 15".
IE and chrome sent exactly the same Proxy-Authorization reply.
The above negociate strict is also in the cache.log on the squid side:
 squid_kerb_auth: DEBUG: Got 'YR
TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' from squid
(length: 59).
WARNING: received type 1 NTLM token

How can I debug squid_kerb_auth to see what config it is reading, what
exactly it is trying to do, etc?
Hmm, looking at the source file
helpers/negotiate_auth/wrapper/negotiate_wrapper.cc and
helpers/negotiate_auth/kerberos/negotiate_kerberos_auth.cc, I realise
that I was calling squid_kerb_auth instead negotiate_kerberos_auth (a
squid_kerb_auth file was available, probably due to an older squid
compilation).
=> So, at least one error fixed:, the squid.conf line is now:
auth_param negotiate program
/usr/local/squid/libexec/negotiate_wrapper_auth -d --kerberos
/usr/local/squid/libexec/negotiate_kerberos_auth -d -i -s
GSS_C_NO_NAME --ntlm /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp --domain=MYDOMAIN

This gives a little bit more info in cache.log, although
authentications still does not work:
grep negotiate_kerberos_auth cache.log
     negotiate_wrapper: Kerberos command:
/usr/local/squid/libexec/negotiate_kerberos_auth -d -i -s
GSS_C_NO_NAME
grep negotiate_kerberos_auth cache.log
     negotiate_kerberos_auth.cc(271): pid=5725 :2012/09/10 11:04:51|
negotiate_kerberos_auth: INFO: Starting version 3.0.4sq

So at least the correct wrapper is being started now, and some debug
messages are arriving.

Aside: in negotiate_kerberos_auth.cc the string "squid_kerb_auth"
appears in the usage: minor doc bug?

Looking at negotiate_kerberos_auth.cc, the "INFO" message above is
printed out at:
    debug((char *) "%s| %s: INFO: Starting version %s\n", LogTime(),
PROGRAM, SQUID_KERB_AUTH_VERSION);
but no messages are logged from the child processes in the while(1) loop?

Thanks in advance,

Sean Boran

>>>>>>>>>>
Hi Sean,

   If you see NTLM tokens in squid_kerb_auth then either you have not
created a keytab for squid or the client can not get a HTTP/<squid> ticket
from AD. Please capture traffic on port 88 for kerberos traffic on the
client and 3128 for squid traffic.

Markus

> For windows system in a domain, what is the typicaly strategy, would
> one usually
> A. Authenticate via Kerberos (only IE browsers, or also chrome/FF?)
> B. else authenticate via ntlkm (IE only?)
> C. else use ldap (all other browsers and Linux, or Windows PCs not in
> the domain).
>
> It is right to say that if kerberos is enabled, but not basic/ldap,
> then non IE browsers cannot login?
> Or will kerberos work for all browsers in a Windows system in the domain?
>
> Or have I completely misunderstood? :-)
>
> Starting off with C) squid_ldap_auth, which works fine, the next step
> is kerberos.
>
> For kerberos, my main reading references are:
> http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
> http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/
> http://wiki.bitbinary.com/index.php/Active_Directory_Integrated_Squid_Proxy
>
> Runing squid/3.HEAD-20120814-r12282.
>
> On the linux level kerberos and samba are installed,/configured the
> system is in the domain (wbinfo -t) and "kinit -V username" works
> fine. Ntml auth on the command line looks ok too (/usr/bin/ntlm_auth
> --domain=MYDOMAIN --username=myuser)
>
> In squid , kerberos configured as follows:
> auth_param negotiate program /usr/local/squid/libexec/squid_kerb_auth
> -d -i -s GSS_C_NO_NAME
> auth_param negotiate children 10 startup=1 idle=5
> auth_param negotiate keep_alive on
> acl restricted proxy_auth REQUIRED
>
>
> After restart squid, log entries look good:
> Sep 7 09:10:31 proxy squid[26997]: helperOpenServers: Starting 1/10
> 'squid_kerb_auth' processes
>
> Trying to connect with IE causes a login box to popup on the bowser
> and squid to log:
> ERROR: Negotiate Authentication validating user. Error returned 'BH
> received type 1 NTLM token'
>
> in cache.log:
> 2012/09/07 09:22:53.421| ACL::checklistMatches: checking 'restricted'
> 2012/09/07 09:22:53.421| Acl.cc(65) AuthenticateAcl: returning 3
> sending authentication challenge.
>
> I can give in a valid or invalid username/password to the popup, box
> but no access is granted and I dont see any usernames or
> squid_kerb_auth lines in the cache.log.
>
> Question: how can one debug in detail what squid_kerb_auth is doing?
> The "-d" option does not seem to show much? (debug_options ALL,1 83,5
> 23,2 26,9 28,9 33,4 84,3: any better suggestions?)
>
> Doing some "tcpdumnp -A" tracing:
> - browser sends: GET http://google.com/ HTTP/1.1
> -proxy answers
> HTTP/1.1 407 Proxy Authentication Required
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: Negotiate
> - browser send back:
> Proxy-Authorization: Negotiate
> TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
> -proxy answers
> HTTP/1.1 407 Proxy Authentication Required
> X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> Proxy-Authenticate: Negotiate
>
> Also tried kerberos with NTLM, in this case access is always denied,
> no popup. Tcpdump show similar handshaking.
> auth_param negotiate program
> /usr/local/squid/libexec/negotiate_wrapper_auth -d --ntlm
> /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
> --domain=MYDOMAIN --kerberos /usr/local/squid/libexec/squid_kerb_auth
> -d -i -s GSS_C_NO_NAME
> -
>
> Thanks in advance for any tips :-)
>
Received on Mon Sep 10 2012 - 10:25:05 MDT