RE: [squid-users] 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_at_condenast.co.uk]
> Sent: Tuesday, 26 October 2010 8:36 PM
> To: Paul Freeman; Squid Users
> Subject: Re: [squid-users] Authentication using squid_kerb_auth with
> Internet Explorer 8 on Windows Server 2008 R2
>
>
> On 26/10/2010 03:56, "Paul Freeman" <paul.freeman_at_eml.com.au> 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_at_MY.DOMAIN
        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_at_MY.DOMAIN
(ArcFour with HMAC/md5)
2 09/24/10 12:54:16 HTTP/my-proxy-server.my.domain_at_MY.DOMAIN
(AES-128 CTS mode with 96-bit SHA-1 HMAC)
2 09/24/10 12:54:16 HTTP/my-proxy-server.my.domain_at_MY.DOMAIN
(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
Received on Tue Oct 26 2010 - 21:12:51 MDT