Trey,
I saw your note about AFS interactions when login in on the
Kerberos list. (Attached at end).
I too am interested in this area, but for a different reason. We
are using DCE and Kerberos 5 beta 5. DCE for the security server,
and DFS; Kerberos for the clients, such as rlogin, telnet, and a
modified ftp. We are able to forward Kerberos tickets, and can
convert them to a DCE context. We also have a modified aklog
which can get a K5 ticket from the DCE security server for a AFS
cell, or for the AFS/DFS translator, and convert this into a AFS
token. Right now these operations are done by independent
programs, but need to integrated in to login.
The problem I am having know, is getting the PAGs straight. Both
DFS and AFS use PAGs, and they both use the groups trick to store
the PAG information. It looks like on different systems, where the
vendor may have modified the DFS code (HP) for example, that the
two types of PAGs may be independent, where as on the Solaris
system were Transarc did DFS, AFS, and the DCE port to Solaris,
and they appear to work together.
The biggest problem is that you can not have a executable with
both the Kerberos libraries and DCE libraries linked together.
They have conflicting names. DCE is based on an earlier Kerberos
5. So I need seperate process to set the PAG, convert the K5 to a DCE
context and get the AFS tokens.
So if you find out any more about the PAGs, and how they
interoperate, please let me know.
Thanks
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: [EMAIL PROTECTED]
----- ------ ----- ----- ----- ----- ----- ----- ----- -----
To: [EMAIL PROTECTED]
Date: 2 Nov 1995 01:35:32 GMT
From: [EMAIL PROTECTED] (Trey Harris)
Message-Id: <479794$[EMAIL PROTECTED]>
Organization: University of North Carolina, Chapel Hill
Sender: [EMAIL PROTECTED]
Subject: Strange AFS 3.4, CDE, and AIX 4.1 interaction
AFS version 3.4 offers a rather nifty feature for AIX 4.1 users wishing to
do authentication via kaserver or Kerberos. Plug in authentication
modules, called afs_dynamic_auth or afs_dynamic_kerbauth, can be placed in
/etc/security/login.cfg and /etc/security/user so that, on a system-wide
or user-by-user basis, the tsm program will authenticate the user to AFS
rather than to /etc/passwd. (An /etc/passwd entry must exist for the user
with the same name as the Kerberos principal, but the password itself in
/etc/passwd or /etc/security/passwd is disregarded.)
Since tsm controls the authentication of login, su, rlogind, and virtually
every other terminal-based login method, this is very convenient for AFS
users, letting them authenticate to AFS without learning a new command
set. afs_dynamic_auth authenticates to the kaserver (or
afs_dynamic_kerbauth authenticates to Kerberos), creates a PAG, and gets
an AFS token for that PAG.
In the standard AFS-ized terminal login, login is spawned by getty or
telnetd (or whatever) which sets a PAG with a token which is inherited by
the shell the user gets. Everything works great.
The point of this post is to ask about a Common Desktop Environment login.
In CDE, dtlogin spawns dtgreet, which verifies your credentials. I've
verified that on HP-UX and Solaris machines running as AFS clients,
dtgreet will not check your password with the kaserver. If your password
is not stored locally or via NIS, dtgreet will give you a login incorrect
message.
On AIX boxes running AFS, however, dtgreet gets the password from the
kaserver; I've starred out my password in /etc/security/passwd and I can
still login. I therefore hypothesize that dtgreet must be running the
tsm code for authentication, which has been AFS-ized by the plug-ins.
Following this logic, dtgreet should be creating a PAG and getting a
token, and then it will spawn a dtsession, which spawns all your clients
and shell windows. The shells and all the other clients should be
members of the PAG and be properly authenticated.
This isn't what I'm seeing, however, and what I'm seeing is a little too
odd for me to get a handle on. As I said, the CDE login is being
authenticated via AFS. However, no tokens are present in the windows I
open (via Front Panel or Application Manager) and if I klog, a UID-based
(rather than PAG-based) token is issued.
Just based on this, I would assume that either the CDE login sequence is
just authenticating to the kaserver and never getting a token, or getting
a PAG and/or token and throwing it away.
But it gets stranger: if I klog -setpag, creating a PAG and a token, then
I can use that token in all windows governed by that dtsession. This
makes me uncomfortable, because as I understood it klog -setpag should
create a PAG for this and all child processes like pagsh does, but
shouldn't be affecting parent or sibling processes.
What really makes me uncomfortable, however, is that if I log out of CDE,
log in as another user, and then back in as myself, I still have the token
from the earlier klog -setpag! (The intermediate CDE user does *not* have
access to my token, thankfully.) I've verified that in between sessions
I have no running processes.
I'm totally befuddled as to what is going on, and wonder if anyone can
take a guess. Could CDE be seeing the PAG and/or the token as something
it needs to save the state of, like the position of windows? Can dtgreet
or the plug-ins be modified so that I can login with a PAG and token?
(If that can be done, I have no problem with putting unlog into my
sessionexit file.)
Thanks...my news server is slow (isn't everybody's?) so please copy me
email if you followup.
--
Trey Harris http://sunsite.unc.edu/harris/
System Administrator, Project Isis, Office of Information Technology
The University of North Carolina at Chapel Hill
