Re: [squid-users] Squid HTTP Keytab SPN question

Hi Khaled,

It would appear that this was a freak error caused by my particular test machine/account. Testing from other test machines and account proved that it was working.

A reboot resolved it..

Thanks,

Nick

On 15/04/2010 12:00, "Khaled Blah" <khaled.blah_at_googlemail.com> wrote:

Hi Nick,

I believe a decrypt integrity check implies that the wrong key is
being used to decrypt the user's Kerbereros ticket. The KVNO might be
correct but the key is not.

I am using "net" to create a keytab. It's rather easy, simply create a
smb.conf if you don't have one already for the "auth1" account
(Netbios name = AUTH1), then do "net ads join" and then "net ads
keytab add http". This will cause net to create a keytab with the
correct keys and the correct KVNO.

Regards,
Khaled

2010/4/15 Nick Cairncross <Nick.Cairncross_at_condenast.co.uk>:
> Hi Khaled,
>
> The reason is that I am also running Samba, which periodically and sometimes 'randomly' updates the machine account in AD (squid1) and throws out the KVNO, and thus the exported squid keytab HTTP.keytab becomes invalid. Using a different account (auth1) means I can run a cron job to run msktutil to update the keytab and keep the KVNO/keytab in sync, and not touching the actual host computer account.
>
> I have got the separate account working up to the point that the cache.log now just reports a Decrypt integrity check failed. I am prompted for my username and password. Entering this allows me to get on the internet and cache.log shows my username. I understand the error message to be an 'incorrect password' type of message but it doesn't quite make sense..
>
> Any pointers from the list?
>
> Nick
>
>
>
>
>
> On 15/04/2010 02:47, "Khaled Blah" <khaled.blah_at_googlemail.com> wrote:
>
> Hi Nick,
>
> what I don't get in your question is this: if squid is already joined
> to your domain as squid1, why create another machine account auth1?
> Maybe I missed out on something.
>
> Your msktutil parameters look fine though.
>
> Regards,
> Khaled
>
> 2010/4/14 Nick Cairncross <Nick.Cairncross_at_condenast.co.uk>:
>> Hi,
>>
>> I'd like confirmation of something is possible, but first best to detail what I want:
>>
>> I want to use a separate computer account to authenticate my users against. I know that this requires an HTTP.keytab and computer in AD with SPN. I would like to use MKTSUTIL for this.
>> If my proxy server is called SQUID1 and is already happily joined to the domain then I need to create a new machine account which I will call AUTH1.
>>
>> 1) Do I need to create a DNS entry for AUTH1 (with the same IP as SQUID1)?
>> 2) If so, do I need just an A record?
>> 3) I have evidently got confused over the msktutil switches and values and so I'm specifying something wrong. What have I done? See below...
>>
>> I used this command after a kinit myusername:
>> msktutil -c -b "CN=COMPUTERS" -s HTTP/squid1.[mydomain] iz -k /etc/squid/HTTP.keytab --computer-name auth1 --upn HTTP/squid1 --server dc1 -verbose
>>
>> This created the computer account auth1 in the computers ou, added HTTP/squid1.mydomain to SPN and HTTP/squid1.mydomain_at_mydomain to the UPN.
>> It also created the keytab HTTP.keytab. Klist reports:
>>
>> 2 HTTP/squid1.[mydomain]@[MYDOMAIN]
>> 2 HTTP/squid1.[mydomain]@[MYDOMAIN]
>> 2 HTTP/squid1.[mydomain]@[MYDOMAIN]
>>
>> However cache.log shows this when I then fire up me IE
>>
>> 2010/04/14 14:52:46| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information. No principal in keytab matches desired name'
>>
>> Thanks as always,
>> Nick
>>
>>
>>
>>
>> ** Please consider the environment before printing this e-mail **
>>
>> 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.
>>
>> Company Registration details:
>> The Conde Nast Publications Ltd
>> Vogue House
>> Hanover Square
>> London W1S 1JU
>>
>> Registered in London No. 226900
>>
>
>
> ** Please consider the environment before printing this e-mail **
>
> 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.
>
> Company Registration details:
> The Conde Nast Publications Ltd
> Vogue House
> Hanover Square
> London W1S 1JU
>
> Registered in London No. 226900
>

** Please consider the environment before printing this e-mail **

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.

Company Registration details:
The Conde Nast Publications Ltd
Vogue House
Hanover Square
London W1S 1JU

Registered in London No. 226900
Received on Fri Apr 16 2010 - 16:20:13 MDT