Microsoft claims that NDS on NT is reverse engineered
Date: January 1998
* 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; 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
X-Mailer: Intemet Mail Service (5.5.1960.3)
Date: Tue, 13 Jan 1998 02:21:14 +0200
From: Eamie Glazener
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
Synopsis
Snippet
From: Lionel Bartlett: 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
: 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