[OpenAFS] Roaming Windows Profiles
Stephen Joyce
stephen@physics.unc.edu
Thu, 6 Feb 2003 16:40:34 -0500 (EST)
Rodney,
I found that I could accomplish the folder redirection without resorting to
(much) black magic. If system:anyuser has l permission on the entire
profile and all of the necessary folders which AD expects to exist DO
exist, folder redirection seems to work in my testing on win2k (perhaps
not on XP; I haven't tested it). I had planned to create these directories
during user account creation.
Regardless, it sounds like your solution has some definite benefits, and
rather than re-invent the wheel, I for one would like as much info about it
as you have time and inclination to provide. Although I'm sure there are
security concerns, the ability to have an "afslogin script" is particularly
interesting...
Cheers,
Stephen
--
Stephen Joyce
Systems Administrator P A N I C
Physics & Astronomy Department Physics & Astronomy
University of North Carolina at Chapel Hill Network Infrastructure
voice: (919) 962-7214 and Computing
fax: (919) 962-0480 http://www.panic.unc.edu
On Thu, 6 Feb 2003, Rodney M Dyer wrote:
> At 05:34 PM 2/5/2003 -0500, you wrote:
> > Pardon my ignorance since I am not an expert in Windows, but how
> >do you setup folder redirection from the local machine back into
> >AFS in the profile?
>
> Dj,
>
> Folder redirection is simple to do "in-theory", but because AFS and
> Kerberos V are in the mix at our site, things get a little more
> complex. We run a active directory server for grouping all of our XP
> machines into a single administrative/security domain. The active
> directory group policy editor allows folder redirection to be setup. This
> worked fine, we just opened up the group policy editor on the AD server and
> changed the neccessary options to enable folder redirection. But after we
> did this, expecting folder redirection to work, it didn't (of course not).
>
> There were a couple of things that were going on at the time that allowed
> us to fix the folder redirection problems as well as others. First, we
> were working out a way to get the system a user token at logon using
> Kerberos V so that the profile could be downloaded out of AFS
> space. Second, even after we had the user's token we found that the system
> had trouble with folder redirection.
>
> Here's what happens when our user's logon...
>
> 1. User presses Ctrl+Alt+Del and logs on using the standard Windows logon
> dialog. We don't use any special GINA replacements since that would
> violate my principle of touching Microsoft's technologies as little as
> possible. I would rather prefer to work "out-of-the-box" with Microsoft stuff.
>
> 2. Since AFS is already installed on the workstation and "logon
> authentication" is enabled, the Windows logon process calls upon the AFS
> authenticator "afslogon.dll" to get the user a token into their ticket
> cache. (standard afs operating condition out-of-the-box) Unfortunately
> this is not done for the system (note user SYSTEM), so the profile can't
> load out of AFS space and folder redirection doesn't work.
>
> How we fixed the problem...
>
> 1. We downloaded the source for OpenAFS and found the C code for
> "afslogon.dll" called appropriately enough "afslogon.c". We modified this
> code so that a command shell could be executed to perform our own
> authentication. This was extremely simple to do. All I did was remark out
> a couple of the traditional routines and replace them with a system call.
>
> 2. Now at logon, the "afslogon.dll" executes a child process that runs a
> command shell script. In that command shell script we can do anything we
> want. In my script I do the following...
>
> 2a. Call kinit to get the system a Kerberos V TGT of the user.
> 2b. Call aklog to get the SYSTEM a user token.
> 2c. Call aklog again with a different option* to create a token
> for the user from the Kerberos TGT.
>
> * Note: We made a small change to the aklog code to allow this
> operation. I'll tell you about it if you want to know.
>
> 2d. Validate system AFS token is good.
> 2e. Get user's AFS/UNIX home directory path.
> 2f. Check for the existance of the users home directory.
> 2g. Check the quota on the home directory.
> 2h. Create a U: drive using "subst" that points to the user's
> home directory.
>
> Note: The "n:" drive points to the top of our AFS filesystem tree
> and is mounted globally by the system at workstation boot by the startup
> script option of group policy. So the "u:" drive points to the user's home
> directory such as...
>
> n:\uncc\usr\a\trng01
> u:\ -> n:\uncc\usr\a\trng01\.
>
> (u stands for unix home)
> (n stands for network drive)
>
> 2i. Check for existance and create if neccessary the following
> directories for folder redirection and profile creation/download...
>
> "u:\xp_profile"
> "u:\pc"
> "u:\pc\win_data"
> "u:\pc\win_data\Desktop"
> "u:\pc\win_data\Application Data"
> "u:\pc\win_data\My Documents"
> "u:\pc\win_data\My Music"
> "u:\pc\win_data\My Pictures"
>
> These directories must already exist in order for folder
> redirection to work correctly so we create them here. We found in early
> testing that the XP machine has trouble creating them in AFS if they don't
> exist. Don't know why since doing it here is just a fix.
>
> 2j. We throw away the token obtained for the system because we no
> longer need it.
> 2k. The command script is completed.
>
> 3. The "afslogon.dll" returns control back to the windows logon process.
> 4. XP downloads the user's profile.
> 5. XP sets up folder redirection.
> 6. XP starts the user's shell.
> 7. The user is logged on with a token that was obtained using Kerb V.
>
> I know this seems rather complex, but using this method has solved almost
> every issue we've encountered. And, because we can change our
> "afslogon.dll" child process script any way we want, we can change things
> at a moments notice without having to modify and recompile any code.
>
> Someday soon I'm going to document all this and put it up on a web
> site... Don't hold your breath.
>
> Rodney
>
> Rodney M. Dyer
> x86 Systems Programmer
> College of Engineering Computing Services
> University of North Carolina at Charlotte
> Email rmdyer@uncc.edu
> Phone (704)687-3518
> Help Desk Line (704)687-3150
> FAX (704)687-2352
> Office 267 Smith Building
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>