From wyllys@borg.SFBay.Sun.COM Tue Jun 3 06:18:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53DHxHF022713 for ; Tue, 3 Jun 2008 06:17:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m53DHuGK027961 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 3 Jun 2008 14:17:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W0080529WR000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 03 Jun 2008 06:17:56 -0700 (PDT) Received: from borg.SFBay.Sun.COM ([10.6.50.138]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00LN229VN7D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 03 Jun 2008 06:17:55 -0700 (PDT) Received: from borg.SFBay.Sun.COM (localhost [127.0.0.1]) by borg.SFBay.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m53DAPoo013597; Tue, 03 Jun 2008 06:10:25 -0700 (PDT) Received: (from wyllys@localhost) by borg.SFBay.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m53DAPVd013593; Tue, 03 Jun 2008 06:10:25 -0700 (PDT) Date: Tue, 03 Jun 2008 06:10:25 -0700 (PDT) From: Wyllys Ingersoll Subject: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] To: PSARC-ext@sun.com Cc: kerberos-discuss@opensolaris.org Message-id: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5889 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: removal of kadm5.keytab 1.2. Name of Document Author/Supplier: Author: Mark Phalan 1.3 Date of This Document: 03 June, 2008 4. Technical Description Proposal: Removal of /etc/krb5/kadm5.keytab Release Binding: patch With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in progress) kadmind(1M) reads the keys it needs directly from the Kerberos database. Prior to this a keytab file had to be populated with the keys kadmind required. By default this file was located at /etc/krb5/kadm5.keytab. Allowing kadmind to read the keys directly from the Kerberos database has a number of advantages: * Less administrative work during setup * Removes a whole class of errors where the keytab has old keys, lacks the relevent keys etc. Old keytabs and the "admin_keytab" option in kdc.conf will be silently ignored. PSARC/1998/125 (Kerberos V5 Remote Administration) introduced the man pages for kadmin(1M) and kadmind(1M). Man-page diffs: =========== kadmind(1M) =========== kadmind requires a number of configuration files to be set up for it to work: /etc/krb5/kdc.conf The KDC configuration file contains configuration infor- mation for the KDC and the Kerberos administration sys- tem. kadmind understands a number of configuration vari- ables (called relations) in this file, some of which are mandatory and some of which are optional. In particular, kadmind uses the acl_file, dict_file, admin_keytab, and kadmind_port relations in the [realms] section. Refer to the kdc.conf(4) man page for information regarding the format of the KDC configuration file. - /etc/krb5/kadm5.keytab - - kadmind requires a keytab (key table) containing correct - entries for the kadmin/fqdn, kadmin/changepw and - kadmin/changepw principals for every realm that kadmind - answers requests. The keytab can be created with the - kadmin.local(1M) or kdb5_util(1M) command. The location - of the keytab is determined by the admin_keytab relation - in the kdc.conf(4) file. - - /etc/krb5/kadm5.acl kadmind uses an ACL (access control list) to determine ... sunw_dbprop_master_ulogsize = N Specifies the maximum amount of log entries available for incremental propagation to the slave KDC servers. The maximum value that this can be is 2500 entries. Default value is 1000 entries. - The kiprop/@ principal must exist in the - master's kadm5.keytab file to enable the slave to authenti- - cate incremental propagation from the master. In the princi- - pal syntax above, is the master KDC's host name - and is the realm in which the master KDC resides. - - Kerberos client machines can automatically migrate Unix users to the default Kerberos realm specified in the local krb5.conf(4), if the user does not have a valid kerberos ... FILES ... /etc/krb5/kadm5.acl List of principals and their kadmin administrative privileges. - /etc/krb5/kadm5.keytab - - Keytab for kadmin principals: kadmin/fqdn, - changepw/fqdn, and kadmin/changepw. - - /etc/krb5/kdc.conf KDC configuration information. =========== kadmin(1M) =========== ktadd [-k keytab] [-q] [-e enctype:salt] ... If the -q option is specified, less status information is displayed. Aliased by xst. The -glob option requires - the list privilege. Also, note that if you use -glob to - create a keytab, you need to remove - /etc/krb5/kadm5.keytab and create it again if you want - to use -p */admin with kadmin. + the list privilege. - princ-exp princ-exp follows the same rules described for the ... FILES ... /etc/krb5/kadm5.acl List of principals and their kadmin administrative privileges. - /etc/krb5/kadm5.keytab - - Keytab for kadmind principals: kadmin/fqdn, - changepw/fqdn, and kadmin/changepw. - - ATTRIBUTES =========== kdc.conf(4) =========== The realms Section This section contains subsections for Kerberos realms, where relation-subsection is the name of a realm. Each subsection contains relations that define KDC properties for that par- ticular realm. The following relations can be specified in each subsection: ... - admin_keytab - - (string) Location of the keytab file that kadmin uses to - authenticate to the database. The default location is - /etc/krb5/kadm5.keytab. - - database_name (string) Location of the Kerberos database for this ... FILES ... /etc/krb5/kadm5.acl List of principals and their kadmin administrative privileges. - /etc/krb5/kadm5.keytab - - Keytab for kadmind principals: kadmin/fqdn, - changepw/fqdn, and kadmin/changepw. - - /var/krb5/principal Kerberos principal database. =========== kdcmgr(1M) =========== FILES ... /etc/krb5/kadm5.acl Kerberos administrative access control list (ACL). - /etc/krb5/kadm5.keytab - - Service keys specific to kadmind(1M). - - /var/krb5/principal 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Tue Jun 3 06:35:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53DZbTw022831 for ; Tue, 3 Jun 2008 06:35:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53DZX3u008463 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Tue, 3 Jun 2008 21:35:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W0050333A4R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 03 Jun 2008 06:35:34 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00B4M3398980@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 03 Jun 2008 06:35:33 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m53DS2QU002795; Tue, 03 Jun 2008 09:28:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m53DS2IG002792; Tue, 03 Jun 2008 09:28:02 -0400 (EDT) Date: Tue, 03 Jun 2008 09:28:02 -0400 From: James Carlson Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <18501.18146.734573.29693@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> Status: RO Content-Length: 699 Wyllys Ingersoll writes: > With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in > progress) kadmind(1M) reads the keys it needs directly from the > Kerberos database. Prior to this a keytab file had to be populated > with the keys kadmind required. By default this file was located at > /etc/krb5/kadm5.keytab. Is there anything that the administrator needs to do to make the new scheme work? Do the existing keys need to be transferred out of that file somehow? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Mark.Phalan@sun.com Tue Jun 3 06:47:47 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53Dlknq022908 for ; Tue, 3 Jun 2008 06:47:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53DliOx013038 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 21:47:45 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00G033NKLP00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 07:47:44 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00FXC3NIEI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 07:47:43 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m53DlgPJ024735 for ; Tue, 03 Jun 2008 13:47:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1W009013FD8W00@fe-emea-09.sun.com> (original mail from Mark.Phalan@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 14:47:42 +0100 (BST) Received: from [129.157.71.112] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1W00JQP3NHC150@fe-emea-09.sun.com>; Tue, 03 Jun 2008 14:47:41 +0100 (BST) Date: Tue, 03 Jun 2008 15:46:21 +0200 From: Mark Phalan Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <18501.18146.734573.29693@gargle.gargle.HOWL> Sender: Mark.Phalan@sun.com To: James Carlson Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <1212500781.4281.187.camel@zup.czech.sun.com> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> Status: RO Content-Length: 808 On Tue, 2008-06-03 at 09:28 -0400, James Carlson wrote: > Wyllys Ingersoll writes: > > With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in > > progress) kadmind(1M) reads the keys it needs directly from the > > Kerberos database. Prior to this a keytab file had to be populated > > with the keys kadmind required. By default this file was located at > > /etc/krb5/kadm5.keytab. > > Is there anything that the administrator needs to do to make the new > scheme work? Do the existing keys need to be transferred out of that > file somehow? The administrator doesn't need to do anything. The keytab will just no longer be used - instead the keys will be directly read from the kerberos db. The administrator may want to delete that file (as its no longer used) but that isn't necessary. -Mark From carlsonj@phorcys.east.sun.com Tue Jun 3 06:57:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53DvR4Z023394 for ; Tue, 3 Jun 2008 06:57:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m53DvQVf065303; Tue, 3 Jun 2008 07:57:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00A0343Q7200@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:57:26 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00L6W43PN8F0@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:57:25 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m53Dnsnm002957; Tue, 03 Jun 2008 09:49:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m53Dns3A002954; Tue, 03 Jun 2008 09:49:54 -0400 (EDT) Date: Tue, 03 Jun 2008 09:49:54 -0400 From: James Carlson Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <1212500781.4281.187.camel@zup.czech.sun.com> To: Mark Phalan Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <18501.19458.506132.915880@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> <1212500781.4281.187.camel@zup.czech.sun.com> Status: RO Content-Length: 1244 Mark Phalan writes: > > On Tue, 2008-06-03 at 09:28 -0400, James Carlson wrote: > > Wyllys Ingersoll writes: > > > With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in > > > progress) kadmind(1M) reads the keys it needs directly from the > > > Kerberos database. Prior to this a keytab file had to be populated > > > with the keys kadmind required. By default this file was located at > > > /etc/krb5/kadm5.keytab. > > > > Is there anything that the administrator needs to do to make the new > > scheme work? Do the existing keys need to be transferred out of that > > file somehow? > > The administrator doesn't need to do anything. The keytab will just no > longer be used - instead the keys will be directly read from the > kerberos db. > The administrator may want to delete that file (as its no longer used) > but that isn't necessary. OK. Perhaps the file should be deleted on system upgrade, so that the user doesn't try to do something silly, like modify the file and expect it to do something. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Mark.Phalan@sun.com Tue Jun 3 07:52:51 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53EqpLo024938 for ; Tue, 3 Jun 2008 07:52:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m53Eqo0K022680 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 08:52:50 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00L0B6O27000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 08:52:50 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00FCH6O1EJ60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 08:52:50 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m53EqnJY017089 for ; Tue, 03 Jun 2008 14:52:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1W004016E44L00@fe-emea-10.sun.com> (original mail from Mark.Phalan@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 15:52:49 +0100 (BST) Received: from [129.157.71.112] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1W0030F6NF7690@fe-emea-10.sun.com>; Tue, 03 Jun 2008 15:52:29 +0100 (BST) Date: Tue, 03 Jun 2008 16:51:08 +0200 From: Mark Phalan Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <18501.19458.506132.915880@gargle.gargle.HOWL> Sender: Mark.Phalan@sun.com To: James Carlson Cc: Wyllys Ingersoll , PSARC-EXT@sun.com, kerberos-discuss@opensolaris.org Message-id: <1212504668.4281.197.camel@zup.czech.sun.com> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> <1212500781.4281.187.camel@zup.czech.sun.com> <18501.19458.506132.915880@gargle.gargle.HOWL> Status: RO Content-Length: 1690 On Tue, 2008-06-03 at 09:49 -0400, James Carlson wrote: > Mark Phalan writes: > > > > On Tue, 2008-06-03 at 09:28 -0400, James Carlson wrote: > > > Wyllys Ingersoll writes: > > > > With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in > > > > progress) kadmind(1M) reads the keys it needs directly from the > > > > Kerberos database. Prior to this a keytab file had to be populated > > > > with the keys kadmind required. By default this file was located at > > > > /etc/krb5/kadm5.keytab. > > > > > > Is there anything that the administrator needs to do to make the new > > > scheme work? Do the existing keys need to be transferred out of that > > > file somehow? > > > > The administrator doesn't need to do anything. The keytab will just no > > longer be used - instead the keys will be directly read from the > > kerberos db. > > The administrator may want to delete that file (as its no longer used) > > but that isn't necessary. > > OK. Perhaps the file should be deleted on system upgrade, so that the > user doesn't try to do something silly, like modify the file and > expect it to do something. That might be a good idea (although locating the file - parsing kdc.conf - might be tricky). As kadm5.keytab is generally managed with the "kadmin/kadmin.local" commands there is little scope for the user to become confused - the kerberos db is always updated when using those commands to modify keytabs. The only scenario I can think of where the user may not get what he expects is when he purposly tries to make kadmind fail by deleting or corrupting kadm5.keytab. In this scenario kadmind will still continue to work when the user may expect it to fail. -Mark From carlsonj@phorcys.east.sun.com Tue Jun 3 08:06:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53F66UZ025513 for ; Tue, 3 Jun 2008 08:06:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m53F5pVO017508; Tue, 3 Jun 2008 16:06:04 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00C0Z7A1JY00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 08:06:01 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00A7J7A08U70@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 08:06:01 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m53EwUDn003497; Tue, 03 Jun 2008 10:58:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m53EwTvW003494; Tue, 03 Jun 2008 10:58:29 -0400 (EDT) Date: Tue, 03 Jun 2008 10:58:29 -0400 From: James Carlson Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <1212504668.4281.197.camel@zup.czech.sun.com> To: Mark Phalan Cc: Wyllys Ingersoll , PSARC-EXT@sun.com, kerberos-discuss@opensolaris.org Message-id: <18501.23573.954140.979969@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> <1212500781.4281.187.camel@zup.czech.sun.com> <18501.19458.506132.915880@gargle.gargle.HOWL> <1212504668.4281.197.camel@zup.czech.sun.com> Status: RO Content-Length: 1392 Mark Phalan writes: > > On Tue, 2008-06-03 at 09:49 -0400, James Carlson wrote: > > OK. Perhaps the file should be deleted on system upgrade, so that the > > user doesn't try to do something silly, like modify the file and > > expect it to do something. > > That might be a good idea (although locating the file - parsing kdc.conf > - might be tricky). I see. Perhaps a boot-time (or one-time on upgrade) warning if the path is specified in kdc.conf? > As kadm5.keytab is generally managed with the "kadmin/kadmin.local" > commands there is little scope for the user to become confused - the > kerberos db is always updated when using those commands to modify > keytabs. The only scenario I can think of where the user may not get > what he expects is when he purposly tries to make kadmind fail by > deleting or corrupting kadm5.keytab. In this scenario kadmind will still > continue to work when the user may expect it to fail. I guess I was thinking more about what happens when things are restored from backup; the key will always be the one in the db, even if a different one is (somehow) given elsewhere. Perhaps that just doesn't happen in practice ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Mark.Phalan@Sun.COM Tue Jun 3 08:43:46 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53FhkNc026330 for ; Tue, 3 Jun 2008 08:43:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m53FhkHQ001963 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 3 Jun 2008 08:43:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00H0D90WAD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 08:43:44 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00F8J90VII10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 08:43:44 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m53Fhh9D012391 for ; Tue, 03 Jun 2008 15:43:43 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1W005017XTIV00@fe-emea-10.sun.com> (original mail from Mark.Phalan@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 16:43:43 +0100 (BST) Received: from [129.157.71.112] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1W008Q690EI5B0@fe-emea-10.sun.com>; Tue, 03 Jun 2008 16:43:26 +0100 (BST) Date: Tue, 03 Jun 2008 17:42:07 +0200 From: Mark Phalan Subject: Re: removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <18501.23573.954140.979969@gargle.gargle.HOWL> Sender: Mark.Phalan@Sun.COM To: James Carlson Cc: Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <1212507727.4281.209.camel@zup.czech.sun.com> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> <1212500781.4281.187.camel@zup.czech.sun.com> <18501.19458.506132.915880@gargle.gargle.HOWL> <1212504668.4281.197.camel@zup.czech.sun.com> <18501.23573.954140.979969@gargle.gargle.HOWL> Status: RO Content-Length: 1944 On Tue, 2008-06-03 at 10:58 -0400, James Carlson wrote: > Mark Phalan writes: > > > > On Tue, 2008-06-03 at 09:49 -0400, James Carlson wrote: > > > OK. Perhaps the file should be deleted on system upgrade, so that the > > > user doesn't try to do something silly, like modify the file and > > > expect it to do something. > > > > That might be a good idea (although locating the file - parsing kdc.conf > > - might be tricky). > > I see. Perhaps a boot-time (or one-time on upgrade) warning if the > path is specified in kdc.conf? > > > As kadm5.keytab is generally managed with the "kadmin/kadmin.local" > > commands there is little scope for the user to become confused - the > > kerberos db is always updated when using those commands to modify > > keytabs. The only scenario I can think of where the user may not get > > what he expects is when he purposly tries to make kadmind fail by > > deleting or corrupting kadm5.keytab. In this scenario kadmind will still > > continue to work when the user may expect it to fail. > > I guess I was thinking more about what happens when things are > restored from backup; the key will always be the one in the db, even > if a different one is (somehow) given elsewhere. Perhaps that just > doesn't happen in practice ... The one in the Kerberos db is the one that matters as that's the one the KDC will use to generate service tickets with. Having the key in two different places (kadm5.keytab and the kerberos db) and out-of-sync will currently prevent kadmind from working properly. With this change the out-of-sync class of errors just goes away - the key material is in just one place: the Kerberos db. If the user restores a Kerberos db from backup but not kadm5.keytab, it will work (old behaviour: not work). If the user restores kadm5.keytab from backup but not the Kerberos db, it will work (old behaviour: not work). So I don't see any new issues when backups are involved. -M From Nicolas.Williams@sun.com Tue Jun 3 08:56:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53FuXKQ027068 for ; Tue, 3 Jun 2008 08:56:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53FuRvk001078; Tue, 3 Jun 2008 23:56:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00E039M41Y00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 08:56:28 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00AP59M38VA0@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 08:56:27 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m53FuPGp005696; Tue, 03 Jun 2008 10:56:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m53FuPg2005695; Tue, 03 Jun 2008 10:56:25 -0500 (CDT) Date: Tue, 03 Jun 2008 10:56:25 -0500 From: Nicolas Williams Subject: Re: [kerberos-discuss] removal of kadm5.keytab [PSARC/2008/358 FastTrack timeout 06/10/2008] In-reply-to: <18501.23573.954140.979969@gargle.gargle.HOWL> To: James Carlson Cc: Mark Phalan , PSARC-EXT@sun.com, Wyllys Ingersoll , kerberos-discuss@opensolaris.org Mail-followup-to: James Carlson , Mark Phalan , PSARC-EXT@sun.com, Wyllys Ingersoll , kerberos-discuss@opensolaris.org Message-id: <20080603155624.GS2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806031310.m53DAPVd013593@borg.SFBay.Sun.COM> <18501.18146.734573.29693@gargle.gargle.HOWL> <1212500781.4281.187.camel@zup.czech.sun.com> <18501.19458.506132.915880@gargle.gargle.HOWL> <1212504668.4281.197.camel@zup.czech.sun.com> <18501.23573.954140.979969@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1626 On Tue, Jun 03, 2008 at 10:58:29AM -0400, James Carlson wrote: > I guess I was thinking more about what happens when things are > restored from backup; the key will always be the one in the db, even > if a different one is (somehow) given elsewhere. Perhaps that just > doesn't happen in practice ... The KDB is the authoritative DB. kadm5.keytab can be seen as a "cache" that administrators previously had to _manually_ keep in sync with the KDB. Keytabs can be seen as a subset of the KDB. Remember, Kerberos V is a protocol where principals share secret keys with the KDC; the KDB is the database where the KDC stores the keys it shares with all its principals. Users, of course, just remember their passwords and the system derives their keys therefrom. Non-human principals store their keys in a local key store; for MIT krb5-derived implementations that would be a "keytab" file. Now, kadmind *always* has direct access to the KDB, so it shouldn't ever have needed any keytabs: it has direct access to the relevant keys via the KDB! kadm5.keytab was only ever needed because the relevant code infrastructure (pertaining to the AP exchange part of the protocol) didn't support looking for keys in the KDB. MIT krb5 1.6.3 fixes this. That fix renders kadm5.keytab no longer necessary. There is nothing that administrators can do to kadm5.keytab via the usual admin utilities (kadmin(1M) and kadmin.local(1M)) that wouldn't also update the KDB anyways. (Very knowledgeable admins could use ktutil(1), which doesn't update the KDB, but savvy admins just wouldn't do that for kadm5.keytab maintenance.) Nico --