[53] in Kerberos
Re: caucus (propagation to servers)
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:20:11 1987
From Saltzer@ATHENA.MIT.EDU Sat Aug 16 11:05:27 1986
Date: Sat, 16 Aug 86 11:01:49 EDT
To: Win Treese <treese@ATHENA.MIT.EDU>
Subject: Re: caucus (propagation to servers)
Cc: Dan Geer <geer@ATHENA.MIT.EDU>, bcn@ATHENA.MIT.EDU, fhsu@ATHENA.MIT.EDU,
jis@ATHENA.MIT.EDU, mike@ATHENA.MIT.EDU, ostlund@ATHENA.MIT.EDU,
kerberos@ATHENA.MIT.EDU
In-Reply-To: Win Treese <treese@ATHENA.MIT.EDU>'s message of Wed, 13 Aug 86 13:07:08 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <Saltzer-PC>
It seems to me that propagating password files (and creating user
directories) several times a day is primarily a requirement that came
from general-purpose time-sharing service. After a little more
software is in place, propagation shouldn't be needed for any servers
to which general users don't log in.
The missing link is the proposed ACLS server. If we put an ACLS
service in place, the other servers can be set up to allow direct login
only by root. All other login would be Kerberos-mediated, just as on
a workstation, and restricted to those who can present an ACLS
proof-of-membership ticket in one of a small number of lists, such as
"operations" and "print-server-operators". The membership of those
lists would be managed by the ACLS server; the set of lists would
change rarely, so there would be no need for daily propagation to
run-of-the-mill servers.
This approach leaves two special cases.
1. There is one entry in the /etc/passwd file on each server:
root. Occasionally that root password must be changed. Probably a
Kerberos-mediated rcp of a new /etc/passwd is the simplest way. This
event isn't accompanied by creating a new directory, so doesn't
require such a heavy-duty mechanism as propagation. A script running
on Hector that krcp's all of these one-line server password files
sounds about right.
2. Kerberos itself should be set up in the same way, but allow
login only by root and by users delivering Kerberos-supplied tickets
that it has itself authenticated, rather than list-membership-tickets
from the ACLS. In addition, probably the Kerberos servers shouldn't
allow anyone to rcp a new /etc/passwd; their root passwords must be
changed by hand.
While waiting for an ACLS to appear, traditional propagation of
/etc/passwd files to non-Kerberos servers is probably the simplest
way to proceed, though.
Jerry
