Chapter 3. Operational Notes

Table of Contents

3.1. Unicode Support
3.1.1. Interoperability with MacOS X
3.2. Requirements for Kerberos v5 Authentication
3.2.1. Active Directory
3.2.2. The krb524 Service is no longer supported
3.2.3. Network Identity Manager Provider
3.2.4. Heimdal 1.5, MIT 4.x, and Weak Encryption Types
3.3. The Former use of the Microsoft Loopback Adapter by the OpenAFS Client Service
3.4. Using Freelance (Dynamic Root) Mode to Improve Mobility
3.5. Locating AFS Volume Database Servers via DNS
3.6. Obtaining AFS Tokens as a Integrated Part of Windows Logon
3.7. AFS Authentication Tool Command Line Options
3.8. The "AFS Client Admins" Authorization Group
3.9. OpenAFS Support for UNC Paths
3.10. aklog.exe
3.11. OpenAFS Servers on Windows are Unsupported
3.11.1. OpenAFS Server Installation
3.11.2. Using the AFS Client Service when the Server is installed
3.12. OpenAFS Debugging Symbols and Checked Builds
3.13. Large File (64-bit) Support
3.14. Encrypted AFS Network Communication
3.15. Authenticated SMB Access to the OpenAFS Client Service
3.16. IBM AFS INI Files Replaced By Windows Registry Keys
3.17. Microsoft Windows Internet Connection Firewall
3.18. Browsing AFS from the Explorer Shell and Office
3.19. Byte Range Locking
3.20. Automatic Discarding of AFS Tokens at Logoff
3.21. Windows Terminal Server installations
3.22. Hidden Dot Files
3.23. Status Cache Limits
3.24. NETBIOS over TCP/IP must be enabled
3.25. OpenAFS binaries are digitally signed
3.26. Maximum Size of the AFSCache File
3.27. Filename Character Sets
3.28. Character Set Issues with Roaming Profiles
3.29. The AFSCache File
3.30. Restricting OpenAFS Client Service Start and Stop
3.31. The @sys Name List
3.32. Symlinks to AFS UNC Paths
3.33. Cache Manager Debugging
3.34. Windows Logon Caching vs. Kerberos Logons
3.35. Initial Server Preferences
3.36. File Timestamps and Daylight Saving Time
3.37. Windows RPC client support must be installed
3.38. Generating Minidumps of the OpenAFS Client Service
3.39. AFS Client Universally Unique Identifiers (UUIDs) vs. System Cloning or Virtual Machine Cloning
3.40. Delayed Write Errors with Microsoft Office Applications
3.41. Global Drives (aka Service Drive Letters) are no longer supported by Microsoft
3.42. 64-bit Microsoft Windows Installations
3.43. Known Issues with Microsoft Windows Vista, Windows 7, Server 2008 [R2], Windows 8 and Server 2012
3.44. AFS Share Name Syntax Provides Direct Access to Volumes
3.45. Differences between Windows and UNIX fs examine
3.46. Literal evaluation of AFS Symlink and MountPoint objects via fs commands
3.47. Out of Quota errors
3.48. Linked Cells
3.49 Registry Alternative to CellServDB File
3.50 Release Notes Converted to Windows HTML Help
3.51. Support for Microsoft RPC Services: WKSSVC and SRVSVC
3.52. Differences between Windows and UNIX fs newcell
3.53. AFS Mount Points and Symlinks are Reparse Points
3.54. AFS Authentication Groups
3.55. Known IFS redirector driver limitations
3.56. Changes for Windows 8 and Server 2012
3.57. The Explorer Shell, Drive Letter Mappings, and Read Only Volumes

3.1. Unicode Support

Starting with the 1.5.50 release of OpenAFS for Windows, each of the AFS Client Service, the AFS Explorer Shell Extension, and the command-line tools are Unicode enabled. No longer is OpenAFS restricted to accessing file system objects whose names can be represented in the locale specific OEM code page. This has significant benefits for end users. Most importantly it permits non-Western languages to now be used for file system object names in AFS from Microsoft Windows operating systems. Now that Unicode names are supported, Roaming User Profiles and Folder Redirection will no longer fail when a user attempts to store an object with a name that cannot be represented in the OEM code page.

Unicode names are stored in AFS using UTF-8 encoding. UTF-8 is supported as a locale on MacOS X, Linux, Solaris, and most other operating systems. This permits non-Western object names to be exchanged between Microsoft Windows and other operating systems. The OpenAFS for Windows client also implements Unicode Normalization as part of the name lookup algorithm. This is necessary because Unicode does not provide a unique representation for each input string. The use of normalization permits a file system object name created on MacOS X to be matched with the same string entered on Microsoft Windows even though the operating system's choice of representation may be different.

It is important to note that AFS file servers are character-set agnostic. All file system object names are stored as octet strings without any character set tagging. If a file system object is created using OEM Code Page 858 and then interpreted as UTF-8 it is likely that the object name will appear to be gibberish. OpenAFS for Windows goes to great lengths to ensure that the object name is converted to a form that will permit the user to rename the object using Unicode. Accessing UTF-8 names on UNIX systems that have the locale set to one of the ISO Latin character sets will result in the UTF-8 strings appearing to be gibberish.

UNIX AFS can not perform Unicode Normalization for string comparisons. Although it is possible to store and read Unicode object names, it is possible that a user may not be able to open an object by typing the name of the object at the keyboard. GUI point and click operations should permit any object to be accessed.

3.1.1. Interoperability with MacOS X

MacOS X uses UTF-8 Normalization Form D (NFD) whereas Microsoft Windows and most other applications use UTF-8 Normalization Form C (NFC). The difference is that in NFD Unicode character sequences containing diacritical marks are decomposed whereas in NFC the Unicode character sequences use combined characters whenever possible. Whereas Microsoft Windows can display and manipulate files stored using NFD, MacOS X Finder does have trouble with filenames that are NFC encoded. All file names stored by the OpenAFS Windows client use NFC.