Password Expiration
We're about to start expiring passwords again.
We don't want to do normal Kerberos password expiration because normal
Kerberos password expiration is very unfriendly. When your password
expires you simply cannot use your account. You get very little clue
as to why. In most cases, you can't tell the difference between trying
to use an expired password and simplying typing the wrong password.
For dial-up access, you simply don't get connected. "But it worked
yesterday."
Instead of putting password expiration into the realm of
Authentication which is Kerberos's job, we have redefined the
problem as one of Authorization. You are simply unauthorized to
use your Uniform Access accounts unless you change your password every
120 days or so. This limitation is implemented by setting the
shell in the unix passwd file to /usr/local/etc/pwchange which
is a utility that forces you to change your password before letting
you onto the system.
The Schedule
The current schedule is that the first passwords will start expiring on
October 26, 1999. The timeline is:
| Oct | 11: |
First warning is sent out. |
| Oct | 26: |
First password expires |
| Nov | 24: |
Last of the passwords unchanged since July 27 expires. |
At last count there were 74,000, plus or minus a couple hundred,
accounts that had not changed their passwords since June 28th. Those
accounts were assigned an arbitrary password expiration time between
October 26th and November 24th. Anyone who has changed or changes
their password after June 28th has a password expiration of at least
120 days after their actual password change time.
How passwords are "expired"
With Kerberos in the picture, I've had to revamp the entire password
expiration scheme. There are several players that get involved in
password expiration. They come into play in the following order:
-
Some application connects to one of the KDCs' kadmind process to
change a password. This could be the kpasswd utility running on
a desktop somewhere or the passwd utility running on a Uniform
Access unix computer. The UA passwd utility will also tell pwsync
to clear the "you must change your password" flag in the pwsync
database.
-
The kadmind process writes the password to a local log file on the
KDC's host.
-
Within the next 15 seconds or so, sqlogd will read the end of that
log file and send the password to the master Kiwi
server.
-
The master Kiwi server will update its own KDC and send the new password
to all the chief Kiwi servers. The chief Kiwi servers will update their
own KDCs and pass the password to all the slave Kiwi servers. New principal
creation also gets into the picture at this point as that's done through
Kiwi.
-
The slave Kiwi server running on carver that updates the Uniform Access
pwsync database will clear the "you must change your password" flag (in
case it wasn't the UA passwd utility that changed the password) and it
will send an update message to the pwx server.
-
The pwx server will add the delay (default 120 days) to the timestamp
it got from the slave Kiwi server and set that as the new expiration
time for this user's password. This expiration time gets stored in the
pwx database which is maintained with the same replicated transaction engine as the pwsync and
Kiwi databases.
-
The pwxpire utility runs on carver each night looking for
passwords to expire. After 105 days, it will detect that this user
needs to be warned that there are only 15 days left before the password
will expire. It sends an email message to the user built from the
template that can be found in /usr/local/lib/pwx/msgs and also
sets a flag in the pwx database indicating that the warning has been
sent so the user does not get more than one 15 day warning.
-
After 15 more days, pwxpire will set the "you must change your password"
flag in the UA pwsync database. This will change the user's shell to
/usr/local/etc/pwchange#. The user will then be put into the
passwd utility on next login, forced to change the password.
What can go wrong?
Besides the normal everyday type things, the following could go wrong
and mess up this process:
-
If carver's Kiwid dæmon stops running and doesn't get started
back up in a timely manner, it won't notice new password changes and
won't update the expiration dates in the pwx database. Operations
watches the Kiwi daemon on carver via Argus so someone will
[hopefully] be notified before this escalates into a problem that
affects users. As soon as Kiwid comes back up on carver it will get
all the intervening password change events from a chief Kiwi server and
update the pwx database appropriately. If carver is down for an
extended period, it shouldn't be a problem, because it's carver who
will be doing the expiration as well.
-
If the pwxpire utility is able to send out the warning email but fails
to update the pwx database indicating that the user has been warned, it
will attempt to warn that user again the next day. The pwxpire utility
should bail out if it fails on that update, so there should only be
one user who gets warned each night until the problem is fixed. The
user who gets warned may change if 15 days elapse or an earlier
user enters into the needs warning state. In this context,
earlier refers to the randomish order that the pwx database
returns its entries based on an internal hash key sorting.
-
If carver's cron doesn't submit the pwxpire command for an extended
period people's passwords won't get expired. You won't hear any
complaints from people that their passwords aren't getting expired
so this is not a biggie. When it eventually starts up again, though,
people will get a warning less than 15 days in advance or they'll
get no warning at all if it has been more than 15 days. The daily
end of day stats that get sent to the unix guru includes a blurb if
the normally scheduled 8am accounting process hasn't run so a dead cron
shouldn't be a problem. A problem with the script that runs
pwxpire could be a reality, though. Nawwww.
How passwords are kept from expiring
What, you don't want your own password to expire? What's good for the
goose is not good for the gander? Okay, you can use the pwx utility to
give a UW NetID a long delay before its password expires or simply set
its expiration date to some time in the far off future. The easiest
way to do this is with:
pwx -c "setpw user 2137115647 0"
This will set the next password expiration to January 18, 2038
(September 20, 2037 plus the standard delay of 120 days). As all
farsighted programmers know, that's so far in the future as will never
come up (don't try to go beyond this as this is the "end of time" as
far as unix with its 32 bit signed time field is concerned). The
normal password change process described above never sets the password
expiration date backwards if it's already to a later time so the
password for the above user will never expire. To set it
back to a standard account use:
pwx -c "delete user"
pwx -c "setpw user"
To set a user's password to expire every 200 days instead of every 120
days use the command:
pwx -c "setpw user 0 17280000"
This will set the delay for the account to 200 days (17,280,000
seconds) and use now as the last password change time.
To list out the status of a particular user, use the command:
pwx -u user
This command should go onto the accman web page somewhere. The pwx
command can be found in melville or carver's /usr/local/etc
directory. I'm considering putting it on daffy as well.
Ken Lowe
Email --
ken@u.washington.edu
Web --
http://staff.washington.edu/krl/