So far as I know, the interop issues between MS krb5 and most others revolve around:
- GSS-API / SPNEGO issues (minor - specs published) - GSS-API extension to HTTP 1.1 (minor - specs published) - GSS-TSIG DNS extension (needed for kerberized DNS which is needed for secure DNS updates in an MS environment - the BIND folk have yet to attempt to implement this, IIRC) (specs published) - the killer: you get no domain users/groups and certain other features in a win2k/winxp environment if your KDCs are not MS (specs NOT published unencumbered). MS seems to consider all Unix accounts to be the moral equivalent of Windows local accounts. But Unix accounts, though they are local in that the POSIX UID/GID namespace is not flat and therefore Unix accounts can't be like Windows domain accounts, are not usually truly local because most folk have NIS/NIS+/LDAP/etc.. domains which they use to distribute /etc/passwd|/etc/group information. This is really the crux of the problem. The MS approach here is to stuff user profile information into Kerberos tickets such that win2k/winxp services need not lookup said user profile information in the domain. When a win2k/winxp service is presented with an AP_REQ with a ticket that lacks said user profile info the service looks up the information in the _LOCAL_ SAM database only - if it searched the domain corresponding to the client's realm then this interop problem would vanish, but, you see, by default (IIRC) services do not have lookup priviledges in ActiveDirectory's LDAP, so why should they bother with domain lookups? (still, they could try the lookups, you'd think). Cheers, Nico On Thu, Jan 17, 2002 at 04:24:30PM -0500, Zafar Baig wrote: > Backgrounder: I am a technical engineering person who has worked on the MIT > krb5 standard on various win32, unix and linux platforms for several years > now. Most of these are through very large scale mission criticial security > server deployments with OSF/opengroup DCE (fyi...DCE has been going > hand-in-hand with krb5 for a really long time now). A 100% interoperability > is a major concern for scalable systems otherwise it becomes a "my way or > the highway" situation. I spend little time developing krb5 apps but I work > pretty deep into the system level code. > > I am looking forward to knowing the technical answers for the speculative or > misleading statements (or "lies") from that article. I won't look at > magazines or .Net's Passport (krb5) reviews for this analysis. Let us truely > analyze the system without bias and see how cool it may or may not be. > > First....What is the latest situation with Krb5 on win2k in terms of > interoperability overhead (especially when considering the proprietary PAC > stuff)? I know that MS has been pushing for it's "Federated" Kerberos > through (project liberty) but what is the latest situation on licensing and > open source? How many auth requests can a krb5 Win2k server take and what > will be the % uptime? The media is only a tool to spread the word/hype > around. I will look at the MS-krb5 code myself if I can get it. How/when can > I get this? > > Your answers to these question will pretty assert the big picture. > > Z > > -----Original Message----- > From: David Lawler Christiansen (NT) [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 3:17 PM > To: Zafar Baig; hot ice; [EMAIL PROTECTED] > Subject: RE: Kerberos on the web > > > No offense, but this article is old news, speculative and misleading in > places. It has nothing to do with MS's use of Kerberos in Passport (which > is what Ice is asking, I think), and only questions whether our Kerberos > implementation will interoperate with any other implementation. The simple > question I must ask in this case is, "have you TRIED it?" > > My experience is that everyone who insists that we don't interoperate is > either speculating, mistaken, or outright lying. We interop just fine, > either as a client, a server, or as a KDC, in single and multiple-realm > scenarios. If you don't believe me, hunt down someone with Win2K and/or > WinXP, or get on the beta program for .NET server. Run your own tests and > draw your own conclusions-- don't just believe the spin. > > Thanks! > -Dave > > > -----Original Message----- > From: Zafar Baig [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 17, 2002 11:27 AM > To: David Lawler Christiansen (NT); hot ice; [EMAIL PROTECTED] > Subject: RE: Kerberos on the web > > > > > http://www.infoworld.com/articles/en/xml/00/04/28/000428enkerpub.xml > <http://www.infoworld.com/articles/en/xml/00/04/28/000428enkerpub.xml> > > Please read this article carefully to understand interoperability issues. > > Excerpts from this article.... > > "....Microsoft's PAC locks users into its version of Kerberos." > > > > -----Original Message----- > From: David Lawler Christiansen (NT) > [ mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > Sent: Thursday, January 17, 2002 1:47 PM > To: hot ice; [EMAIL PROTECTED] > Subject: RE: Kerberos on the web > > > > Not trolling, but where exactly did you hear that we were doing it "all > our way", and what does that mean? > > Thanks! > -Dave > > > -----Original Message----- > > From: hot ice [ mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > > Sent: Thursday, January 17, 2002 10:00 AM > > To: [EMAIL PROTECTED] > > Subject: Kerberos on the web > > > > > > Are there any commercially available kerberos-based > > authentication products for the web? I know Microsoft is > > doing something with Passport - but that's still all fuzzy > > and they are doing it in typical MS-fashion doing it all > > their way, or so I hear. > > > > Any suggestions or recommendations on products that offer > > website authentication - username/password, smartcard and a > > combination..? > > > > TIA > > > -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
