This is true, but it is unclear how compatible Microsoft's version of
Kerberos will be with the standard. It is evident that some degree of
incompatibility will exist; the exact extent of that incompatibility is
unknown at this writing. What seems to be the case is that with the
proprietary ticket extension created by Micrososft KDCs, a non-Microsoft KDC
won't be able to include any group membership information in the ticket.
This may or may not impact you, depending on how critical Windows group
membership information is to your Windows infrastructure.

This article, written by Ted T'so, gives what I feel is a reasonable summary
of the situation. This originally appeared in the November 1997 NT special
edition of ;login:, and is used here with permission.

From: Ted T'so <tytso@MIT.EDU>

     Microsoft Embraces and Extends Kerberos V5

     There has been a lot of excitement generated by Microsoft's
     announcement that NT 5.0 would use Kerberos. This excitement was
     followed by a lot of controversy when it was announced by
     Microsoft would be adding proprietary extensions to the Kerberos
     V5 protocol. Exactly what and how Microsoft did and tried to do
     has been a subject of some confusion; here's the scoop about what
     really happened.

     NT 5.0 will indeed use Kerberos. However, this protocol has been
     "embraced and extended" by Microsoft, by adding a digitally signed
     Privilege Attribute Certificate (PAC) to the Kerberos ticket. The
     PAC will contain information about the user's 128-bit NT unique
     id, as well as a list of groups to which the user belongs.

     The NT PAC is unfortunately not compatible with the PAC's used by
     the Open Software Foundation's Distributed Computing Environment
     (DCE). It is also somewhat debatable whether the NT PAC is legal
     with respect to RFC-1510, the IETF Kerberos V5 protocol
     specification. The original intent of RFC-1510 prohibited what
     Microsoft was trying to do, but Microsoft found what they claimed
     to be a loophole in RFC-1510 specification.

     Many folks, including Paul Hill and myself at MIT, as well as
     Cliff Neumann at ISI, have tried to work with Microsoft to find a
     more compatible way of doing what they wanted to do. To that end,
     we made changes in the upcoming revision of RFC-1510 to add a
     clean and compatible way of adding extensions such as Microsoft's
     PAC to the Kerberos ticket.

     To Microsoft's credit, they agreed to change NT 5.0 to use a
     cleaner and more compatible way of adding extensions to the
     Kerberos V5 ticket. They also pledged that they would make
     available to us detailed technical information about the NT PAC
     after the beta release of NT 5.0. This pledge was very important
     to MIT and other commercial, educational, and government sites
     which have an extensive deployed base of Kerberos V4 applications
     (for example Transarc's AFS), as we had planned to add the ability
     to generate an NT PAC to the MIT Kerberos V5 implementation, which
     has backwards compatibility for Kerberos V4 applications.

     Unfortunately, at the Microsoft Professional Developers Conference
     (PDC) in September, Microsoft appears to be backing away from this
     commitment. For the first time, Microsoft revealed that they had
     chosen to implement the NT Domain Controller such that the Active
     Directory Server and the Microsoft KDC ran in the same process
     space, and that NT clients could not be configured to split a
     Domain Controller across two machines. Thus, it would not be
     useful for Microsoft to reveal their proprietary extensions to the
     Kerberos protocol.

     However, at the PDC, Microsoft did indicate that they had licensed
     their Domain Controller to a few UNIX vendors. So it may
     eventually be possible to run a Domain Controller on a non-NT
     machine but there is no indication what the license may cost each
     site. It is doubtful, however, whether Kerberos V4 support will be
     included in those products.

     Microsoft should be commended for using a mature industry standard
     such as Kerberos for their authentication protocol. Kerberos has
     had a long review period, and its use has been proven in many
     operational environments. It seems ironic, however, that Microsoft
     would choose to design and deploy their implementation with
     features that are guaranteed to alienate the early adopters of
     Kerberos, the very people that have helped to create and improve
     the technology that Microsoft has chosen to "embrace and extend."

Microsoft has issed a number of technical reports explaining how they have
implemented Kerberos 5 and procedures for interoperating with "vanilla"
Kerberos 5. They include:

   * Windows 2000 Kerberos Authentication
     <http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.asp>

   * Windows 2000 Kerberos Interoperability
     <http://www.microsoft.com/WINDOWS2000/library/howitworks/security/kerbint.asp>

   * Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability
     <http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp>

Unfortunately, none of the above documents can be read on a non-Microsoft
operating system; the FAQ author notes the irony of this situation.