Microsoft Windows Active Directory can be used as a Kerberos v5 KDC in conjunction with OpenAFS. There are two things to consider when using an Active Directory as the Kerberos realm that issues the AFS service ticket.  First, the Kerberos v5 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 (the Microsoft PAC).  If the issued tickets are larger than 344 bytes, the OpenAFS 1.2 servers will be unable to process them and will issue a RXKADBADTICKET error. OpenAFS 1.4 (and beyond) servers can support the largest tickets that Active Directory can issue.  Second, the Kerberos v5 tickets issued by Windows 2003 Active Directory are encrypted with the DES-CBC-MD5 encryption type (enctype).  OpenAFS 1.2 servers only support the DES-CBC-CRC enctype. As a result, OpenAFS 1.2 servers cannot process the resulting Kerberos v5 tokens. Windows 2000 Active Directory issues tickets with the DES-CBC-CRC enctype.

Microsoft has documented in Knowledge Base article 832572 a new NO_AUTH_REQUIRED flag that can be set on the account mapped to the AFS service principal. When this flag is set, the PAC authorization data will not be included in the ticket. Setting this flag is recommended for all accounts that are associated with non-Windows services and that do not understand the authorization data stored in the PAC. This flag cannot be used if AFS service tickets are obtained via cross-realm using an Active Directory user principal.

Note that an Active Directory computer object cannot be used for the afs service principal.

Some organizations have AFS cell names and Kerberos realm names which differ by more then just lower and upper case and rely on a modification to krb524d which maps a Kerberos v5 ticket from realm FOO to a Kerberos v4 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 v5 tickets as AFS (2b) tokens. This is the first building block necessary to break away from the limitations of Kerberos v4 with AFS.  By using Kerberos v5 directly we avoid the security holes inherent in Kerberos v4 cross-realm.  We also gain access to cryptographically stronger algorithms for authentication and encryption.

Another reason for using Kerberos v5 directly is because the krb524 service runs on a port (4444/udp) which has increasingly been 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 v4 ticket with a Kerberos v5 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 ACL’s are not the principal names from the Kerberos v5 ticket.  To support this transition, OpenAFS for Windows 1.4 adds a new registry value, Use524, 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.

Note that the OpenAFS 1.4.x servers permit the use of a secondary realm name that can be treated as equivalent to the cell name for authentication.

As of release 1.5.9, OpenAFS for Windows includes a Network Identity Manager Provider for obtaining AFS tokens. This plug-in is a contribution from Secure Endpoints Inc. Network Identity Manager is a multiple identity credential management tool that ships with MIT Kerberos for Windows version 3.0 and above. The OpenAFS plug-in requires MIT Kerberos for Windows version 3.1 or above. Version 3.2.2 is recommended for the best user experience.

The Network Identity Manager replaces the former KFW ticket manager, Leash", and when combined with the OpenAFS Provider, it is intended to be used as a replacement for the AFS System Tray Tool (afscreds.exe). Unlike both Leash and the AFS System Tray Tool, Network Identity Manager with the OpenAFS Provider can easily manage AFS tokens for multiple cells from one or more Kerberos v5 identities.

The AFS configuration panel for each Kerberos v5 identity is used to configure which cells credentials should be obtained for and how they should be obtained. If the cell to realm mapping cannot be automatically determined, it can be explicitly specified. If the cell does not support Kerberos v5 tickets as tokens, then a krb524 service can be configured.

The OpenAFS Provider configuration panel can be used to check the status of the AFS Client Service and its version. An optional checkbox is provided that will prevent the AFS System Tray Tool from being started by Windows after login. A shortcut to the OpenAFS Control Panel is also provided.