openafs/doc/txt/winnotes/afs-install-notes.txt
Jeffrey Altman 40d2f5f7c0 windows-admin-group-20040823
Update text files for 1.3.71 and describe the new Windows Authorization
Group "AFS Client Admins"

====================
This delta was composed from multiple commits as part of the CVS->Git migration.
The checkin message with each commit was inconsistent.
The following are the additional commit messages.
====================

Add support for "AFS Client Admins" windows authortization group

====================

NTMakefile changes for Admin Group
2004-08-23 16:49:45 +00:00

376 lines
18 KiB
Plaintext

OpenAFS for Windows 1.3.71 Installation Notes
---------------------------------------------
The OpenAFS for Windows product was very poorly maintained throughout the
1.2.x release cycle. While the Unix version was being enhanced and its
quality was improving the Windows version stagnated. The IBM AFS 3.6 product
was not designed for the Windows 2000/XP/2003 operating system nor was it
architected with highly disconnected environments in mind.
The 1.3.x series of releases not only fixes a large number of bugs in the 1.2
series but also attempts to enhance the functionality of the product to better
fit the usage model of today's users. Several items standout.
1. The Kerberos 4 infrastructure on which the 1.2 series is reliant is no
longer secure. Cross-realm Kerberos is very important in the AFS context and
most sites have or are migrating to Kerberos 5 environments. The 1.3 series
integrates with the MIT Kerberos for Windows 2.6.x product to provide Kerberos
5 functionality including the ability to auto-renew credentials and obtain
single sign-on capabilities with the Microsoft Windows Kerberos Logon Service.
As of 1.3.65, the OpenAFS client will directly use Kerberos 5 tickets as tokens if
KFW is installed. The client requires that all of the AFS Servers with which it
communicates support the use of Kerberos 5 tickets as tokens (aka 2b tokens).
This means that all of the AFS servers must be running OpenAFS release 1.2.8 or
higher. Transarc servers do not support Kerberos 5 tickets as tokens.
When using a Microsoft Windows Active Directory as the KDC which issues the
service ticket for the AFS cell there are two things to consider. First, the
Kerberos 5 tickets issued by Active Directory can be quite large when compared
to tickets issued by a traditional KDC due to the incorporation of
authorization data in the PAC. If this is your situation you either must
modify your 1.2.x servers to support tokens larger than a few hundred bytes;
or install the 1.3.64 or higher release on your servers. Second, Windows 2003
Active Directory will issue service tickets utilizing the DES-CBC-MD5 enctype.
OpenAFS releases older than 1.3.64 will not properly support this enctype.
2. The AFS Client Service does not provide robust behavior in an environment
with a plug-n-play network environment. Changes to the number of network
adapters or the assigned IP addresses will cause the service to panic. The
recommended work around for this problem is to install the Microsoft Loopback
Adapter on the machine. When the MLA is installed with a static IP address
the AFS Client Service will bind only to the loopback and not be affected by
changes to state of other network adapters installed on the system.
Starting in the 1.3.65 release the installers provided by OpenAFS.org will
install the Microsoft Loopback Adapter for you with a name of "AFS" and a
pre-assigned IP address in the 10.x.x.x range.
One of the benefits of using the MLA is that the NETBIOS names used for the
AFS Client's SMB server do not have to be published on any adapter other than
the MLA. This means that the names no longer need to be unique. When the MLA
is in use, the NETBIOS name associated with the AFS Client Service is simply
"AFS". When the MLA is not in use the NETBIOS name is "MACHINE-AFS".
When the MLA is installed, UNC paths of the form \\AFS\cellname\path may be used.
3. Traditionally, when the AFS Client Service starts it must be able to
access the "root.afs" volume of the default cell. The "root.afs" volume
contains a set of read-only and read-write mount points to the "root.cell"
volumes of various cells the administrator of the default cell believes
should be accessible. If the "root.afs" volume is
inaccessible when the client service is started, the service will panic.
Since many users now use laptops or otherwise operate in disconnected
environments in which a VPN may be needed to access the cell's servers, it is
often the case that the "root.afs" volume for the default cell is not
reachable and the AFS Client Service will not successfully start.
The OpenAFS Client Service now supports a fake "root.afs" volume which is
dynamically constructed when the service starts. This mode is called
Freelance mode. Freelance mode is turned on by default.
The contents of the
fake "root.afs" volume are constructed dynamically as cells are accessed.
When the fake "root.afs" volume is constructed it will only contain two
mount points: a read-only and read-write mount point used to access the
"root.cell" volume of the default AFS cell. Any attempt to access a
valid cell name will automatically result in a new mount point
being created in the fake "root.afs" volume. If the cellname begins with
a "." the mount point will be read-write; otherwise the mount point will
be read-only. These mount points are preserved in the registry at key:
HKLM\SOFTWARE\OpenAFS\Client\Freelance
Additional mount points may be manually created using the "fs mkmount"
command. Mount points may be removed using the "fs rmmount" command.
fs mkmount \\AFS\all\athena.mit.edu root.cell athena.mit.edu
fs mkmount \\AFS\all\.athena.mit.edu root.cell athena.mit.edu -rw
fs rmmount \\AFS\all\athena.mit.edu
fs rmmount \\AFS\all\.athena.mit.edu
4. The OpenAFS for Windows client will use AFSDB DNS records to
discover cell information when it is not located in the local CellServDB file
(\Program Files\OpenAFS\Client\CellServDB).
5. OpenAFS for Windows 1.3.71 only supports Windows 2000, Windows XP, and
Windows 2003. Windows NT 4.0 and the entire Windows 9x/Me line are no
longer supported. Older releases of OpenAFS are available for download
if those operating systems must be supported. The last version with support
for Win9x is 1.2.2b. The last version with support for Windows NT 4.0 is
1.2.10.
6. OpenAFS for Windows installs a WinLogon Network Provider to provide
Integrated Logon (Single Sign-on) functionality. Integrated Logon can be used
when the Windows username and password match the username and password
associated with the default cell's Kerberos realm. For example, if the
windows username is "jaltman" and the default cell is "athena.mit.edu", then
Integrated Logon can be successfully used if the windows password matches the
password used for the Kerberos principal "jaltman@ATHENA.MIT.EDU".
Integrated Logon is required if you desire the ability to store roaming user
profiles within the AFS file system. OpenAFS does not provide tools for
synchronizing the Windows and Kerberos user accounts and passwords.
If KFW is installed, the Integrated Logon will use Kerberos 5 to obtain
tokens. Otherwise, Kerberos 4 is used.
There is a High Security mode for use with Integrated Logon when multiple
users will share a single machine. There are known problems with this mode.
In particular, if you are using this mode it is crucial that new AFS tokens
not be obtained after the logon session starts except via the AFS Systray tool
as started by the AFS Network Provider. If the AFS Systray tool is stopped
you must log off to obtain new tokens. Do not use external tools such as
"aklog.exe" if High Security mode is turned on. As of 1.3.70, OpenAFS supports
Authenticated SMB connections which removes the need for High Security mode.
DO NOT USE IT!!!!!
What Integrated Logon does not do:
(a) Integrated Logon does not have the ability to obtain Kerberos 5
tickets for use during the Windows Session. At the current time there
is no mechanism by which a Kerberos 5 CCAPI credentials cache can
be constructed during the logon process such that it will exist in
the user's logon session.
(b) Integrated Logon does not have the ability to cache the user's
username and password for the purpose of obtaining tokens if the
Kerberos KDC is inaccessible at logon time.
7. The AFS Systray tool (afscreds.exe) supports several new command line
options:
-A = autoinit
-M = renew drive maps
-N = ip address change detection
-Z = unmap drives
autoinit will result in automated attempts to acquire AFS tokens when
afscreds.exe is started. afscreds.exe will attempt to utilize tickets stored
in the MSLSA credentials cache; any existing CCAPI credentials cache; and
finally display an Obtain Tokens dialog to the user. When used in combination
with ip address change detection, afscreds.exe will attempt to acquire AFS
tokens whenever the IP address list changes and the Kerberos KDC is
accessible.
The renew drive maps option is used to ensure that the user drive maps
constructed via the AFS tools (not NET USE) are re-constructed each time
afscreds.exe is started.
By default afscreds.exe is configured by the OpenAFS.org installers to use -A
-N -M -Q as startup options. Currently, there is no UI to change this selection
after install time although these options may be altered via the registry either
per machine or per user. See AfscredsShortcutParams in registry.txt.
8. Some attempts have been made to restrict the ability
of users to alter the state of the AFS Client
Service. For example, the following fs.exe commands are now restricted to
Administrator:
- checkservers with a non-zero timer value
- setcachesize
- newcell
- sysname with a new sysname list
- exportafs
- setcell
- setserverprefs
- storebehind
- setcrypt
- cscpolicy
- trace
setting the default sysname for a machine should be done via the registry and
not via "fs sysname".
Some of the AFS Client Configuration Control Panel options are also restricted
to use by the "Administrator" account.
9. The AFS Client should support UNC paths everywhere. Power users that make
extensive use of the command line shell, cmd.exe, might want to consider using
JP Software's 4NT command processor. Unlike cmd.exe, 4NT does fully support
UNC paths and can use a UNC path as the default device.
10. The AFS Client ships with its own version of aklog.exe which should be
used in preference to those obtained by third party sources. The OpenAFS
aklog.exe supports Kerberos 5 as well as the ability to auto-generate
pts IDs for user's obtaining tokens to foreign cells.
Usage: aklog [-d] [[-cell | -c] cell [-k krb_realm]]
[[-p | -path] pathname]
[-noprdb] [-force]
[-5 | -4]
-d gives debugging information.
krb_realm is the kerberos realm of a cell.
pathname is the name of a directory to which you wish to authenticate.
-noprdb means don't try to determine AFS ID.
-5 or -4 selects whether to use Kerberos V or Kerberos IV.
(default is Kerberos V)
No commandline arguments means authenticate to the local cell.
11. The AFS Server functionality provided with OpenAFS 1.3.71 might work but
should be considered highly experimental. It has not been thoroughly tested.
Any data which would cause pain if lost should not be stored in an OpenAFS
Server on Windows.
A few notes on the usage of the AFS Client Service if it is going to be
used with the OpenAFS AFS Server:
(a) When the AFS Server is installed Freelance mode must be turned off.
(b) The AFS Server and related tools only support the built in kaserver
(Kerberos IV). If the AFS Server is being used, MIT Kerberos for Windows
should not be used.
12. The OpenAFS for Windows installers now include Symbol information which
should be installed if you are experiencing problems and need to send crash
reports. This is true in both the release and the debug versions of the
installers. The differences between the release and debug versions are
whether or not the binaries were compiled with optimization; whether the
debug symbols are installed by default; and whether additional debug
statements were compiled into the binaries.
13. OpenAFS for Windows does not support files larger than 2GB.
14. There are reported problems running the AFS Client on Hyperthreaded
Pentium 4 machines. A registry entry may be created to specify
that the AFS Client Service should only use a single processor. If you have
a hyperthreaded system and you are experiencing crashes, it is advised that
you create the "MaxCPUs" registry value and set it to "1".
See "registry.txt" for details.
15. Local RPC is used as the default RPC mechanism for setting
tokens. TCP RPC is required to be installed and is used for debugging
and other functions.
16. OpenAFS for Windows automatically open ports in the Windows
Internet Connection Firewall.
17. The OpenAFS for Windows installer by default activates a weak form of
encrypted data transfer between the AFS client and the AFS servers. This
is often referred to as "fcrypt" mode.
18. OpenAFS 1.3.71 adds support for authenticated SMB connections using
either NTLM or GSS SPNEGO (NTLM, Kerberos 5, ...). In previous versions
of OpenAFS the SMB connections were unauthenticated which left open the
door for several security holes which could be used to obtain access to
the use of other user's tokens on shared machines. With the introduction
of authenticated SMB connections the so called High Security mode should
no longer be used.
When GSS SPNEGO results in a Kerberos 5 authentication, the Windows SMB
client will attempt to retrieve service tickets for "cifs/afs@REALM" (if
the loopback adapter is in use) or "cifs/machine-afs@REALM" (if the loopback
adapter is not being used). It is extremely important that this service
principal not exist in the KDC database. If the request for this ticket
fails, a subsequent request for "cifs/HOST$@REALM" will be issued. This
service principal should exist in the KDC database. The key associated
with this service principal must match the key assigned to
"host/machine@REALM". If the local machine is part of a Windows Domain
this will all be taken care of for you. If the local machine is using
a non-MS KDC for authentication, then your KDC administrator will have to
add these service principals to the list of principals to be maintained
for each host.
19. As of 1.3.70, INI files are no longer used for the storage of AFS
configuration data. No longer are there any AFS related files stored in the
%WINDIR% directory. The CellServDB file is no longer called "afsdsbmt.ini"
and it is stored in the OpenAFS\Client directory. The afs_freelance.ini
and afsdsbmt.ini file data has been moved to the registry.
IMPORTANT: while the CellServDB file location and freelance mountpoint
data will be automatically migrated; there is no mechanism for automatic
migration of Submounts, Drive Mappings, Active Maps, and CSCPolicy data.
20. As of 1.3.70, the OpenAFS Client is compatible with Windows XP SP2
and Windows 2003 SP1. The Internet Connection Firewall will be
automatically adjusted to allow the receipt of incoming callback messages
from the AFS file server. In addition, the appropriate Back Connection
entries are added to the registry to allow SMB authentication to be
performed across the loopback connection.
21. As of 1.3.70, the OpenAFS Client Service supports the CIFS Remote
Admin Protocol which provides browsing of server and share information.
This significantly enhances the interoperability of AFS volumes within the
Explorer Shell and Microsoft Office applications.
22. OpenAFS will now automatically forget a user's tokens upon Logoff
unless the user's profile was loaded from an AFS volume. In this situation
there is no mechanism to determine when the profile has been successfully
written back to the network. It is therefore unsafe to release the user's
tokens.
23. Terminal Server installations.
When installing under Terminal Server, you must execute the NSIS installer
(.exe) from within the Add/Remove Programs Control Panel. Failure to do so
will result in AFS not running properly. The AFS Server should not
be installed on a machine with Terminal Server installed.
24. AFS is a Unix native file system. As such the OpenAFS client attempts
to treat the files stored in AFS as they would be on Unix. File and directory
names beginning with a "." are automatically given the Hidden attribute so
they will not normally be displayed.
25. As of 1.3.71, the OpenAFS for Windows client supports a local Windows
authorization group called "AFS Client Admins". This group is used in
place of the "Administrators" group to determine which users are allowed
to modify the AFS Client Service configuration via either afs_config.exe
or fs.exe. During installation this group is created and the current
contents of the Administrators group is copied.
------------------------------------------------------------------------
Reporting Bugs:
Bug reports should be sent to openafs-bugs@openafs.org. Please include as
much information as possible about the issue. If you are reporting a crash,
please install the debugging symbols by re-running the installer. If a dump
file is available for the problem include it along with the AFS Client Trace
file %WINDIR%\TEMP\afsd.log. The AFS Client startup log is
%WINDIR%\TEMP\afsd_init.log. Send the last continuous block of log
information from this file.
------------------------------------------------------------------------
How to Contribute to the Development of OpenAFS for Windows:
Contributions to the development of OpenAFS for Windows are needed.
Contributions may take many forms including cash donations, support contracts,
donated developer time, and even donated tech writer time.
If you wish to be involved in OpenAFS for Windows development please join the
openafs-win32-devel@openafs.org mailing list.
https://lists.openafs.org/mailman/listinfo/openafs-win32-devel
User questions should be sent to the openafs-info@openafs.org mailing list.
https://lists.openafs.org/mailman/listinfo/openafs-info
You must join mailing lists if you wish to post to the list without incurring
a moderation delay.