last modified: 06/30/95
DCNS has been investigating Netware for use and/or support at MIT. MIT has no plans to route IPX on the MIT backbone. This limits the usefulness of Netware at MIT. Netware may also use TCP/IP protocols with the use of IP Tunneling or Netware/IP. The invesigation of Netware/IP is the primary focus of DCNS's pilot project. Concurrent with this is the investigation of Novell's NDS system.
If DCNS finds that the use of Netware/IP and NDS may be of benefit to MIT and be managable in a cost effective way we may offer a root NDS and DSS server for the campus.
DCNS is currently running three Netware servers. Wimpy, Dopey, and Sappy.
WIMPY is configured to a be the root NDS server for the campus. It is also the primary DSS server for the campus. We do not anticipate putting user accounts onto this machine. It is used to be used as a primary service provider for services other than file and print services.
DOPEY is configured to be a read/write replica of the root NDS partion which is located on WIMPY. DOPEY is also the home of the dosdev source tree. We are in the process of investigating the use of ADSM to back this up. DOPEY also runs the MAC AFP support for 5 users.
SAPPY is expected to remain an experimental server. This server will contain the Netware home directories of the dosdev UROP students. This server will also be used as a test bed for installation of new NLMs by DCNS. SAPPY also runs a 5 user license of the MAC AFP software.
The DCNS dosdev team expects to use Netware extensively as its primary file system for storing source code.
Netware/IP is a product that allows the Netware Core Protocols, NCP, to run over IP rather than IPX. It is available as a separate product. The product consists of several pieces. It consists of the DSS, domain sap server, DNS, domain name server, Netware/IP server, and xconsole. It is managed via the uniconsole NLM.
The DNS portion of the product should not be configured at MIT. Our existing servers yield better performance than using Netware as a DNS server. User unfamiliar with the configuration and maintenance of DNS servers may cause a problem within the MIT environment when trying to configure this product. DCNS has noticed on more than one occasion that if the Netware server is configured to be a DNS server it initiates a zone transfer with our existing DNS servers. Often the Netware servers are unable to complete the zone transfer. This causes the DNS servers that DCNS maintain to hang. This result is denial of service to other users of MITnet. DCNS has not yet determined the exact steps that lead to this problem or why the Netware servers hang during the zone transfer.
The Xconsole portion of the Netware/IP package allows the Netware server to be remotely managed via an xterm or a telnet session. Of course this also opens the obvious security hole to the Netware server. Server administrators need to wiegh their options if they are going to use this product. On the one hand it allows the server to be managed remotely, on the other hand a simple sniffer attack with open the server to another user. In the case of small departmental servers the case can be made that the admins should visit the machine in person. If DCNS has to help maintain servers then it is essential that we use remote management because we have neither the time nor personnel to physically visit each machine. DCNS should make it security concerns known to Novell and the TTP group so that the product may evolve in the future.
The DSS server, domain sap server, is similiar in concept to a DNS server. Traditionaly Netware has used SAP, service advertisement protocol, to advertise the services available on the network. This is a brodcast mechanism. The DSS replaces the boradcast nature of SAP with a centralized database. A netware server must act as a DSS. The DSS is located by clients via DNS. The DSS is designated by a subdomain. Currently our DNS servers have a subdomain of nwip.mit.edu which points to WIMPY which in turn functions as the primary DSS.
Netware/IP is not required on all servers. However we strongly recommend it for anyone that wants to buy in to the centralized NDS tree and easily configured TCP/IP access to their Netware servers.
The biggest problems with Netware/IP at the moment are that it only works on DOS/Windows and only when using the LWP or FTP stack. It is not supported on the
NDS, Netware Directory Service, is a large part of Novell's stratgey to expand Netware into the WAN and eventually Internet markets. NDS is an X.500 derivative. NDS provides a centralized or distributed database of servers, users, groups, printers, drive volumes, and other network resources.
Long term interoperability will be greatly enhanced if departments that use NDS buy into uniform nameing convention for the entire campus. Departments that are looking into NDS should install Netware/IP and work with DCNS to be intergrated with our NDS tree from the start. Departments that are unwilling to run Netware/IP at this time should follow our naming convention so that they may merge into our tree in the future. Ignoring this issue may cause departments a very costly migration in the future.
Tom and Jeff think that the tree should be very flat. E.g. MIT should be at the root and each group should be the next level down. They have reached this conclusion based on X.500 experiences. I am not sure that NDS works well in this configuration. So far I have been creating a tree with more layer. For example the dosdev group has a context of ou=dcns.ou=is.o=mit and the document services users have the context ou=docserv.ou=libraries.o=mit.
My suggestion is to learn about the system by trying out both models. CAO and other groups added later will be given a flat context of ou=cao.o=mit. DCNS and DOCSERV will remain as they are for now and we will revisit the issue later.
The Domain SAP Server, DSS, greatly reduces SAP traffic when using Netware. The Netware/IP domain for MIT is NWIP.MIT.EDU. This named is resolved through DNS. Presently this name record points only to WIMPY.MIT.EDU which is configured to be a primary DSS. We may wish to configure other servers as secondary servers at a later time. For now we are not running any secondary servers.
This is when IPX is encapsulated in UDP. This technique is slow and has a high traffic overhead. Net OPS does not recommend using this.
Lincoln Labs has met with Janet Perry of Novell and asked for an ELA agreement. An ELA agreement provides several benefits to educational sites which meet the requirements. Novell wishes to continue to treat LL and MIT as one site. We are gather facts to see if the unified site meets the ELA requirements.
Bill Huxley of CAO has done a priliminary pass at the open POs to see amount of Novell products that we are purchasing.
I have asked Janet Perry of Novell to provide me with a list of our vendors of record from Novell's databases. This information will allow Bill Huxley to refine his queries.
Points of contact:
University of Pittsburgh
Chris Keslar, keslar+@pitt.edu
(412) 624-2977, Fax: (412) 624-8572
Systems Analyst, Information and Office Services
Chris told me that UPitt has developed software to keep Netware and Kerberos password synchronized. This is not using the CMU code.
One person from Novell told me that there is a commercial product from the UK that also synchronizes the passwords. He thought the firm was CKS in the UK.
Umich has done some similar work. They have a white paper.
Mike LaHaye, Systems Project Coordinator, User Services,
mjl@ngw.med.umich.edu
Work Phone: +1 313 747-4293
Fax Number: +1 313 764-5601
CMU has also done some work with Kerberos and Netware.
We just completed the work of providing Kerberos support for Netware. For details send mail to Wally at wally+@cmu.edu (note the + sign to denote registered ID rather than name to be used for fuzzy matching).
It is unclear if this work affects the security of the Kerberos database or Netware. So far the negative comments that I have heard have just been from hallway conversations. I have not seen any documentation for the project nor the source code. (pbh)
Novell is developing a login API. Notes are available from the Brainshare proceedings. Here are some of my quick notes from the session.
The login script processor has been slightly extended. Users will have a single login script with platform keyword for #ifdef type of processing of the script.
The first target platforms for the login API are DOS, Windows and OS/2. The next target will be NT. No mention of the Mac.
Identification and authentication interfaces may disappear in future releases !
One of the header files used and required is ntypes.h. This can be found on the CD from Brainshare '93.
Point of contact for this work at Novell is anevarez@novell.com