[OpenAFS-devel] Windows 2000 Token authentication problems

[Lantzer, Ryan]

I believe that I have discovered a bug in OpenAFS that I believe was
introduced by the Windows Token mapping that made it into OpenAFS 1.0.4a.
The problem I've found seems to also exist in OpenAFS 1.1.1a.

At my site, there are a couple of instances where we would like to access
files from AFS in NT/2000/XP while no one is logged in. In one instance, we
have a customized Gina that pulls a "message of the day" from a file on AFS
and displays it in the login dialog. In another instance, we would like to
be able to use a GPO out in ADS to run system startup/shutdown scripts which
reside in AFS. In both of these cases, NT will be attempting to access files
in the system context, without a user logged in.

When I have OpenAFS 1.0.4a or OpenAFS 1.1.1a installed while I am trying to
perform either of these tasks, the AFS Client service dies right around the
time that the relevent files are being accessed from AFS. Instead of
quitting and sending (hopefully) usefull messages to the Event Log, the Dr.
Watson catches the fault with the following message:

The application, afsd_service.exe, generated an application error.
The error occurred on 09/06/2001 @ 17:15:10.768.
The exception generated was C0000005 at address 61702A8E (lock_ObtainMutex).

Since the OpenAFS client seems to behave pretty well while accessing files
in a logged-in user's context, I think that maybe the updates to handle
Windows 2000 token authentication don't properly handle the case where a
user isn't logged in.

Ryan Lantzer



[OpenAFS-devel] W2000 Token authentication problems 
James Peterson jimpeter@us.ibm.com 
Wed, 6 Jun 2001 15:54:03 -0700 

W2000 Patches in Progress.

We will enum through the lana list and add netbios name to each lana (as
Microsoft recommends).  It will no longer be necessary to enter the correct
Lana number in the Advanced Tab.

Fix integrated log on.  Issue is that during logon klog is done in OS
context and therefore any SMB communication (pioctle calls) doesn't have a
user name or password associated with it.

Token authentication is really about binding the correct token list to the
correct user/machine/LSN.  It seems that Windows 2000 can create multiple
sessions per user (in addition to the multiple user id's per session).
This causes it to loose tokens when new sessions are created. The creation
of multiple sessions seems to happen frequently on W2K terminal server and
occasionally on W2K professional.  This is particular critical if DOS
windows are used.

The patch we have decided to try is to create a global user list (instead
of a user list per LSN, logical Session Number) .   This would make the
assignment of tokens by userName/machineName rather than by LSN.   If this
patch works then we can add security by doing a one way hash of the
userName/machineName.

Since blank user name is also used frequently, we would reserve userID 0
for blank user names and it would never have a token list associated with
it.

I expect to finish early next week.

James Peterson
"Integrity is the base of excellence."