>1. Is it possible to have more than one tgt principal per password?
A minor nit ... it's a bit of a misnomer to call it a "tgt password";
the password is really associated with the principal, not the tgt per se
(and the phrase "tgt password" might mean the session key stored in the
TGT, which isn't what you're talking about at all).
And from your description, I _think_ you have the question backwards ...
I think you really want to know if you can have more than one encryption
key per password. The answer is yes; this is supported in MIT V5 today.
Can't do it with V4 or the AFS kaserver AFAIK.
The problem _I_ see is that you'll need to store secrets on your samba
server that could be used to get Kerberos tickets, which in essence
turns your samba server into another KDC.
>2. If not, could I setup two principals in Kerberos and modify MIT's aklog
>program to smash those principals into the same AFS token?
You'd have to do this translation on the server, since the only important
part is the identity in the encrypted ticket.
>3. Is there something obvious I'm missing in this puzzle which would make
>the problem easier?
Well .... it's a toughie. You'd really want to send the Samba server
one of your forwarded Kerberos tickets, but unfortunately that's not
an option.
The real problem is that your Samba server has to prove the identity
of principals to Kerberos using something has no relation to
Kerberos, so (AFAIK) the only way to make this work is to give the
Samba server the ability to get a Kerberos ticket for _anybody_,
and trust the Samba server to DTRT (and guard it with your life).
If anyone has a way around this, I'd love to hear it.
AFAIK, everyone who uses Samba with AFS sucks it up and sends
plaintext passwords. Luckily I killed Samba here before it got
off the ground, and now that the NT AFS client exists, it's not an
issue anymore.
Oh, note that I mean no disrespect to the authors of Samba when I
say that I killed it; they did a fine piece of work. It's just
that the protocol they have to interoperate with isn't so great on
the authentication side :-/ I knew that our goal was no plaintext
passwords, and since we didn't have any control over the SMB client
software we could really make it work with Kerberos, and if SMB
got too entrenched at our site it would have been impossible to get
rid of it (POP was bad enough, but luckily we were able to come up
with Kerberos solutions for everybody).
--Ken
