[mdk-re] Re: Netmeeting for Linux?

Пн Фев 11 17:32:03 MSK 2002

On Mon, Feb 11, 2002 at 04:54:01PM +0300, Aleksey Novodvorsky wrote:
> John wrote:
> 
> > >
> > >Неделю-две назад обсуждались варианты аналогов Exchange под Linux.
> > >Посмотрите в архиве рассылки.
> > >
> > Посмотрел, ни до чего хорошего там не договорились
> 
> К сожалению, это отражает положение дел со свободными  серверами Groupware.
Вот цитата из обещанного и упомянутого в начале января письма Люка,
скандально известного разработчика Samba-TNG. Несмотря на его
ярковыраженное самолюбование, он вполне объективно оценивает деятельность
Микрософт в технологическом плане и то, почему же не удается создать
"свободные сервера Groupware". Я подредактировал текст письма, поскольку
Люк не стеснялся в выражениях по поводу и без и убрал все упоминания о
контексте, в рамках которого возникло это письмо. Пусть это будет так.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-==-=-=--=-=-===--=-=-=
From: Luke Kenneth Casson Leighton <lkcl на samba-tng.org>
Subject: Re: Urgent: Need info about cooperation with Microsoft

[..]
 i have provided these explanations, and then the answers.

 additionally, the focus of your enquiry should be extended
 to much more than SAMBA.  it should be extended to DCOM,
 DCE/RPC, Exchange, SQL, Kerberos-5, LDAP, BackOffice,
 Visual Basic, file formats of all microsoft documents of
 all microsoft programs, NetMeeting, dotNET, Microsoft Project,
 Money, Works...

 anything that is likely to become, or _has_ become, due
 to having been very well designed [and for the most part
 well implemented], critical day-to-day computing
 infrastructure.

 i also include some additional comments, which i hope will
 allow you to realise quite how important the underlying
 infrastructure is, on which all of the "visible" programs
 that everyone sees - and therefore misleadingly focusses upon.

 microsoft is jumping up and down in glee at having won a
 court-case that didn't even MENTION _the_ most important
 technology they have developed, the successful hiding and
 use of which is stifling competition.

[..]

so, modifying your question to, "Samba 3.0 will support
Windows 2000 ActiveDirectory / Kerberos-5 Domains...":

this is a massive undertaking spanning at least ten separate protocols.

those that i can think of immediately are:

- NetBIOS

- SMB

- NamedPipes

- DCE/RPC

- DCE/RPC support services (NETLOGON + LSA)

- NTLMSSP (authentication and encryption algorithms & implementation)

- Kerberos 5 *plus* Krb-5 security modifications (talk to assar,
  from the heimdal group)

- LDAP *plus* security modifications (talk to luke howard)

the management APIs involved in replication, browsing of
account information etc are NOT included in this list.

[..]

i'm the person that's been responsible for the NamedPipes,
DCE/RPC support, DCE/RPC services, NTLMSSP etc. that are
essential to providing Windows NT 4.0 Domains and furthermore
is still essential as support to Windows 2000 Domains.

this work, documented and described in the book "DCE/RPC
over SMB: Samba and Windows NT Domain Internals", ISBN
1578701503 by MTP (New Riders Group), which i lead over a
period of four years, took approximately six to seven man-years.

this work ***ASSISTED*** microsoft due to my having produced
at least twenty critical security audit reports related to
Windows NT 4.0 Domain Services, including reproduction
programs in order that microsoft could reproduce the critical
fault and then fix it.

quite often, the work involved weeks or even months of
network analysis, to find a problem that must have been there
since the introduction of Windows NT 3.1 and 3.51 in 1991,
at least seven or eight years beforehand, that could have
been exploited AT ANY TIME by unscrupulous individuals in
order to break into any Windows NT Domain network, world-wide.

AT NO TIME, having found the problem, was anyone OUTSIDE of
microsoft consulted, to the best of my knowledge, regarding
the fix _to_ the problem.

as a result, having had to follow EC Directive EC250/90,
i then AGAIN had to follow this same directive in order
to find out - AFTER release [i.e. up to 1 or 2 years later] -
what the fix was.

[..]

there was only one instance of assistance / documentation
received from microsoft, and i am not at liberty to reveal
who.  the information, which saved two months of intensive
time, was released to us in microsoft's own interests because
they were having internal security problems, and needed
to upgrade.

naturally, they couldn't very well upgrade SAMBA themselves,
so released a document to me and a few other critical
third party CIFS / SMB vendors.  THAT IS ALL.

[..]

>   * How good is interoperation between SAMBA and Exchange 2000?

 explanation [answer follows below]

 Exchange 2000 is a DCE/RPC Service.

 SAMBA contains a proprietary, minimalist implementation of
 DCE/RPC.

 proprietary in the sense that it dominates the TCP ports
 [139 and 445] that provides an Authenticated Transport for
 DCE/RPC (NamedPipes).

 because of this, no other DCE/RPC implementation may
 interoperate at the same time as SAMBA.

[..]
 The interoperability between SAMBA TNG and Exchange 2000
 will be very good.

 ***IF*** we can get the specifications from Microsoft
 for MAPI and the DCE/RPC services.

 ***IF*** someone will pay money to have it developed,
 open source.

 i estimate that it will take 18 full man-months to reverse-
 engineer MAPI and the Exchange DCE/RPC Services necessary
 to provide Exchange 5 and Exchange 2000 compatibility at
 a ***BASIC*** level.

>   * In case there are some gaps in interoperability: Why? What would
>     you need in order to close them?

 - IDL files for:

	NT Domain Support

 	NETLOGON
	lsa
	spoolss
	samr
	svcctl
	browsess
	srvsvc
	wkssvc
	winreg

	Exchange 5/2000 Support at least 5 IDL files:

	nspi
	drs
	dri
	unnamed (x-400-like?)
	unnamed (exchange admin / management)

	SQL 7/2000 Support at least 2 IDL files:

	ms-sql (?)
	sql-admin (?)

 - Documentation for the above!  and that doesn't mean
   my book, ISBN 1578701503.

 - NTLMSSP specification (including NTLM v1 _and_ v2)

 - NETLOGON Secure Channel specification

 - Password Changing and Encryption Algorithms

 	- Win95
	- NT (over samr)
	- 2000 (over samr, in SamrChangeUserPassword *)
	- 2000 (Active Directory's password field encryption is not documented)

	[* need info for NTLMSSP v1, _and_ v2, _and_ the
	  security update implemented in Windows 2000 Service
	  Pack 2, which i helped alert microsoft to what the
	  problem was!)]

>   * Is there anything else Microsoft did in order to help or hinder
>     you to write software which is fully interoperable with Windows?

  here we go.

  one part of the answer:

  paul leach, where not constrained by lack of time plus 
  contractual obligations to his employer, was very helpful.

  second part of the answer requires an explanation first:

  you are aware of "The Halloween Documents"?

  the effects of the strategies outlined in these documents is
  far more successful than anyone realises.

  what microsoft has done is to develop some *extremely* good
  software, an incredible, incredible feat of engineering.  very
  few people realise quite how astoundingly well designed the
  Windows NT Domains Architecture is [and that INCLUDES microsoft:
  very few people inside MICROSOFT realise how good it is, as
  we are witnessing today with the continued security failures
  in Windows XP].

  the implementation time for the first version of this software,
  known as Windows NT, was 4.5 years, with 7 people, at 3.5 million
  lines of code.  this became the backbone / core services -
  a foundation, upon which further software and services could be
  reliably built.

  some of those services were older services ported and upgraded
  to Windows NT.  for example, CIFS, NamedPipes, and DCE/RPC.

  basically what i am saying is that microsoft's core services,
  which have taken ten to fifteen physical years and approximately
  one man CENTURY to develop, are LAYERED AT LEAST IN FIVE LEVELS
  OF DEPENDENCY.

  so the strategy outlined in the halloween documents,
  to "keep proprietary and keep quiet and get 2 years ahead",
  is successful AT LEAST FIVE TIMES OVER.

  let's take an example.

  to implement Exchange 2000, you first need:

  - NTLMSSP authentication (tied in to NT Domains) (6 months)
  - MAPI (1 year)
  - DCE/RPC (2 - 5 years)

  to implement NT Domains, required above, you need:

  - DCE/RPC over NamedPipes (tied in to SMB) (1 year)
  - samr (6months excluding reverse-engineering time)
  - lsa (6months excluding reverse-engineering time)
  - netlogon (1 year excluding reverse-engineering time)
  - srvsvc (3 months excluding reverse-engineering time)
  - wkssvc (1 month excluding reverse-engineering time)

  to implement SMB, required above, you need:

  - a NetBIOS implementation (ports 137,138 and 139 and 445)
  - an SMB file server (_at least_ 5 man-years)
  - a NetBIOS Browsing Client / Server (2 years)

  to implement NetBIOS, you need:
  - rfc1001 and rfc1002 (1 year)

  you get the picture?

  the levels of dependency drill down.

  the story is the same for DCOM and also for SQL as it is
  for Exchange: without these dependencies met, you will get
  NOWHERE.

  and i haven't even added in Active Directory / Kerberos 5
  [part of Windows 2000 Domains]!

  second part of the answer:

  with this explanation in mind, you can see that there is
  someone, somewhere inside microsoft, who has been responsible
  for this "strategic business initiative".

  find them for me.

[..]

  The current EU case is focussing - AGAIN - on browsers and
  multimedia programs.

  these are TOTALLY IRRELEVANT.  the APIs published in the MSDN
  by microsoft are published for good reasons: they provide
  a layer of independence, allowing microsoft the freedom to
  change, advance and enhance the underlying implementation.

  however, i am fully aware that microsoft has a practice of
  occasionally adding to or carefully bypassing the published
  APIs for speed and functionality purposes and then NOT
  informing competitors.

  a classic example of this was the addition in NT 4.0 SP2 of
  an undocumented API for cleaning up the NTFS file system.
  this was added for the benefit of ONE VENDOR who wished to
  provide an NTFS defragmenter program.  NOONE ELSE was
  informed of this API.  see http://sysinternals.com web site
  (i think) for more details.

  publication of internal APIs needs to be done with some care,
  but it IS necessary.  there are risks that a major third
  party program may use an API that later changes or is removed
  at microsoft's discretion, resulting in support calls _to microsoft_
  wasting _their_ time and money telling the individual to go
  back to their third party supplier.  _that_ isn't fair.

  ... however, neither is the practice of witholding information
  such that no-one _at all_ may interoperate other than selected
  parties, whether themselves - microsoft internally - or other
  corporations with money or other arm-twisting tactics to pay
  for the privilege.

  an example of a good arm-twisting tactic is Novell.  Microsoft
  was dependent upon Novell for file serving up until around...
  1997, plus-or-minus 18 months.  microsoft needed Novell
  support, so microsoft gave them sufficient information to
  get microsoft where they needed to be [with a good file server!].
  when they could replace the fileservers with NT, they stopped
  talking to Novell...

  another example is Network Appliances.  Network Appliances
  do combined NFS and SMB/CIFS massive terabyte fileservers.
  THIS IS SPECULATION: they had a customer with several thousand
  Unix [solaris?] servers - probably in the region of five to
  ten thousand.  they were in the process of replacing these
  with NT.

  the customer purchased a Network Applicance dual NFS / SMB
  server in order to have their users migrate and still access
  the same files, from unix workstations to nt workstations.
  this customer was having difficulty due to the size of their
  install-base with password migration and other issues, due
  to Network Appliances not having access to Microsoft
  NT Domains Technology, like everyone else.

  the customer, after a short conversation with Network Appliance
  technical gurus, got on the phone to microsoft, with the
  full intention of telling them where to stuff their 10,000
  Windows NT and Exchange / Outlook Licenses.

  microsoft, after doing some quick mathematics... GAVE NETWORK
  APPLIANCES THE NT DOMAIN IDL FILES.

  can anyone else do math?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-
-- 
/ Alexander Bokovoy
Software architect and analyst             // SaM-Solutions Ltd.
---
"Don't talk to me about disclaimers!  I invented disclaimers!"
-- The Censored Hacker