Description of some Windows Patches based from 1.2.2 1. Windows NT/2000 Fixes Auto LANA Number can be disabled or enabled through the AFS Client Configuration dialog. The user no longer needs to manually change the registry entries. 2. Win9x Fixes Patch install script to place the AFS Control Panel icon on the desktop and program menu. 3. Build changes for Windows Building 'media' no longer builds the whole project. 4. Security enhancement for AFS client on multi-user Windows 2000 machines Enclosed is a description on how the current OpenAFS obtains authentication tokens through its use of SMB messages that communicate to the OpenAFS cache manager (e.g., for Windows NT). (1) The OpenAFS cache manager starts and registers itself as an SMB server with the name \\-afs. (2) The Windows SMB client sets up an SMB session with the AFS cache manager by requesting an SMB Session setup. When the cache manager receives a Session Setup request, it supplies a UID for a particular session and user name. The Windows SMB client will use this UID in sending all future requests for the same user. (3) When an AFS logon is done (through klog or the AFS authentication panel), an AFS token is passed to the cache manager by using a pioctl call; this call is implemented as an SMB write request to a special filename recognized by the cache manager. The SMB write request is sent within an established SMB session. The new AFS token is associated with the UID of the user performing the pioctl request. The above scheme is sufficient for Windows NT because it only uses a single SMB session while the user is logged on. However, it is broken on Windows 2000 because Win2k ocasionally starts new sessions with established connections. This essentially invalidates the UID's established within the previous session. When the cache manager receives a new Session Setup request with the same user name, it will assign a new UID. Since the tokens are still associated with the old UID, however, the tokens will appear to be "lost." The current Open AFS approach (in release 1.1.1a) to this problem is to map pairs to AFS tokens. When a new Session Setup request is received, the tuple in the SMB message is used to find the associated AFS tokens. A new UID is assigned, which is also associated with the tuple so that future SMB requests using this UID will be able to find the tokens. This approach worked fine for single user machines; however, for multi-user machines, a user can break this security simply by choosing to connect to an AFS share using a different user name. Since the cache manager does not perform authentication using the SMB user name and does not ask the SMB client for a password, a user can pass in any desired username when connecting to AFS shares and use whatever tokens are associated with that username. Problem 1: User-A connects to an SMB share as User-B and that SMB share already has a token associated with User-B. User-B's tokens will now be usable by User-A. Problem 2: User-B logs off without removing their tokens. User-A logs on and connects to an SMB share as User-B. User-B's tokens will now be usable by User-A. Description of a fix for the above security problems: The fix is based on a scheme involving the use of secret SMB user names randomly generated by the AFS client at the beginning of a login session. The cache manager is configured to map AFS tokens to tuples. Since there is no way for a user to find out the secret user names that are generated for other users, it should not be possible to gain access to other users' tokens. Here is how it works: At the time of Windows logon, the AFS client creates a random name for the user and connects each AFS share (without assigning drive letters) using this random name. After the connection is established, the SMB client will automatically use the same secret SMB user name whenever the user accesses an AFS share. When the user maps their own drive letters to these shares, the new drive mapping will inherit the secret SMB user name from the established connection. There is a registry entry that is used to provide options to turn on/off the generation of secret SMB user names: \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider LogonOptions= {Hex 0x0001 - Integrated Logon, Hex 0x0002 - Random SMB User Name Generation} The following registry entry is being set by the installation script. The value is used by Windows credential manager to call up the "secret SMB user names" application at Windows Logon time. \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaemon\NetworkProvider LogonScript=........ Below are a few recommendations and information related to this security upgrade: (1) Do not delete connections to the AFS shares made by the AFS client. These connections do not have a drive letter assigned. In the NET USE output list the connections look like the following: Status Local Remote Network ------------------------------------------------------------------ OK \\computerName-afs\share Microsoft... Deleting these connections to AFS shares would render the current AFS tokens unusable. In this situation you would need to log off Windows and log back in or restart the AFS client. Otherwise, the SMB client will be using your Windows logon name, instead of a secure name, to reconnect to the cache manager. This would be a security risk on multi-user machines. (2) When a new AFS share is added through the AFS client GUI, a new SMB connection to the cache manager is automatically made with the same secure user name that is in use. (3) The SMB connections used by the AFS client to set the secure user names do not map to any drive letters; however, they do show up when a NET USE command is issued. (4) If you use the RUNAS command with an alternate user name, the DOS process will run as an alternate user. Also, if you klog from this window the tokens obtained will be associated with the alternate user name. These tokens will not be protected with a secret SMB user name.