Become a fan of Slashdot on Facebook


Forgot your password?

Proprietary Extension to Kerberos in W2K 248

st.n. writes "Heise News is reporting that Microsoft made its own proprietary extension (and incompatibility) to the Kerberos authentication protocol, which was developed at MIT as an open standard. Supposedly a W2K client will only work with a W2K server, not any other kerberos server, because MS uses a yet unused data field and the W2K client relies on that field being present. For those of you who don't speak German, I found it also at Yahoo."
This discussion has been archived. No new comments can be posted.

Proprietary Extension to Kerberos in W2K

Comments Filter:
  • Specification and source are online:
  • by Anonymous Coward
    But heaven forbid anyone, and especially Microsoft, finds that the "standards" don't meet their needs.

    Indeed. All those meetings of the C Standards committee that the GCC maintainers ignore and/or boycott... It just wouldn't do to waste time at meetings when there's embracing and extending of the C language to be working on. (non compatible 'features' of GCC, that aren't even reported with the 'ansi' and 'pedantic' switches on, which causes programmers to write C code for GCC that won't build on any other compiler)

    And the Bash shell... which purports to be backwards compatible with the POSIX standard for /bin/sh.... Thank goodness the Bash maintainer is on record as not having access to a copy of the POSIX standard....

    Yep. It's a big cruel world out there. And the GNU and the Microsoft "embracers and extenders" are at it again...
  • by Anonymous Coward
    This was posted in this [] article on Linux Today []. The ZDNet article referenced within can be found here [].
  • by Anonymous Coward
    I get the distinct impression that the word "interoperability" has a different definition for MS... basically: "All of MS's products work with MS products... how much more do you want?

    The Microsoft Dictionary

    interoperability: The ability of a Microsoft product to operate with another Microsoft product.

    multi-platform: Works with both Windows NT Workstation and Windows 2000 Professional.

    Standards: The way Microsoft does something. However if you do it the same way we will sue you.

    legacy: Any product that competes with a Microsoft product or a Microsoft produt that a newer version is available or planned.

    Security: Asks for a password. Example: Windows 95 has a high level of security because it asks for a password.

    Monopoly: Unknown.

  • by Anonymous Coward
    The article submitter and this poster (and just about everyone else in Linuxland) are misusing "proprietary". This poster quotes the word as if it shouldn't apply to "trade secret", when, in fact, it is completely superfluous. All trade secrets are proprietary as governements give companies the right limit other's use of trade secrets. Something is proprietary if someone has the power (normally by law) to control other's use it. That makes anything that is copyrighted, patented, or a trade secret (and probably a few other things) proprietary. Proprietary doesn't mean "secret" or "not open". It means "not in the public domain". M$'s modification of the K. protocol may or may not be considered by a court to be a trade secrets. I would doubt it very much.
  • What can we do to about this?

    We aren't talking about some application that does something differently than everyone else, we're talking about messing with a standard to gain and maintin control of the market.

    I just can't beleive this is ethically or legally right. What can we do to deal with this ongoing problem with Microsoft? Class action lawsuit? What are our options?

    Brandon Petersen
  • In my uni, there's a feeling that upgrading to win1900 will give more hassle than it's worth...

    Unless there's a timebomb in SP6a, we're not likely to change the NT servers to 1900 anytime soon. Anyway, dual P333/256Mb RAM may probably not be enough to cope with the 1900 OS overhead....

    Us changing the server to Linux probably has a higher chance than betting on us going for win1900.

    Actually, the same happened with 3.51 .... took us some time to decide NT4 was safe enuf... and then we regretted the change for some time :-) Not likely we'll do the same mistake twice!


  • They do this to _every_ protocol they get their hands on. IPP, LPD, DHCP, Java, hell even their version of traceroute isn't right.

  • This is annoying in that it's not documented. But heaven forbid anyone, and especially Microsoft, finds that the "standards" don't meet their needs.

    Well, that's what standards bodies are for. You have to realize that the IETF (and other standards bodies) committees aren't just composed of some sort of godlike beings who hand down edicts, they're composed of people from the various companies that actually implement the standards. So if MS really has a beef with a standard that they want changed, they should take it up with the standards body and get their modifications documented.
  • by pb ( 1020 )
    That's completely braindead, but why am I not surprised?

    Microsoft shows its commitment to embracing and extending open standards once again. Let's see what new and wonderful ideas they don't share with the people working on LDAP, Directory Protocols, etc., etc.

    My only reassuring thought is that Microsoft couldn't secure a paper bag, so their implementation of Kerberos should be humorous, at least. :)
    pb Reply or e-mail; don't vaguely moderate [].
  • > I'm not sure who to believe.

    Well in my experiance, beliveing MS makes you feel like a sucker later.

  • "DNSSEC - which is a public key infrastructure unto itself - is very complex. In our judgment, at the time, it was not ready for implementation and deployment. It followed that RFC 2137 was also not ready for implementation and deployment."

    What this really means:

    "We conducted a think-tank session that included the brightest minds in Microsoft Research Labs, including the famous team that invented the sybbloic link just in time for Windows2000. It was determined that patch-build-1,234,567 broke when we tried to implemt it becuase of inconsistencies between patch-122,239, and patch 569,496, which were, consequently patches for patch 1223,456, which patched patch 22,134. Surely this standard is wrong."


    TSIG and TKEY alone do not solve the key distribution problem inherent in any secret key system. However, both mechanisms allow for extension, which permitted us to publish a third complementary draft, "GSS Algorithm for TSIG (GSS-TSIG)"."

    This one is not as funny. Seems like they use IETF protocol protocol and process to their advantage, fulfilling process requirements while breaking the spirit of the guidelines.


    "Microsoft would be happy to assist any vendors who wish to develop an independent, interoperable implementation."

    No doubt. Maybe that's why your draft has been in since 1997 and noone outside of Microsoft is interested in going forward with it.
  • 23:40:07:~$ cat a.c
    int main() { int n = 10; int temp[n]; exit(1); }
    23:40:53:~$ g++ -Wall -pedantic -ansi -o a a.c
    a.c: In function `int main()':
    a.c:1: warning: ANSI C++ forbids variable-size array `temp'
    a.c:1: warning: unused variable `int temp[((n - 1) + 1)]'
  • I went to a seminar at the otherwise _lame_ SNAC conference where they discussed what's coming in NT 5.

    They said back then that the Borg had co-opted kerb and were doing horrible things to it, and would then use it in their marketing jibberish and tout their 'support of open protocols!'.

    Film at 11.

  • That is where you are dead wrong.

    What Microsoft clearly intends is that no matter what users want, they're going to do everything in their power to make sure admins have to put up a Windows2000 server on their network. The majority of people using computers (including the administrators of most networks) are not technically competent enough to understand why the incompatibility occurs, and they're almost certainly not competent enough to run around making changes to a lot of their production systems, so they're going to wind up being forced to simply pay someone else to fix it so that the Win2k users can "take advantage" of this wonderful thing called Kerberos. This is the kind of crap that Microsoft lives off of. Make sure all the users are morons, and some of them will eventually be promoted to administrators, and then flood the market with other morons trained in the efficient sales and marketing of Microsoft products, and call them technicians anyway.

    ...which is about the same time that the local MSCE's will be undoing their belts, ready to deliver the Microsoft "solution".

    Frankly, at this point I would rather shove my hands up to the shoulders into a wood chipper than to use Microsoft products anymore.

  • AFAIK, nobody at MIT has plans to migrate any important services to a Windows-based platform any time soon. Kerberized POP, krb5-authenticated print services, Kerberized Zephyr, AFS, an so forth will all continue to run on Unix-based machines.

    This means that the issue is (mostly) irrelevant to Athena. Since every service is going to run on Unix, we don't care about Windows "extensions" to Kerberos; if Windows machines can access Unix services using a Unix-based Kerberos server, then everything Just Works (TM).

    Personally, I think Pismere is just a lost cause. Even if Win2K is "a new standard of reliability", I suspect a test cluster of 10 Windows-based machines would have much more serious problems than the 10 beta Linux-Athena machines currently available for public use in W20-575. Just about everything we need is available now (and has been for several years) on Unix, and people with personal PCs have been able to install SIPB's Linux-Athena to get Athena on their desktop. With an official supported MIT I/S Linux-Athena coming soon, it's clear that MIT isn't planning on pushing Windows as their Intel-based OS of choice.

  • Maybe I'm not understanding the politics or technical intensity of this. But if this is going to cause such a huge issue with compatibility, and we know that it is... then it seems to me that an appropiate solution would be NOT to implement Win2K in an environment where you know it's going to be a bitch..

    and with the sudden surge of popularity in free stuff, the solution seem kind of obvious.. but this isn't one of those "USE LINUX, LINUX RULES" rants.. there are several other solutions out there.. roll your own.

  • And what about Active Directory? Another brilliant innovation that's actually a standard technology with some unnecessary (IMHO) changes, so that a Windoze box can access a directory with LDAP but existing LDAP-clients can't easily use a Micros~1 directory server 'cause the schema is wrong.

    Would they really still be working like this, even with the way their trial is going? I know they're not stupid, but maybe they just can't help themselves...

  • They should be made to stick to standards, or to submit their ideas into the standard. There should be some kind of "Open Standards Licence", like the GPL, so that if you take a standard and make some changes to it, you have to release the changed to that standard.

    This is a Very Bad Idea. If you allow for licenses on how standards are implemented, Microsoft could kill samba, and then demand royalties on any program that can interpret MS Word documents.

    What you can do, is trademark the name of the standard, and require that any product bearing that mark pass your test suite. Of course, as soon as you do that, the Open Source community will try to beat you to death with big sticks because your standard isn't open enough. (Consider the Java(tm) or Unix(tm) marks)

    And then the embracer and extender just implements their broken version anyway, and quite legally calls it "J", or "Unix-like operating system".

    On the other hand, if the DOJ forced Microsoft to publish all their APIs and network protocols, in a similar vein to what was done to IBM, then the problem in this instance would be moot, and few other companies are powerful enough to use embrace and extend in this way.

    Charles Miller

  • I wrote in [it was rejected] about how M$ was going to follow Apple's lead [yet again] and have client services available (like site visibility ?) ONLY to its desktops connecting to its IIS servers.

    Now you'll have to pay a tithe to M$ to list you site on a (M$) DNS and you may or may not be able to see anyone else's site.

    Running /. on IIS guys? Then there goes half your readership.
  • The company which installed the wiring for our PBX and network appeared to be competent up-front. Then they put in RJ-45s for both phone and network throughout the building... even though the phone system they sold us used RJ-11 (only one wire pair for that matter).

    When asked, they said "oh, the little plugs fit OK in the big sockets". Then they labelled the jacks as "1" and "2", not as "phone" and "computer".

    We explained the idiocy to them, and insisted the replace all the phone jacks with RJ11s. They agreed after some cajoring.

  • This has actually been known for awhile. The only reason it is receiving press now is because people will finally be forced to deal with this issue -- along with the many other gotchas that come with W2K. Until cross compatibility comes along for the two different versions of kerberos, windows users will be left isolated and in an uncomfortable position. --voodoo
  • The problem is if you don't talk to a W2K Kerberos Server you don't get your sercurity [sic] permisions [sic] so it reverts to netlogon.

    And this is a pretty good job?


  • Yes it should compile. Whitespace shouldn't matter. The compiler shouldn't care if you use a [CR], a [TAB], a [SPACE], the number or combination of such characters you use, or whatever, just so long as there is at least one whitespace character where a whitespace character needs to be.
  • It uses Kerberos as defined by the standard. If people are going to bitch and moan about Microsoft doing this, then stop writing ambiguities into the standards. Of course, there's a reason why this field was left open, and that's so that vendors (apparently, only vendors other than Microsoft, haha) could could use it for things like vendor-specific or application-specific data. Now that Microsoft uses it to their advantage, everyone's in tears. Well Boo-frickin'-hoo.

    Whoops, now that I see your comment that Win2K has only 27 apps avaiable for it, I realize that you have no idea what you're talking about. My post would've been better spent replying to someone with a clue.


  • May I recommend The Halloween Documents [] by ESR. There you will get an understanding of why M$ does this....
  • I thind we should tell it to the Judge! Just in the form of an open letter. The games continue! The Monopolist is Still behaving badly.

    Oh Well. Our company has 1 application left that runs on NT. And it is a 3rd party app. We have put that 3rd party on notice that we will not be using any new versions of Windows in the future and they have a Linuxified version of this service in test... Just like IBM in the early 80s. You just have to be diligent. Don't use M$ products for your IT solutions.
  • Please moderate the above post down. Sorry but it is offtopic and if you know anyone with MS it is just not funny.
  • Microsoft has not tried to hide this in any way. I learned about it last April in a W2K class and it is in numerous whitepapers on their site.

    It is my understanding that this sort of extension is allowed in the kerberos spec and that MS is not the first implementation to take advantage of it.

    If you are going to bash MS, don't bash them for following the rules. With W2K, Microsoft is finally making a fair attempt at following and using the standards.
  • This is totally off-topic but you wouldn't know where I could find these "MMJ" cables and a MMJ-->9 pin RS-232 adapter. I just happend to buy an old VT420 for pennies, I intend to connect it to one of my Linux boxen. Unfortunately I have no cable. Learning that the cable type is "MMJ" is a big help. If you have any more info I would love to hear it.
    Mark Tinberg

  • Email is supposed to by Mark Tinberg
  • It is MS being their usual "we work with them (almost)" self, but in this case, they're not hiding anything. They just happen to use more of the spec than the reference one.

    from ZDNet's article:

    Shanen Boettcher, Windows 2000 product manager at Microsoft, said last week that the company has only made use of an existing feature of Kerberos and is not undercutting an existing standard. But he acknowledged the change is not documented, noting that some developers may believe they need to know the details of Microsoft's change before they will be able to get their software to work with it.


    When asked how developers will work with the specifics of Microsoft's implementation, Boettcher said: "The contents of the field are currently not available. We have been asked to document them, and we are trying to figure out what to do with that request."

    Sounds to me like they're hiding something...

  • The most popular Linux license doesn't need the addendum -- the GNU GPL already makes evil corporations run screaming. Some forbid their employees from even looking at GPL-protected code. :)

    Cause they know if they use it, or modify it, without giving the source back, they can be sued -- not just for money, but for the public release of the code for that product (and thus the loss of any profit from it).

    Few would take that risk.

  • as far as your off topic theory goes, i smoke pot and use also windows except ive run out of pot and am yet again considering deleting windows. so that seems to go with your theory quite well. ill have to let you know if when i get my hands on some more smoke if i decide i really couldnt be bother deleting windows after all. probably when mozilla is as nice as ie and i finish this job (which requires me to use mssql argh!)ill end up deleting my windows.dsk but ill probably end up keeping it on there anyways, cause i sure intend to get some more smoke soon :)

  • Actually, it looks like they're trying to leverage their desktop dominance to sell more servers.
  • by Anonymous Coward
    Here it is. []
  • Trade secrets have very limited legal protection compared to copyrights or patents. As I understand it, as long as you haven't actually had access to the secret information, you can divulge it all you want. So reverse engineering would be perfectly legal. That's why there are both trade secrets and patents. With a patent, you get protection for a limited time. With a trade secret, the protection lasts until someone figures the secret out (as opposed to ferreting it out).
    I am not a lawyer. I do not actually know American law. This is just a bunch of uneducated guesses.
  • Thing is, I have a crimper with an MMJ adaptor -- but that's the only adaptor it has. So all I can crimp are MMJ cables. I've used the damned thing exactly once -- when I was running a cable down to the basement to connect a linux box in my room to a VT420 in the basement. It worked fine, too, but you have to realize that DEC's MMJ DECConnect cables also had a couple of wire twists in them. A multimeter helped me figure out which ones they'd switched around. Unfortunately, I can't remember offhand which ones those were, and the terminal _will not work_ properly without those cables switched (and it didn't work with a straight cable and a null modem, either.)

    - A.P.

    "One World, one Web, one Program" - Microsoft promotional ad

  • Anyone wanna take bets on how long it'll take for someone to reverse engineer the MS extensions?

    IIRC, doesn't Australia (and possible elsewhere) speicifically allow reverse engineering to mainting interopribility (or somesuch)?

    Do the reverse-engineering in the US, or wherever, and get an Aussie friend to publish the results on an Australian web server.

    What, you mean the rest of the world can see that web server? Oh well, too bad...

  • Not wishing to speak for RMS, but isn't this *exactly* why he created the GPL - because the MIT license allowed companies to try these stupid tricks.

    MIT (as well as every other educational institution) should release all code under the GPL, or similar licenses with protection against proprietary extensions.

  • Windows 2000 either supports Kerberos authentication or it doesn't.

    Kerberos is a well defined standard. If they misimplemented it in such a way that their product will not interoperate with existing Kerberos domains, then they didn't implement Kerberos.

    If Microsoft chooses to lie to their customers, no amount of IP whining is going to help--oh, unless this UCITA thing happens to pass...oh.

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
  • The reference implementations of Kerberos 4 & 5 are available under a BSD-style license, so there's nothing wrong with what Microsoft has done, even if they do use Kerberos code in Windows. (I'm not sure if they've said they use any MIT code or if they did a ground-up implementation based on the specs)
  • > More importantly, the standard DCE approach
    > admits of a nasty race condition, where a second
    > user uses a first user's workstation token to
    > get at his or her user ACL entry.

    Huh ? This doesn't make sense. All the packets used in kerberos are integrity and privacy protected. The scenario you describe is simply not possible. Also, there is no such thing as a 'workstation token'. Kerberos principals are users and services, not machines.

    The "MS hack", as you describe it, has *nothing* to do with any potential race conditions in DCE.

    I would suggest reading "Network Security", by Perlman, Kaufman and Spencer for an excellent introduction to these topics.


    Jeremy Allison,
    Samba Team.
  • No, actually it is still an issue. I have been requesting that Microsoft document this extension (Hi Peter :-) ever since I heard about Win2k (then WinNT5) being kerberos based back in '97. I was porting MIT Kerberos 5 to Windows NT 4.x at the time for Cygnus (now RedHat).

    Every time I ask (and I've asked *many* times, publically as well as privately) Microsoft have said "yes we are committed to documenting this". I believe them. I just want to *see* the documentation first....


    Jeremy Allison,
    Samba Team.
  • Regardless, it really ins't [sic] microsoft's job to ensure compatability [sic] with anyone but themselves.

    That sentence lends itself to another reading, which is that it's in MS's interest not to interoperate with anyone else's stuff, except at a minimal level insofar as you need to (say) speak TCP/IP. This is the same sort of thinking that helped IBM sew up 90+% of the mainframe market well into the 70's, and earned them (a) widespread enmity from customers and competitors, (b) a federal antitrust investigation, and (c) carte blanche to unilaterally carry the state of the art in whatever direction they wished. There's a gray area between intentional incompatibility and actual anticompetitive behavior when you have the market share IBM did then (or Microsoft does now).

    If they really care about increasing the utility of technology in the larger sense, which I'd argue they must if they know what's good for them long-term, they should participate reasonably in standards definition processes. I know that a lot of what you decry as "interorganizational posturing" involves companies being inflexible on just these sorts of issues, and that Microsoft is as bad an offender as any--when they deign to participate at all.

    Anecdote: My friend was the Lucent delegate to an IETF Working Group. For three consecutive meetings no work at all was completed, because every time the Microsoft rep opened his mouth it was to say "I move that the entire text of the proposed section be stricken and replaced with: 'Bla bla bla....'." That is not what I would call playing well with others.

    I am not a blindly Microsoft-hating zealot. I do take exception to many of their business practices.
  • Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:

    The DNSEXT working group home page []
    RFC 2065 []
    RFC 2137 []
    RFC 2535 []
    Secret Key Transaction Authentication for DNS (TSIG) []
    Secret Key Establishment for DNS (TKEY RR) []
    GSS Algorithm for TSIG (GSS-TSIG) []
    White paper on Kerberos interoperability []
    Press release on Kerberos interoperability []
    S imple Secure Domain Name System (DNS) Dynamic Update []

  • I had the same kind of questions last month. It lead to an essay [] called "Barbarians in the Library" [].

    The gist of my argument is that, if open standards and protocols benefit any one person or organization more than that person or organization contributes to everyone else (as is the case for pretty much everybody!), perhaps removing those benefits will help convince a rogue organization to stop trying to embrace, extend, deform, and extinguish those standards and protocols. It would be nice to get some suggestions and critiques and comments on it. :)


  • You can even fix NT, if you have the source code.

    MIT has campus computing labs with solaris and
    IRIX. To get future NT client to work with the
    existing Kerberos Authentication server, they
    are forced to modify NT source code.
    (Part of project Pismere

    They will also have NT mount user home
    directories off of the Andrew File System (AFS).

  • Side effect is that Unix and Linux boxes could get their connection to printers refused because of this.

    No, it's actually the other way around. Windows clients could get their connections to printers and files refused because of this. Kerebros is supposed to authenticate once, and the let you have access to all resources you have permission to, without continually reauthenticating. However, It'll end up that Windows clients will only have access to resources on Windows servers. So you can't have Samba running as your server. Microsoft profusely apologizes for the inconvinience. (Yeah, right!)

  • Is there anything in the Kerberos license that demands they not call it "Kerberos"?

    Why can GNU call their version of a standard "make", even though it has numerous incompatible extensions, but Microsoft is not allowed to call their version of Kerberos by the name of "Kerberos", even though it has far fewer extensions and incompatibilities than does GNU Make?

  • Is their, I mean Active Directory, implementation compatable within a standard LDAP environment, or did they "customize" it as well?

  • I thought pretty much any Win32 app other than games would run on Win2k fine, is that not true?
  • I just returned (less than an hour) from a Microsoft briefing about W2K (hey it was free and fun).
    The MS droid mostly skipped security but spent quite some time on Kerberos. He insisted the MS Kerberos was fully compatible. He even said (translation from Dutch): "the implementation was clean of incompatible Microsoft additions".
    According to him the use of the extra field was according to RFC 1510 and would work with all other clients and servers.
  • Surprise []. The Authentication method "Windows NT Challenge/Response" sends an encrypted challenge to the browser. A nonstandard browser just sits there...until you notice your CPU is busy and the flickering messages in the status line. More examples on Deja news [] by searching for "Netscape MS proxy problem".

    An MS plugin for Netscape [] exists, if you're running Netscape on a system which is compatible with the plugin.

    Actually, even Exchange Server has problems [] if not running on same server as IIS.

  • by mircea ( 28953 )
    Not to mention I submitted the story 4 days ago, and it was rejected in a matter of minutes. Who cares anymore...
  • Nothing Evil about this, just annoying

    When your kid brother punches you, that's annoying.

    When an 800lb gorilla punches you, that's evil. (because unless you figure out a way to soften the blow, you're dead)

  • I know two people with MS: one of them is me, and the other one is my mother (yes, really.)

    Personally, I happen to think it's funny as hell.. and if I had any mod points left, I'd moderate it up as such.
  • GCC has typeof which nobody else does. It also has builtin functions for alloca, abort, exit, and _exit. Which by the standards should be in a library allowing for a linktime replacement of the standard C versions. In g++ there is the headof extension. And those are just the obvious.
  • That's not really an answer. It may be a use that is related to a property that only W2K has. It also may have been the sort of thing that was developed in 6-12 months rather than 6-12 years. Some of these standards take way too damned long to settle, often because of interorganizational posturing.

    Regardless, it really ins't microsoft's job to ensure compatability with anyone but themselves. How many vendors will authenticate users for a VMS system? When you have a different paradigm it is often useless and futile to try and maintain 100% compatability with every little OS under the sun. Really documentation is the only issue here.
  • I read on the Novell site (yeah, really unbiased of course) that for LDAP Micro$oft did the opposite of embrace and extend. LDAP has had a bunch of extensions added over the years which have become defacto standard. Lots of clients use these extensions, including Lotus Notes. According to Novell MS LDAP does not include these extensions, so it breaks all the standard clients. Unfortunately I can't now find that page on their site.


  • I agree. Define what the data authorisation field should contain, and release the standard as "Kerberos 6 - the more secure and updated version!" and then implement the changes in all of the other implementations. Windows 2000 will be stuck with "Kerberos 5 - the old and duffed up and abused version".

    They should be made to stick to standards, or to submit their ideas into the standard. There should be some kind of "Open Standards Licence", like the GPL, so that if you take a standard and make some changes to it, you have to release the changed to that standard.

  • Yes. However, if Kerberos had been patented, and then use of the patent was granted under some copyleft license, then Microsoft couldn't have done this.
    Of course, that might not have helped either; maybe they'd just have opted for something entirely different.
  • I believe they use a field for which there is no specified use.

    This simply means that only W2K can talk Kerberos with W2K servers. It doesn't mean W2K cannot talk to other OSes. The other implementations will just disregard the field. However, if you are attempting to integrate any other systems with W2K server, you are SOL, and apparently Microsoft wants to force you to buy W2K.
  • Obviously MS has choosen to implement a standard that, while pretty similar to Kerberos, actually isn't Kerberos. The current standard is available from enough sources and Microsofts changes are not part of it. Thus any company using W2K for which Kerberos is a critical application should sue MS on the grounds that their product W2K isn't able to use Kerberos, contrary to advertising.

    It's enough that ONE business successfully sues MS even if it's only for some K$ worth of unscheduled downtime and worktime needed to 'fix' this 'feature'.
  • MS sure did release a browser fast when Mr. Gates realized the internet was important.

    In Microsoft's defense, they do have lots of monkeys and keyboards (typewriters did not crash enough). :)
  • Folks, this article about w2k Kerberos incompatibility untrue. I have set up a Win2k RC2 workstation last month at my job for testing purposes. We have a Unix KDC on the network running the standard MIT Kerberos distribution. I configured the win2k workstation to authenticate against the unix KDC - and it worked perfectly. As a matter of fact, I configured the workstation using microsoft's own step by step instructions for doing so, which can be found at [] /Q232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0. See the part entitled "Using an MIT KDC with a Windows 2000 Workstation".

    This article may be confusing everything with earlier verions of win2k betas (AKA NT5) which microsoft had openly said would not be fully compliant with the kerberos standard. However, they changed this around the RC2 release I believe. You can find an outdated article with more details on this here: [] /embraces.html.

    This older stuff is probably what they're talking about, but they have definitely changed w2k to make it fully compliant with the existing Kerberos standard...

  • Actually you can use W2K kerberos to access Unix/Linux kerberos systems. But you can't use Unix/Linux kerberos clients to access W2K servers. Typical Microsoft "embrace-and-extend" crap.
    Acually it's the other way round: any client can access W2K servers, but a W2K client will only work properly when communicating with a W2K kerberos server. Otherwise some Win-services like printing won't be available.

    But I think that was what I wrote when I posted that news, only with less words. :-)

    - Stephan.
    Carpe diem!
  • Replace in any way, shape or form.

    With the common course of business, or for gain of economic interest

    The people at Microsoft are no different than us; They deserve their individual right to the source too! If wants to submit a patch, or tweak it to his personal liking, he should be able to. Judging him a 'lying scumbag' based on the exploits of his employer are wrong..
  • You mean, like <a href= news/0,9493,2449668,00.html?chkpt=entne> ?

    You can use &lt; to escape a less-than sign (and &amp; to escape an ampersand). You can also post in plain text instead of HTML formatted if you want to post a code fragment.

  • It is MS being their usual "we work with them (almost)" self, but in this case, they're not hiding anything. They just happen to use more of the spec than the reference one.
    If this stuff is supposedly in the spec, why are people complaining about it being undocumented and therefore not able to be rolled into, say, Samba?
  • I'm afraid we've been seeing MS-TCP/IP for a while now. No version of Windows currently supports the full TCP/IP spec. In fact, Linux only got full support recently.
  • I contend that the extra field is the packet data encrypted on the ultra-secret NSA key, allowing them to eavesdrop on all network transmissions that use the protocol!

    That's right, I can dish it out as well as I can take it :-)

  • Well I dont intentinally mean to offend anyone with MS multiple sclerosis that is) obviously my comment was meant to be funny, and I'm sure that people who have MS have a sense of humor. If youve been offended, then I'm sorry, but lighten up, the world is a harsh place, and if you cant laugh every once in awhile, you might as well get off this rock.

  • I can envision a hue-and-cry among open source users, who will see this (quite justifiably, I might add) as Microsoft's usual policy of "embrace-and-extinguish." There will be vitriolic posts here, full of people who will suggest that we figure out how to hack Microsoft's modification, or send lots and lots of E-mails to Microsoft to vent our collective spleen, and all kinds of howls of outrage.

    Shall we try to get the word out on various news services? It could be difficult - the people who don't immediately understand the technical issues are likely to see us as "anti-Microsoft zealots," and subsequently dismiss our complaints as so much noise. Not that we've always been so good at advocating our actions - for every 10 level-headed suggestions, we have one rabid nihilistic recommendation that is far more entertaining, and grabs far more media attention. Unfair, but true.

    The problem is this - How can we figure out a way to prevent Microsoft from doing this? And how do we do it without looking like a bunch of lunatic-fringe weirdos?

  • Reminds me of the old DEC days when they made proprietary RJ-11 connectors, they had the tab on the side so you could only use sanctioned DEC cables, which were twice as expensive. I can see parallels in what M$ is doing, for obvious reasons, but when will M$ learn that every time they do something like this they really create long term damage to their products and alienate their customer base. Whatever PHB's at M$ who supported this should be canned, this is even bad by M$ standards.
  • Y'know we'd save a lot of headache if every open source license had the following addendum:

    Microsoft, and any subsidiary company or employee thereof, is specifically barred from modifying this source code in any way, shape or form.

    If you can't join 'em, beat 'em...preferrably with a big stick.

  • Let's give proper credit. For once, Microsoft has NOT perverted the standard. They have used a field in the way the RFC described. I believe the RFC actually states that the field is free-form, and that its contents should be defined by the application.

    The complaint against Microsoft regarding this issue is that their specific use is a secret.

    This is a fairly creative move on Microsoft's part. From appearances, they have fully embraced the standard and have followed it to the letter.

    They simply chose to keep a secret.

    Why can't Microsoft keep a secret? Sure, it's annoying, but is it illegal or morally/ethically wrong? I don't know. I'm biased, so it seems wrong to me.

    I don't think it benefits consumers. It is a barrier to interoperability. It is unlikely that this single secret required a significant amount of research and development, except maybe to identify it as a strategic thing to keep secret.

    It won't take long for someone to reverse engineer it or pry the information out of Microsoft, but in the meantime everyone is going to appear to be lagging behind Microsoft in the W2K-compatible server arena, and Microsoft will gain market share. It is unlikely that the DoJ will be able to reverse that.

    Regarding traceroute... there is no "right" way to traceroute. Traceroute is a hack. It was not designed into IP. It simply uses conveniently available IP capabilities to accomplish its goal.

    Even IF Microsoft's traceroute is not the same as others, their implementation hasn't failed me... so I find any implementation difference to be far less annoying than the fact that they called it "tracert.exe" instead of "traceroute.exe".

    None of the operating systems on which "tracert.exe" ships are restricted to 8.3 filesystems. Maybe it's cuz of the ISO9660 filesystem. Whatever the case, it's annoying.

    Hmm... I seem to be drifting here... wheee! [submit]
  • I used to work at dec, many years back.

    the way the MMJ (modified modular jack) came about was to protect devices from being plugged into phone lines. rj11 for comms devices is braindead, IMHO. rj11 is for telco current loop stuff - period! for serial 232 style devices, the MMJ made perfect sense.

    and with ethernet being a wider connector (rj45), you have the same benefit as the MMJ - you can't plug a serial cable into a phone jack.

    ok - well, a lot of people are using rj45 for phone connectors today. that still doesn't make it right. rj11=phone; rj45=data. why do folks have problems understanding this?


  • According to a page on microsoft's site:

    "Windows 2000 clients, either Server or Professional, can be configured to use an MIT Kerberos server. This provides a single sign-on to the MIT KDC and a local Windows 2000 client account"

    You can read more about this at 232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0 []

    So at least they didn't completely break kerberos.

  • by Anonymous Coward on Thursday March 02, 2000 @08:55AM (#1230644)
    First things first. The mag is wrong, we did Kerb5/Win2000 testing most of last year and it was sometimes broken in the -betas-. Final product does work as stated.

    MS-Extensions. - This is the vendor data that is allowed as part of the spec. Same place the IBM/Transarc/SecurityDynamics/Entrust/etc put there propriatory data.

    3. Won't talk to other Kerb'5 boxes. BULLSHIT on client and server.

    4. No real interobrility. If you don't read the damn docs and keep your head up your a**. otherwise it works like this:

    Unix Realm MitK5 manual secured vpn type link Win2000 KDC Win2000 AD -> backlevel NT4 domains.

    if you want you NT4 box to Authenticate in Unix kerb5 go right ahead. The user ticket will be fine on a trusted NT based kerb realm. same goes true in reverse.

    What you lose. Same problems as with all -legal-but-not-required things; no matters who extension it is one side can't process the vendor data. Solve the problem by static mapping trusted and untrusted principles in the kerb realms. It can be a pain and is really only a small scale fix. Same as the other K5 vendors solutions.

    no, ou can't make a host part of two realms at once. this is true on all kerb versions

    silver-lineing. The K4 world sucked and K% suckes less. The problems of the vendor data have been ignored by most vendors (hello IBM) untill MS starting showing code to the Win2000 Kerb modules and working with MIT and the standards group to get the vendor spec closed. No one wan't to say the MS-Kerb is spec clean and that they aren't. hence the recent intrest other vendors have displayed about joining in cleaning up kerb5

    btw, there is a big bug in cross-realm auth that is (hopefully) fixed in sp1 (eta march-april). It hits Win2k to Win2k just as well

  • by /dev/niall ( 1043 ) on Thursday March 02, 2000 @07:34AM (#1230645)
    While I'm sure that Microsoft's intentions were to break exisitng Kerberos installations so they NEED Win2K somewhere in the mix, it doesn't look like an incorrect use of the field in question. If they argue that they're granting rights to Windows resources only anyway... here's a snipped from RFC 1510:

    The authorization-data field is used to pass authorization data from the principal on whose behalf a ticket was issued to the application service. If no authorization data is included, this field will be left out. The data in this field are specific to the end service. It is expected that the field will contain the names of service specific objects, and the rights to those objects. The format for this field is described in section 5.2. Although Kerberos is not concerned with the format of the contents of the subfields, it does carry type information (ad-type).

    By using the authorization_data field, a principal is able to issue a proxy that is valid for a specific purpose. For example, a client wishing to print a file can obtain a file server proxy to be passed to the print server. By specifying the name of the file in the authorization_data field, the file server knows that the print server can only use the client's rights when accessing the particular file to be printed.

    It is interesting to note that if one specifies the authorization-data field of a proxy and leaves the host addresses blank, the resulting ticket and session key can be treated as a capability. See [9] for some suggested uses of this field.

    The authorization-data field is optional and does not have to be included in a ticket.

    Please note that I'm not defending Microsoft! It's pretty obvious what their intentions where given their track record.

  • by X ( 1235 ) <> on Thursday March 02, 2000 @07:11AM (#1230646) Homepage Journal
    I had heard this rumour long before W2K came out. However, according to this document [], such interoperability is possible. I'm not sure who to believe.
  • by SpiceWare ( 3438 ) on Thursday March 02, 2000 @08:43AM (#1230647) Homepage

    I've had to fight Microsofts CHAP implementation in the past. At a prior company I worked I used to have to dial in to support our EDI software(24 hour support, but seldom needed to call in). I used my OS/2 system to access our AS/400. For some reason they changed our dial-up hardware to NT and all of a sudden I was no longer able to dial in.

    I eventually tracked it down to the MS version of CHAP not liking my standard CHAP routines. They wouldn't change the settings to accept standard CHAP as "it would make the system less secure". They didn't like my question of "If 90% of the systems are using Windows, then how does MS-CHAP make it more secure?"

    I refused to change my home system to Windows due to work requirements(what I use on my own time is my choice, not theirs). For a few months I didn't provide support from home until I stumbled across a new PPP dialer, Injoy [], that had MS-CHAP support.

  • by Signal 11 ( 7608 ) on Thursday March 02, 2000 @07:04AM (#1230648)
    And this is new for Microsoft? Now, what is really humorous about this is that now that the kerberos people are aware of this they'll add "MS extensions" back into the codebase to allow interoperability.. just like pppd added support for MS CHAP and the extra garbage that's sent over the protocol.

    Heh. Don't get too worried: we've got 'em under control. Be happy they're using the core of kerberos so it won't be hard to detect and fix the changes they made.

  • by Admiral Burrito ( 11807 ) on Thursday March 02, 2000 @01:21PM (#1230649)

    Acually it's the other way round: any client can access W2K servers, but a W2K client will only work properly when communicating with a W2K kerberos server.

    Does anyone else see the irony here? MS-Kerberos forces Win2k clients to use a Win2k server...

    Kerberos keeps the damned in Hades. Film at eleven.

  • by mcc ( 14761 ) <> on Thursday March 02, 2000 @02:45PM (#1230650) Homepage
    What we want stopped?
    Microsoft throwing a bunch of crud into open protocols, cluttering up the procotol JUST so they can put their names on it, say "look! microsoft did something in creating this standard!" Microsoft does not do extend these things to get a technical benefit from the extention; they do it to show people who's boss, to point out that MIT, the linux community, et all, is NOT in control here; this is MICROSOFT'S world, not theirs, and if they think that a community decision is going to be allowed to dictate what happens, then they have another thing coming. And, of course, in the process of extending, they propeitarize, which directly hurts the community currently using the protocol because it means that for a longish while, the original supporters of the protocol will be unable to adapt their software to be operable with microsoft's supporters; and even after the original supporters support microsoft's extention, the way they do this will more than likely be reverse-engineered and highly dodgy (*cough *cough *SAMBA* cough*).

    We don't really want microsoft to stop extending; more importantly what we want is microsoft to design their extentions to the standards in such a way as to ENCOURAGE INEROPABILITY. If you are going to be extending a standard, this is not evil in itself; if you are going to add something to the standard in order to get some kind of feature or benefit that you would not get without the extention, this is almost certainly a good thing. But if whatever is on the other side of the protocol from you does not comply with your extention, the result should be that neither side benefits from the presense of the extention. The result should NOT be interopability. All recent extendable standards i can think of-- HTML being the first to come to mind-- attempt to stress methods by which failure by both ends to support the same extention results in the extention not being used, NOT in the standard becoming nonfunctinonal between the two sides.

    a better way to phrase the original question, i think, woudl be: How do we get the media, the public, and everything to the point where microsoft can no longer get away with doing this? Microsoft does not neccicarily need to be stopped in this respect; but what needs to happen is people need to be _aware_ that microsoft is doing this; that microsoft is purposefully breaking functionality in a product _they paid for_ in a situation where that functionality that could have easily be retained. People need to begin asking themselves the question of why microsoft is doing this. People need to be aware of the extent to which microsoft wants everything propeitary to them. If people in general were aware of what was going on, and more importantly UNDERSTOOD it, they would almost certainly disapprove; but instead we wind up with the people (who probably never go to anything requiring more authentication than My Yahoo) just going, "Kerberos? Huh?". You think "propeitary" is even in most people's vocabulary?

    I apologize if my writing here is somewhat unwieldy. I've had a bad day. :P

  • Actually you can use W2K kerberos to access Unix/Linux kerberos systems. But you can't use Unix/Linux kerberos clients to access W2K servers. Typical Microsoft "embrace-and-extend" crap.

    Microsoft used the semi-documented (but not in the official spec) data authorization field in the kerberos ticket to their own purposes and refuses to tell anyone what they did.
  • by Stavr0 ( 35032 ) on Thursday March 02, 2000 @10:07AM (#1230652) Homepage Journal
    according to Microsoft Mythology, Kerberos is a cat and it's got four heads. It guards the gates of heck.
  • by EnderWiggnz ( 39214 ) on Thursday March 02, 2000 @07:09AM (#1230653)
    maybe MS will test the UCITA and not allow reverse-engineering of this "proprietary" tradesecret that they obviously enhanced...

    I get the distinct impression that the word "interoperability" has a different definition for MS... basically:
    "All of MS's products work with MS products... how much more do you want?
  • by bifrost ( 45323 ) on Thursday March 02, 2000 @07:42AM (#1230654) Homepage
    The best part is that the MS Kerberos extensions *STILL* Rely on the old insecure Domain Authentication system. They actually pass tickets between machines with that. We all know how wonderful that system is, and of course how secure it is. You still won't find MS Kerberos to be useful, the only way for Win2k to correctly authenticate to a Kerberos domain, is to make it part of a guest/second domain, in which the W2k PDC is the KDC for a second domain!

    Its retarded, It still relies on the old screwed up MS Security junk, which is *STILL* compatible with the ancient LanMan authentication. Something that is still easily crackable. Don't throw away that old L0phtcrack yet, there is still use for it.

    About the only good thing about Win2k is that you don't *HAVE* to reboot for the almost 100 things you used to have to, now its just like 10-15 things that you do. And that its got IPSec built in, but apparently you still need to have a Win2k Cert server for that to work, so its the same old story. *sigh*
  • by Farq Fenderson ( 135583 ) on Thursday March 02, 2000 @08:27AM (#1230655) Homepage
    There is a solution to this. Or at least to stop it from happening in the future.

    Stadnards could be written in such a way that any extended features must be requested before thier use. If they aren't available, then the client / server MUST continue without the use of that extended feature.

    This would eliminate incompatabilities like this, since any closed (or otherwise) implementation that doesn't function without a certain extended feature could not claim to conform to the standard. At this point micros~1 could not claim they've got an 'enhanced implementation of standard X' when their version is incompatable with everyone else's. They could only claim to have an 'incomplete implementation of standard X'. The key is placing portability implicitly in the standard.

    script-fu: hash bang slash bin bash
  • by logicTrAp ( 2864 ) on Thursday March 02, 2000 @07:10AM (#1230656) Homepage
    You can get some more info on this issue in the Kerberos FAQ []
  • by Arandir ( 19206 ) on Thursday March 02, 2000 @10:19AM (#1230657) Homepage Journal
    "How can we figure out a way to prevent Microsoft from doing this?"

    What exactly do you want to stop? If you want to stop Microsoft from extending standards, then your only recourse to to make those standards proprietary. Even if Kerberos were under the GPL, Microsoft could still add an extension to it and release the modifications back. But there would STILL be an extension to Kerberos! It would then be up to the Kerberos team to incorporate the Microsoft extensions or not. Only by disallowing modifications can this be stopped.

    But the Kerberos license is unrestricted, and not copyleft. Their goal was to get Kerberos used as widely as possible. W2K with Kerberos extensions is much more compatible than W2K with no Kerberos at all.
  • by Anonymous Coward on Thursday March 02, 2000 @09:11AM (#1230658)
    From zdnet []:

    "[Windows 2000 product manager] Boettcher added that both Unix workstations and Win2000 desktops may log in to the Win2000 server. But Win2000 desktops cannot log in to a Unix Kerberos server and receive access to Win2000 resources such as file and print, he said."

    Every new release of Windows NT to date has added "extensions" to SMB designed to prevent third party vendors from acting as SMB servers. Since Samba is a better SMB implementation than Micro$oft's, obviously MICROS~1 marketing were afraid Samba was cutting into NT Server sales. Hence this transparent attempt to render Samba worthless for Win2K clients.

    The only credible response to this is a complete boycott of Win2K until Microshaft provides the Samba development team with the information they need to make Samba interoperate with Win2K clients.

  • > Can you link to any hard data?

    Yep. The O'Reilly book, "DCE Security Programming" by Wei Hu, ISBN 1-56592-134-8 (just don't buy it from Amazon :-).

    Page 37, section entitled "How PAC's are used" explains how a standard Kerb5 TGT is obtained, then a ticket to the privillage service is obtained, then a second TGT (called a PTGT) is obtained from the privillage service. This PTGT contains the authorisation data (user and groups in the form of DCE UUIDs) stored in the "application data" field.

    It was done this way so a *standard* kerb5 server could be used as a authentication source, with a secondary server used as an *authorization* source.

    Microsoft could have done the same. They didn't, but modified the Kerb5 KDC directly and put authorization data into the TGT. That's what the fuss is about.


    Jeremy Allison,
    Samba Team.
  • > MS-Extensions. - This is the vendor data that is
    > allowed as part of the spec. Same place the
    > IBM/Transarc/SecurityDynamics/Entrust/etc put
    > there propriatory data.

    This is incorrect. The DCE PAC's are created by first getting a *standard* TGT from a Kerb5 KDC, then using that to get an additional TGT containing the PAC. Microsoft could have done the same. They chose not to. That is what people are objecting to.


    Jeremy Allison,
    Samba Team.
  • by Teroc ( 8747 ) on Thursday March 02, 2000 @07:25AM (#1230661)
    mailing list several days previous. Here is the 'relevant' information, posted by a rep from Microsoft:

    When RFC 2137 "Secure Domain Name System Dynamic Update" was written, it was
    based on the then-current DNSSEC spec, RFC 2065 "Domain Name Security
    Extensions". RFC 2535, a re-write of DNSSEC based on implementation and
    deployment experience, obsoletes RFC 2065. A side-effect of the deprecation
    of RFC 2065 is the invalidation of RFC 2137. RFC 2137 is not safe for

    Upshot: there is no IETF standard for DNS secure dynamic update.

    Two years ago we had to make a call on whether or not we should implement
    DNSSEC (RFC 2065) in Windows 2000. DNSSEC - which is a public key
    infrastructure unto itself - is very complex. In our judgment, at the time,
    it was not ready for implementation and deployment. It followed that RFC
    2137 was also not ready for implementation and deployment.

    Still, we needed a solution for secure dynamic update. As it happened, the
    DNSIND working group in the IETF had already recognized that DNSSEC was not
    appropriate in all situations, and that there was a demand for a lightweight
    (shared secret) alternative. Two complementary Internet-Drafts were
    published to satisfy this requirement: "Secret Key Transaction
    Authentication for DNS (TSIG)", and "Secret Key Establishment for DNS (TKEY

    TSIG and TKEY alone do not solve the key distribution problem inherent in
    any secret key system. However, both mechanisms allow for extension, which
    permitted us to publish a third complementary draft, "GSS Algorithm for TSIG
    (GSS-TSIG)". The GSS-API mechanism enables us to use integrated Windows
    security to solve the key distribution problem, and ensure our customers
    will have no additional key management burden associated with secure update.

    The GSS-TSIG draft has been available since November of 1997. Microsoft
    would be happy to assist any vendors who wish to develop an independent,
    interoperable implementation. We have already demonstrated GSS-API/Kerberos
    interoperability between Windows 2000 and other GSS/Kerberos implementations
    (see below for more information).

    The DNSEXT working group (a consolidation of the DNSIND and DNSSEC working
    groups) is currently working on an Internet-Draft to replace RFC 2137. This
    draft, called "Simple Secure Domain Name System (DNS) Dynamic Update",
    separates the authentication of an update from the later DNSSEC
    authentication of the data. The draft acknowledges the TSIG/TKEY method as
    a way to authenticate updates. When TSIG, TKEY, GSS-TSIG, and Simple Secure
    Dynamic Update reach standard status, there will be an IETF standard for DNS
    secure dynamic update.

    Microsoft is continuing to evaluate the viability of and demand for
    DNSSEC/public key-based security for DNS.

    Note especially the third paragraph from the end, where MS will gladly 'help' you write a standard :)
  • by trims ( 10010 ) on Thursday March 02, 2000 @07:19AM (#1230662) Homepage

    Actually, MS's implimentation interoperates to a certain degree with the reference MIT one. The difference that people are pointing out is that MS implimented one of the "optional" features that the reference implimentation doesn't.

    Now, this is good and bad. What it means is that MS clients can authorize to an MIT-based server's realm, and that UNIX clients can authorize to a MS-based realm, though you really need to run an MS server as the "native" realm for the MS clients, in order to have this extra field for the MS clients to use. I think they use it for something in Active Directory, but I'm not sure.

    It is MS being their usual "we work with them (almost)" self, but in this case, they're not hiding anything. They just happen to use more of the spec than the reference one.

    There's nothing keeping someone from taking the MIT software and adding the optional feature that MS uses. In fact, it's not hard to do (we once looked at doing exactly this). IASMOP (It's A Simple Matter Of Programming). The hitch is that you have an installed base that needs to be upgraded, which is kinda a bummer.

    And no, this isn't new. I found out about this almost 2 years ago.

    Nothing Evil about this, just annoying.


  • by coyote-san ( 38515 ) on Thursday March 02, 2000 @08:22AM (#1230663)
    A lot of people are reacting to MS's "breaking" yet another standard, and don't understand the real problem that MS is trying to solve.

    In a nutshell, Kerberos is a *network* authentication mechanism, not a system authentication mechanism. That means that when John Smith sits down at his terminal and acquires a Kerberos ticket, it's validated against a central site *with no cross-reference to local information.*

    In an ideal world, the principal name and local user name would be identical. The local system could then look up the principal name in its local user database and acquire user information from /etc/passwd and /etc/groups, or their local equivalents. In the real world, this isn't always possible but many sites use a (standard?) secondary mechanism that maps Kerberos principals to local user names, and again you acquire user information from /etc/passwd and /etc/group.

    Other alternatives are getting that information out of NIS, LDAP, etc., or Kerberos-enhanced versions of the same if they're paranoid about someone trying to spoof that information.

    (AFAIK) what MS did with W2Kerberos is put the equivalence of /etc/passwd and /etc/group information into the "authorization" field. That's unusual, but not inappropriate -- and arguably an elegant solution to the crippled NT environment.

    However, for reasons that make no sense to anyone in this reality they decided to digitally sign that information. From a security standpoint, this is utterly insane - Kerberos tickets already use strong encryption and session keys, so there's nothing to be gained by adding an additional layer of encryption to the payload. Furthermore, the KDC should be physically and electronically secured, so it should not be a significant risk to maintain unsigned user authority information on the KDC in plaintext. Assuming you don't simply colocate those services, of course!

    However, digitally signing that data and failing to disclose the details is an excellent way to control market share, if the user community doesn't rip their head off for this trick. In this case it's a possibility since the sites that use Kerberos are more security-aware than your average site, and they might not be willing to compromise their security by maintaining two realms (or worse, replacing their Unix KDCs with Windows KDCs).
  • by cybercuzco ( 100904 ) on Thursday March 02, 2000 @08:16AM (#1230664) Homepage Journal
    This is off topic, but did anyone else notice the unintentionally funny headline at BBC Sci/tech? It says "cannabis helps 'MS' sufferers" I of course, totally agree, If I used Windows I'd have to be smoking pot too ;-)

I've got a bad feeling about this.