Date: Thu, 23 Oct 1997 15:40:40 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
I've been keeping relatively quiet on this subject while we tried
working with Microsoft to come up with a more positive solution.
Unforunately, I regret to say that the results have been less than
The following article will be appearing in an upcoming issue of Usenix's
;login newsletter, and it pretty much sums up the entire story.
Obviously, because NT clients can only use the Kerberos server embedded
inside an NT Domain Controller running on a Windows NT box, this is
going to cause major problems for anyone who has already deployed a
Kerberos infrastructure in their site --- this includes folks using OSF
DCE, Transarc AFS, not just those folks using either the MIT Kerberos
implementation, or one of the commercial Kerberos products from
Cybersafe, OpenVision, Cygnus, etc.
We're still investigating what we might be able to do to salvage this
situation, but most of the solutions that we've looked at aren't pretty
one way or another.
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
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."