contents of the Administrators group is copied.
+26. Some organizations which have AFS cell names and Kerberos realm names
+which differ by more then just lower and upper case rely on a modification
+to krb524d which maps a Kerberos 5 ticket from realm FOO to a Kerberos 4
+ticket in realm BAR. This allows user@FOO to appear to be user@bar for
+the purposes of accessing the AFS cell. As of OpenAFS 1.2.8, support was
+added to allow the immediate use of Kerberos 5 tickets as AFS (2b) tokens.
+This is the first building block necessary to break away from the
+limitations of Kerberos 4 with AFS. By using Kerberos 5 directly we
+avoid the security holes inherent in Kerberos 4 cross-realm. We also
+gain access to cryptographically stronger algorithms for authentication
+and encryption.
+
+Another reason for using Kerberos 5 directly is because the krb524 service
+runs on a port (4444) which has become increasingly blocked by ISPs. The
+port was used to spread a worm which attacked Microsoft Windows in the
+summer of 2003. When the port is blocked users find that they are unable
+to authenticate.
+
+Replacing the Kerberos 4 ticket with a Kerberos 5 ticket is a win in all
+situations except when the cell name does not match the realm name and
+the principal names placed into the ACLs are not the principal names from
+the Kerberos 5 ticket. To support this transition, OpenAFS for Windows
+in 1.3.72 adds a new registry value to force the use of krb524d. However,
+the availability of this option should only be used by individuals until
+such time as their organizations can provide a more permanent solution.
+
+
+
------------------------------------------------------------------------
Reporting Bugs:
git://git.openafs.org / openafs.git / blobdiff