Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 6710 From tlyu@MIT.EDU Wed Sep 25 15:34:14 1996 Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by avalanche-breakdown.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA21497 for ; Wed, 25 Sep 1996 15:34:13 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id PAA16309 for ; Wed, 25 Sep 1996 15:34:12 -0400 Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP id AA23209; Wed, 25 Sep 96 15:34:11 EDT Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA19717; Wed, 25 Sep 1996 15:34:10 -0400 Message-Id: <9609251934.AA19717@tesla-coil.MIT.EDU> Date: Wed, 25 Sep 1996 15:34:10 -0400 From: tlyu@MIT.EDU Reply-To: tlyu@MIT.EDU To: krb5-bugs@MIT.EDU Subject: v4 kadmin functionality is lacking X-Send-Pr-Version: 3.99 >Number: 24 >Category: krb5-admin >Synopsis: v4 kadmin functionality is lacking >Confidential: no >Severity: serious >Priority: low >Responsible: bjaspan >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Wed Sep e 15:35:01 EDT 1996 >Last-Modified: Thu Feb 19 19:13:05 EST 1998 >Originator: Tom Yu >Organization: mit >Release: unknown-1.0 >Environment: System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc >Description: The current kadmin system does not provide complete compatibility with the krb4 kadmin system. >How-To-Repeat: >Fix: >Audit-Trail: From: "Barry Jaspan" To: krb5-bugs@MIT.EDU, tlyu@MIT.EDU Cc: tytso@MIT.EDU, tlyu@MIT.EDU, krb5-prs@AVALANCHE-BREAKDOWN.MIT.EDU Subject: Re: krb5-admin/24: v4 kadmin functionality is lacking Date: Wed, 25 Sep 1996 16:30:09 -0400 Is it really necessary to ahve *all* krb4 kadmin functionality, or is there only some subset that is actually required? How can we determine exactly what krb4 kadmin commands are still being used around MIT? If some can be eliminated, it may make the entire task more likely to get done. From: "Theodore Y. Ts'o" To: "Barry Jaspan" Cc: krb5-bugs@MIT.EDU, tlyu@MIT.EDU, tlyu@MIT.EDU, krb5-prs@rt-11.mit.edu Subject: Re: krb5-admin/24: v4 kadmin functionality is lacking Date: Thu, 26 Sep 1996 15:38:24 -0400 Date: Wed, 25 Sep 1996 16:30:09 -0400 From: "Barry Jaspan" Is it really necessary to ahve *all* krb4 kadmin functionality, or is there only some subset that is actually required? How can we determine exactly what krb4 kadmin commands are still being used around MIT? If some can be eliminated, it may make the entire task more likely to get done. There are 6 kadmin requests which are handed by the krb4 kadmin server: request used by CHANGE_PW kpasswd ADD_ENT reg_svr, kadmin GET_ENT kadmin MOD_ENT reg_svr, kadmin (used by administrators to set a pw) CHECK_PW reg_svr CHG_STAB get_srvtab We could not implement GET_ENT; it is supported by the v4 kadmin cli, but it doesn't do much that's useful anyway. That simplifies the job a little, but not by much. - Ted From: "Theodore Y. Ts'o" To: gnats@rt-11.mit.edu Cc: Subject: Re: krb5-admin/24: v4 kadmin functionality is lacking Date: Thu, 26 Sep 1996 15:41:33 -0400 Date: Wed, 25 Sep 1996 16:30:09 -0400 From: "Barry Jaspan" Is it really necessary to ahve *all* krb4 kadmin functionality, or is there only some subset that is actually required? How can we determine exactly what krb4 kadmin commands are still being used around MIT? If some can be eliminated, it may make the entire task more likely to get done. There are 6 kadmin requests which are handed by the krb4 kadmin server: request used by CHANGE_PW kpasswd ADD_ENT reg_svr, kadmin GET_ENT kadmin MOD_ENT reg_svr, kadmin (used by administrators to set a pw) CHECK_PW reg_svr CHG_STAB get_srvtab We could not implement GET_ENT; it is supported by the v4 kadmin cli, but it doesn't do much that's useful anyway. That simplifies the job a little, but not by much. - Ted From: "Theodore Y. Ts'o" To: Barry Jaspan Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/24: v4 kadmin functionality is lacking Date: Mon, 4 Nov 1996 14:44:01 -0500 `Theodore Y. Ts'o' made changes to this PR. *** /tmp/gnatsa002kB Mon Nov 4 14:38:09 1996 --- /tmp/gnatsb002kB Mon Nov 4 14:43:54 1996 *************** *** 17,23 **** >Synopsis: v4 kadmin functionality is lacking >Confidential: no >Severity: serious ! >Priority: medium >Responsible: bjaspan >State: open >Class: sw-bug --- 17,23 ---- >Synopsis: v4 kadmin functionality is lacking >Confidential: no >Severity: serious ! >Priority: low >Responsible: bjaspan >State: open >Class: sw-bug From: Tom Yu To: krbdev@MIT.EDU Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/24: v4 kadmin functionality is lacking Date: Sun, 9 Mar 1997 02:42:44 -0500 I am really tempted to punt completely on the krb4 kadmind problem. There are serveral reasons: The ADD_ENT and MOD_ENT requests take keys, not passwords. This is incompatible with the kadm5 API. Since only reg_svr and the krb4 kadmin use these requests, and we have a large amount of control over the use of these, I propose that we not implement them. The CHECK_PW request is used by the userreg client, which we can also rewrite to deal with kadm5. CHG_STAB could also be left unimplemented, since its usage is limited to get_srvtab, and we can distribute a shell script or something equivalent to deal with generating krb4 srvtabs. Anyway, we should also deal with the generic get_srvtab problem at some point. I don't know if a serious discussion has taken place about this yet, but the main aspect of this problem is a site with many machines needing keytabs but few administrators to walk about to machines to generate them would be bottlenecked on these administrators during krb5 deployment. There are several ways to remedy this problem, but the one that I am leaning towards is to have a special acl file that would indicate what users are allowed to change keytabs for particular hosts. Perhaps this deserves a separate PR. ---Tom State-Changed-From-To: open-closed State-Changed-By: tlyu State-Changed-When: Thu Feb 19 19:12:29 1998 State-Changed-Why: Stale. Changes to v4kadmind since then have fixed this mostly. >Unformatted: