[squid-users] Re: squid_kerb_auth for AD auth

From: Markus Moeller <huaraz_at_moeller.plus.com>
Date: Mon, 10 Sep 2012 23:14:21 +0100

Hi Sean,

  When I said client I meant the Windows client ( or do you have also Unix
clients ?) On Windows you can install a tool called kerbtay which shows you
the ticket you have. If you dont' see any ticket for HTTP/<squid-fqdn> you
need to use a capture tool like wireshark and loot at the traffic on port 88
( the kerberos authentictaion port). You should see TGS request from the
client to AD and a TGS reply from AD with either the ticket or an error
message. Let me know what error message you get as I assume you will have
one.

Markus

"Sean Boran" <sean_at_boran.com> wrote in message
news:CAOnghjtX7TQd_XwM81=4sSebknVbnx=w2uDiP_WSb=1Q5rnwvQ_at_mail.gmail.com...
> 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 - 22:19:34 MDT

This archive was generated by hypermail 2.2.0 : Tue Sep 11 2012 - 12:00:03 MDT