[6106] in Kerberos
Re: Strange AFS 3.4, CDE, and AIX 4.1 interaction
daemon@ATHENA.MIT.EDU (Chris Liljenstolpe (Swanson))
Thu Nov 2 11:38:21 1995
Date: Thu, 02 Nov 1995 10:23:43 -0600
To: harris@email.unc.edu (Trey Harris), kerberos@MIT.EDU
From: "Chris Liljenstolpe (Swanson)" <chris.liljenstolpe@ssds.com>
Greetings,
Please copy me on your responses.
Regards,
-+Chris
At 01:35 95/11/02 GMT, Trey Harris wrote:
>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
>
>
/ Chris Liljenstolpe (Swanson)
____/ ____/ ___ / ____/ Engineer <chris.liljenstolpe@ssds.com>
____ / ____ / /__/ / ____ / 8400 Normandale Lake Blvd #993
_______/ _______/ _______/ _______/ Bloomington, MN 55473
business driven technology solutions. (612) 921-2392 FAX (612) 921-2395
Key Fingerprint = FE 43 BD A6 3C 13 6C DB 89 B3 E4 A1 BF 6D 2A A9
Um Yah Yah!
