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: [EMAIL PROTECTED]
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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
