Netware/Novell

From Techrights

(Difference between revisions)
Jump to: navigation, search
Current revision (01:23, 1 December 2009) (view source)
 
(25 intermediate revisions not shown.)
Line 1: Line 1:
 +
[[Category:Comes v Microsoft]]
 +
[[Category:Antitrust]]
 +
[[Category:Microsoft]]
 +
[[Category:Novell]]
 +
[[Category:Netware]]
 +
[[Category:Network]]
 +
This index deals with [[Comes vs Microsoft]] court exhibits which offer a glance at the history of Microsoft abuse. For a concise summary of some of the exhibits, see "[[Petition text - overview]]".
 +
 +
=== Relationship ===
 +
* [[The Netware Microsoft relationship]] (Exhibit PX07689)
* [[The Netware Microsoft relationship]] (Exhibit PX07689)
 +
* [[Microsoft access to Novell’s SuperLab]] (Exhibit PX02208)
 +
* [[Win95 Logo program requirements and Novell]] (Exhibit PX02250)
 +
* [[Novell interface guidelines]] (Exhibit PX02839)
 +
 +
=== Sabotage ===
 +
* [[Novell: Microsoft refused to fix bugs]] (Exhibit PX02350)
* [[Novell: Microsoft refused to fix bugs]] (Exhibit PX02350)
* [[Novell to Microsoft: help MAPI has stopped working]] (Exhibit PX02365)
* [[Novell to Microsoft: help MAPI has stopped working]] (Exhibit PX02365)
-
* [[Microsoft access to Novell’s SuperLab]] (Exhibit PX02208)
 
* [[Making Microsoft MAPI not work with GroupWise]] (Exhibit PX02685)
* [[Making Microsoft MAPI not work with GroupWise]] (Exhibit PX02685)
-
 
+
* [[Microsoft's Allchin: we need to slaughter Novell]] (Exhibit PX00948)
-
 
+
* [[Novell: where have the header files gone]] (Exhibit PX02365)
-
* [[Deferred use of DR-DOS]] (Exhibit PX00033)
+
-
* [[Comparing MS-DOS and DR-DOS]] (Exhibit PX00034_A)
+
* [[The way to shut out Novell]] (Exhibit PX04293)
* [[The way to shut out Novell]] (Exhibit PX04293)
-
* [[Microsoft claims that NDS on NT is reverse engineered]] (Exhibit PX02827)
+
* [[Yet more undocumented API calls]] (Exhibit PX02667)
-
* [[]] (Exhibit )
+
* [[Making Outlook not work with GroupWise]] (Exhibit PX02921)
-
* [[]] (Exhibit )
+
-
* [[]] (Exhibit )
+
-
* [[]] (Exhibit )
+
-
* [[]] (Exhibit )
+
-
* [[]] (Exhibit )
+
 +
Some of this material is also covered (with commentary) in: http://boycottnovell.com/2007/03/19/novell-iowa-antitrust/
 +
Also see parts of the documents in: http://boycottnovell.com/2007/04/22/brad-silverberg-no-no/
-
== NDS lies propagated by MS ==
+
=== DR-DOS ===
-
From: Gary Hein
+
* [[Deferred use of DR-DOS]] (Exhibit PX00033)
-
Date: Sat, May 30, 1998 3:34 PM
+
* [[Comparing MS-DOS and DR-DOS]] (Exhibit PX00034_A)
-
Subject." Fwd: ND$ for NT / LDS Church
+
-
:Don’t know if you guys have seen this document yet, but it’s just another example of lies propagated by MS. There are some very disturbing remarks, including:
+
=== WordPerfect ===
-
:Although it is possible to establish bi-directional trust, the trust connection can not be used for administering remote, unmigrated domains. This means that centralizing management with NDS for NT requires a wholesale conversion of the entire enterprise
+
* [[Blasted for APIs document]] (Exhibit 1614)
 +
* [[Athena and shell extension]] (Exhibit 2383)
-
:GH: False
+
=== NDS ===
-
:Note that NT servers would need to run IPX/SPX to support NDS for NT as well as TCP/IP to access other network resources and to comply with current standards.
+
* [[Microsoft claims that NDS on NT is reverse engineered]] (Exhibit PX02827)
-
 
+
* [[NDS lies propagated by Microsoft]] (Exhibit PX02913)
-
:GH: False - NDS for NT works over IP - no need to add IPX. This is a scare tactic.
+
* [[NDS on NT - Microsoft's Story]] (Exhibit PX02827)
-
 
+
* [[Microsoft propagates lies about NDS ]] (Exhibit PX02913)
-
:Service Pack updates are questionable at best. MCS has not yet released Service Pack 4.0, however we suspect it will replace the existing samsvr.dll. To protect against NT Service Packs replacing samsrv.dll, NDS for NT checks at shutdown time and replaces samsrv.dll with the Novell version. MCS believes potential for failure is very high, as soon as any rill starts depending on new exports from samsrv.dll. Replacing this one critical dll could case the system to fail to boot and recovery could be very difficult.
+
-
 
+
-
:GH: Perhaps advance knowledge of SP4?
+
-
 
+
-
:Microsoft has repeatedly stated that it will support their NT customers and NT’s basic functionality, but in areas that NDS touches, namely security and authentication, Microsoft will refer customers to Novell. This has the potential of creating some confusion in the resolution of issues revolving around security and authentication.
+
-
 
+
-
:GH: Scare tactic
+
-
 
+
-
:Also, comments from PeopleSoft should be solicited to see if PeopleSoft and Tuxedo are supported in environments where NDS for NT is in use as well as the IntranetWare client.
+
-
 
+
-
:GH: Is it possible that MS is telling NT developer that they should not support their products with NDS for NT?
+
-
 
+
-
:Windows NT has a feature where anonymous Iogon users can list domain user names and enumerate share names. Customers who wanted enhanced security requested the ability to optionally restrict this functionality. Windows NT 4.0 Service Pack 3 and a hotfix for Windows NT 3.51 provide a mechanism for administrators to restrict the ability for anonymous logon users from obtaining system information. These anonymous connections are also known as NULL session connections. During the installation of Novell’s NDS for NT, the samsrv.dll is replaced. Novell NDS for NT currently does not include support for restricting anonymous connections. MC£ see this deficiency as a security weakness.
+
-
 
+
-
:GH: This is the Red Button attack, which MS ’claims’ is fixed with SP3, but really isn’t. Again, this is completely incorrect - using NDS for NT will not impact the security flaw mentioned in this document.
+
-
 
+
-
:Anyhow - I don’t know if this is of any use to you but I thought I’d forward it over anyway. Thanks,
+
-
 
+
-
:Gary
+
-
 
+
-
From: Loren Bishop <BishopLK@chq.byu.edu>
+
-
To: HUB-OREM .SLC(BRICHAN)
+
-
Date: Wed, May 27, 1998 7:52 AM
+
-
Subject: Fwd: NDS for NT
+
-
 
+
-
: Here is the document from Microsoft Consulting Services. We need a similar document from Novell. Please keep this confidential. I don’t know that Microsoft would appreciate me sharing it with you.
+
-
 
+
-
From: Eugene Morgan <emorgan@microsoft.com>
+
-
To: "Kenji Suzuki (E-mail)" <ksuzuki@chqbyu.edu>, "’b...
+
-
Date: Thu, May21, 1998 4:43 PM
+
-
Subject: NDS for NT
+
-
 
+
-
: Attach is the final version of the document that addresses NDS for NT. If you have any questions please call me.
+
-
 
+
-
<<NDSForNTConcems.wpd>>
+
-
 
+
-
Eugene Morgan
+
-
Microsoft Consulting Services
+
-
Rocky Mountain District
+
-
(801) 540-4907
+
-
 
+
-
: CONFIDENTIAL
+
-
 
+
-
The Church of Jesus Christ of Latter-day Saints
+
-
 
+
-
NDS for NT:
+
-
Microsoft’s Consulting Services
+
-
Concerns
+
-
 
+
-
Prepared By:
+
-
Eugene Morgan
+
-
Microsoft Consulting Services
+
-
May 1998
+
-
Document Version 1.2
+
-
 
+
-
..
+
-
 
+
-
NDS for NT - MCS Concerns
+
-
NDS for NT
+
-
Microsoft Consulting Services Concerns
+
-
 
+
-
1.1 Introduction
+
-
 
+
-
 
+
-
: As the Church contemplates the deployment of NDS for NT there are some things to consider. There has been some questions about NDS for NT directed to Microsoft Consulting Services regarding NDS for NT from Novell. This document will hopefully articulate our concerns with regard to this product.
+
-
 
+
-
..
+
-
 
+
-
1.4 Concerns With NDS for NT
+
-
 
+
-
 
+
-
: Microsoft has published a number of documents on NDS for NT, unfortunately most are internal and not available to the public. In addition, there has been a considerable amount of discussion on the various e-mail aliases within Microsoft. The following represents a distillation of the various documents and discussions and enumerated what MCS feels are areas of concern.
+
-
 
+
-
1.4.1 Administration
+
-
 
+
-
: Multiple tools for administration due to missing functionality. Novell’s NWAdmin does not give access to the full set of Windows NT security capabilities; in particular, there is no way to manage trust links with external (unmigrated) domains, and no way to manage local policies. The administrator uses NWAdmin for most tasks, but must use User Manager and Server manager for trust and local policy management.
+
-
 
+
-
: Although it is possible to establish hi-directional trust, the trust connection can not be used for admirlistering remote, unmigrated domains. This means that centralizing management with NDS for NT requires a wholesale conversion of the entire enterprise.
+
-
 
+
-
Password synchronization: Since NDS for NT must support all Windows NT clients, not just Windows NT clients with the IntranetWare client installed, Novell must maintain two passwords for every user: a Windows NT password and an NDS password. From Novell’s own announcement documents it is clear that this is a compromise solution that is far from transparent to the user. It important to point out that it is possible for the passwords to get out of sync. This could cause additional problems for uses as well as the Help Desk and other operational teams supporting the Utility.
+
-
 
+
-
ACL (Access Control List) confusion: In the case of a single NDS user being granted access to multiple domains, the same user, "BobSmith" would appear in the context of each "trusted domain" selected. A Windows NT ACL could have entries for Domainl\BobSmith, Domain2\BobSmith, and Domain3\BobSmith. All three are in fact the same user, but with different SlDs (NT Security ID’s).
+
-
 
+
-
: Also, in NDS for NT it is possible to create case-sensitive account names, for example "bsmith" and "BSmith". Because NT is not case sensitive for user names only one of the accounts would be accessible even though both would exist within NDS for NT. This could be a security issue and would also be confusing to administrators and others managing user accounts and of course customers.
+
-
 
+
-
: NDS for NT - MCS Concerns
+
-
 
+
-
: Multiple group paradigms: Windows NT Groups are not NDS groups. To make a group visible in Windows NT the administrator must create an IWSam group as a child of a domain object. Only users can be added to IWSam groups.
+
-
 
+
-
: No immediately obvious scripting support: ADSl supports NDS, but ADSI does not expose the SlD, password residue, and other items required to migrate a Windows NT domain to NDS. This means the migration process is via the user interface, and the current user interface makes this quite laborious.
+
-
 
+
-
1.4.2 Disaster Recover
+
-
 
+
-
: MCS is concerned with the effects NDS for NT has on recoverability in the case of a system failure. Because NDS for NT moves all of the directory information from the registry to the NetWare Directory, if the NT Primary Domain Controller fails, the following steps would be necessary to recover.
+
-
 
+
-
: Do a reverse migrate to all the BDCs in the Domain.
+
-
 
+
-
: Promote one ofthe BDCs to a PDC.
+
-
 
+
-
: Reinstall and restore the original PDC as a BDC and restore files and applications.
+
-
 
+
-
: Promote the restored BDC back to a PDC.
+
-
 
+
-
: Reinstall NDS for NT on the PDC and each BDC in the domain.
+
-
 
+
-
: This process seems rather involved and would cause a severe interruption of services and applications hosted on NT. It’s important to point out that some of these applications are mission critical, PeopleSoft for example. Furthermore, if any NT backup domain controllers are located remotely to facilitate faster WAN login and lower WAN traffic, as in the case of England and Australia, this becomes an even more complex process. (Note: Novell has said that they will have a fix for this at some point.)
+
-
 
+
-
: MCS offers the following disaster recovery advice; prior to implementing NDS for NT thoroughly test the above scenario and ulxtate the disaster recovery plan on how to recover in the advent of a failure.
+
-
 
+
-
1.4.3 Scalability
+
-
 
+
-
: MCS has not heard of any large implementations of NDS for NT. Considering what it takes to architect a large NDS implementation, MCS questions what effects NDS for NT will have on the existing NDS infrastructure. MCS would suggest interviewing early adopters of NDS for NT prior to implementing NDS for NT. Furthermore, it would be important to understand the impact of NDS on NT would have on the existing NDS servers and supporting network infrastructure. Note that NT servers would need to run IPX/SPX to support NDS for NT as well as TCP/IP to access other network resources and to comply with current standards.
+
-
 
+
-
: NDS has partitioning requirements to keep from overloading its database as well as replication limitations. The NDS data is threaded through several files, remarkably similar to the file structure used by Microsoft directory service prior to moving NT’s directory to utilize the JET database engine in 1991. Our concern is that the duplication of objects in the NDS directory will impact performance significantly for all NDS authenticated users.
+
-
 
+
-
: It’s also our understanding that in NDS for NT there is a limited one to one relationship between an NDS container and a Domain. Therefore if an enterprise has users spread across multiple NDS containers it may be necessary to implement separate NT domains that are related to the respective NDS containers.
+
-
 
+
-
: With NDS for NT, NT domains become NDS groups. It is MCS’s understanding, based on Novell recommendation that NDS groups should not have more than 2000 members. This does raise the question about the scalability of NDS for NT. Will this group limitation be an issue for the Church?
+
-
 
+
-
: Given that NDS for NT converts NT domains to NDS groupsl it is recommended that interdependence between these NDS groups be tested in order to ascertain that the necessary relationships exists between these NDS created groups.
+
-
 
+
-
: As the Church begins to develop large applications, the Church my find it reasonable or necessary to deploy NT on Alpha systems in a effort to scale an application to meet demand. There is no support for NDS for NT on Alpha NT servers. Novell has indicated this is, "a hard problem" and has offered no guarantees and little hope that it will be addressed in the future.
+
-
 
+
-
1.4.4 Upgrade and Update Capability
+
-
 
+
-
..
+
-
 
+
-
: At a recent Novell event, Brain Share1, a demonstration of NDS for NT was given. It was observed that at that demonstration it took 35 seconds for a user to log on against a (presumably) unloaded server in a tree with under ten users. This, naturally, raises concerns about speed and response time, not only for user authentication but also for any application that requires NT authentication.
+
-
 
+
-
1.4.6 Reliability
+
-
 
+
-
: In order to install NDS for NT it is necessary to install the IntranetWare Client. Based on past performance, Microsoft does not recommend the IntranetWare Client for installation on servers, especially servers that also host mission critical applications. MCS feels this is a high risk and should be considered carefully. It’s also important to know that there are issues with using TCP/IP with Novell’s current IntranetWare client. This is one of the main reasons the Church has had to maintain its dependence on IPX/SPX.
+
-
 
+
-
: It will also be necessary to retest any NT server based applications that runs on NT for reliability. CQH will need to be tested; DHCP, WINS, and DNS services will all need to be tested.
+
-
 
+
-
: Also, comments from PeopleSoft should be solicited to see if PeopleSoft and Tuxedo are supported in environments where NDS for NT is in use as well as the IntranetWare client.
+
-
 
+
-
1.4.7 Security
+
-
 
+
-
: What are the implications of calls that used to go between the samsvr.dll and the registry now being redirected across the network? Do the passwords retain their encrypted state that they were originally transmitted in? If they are encrypted, is that encryption secure?
+
-
 
+
-
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02913.pdf
+
-
 
+
-
 
+
-
== we need to slaughter Novell .. ==
+
-
 
+
-
From: jimall Mon Sep 9 11:09:33 1991
+
-
To: billg steveb
+
-
Cc: bradsi; jonl; mikemur; paulma
+
-
Subject winball
+
-
Date: Mon Sep 09 11:08:44 PDT 1991
+
-
 
+
-
 
+
-
The news on the street continues to confirm the IBM and Novell announcements this week. DRDOS 6, Novell bundling, SLRP, and IBM reselling DRDOS are the words. Still no real data on the details.
+
-
 
+
-
MS Response:
+
-
 
+
-
1. repackage DOS for PS/2's
+
-
 
+
-
2. integrate Windows with DOS, Common install. Make it so that there is no reason to try DRDOS to get Windows.
+
-
 
+
-
This is much more important than 1, given the OEM deals that Novell will try to do for DRDOS on the clone machines.
+
-
 
+
-
3. integrate winball with Windows 3.1
+
-
 
+
-
..
+
-
 
+
-
 
+
-
We must slow down Novell. The strongest action that we could take would be to include networking with Windows for essentially a zero uplift in price (maybe minor COGS uplift). As you said Bill, it has to be dramatic.
+
-
 
+
-
..
+
-
 
+
-
We need to slaughter Novell before they get stronger.
+
-
 
+
-
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/0000/PX00948.pdf
+
-
--
+
-
 
+
-
 
+
-
synopsis: Integrate Windows with DOS to slaughter DR-DOS on the non IBM desktop. Repackage DOS for PS/2's ..
+
-
 
+
-
What's the reference to 'DOS for PS/2', I thought OS/2 was still the next generation OS. Given the mutually contradictory statements coming out of these emails, I don't think it was only MS pre-announcing vapourware to throw off the other fella and freeze the market, as not actually having a long term strategy of their own.
+
-
Having spotted the next great threat, the typical reaction, and it always was a reaction, was to pre-announce a me-too product that would super-set the current enemies version of whatever. Then 'partner' with the company, at the same time lean on everyone else not to do business with them and quietly FUD their product. Eventually 'merge' with the company and buy the stock at rock bottom.
+
=== Linux/UNIX ===
-
--
+
* [[Contain the UNIX threat - "We should make sure the Unix focus includes Linux"]] (Exhibit px03036)
-
court documents in the case of Comes v. Microsoft.
+
Also see (2009): [http://www.groklaw.net/article.php?story=20091124122912739 The 158 Exhibits Attached to Novell's Response to MS's Cross Motion for SJ in Antitrust Suit]

Current revision

This index deals with Comes vs Microsoft court exhibits which offer a glance at the history of Microsoft abuse. For a concise summary of some of the exhibits, see "Petition text - overview".

Contents

Relationship

Sabotage

Some of this material is also covered (with commentary) in: http://boycottnovell.com/2007/03/19/novell-iowa-antitrust/

Also see parts of the documents in: http://boycottnovell.com/2007/04/22/brad-silverberg-no-no/

DR-DOS

WordPerfect

NDS

Linux/UNIX

Also see (2009): The 158 Exhibits Attached to Novell's Response to MS's Cross Motion for SJ in Antitrust Suit

Personal tools
Search entire domain
Stories