Hi,
So that the correct version numbers 2
root@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@xxxxxxxxxxxxxx (DES
cbc mode with CRC-32)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx (DES
cbc mode with RSA-MD5)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(ArcFour with HMAC/md5)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(AES-256 CTS mode with 96-bit SHA-1 HMAC)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(AES-128 CTS mode with 96-bit SHA-1 HMAC)
root@teste:~#
root@teste:~#
root@teste:~# kvno HTTP/proxy.vialactea.corp
HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx: kvno = 9
root@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?
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@xxxxxxxxxxxx> wrote in message
news:4DE5091F.4090109@xxxxxxxxxxxxxxx
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@teste:/etc/squid3#
root@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@xxxxxxxxxxxxxx (DES
cbc mode with CRC-32)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx (DES
cbc mode with RSA-MD5)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(ArcFour with HMAC/md5)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(AES-256 CTS mode with 96-bit SHA-1 HMAC)
9 12/31/69 20:00:00 HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
(AES-128 CTS mode with 96-bit SHA-1 HMAC)
root@teste:/etc/squid3#
root@teste:/etc/squid3#
root@teste:/etc/squid3# kvno HTTP/proxy.vialactea.corp
HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx: kvno = 9
root@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@teste:/etc/squid3# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: squid@xxxxxxxxxxxxxx
Valid starting Expires Service principal
05/30/11 23:22:23 05/31/11 09:25:30
krbtgt/VIALACTEA.CORP@xxxxxxxxxxxxxx
renew until 05/31/11 23:22:23
root@teste:/etc/squid3# kvno HTTP/proxy.vialactea.corp
HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx: 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@teste:/etc/squid3# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: squid@xxxxxxxxxxxxxx
Valid starting Expires Service principal
05/30/11 23:22:23 05/31/11 09:25:30
krbtgt/VIALACTEA.CORP@xxxxxxxxxxxxxx
renew until 05/31/11 23:22:23
05/30/11 23:25:38 05/31/11 09:25:30
HTTP/proxy.vialactea.corp@xxxxxxxxxxxxxx
renew until 05/31/11 23:22:23
root@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
