Hi Nick Thanks for looking at this. I appreciate your help. My answers to your questions are in line below > -----Original Message----- > From: Nick Cairncross [mailto:Nick.Cairncross@xxxxxxxxxxxxxxx] > Sent: Tuesday, 26 October 2010 8:36 PM > To: Paul Freeman; Squid Users > Subject: Re: Authentication using squid_kerb_auth with > Internet Explorer 8 on Windows Server 2008 R2 > > > On 26/10/2010 03:56, "Paul Freeman" <paul.freeman@xxxxxxxxxx> wrote: > > > >Hi. > >I have successfully installed Squid 3.1.8 on Ubuntu 10.04LTS and have > >enabled > >Kerberos/NTLM authentication using the squid_kerb_auth helper. This > >setup is > >working well and successfully authenticates Windows domain users when > they > >are logged in using their domain credentials on Windows XP > workstations > >using > >Internet Explorer (v6,7 and 8) and Firefox. > > > >Squid is configured with two helpers, the first, squid_kerb_auth and > the > >second, the Samba ntlm helper. > > > >However, today I came across a problem when using Internet Explorer 8 > on a > >server running Windows Server 2008 R2. The IE8 enhanced security mode > is > >disabled and the logged in user is a standard domain user. The > Windows > >server is joined to the domain and is not a domain controller. The > >Windows > >server is up to date with Microsoft patches and updates. > > > >Authentication is failing for some reason. Instead of authenticating > >silently, the user is prompted for a username and password 6 times > before > >receiving the Cache Access Denied message. > > > >If I disable the squid_kerb_auth helper in squid.conf and restart > squid, > >leaving only the Samba NTLM helper, authentication works successfully. > > > >In cache.log I find: > >squid_kerb_auth: DEBUG: Got 'YR YII... > >squid_kerb_auth: DEBUG: Decode 'YII... > >squid_kerb_auth: ERROR: gss_accept_sec_context() failed: Unspecified > GSS > >failure. Minor code may provide more information. > >squid_kerb_auth: INFO: User not authenticated > >authenticateNegotiateHandleReply: Error validating user via Negotiate. > >Error > >returned 'BH gss_accept_sec_contect() failed: Unspecified GSS failure. > >Minor code may provide more information. ' > > > >Has anyone else found this with IE8 on Windows Server 2008 R2? Is it > due > >to > >the 64-bit version of IE8 or some unusual interaction between the IE8 > >version > >shipped with Windows Server 2008 R2 and the squid_kerb_auth module? > > > >I have a Wireshark capture of the traffic between the browser session > on > >Windows Server 2008 R2 and the proxy server during authentication and > >would > >like to assist with investigating the problem further if someone can > >provide > >some advice as to where to look. > > > >Regards > > > >Paul > > > Hi Paul, > Just my thoughts (which are minor in relation to the power of other > listers..!): Are you specifically running the 64-bit version of IE? How > does your DNS look? A/PTR records all in order? What does kerbtray show? > What encoding for kerberos are you using? What does klist -ekt <keytab> > show? Correct FQDN in your browser? > Cheers > Nick > I presumed IE8 was the 64-bit version but on further checking I have found it is the 32-bit version. The 64-bit version is also installed and I have tried that with the same result. As far as I know (I set DNS up :-) ), DNS is configured correctly with forward and reverse records. I checked the Kerberos tickets on a Windows XP workstation that authenticates correctly to squid using IE8 (32-bit) and the Windows 2008 R2 server using IE8 (32-bit and 64-bit) and found tickets for the proxy server as follows: Win XP Workstation: Server: HTTP/my-proxy-server.my.domain@xxxxxxxxx KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) End Time: 10/27/2010 17:37:35 Renew Time: 11/3/2010 7:37:35 Win 2008 R2 server: Client" my.login @ MY.DOMAIN Server: HTTP/my-proxy-server.my.domain @ MY.DOMAIN KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a00000 -> forwardable renewable pre_authent Start Time: 10/27/2010 7:30:13 (local) End Time: 10/27/2010 17:17:38 (local) Renew Time: 11/3/2010 7:17:38 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 The key difference is the ticket encryption type: RC4-HMAC for Win XP vs AES-256-HMAC-SHA1 for Win 2008 R2. On the proxy server, klist -ekt ticket_file shows: KVNO Timestamp Principal 2 09/24/10 12:54:16 HTTP/my-proxy-server.my.domain@xxxxxxxxx (ArcFour with HMAC/md5) 2 09/24/10 12:54:16 HTTP/my-proxy-server.my.domain@xxxxxxxxx (AES-128 CTS mode with 96-bit SHA-1 HMAC) 2 09/24/10 12:54:16 HTTP/my-proxy-server.my.domain@xxxxxxxxx (AES-256 CTS mode with 96-bit SHA-1 HMAC) I have just remembered that I recently came across a problem with AES-256 encryption on Ubuntu 10.04LTS. I discovered this when I found I could not establish a https session to a Linux web server which was using a certificate I had issued from the Windows Certificate Service on Windows 2008 R2. The problem turned out to be the certificate was signed by the Root CA using AES-256. After some "Googling" I found OpenSSL on Ubuntu could not manage this encryption type. I changed the Root CA encryption type to sha1 and re-issued the linux web server certificate and all was well I suspect the Kerberos problem I am seeing when authenticating to squid is similar. Windows 2008 R2 is encrypting using AES-256 but squid/kerberos cannot decrypt this successfully. Does this sound feasible? Can I force Windows 2008 R2 to use a different encryption type or can I get OpenSSL (which I presume is used for the encryption/decryption in Kerberos on Linux) to support AES-256? Can I debug this further to confirm this? Regards Paul > > > > The information contained in this e-mail is of a confidential nature > and is intended only for the addressee. If you are not the intended > addressee, any disclosure, copying or distribution by you is prohibited > and may be unlawful. Disclosure to any party other than the addressee, > whether inadvertent or otherwise, is not intended to waive privilege or > confidentiality. Internet communications are not secure and therefore > Conde Nast does not accept legal responsibility for the contents of > this message. Any views or opinions expressed are those of the author. > > The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover > Square, London W1S 1JU
