Netware/Novell

From Techrights

(Difference between revisions)
Jump to: navigation, search
(→MS access to Novell’s SuperLab)
(→we need to slaughter Novell)
Line 6: Line 6:
-
== the Netware Microsoft relationship .. ==
+
== 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
 +
 +
== the Netware Microsoft relationship .. ==

Revision as of 14:20, 16 January 2009




Contents

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

the Netware Microsoft relationship ..

To: Jan Newman From: Bob Ross Date: 8/17/93

RE: The Novell/Microsoft Relationship with regards to the developement of a NetWare Client for Windows NT ..

When we received the build, we recompiled our code and found that it would not work. We found that some changes were made to the redirector interfaces and the structure and that significant changes were made to to TDI interface. We had to discover each of the changes for our selves and then call Microsoft and point out where it had changed in order to receive each of the pieces of information from them .. This process tool a great deal of time. We lost almost 2 months of development time on the FCS release from this ..

Build 473 did not arrive when promised, but rather came to us about 3 weeks late (and 1 week after the production disk went to developers from Microsoft). The promised documentation that would explain what had been changed in this build consisted of a list of E-Mail messages between Microsoft engineers ..

Monday July 26, 1993 Microsoft went to manufacturing with the golden version of Windows NT .. We were told that our copy should arrive no later than Thursday 7/29

Friday July 30, 1993 Microsoft said that our developer copy had just gone out.

Tuesday August 3, 1993 We received our copy today, more than a week after it had been sent to customers. Microsoft told us that the delay was because the development code .. no longer fit on a single CD-ROM disk and it took them more time to work out compressing it ...

comes v Microsoft http://iowa.gotthefacts.org/011607/7000/PX07689.pdf

Novell: MS refused to fix bugs

Novell Confidential No 6665

Product and Price Change Notification

Attached a copy of the standard business and financial plans.

Originator: John Bodine Ext: 2.7082 Mailstop: ORM D-167

Type of change

X Other Patch Disk

FCS Date 7/10/95

..

Patch Disk for WordPerfect and PerfectOffice

The Windows Product Marketing team, in conjunction with developement has decided to produce a and distribute a "patch" disk for both PerfectOffice and WordPerfect 6.1 for Windows. To reiterate, the reason we have decided to produce a patch is to address two main concerns:
1) Win95 compatibility
2) High priority bugs
It should be noted that these bugs, for the most part, are not problems with our software (the Win95 bugs are problems we addressed with Microsoft which they refused to fix). In both cases, the patch will be limited to one diskette.
These patch disks provide updates to WordPerfect 6.1, Presentations 3.0, and the PerfectOffice 3.0 Desktop Application Director (in the PexfectFit directory). The patch disks address key complaints that technical services and large accounts are currently receiving, such as memory leaks, Support of DOS in a network environment (DuPont, 100,000 users), ODMA problems, temp files eating up hard disk space, problems with styles, DDE link problems, and printing problems with Presentations.
In addition some known problems with running PerfectOffice 3.0 on Windows 95 have been addressed such as prompting for network ID when opened, bad title bar display, Show Me problems with Coaches, and Grammatik GPF’s.
The time line for completion of the patch disks are as follows:
6/27 - Gold master candidate released to testing-testing continues throughout weekend
7/5 - First Article candidate released to MFG.
7/6 - Manufacturing to begin duplicating disks
The disks will be available for download off our Novell home page and over our electronic bulletin board services. The disk will also be available directly, via our 800 numbers. The disks are sent out free of charge.
Total cost for this project: $11,500.00

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02350.pdf

Novell to MS: help MAPI has stopped working

From: Richard Jones To : Internet : yvesm@microsoft. com Date: 7/21/95 9:48am subject: A couple of issues

Hi Yves,
I wanted to check that you received our Alpha 11 CD early last week. I checked with our Beta administrator and it was sent to John Ludwig.
I have one issue that was escalated to me by our messaging group concerning MAPI. Here is the message:
"My MAPI service providers that used to work in the M7 time frame (January beta) no longer seem to work. Can we get documentation on the changes that have been made to the SPls (especially transport and address book) since M7.
Thanks,
Bruce Greerublatt
Bruce had sent this request almost a month ago to NOVSUP and has received no response. Could you help us out please?
If there are any issues you need resolved with us, please let us know.
BTW: any more news on us getting a beta copy of "Maple’? Thanks,
Richard Jones
cc: Internet:johnlu@microsoft.com,Ben Hendrick, Bruce ...

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02365.pdf

MS access to Novell’s SuperLab

To: WPCORPP1.CORP.DUFF,Fortune.SJF-MAL2.DONE From: Dav Miller CC: WPCORPP1.CORP.TYMATT,WPCORP1 .CORP.RKING.Fortune.SJF-MAIL2. Dave Subject: More on Agenda for Microsoft meetng Date Thursday, January 5, 1996 6:10 AM

Duff, Don
I am working with Microsoft on finalizing an agenda for the meeting between Bill G. and Bob on January 10th. (Cindy Parsay is working on an actual time but does not have one at this point. At this point, the agenda is the same as the proposal I sent out before the holidays. They have agreed to it as well It is the following:
I. NetWare client bundle with Windows95
Pertinent issues for Discussion
- Novell has delivered a draft of a license agreement
- Microsoft’s position is to continue development of NCP compatible services. Will not agree to the contract if it means they stop NCP services development.

..

- Microsoft would like cooperative product testing, access to Novell’s SuperLab for Win95 testing.
Note: They would like to test their NCP server and client efforts.
Please provide me with input to help finalize an agenda. If there is anything that you feel should be added please let me know as soon as possible.
- Dave -

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02208.pdf

making MS MAPI not work with GroupWise

From: David Raissipour <DavidRa @Exchange.Microsoft com> To: Bill Mangum’ <BMANGUM@novell.com> Date: 4/9/97 11:14AM Subject: RE: Thank you for being persistent on the product delivery

Sorry that it took so long to get back to you. I guess it’s better late then never (although that is a horrible excuse). In any case, here are some answers to your questions.
The truth is that contrary to some published reports, MAPI has not changed in quite some time. What has changed with Outlook is the extent to which we rely on MAPI. Outlook ’97 is heavily MAPI dependent and that is the reason most MAPI service providers that were previously written for exchange no longer work with Outlook. Over the past few months I have been working with several other developers that have run into similar problems and it has all come down to beefing up their MAPI service providers.
In order for GroupWise to work as the primary store with Outlook, there are a few requirements of the store itself. The most important one is that the store need to support named properties and the ability to create named properties on MAPI items on the fly. This is a piece of functionality that is heavily used by Outlook.
I will forward you some information that I have put together for other developers and I hope that they come in handy in your work to update your MAPI drivers to support Outlook.
If you have any questions, please feel free to contact me.

David Raissipour Outlook Product Planner Microsoft Corporation Mailto:DavidRai@Microsoft.com

On Friday, December 20, 1996 11:33 AM, Bill Mangum [SMTP:BMANGUM@novelI.com] wrote:

> David
> I did receive the product and there have been a couple of programmers reviewing the compatibility of Outlook with GroupWise. As you may suspect because of the changes in the version of MAPI that you have used with Outlook and probably Exchange 5 back-end also the. compatibility has fallen between our products.
> You had mentioned that you had work under way to do some write up of the changes and issues with the new version of MAPI that you are using. Also the specific calls that Outlook is making against a MAPI store, MAPI Address books, and the MAPI MTA. I would like to make sure that we are on the list of developers to receive that doc as soon as you are ready to have someone look at it for testing purposes.
> Also if you can give us any insight as to how the MAPI "standard" changes are evolving and what to expect in the next several months (year) that would be great.
> Thank you again

Bill Mangum Novell GroupWise Division Product Manager- Admin/Dir/Mngmt bmangum@novell.com NWA 000201

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02685.pdf

comes: deferred use of DR-DOS ..

General Manager Kempac Equipment Systems (S) 15 September 1988

Attn Mr. Davis Yea

..

our management has decided to defer the commitment to using DR DOS because the list of compatible software packages is not as extensive as wish it would t-c. For example, we have tested version 3.2 which is supposed to be compatible with Novell Advanced Netware 2.0a, but it failed to run ...

http://iowa.gotthefacts.org/011607/0000/PX00033.pdf 


  comes: comparing MS-DOS and DR-DOS ..


From: pascalm Thu Sep 22 14:42:18 1988 To: billg Cc: aaronr; philba; russw; tomle Subject: RE: DR DOS

Here- follow the three "differences" (between DR and MS DOS) that Aaron has been able to find so far. Except for these differences,the two OSs behave similarly, including undocumented calls.

The bottom line is that, given Aaron's current findings, an application can identify DR DOS. However, most apps usually have no business making calls that will let them decide which DOS (MS or DR) they are running on.

Do you think differently ? ...

http://iowa.gotthefacts.org/011607/0000/PX00034_A.pdf

I thought Microsoft never tested other OSes ?

the way to shut out Novell

From: Brad Silverberg To: Joachim Kempin Cc: Brad Chase Subject: RE: Windows base and premium Date: Thursday, January 06, 1994 10:27 AM

.. if we are too rude in base then oems may either stick with win3.1/msdos or defect to os/2.
the way to shut out novell in the base is to either ship a full client or make it so there is no network connectivity.

From: Joachim Kempin To: billg; bradsi; mikemap; paulma; steveb cc: joachimk; stevesi Subject: RE: Windows base and premium Date: Thursday, January 06, 1994 9:41 AM

.. In particular in the area of WfW kind connectivity we will face stiff competition from NOVELL and Prob, OS/2 by then ..

From: Bill Gates To: Brad Silverberg; Joachim Kempin; Mike Maples; Paul Maritz; Steve Ballmer Cc: Steven Sinofsky Subject: Windows base and premium Date: Sunday, December 26, 1993 3:16 PM

I think I am thinking of base as more limited than anyone else. I admit it causes potential problems with our compaq deal but there is a way to handle that by creating: base + some stuff is what compaq gets but that is less then premium so they can have something funny that no one else have or they can pay less and just get base or they can pay a little more and get premium.
I think base has the following things:
a. You can't add fonts. RUDE
b. You can't change screen driver. MAY BE OK
c. Some capacity constraints. Noticable - like 2 apps only or 8 meg. WILL MAKE ENDUSERS MOST ANGRY, AND OPEN OS/2 OPPORTUNITIES.
d. NO networking or connectivity. FIND RIGHT BALANCE
e. Some speed limits that are noticeable. AS LONG AS BASE = WFW AND PREMIUM GOES BEYOND WE CAN DO.
f. Only the most basic applets. AGREED.
Base is base. It is a lot better than DOS and it is NOT as good as Win:

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/4000/PX04293.pdf

MS claims that NDS on NT is reverse engineered

From: Lionel Bartlett <bartlel@telkom.co.za; To: GERMAN¥.DUS(Claus Schinabeck) Date: Mon, Jan 19, 1998 4:26 AM Subject: NDS on NT - Microsofts Story

    • High Priority **
Hi David,


Thanks for the effort you made to get me the info I needed before the ATS training. The training was very valuable!
Please verify the ’NDS on NT’ attached mail from Microsoft!!
Please send me Cutris’s email address. I’m not sure of the spelling of his surname.
Regards,
Lionel Bartlett
Telkom SA Ltd.

..

Received: from qit-ul-0104.telkom.co.za ([165.143.91.10]) by telkom32.telkom.co.za (GroupWise SMTP/MIME daemon 4.1 v3) ; Tue, 13 Jan 98 19:00:19 ZAT Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by qit-ul-0104.telkom.co.za (8.8.5/1997111401) with ESMTP id TAA00843; Tue, 13 Jan 1998 19:00:08 +0200 Received: by INET-02-1MC with Intemet Mail Service (5.5.1960.3) id <C5WG198B>; Tue, 13 Jan 1998 09:00:07"-0800 Message-ID: <5B3F16B2D B67D1119AOD00805F312AA2070101 @ red-msg-58.dns.microsoft.com> Deferred-Delivery: Tue, 13 Jan 1998 09:00:00 -0800 Return-Receipt-To: Eamie Glazener <eamieg@microsoft.com> X-Mailer: Intemet Mail Service (5.5.1960.3) Date: Tue, 13 Jan 1998 02:21:14 +0200 From: Eamie Glazener <eamieg@microsoft.com> To: BartleL@telkom.co.za Cc: billren@microsoft.com,geraldmu@microsoft.com, lerouxg@telkom.co.za Subject: RE: BackOffice News- December 2, 1997-Reply

You may also be interested in

http://www.micro~oft.com/ntserver/compadsons/nondsfomt.asp.

- Earnie

- Original Message---- > From: Eamie Glazener > Sent: Monday, January 12, 1998 4:07 PM > To: ’bartlel@telkom.co.za’ > Cc: Gerald Murphy; Bill Renaud; ’lerouxg@telkom.co.za’ > Subject: FW: BackOffice News- December 2, 1997-Reply

> - PLEASE NOTE THE INFORMATION IN THIS MESSAGE IS CONFIDENTIAL AND SUBJECT TO YOUR EXISTING NDA WITH MICROSOFT-

Lionel, we had a great time in SA. Thank you for spending some time with us and for listening to what we had to say. Sorry you somehow got the impression that Peter and I were chancers. We certainly did not and do not intend to mislead you in any way.
The fact is NDS on NT is reverse engineered. The SAM APIs are not exposed, so the only way to develop a replacement for SAMSRV is through reverse engineering the APIs based on analysis of the running system, decoding of entry points and call frames, and other related techniques - not through documentation and SDKs. Anyone who tells you differently is the true chancer in this case.
> Your observation about the current version of NDS on NT is astute. You may be interested in these additional observations:
1. SAM APIs are subject to change. Installation of a service pack could, for example, install an updated SAMSRV.DLL and effectively disconnect the DC in question from NDS.
2. Since the SAM APIs are not exposed there is a high probability that some SAM operations are not covered by the replacement SAMSRV. The impact of this is difficult to assess without exhaustive testing.
3. In the case of a single NDS user being granted access to multiple domains, the same user, "JamesSmith" would appear in the context of each "trusted domain" selected. A Windows NT ACL could have entries for Domain1\JamesSmith, Domain2\JamesSmith, and Domain3\JamesSmith. All three are in fact the same user, but with different SIDs.
4. 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.
5. An administrator must use multiple tools for administration due to missing functionality in NDS for NT
6. ADSI supports NDS, but ADSI does not expose the SID, password residue, and other items required to migrate a Windows NT domain to NDS. This means the migration process is via the UI, and the current UI makes this quite laborious.
7. Since NDS for NT must support all Windows NT clients, not just Windows NT clients with the IntranetWare client installed, Novell must maintain 2 passwords for every user:, a Windows NT password and an NDS password. From Novell’s own announcement documents it is clear this is a ¯ compromise solution that is far from transparent to the user.
8. Every domain controller for a given Windows NT domain must have the NDS for Windows NT components installed so that all authentication and authorization operations are redirected to NDS. It is not clear what the system behavior will be in a partially migrated domain (e.g. some DCs with NDS for NT and some without).
9. Network traffic for Windows NT authentication and authorization doubles. Each SAM operation at a DC results in an least one additional round trip between the DC and a NetWare server.
10. This will not work on Windows NT Server 5.0. Novell has made assurances that installing NDS for NT will not hinder an upgrade to Active Directory. This is incorrect. The upgrade from Windows NT Server 4.0 to Windows kiT Server 5.0 converts the SAM by reading it directly, not by calling SAM APIs. The users and groups created in NDS will not be picked up in the upgrade (assuming the upgrade can even begin with the hacked SAMSRV installed, which is unlikely). NDS for NT users will be faced with a second migration after installing Windows NT Server 5.0, to bring the NDS users into Active Directory.

Furthermore, there are multiple paths into the authorization and authentication system in Windows NT Server 5.0, there is no single place to trap and redirect these operations. A Windows NT Server 5.0 version of NDS for NT will require a total rewrite, and there is little motivation for this since Windows NT Server 5.0 comes with Active Directory.

11. NDS for NT is not a mainstream product. It is a point solution that ¯appears to be designed to appeal to NetWare customers with an expanding base of Windows NT servers supporting applications like Exchange. While NDS for NT might be appealing as a stopgap measure to provide more ¯ centralized administration of Windows NT domains, the substantial expense, questionable stability, and dead-end nature of the implementation all argue against it.
You saw and heard from us how NT domains can meet your needs effectively today; provide acceptable administrator support, and provide far better application support than NDS. The story gets even better with NT5. I strongly urge you to consider a move to NT4 today both for the benefits NT ¯ offers today and as a means of positioning Telkom for a smooth migration to NT5. You will be happy you did.
Once again, thank you for the great time we had in SA. We look forward to seeing you again the next time we are in Johannesburg.

Best wishes, Earie Glazener Enterprise Customer Unit

-Original Message-- From: Lionel Bartlett [SMTP:bartlel@telkom.co.za] Sent: Fdday, December 05, 1997 7:58 AM To: Gerald Murphy Cc: lerouxg@telkom.co.za Subject: BackOffice News- December 2, 1997 -Reply

Hi,
Thanks for the news.
Those Microsoft Consultants you brought over here are chancers. NDS on NT is not reverse engineered, it makes use of Microsoft RPC technology. The current version of NDS on NT isn’t that great anyway.
Regards,
Lionel Bartlett
Telkom SA Ltd.
¯
¯ * NT5 will be released...hmmm... 2000-2999

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02827.pdf

NDS lies propagated by MS

From: Gary Hein Date: Sat, May 30, 1998 3:34 PM 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:
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
GH: False
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.
GH: False - NDS for NT works over IP - no need to add IPX. This is a scare tactic.
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

Retrieved from "http://techrights.org/wiki/Netware/Novell"
Personal tools
Search entire domain
Stories