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 ; 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 ; 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 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 >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 >Release: 1.0pl1 >Environment: System: SunOS nexus 4.1.4 3 sun4m Architecture: sun4 >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. >How-To-Repeat: Enable minumum password lifetimes for a while with a large user population. >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 --- 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 *************** *** 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); >Audit-Trail: From: Marc Horowitz 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 writes: >> 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 To: Marc Horowitz 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 >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. >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 To: Ken Hornstein 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 writes: >> 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 To: Ken Hornstein 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 To: Marc Horowitz 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 >>> 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 To: Ken Hornstein 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 writes: >> 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 >Unformatted: