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@xxxxxxxxx
Regards
Markus
"Paul Freeman" <paul.freeman@xxxxxxxxxx> wrote in message
news:19672EECFB9AE340833C84F3E90B5956043780EF@xxxxxxxxxxxxxxxxxxxxxx
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
