[OpenAFS] Roaming Windows Profiles

[Rodney M Dyer]

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