Kerberos and DCE
This is where we run into Doug Engert, the
Authentication Task Force,
Argonne National Labs, the DOE, etc. All one project, with Mr. Engert doing
most or all of the work and pushing MIT and various vendors to fix their stuff.
As a result, DCE is compatible with Kerberos 5, not just in theory but in
practice. Notwithstanding, there are plenty of complications.
The location and format of DCE's credentials cache is somewhat compatible
with Kerberos 5, but at best there's a lot of data in there that means something
only to DCE, relating to things Kerberos doesn't support. The environment
variable KRB5CCNAME determines the file location; Kerberos picks
/tmp/krb5cc_(uid) or /tmp/krb5cc_p(pid), DCE usually does something in
/opt/dcelocal, but both recognize that environment variable.
If telnetd (for example) wants to provide its user with a fully functional
Kerberos environment, it has to transfer the credentials from the client's
host and set them up. If it wants to make them real DCE credentials, it needs
to set them up as such.
We don't have any DCE applications to speak of. Everything like telnetd comes
from the MIT Kerberos distribution. These applications can't set up a DCE
credentials cache, without some help from something that can be linked with
the necessary DCE functions. Engert provides this in k5dcelogin. When that's
configured, it's invoked by telnetd instead of login.krb5; k5dcelogin then
in turn invokes /bin/login. (Unfortunately some of the necessary DCE functions
are not exported in IBM's libdce.a and they're reportedly unwilling to fix this,
so we have to mangle our own copy of libdce.a on AIX.)
Where the latest versions of the DCE-compatible login have been installed,
login.krb5 is a symbolic link to k5prelogin. To go back to
the standard MIT forwarding, re-link it to login.k5 -- that's the
file that MIT normally installs as login.krb5.
The MIT kpasswd is incompatible with the DCE security service. On our hosts,
passwd would be a DCE client along with its other functions, so there's no
need for a separate dce_passwd. For non-DCE hosts (Ultrix, other hosts on
campus including red et al.), we have v5passwd. It's from an
older MIT beta release of Kerberos 5, but we have a hack (courtesy of Doug
Engert) that makes the v5passwdd server work with DCE, by simply
running a dcecp change command for each request.