Wrong Password, Still Got Ticket
Jason C. Wells
jcw at highperformance.net
Wed Nov 17 00:06:51 EST 2004
The short story is that I was able get service tickets using the wrong
password. The long story, and subsequent question follows.
I recently change my password via kadmin cpw. When I propogated my
database, I foolishly propogated the database to the master and not to the
slave. My password was now different between master and slave. I spent
the next few minutes trying to figure out why Windows XP wasn't using the
new password. I managed that part easily enough.
This is the part I do not understand. I gave Windows XP login my old
password. XP got a ticket from the not yet updated KDC. (I pointed my
Windows box at the slave for the express purpose of reminding me to
propogate databases when my logins fail.) At this point, the XP
credentials cache has a valid ticket based on the old password from the
slave. I use MSLSA importation.
ksetup shows:
C:\Documents and Settings\jcw>ksetup
default realm = STRADAMOTORSPORTS.COM (external)
STRADAMOTORSPORTS.COM:
kdc = a2.stradamotorsports.com
kdc = a1.stradamotorsports.com
Realm Flags = 0x0 none
Mapping all users (*) to a local account by the same name (*).
krb5.ini shows:
[realms]
STRADAMOTORSPORTS.COM = {
kdc = a1.stradamotorsports.com
kdc = a2.stradamotorsports.com
admin_server = a1.stradamotorsports.com
default_domain = stradamotorsports.com
}
Note the order of the KDC listings.
I understand that I have valid TGT from the slave server. I understand
why I get a service ticket for the Windows host. Windows is interacting
with the slave that has the obsolete password.
How can leash be fetching proper service tickets for subsequent logins to
various services using a TGT that was gained with an obsolete password?
The TGS on the master KDC should be unable to decrypt the TGT that was
encrytped using a different (wrong) password.
Thanks,
Jason C. Wells
More information about the Kerberos
mailing list