[squid-users] Re: Re: Re: problems squid_kerb_auth

> Hi,
>
> So that the correct version numbers 2
>

Sorry I do not understand what you want to indicate.

>
> root_at_teste:~# klist -ekt /etc/squid3/proxy.keytab
> Keytab name: WRFILE:/etc/squid3/proxy.keytab
> KVNO Timestamp Principal
> ---- -----------------
> --------------------------------------------------------
> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP (DES
> cbc mode with CRC-32)
> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP (DES
> cbc mode with RSA-MD5)
> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
> (ArcFour with HMAC/md5)
> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
> (AES-256 CTS mode with 96-bit SHA-1 HMAC)
> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
> (AES-128 CTS mode with 96-bit SHA-1 HMAC)
> root_at_teste:~#
> root_at_teste:~#
> root_at_teste:~# kvno HTTP/proxy.vialactea.corp
> HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP: kvno = 9
> root_at_teste:~#
>
> 9 in both
>
> But like so mean to each password change this kvno and amended, if I
> generate a keytab now that time and place the file in / etc/squid3 and
> go and change the password is invalid keytab?
>

Correct a password change on the AD account which is associated to the HTTP
service principal will make the keytab invalid. How did you create the
keytab ? I know that if you use samba and run the smaba daemons the daemons
will regularly change the AD password making the keytab invalid.

> Regards
>
> On 05/31/2011 03:57 PM, Markus Moeller wrote:
>>
>> Hi
>>
>> Firstly kvno means Kerberos key version number and marks each key so
>> that you can keep old and new keys. Each time you change the password
>> of the AD account associated to the HTTP service principal the version
>> number increases by 1.
>>
>>
>>
>> "spiderslack" <spiderslack_at_yahoo.com.br> wrote in message
>> news:4DE5091F.4090109_at_yahoo.com.br...
>>> On 05/31/2011 11:07 AM, spiderslack wrote:
>>>> On 05/30/2011 07:02 PM, Markus Moeller wrote:
>>>>> That looks better, but not quite right. What does klist -ekt
>>>>> <squid-keytab> (for MIT) or ktutil -k <squid-keytab> list (for
>>>>> Heimdal) give ?
>>>>> Also can you do a kinit <user> and then a kvno HTTP/<squid-fqdn> ( I
>>>>> assume MIT here) ?
>>> On 05/30/2011 07:02 PM, Markus Moeller wrote:
>>>> That looks better, but not quite right. What does klist -ekt
>>>> <squid-keytab> (for MIT) or ktutil -k <squid-keytab> list (for
>>>> Heimdal) give ?
>>>> Also can you do a kinit <user> and then a kvno HTTP/<squid-fqdn> ( I
>>>> assume MIT here) ?
>>> follows the output of the commands:
>>>
>>> root_at_teste:/etc/squid3#
>>> root_at_teste:/etc/squid3# klist -ekt /etc/squid3/proxy.keytab
>>> Keytab name: WRFILE:/etc/squid3/proxy.keytab
>>> KVNO Timestamp Principal
>>> ---- -----------------
>>> --------------------------------------------------------
>>> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP (DES
>>> cbc mode with CRC-32)
>>> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP (DES
>>> cbc mode with RSA-MD5)
>>> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
>>> (ArcFour with HMAC/md5)
>>> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
>>> (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>>> 9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
>>> (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>>> root_at_teste:/etc/squid3#
>>> root_at_teste:/etc/squid3#
>>> root_at_teste:/etc/squid3# kvno HTTP/proxy.vialactea.corp
>>> HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP: kvno = 9
>>> root_at_teste:/etc/squid3#
>>>
>>
>> This is what I see also in the pcap. kvno = 9 and RC4-hmac which is
>> the same as ArcFour with HMAC/md5
>>
>> [truncated] Proxy-Authorization: Negotiate
>> YIIGHwYGKwYBBQUCoIIGEzCCBg+gMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBdkEggXVYIIF0QYJKoZIhvcSAQICAQBuggXAMIIFvKADAgEFoQMCAQ6iBwMFACAAAACjggSlYYIEoTCCBJ2gAwIBBaEQGw5WSUFM
>> GSS-API Generic Security Service Application Program Interface
>> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
>> SPNEGO
>> negTokenInit
>> mechTypes: 4 items
>> mechToken:
>> 608205D106092A864886F71201020201006E8205C0308205...
>> krb5_blob:
>> 608205D106092A864886F71201020201006E8205C0308205...
>> KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
>> krb5_tok_id: KRB5_AP_REQ (0x0001)
>> Kerberos AP-REQ
>> Pvno: 5
>> MSG Type: AP-REQ (14)
>> Padding: 0
>> APOptions: 20000000 (Mutual required)
>> Ticket
>> Tkt-vno: 5
>> Realm: VIALACTEA.CORP
>> Server Name (Service and Instance):
>> HTTP/proxy.vialactea.corp
>> enc-part rc4-hmac
>> Encryption type: rc4-hmac (23)
>> Kvno: 9
>> enc-part:
>> 7080B29BE044CEFD9C56911F2F481F93E00D89E23963ED57...
>> Authenticator rc4-hmac
>>
>> This should have worked as it matches a key in the keytab.
>>
>>> root_at_teste:/etc/squid3# klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: squid_at_VIALACTEA.CORP
>>>
>>> Valid starting Expires Service principal
>>> 05/30/11 23:22:23 05/31/11 09:25:30
>>> krbtgt/VIALACTEA.CORP_at_VIALACTEA.CORP
>>> renew until 05/31/11 23:22:23
>>> root_at_teste:/etc/squid3# kvno HTTP/proxy.vialactea.corp
>>> HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP: kvno = 8
>>
>>
>> What is done differently here ? kvno is now 8 ? This can only happen
>> if you have more then one AD server (or kdc) and they have not
>> synchronised the keys. So one AD server has an old key which does not
>> match a key in the keytab.
>>
>>
>>> root_at_teste:/etc/squid3# klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: squid_at_VIALACTEA.CORP
>>>
>>> Valid starting Expires Service principal
>>> 05/30/11 23:22:23 05/31/11 09:25:30
>>> krbtgt/VIALACTEA.CORP_at_VIALACTEA.CORP
>>> renew until 05/31/11 23:22:23
>>> 05/30/11 23:25:38 05/31/11 09:25:30
>>> HTTP/proxy.vialactea.corp_at_VIALACTEA.CORP
>>> renew until 05/31/11 23:22:23
>>> root_at_teste:/etc/squid3#
>>>
>>>
>>> I did not understand what is KVNO, what would it be?
>>>
>>> also ran the command klist windows on the client which I am trying to
>>> connect via internet explorer see below
>>>
>>> C:\kerberos>klist
>>>
>>> Current LogonId is 0:0x2fe13
>>>
>>> Cached Tickets: (2)
>>>
>>> #0> Client: Administrator @ VIALACTEA.CORP
>>> Server: krbtgt/VIALACTEA.CORP @ VIALACTEA.CORP
>>> KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
>>> Ticket Flags 0x40e00000 -> forwardable renewable initial
>>> pre_authent
>>> Start Time: 5/31/2011 14:39:29 (local)
>>> End Time: 6/1/2011 0:39:29 (local)
>>> Renew Time: 6/7/2011 14:39:29 (local)
>>> Session Key Type: AES-256-CTS-HMAC-SHA1-96
>>>
>>>
>>> #1> Client: Administrator @ VIALACTEA.CORP
>>> Server: HTTP/proxy.vialactea.corp @ VIALACTEA.CORP
>>> KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
>>> Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
>>> Start Time: 5/31/2011 14:44:25 (local)
>>> End Time: 6/1/2011 0:39:29 (local)
>>> Renew Time: 6/7/2011 14:39:29 (local)
>>> Session Key Type: RSADSI RC4-HMAC(NT)
>>>
>>>
>>> C:\kerberos>
>>>
>>> is attached another. pcap what intrigued me was the following line of
>>> capture.
>>>
>>> APOptions: 20000000 (Mutual required)
>>> .0.. .... .... .... .... .... .... ....
>>> = Use Session Key: Do NOT use the session key to encrypt the ticket
>>> ..1. .... .... .... .... .... .... ....
>>> = Mutual required: MUTUAL authentication is REQUIRED
>>>
>>> Do not use the session key?
>>> Thanks for the help.
>>>
>>> Att.
>>>
>>>
>>
>> Can you check that you do an export
>> KRB5_KTNAME=/etc/squid3/proxy.keytab in the squid startup script.
>>
>>
>> Markus
>>
>
>
>
Received on Wed Jun 01 2011 - 19:24:47 MDT