No more feature changes expected before 1.3.70; future release plans

As of tonight's builds, 2004-07-15, I am not expecting to commit any new
functional changes to OpenAFS for Windows.   The one exception will
be the additional of a new help engine if someone volunteers to update
the online help files.

Please test these releases extensively in your environments and make plans
to distribute the 1.3.70 release to your end users.  After the release 
of 1.3.70
I anticipate a hiatus of additional releases for about two months.  
After that
I will resume issuing releases about once a month.  However, from this 
point
forward the changes to the OpenAFS client will be more dramatic.  In 
particular,
the set of changes I would like to ship in December or January will include
a completely new user interface.  As such I expect that the September 
release
will not be considered a "stable" release.   Unless there is a good 
reason to
delay the release I am going to target the release of 1.3.70 for Tuesday
July 27th.   As such please attempt to find testing time sometime within the
next several days so as to leave time for bug fixes to be applied as needed.

As mentioned earlier in the week, the original intention was to call this
release 1.4 as the 1.4 version number is the value reserved for the next 
stable
release on Unix.  Unfortunately the state of the Unix distribution is 
such that
it is not ready to cut a new stable branch.  As such we in the Windows world
will continue to label releases as either "stable" or "development" 
independent
of the version number.

If someone has time it would be nice to be able to obtain some performance
comparisons between 1.2.10 and the latest daily builds.  Both with and 
without
crypt mode on.  I expect the new builds will compare quite favorably.

As always I encourage all organizations that wish to contribute to 
OpenAFS for
Windows development to contact me.  Financial contributions as well as 
in kind
assistance are seriously appreciated.   There is much to do and it is 
only going to
be accomplished with the support of the organizations which rely on this 
software
within their organizations.

Thanks.  I hope the efforts of myself and Asanka are well received.

Jeffrey Altman


Daily builds can be obtained from:

   /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/
   \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS\
   http://web.mit.edu/~jaltman/Public/OpenAFS/

Here is the complete list of changes since the 1.3.65 release:

   * The network provider can be configured to have different behavior
     depending on the domain that the user logs into.  These settings are
     only relevant when using integrated login.  A domain refers to an
     Active Directory (AD) domain, a trusted Kerberos (non-AD) realm or the
     local machine (i.e. local account logins).  The domain name that is
     used for selecting the domain would be the domain that is passed into
     the NPLogonNotify function of the network provider. (see registry.txt
     for details)

   * Added a new registry value [HKCU\SOFTWARE\OpenAFS\Client]
     "Authentication Cell" which may be used to specify a default
     authentication cell for afscreds.exe which is different from
     the default cell for the AFS Client Service daemon.

   * Added a Logoff WinLogon Event Notification function to afslogon.dll.
     afslogon.dll moved to %WINDIR%\System32\.
     New registry entries added to register the dll for Winlogon events.

     The logoff event will now force a call to ktc_ForgetAllTokens()
     using the context of the user being logged off.

     Need to double check that this code does not prevent profile data
     from being written back to an afs volume

   * Windows XP SP2 Internet Connection Firewall interoperability
     has been added.

   * The %WINDIR%\afsdsbmt.ini contains four sections:
        Submounts, Drive Mappings, Active Maps and CSC Policies.
     The Submounts and CSC policies are now stored in the registry under
        [HKLM\SOFTWARE\OpenAFS\Client\Submounts]
        [HKLM\SOFTWARE\OpenAFS\Client\CSCPolicy]
     The Drive Mappings and Active Maps are stored in the registry under
        [HKCU\SOFTWARE\OpenAFS\Client\Mappings]
        [HKCU\SOFTWARE\OpenAFS\Client\Active Maps]

     There is no automatic migration of this data as it would be impossible
     to consistently migrate data to user profiles which may not be active
     when the machine is updated.

   * The %WINDIR%\afs_freelance.ini contains lists of mountpoints for the
     fake root.afs volume.  For the same reasons as for the cellservdb file,
     this information should not be in %WINDIR%.  This information is now
     kept under the registry key
        [HKLM\SOFTWARE\OpenAFS\Client\Freelance]

     The data from the afs_freelance.ini file will be automatically
     migrated to the registry on first execution of afsd_service.exe

   * Keeping the CellServDB file in the location %WINDIR%\afsdcell.ini is
     troublesome for several reasons.  One, it is confusing for those who
     expect the file to be named "CellServDB" instead of "afsdcell.ini".
     Two, this file is not a Windows Profile formatted file.  Three,
     applications should not be reading or writing to %WINDIR%.  It causes
     problems for Windows Terminal Server.

     The new location of CellServDB will be the OpenAFS Client install
     directory which is by default C:\Program Files\OpenAFS\Client and can
     be determined by querying the registry for
     [HKLM\SOFTWARE\TransarcCorporation\AFS Client\CurrentVersion]PathName

     The existing afsdcell.ini will be migrated by the NSIS installer.
     The Wix installer must still be updated to do the same.

   * Change NSIS installer to use DNS by default; to remove Integrated Logon
     High Security mode; and to add Terminal Services compatibility registry
     entries to allow the OpenAFS tools to find the afsdcell.ini and other
     configuration files in %WINDIR%.
 
   * Add support for authenticated SMB connections.   This will remove
     the need for high security mode in most situations.  Both NTLM
     and Extended Security (GSS SPNEGO) modes are supported.  Effectively,
     only NTLM can be used even though Kerberos is now supported.  The
     reason is that it is not possible to construct a service principal
     which is unique to each individual machine.

     SMB Extended Auth does not work on XP SP2 unless one of two registry
     modifications are made:

     (1) To disable the check for matching host names on loopback 
connections
        set this key.  This does not require a reboot:

        [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
            "DisableLoopbackCheck"=dword:00000001

     (2) To add the AFS SMB/CIFS service name to an approved list.  This
        does require a reboot:

        [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
            "BackConnectionHostNames"=multi-sz "AFS" "MACHINE-AFS"

     afsd_service.exe will automatically add the current Netbios Name
     to the BackConnectionHostNames list and then temporarily disable
     the loopback check for one cycle of startup/shutdown of the service.
     We assume most folks do not start/stop without a reboot so this
     will be adequate in most cases.

   * Fix security hole in afslogon.dll which allowed passwords to be
     sent in clear text to the KDC in a misformed principal name.

   * Fix cm_GetCell() to properly handle expired dns entries
     without crashing

   * If Freelance mode is active and the afs_freelance.ini
     file does not exist, do not create an empty file.
     Instead create a file containing ro and rw mountpoints
     to the default cell using the standard conventions.

   * Modify the Freelance support to handle the ability
     to create rw mount points in the fake root.afs volume.

   * Changed the RPC mechanism used for token setting from
     named pipes to local.  Use of named pipes can be restored
     by setting the environment variable AFS_RPC_PROTSEQ to
     "ncacn_np".

     Named pipes were required when a Windows 9x system was
     using a NT system in gateway mode which is incompatible
     with our use of local loopback adapters.

   * In afscreds.exe, if a username of the form user@REALM is
     specified and no password is specified, do not perform a
     kinit operation.  Only perform the aklog functionality.

   * Add a new registry value which allows the number of processors
     on which afsd_service.exe executes to be restricted.  Valid
     values are 1..numOfProcessors

       HKLM\SYSTEM\CurrentControlSet\Services\TransarcAfsDaemon\Parameters
          (DWORD) MaxCPUs