Skip Menu |
 

Download (untitled) / with headers
text/plain 11.3KiB
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

Show quoted text
>Number: 440
>Category: krb5-admin
>Synopsis: You can't change the last pwd change date
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bjaspan
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Thu Jun 26 19:42:01 EDT 1997
>Last-Modified: Fri Jun 27 20:21:01 EDT 1997
>Originator: Ken Hornstein
>Organization:
Navel Lint Research Laboratory

Show quoted text
>Release: 1.0pl1
>Environment:

System: SunOS nexus 4.1.4 3 sun4m
Architecture: sun4

Show quoted text
>Description:

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.
Show quoted text
>How-To-Repeat:

Enable minumum password lifetimes for a while with a large user population.
Show quoted text
>Fix:

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);
Show quoted text
>Audit-Trail:

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:

Show quoted text
>> 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.

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

Show quoted text
>If you set the +needchange bit, you should still be able to change the
>password.

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.

Show quoted text
>I
>don't that this data should be changeable via the admin system,
>because it only cures the symptom, not the disease.

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:

Show quoted text
>> 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.

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

Show quoted text
>>> 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.
>
>Cygnus KerbNet has full support for +needchange in login, xdm, and
>NT gina. See my next message for details. (Finally!)

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:

Show quoted text
>> 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.

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
Show quoted text
>Unformatted:
Download (untitled) / with headers
text/plain 6.3KiB
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

Show quoted text
>Number: 441
>Category: krb5-admin
>Synopsis: You can't change the last pwd change date
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bjaspan
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Thu Jun 26 19:43:03 EDT 1997
>Last-Modified:
>Originator: Ken Hornstein
>Organization:
Navel Lint Research Laboratory

Show quoted text
>Release: 1.0pl1
>Environment:

System: SunOS nexus 4.1.4 3 sun4m
Architecture: sun4

Show quoted text
>Description:

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.
Show quoted text
>How-To-Repeat:

Enable minumum password lifetimes for a while with a large user population.
Show quoted text
>Fix:

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);
Show quoted text
>Audit-Trail:
>Unformatted: