"last log" and other information tracking

[Erich Weiler]

Hi Richard,

Yes, I just read somewhere that pre-auth was required...  But I tried 
adding a user as such:

kadmin: addprinc +require_preauth username

and then authenticated somewhere as the user and it didn't seem to make 
a difference...  Is my syntax wrong maybe?  Or am I maybe missing some 
steps?

Thanks for replying!

ciao, erich

Richard E. Silverman wrote:
>> Greetings all!
>> I'm having trouble finding the answer to a problem I'm having... 
>> Basically, when I do a "getprinc username" through kadmin, I get:
>>
>> kadmin:  getprinc user
>> Principal: user at DOMAIN.COM
>> Expiration date: [never]
>> Last password change: Fri Jul 21 16:26:28 PDT 2006
>> Password expiration date: [none]
>> Maximum ticket life: 1 day 00:00:00
>> Maximum renewable life: 0 days 00:00:00
>> Last modified: Fri Jul 21 16:26:28 PDT 2006 (admin/admin at DOMAIN.COM)
>> Last successful authentication: [never]
>> Last failed authentication: [never]
>> Failed password attempts: 0
>> Number of keys: 6
>> Key: vno 4, Triple DES cbc mode with HMAC/sha1, no salt
>> Key: vno 4, ArcFour with HMAC/md5, no salt
>> Key: vno 4, DES with HMAC/sha1, no salt
>> Key: vno 4, DES cbc mode with RSA-MD5, no salt
>> Key: vno 4, DES cbc mode with CRC-32, Version 4
>> Key: vno 4, DES cbc mode with CRC-32, AFS version 3
>> Attributes:
>> Policy: [none]
>> kadmin:
>>
>> Note that it says "Last successful authentication: [never]" and "Last 
>> failed authentication: [never]".  That user has in fact authenticated 
>> many times, and has failed a few too.  Is there a way I can get that 
>> information to be logged so it will show up with the above "getprinc 
>> user" command?  I've looked through the "logging" documentation but am 
>> stumped...  Thanks in advance for any advice!
> 
> I'm just guessing at this one, but I note that this principal does not
> require preauthentication.  In this, case the client does not actually
> authenticate itself to the KDC at all: the KDC simply sends out the
> encrypted TGT and relies on the fact that only the intended principal
> can decrypt it.  Hence, I would expect these counters to remain zero.
> 

-- 
===================================
Erich Weiler
UNIX Systems Administrator
School of Engineering
University of California Santa Cruz
weiler at soe.ucsc.edu
===================================