Future Directions for the AFS Client on Windows Jeffrey Eric Altman jaltman *at* secure-endpoints *dot* com Why am I here at SLAC? z Introduce myself to the community z Describe the state of OpenAFS on Windows today z Describe the issues which must be solved z Offer proposals for future directions z Obtain your feedback AFS Best Practices '2004 2 OpenAFS Windows Futures Who am I and what do I do? z OpenAFS Gatekeeper for Windows • Audit code submissions • Manage Bug Requests • Build releases • Fix things • Plan for the future z MIT Kerberos for Windows maintainer z Project JXTA Board Member AFS Best Practices '2004 3 OpenAFS Windows Futures What else have I done? z The Kermit Project • Cross platform (Unix, OS/2, Windows) z Internet Access Methods • Java based Person to Person collaboration software z Miscellaneous Network Security stuff • OpenSSL, Secure Remote Password, TELNET START_TLS, FTP AUTH TLS, SSH z Internet Engineering Task Force (IETF) AFS Best Practices '2004 4 OpenAFS Windows Futures I have no AFS experience Why am I a Gatekeeper? z Windows development background z Networking experience z Security experience z Reputation from other projects z Volunteer AFS Best Practices '2004 5 OpenAFS Windows Futures How bad things were … z OpenAFS on Windows was under supported z Other than the work added in 1.2.8 there have been close to zero changes since 1.0 z Submitted patches could not be applied as there was no one to audit them z Bugs placed in RT could not be responded to. AFS Best Practices '2004 6 OpenAFS Windows Futures There is a new sheriff in town z All items in RT queue have at least been responded to if not fixed z Outstanding patches have been applied z Code submissions obtained and integrated z Resource leaks plugged z “Stable” OpenAFS 1.3.61 announced March 22 AFS Best Practices '2004 7 OpenAFS Windows Futures 1.2.11 vs. 1.3.61: Which definition of “stable” do we mean? 1. “Stable” meaning that the code does not change very much from release to release providing predictability 2. “Stable” meaning that the code performs reliably without crashing unexpectedly or adversely impacting the performance of the system AFS Best Practices '2004 8 OpenAFS Windows Futures Reasons 1.2.x is Not a Stable Release z Un-initialized variables z Memory leaks due to reference count management errors z Kernel object leaks due to reference count and usage errors z Thread deadlocks due to recursive use of single use lock implementation AFS Best Practices '2004 9 OpenAFS Windows Futures More reasons 1.2.x is Not Stable z Memory allocated in one DLL is de- allocated in another z Operations which require both a pioctl and a RPC to send private data (ktc_GetToken and ktc_SetToken) are not atomic AFS Best Practices '2004 10 OpenAFS Windows Futures Even more reasons … z The number of NetBIOS control blocks used in protocol operations (100) exceeds the number of objects which Windows can wait on simultaneously (64). z SMB messages with the “extended” bit set were not supported preventing file operations from being performed on a subset of files. AFS Best Practices '2004 11 OpenAFS Windows Futures What is new in 1.3.61? z Code Donations z New functionality from: z Improved • Rob Murawski Performance • Joe Beuhler z Improved Reliability • MIT • Morgan Stanley z New Installer • Secure Endpoints z Improved Developer • Sine Nomine experience • Skyrope • others AFS Best Practices '2004 12 OpenAFS Windows Futures New Build System z Supports • Microsoft Visual C++ 6.0; • Visual Studio .NET; and • Visual Studio .NET 2003 (release builds) z Only Windows 2000 and above z Windows 9X did not compile and there is no desire to fix it. AFS Best Practices '2004 13 OpenAFS Windows Futures New NSIS Installer z Rob Murawski implemented a new installer using the Open Source Nullsoft Scriptable Installer Framework 2.0 z Supports new installs, uninstalls and upgrades from previous releases z Designed for interactive installs (not an MSI) AFS Best Practices '2004 14 OpenAFS Windows Futures NSIS Installer: Selecting Components AFS Best Practices '2004 15 OpenAFS Windows Futures NSIS Installer: CellServDB AFS Best Practices '2004 16 OpenAFS Windows Futures NSIS Installer: Client Configuration AFS Best Practices '2004 17 OpenAFS Windows Futures \\afs\cellname\ z UNC paths of the form \\afs\cellname are now supported when using the MS Loopback adapter z The “NetbiosName” registry value can be used to specify alternatives to “afs” z No longer need to use \\afs\all\cellname AFS Best Practices '2004 18 OpenAFS Windows Futures MIT Kerberos for Windows 2.6 Integration z Obtain tokens using Kerberos 5 and krb524d z Imports credentials from both the MSLSA and CCAPI credential caches z Automatically renews tokens and tickets as they approach expiration z Architecture supports obtaining tokens for multiple cells from a single krb5 tgt (no UI) z Not yet supported by Integrated Logon z Can be disabled on a per user basis (no UI) AFS Best Practices '2004 19 OpenAFS Windows Futures Using DNS to resolve Cells (not new just not used) z Cells not specified in the %WINDIR%\afsdcell.ini (aka CellServDB) may be discovered via DNS z Windows DNS Query API now used instead of home grown implementation z No longer a need to configure DNS servers with %WINDIR%\afsdns.ini z Controlled by “UseDNS” registry value AFS Best Practices '2004 20 OpenAFS Windows Futures Freelance mode (not new just not used) z No need for a home cell to provide mount points for other cells z Dynamically mounts cells upon first use z Stores local mount points in %WINDIR%\afs_freelance.ini z “fs mkmount” and “fs rmmount” may be used to configure mount lists z Controlled by “FreelanceClient” registry value z Provides for better disconnected user experience AFS Best Practices '2004 21 OpenAFS Windows Futures Select Lan Adapter by Name z The display name of the LAN Adapters can be used as a means of specifying which LAN adapter should be used by the AFS Client Service. z Simply name the desired LAN Adapter “AFS” z This functionality may be disabled using the “NoFindLanaByName” registry value z This functionality is disable by default by the 1.3.61 NSIS installer. AFS Best Practices '2004 22 OpenAFS Windows Futures Hidden Dot Files z Following Unix tradition, files/directories whose names begin with a period are given the Hidden attribute when the “HideDotFiles” registry value is set AFS Best Practices '2004 23 OpenAFS Windows Futures Power Management Support z Automatic Flushing of Volume data upon receipt of Standby or Suspend Notifications AFS Best Practices '2004 24 OpenAFS Windows Futures Compatibility with Cisco IPSec VPN Client z The maximum size of Rx packets must be kept no larger than 1292 bytes in order to pass through the Cisco IPSec VPN Client z Installer sets the “RxMaxMTU” registry value to 1260 to provide compatibility AFS Best Practices '2004 25 OpenAFS Windows Futures Logging Changes z afsd_init.log and afsd.log moved to the %TEMP% directory (usually %WINDIR%\TEMP for the SYSTEM account) z Stack Trace data logged to afsd_init.log during assertion failure or unhandled exception AFS Best Practices '2004 26 OpenAFS Windows Futures The Beginning of Per User Profile Information z HKLM\Software\OpenAFS\Client key used to set system default values z HKCU\Software\OpenAFS\Client key used to store user configuration data z Currently used for: • Token Expiration Reminders • Use of Kerberos for Windows • Show Tray Icon (afscreds.exe auto start) • afscreds.exe shortcut parameters AFS Best Practices '2004 27 OpenAFS Windows Futures New afscreds.exe functionality z -A = if needed, obtain tokens automatically using available Kerberos credentials or display an obtain token dialog to the user z -M = renew drive mapping z -N = activate IP Address Change monitor. If new address is discovered and no tokens are present query KDC; if found present token dialog to the user z -Z = remove all drive mappings AFS Best Practices '2004 28 OpenAFS Windows Futures Many other changes z Performance optimizations z Additional runtime configuration via the registry z Added instrumentation z Fixed “vos listaddrs” and “fs setserverprefs” z See the release notes for details AFS Best Practices '2004 29 OpenAFS Windows Futures Known Issues: Multi-user support z “Cell” registry value serves two orthogonal purposes • Specifies home cell for the AFS Client Service • Specifies the default cell to use when obtaining tokens z Drive mapping data is stored globally although drive maps are actually maintained by the shell per user z Mount points are global allowing users to alter the environment for others z Token leakage occurs when tokens are obtained via afscreds.exe, aklog.exe, or KfW’s Leash32.exe AFS Best Practices '2004 30 OpenAFS Windows Futures Known Issues: AFS Client Service z AFSD Client Service unable to handle dynamic changes to network configuration when MS Loopback Adapter is not installed z SMB redirector overhead imposes performance restrictions z Large File (> 2GB) support not yet implemented AFS Best Practices '2004 31 OpenAFS Windows Futures Known Issues: Cache Management z Cache is memory based resulting in a loss of cache data upon AFS Client Service shutdown z Each cached file is stored multiple times by the system: • Once in the AFSCache file • Once in the memory mapped to the AFSCache file z Maximum Cache size restricted by resource utilization AFS Best Practices '2004 32 OpenAFS Windows Futures Known Issues: Integrated Logon z Does not yet work with Kerberos for Windows z Needs a better method of storing tokens on a per