Search squid archive

RE: Authentication using squid_kerb_auth with Internet Explorer 8 on Windows Server 2008 R2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux