[OpenAFS] Windows Logon Scripts

[Rodney M Dyer]

At 01:45 PM 12/6/2005, Mike Bydalek wrote:
>One of the last obstacles I have to rolling out OpenAFS company wide is 
>that of Windows.  So far, I have everything working beautifully with 
>single sign-ons with a MIT Kerberos realm.  The final part of my Windows 
>setup is that of getting the data off the client machines and onto the AFS 
>server.
>
>One of the caveats to using the Kerberos logins is that you need a local 
>account, which contains a local profile.  What I did was map all my users 
>to this account.  What I need to do is have it redirect folders to the 
>appropriate /afs directory, or (ideally) use roaming profiles.  I've come 
>across a really interesting page regarding this at 
>http://www.coe.uncc.edu/~rmdyer/krblogon.htm.  The problem is that this 
>just seems overkill for my setup.
>
>All I want to do is just have one additional drive map to 
>/afs/.../home/%USERNAME% when a user logs in, and redirect the desktop and 
>"My Documents" (Start with the basics).
>
>Does anyone know of a good way to do basic things like this when logging 
>into Windows?  I don't see a way to call a login script via. the OpenAFS 
>1.4.1-rc2 client that I'm testing.

The logon script you referenced (krblogon.cmd) is now several years old, 
outdated, patched, refactored, wasn't made for anyone elses environment, 
and you are correct, it is "overkill" for most organizations.  The script 
was developed for our network environment only, and makes several assumptions.

Our Mosaic Windows network environment assumes the following characteristics:

1.  The Windows clients (Win2k,XP) are members of a Windows AD domain.
2.  The user accounts are maintained in AD and our MIT realm.
3.  There are no local accounts on the clients (or very few).
4.  The AD domain is in a trust relationship with a third party kerberos 
realm (our MIT KDC REALM).
5.  All the user accounts on the AD domain have a domain to realm mapping.
6.  The user account passwords on the AD domain are random characters which 
the users don't know.
7.  The AD domain users logon to the Windows clients without administrator 
or power user access.
8.  The user account home directories are in AFS, as well as the roaming 
profiles, and directories for folder redirection.
9.  If a roaming profile doesn't download from AFS, the the user isn't 
allowed to logon.  Something must be wrong that needs to be fixed.
10.  Most of the applications also run out of AFS file space, however 
because of performance or registration reasons, many are installed locally, 
eg. MS Office.

We have had very few problems with users home directories in AFS.  Roaming 
profiles, and folder redirection from AFS is a big bonus.  We have some 
shared space in AFS between departmental workers and have had little 
problems.  Because AFS hasn't had full byte range locking and sharing we 
created a small CIFS shared space off of our AD servers where we store 
applications that need it, eg.  msaccess.exe, etc.  The CIFS space is 
mounted along with all drives needed for the user when they logon.

For historical reasons, we run two different logon scripts when the user 
logs on.  The first logon script runs as user SYSTEM and has an 
authentication token for the user.  This allows us to do administrative 
things in the user account before the users profile downloads.  We can also 
stop the logon process if something goes wrong here, if the user is out of 
quota, or warn them if their quota is low for example.  This first logon 
script is executed by a "hacked" afs logon network provider 
(afslogon.dll).  Because of the method used with the first logon script, we 
cannot use it under a Windows Terminal Server environment, but that isn't a 
problem so far in our network.  The second logon script runs simply under 
the users account.  The second script mounts needed drives and performs 
other miscellaneous items.

Rodney

Rodney M. Dyer
Windows Systems Programmer
Mosaic Computing Group
William States Lee College of Engineering
University of North Carolina at Charlotte
Email: rmdyer@uncc.edu
Web: http://www.coe.uncc.edu/~rmdyer
Phone: (704)687-3518
Help Desk Line: (704)687-3150
FAX: (704)687-2352
Office:  CARC Building, Room 232



>Thank you,
>Mike
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info