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.

Credentials

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.

Ticket forwarding

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.

Password change

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.