Hi Amos !
First thank you for your patience and your answers.
I agree on the Negotiate/Kerberos workflow, and its security implication. But I have some
last extra questioning about Kerberos.
It seems that we disagree on how Kerberos is supposed to work. See lower :
> > [Client sends a Kerberos Service Ticket to Squid]
> The client sends such ticket to the proxy, the proxy sends it to the DC.
What do you consider as a DC ?
For me and until now, DC meant "Domain Controller", or "Distribution Center"
(shorthand for KDC, Kerberos' Key Distribution Center): the trusted third party
process that can be either MIT/Heimdal Kerberos or MS Active Directory.
Am I right ?
> The DC tells the proxy ("OK allow" or "no deny").
I didn't observed any communication between the negotiate_kerberos_auth helper
and the DC. The only form of communication is reading requests on the standard input
(from squid), reading files like a keytab (the service key) and the krb5.cfg
Kerberos Realm configuration file, and writing responses on the standard output (to Squid).
No connect() system call, no socket, no IPC to some DC. (And users where correctly
authenticated, of course)
And it should be fine since the Kerberos protocol doesn't define any communication
between a service and a DC.
Yesterday I tried a Debian Firefox with a Heimdal Kerberos server. This morning,
I've tried to use a Firefox on Windows 10, with an account provided from a
MS Windows Terminal Server 2008 running an Active Directory.
In either case Firefox was configured to pass trough a Squid instance.
This Squid instance was configured like this in the two scenarii :
auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME
auth_param negotiate children 1
auth_param negotiate keep_alive on
acl foobar proxy_auth REQUIRED
http_access allow foobar
The keytab was configured via the KRB5_KTNAME environment variable like this :
(in the /etc/default/squid file)
export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
This keytab was generated using the Samba "net ads keytab" command for Active Directory,
and with "kadmin ext" for Heimdal.
> If that were the case there would be no need for auth_param helpers to be
> configured. Squid passes tokens to the helper which handles all contact and
> validation with the DC.
My point is that the Kerberos helper doesn't need any contact with the DC. All it
has to know is the service key stored in the keytab file. So each new TCP connection
does not create a contact to the DC. It is what I have observed, but perhaps I'm
missing something.
So I need to be sure of this detail because we need to reduce the authentication
load of some Active Directories (which previously used NTLM), and Kerberos seems
to be the solution. By telling me that the helper contacts the DC on each TCP
connection with Kerberos, you puzzles me...
--
Emmanuel Coirier
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
