Standard Disclaimer: Speaking for myself, not necessarily my employer. Below:
> -----Original Message----- > From: Wyllys Ingersoll [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 12:48 PM > To: David Lawler Christiansen (NT) > Cc: [EMAIL PROTECTED] > Subject: Re: Kerberos on the web > So, which parts of the article are no longer true, are > misleading, or are outright lies? Clarification: Nowhere did I say that the article was a pack of lies. I did say that the article was misleading in its tone. The two paragraphs that indirectly call into question the interoperability of the MS Kerberos package are the ones I mean: "Users have voiced concerns that they were having trouble establishing interoperability between their Unix-based Kerberos implementations and Windows 2000." ...this sentence does not read as "some people are having trouble". It reads as "Lots of people are having trouble, and you will too." I dispute this. "Critics charge that Microsoft's PAC locks users into its version of Kerberos." ...this is the one I'm really interested in. The "Critics" are niether identified nor even quoted directly. This sentence does not read as somebody's concern, but as a direct accusation. > I think one problem is that a Win2K AD server can > interoperate fine with other Kerberos implementations as long > as AD gets to be the > KDC. If you try to configure a network with a non-AD server > as the KDC (use a stock MIT KDC, for example), the Microsoft > system can be forced to use it, but by doing so you can no > longer participate in the domain or get MS privileges from > the tickets generated by the non-MS KDC, effectively making > your expensive Win2K server alot less useful. It's true that you can't get the token information out of the ticket if the KDC cannot generate a PAC (presumeably because it is not an MS KDC). However, this doesn't render your server useless. What it does do is deprive you of the benefits that a Windows Domain grants you, which go far beyond just Kerberos authentication. The server itself is just as configurable and useful as it was before-- you just have to manage it differently. For example, Windows Domains have Group Policy, which enables you to make sweeping changes within your domain in a convenient manner. Those changes can be made without group policy-- it's just not as easy. The unix equivalent is something like YP or Hesiod-- if you don't have them, then you must manage the local account space to match up principals with accounts. Windows is the same way-- the Domain provides the authorization and other services. Whether those services use Open Standards correctly or even at all is beyond the scope of my message. > Not being able > to actually write software to generate the PAC field from a > non-MS server is the root of this problem. You don't NEED the PAC to interop with us. That's by design in RFC1510. The point is, at the protocol level, all clients (us included) work fine without it. Yes, it may make some domain-level features in Windows harder to use, but those features are not part of Kerberos and don't have anything to do with interop (IMHO). > If you were truly > to open up your implementation and share the information with > the Kerberos community in an open manner (i.e. unencumbered > by a license) this problem would quickly disappear. I'm not here to debate anyone on the benefits/pitfalls of our particular business decisions. I'm specifically interested in debunking the myth that our Kerberos doesn't interop with other Kerberoses. > The short answer it, if you want a Kerberized network with a > mixture of Microsoft and non-Microsoft software, you better > let MS be the KDC or else you forefeit alot of the nice MS > features. Its a backhanded way of forcing people to choose > your tools. > > -Wyllys No. We intend for people to "choose our tools" because our tools meet their needs in ways that other tools do not. This may be by implementing features nobody else has, or implementing them better. Providing a better story in their particular environment, or it might even be because of something else not directly related to the product, like better customer service. Even having a unix KDC does not eliminate the features of which you speak. You can use the unix KDC for authentication and add a Windows Domain for authorization only. Then you get the best of both worlds without sacrificing either. Thanks! -Dave
