[3456] in Kerberos
Re: Kerberos and DCE
daemon@ATHENA.MIT.EDU (Richard J Mark)
Tue Jun 21 20:26:52 1994
From: rmark@anduin.ocf.llnl.gov (Richard J Mark)
To: kerberos@MIT.EDU
Date: Tue, 21 Jun 1994 17:15:00 -0700 (PDT)
Reply-To: rmark@llnl.gov
We have had some practical experience with this issue which might be
useful for those of you bewildered by the recent exchange of messages.
There was a basic question to our approach- Can a DCE security service
be used in place of a MIT Kerberos V server to support authentication for
MIT Kerberos V "kerberized" clients and services/applications? Part of the
motivation for this is a single principal/registry database (granted there
might be some duplication of machine principals due to current naming
conventions). Administratively, this is a big win.
For us, we had heard the taxonomy of Kerberos and DCE security and that in
theory it should work but we were far more interested in verifying that it
would work. We tested with the following implementations- MIT's Kerberos
V Beta 2 release and OSF's DCE 1.0.2 release. We tested the AS component
(kinit to get TGTs) and the TGS component (with applications/services such
as krlogin/d, krsh/d, kftp/d, ktelnet/d). The DCE 1.0.2 release required
a patch due to differences in encoding rules; to our knowledge, this has
been fixed in the DCE 1.0.3 release. We observed the differences in cache
file formats and realized there are potential incompatibilities when both
MIT Kerberos V clients/services and DCE clients/services use the same cache
file. We skirted this complication since our test machines had either the
DCE environment or the MIT Kerberos V environment but not both. The
important note is that we didn't modify the MIT Kerberos V applications
to employ a DCE security server for authentication requests; we simply
changed the configuration so that the MIT Kerberos V clients used the DCE
security server.
Given the above stated implementations, we conclude that the basic
functionality works! And yes, there are many open issues (e.g., remote
administration, inter-realm/cell authentication) that are very important
for true usability.
I will be happy to elaborate on the specific details of our tests for those
interested in that sort of thing.
Regards,
Richard Mark
University of California - Lawrence Livermore National Laboratory
PO Box 808, L-61
Livermore, CA 94551
rmark@llnl.gov (e-mail)
+1-510-423-1940 (voice)
+1-510-423-8719 (FAX)
