Hi Paul,
As far as I know the Kerberos libraries do not use openssl code. Can you
capture the traffic between your 2008 server and AD on port 88 and between
the 2008 server and squid on 3128 (the squid port). Can you also capture the
traffic between squid and AD when you try a kinit -kt squid.keytab
HTTP/my-proxy-server.my.domain_at_MY.DOMAIN
Regards
Markus
"Paul Freeman" <paul.freeman_at_eml.com.au> wrote in message
news:19672EECFB9AE340833C84F3E90B5956043780EF_at_mel-ex-01.eml.local...
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 - 22:15:04 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 27 2010 - 12:00:05 MDT