[BBLISA] Am I missing the screamingly obvious? (AFS/Kerberos/LDAP)

[Michael Tiernan]

Right from the start I'll admit to being out on a knowledge limb and
getting close to it falling out from under me.

I'm having a problem with some SSH/AFS/Kerberos aspects. It might be
that I am asking for something that I just can't do. I don't know and
I'm turning to this august group for some advice.

Problem:
(These are all "standard" Linux systems, CentOS5)

I have a system "fred" it is in a kerberos realm "MONDAY" and there's
no AFS component in this realm.

I have another system "barney" which *IS* in a kerberos realm
"TUESDAY" and has an AFS compomponent in it (which works fine).

So, I have a user "Me" who wants to log onto "fred" via an SSH
connection from a standalone system, get authenticated via Kerberos
and is in the LDAP database.
This part works FINE.

"Me" can also log into "barny" from that same system via SSH, get
authenticated and get his home dir via AFS from the LDAP db.
This also works FINE.

Where it goes off the rails is this..... (I am very likely configuring
this wrong hence my asking for a reality check.)

"Me" wants to log into "fred" from the same standalone system, via the
same SSH & Authentication process and then _once logged in_, be able
to, either automagically (ala automount) or by requesting tickets and
aklog tokens, reach /afs/barny/user/me (separate from his fred home
dir)

Now, if "Me" logs into fred, sets up what seems to be reasonable
values for the AFS configs and starts AFS, "Me" _can_ kinit a ticket
for afs and then aklog a token to get into that AFS directory
properly.

BUT, if anyone else tries to log in to "fred", they get a failure
because SSH times out trying to get tokens from the "TUESDAY" realm
that they're not a real part of. OR, if the AFS configs are set up for
the realm "MONDAY" (who has no AFS server) then the AFS stuff won't
start.

I *KNOW* I've been dancing all around the problem without seeing it.

Anyone have any pointers for me?

Thank you all for the use of your bits.
-- 
    << MCT >>   Michael C Tiernan.