Earl Shannon wrote:
Hello,
This is just a minor point, and if using aklog is where things go
then fine. If I understand you correctly Ken, then aklog is getting
my token/ticket as part of setting up a session at login as a
separate application of sorts. And as I say that's fine. But my
point is I don't get a ticker for say, IMAP, until I start a mail
client and it attempts to login to the IMAP server. I'm suggesting
that the afs token/ticket doesn't need to be obtained until the
user attempts to make use of AFS, ie, by cd 'ing into the AFS
file system. And its at that point that the authentication to AFS
occurs. Using aklog as part of a session setup is a "pre-authentication"
of sorts.
Two comments here:
(1) One of the problems is that a cd /afs is done by the kernel,
where as Kerberos ticket caches are maintained in user space and pointed
at by environment variables.
The Opengroup's DFS did some thing similar to what you wanted to do
as the ticket caches where stored in
/opt/dcelocal/var/security/creds/dcecreds_<PAG>
where <PAG> was the pag number in hex. The DFS kernel code could then ask the
dced (or was it a dfsd) daemon to get additional tickets as needed to access
the servers. In DFS each server had its own principal and key, unlike AFS
where there was one common key for all the servers in the cell. So as the DFS
kernel need to contact a different DFS server, it would need a new ticket.
NFSv4 has the same problem and I think they are trying to use gsspai and store
the tickets in the kernel. (I may be wrong on how they are doing it, but they
have the same problem of the kernel needing to get tickets.)
(2) You also asked, why aklog is not built. I would speculate, it has to do
with whose Kerberos do you build it against? MIT, Heimdal, or a vendor's
provided version? The APS community has supporters for all of these different
Kerberos implementations. Sun and HP both provide thier own Kerberos with
their OSs. Some Linux provide both MIT and Heimdal. Kerberos does not have a
standard API like gssapi where an application like aklog could be built against
the API, and at runtime use the local version on the system. How about a
gssklog ;-)
Now, since most sites using AFS put peoples home file
space in AFS, the session setup getting the token is a good
and currently necessary, thing. :)
It sure is.
Regards,
Earl Shannon
Ken Hornstein wrote:
While probably not the case I can only hope that the exclusion of the
tools
is because they want to do a better job of inter operating with the KDC.
In my opinion that would mean dropping the need for aklog and asetkey.
After all aklog is basically a second authentication.
You are incorrect. Aklog is simply the program that takes your Kerberos
tickets and makes them available to AFS (possibly getting a Kerberos
ticket for AFS, but it doesn't ask for a password). In this sense, it
behaves just like every other Kerberized application. If you arrange for
aklog to be run at login time, it becomes an essential component of
single sign-on (you don't have to use aklog per se, you can use a PAM
module that does aklog-like things).
Why can't the authentication
take place the same way as say, using an IMAP server?. You access the
server,
( cd to /afs ) and get asked for your credentials.
If you can figure out how to make this happen in a portable manner, let
me know.
And asetkey simply puts the principal afs into a keyfile that afs
knows how
to read. Well, make afs read the kerberos key file where it is as it is.
That's not unreasonable. I suspect sometime in the future someone will
do that. But it's worth pointing out that you don't technically need
asetkey; you can use klist to read the raw key data (-K in MIT
Kerberos), and Heimdal already knows how to write a AFS KeyFile. I'm
not saying asetkey won't get added, but there was a finite amount of
time before the 1.4 branch was cut, and I only had the free time to do
aklog.
--Ken
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
