AFS also comes with its own kaserver that is K4 and DES only based. Many sites have used other KDCs instead, including MIT and Heimdal with K4 and K5 and some sites have used the krb524d along with programs like aklog, ak5log and gssklog to use K5 only KDC, like DCE and AD that don't have K4.
But not all sites have converted. But are being encouraged to. I don't know how many are still out there. Since the author of the note you sited was trying to use the pam_krb5, they are not using K4. They may have got their users by now converted. Ask them. As Ken said, the issue may have to do with passwords not being changed sine a conversion for a kaserver to a real Kerberos server where the salt was carried over. Looking at the OpenAFS source code, the kpasswd.c does have options for using the MIT type salt. So it might be possible to have people change their passwords before any conversion to a new KDC, and thus avoid the afs3 salt. The e-mail you sited from 2007 may be a mute point today. You may want to ask the sender. We use AD as the KDC, and thus don't trust me on any of these comments on the kaserver. Ask on the OpenAFS lists. Will Fiveash wrote: > On Fri, Aug 22, 2008 at 03:30:59PM -0400, Ken Raeburn wrote: >> On Aug 21, 2008, at 17:39, Will Fiveash wrote: >>> I'm wondering what the best solution is in regards to OpenSolaris krb >>> handling the afs3 salt type. Our kdc.conf man page states that only the >>> normal salt type is supported and there is a bug CR relating to this: >>> >>> 6734142 krb should only accept the normal salt type >> I think mainly it'd be an issue for sites that have migrated databases that >> were once in kaserver, and haven't forced everyone to change their >> passwords. After a password change, a user should be getting the >> configured (normally "normal") salt types, I think. But even if the site >> has been running MIT or Sun KDCs for years, if some accounts haven't >> changed their passwords, the keys stored would still require that the >> clients be able to use AFS string-to-key, and that the KDC be able to tell >> the clients to do so. > > Ken, if AFS currently requires krbv4 then a Solaris KDC can not be used, > right? (Solaris krb has never supported krbv4) No, AFS is in a transition. The AFS token was originally a K4 service ticket, obtained using the klog program from the kaserver or other K4 KDC. But today the encrypted part of a K5 ticket can be used in the token. The TGT for the user can be K5, and use more then DES. The aklog, ak5log or gssklog is an application program that requests a token using the K5 TGT, and K5 service ticket for afs/cell at REALM directly or use it with krb524d or gssklogd to get an AFS token. Many sites use pam_afs_session to call aklog to get the token during login or sshd using delegated credentials. So a Solaris KDC can work. The problem comes when one wants to convert from the kaserver to a real K5 KDC, without the user having to change the password. > >> I doubt there's much need these days for the KDC to support use of afs3 >> salt when updating entries in the database. But both angles are probably >> worth asking AFS users about... > > Based on what Ken and Doug wrote about this I now think that OS krb code > should support the AFS string-to-key function for backwards compat but > disallow use of the afs3 salttype when creating new princ keys. Sounds good to me. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
