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 UNIX KDCs due to the inclusion of Windows specific 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. Windows Server 2008 R2 Active Directory domain by default disables use of DES-CBC-MD5 and it must be enabled.

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.

Before there was native support for Kerberos v5 derived AFS tokens, the krb524 service was used to convert a Kerberos v5 service ticket into a Kerberos v4 service ticket that could in turn be used to construct an AFS authentication token.  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. Unfortunately, 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 that 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.

To support this mode of operation OpenAFS for Windows 1.4 supports a registry value, Use524, that forces the use of krb524d within the AFS Authentication Tool and integrated logon.  This option should only be used by individuals until such time as their organizations can transition away from the krb524 service.

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. This functionality can be used to avoid the need for the krb524 service if and only if both realms are managed by the same administrative entity.

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 can be used as a replacement for the AFS Authentication Tool (afscreds.exe). Unlike both Leash and the AFS Authentication Tool, Network Identity Manager with the OpenAFS Provider can easily acquire and renew 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 Authentication Tool from being started by Windows after login. A shortcut to the OpenAFS Control Panel is also provided.

As of OpenAFS 1.5.66, the Network Identity Manager OpenAFS Provider displays the same AFS Lock notification icon generated by the AFS Authentication Tool. The AFS Lock can be used to determine if: