[1636] in Kerberos_V5_Development
Re: krb5 databases and kadmin
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Aug 26 11:25:20 1996
Date: Mon, 26 Aug 1996 11:25:16 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: hartmans@MIT.EDU
Cc: krbcore@MIT.EDU, jcb@cygnus.com
In-Reply-To: <199608251545.LAA13044@tertius.mit.edu> (message from Sam Hartman
on Sun, 25 Aug 1996 11:45:55 -0400)
* Most implementations of KRB4 code use 1/1/2000 or 12/31/1999 as the
expiration date for new principals.... I guess the
loadv4 code could covert that date to never, although I'm not sure
that it should do this.
I think loadv4 probably should make that conversion, perhaps printing
out a single warning when it first does so. The probability that
someone explicitly set an expiration date of the exact second used by
krb4's admin system is small enough that we shouldn't let it deter
from doing the right thing in the normal case.
* I had never used the Beta 6 kadmin on my database, and the Beta 6
version of kdb5_edit didn't update the password change date when the
cpw command was used. Thus, all the last-password-cahnged dates in
the database were never. I didn't notice this, and I created a policy
and added most of my users to the policy. I created a 2-year maximum
life for passwords. Unfortunately, never == 1970, so all my passwords
suddently expired.
Annoying, but like you said not really a bug. A site that doesn't
want to make everyone change their passwords can use a dump + awk +
load cycle to set the last_password_change time to now. Since this is
likely to be an issue with every sites that uses pw expiration, and
since the script is so trivial, perhaps we should just write it once
and distribute it.
* I tried to fix the problem by changing the maxlife on the policy.
However, this doesn't do anything for principals that already have the
policy; you need to re-modify these principals for it to take effect.
I had to think about this statement for a while before I understood
it, so yes, I definately think it needs clarification and
documentation. Here's the actual essence of the statement: When you
assign a policy to a principal, that principal's password expiration
in the KDC database is set right then to princ->last_pw_change +
policy->pw_maxlife (this is so that the KDC does not have to look up
the policy for every AS_REQ). However, modifying a policy DOES NOT
alter the principal records of a principal assigned to that policy
(doing so would risk the atomicity of the modify_policy operation).
As a result, new password expiration times are computed ONLY when a
principal's password is changing; alternatively, they can be assigned
with the -pwexpire option to modify_principal (but see below).
* If a principal has a policy, the -pwexpire flag doesn't do anything
useful.
If a principal has a policy, the -pwexpire flag allows an admin to set
a password expiration to any time BEFORE the policy would otherwise
require the password to expire. In other words, an admin can say "I
want to force this user to change his password within 3 days," but not
"I want to explicitly override the policy I assigned and let this
principal go an extra month without changing his password."
At OV we argued for a while about whether to allow -pwexpire to
override the policy and eventually decided the benefit did not justify
the risk. Besides, it is still pretty easy to accomplish: change
policy->pw_maxlife to something large (or never), change the princ's
password, and set policy->pw_maxlife back. This three-step process is
a pain, but it shouldn't have to used very often and we want to
discourage it anyway. If a site wants to override the pw expiration
of an entire database, then it can still do so with N
modify_principals and only 2 modify_policys.
Certainly, this should all be documented. Jeff, does this make sense
to you?
Barry
