On Wed, 27 Mar 2002 10:54:25 -0800, Larry Osterman wrote: > IMHO, the only reason for an open source server running on W2K to NOT > support NTLM authentication is bigotry - the SSPI APIs needed to support > NTLM are pretty simple to support and are well documented.
Larry - He didn't say "running on W2K". There are many other reasons than bigotry for an open source server not to support NTLM. The chief reason is that, AFAIK, there is no RFC which documents AUTH=NTLM. If Microsoft is serious about wanting open source software to support NTLM, it would open the NTLM specification and publish it as an RFC. Meaning, of course, that Microsoft gives up control and ownership of NTLM. Without an RFC documented AUTH=NTLM, NTLM is a vendor-specific, unsupported and unsupportable mechanism. And no, various versions of reversed-engineered C code to do NTLM floating around do not address the issue. Of course, if you are really determined that open source support NTLM without Microsoft providing an RFC, then an RFC could be written by myself or someone else. Microsoft would get a chance to review it, but that document, written outside Microsoft, would now be the standard for NTLM and any deviation between that document and Microsoft's code (and there will be deviations because we are fallable human beings) would render Microsoft non-compliant with its own NTLM! OK, enough for the absurd. I think that you get my point. I think that most of us agree that NTLM should be allowed to die in peace. It's Microsoft's proprietary authentication mechanism. Nobody wants to take it away from Microsoft. On the other hand, as such, you can't claim that lack of support for NTLM is due to "bigotry." We're both in a situation that we both want to get out of. The correct outcome is for us both to move towards open authentication mechanisms and away from vendor-proprietary mechanisms. I don't know why Microsoft doesn't support CRAM-MD5 or Kerberos in its clients; CRAM-MD5 in particular is trivial to implement. I hope that Microsoft will in a future version. -- Mark --
