> > If you know that at a certain time, the individual with that principal > > is going to be leaving your company/school/whatever, this is a good way > > to ensure that they can no longer authenticate to your KDC after that > > time. ... > Why would I expire the PRINCIPAL, when I solve the above issue by expiring the > password? If the password is expired, the account can't be used... I'm not > getting it...
This isn't actually the case; an expired password can be reset by the user, while the user can't do anything about an expired principal. You can convince yourself with an experiment along these lines: (On a ZONE.MIT.EDU KDC) kadmin.local: ank mitchb/[EMAIL PROTECTED] WARNING: no policy specified for mitchb/[EMAIL PROTECTED]; defaulting to no policy Enter password for principal "mitchb/[EMAIL PROTECTED]": Re-enter password for principal "mitchb/[EMAIL PROTECTED]": Principal "mitchb/[EMAIL PROTECTED]" created. kadmin.local: modprinc -pwexpire yesterday mitchb/[EMAIL PROTECTED] Principal "mitchb/[EMAIL PROTECTED]" modified. (Now on a client machine) $ kinit mitchb/[EMAIL PROTECTED] Password for mitchb/[EMAIL PROTECTED]: Password expired. You must change it now. Enter new password: Enter it again: $ klist Ticket cache: FILE:/tmp/krb5cc_4347 Default principal: mitchb/[EMAIL PROTECTED] Valid starting Expires Service principal 03/19/03 04:10:19 03/19/03 14:10:19 krbtgt/[EMAIL PROTECTED] However... (back on the kdc) kadmin.local: modprinc -expire yesterday mitchb/[EMAIL PROTECTED] Principal "mitchb/[EMAIL PROTECTED]" modified. (and back on the client machine) $ kinit mitchb/[EMAIL PROTECTED] kinit(v5): Client's entry in database has expired while getting initial credentials Mitch ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
