[2444] in Kerberos
Re: kdb5_edit extract_srvtab brain-damaged
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed Dec 9 15:16:53 1992
Date: 9 Dec 1992 19:36:48 GMT
From: jik@Athena.MIT.EDU (Jonathan I. Kamens)
To: kerberos@shelby.Stanford.EDU
In article <9212090607.AA10929@tsx-11.MIT.EDU>, tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
|> Date: 7 Dec 1992 20:48:57 GMT
|> From: jik@Athena.MIT.EDU (Jonathan I. Kamens)
|>
|> The kdb5_edit version of extract_srvtab is broken in two different
|> ways: (1) It thinks that principals contain a single-component aname
|> and single-component instance, a la V4;
|>
|> As far as the MIT implementation is concerned, that *is* the convention.
|> Other implementations of the protocol may use something else, but all of
|> the clients and the application are going to be using the convention of
|> first component is the name of the service, second component is the
|> fully qualified domain name of the host.
I understand this. I agree that kdb5_edit should make it easy to do things
that are in accord with the conventions employed in the MIT distribution.
However, I see no reason for the program to *limit* what the user can do, if
the user *does* choose to use some other convention.
In other words, the program should provide access to the full functionality of
the protocol and keytab file implementation. Without the patch I sent in, it
doesn't (which isn't to say that with the patch, it does :-).
An example: I am working on adding Kerberos authentication to a system which
uses names other than canonicalized host names to identify services entities.
In fact, the client programs which need to contact the service entity have no
way of finding out the real host name of those entities -- all they know is the
names used by the system. Therefore, I have no choice but to use those names
as my instances in the Kerberos database, but I want those keys to reside in
the standard keytab file, not in a separate one.
--
Jonathan Kamens jik@MIT.Edu
MIT Information Systems/Athena Moderator, news.answers
