Ticket History #440: You can't change the last pwd change date

From kenh@cmf.nrl.navy.mil Thu Jun 26 19:41:07 1997
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id TAA19019 for <bugs@RT-11.MIT.EDU>; Thu, 26 Jun 1997 19:37:06 -0400
Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP
id AA17444; Thu, 26 Jun 97 19:29:49 EDT
Received: from nexus.cmf.nrl.navy.mil (kenh@nexus.cmf.nrl.navy.mil [134.207.10.9])
by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id TAA28119
for <krb5-bugs@mit.edu>; Thu, 26 Jun 1997 19:30:31 -0400 (EDT)
Received: (from kenh@localhost)
by nexus.cmf.nrl.navy.mil (8.8.5/8.8.5) id TAA19128;
Thu, 26 Jun 1997 19:30:52 -0400 (EDT)
Message-Id: <199706262330.TAA19128@nexus.cmf.nrl.navy.mil>
Date: Thu, 26 Jun 1997 19:30:52 -0400 (EDT)
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Reply-To: kenh@cmf.nrl.navy.mil
To: krb5-bugs@MIT.EDU
Subject: It is impossible to change the last pwd change date
X-Send-Pr-Version: 3.99

Navel Lint Research Laboratory


System: SunOS nexus 4.1.4 3 sun4m
Architecture: sun4


After having used minimum password lifetimes, one quickly discovers that
there needs to be a way to override them occasionally.

One common thing that happens is that an admin will reset a user's password,
but the user won't be able to change their password until the minimum
password lifetime has elapsed. This makes them cumbersome to use, and
encourages sites not to use this feature.

Enable minumum password lifetimes for a while with a large user population.

These patches provide the ability to change the "last password change"
time from the admin front-end. This allows an administrator to override
the minimum password lifetime if necessary.

Index: krb5/kadmin/cli/kadmin.c
diff -c krb5/kadmin/cli/kadmin.c:1.1.1.1 krb5/kadmin/cli/kadmin.c:1.2
*** krb5/kadmin/cli/kadmin.c:1.1.1.1 Mon Jun 2 17:55:06 1997
--- krb5/kadmin/cli/kadmin.c Thu Jun 26 19:19:11 1997
***************
*** 709,714 ****
--- 709,730 ----
++*randkey;
continue;
}
+ if (strlen(argv[i]) == 13 &&
+ !strcmp("-lastpwchange", argv[i])) {
+ if (++i > argc - 2)
+ return -1;
+ else {
+ date = get_date(argv[i], NULL);
+ if (date == (time_t)-1) {
+ fprintf(stderr, "Invalid date specification \"%s\".\n",
+ argv[i]);
+ return -1;
+ }
+ oprinc->last_pwd_change = date;
+ *mask |= KADM5_LAST_PWD_CHANGE;
+ continue;
+ }
+ }
for (j = 0; j < sizeof (flags) / sizeof (struct pflag); j++) {
if (strlen(argv[i]) == flags[j].flaglen + 1 &&
!strcmp(flags[j].flagname,
***************
*** 762,768 ****
{
fprintf(stderr, "usage: %s [options] principal\n", func);
fprintf(stderr, "\toptions are:\n");
! fprintf(stderr, "\t\t[-expire expdate] [-pwexpire pwexpdate] [-maxlife maxtixlife]\n\t\t[-kvno kvno] [-policy policy] [-clearpolicy]\n\t\t[-maxrenewlife maxrenewlife] [{+|-}attribute]\n");
fprintf(stderr, "\tattributes are:\n");
fprintf(stderr, "%s%s%s",
"\t\tallow_postdated allow_forwardable allow_tgs_req allow_renewable\n",
--- 778,784 ----
{
fprintf(stderr, "usage: %s [options] principal\n", func);
fprintf(stderr, "\toptions are:\n");
! fprintf(stderr, "\t\t[-expire expdate] [-pwexpire pwexpdate] [-maxlife maxtixlife]\n\t\t[-kvno kvno] [-policy policy] [-clearpolicy]\n\t\t[-maxrenewlife maxrenewlife] [-lastpwchange pwchangedate]\n\t\t[{+|-}attribute]\n");
fprintf(stderr, "\tattributes are:\n");
fprintf(stderr, "%s%s%s",
"\t\tallow_postdated allow_forwardable allow_tgs_req allow_renewable\n",
Index: krb5/lib/kadm5/srv/svr_principal.c
diff -c krb5/lib/kadm5/srv/svr_principal.c:1.3 krb5/lib/kadm5/srv/svr_principal.c:1.4
*** krb5/lib/kadm5/srv/svr_principal.c:1.3 Tue Jun 3 00:07:00 1997
--- krb5/lib/kadm5/srv/svr_principal.c Thu Jun 26 19:19:38 1997
***************
*** 1,11 ****
/*
* Copyright 1993 OpenVision Technologies, Inc., All Rights Reserved
*
! * $Header: /afs/cmf.nrl.navy.mil/project/cvsroot/krb5/lib/kadm5/srv/svr_principal.c,v 1.3 1997/06/03 04:07:00 kenh Exp $
*/

#if !defined(lint) && !defined(__CODECENTER__)
! static char *rcsid = "$Header: /afs/cmf.nrl.navy.mil/project/cvsroot/krb5/lib/kadm5/srv/svr_principal.c,v 1.3 1997/06/03 04:07:00 kenh Exp $";
#endif

#include <sys/types.h>
--- 1,11 ----
/*
* Copyright 1993 OpenVision Technologies, Inc., All Rights Reserved
*
! * $Header: /afs/cmf.nrl.navy.mil/project/cvsroot/krb5/lib/kadm5/srv/svr_principal.c,v 1.4 1997/06/26 23:19:38 kenh Exp $
*/

#if !defined(lint) && !defined(__CODECENTER__)
! static char *rcsid = "$Header: /afs/cmf.nrl.navy.mil/project/cvsroot/krb5/lib/kadm5/srv/svr_principal.c,v 1.4 1997/06/26 23:19:38 kenh Exp $";
#endif

#include <sys/types.h>
***************
*** 358,364 ****

CHECK_HANDLE(server_handle);

! if((mask & KADM5_PRINCIPAL) || (mask & KADM5_LAST_PWD_CHANGE) ||
(mask & KADM5_MOD_TIME) || (mask & KADM5_MOD_NAME) ||
(mask & KADM5_MKVNO) || (mask & KADM5_AUX_ATTRIBUTES) ||
(mask & KADM5_KEY_DATA) || (mask & KADM5_LAST_SUCCESS) ||
--- 358,364 ----

CHECK_HANDLE(server_handle);

! if((mask & KADM5_PRINCIPAL) ||
(mask & KADM5_MOD_TIME) || (mask & KADM5_MOD_NAME) ||
(mask & KADM5_MKVNO) || (mask & KADM5_AUX_ATTRIBUTES) ||
(mask & KADM5_KEY_DATA) || (mask & KADM5_LAST_SUCCESS) ||
***************
*** 527,532 ****
--- 527,545 ----
kdb.tl_data = tl;
tl2 = tl2->tl_data_next;
}
+ }
+
+ /*
+ * I'm not sure if client programs should be forced to modify the
+ * TL_DATA directly, or use the obvious mechanism of modifying
+ * KADM5_LAST_PW_CHANGE. To me, the latter seems to make more
+ * sense.
+ */
+
+ if (mask & KADM5_LAST_PWD_CHANGE) {
+ if ((ret = krb5_dbe_update_last_pwd_change(handle->context, &kdb,
+ entry->last_pwd_change)))
+ goto done;
}

ret = kdb_put_entry(handle, &kdb, &adb);

From: Marc Horowitz <marc@cygnus.com>
To: kenh@cmf.nrl.navy.mil
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: 26 Jun 1997 21:07:50 -0400

Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:


If you set the +needchange bit, you should still be able to change the
password. If I'm wrong about this, then that should be fixed. I
don't that this data should be changeable via the admin system,
because it only cures the symptom, not the disease.

Marc

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Marc Horowitz <marc@cygnus.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: Thu, 26 Jun 1997 23:49:27 -0400


Well, yes, that's true .... but once you set +needchange, you can't
get any other tickets _until_ you change the password. This means
you're effectively screwed if, for example, someone has to log into
your dialup server with their Kerberos password to _change_ their
Kerberos password. Unfortunately, +needchange really doesn't work
as well as I'd like it.


Well, actually, it's changable now, because clients are allowed
to modify a principal's TL_DATA .... I'm just providing a nicer
way of setting it :-)

If you've got a solution for situations where you can't run kpasswd,
(or an equivalant) I'd love to hear it .... but I don't think there
is one. I personally think having the last pwd change date be
updated when an admin changes your password is a bug, but that
seems like a harder nut to crack.

--Ken

From: Marc Horowitz <marc@cygnus.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: 27 Jun 1997 18:03:00 -0400

Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:


Cygnus KerbNet has full support for +needchange in login, xdm, and
NT gina. See my next message for details. (Finally!)

Marc

From: Marc Horowitz <marc@cygnus.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: 27 Jun 1997 18:06:03 -0400

oh, this is krb5-bugs, not comp.protocols.kerberos. See my upcoming
post there :-)

Marc

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Marc Horowitz <marc@cygnus.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: Fri, 27 Jun 1997 18:24:48 -0400


By "(or an equivalant)" I was referring to cases where you had the
ability to roll support for +needchange into the login process.

This isn't a solution for our users that are coming in via our Cisco,
our Netblazer, or our Annex, or any other systems that we can't run
our own version of Kerberos on.

--Ken

From: Marc Horowitz <marc@cygnus.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/440: It is impossible to change the last pwd change date
Date: 27 Jun 1997 20:19:48 -0400

Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:


Well, it is possible to modify the annex daemon to prompt for a new
password. Cisco and Netblazer are harder. Anyway, since dialup
passwords are often scripted, we always used a different principal for
dialup access. You could make this principal not have a minimum
password life, since it's highly vulnerable, anyway.

Marc