Sorry to reply to my own email but I realised I have not properly described the encryption type problem I had with https which may mean my theory about it being similar to the Kerberos problem is incorrect. The certificate encryption problem I had on Ubuntu 10.04 LTS was due to the Windows Root CA issuing the web server certificate with the sha256RSA signature algorithm. Apparently OpenSSL on ubuntu cannot manage this. Sorry for any confusion. Regards Paul > -----Original Message----- > From: Paul Freeman [mailto:paul.freeman@xxxxxxxxxx] > Sent: Wednesday, 27 October 2010 8:13 AM > To: Nick Cairncross; Squid Users > Subject: RE: Authentication using squid_kerb_auth with > Internet Explorer 8 on Windows Server 2008 R2 > > 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