On Thu, 2008-09-04 at 13:37 +0200, Mark Phalan wrote: > On Wed, 2008-09-03 at 19:11 -0700, Henry B. Hotz wrote: > > 1) the AFS salt is only relevant for the AS_REQ and not for the TGS_REQ. > > > > 2) anyone supporting AFS salt in a K5 kdc is almost certainly also > > supporting the standard salt as well. As noted a simple password > > change then eliminates the problem since a K5 kinit will only see the > > standard salt, and the AFS salt will only be used by kaserver > > emulation code (which Sun doesn't have). > > > > 3) all recent OpenAFS (and Arla) implementations have been able to > > handle K5 formatted AFS tokens. For some discussion of ways to get > > AFS tokens in a K5 infrastructure take a look at > > http://www.eyrie.org/~eagle/software/pam-afs-session/ > > . > > > > 4) OpenAFS strongly recommends that you use a standard Kerb5 server > > and not the kaserver for new deployments. > > > > I'm not really keeping up with AFS, and I haven't tried to build aklog > > on S10 recently, but I seriously doubt there is anything to prevent > > someone from doing a new OpenAFS deployment using a Sun Kerberos > > infrastructure. If aklog won't build, I know they would welcome > > patches to make it build, and I doubt it would be difficult. (Have > > you done this lately, Doug?) > > > > My recommendations: > > > > 1) support the AFS salt *properly* for client initial > > authentications. (The current S9/S10 and MIT code does not behave > > correctly if a >8 character AFS password is used.) I know this may be > > difficult to test, so if you don't then please at least do something > > more user-friendly than a seg-fault! > > Can you elaborate more on the seg-fault? I fixed this in S10u5 and > Nevada which sounds related: > > 6644742 kadmind cores when using an 'afs3' salt and password > 8 chars > > you can see (a very little bit) more at bugs.opensolaris.org.
Well actually you can't - it doesn't seem to be there. -M
