From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Alexander Bokovoy To: mandrake-russian@altlinux.ru Message-ID: <20020211143107.GJ24412@sam-solutions.net> Mail-Followup-To: mandrake-russian@altlinux.ru References: <1013332505.20498.6.camel@COMP00-0603> <3C679B95.8060006@rmts.donpac.ru> <43611474.20020211140138@pub.tmb.ru> <3C67B164.6070607@rmts.donpac.ru> <514701523.20020211150947@pub.tmb.ru> <3C67B644.1000807@rmts.donpac.ru> <3C67CCF9.17FD96A0@altlinux.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C67CCF9.17FD96A0@altlinux.ru> Subject: [mdk-re] Re: Netmeeting for Linux? Sender: mandrake-russian-admin@altlinux.ru Errors-To: mandrake-russian-admin@altlinux.ru X-BeenThere: mandrake-russian@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: mandrake-russian@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: Linux-Mandrake RE / ALT Linux discussion list List-Unsubscribe: , List-Archive: Date: Mon Feb 11 17:32:03 2002 X-Original-Date: Mon, 11 Feb 2002 16:31:07 +0200 Archived-At: List-Archive: List-Post: 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 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