Ticket History #2139: KfW-2.6 beta2 in a mixed realm environment, wrong client principal

There may be a bug/misunderstanding in W2K which is carried forward
into KfW. It looks like the MS code may be reporting the wrong realm
of the client when returning a ticket with KERB_RETRIEVE_TKT_RESPONSE maybe
returning the wrong realm.

The KERB_EXTERNAL_TICKET structure says:
ClientName
KERB_EXTERNAL_NAME structure containing the client name in the
ticket. This name is relative to the current domain.

The clue to the problem may be "relative to the current domain"
what ever that means.


We have two realms, ANL.GOV is a W2K domain, and KRB5.ANL.GOV
is using a MIT 1.2.8 KDC.

I logon using Windows login to the local workstation that is
listed as host/deet22.ctd.anl.gov@KRB5.ANL.GOV

This causes a TGT and cross realm TGT to be obtained.
But notice below that the principal listed for the cross realm
TGT and the host ticket is listed as b17783@KRB5.ANL.GOV, rather
then what is actually in the ticket of b17783@ANL.GOV



C:\Program Files\MIT\Kerberos\bin>klist -e
Ticket cache: API:krb5cc
Default principal: b17783@ANL.GOV

Valid starting Expires Service principal
01/20/04 16:11:50 01/21/04 02:11:50 krbtgt/KRB5.ANL.GOV@ANL.GOV
for client b17783@KRB5.ANL.GOV, renew until 01/27/04 16:11:50
Etype (skey, tkt): DES cbc mode with RSA-MD5, DES cbc mode with
RSA-MD5

01/20/04 16:11:50 01/21/04 02:11:50 krbtgt/ANL.GOV@ANL.GOV
renew until 01/27/04 16:11:50, Etype (skey, tkt): etype 0,
ArcFour with
HMAC/md5
01/20/04 16:11:57 01/21/04 02:11:50 host/deet22.ctd.anl.gov@KRB5.ANL.GOV
for client b17783@KRB5.ANL.GOV, renew until 01/27/04 16:11:50
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
RSA-MD5

The Windows kerbtray.exe lists the client name correctly in the
krbtgt/ANL.GOV@ANL.GOV
and the krbtgt/KRB5.ANL.GOV@ANL.GOV tickets but not in the
host/deet22.ctd.anl.gov@KRB5.ANL.GOV ticket.

The KRB5.ANL.GOV KDC logs show the client name correctly in the host
ticket as
b17783@ANL.GOV

This was not a problem with the older ms2mit, which only copied the
single TGT.
But KfW appears to copy both TGTs.

Some GSSAPI programs when trying to use these tickets fail. If I use
Leash and
give it the b17783@ANL.GOV and password, the gssapi applications work.

So the interpretation of "relative to the current domain" may need to be
looked at closely.


-- Douglas E. Engert <DEEngert@anl.gov> Argonne National Laboratory 9700
South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
_______________________________________________ krbdev mailing list
krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev

This is related to ticket 2139. Doug has described a problem in which
the MS Tickets made accessible to the MIT krb5 gssapi implementation
cannot access services via cross realm. apparently, the ms tickets do
not use the same convention for cross realm client identity mapping as
MIT krb5 does. The problem is most likely in the default implementation
of the retrieval function which is depended on by the mslsa ccache
implementation.

This needs to be fixed for 1.3.2.

Comment from Doug:

I have gotten further. I don't think the identity mapping or retrieval
method
is a problem. I think it is the fwd_tgt.c code.

By removing "default_tkt_enctypes" and "default_tgs_enctypes" in the
krb5.ini,
gssapi can get forwardable TGTs. I think the problem may be in the
fwd_tgt.c
where it is trying to guess what etype the host can handle.

In the following 2 examples the TGT to be forwarded is obtained from the
MS AD. The hosts are in the MIT realm.

This is strange because on one host the host principal in the MIT realm
has only a des-cbc-crc key, and this is what was in the "default_*_enctypes"
and that is is what is finally returned in the forwarded TGT. But it
only works if I remove the "default_*_enctypes"

In the other host the host principal has both a 3des and a des-cbc-crc key,
yet the forward TGT has RC4-HMAC. The system is running krb5-1.2.8 and
does not understand rc4-hmac! (This system needs to be updated to 1.3.x)

I believe that the fwd_tgt.c code is confused. But there is no
debugging output, and the gssapi silently continues if delegation
fails. It may have been confused, because the imported TGT had RC4-HMAC,
which was not in its list of "default_*_enctypes". If I let Leash
get the tickets, it ownered the "default_*_enctypes" and gets an initial
TGT with des-cbc-crc.

So I am running without the "default_*_enctypes" for now.

2004-01-30 Jeffrey Altman <jaltman@mit.edu>

* cc_mslsa.c: As per extensive conversations with Doug Engert we have
concluded that MS is not specifying a complete set of domain information
when it comes to service tickets other than the initial TGT. What happens
is the client principal domain cannot be derived from the fields they
export. Code has now been added to obtain the domain from the initial
TGT and use that when constructing the client principals for all tickets.

This behavior can be turned off by setting a registry either on a per-user
or a system-wide basis:

{HKCU,HKLM}\Software\MIT\Kerberos5
PreserveInitialTicketIdentity = 0x0 (DWORD)


To generate a diff of this commit:



cvs diff -r5.94 -r5.95 krb5/src/lib/krb5/ccache/ChangeLog
cvs diff -r5.7 -r5.8 krb5/src/lib/krb5/ccache/cc_mslsa.c

* Update README to describe the new PreserveInitialTicketIdentity
registry key.


To generate a diff of this commit:



cvs diff -r1.23 -r1.24 krb5/src/windows/ChangeLog
cvs diff -r1.10 -r1.11 krb5/src/windows/README

pullup from trunk


To generate a diff of this commit:



cvs diff -r5.82.2.5 -r5.82.2.6 krb5/src/lib/krb5/ccache/ChangeLog
cvs diff -r5.3.2.4 -r5.3.2.5 krb5/src/lib/krb5/ccache/cc_mslsa.c
cvs diff -r1.19.2.16 -r1.19.2.17 krb5/src/windows/ChangeLog
cvs diff -r1.6.2.4 -r1.6.2.5 krb5/src/windows/README