daemon@ATHENA.MIT.EDU (Hugh C. Lauer)
Wed Jan 24 17:51:43 1990
From: lauer@BTC.KODAK.COM (Hugh C. Lauer)
To: kerberos@ATHENA.MIT.EDU
Cc: lauer@BTC.KODAK.COM
I may have had too high an expectation for Kerberos, or perhaps I am
overlooking something obvious. I had hoped that it would help me solve
an adminstration problem of a large number of users over a wide area
network, but upon experimentation it seems that it does not.
What I want to do:- I have a half-dozen or so sites spread across the
country, each with a local system administrator (whom I am prepared to
trust). I want each site to be able to register its own users, but I
want all of the users to be able to login into hosts at the other
sites, either physically when they are travelling or remotely via the
network. When they do, I want them to at least be recognized as
themselves; in a more advanced world, it would be nice to also let them
have their own home directories, etc.
So I started experimenting with Kerberos; for the time being, I avoided
replicated databases and multiple realms. For basics, I tried creating
a number of fictitious users in a single Kerberos database, then set up
and registered some services with the same database. Then I
authenticated myself as one of these fictitious users and tried to do
what a real remote user would have done -- rlogin to one of the
registered servers. The authentication seemed to proceed to
completion, but the server returned an error message of the following form:-
pyramus% rlogin tundra
login: lauer has not given you permission to login without a password.
Password:
The only password that it seemed accept is MY personal password.
Of course, the fictitious user is not registered in /etc/passwd on the
remote machine, so what user id would he have become if he did
successfully log in? do all such users become me?
Am I overlooking something very simple and dumb, or am I expecting too
much of Kerberos? Do I have to register all of the users of all of my
sites in a giant /etc/passwd file and propagate it everywhere? or what?
Thanks,
/Hugh Lauer
Kodak Boston Technology Center
daemon@ATHENA.MIT.EDU (Jon A. Rochlis)
Wed Jan 24 20:16:34 1990
From: jon@MIT.EDU (Jon A. Rochlis)
To: lauer@BTC.KODAK.COM (Hugh C. Lauer)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Wed, 24 Jan 90 17:33:26 -0500.
Am I overlooking something very simple and dumb, or am I expecting too
much of Kerberos?
I think you are expecting too much. Remember Kerberos is just
providing authentication service (it tells a service who you are),
nothing more. What you are asking for is authorization (should the
service allow you to access its resources, i.e. login in the case of
an remote login service).
Do I have to register all of the users of all of my
sites in a giant /etc/passwd file and propagate it everywhere? or what?
Basically you must have some authorization policy which your remote
login server implements. The most obvious is the default:
if kerberos user "a.b@r" tries to login as unix user xxx
look up xxx in /etc/passwd
if xxx doesn't exist deny the login (possibly failing
back to asking for an account/password, which
has *nothing* to do with kerberos)
if xxx does exist then
look in ~xxx/.klogin for a line authorizing
a.b@r to login as xxx. if found allow the login.
if ~xxx/.klogin doesn't exist allow the login
only if the kerberos name is xxx.null@local-realm
(I should mention that if you're logged into a unix machine as
"lauer", kinit as "testuser", and type "rlogin somehost", you will be
attempting to login to "somehost" as the unix user "lauer" with
Kerberos credentials of "testuser.null@local-realm". If you wanted to
login say, as root, you would need to do "rlogin somehost -l root",
and if testuser was in ~/.klogin on somehost you would win.)
The issue here as you note, is how you get /etc/passwd on the
thousands of machines you might find. You have a couple of realistic
options:
maintain accounts in a central database and download to each
server periodically
maintain accounts in a central database and have the servers
query nameservers to get the data (ala Yellow Pages
and Hesiod)
(note there are security issues with how this information is
delivered to the servers)
Athena has several systems which help out with authorization.
Including Moira (the service managment system) and Hesiod (the
nameserver). There are several papers about this available for
anonymous ftp from athena-dist.mit.edu, including a paper outlining
all the various services which make up the Athena distributed
environment. Kerberos is just one of the services. Expecting
Kerberos to provide all the services required to run such an
environment is asking a bit much.
-- Jon
daemon@ATHENA.MIT.EDU (Jerome H Saltzer)
Thu Jan 25 15:37:07 1990
To: lauer@BTC.KODAK.COM (Hugh C. Lauer), jon@MIT.EDU (Jon A. Rochlis)
Cc: kerberos@ATHENA.MIT.EDU
From: Jerome H Saltzer < Saltzer@MIT.EDU>
In-Reply-To: Message of Wed, 24 Jan 90 19:35:38 EST
Jon is correct that the question here is one of authorization policy, which lies
outside Kerberos. However, it may not be so hard to create a policy that does
what Hugh needs. The key is his assertion that he is prepared to trust the
various administrators of his several systems.
Suppose he were to modify the remote login server policy to be something like
the following:
if kerberos user "xxx@r" tries to login as unix user xxx
look up xxx in /etc/passwd
if xxx doesn't exist then
if "r" is the realm that this system trusts ("local-realm")
create user xxx, with password "*"
if not, deny the login
if xxx does exist then
look in ~xxx/.klogin for a line authorizing
xxx@r to login as xxx. if found allow the login.
if ~xxx/.klogin doesn't exist allow the login
only if the kerberos name is xxx.null@local-realm
That is essentially the same policy we use on Athena workstations (with regular
login, rather than rlogin) and it seems to have approximately the properties
that Hugh requires. Making the same change in policy to local login would
permit a Kerberos-registered user to walk up to a system at a different site and
login.
Jerry