We are having issues using SPNEGO. Our problem seems to be the one
defined on:
http://www-01.ibm.com/support/docview.wss?rs=638&context=SSPREK&uid=swg21259123&loc=en_US&cs=UTF-8&lang=en
When we try to login, our browsers pass the following ticket
information:
Ticket
Tkt-vno: 5
Realm: DWPPTP.LONDONDC.COM
Server Name (Service and Instance):
HTTP/ettloadbalancer.dwpptp.londondc.com
Name-type: Service and Instance
(2)
Name: HTTP
Name:
ettloadbalancer.dwpptp.londondc.com
enc-part des-cbc-md5
Encryption type: des-cbc-md5 (3)
Kvno: 4
enc-part:
1857B643262FFCBFF4F54F7D2D7E41F7D67DC10257C15D28...
The Kvno is 4, yet when performing a klist on the keytab file:
ivmgr@dptettsw02:/var/pdweb/log$ klist -k /var/pdweb/keytab-dptettsw02/
ettloadbalancer_HTTP.keytab
Keytab name: FILE:/var/pdweb/keytab-dptettsw02/
ettloadbalancer_HTTP.keytab
KVNO Principal
----
--------------------------------------------------------------------------
3 HTTP/ettloadbalancer.d...@DWPPTP.LONDONDC.COM
We have followed the recommendation of recreating the keytab file and
this has change the KVNO number in the keytab file. However the KVNO
passed by the browser does not matched - how does this value get set?
Any help is appreciated
Regards
Kev
KD> Hi, I'm hoping someone can help. We are having issues using
KD> SPNEGO. Our problem seems to be the one defined on:
KD> http://www-01.ibm.com/support/docview.wss?rs=638&context=SSPREK&uid=swg21259123&loc=en_US&cs=UTF-8&lang=en
KD> When we try to login, our browsers pass the following ticket
KD> information:
KD> Ticket Tkt-vno: 5 Realm:
KD> DWPPTP.LONDONDC.COM Server Name (Service and Instance):
KD> HTTP/ettloadbalancer.dwpptp.londondc.com Name-type: Service and
KD> Instance (2) Name: HTTP Name: ettloadbalancer.dwpptp.londondc.com
KD> enc-part des-cbc-md5 Encryption type: des-cbc-md5 (3) Kvno: 4
KD> enc-part: 1857B643262FFCBFF4F54F7D2D7E41F7D67DC10257C15D28...
KD> The Kvno is 4, yet when performing a klist on the keytab file:
KD> ivmgr@dptettsw02:/var/pdweb/log$ klist -k
KD> /var/pdweb/keytab-dptettsw02/ ettloadbalancer_HTTP.keytab Keytab
KD> name: FILE:/var/pdweb/keytab-dptettsw02/
KD> ettloadbalancer_HTTP.keytab KVNO Principal ----
KD> --------------------------------------------------------------------------
KD> 3 HTTP/ettloadbalancer.d...@DWPPTP.LONDONDC.COM
KD> We have followed the recommendation of recreating the keytab file
KD> and this has change the KVNO number in the keytab file. However
KD> the KVNO passed by the browser does not matched - how does this
KD> value get set?
You need to purge the ccache on the client machine so that it obtains a
new, matching ticket from the KDC.
KD> Any help is appreciated
KD> Regards
KD> Kev
--
Richard Silverman
r...@qoxp.net
Thanks Richard, is that done using the "C:\Program Files\Resource Kit
\KLIST.EXE" purge" command? If so, I have tried this but it still
isn't working
KD> Thanks Richard, is that done using the "C:\Program Files\Resource
KD> Kit \KLIST.EXE" purge" command? If so, I have tried this but it
KD> still isn't working
Do all of the following match?
* kvno reported by "getprinc" in kadmin
* kvno in the keytab file
* kvno in the ticket supplied by the browser
What are you using on the server side, Apache + mod_auth_kerb? If so,
what are the log messages emitted by mod_auth_kerb?
--
Richard Silverman
r...@qoxp.net
(Richard Silverman suggested to clean out the client ticket cache,
but that may only be part of the problem.)
The knvo is usually increased by one each time you change the key in the KDC,
so it looks like you did not update the keytab the last time you changed
the key. The KDC and keytab need to stay in sync. The client got a ticket with
a kvno of 4, but the keytab has a kvno of 3. Do you have more then one copy
of the keytab file? I see the word load balancer in you note. Did you update both?
Whose KDC are you using, and what tool did you use to create or update the keytab?
(The reason for a kvno is that A keytab can have more then one key for a
service principal, each with a different kvno. This is done to allow tickets
issued with the older kvno to continue to work when a new key and kvno is
created in the KDC and keytab. At a later time the keytab can be cleaned up
removing the older entry.)
>
> Regards
>
> Kev
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Hi Douglas, thanks for you response.
ktpass was used to create the keytab. The KDC is maintained by our
local service unit.
We're really scratching our heads at the moment, it seems that each
time we create a new keytab file shortly afterwards the KVNO in the
client ticket changes. I've no idea why they are out of sync. What
changes etc could cause the KVNO to increment on the KDC?
Thanks
Kev
KD> Hi Douglas, thanks for you response.
KD> ktpass was used to create the keytab. The KDC is maintained by our
KD> local service unit.
KD> We're really scratching our heads at the moment, it seems that
KD> each time we create a new keytab file shortly afterwards the KVNO
KD> in the client ticket changes. I've no idea why they are out of
KD> sync. What changes etc could cause the KVNO to increment on the
KD> KDC?
Extracting the key (ktadd) does that, itself -- you get a *new* key when
you use ktadd. It's important to never do ktadd without also updating any
keytabs which contain the key. In particular, if there are multiple
keytabs, then you can't just use kadmin/ktadd to update them all; you have
to extract the key once and then insert it separately into the remaining
keytabs, e.g. with ktutil.
KD> Thanks