Henry B. Hotz wrote:
You know the only thing that would *really* satisfy me is if Kerberos
and AFS used the same ticket/token storage mechanism, and that
mechanism had all the properties of PAG's (and there were proper
tools for dealing with the storage). None of the three camps have
made fundamentally wrong design decisions, but I hate the results.
Sounds like what DCE/DFS did. The Kerberos tickets where stored
in a well known location, with the PAG number as part of the file name.
/opt/dcelocal/var/security/creds/deccred_xxxxxxxx where xxxxxxxx was
the PAG. Then the kernel could tell dced (something
like afsd) to fetch a ticket from the cache or even get additional tickets
and renew tickets. This also allowed DFS to use a separate principal
for each server. This is kind of what Windows does too with cifs/servername
principals. So it can be done.
Other applications could use the tickets in the cache bu seting the
KRB5CCNAME to point at the deccred_xxxxxxxx. So "Kerberos and DFS used the
same ticket/token storage mechanism."
I'll shut up now. I think we've beat this horse to death.
It may not be dead, just turned out to pasture to early.
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
_______________________________________________
krbdev mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/krbdev
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
