">Nikolaos Milas" <nmilas@xxxxxx> wrote in message news:4E7AD311.1000702@xxxxxx...
On 22/9/2011 8:47 Ãμ, Nikolaos Milas wrote:Many thanks Markus, I also discovered, after each authentication attempt from the browser, in squid cache.log the following errors:A question that might shed some light: Do I have to create a kerberos host and service for every final client, and then transfer a keytab to the respective client?
No,you only need one keytab for the squid server.
Until now, I have the impression that this is not needed (and I have not done it). I believe that *the user* who is authenticating to squid (using a browser) must have a record in Kerberos server (and not his machine).
The user must exist as a user in a Kerberos server (e.g. Active Directory)
So, on the client side we (should) need nothing but a kerberos-capable browser. On the squid side we need a keytab for the squid service (HTTP/squid.example.com) which is defined/stored in kerberos server.
yes
So squid should be able to receive the request from a client (a user, through a browser) to authenticate (to squid) and then pass it to kerberos server?
Not exactly. The process is: 1) user logs in to a windows desktop or uses kinit on a Unix client which means an Authentication request (AS REQ) is send to the Kerberos server.2) user tries to access a website via squid 3) squid challanges the browser
4) the browser check the OS credential cache 5) if no HTTP/<squid> ticket exists in the cache a ticket granting service request (TGS REQ) is send to the Kerbeors server 6) The browser send the ticket which has encrypted details to squid 7) squid decrypts the ticket information with the key stored in the keytab (which is a shared key from ther Kerberos server extracted once with the mentioned tools) 8) if decryption is OK extract username from ticket 9) use username for authorisation on squid 10) reply to browser with OK or deny
How things work? (I haven't found details in the documentation.) Thanks, Nick
<<attachment: smime.p7s>>
