741 COMPARATIVE OPERATING SYSTEMS

TERM PAPER

SUMMER 2001

COMPARISON OF NETWORK OPERATING SYSTEMS

BY

MUKUNDAN SRIDHARAN

COMPARISON OF NETWORK

OPERATING SYSTEM S

Abstract

We are in a era of computing in which networking and distributed computing is the norm and not a exception. The ability of a operating system to support networking has become crucial for its survival in the market. In today’s picture there is no operating system, which doesn’t support networking. This paper tries to give a review of various network operating systems or the networking support of a operating system, in relevance to the modern operating systems. The emphasis is on basic design and architecture, not their specifications or services. The paper considers various operating systems like Novell Netware, the sun NFS, the Styx, CIFS/SMB and Microsoft Windows 2000 server. Again the concentration is on modern and evolving operating systems like the Novell Netware and Microsoft’s Windows 2000. The objective of the paper is to study and compare various operating systems and to bring out the inherent advantages and disadvantages in using them.

1.0 INTRODUCTION

Individual computers are connected together to form computer networks. The operating system, protocols and services which help us in interconnecting the computers are collectively called Network Operating systems. The webopedia.com defines Network Operating Systems as follows:

An operating system that includes special functions for connecting computers and Devices into a local-area network (LAN). Some operating systems, such as UNIX and the Mac OS, have networking functions built in. The term network operating system, however, is generally reserved for software that enhances a basic operating system by adding networking features. For example, some popular NOS's for DOS and Windows systems include Novell Netware, Artisoft's LANtastic, Microsoft LAN Manager, and Windows NT.

In this paper I have reviewed various Network OS and compare them and find out their suitability to various applications.

2.0 SUN NFS

2.1 Introduction:

NFS, or the Network File System, was originally developed by Sun Microsystems in the 1980's as a way to create a file system on diskless clients. NFS provides remote access to shared file systems across networks. This means that a file system may actually be sitting on machine A, but machine B can mount that filesystem and it will look to the users on machine B like the file system resides on the local machine. In this way NFS is transparent to the user. NFS was also designed to be machine, operating system, network architecture, and transport protocol independent.

The primary functions of NFS are to export or mount directories to other machines, either on or off a local network. These diretories can then be accessed as though they were local. NFS uses a client/server architecture and consists of a client program, a server program, and a protocol used to communicate between the two.

The server program makes filesystems available for access by other machines via a process called exporting. File systems that are available for access across the network are often referred to as shared file systems.

NFS clients access shared file systems mounting them from an NFS server machine. When a file system is mounted, it is integrated into the directory tree. An advanced form of this service is the automounter, which automatically mounts and unmounts file systems.

The NFS mount protocol facilitates the functions that allow NFS clients to attach remote directory trees to a mount point in the local file system. A mount point is an empty directory or subdirectory, created as place to attach a remote file system. In order to mount a file system from an NFS server, a user needs an account on the machine where the file system resides. The NFS client passes the UID and GID of the process requesting the mount to the NFS server. The server then validates the request. Mount protocol also allows the server to grant remote access privileges to a restricted set of clients via export control.

There are currently four versions of NFS. The default version for most workstations is NFS2.

2.2 Whats new in NFS 4

The first major structural change to NFS compared to prior versions is the elimination of ancillary protocols. In NFS Versions 2 and 3, the Mount protocol was used to obtain the initial filehandle, while file locking was supported via the Network Lock Manager protocol. NFS Version 4 is a single protocol that uses a well-defined port, which, coupled to the use of TCP, allows NFS to easily transit firewalls to enable support for the Internet. As in WebNFS, the use of initialized filehandles obviates the need for a separate Mount protocol [RFC1813]. Locking has been fully integrated into the protocol, which was also required to enable mandatory locking. The lease-based locking support adds significant state (and concomitant error recovery complexity) to the NFS Version 4 protocol.

Another structural difference between NFS Version 4 and its predecessors is the introduction of a COMPOUND RPC procedure that allows the client to group traditional file operations into a single request to send to the server. In NFS Versions 2 and 3, all actions were RPC procedures. NFS Version 4 is no longer a "simple" RPC-based distributed application. In NFS Version 4, work is accomplished via operations. An operation is a file system action that forms part of a COMPOUND procedure. NFS Version 4 operations correspond functionally to RPC procedures in former versions of NFS. The server in turn groups the operation replies into a single response. Error handling is simple on the server evaluation proceeds until the first error or last operation where upon the server returns a reply for all evaluated operations.

We introduced the COMPOUND procedure to reduce network round trip latency for related operations, which can be costly over a WAN (for example, the Internet). The model NFS Version 4 uses implies the NFS layer engages more closely in the marshalling and unmarshalling of data, which complicates implementation. NFS Version 3 was designed to be easy to implement given an NFS Version 2 implementation. NFS Version 4 did not have that requirement. The only RPC procedures in NFS Version 4, in the strict sense, are NULL and COMPOUND and theircall back analogues.

Table 1. groups the operations (or in the case of NFS Version 2 and 3, RPC procedures) functionally for purposes of comparison. The comparison is a little unfair since the Network Lock Manager, Status Monitor and Mount protocol procedures needed by NFS Versions 2 and 3 are not shown. Significant changes occurred to data structures and semantics of existing operations, some of which are described below.
|Table 1. NFS operations by version - at a glance |
|Version 2 |Version 3 |Version 4 |
|NULL |NULL |NULL |
|Compound operations |
| | |COMPOUND |
| | |NVERIFY |
| | |VERIFY |
| | |Reserved Operation 2 |
|OPEN/CLOSE operations |
| | |OPEN |
| | |OPENATTR |
| | |OPEN_CONFIRM |
| | |OPEN_DOWNGRADE |
| | |CLOSE |
|Delegation operations |
| | |DELEGPURGE |
| | |DELEGRETURN |
| | |SETCLIENTID |
| | |SETCLIENTID_CONFIRM |
|Client callback procedures for delegation |
| | |CB_NULL |
| | |CB_COMPOUND |
| | |CB_GETATTR |
| | |CB_RECALL |
|Locking operations |
| | |LOCK |
| | |LOCKT |
| | |LOCKU |
| | |RENEW |
|Filehandle operations |
| | |PUTPUBFH |
| | |PUTROOTFH |
| | |GETFH |
| | |RESTOREFH |
| | |SAVEFH |
|Security operations |
| |ACCESS |ACCESS |
| | |SECINFO |
|Traditional file operations |
|LOOKUP |LOOKUP |LOOKUP |
| | |LOOKUPP |
|GETATTR |GETATTR |GETATTR |
|SETATTR |SETATTR |SETATTR |
|LINK |LINK |LINK |
|READDIR |READDIR |READDIR |
| |READDIRPLUS | |
|READLINK |READLINK |READLINK |
|CREATE |CREATE |CREATE |
|MKDIR |MKDIR | |
| |MKNOD | |
|REMOVE |REMOVE |REMOVE |
|RMDIR |RMDIR | |
|RENAME |RENAME |RENAME |
|SYMLINK |SYMLINK | |
|READ |READ |READ |
|WRITE |WRITE |WRITE |
| |COMMIT |COMMIT |
|STATFS |FSSTAT | |
| |FSINFO | |
| |PATHCONF | |
|Never implemented |
|ROOT | | |
|WRITECACHE | | |
|18 ops |22 ops |42 ops |

The NFS Version 4 introduction of the stateful operations OPEN and CLOSE is another major structural difference. NFS Versions 2 and 3 were essentially stateless. LOOKUP was the closest analogue to an open operation in earlier versions of NFS. However, a LOOKUP procedure did not create state on the server. The introduction of the stateful OPEN and CLOSE operations is required to ensure atomicity of share reservations as defined for Windows file sharing [CIFS], and to support exclusive creates. Additionally, the OPEN operation provides the server the ability to delegate authority to a client, allowing aggressive caching of file data and locking state.

The CREATE operation of NFS Version 4 differs from an NFS Version 3 CREATE in that it is only used to create special file objects such as symbolic links, directories, and special device nodes. To ensure correct share reservation semantics, the regular file CREATE procedure of NFS Versions 2 and 3 is replaced by the NFS Version 4 OPEN operation (with a create bit set). CREATE and REMOVE in NFS Version 4 subsumes the MKDIR and RMDIR directory functionality of prior versions of NFS.

NFS Version 4 servers depart from the semantics of previous NFS versions in requiring LOOKUP requests to cross mount points on the server. In NFS Version 4, a LOOKUP is very simple. It only sets the current filehandle to point at the file object resolved. Attributes (including the filehandle itself) can be obtained with a subsequent GETATTR operation in the same COMPOUND procedure. Additionally, as defined in WebNFS, LOOKUP takes a multi-component pathname.

Previous versions of NFS assigned special semantics to the directory entries "." and ".." NFS Version 4 assigns no special meaning to these names, and requires the client to explicitly use the LOOKUPP operation to obtain the filehandle of a parent directory.

The Weak Cache Consistency information (pre- and post-operation attributes) of NFS Version 3 has been removed. Instead, CREATE, LINK, OPEN, REMOVE, and RENAME return a data structure change_info (typically implemented as a modified time) that provides information on whether the directory underlying the object changed during the operation. The client can use this information to decide whether to flush cached directory information in the face of concurrent client modifications.

Underlying the NFS Version 4 protocol is mandated strong security via an extensible authentication architecture built on GSS-API. The client determines the authentication type required for a given file's access using the SECINFO operation. Initial authentication flavors supported in this framework are Kerberos and LIPKEY. NFS Version 4 defines a Windows NT and Unix-compatible access control model.

The NFS Version 3 directory scanning operation READDIRPLUS procedure was dropped, and its functionality of providing attributes with each directory entry (including the filehandle) is now supported by the READDIR operation. This "bulk LOOKUP" functionality is used to initialize attribute caches when first scanning directories to reduce latency introduced by a (now unneeded) subsequent stream of LOOKUP operations.

Attributes of the file system underlying a file system object (for example, file system free space) exist in NFS Version 4 as attributes of the file system object itself. This replaces the NFS Version 3 procedures FSSTAT, FSINFO and PATHCONF with an NFS Version 4 GETATTR operation of the desired attributes.

As in NFS Version 3, file access rights are checked on the server, not the client. However, in NFS Version 4, file access rights are checked as part of an explicit OPEN operation instead of the NFS Version 3 LOOKUP and ACCESS procedure sequence. In retrospect, the introduction of the separate ACCESS procedure to handle access checking in conjunction with an initial LOOKUP (associated with a client application opening a file) hurt performance by introducing further unwanted network latency. The explicit ACCESS operation is retained in NFS Version 4 to support the UNIX access(2) programming interface which does not require the file to be opened.

NFS Version 4 supports file system replication and migration, but details of server-to-server file system transfers are undefined.

3.0 THE STYX ARCHITECTURE FOR DISTRIBUTED SYSTEM

3.1 Intorduction:

The Styx operating systems depend on, advocate, and generally push to the limit a fruitful idea: to present their resources as files in a hierarchical name space. The objects appearing as files may represent stored data, but may also be devices, dynamic information sources, interfaces to services, and control points. The approach unifies and provides basic naming, structuring, and access control mechanisms for all system resources. A simple underlying network protocol, Styx, forms the core of the architecture by presenting a common language for communication within the system.

The original idea behind Styx was to encode file operations between client programs and the file system, to be translated into messages for transmission on a computer network. Using this technology, Plan 9 separates the file server­a central repository for permanent file storage­both from the CPU server­a large shared-memory multiprocessor­and from the user terminals. This physical separation of function was central to the original design of the system; what was unexpected was how well the model could be used to solve a wide variety of problems not usually thought of as file system issues.

Note that although the resources published by Styx behave like files, they have file names, file permissions, and file access methods, they do not need to exist as standard files on disk. The /dev/mouse file is accessed by standard file I/O mechanisms but is nonetheless a transient object fabricated dynamically by a running program; it has no permanent existence.

By following this approach throughout the system, Plan 9 achieves a remarkable degree of transparency in the distribution of resources[PPTTW93]. Besides interactive graphics, services such as debugging, maintenance, file backup, and even access to the underlying network hardware can be made available across the network using Styx, permitting the construction of distributed applications and services using nothing more sophisticated than file I/O.

3.2 The Styx protocol

Styx's place in the world is analogous to Sun NFS[RFC][NFS] or Microsoft CIFS[CIFS], although it is simpler and easier to implement [Welc94]. Furthermore, NFS and CIFS are designed for sharing regular disk files; NFS in particular is intimately tied to the implementation and caching strategy of the underlying UNIX file system. Unlike Styx, NFS and CIFS are clumsier at exporting dynamic device-like files such as /dev/mouse.

Styx provides a view of a hierarchical, tree-shaped file system name space[Nee89], together with access information about the files (permissions, sizes, dates) and the means to read and write the files. Its users (that is, the people who write application programs), don't see the protocol itself; instead they see files that they read and write, and that provide information or change information.

In use, a Styx client is an entity on one machine that establishes communication with another entity, the server, on the same or another machine. The client mechanisms may be built into the operating system, as they are in Plan 9 or Inferno[INF1][INF2], or into application libraries; a server may be part of the operating system, or just as often may be application code on a separate server machine. In any case, the client and server entities communicate by exchanging messages, and the effect is that the client sees a hierarchical file system that exists on the server. The Styx protocol is the specification of the messages that are exchanged.

At one level, Styx consists of messages of 13 types for

• Starting communication (attaching to a file system) • Navigating the file system (that is, specifying and gaining a handle for a named file) • Reading and writing a file • Performing file status inquiries and changes

However, application writers simply code requests to open, read, or write files; a library or the operating system translates the requests into the necessary byte sequences transmitted over a communication channel. The Styx protocol proper specifies the interpretation of these byte sequences. It fits, approximately, at the OSI Session Layer level of the ISO standard classification. Its specification is independent of most details of machine architecture and it has been successfully used among machines of varying instruction sets and data layout.

In use, an operation such as

open("/usr/rob/.profile", O_READ);

is translated by the underlying system into a sequence of Styx messages. After establishing the initial connection to the file server, an attach message authenticates the user (the person or agent accessing the files) and returns an object called a FID (file ID) that represents the root of the hierarchy on the server. When the open() operation is executed, it proceeds as follows.

* A clone message duplicates the root FID, returning a new FID that can navigate the hierarchy without losing the connection to the root. * The new FID is then moved to the file /usr/rob/.profile by a sequence of walk messages that step along, one path component at a time (usr, rob, .profile). * Finally, an open message checks that the user has permission to read the file, permitting subsequent read and write operations (messages) on the FID. * Once I/O is completed, the close message will release the FID.

At a lower level, implementations of Styx depend only on a reliable, byte-stream Transport communications layer. For example, it runs over either TCP/IP, the standard transmission control protocol and Internet protocol, or Internet link (IL), which is a sequenced, reliable datagram protocol using IP packets. It is worth emphasizing, though, that the model does not require the existence of a network to join the components; Styx runs fine over a Unix pipe or even using shared memory. The strength of the approach is not so much how it works over a network as that its behavior over a network is identical to its behavior locally.

3.3 Architectural approach

Styx, as a file system protocol, is merely a component in a more encompassing approach to system design: the presentation of resources as files.

Suppose an application wishes to establish a connection over TCP/IP to www.bell-labs.com The first task is to translate the domain name www.bell-labs.com to a numerical internet address; this is a complicated process, generally involving communicating with local and remote Domain Name Servers. In the Styx model, this is done by opening the file /dev/dns and writing the literal string www.bell-labs.com on the file; then the same file is read. It will return the string 204.178.16.5 as a sequence of 12 characters.

Once the numerical Internet address is acquired, the connection must be established; this is done by opening /net/tcp/clone and reading from it a string that specifies a directory like /net/tcp/43, which represents a new, unique TCP/IP channel. To establish the connection, write a message like connect 204.178.16.5 on the control file for that connection, /net/tcp/43/ctl. Subsequently, communication with www.bell-labs.com is done by reading and writing on the file /net/tcp/43/data.

There are several things to note about this approach.

• All the interface points look like files, and are accessed by the same I/O mechanisms already available in programming languages like C, C++, or Java. However, they do not correspond to ordinary data files on disk, but instead are creations of a middleware code layer. • Communication across the interface, by convention, uses printable character strings where feasible instead of binary information. This means that the syntax of communication does not depend on CPU architecture or language details. • Because the interface, as in this example with /net as the interface with networking facilities, looks like a piece of a hierarchical file system, it can easily and nearly automatically be exported to a remote machine and used from afar.
In particular, the Styx implementation encourages a natural way of providing controlled access to networks. Lucent, like many organizations, has an internal network not accessible to the international Internet, and has a few gateways between the inside and outside networks. Only the gateway machines are connected to both, and they implement the administrative controls for safety and security. The advantage of the Styx model is the ease with which the outside Internet can be used from inside. If the /net file tree described above is provided on a gateway machine, it can be used as a remote file system from machines on the inside. This is safe, because this connection is one-way: inside machines can see the external network interfaces, but outside machines cannot see the inside.

3.4 Security issues

Styx provides several security mechanisms for discouraging hostile or accidental actions that injure the integrity of a system.

The underlying file-communication protocol includes user and group identifiers that a server may check against other authentication. For example, a server may check, on a request to open a file, that the user ID associated with the request is permitted to perform the operation. This mechanism is familiar from general-purpose operating systems, and its use is well-known. It depends on passwords or stronger mechanisms for authenticating the identity of clients.

The Styx approach of providing remote resources as file systems over a network encourages genuinely secure access to the resources in a way transparent to applications, so that authentication transactions need not be provided as part of each. For example, in Inferno, the negotiation of an initial connection between client and server may include installation of any of several encrypting or message-digesting protocols that supervise the channel. All application use of the resources provided by the server is then protected against interference, and the server has strong assurance that its facilities are being used in an authorized way. This is relevant both for general-purpose file servers, and, in the telephony field, is especially useful for safe remote administration.

3.5 Advantages

Styx has these advantages:

• A simple, familiar programming model for reading and writing named files. File systems have well-defined naming, access, and permissions structures. • Platform and language independence. Underlying access to resources is at the file level, which is provided nearly everywhere, instead of depending on facilities available only with particular languages or operating systems. C++ or Java classes, and C libraries can be constructed to access the facilities. • A hierarchical naming and access control structure. This encourages clean and well-structured design of resource naming and access. • Easy testing and debugging. By using well-specified, narrow interfaces at the file level, it is straightforward to observe the communication between distributed entities. • Low cost. Support software, at both client and server, can be written in a few thousand lines of code, and will occupy only small space in products.

This approach to building systems is successful in the general-purpose systems Plan 9 and Inferno; it has also been used to construct systems specialized for telephony, such as Mantra[MAN] and the PathStar Access Server. It supplies a coherent, extensible structure both to the internal communications within a single system and external communication between heterogeneous components of a large digital network.

4.0 CIFS/SMB

4.1 Introduction

CIFS enables collaboration on the Internet by defining a remote file-access protocol that is compatible with the way applications already share data on local disks and network file servers. CIFS incorporates the same high-performance, multiuser read and write operations, locking, and file-sharing semantics that are the backbone of today's sophisticated enterprise computer networks. CIFS runs over TCP/IP and utilizes the Internet's global Domain Naming Service (DNS) for scalability, and is optimized to support slower speed dial-up connections common on the Internet.
CIFS is an enhanced version of Microsoft's open, cross-platform Server Message Block (SMB) protocol, the native file-sharing protocol in the Windows 95, Windows NT®, and OS/2 operating systems and the standard way that millions of PC users share files across corporate intranets. CIFS is also widely available on Unix, VMS, and other platforms

Not intended to replace HTTP, CIFS complements HTTP while providing more sophisticated file sharing and file transfer than older protocols such as FTP. CIFS is designed to enable all applications, not just Web browsers, to open and share files securely across the Internet.

4.2 Finding A File

CIFS is based on the SMB protocol widely in use by personal computers and workstations running a variety of operating systems. The full specification (at ftp://ietf.cnri.reston.va.us/internet-drafts/ draft-heizer-cifs-v1-spec-00.txt) runs 155 pages, so we'll only look at some of the pertinent info.
For any particular file, it is assumed that the client machine will be able to determine the name of the server and the relative name within the server. In the URL "file://fs.megacorp.com/users/fred/stuff.txt," the client should know how to parse the string so it knows that this represents a file on the server fs.megacorp.com, located at the path /users/fred/stuff.txt. Once the server name has been determined, the client needs to resolve that name to a transport address. This specification defines two ways of doing so: using the DNS or NetBIOS name resolution. The method used is configuration-dependent; the default is DNS to encourage interoperability over the Internet. The name-resolution mechanism will place constraints on the form of the server name. In the case of NetBIOS, the server name must be 15 characters or less and uppercase. The server name can also be specified as the string form of an IPv4 address in the usual dotted notation (for example, "157.33.135.101"). In this case, resolution consists of converting to the 32-bit IPv4 address.

4.3 Opportunistic Locks

Network performance can be increased if the client can buffer file data locally. For example, the client does not have to write information into a file on the server if the client knows that no other process is accessing the data. Likewise, the client can buffer read-ahead data from the file if the client knows that no other process is writing the data. The mechanism that allows clients to dynamically alter their buffering strategy in a consistent manner is known as opportunistic locks or oplocks. Versions of the SMB file-sharing protocol including and newer than the LANMAN1.0 dialect support oplocks. There are three different types of oplocks. An exclusive oplock allows a client to open a file for exclusive access and allows the client to perform arbitrary buffering. A batch oplock allows a client to keep a file open on the server even though the local accessor on the client machine has closed the file. A Level II oplock indicates that there are multiple readers of a file and no writers. When a client opens a file, it requests the server to grant it a particular type of oplock on the file. The response from the server indicates the type of oplock granted to the client. The client uses the granted oplock type to adjust its buffering policy. The SMB_COM_LOCKING_ANDX SMB is used to convey oplock break and response information.

4.4 Exclusive Oplocks

If a client is granted an exclusive oplock, it may buffer byte range lock information, read-ahead data, and write data on the client because the client knows that it is the only accessor to the file. The basic protocol requires that the client open the file, requesting that an oplock be given to the client. If the file was opened by anyone else, then the client is refused the oplock and no local buffering may be performed. This also means that no read-ahead may be performed to the file unless the client knows that it has the read-ahead range locked. If the server grants the exclusive oplock, the client can perform certain optimizations for the file such as buffering lock, read, and write data.
[pic]

The exclusive oplock protocol is shown in Figure 3. When client A opens the file, it can request an exclusive oplock. Provided no one else has the file open on the server, the oplock is granted to client A. If at some point in the future another client, such as client B, wants to open the same file, then the server must have client A break its oplocks.

Breaking the oplock involves client A sending the server any lock or write data that it has buffered, and then letting the server know it has acknowledged that the oplock has been broken. This synchronization message informs the server that it can allow client B to complete its open. Client A must also purge any of its read-ahead buffers for the file. This is not shown in the diagram since no network traffic is needed to do this.

4.5 Batch Oplocks

Batch oplocks are used when client programs cause the amount of network traffic to go beyond an acceptable level for the functionality provided by the program. For example, the MS-DOS command processor executes commands from within a command procedure by performing the following steps: • Opening the command procedure. • Seeking to the next line in the file. • Reading the line from the file. • Closing the file. • Executing the command.
This process is repeated for each command executed from the command procedure file. This type of programming model causes an inordinate amount of processing of files, thereby creating a lot of network traffic that could otherwise be curtailed if the program was to simply open the file, read a line, execute the command, and then read the next line. Batch oplocking curtails the amount of network traffic by allowing the client to skip the extraneous open and close requests. When the MS-DOS command processor then asks for the next line in the file, the client can either ask for the next line from the server, or it may have already read the data from the file as read-ahead data. In either case, the amount of network traffic from the client is greatly reduced
[pic]
If the server receives either a rename or a delete request for the file that has a batch oplock, it must inform the client that the oplock is to be broken. The client can then switch to a mode where the file is repeatedly opened and closed (see Figure 4). When client A opens the file, it can request an oplock. Provided no one else has the file open on the server, then the oplock is granted to client A. In this case, client A keeps the file open for its caller across multiple open/close operations. Data may be read ahead for the caller, and other optimizations, such as buffering locks, can also be performed. When another client requests an open, rename, or delete operation from the server for the file, client A must clean up its buffered data and synchronize with the server. Most of the time this involves actually closing the file, provided that client A's caller actually believes that it has closed the file. Once the file is actually closed, client B's open request can be completed.

4.6 Level II Oplocks

Level II oplocks allow multiple clients to have the same file open as long as no client is performing write operations to the file. This is important for many environments because many clients open files with read/write access even though they never write to the file. While it makes sense to do this, it also tends to break oplocks for other clients even though neither client intends to write to the file.

[pic]
The Level II oplock protocol is shown in Figure 5. This sequence of events is very much like an exclusive oplock. The basic difference is that the server informs the client that it should break to a Level II lock when no one has been writing the file. Client A, for example, may have opened the file for a desired access of read and a share access of read/write. This means, by definition, that client A will not perform any writes to the file.

When client B opens the file, the server must synchronize with client A in case client A has any buffered locks. Once it is synchronized, client B's open request may be completed. Client B, however, is informed that it has a Level II oplock rather than an exclusive oplock. In this case, no client that has the file open with a Level II oplock may buffer any lock information on the local client machine. This allows the server to guarantee that if any write operation is performed, it need only notify the Level II clients that the lock should be broken without having to synchronize all of the accessors of the file. The Level II oplock may be broken and set to none, meaning that some client that opened the file performed a write operation to the file. Because no Level II client may buffer lock information, the server is in a consistent state. The writing client, for example, could not have written to a locked range by definition. Read-ahead data may be buffered in the client machines, however, thereby cutting down on the amount of network traffic to the file. Once the Level II oplock is broken, the buffering client must discard its buffers and degrade to performing all operations on the file across the network. No oplock break response is expected from a client when the server breaks a client from Level II to none.

4.7 Security Model

Each server makes a set of resources available to clients on the network. A shared resource may be a directory tree, a named pipe, or a printer. As far as clients are concerned, the server has no storage or service dependencies on any other servers; a client considers the server to be the sole provider of the file (or other resource) being accessed. The SMB protocol requires server authentication of users before file accesses are allowed, and each server authenticates its own users. A client system must send authentication information to the server before the server will allow access. The SMB protocol defines two methods which can be selected by the server for security: share level and user level. A share-level server makes some directory on a disk device (or other resource) available. An optional password may be required to gain access. Thus, any user on the network who knows the name of the server, the name of the resource, and the password has access to the resource. Share-level security servers may use different passwords for the same shared resource with different passwords allowing different levels of access. A user-level server makes some directory on a disk device (or other resource) available, but also requires the client to provide a username and corresponding password to gain access. User-level servers are preferred over share-level servers for any new server implementation, since organizations generally find user-level servers easier to administer as employees come and go. User-level servers may use the account name to check access-control lists on individual files, or may have one access control list that applies to all files in the directory.
When a user-level server validates the username and password presented by the client, an identifier representing that authenticated instance of the user is returned to the client in the Uid field of the response SMB. This Uid must be included in all further requests made on behalf of the user from that client. A share-level server returns no useful information in the Uid field. The user-level security model was added after the original dialect of the SMB protocol was issued, and subsequently some clients may not be capable of sending usernames and passwords to the server. A server in user-level security mode communicating with one of these clients may decide to permit a client to connect to resources even if the client has not sent user name information; for example, by deriving a user name as follows: if the client's computer name is identical to a username known on the server, and if the password supplied to connect to the shared resource matches the password for that username, an implicit user logon may be performed using those values. If this fails, the server may fail the request or assign a default account name of its choice (a so-called "guest account"). The value of Uid in subsequent requests by the client will be ignored and all access will be validated assuming the username selected. Servers built to CIFS specifications should operate in user mode.

4.8 Conclusion

By using CIFS to communicate between machines, clients and servers of various types can share files and printing functions in a generic, extensible way. CIFS supplies a rich set of messages, security features, high performance, and file-safety specifications (so that multiple machines can access the same file without locking problems). It has already attracted the support of much of the industry, and is already available on a variety of platforms

5.0 Netware protocols

5.1 Introduction

NetWare is a network operating system (NOS) that provides transparent remote file access and numerous other distributed network services, including printer sharing and support for various applications such as electronic mail transfer and database access. NetWare specifies the upper five layers of the OSI reference model and as such, runs on virtually any media-access protocol (Layer 2). Additionally, NetWare runs on virtually any kind of computer system, from PCs to mainframes. This chapter summarizes the principal communications protocols that support NetWare.

NetWare's client-server architecture supports remote access that is transparent to users through remote procedure calls. A remote procedure call begins when the local computer program running on the client sends a procedure call to the remote server. The server then executes the remote procedure call and returns the requested information to the local client.

The Figure below illustrates the NetWare protocol suite, the media-access protocols on which NetWare runs, and the relationship between the NetWare protocols and the OSI reference model. This chapter addresses the elements and operations of these protocol components.

The NetWare protocol suite maps to all OSI layers.

5.2 Internetwork Packet Exchange (IPX) Overview

Internetwork Packet Exchange (IPX) is the original NetWare network-layer (Layer 3) protocol used to route packets through an internetwork. IPX is a connectionless datagram-based network protocol and, as such, is similar to the Internet Protocol found in TCP/IP networks.

IPX uses the services of a dynamic distance vector-routing protocol (Routing Information Protocol [RIP]) or a link-state routing protocol (NetWare Link-State Protocol [NLSP]). IPX RIP sends routing updates every 60 seconds. To make best-path routing decisions, IPX RIP uses a "tick" as the metric, which in principle is the delay expected when using a particular length. One tick is 1/18th of a second. In the case of two paths with an equal tick count, IPX RIP uses the hop count as a tie breaker. (A hop is the passage of a packet through a router.) IPX's RIP is not compatible with RIP implementations used in other networking environments.

As with other network addresses, Novell IPX network addresses must be unique. These addresses are represented in hexadecimal format and consist of two parts: a network number and a node number. The IPX network number, which is assigned by the network administrator, is 32 bits long. The node number, which usually is the Media Access Control (MAC) address for one of the system's network interface cards (NICs), is 48 bits long.

IPX's use of a MAC address for the node number enables the system to send nodes to predict what MAC address to use on a data link. (In contrast, because the host portion of an IP network address has no correlation to the MAC address, IP nodes must use the Address-Resolution Protocol [ARP] to determine the destination MAC address.)

5.3 NetWare Transport Layer

The Sequenced Packet Exchange (SPX) protocol is the most common NetWare transport protocol at Layer 4 of the OSI model. SPX resides atop IPX in the NetWare Protocol Suite. SPX is a reliable, connection-oriented protocol that supplements the datagram service provided by the IPX, NetWare's network-layer (Layer 3) protocol. SPX was derived from the Xerox Networking Systems (XNS) Sequenced Packet Protocol (SPP). Novell also offers Internet Protocol support in the form of the User Datagram Protocol (UDP). IPX datagrams are encapsulated inside UDP/IP headers for transport across an IP-based internetwork.

5.4 NetWare Upper-Layer Protocols and Services

NetWare supports a wide variety of upper-layer protocols, including NetWare Shell, NetWare Remote Procedure Call, NetWare Core Protocol, and Network Basic Input/Output System.

The NetWare shell runs clients (often called workstations in the NetWare community) and intercepts application input/output (I/O) calls to determine whether they require network access for completion. If the application request requires network access, the NetWare shell packages the request and sends it to lower-layer software for processing and network transmission. If the application request does not require network access, the request is passed to the local I/O resources. Client applications are unaware of any network access required for completion of application calls.

NetWare Remote Procedure Call (NetWare RPC) is another more general redirection mechanism similar in concept to the NetWare shell supported by Novell. NetWare Core Protocol (NCP) is a series of server routines designed to satisfy application requests coming from, for example, the NetWare shell. The services provided by NCP include file access, printer access, name management, accounting, security, and file synchronization.

NetWare also supports the Network Basic Input/Output System (NetBIOS) session-layer interface specification from IBM and Microsoft. NetWare's NetBIOS emulation software allows programs written to the industry-standard NetBIOS interface to run within NetWare system.

5.5 NetWare Application-Layer Services
NetWare application-layer services include NetWare message-handling service (NetWare MHS), Btrieve, NetWare loadable modules (NLMs), and IBM Logical Unit (LU) 6.2 network-addressable units (NAUs). NetWare MHS is a message-delivery system that provides electronic mail transport. Btrieve is Novell's implementation of the binary tree (btree) database-access mechanism. NLMs are add-on modules that attach into a NetWare system. NLMs currently available from Novell and third parties include alternate protocol stacks, communication services, and database services. In terms of IBM LU 6.2 NAU support, NetWare allows peer-to-peer connectivity and information exchange across IBM networks. NetWare packets are encapsulated within LU 6.2 packets for transit across an IBM network.

5.6 Novell Directory Service(NDS)
NDS eDirectory8.5 is a full-service, platform-independent directory that serves as the foundation for myriad directory-enabled services. The number of directory-based applications is rapidly increasing, many of which provide crucial e-business functionality such as automated business-relationship management, supply-chain management, and electronic store fronts. Other services that directory-enabled products can provide include automated provisioning, enhanced security, customer profiling, electronic wallets, automated notification systems, customized Web interfaces and virtual private networks (VPNs).
Application service providers (ASPs), Internet service providers (ISPs), software developers, and other companies that aggressively compete in the Internet economy have made eDirectory their directory of choice, including Business Layers, CNN, PeopleSoft, Red Hat, Sun Microsystems, and Xircom. eDirectory 8.5 is also the foundation for several Novell® solutions such as Certificate Server, DirXML™, eGuide, iChain™, Net Publisher and Single Sign-on.
A recent report by the Aberdeen Group emphasizes that "today's directory must at least be extensible (able to maintain in-depth, hierarchically linked information about a range of `objects'—people, devices, applications, resources, and services); portable (able to work with multiple operating systems and applications); and scalable (able to maintain information on thousands of objects in the same directory)" ("Directory-Guided IT: A Planning Manifesto," Feb. 5, 1999). NDS eDirectory 8.5 meets the first two criteria exactly and it far exceeds the third. Its extensible schema and hierarchical tree structure allow you to include and manage nearly any type of object, its native Lightweight Directory Access Protocol (LDAP) support guarantees compatibility with other LDAP-based applications, and it scales to not only thousands of objects but to more than one billion.
This latest version of Novell Directory Services® (NDS) powers e-businesses running on NetWare®, Windows 2000, Windows NT, Solaris, Compaq Tru64 UNIX and Linux networks. New features in eDirectory 8.5—including DNS federation, filtered replication, and NDS iMonitor—give you additional tools for optimal directory operation and management. The advantages of providing your network with robust, scalable directory services, though already tremendous today, will only increase exponentially as demand for e-business functionality grows and vendors create solutions to fill it.
Benefits
• Enjoy the most fully developed and powerful directory service available • Lay the foundation for electronic commerce • Deploy directory-enabled applications • Access resources with a single login • Scale to any size directory • Keep your network resources secure • Protect your current investment in hardware and software • Reduce the cost of network computing • Enjoy superior schema flexibility • Support open standards • Easily manage your directory • Easily customize your directory to reflect your organization • Reduce network downtime • Use easy and fast application-development tools
5.7 NDS Architecture

The DS agent within an NDS server processes requests from three types of clients. Two, the NDAP and LDAP clients, have similar functionality and have full access to the directory, its entries, schema, operations, and background processes. The third client, the bindery client, has restricted access and must go through a bindery emulator which makes the directory appear as a flat bindery database and hides all functionality that isn't available in the NetWare 3.x bindery. See Bindery Services for more information about bindery emulation.
The DS agent also communicates with other NDS servers. The agent establishes a client connection with another NDS server and uses the connection to read, write, and search entry information, to perform partition operations, and to synchronize data. The following figure illustrates these communication paths.

[pic]
5.7.1 LDAP Clients and Applications
LDAP clients and applications currently interface with NDS through the Novell LDAP server. The LDAP server communicates directly with the DS agent on its server as well as with DS agents on other NDS servers. The client determines whether NDS returns referrals or uses referrals to traverse the tree and go remote to find the information on other NDS servers.
Since LDAP clients and applications do not require Novell client software, the LDAP application is responsible for establishing a connection and authenticating to the NDS server. It is also responsible for ensuring platform dependencies are met. For example, an LDAP application that uses Java and runs on a client workstation must have a JVM installed. An LDAP JNDI application must have a Java service provider installed.

5.7.2 NDAP Clients and Applications
NDAP clients and applications require Novell client software which includes support for various languages (C/C++, Java, and JNDI) and includes a JVM and a Java service provider. Scripting components have been built on top of these languages to allow additional methods for NDS access.
The client software establishes and manages the authentication to the NDS tree. It formulates the application's request into an NDAP request that is sent to the DS agent. The application can use the connections established by the client software or it can establish its own connections.

5.7.3 DS Agents
DS agents are responsible for managing the information stored in the NDS database and coordinating distributed operations with other servers. The agents manage all NDS requests, including the following:
Security (authentication and access control)
Entry management (add, delete, modify, search, read)
Partition operations (split, join, move)
Replica operations (add, delete, change type)
Replica and schema synchronization
Schema management (read and write)

5.7.4 Directory and Schema Database
The NDS database contains two main types of information: directory and schema. The directory contains entries with their attributes and values. Novell applications usually refer to entries as objects and attributes as properties. For more information on how NDS organizes, uses, and allows access to this information, see NDS Objects.
The schema portion of the database contains the object class definitions and the attribute definitions. These definitions control the information that can be added to the directory. For example, the schema contains a definition for a User object. This definition determines where in the NDS tree a user entry can be located, what the user entry can be named, and what attributes must have values before a user entry can be created.

5.7.5 Background Processes
The DS agent communicates with the background processes that keep the NDS database synchronized with other NDS servers and purged of obsolete data. These processes run without user intervention, although some allow for limited user management. For more information about the processes, see Background Processes. For information on commands for managing the processes, see Directory Services Trace Utilities.

5.7.6 OS Resources
The NDS server accesses operating system resources, such as disk space and memory, through a primitive layer interface. This layer isolates this functionality so that NDS can be implemented on multiple operating systems such as NetWare, NT, and Solaris.

6.0 Microsoft Windows 2000 Server

6.1 Introduction to Active Directory
Active Directory is an essential and inseparable part of the Windows 2000 network architecture that improves on the domain architecture of the Windows NT® 4.0 operating system to provide a directory service designed for distributed networking environments. Active Directory lets organizations efficiently share and manage information about network resources and users. In addition, Active Directory acts as the central authority for network security, letting the operating system readily verify a user's identity and control his or her access to network resources. Equally important, Active Directory acts as an integration point for bringing systems together and consolidating management tasks.
Combined, these capabilities let organizations apply standardized business rules to distributed applications and network resources, without requiring administrators to maintain a variety of specialized directories.
[pic]
Active Directory provides a single point of management for Windows-based user accounts, clients, servers, and applications. It also helps organizations integrate systems not using Windows with Windows-based applications, and Windows-compatible devices, thus consolidating directories and easing management of the entire network operating system. Companies can also use Active Directory to extend systems securely to the Internet. Active Directory thus increases the value of an organization's existing network investments and lowers the overall costs of computing by making the Windows network operating system more manageable, secure, and interoperable.

Active Directory lets organizations store information in a hierarchical, object-oriented fashion, and provides multi-master replication to support distributed network environments.

6.2 Hierarchical Organization

Active Directory uses objects to represent network resources such as users, groups, machines, devices, and applications. It uses containers to represent organizations, such as the marketing department, or collections of related objects, such as printers. It organizes information in a tree structure made up of these objects and containers, similar to the way the Windows operating system uses folders and files to organize information on a computer.
[pic]

Figure 1: Active Directory organizes information hierarchically to ease network use and management.
In addition, Active Directory manages the relationships among objects and containers to provide a single, centralized, comprehensive view. This makes resources easier to find, manage, and use in a highly distributed network. The Active Directory hierarchy is flexible and configurable, so organizations can organize resources in a way that optimizes their usability and manageability.
In Figure 1 above, containers are used to represent collections of users, machines, devices, and applications. Containers can be nested (created one-inside-the-other) to reflect accurately the company's organizational structure. In this case, marketing and personnel organization containers represent those respective departments, and their relationship to one another, within the company. Grouping objects in the directory lets administrators manage objects on a macro-level (as collections) rather than one-by-one. This increases management efficiency and accuracy while letting organizations align network management with their business processes.

6.3 Object-oriented Storage

As mentioned earlier, Active Directory stores information about network elements in the form of objects. These objects can be assigned attributes, which describe specific characteristics about the object. This lets companies store a wide range of information in the directory and tightly control access to it.
[pic]

Figure 2: Active Directory objects and attributes are protected by access control lists.
As illustrated in Figure 2 above, object- and attribute-level security lets administrators precisely control access to information stored in the directory. For example, a user object stored in the directory for Bob Jones has attributes for Bob's name, e-mail address, phone number, and Social Security number. The Active Directory lets administrators assign access privileges for each attribute of the object, as well as for the entire object. In this case, the system administrator has allowed global access to the Bob Jones object, but has locked access of the Social Security Number attribute.

6.4 Multi-Master Replication

To provide high performance, availability, and flexibility in distributed environments, the Active Directory uses multi-master replication. As illustrated in Figure 3 below, this lets organizations create multiple copies of the directory, known as directory replicas, and place them throughout the network. Changes made anywhere on the network are automatically replicated throughout the network. (This is in contrast to single-master replication in which all changes must be made to a single, authoritative directory replica).
[pic]

Figure 3: Active Directory supports multi-master replication for flexibility, high-availability, and performance.
For example, fully synchronized directory replicas can be made available to each location in a wide area network (WAN). Such a process can give users faster performance because they can locate resources using the local directory service rather than by traversing the WAN. These same directories could be managed locally or remotely depending on available administrative resources.

6.5 Shortcomings of Windows NT Directory.

Windows NT 4.0 and 3.51 have limitations in the following areas:

6.5.1 Scalability.
In Windows NT 4.0, the domain is stored in the Windows registry. Although these domains are theoretically limited to 40,000 objects (users, groups, and workstations), most practical deployments cannot exceed 10,000 objects before becoming extremely cumbersome and essentially unsupportable. Simple management tasks, such as changing a user's password, may require sorting through thousands of objects. Further complicating matters, the registry is always cached in the server's memory, so large domains require a lot of server RAM.

6.5.2 Replication and Fault Tolerance.
Windows NT 4.0 domain replication is built on a master-slave replication model: Domain changes (such as adding a user, creating a group, and changing a password) occur at the Primary Domain Controller (PDC), which then sends out updates to all Backup Domain Controllers (BDCs). Unfortunately, if the PDC is down or unreachable due to a LAN or WAN problem, the domain is unmanageable. The PDC is not only a single point of failure in terms of management but is also the sole source of domain information, creating inefficient replication in large companies that may include hundreds of BDCs.

6.5.3 Limited Object Types/No Extensibility. Conceived before cellular phones, pagers, and the Internet, the Windows NT 4.0 domain structure can't represent objects found in today's IT infrastructure. Windows NT 4.0 domains are limited to users, groups, and computers, with no capability to extend the domain for new types of objects (such as web servers and routers) or new attributes (such as pagers, cellular phones, and web site home pages).

6.5.4 No Hierarchy. Users, groups, and computers are equals within the domain, even if they exist in separate business divisions or departments. Simply stated, due to its flat nature, the Windows NT 4.0 domain can't represent a company's hierarchy or organizational chart.

6.5.5 Trust Relationships. Connecting multiple Windows NT 4.0 domains together requires trust relationships, which grow exponentially as domains are added. Trust relationships also increase management overhead and complicate domain-planning issues.

6.5.6 Delegation of Authority. Administrative rights within the Windows NT 4.0 domain system are all-or-nothing. It is impossible to delegate administrative rights to a subset of objects, such as giving a department manager rights to manage users within their department.

6.6 Improvements made in Active Directory

Active Directory includes many improvements to Windows NT 4.0 domains, such as the following:

6.6.1 Scalability. The Active Directory database is no longer stored in the registry but in a database similar to the database used by Microsoft Exchange. Microsoft claims that this new database supports up to 10 million objects per domain.

6.6.2 Replication and Fault Tolerance. Active Directory does not have a PDC/BDC hierarchy and, therefore, has no single point of failure within the domain management system. Active Directory also supports multimaster replication, whereby domain changes may occur on any domain controller. These changes are then automatically replicated to all other domain controllers.

6.6.3 Extensible Schema. The Active Directory schema supports many new types of objects and attributes and allows developers to define their own application- or product-specific domain objects.

6.6.4 Hierarchy.
Domain Organizational Units (OUs) allow companies to represent their business hierarchy within the domain structure.

6.6.5 Improved Trust Relationships.
Trust relationships are now both automatic and transitive in Active Directory, decreasing management overhead and domain-planning issues.

6.6.6 Delegation of Authority. Active Directory enables you to delegate administrative rights. For example, you can give a department manager administrative rights over users within his or her department.
Active Directory is obviously an improvement on the previous Windows NT 4.0 domain. However, because Active Directory is based on legacy domains, it continues to suffer from domain limitations--including limitations in security, delegation of rights, partitioning and replication, and deployment

7.0 COMPARISON OF NDS and ACTIVE DIRECTORY(AC)

7.1 Manageability
AD is still built on the premise of domains; in fact, it's best described as a bunch of domains leashed together. It lets you divide domains into separate administrative divisions called organizational units (OUs). This overcomes a severe limitation in the way administrative rights were doled out in earlier versions of NT. Now, an administrator can be given access to a subset of a domain, instead of the entire domain. With NT 4.0, administrative rights were an all-or-nothing proposition.

Organizational units also introduce hierarchical naming to NT domains, which allows naming conventions that mirror a company's real organizational structure, such as johnd.sales.ny.bigcorp (object.ou.ou.domain), instead of just johnd. Although this eases management to some degree, OUs are certainly not a panacea.

For example, to give an OU in AD access to an external resource like a branch office's server, all the user groups within the OU must also be added to that resource, just as in the current domain system. This is because unlike NDS, AD doesn't use the OU as a security principal. NDS's hierarchical trees represent both the security right of administrators and the access right of the security principals, which are objects that have security schemas applied to them.

Although this feature makes an NDS tree somewhat easier to manage than AD, it makes it impossible to create complex distributed groups. Novell recommends that user groups not have members from other partitions, which are NDS's equivalent of domains in AD. This makes it difficult to create geographically dispersed, or ad hoc groups. You'll also find it difficult to create a multidisciplinary group, one that includes engineers from one group, marketing people from another group, and finance people from yet another group--all of whom are evaluating the launch of a new product and need access to a new resource, such as the server in which all the files are stored. AD, on the other hand, introduces powerful groups that can span multiple domains. And these groups can accurately reflect any business process, such as groups based on a cost center or current project.

7.2 Scalability
Much like the management of NT 4.0 domains, scalability leaves a lot to be desired--both Microsoft and Novell acknowledge that. An NT 4.0 domain server houses all authentication information in the Registry. This singular design concept is a hindrance in many ways, especially to legacy NT domains. The most obvious problem is the lack of extensibility. As it is, legacy domains understand only five different types of objects: users, local groups, global groups, printers, and computers. Although these five object types may be all a network will ever need, they can't be extended. In other words, it's impossible to add, say, a user's e-mail address to his or her profile, which explains why applications such as Microsoft's own Exchange must use a completely separate directory from a standard domain.

These objects have no extensible schema. (Schemas are the attributes associated with an object.) For instance, a user in a legacy NT system would have only a name and a password. The new schema for users could include these items, plus an e-mail address, a personal Web page, location, parking spot, preferred method of contact (voice mail or e-mail), and the type of PC they're using, for example.

Microsoft's solution to the extensibility problem is to move the schema for objects out of the Registry and into a JET database, which is similar to the Access and Exchange engine. Microsoft says this database will be able to handle a million objects per domain--a huge leap from what is currently possible with the Registry.

More importantly, now that the schema is an object within a database, it can be customized. For example, all too often a new application has to be rolled out without adequately preparing users for it. With AD's directory structure, IT can query the directory for a list of 486-based PCs in a specified location to easily find computers that can't support a new application and have to be upgraded. This list can then be forwarded to the purchasing department, which in turn can order the necessary systems and then send the list to facilities. In this example, small changes in a schema affected the bottom line of three separate divisions of a company, not to mention sparing a user from the agony of trying to use an application on a system that simply can't handle it.

In contrast to Active Directory's JET-based database, NDS's Directory Information Base (DIB) uses a hierarchical file system reminiscent of the X.500 file system. The DIB stores all the partition information for NDS, whose partitions mimic much of the functionality of domains in an AD but lack some of the scalability. For example, Novell recommends no more than 5,000 objects in a single partition and that these partitions do not span WAN links. This limitation unfortunately forces you to install multiple servers to handle these partitions and then multiple servers to operate as backups. In addition, creating a separate partition at each branch office to avoid traversing WAN links can add to the complexity of your network.

7.3 Replication
To address the problem of managing multiple servers, both directories implement sophisticated replication and synchronization schemes. Each has tried to best the simple master-slave setup in NT 4.0, which uses a master--the primary domain controller (PDC)--to update the slaves--backup domain controllers (BDCs). This master-slave system is inferior because it requires all updates to occur at a single point (the PDC) and then be propagated out to the rest of the network (the BDCs). Instead of this master-slave scenario, both products attempt a master-master replication scheme, although AD is closer to a true multimaster scheme.

First, Novell's replication scheme uses three types of replicas: master, read/write, and read-only. The first instance of a partition is usually the master, and subsequent backup partitions are designated read/write or read-only. Both the master and its read/write counterpart can accept most changes, but only the master can administer the actual partition. Because of this limitation, NDS can't be considered a true master-master system; if the master goes down, no partition operations can be performed until the problem is fixed.

In contrast, AD has only one type of replica (a master), and any operation can be performed on it. AD also puts limitations on some actions such as schema updates, but it uses a token for these floating, single-master operations. With a token system, any replica can perform any operation; it just can't do it all the time. This makes AD's server-maintenance scheduling easy, because the token from a master can simply be passed before the server is downed. And while this server is down, schema updates can still be accomplished.

Another subtle, but notable, difference in the way each directory service handles replication is the unit of replication (the collection of data that must be copied). First, the only unit of replication in AD is the domain, and each server can hold only one domain. Because of this, you must provide a separate server that acts as a BDC for every single domain. For example, with AD, a network with 10 domains needs 20 servers: one for each domain and one for each of the backups. Although each domain requires its own BDC, one AD domain can contain as many as 10 million objects. But with NDS, only 12 servers are needed: 10 as the primaries and the other two acting as backups housing the entire 10 domains on each server for redundancy. NDS's 5,000-object limitation may cause a performance issue, but the dip in performance should be tolerable for the short time it takes to replace the primary server.

With all this replication, a robust means of synchronization must be implemented--one that takes into account updates occurring across the globe on multiple servers. Here again, the two companies chose different approaches. Microsoft opted for an Update Sequence Number (USN), which is a 64-bit number attached to every newly created object. Each time the object is modified, the USN is updated incrementally. And when servers replicate, they compare an object's USN and write the object with the higher one.

NDS uses a less sophisticated method, called time-stamp comparison, in which case it is assumed that time is synchronized throughout the entire enterprise and the higher time-stamped object will be written. Although NDS's method of handling time synchronization is cumbersome, it should be noted that synchronization will be necessary with NT 5.0, because Kerberos 5.0 requires it.

Where there's replication, there's a transport method. And yet again, Microsoft goes the extra mile by providing multiple options. AD includes various transport methods, such as SMTP and RPC (Remote Procedural Call), and NDS uses only a proprietary method. This means one AD server, for instance, can e-mail its updates to another server. This may not seem important, but it can indeed eliminate configuration headaches, as new ports won't have to be opened on firewalls to let replication traffic through.
Novell's current schemes, which are notorious for their poor use of bandwidth, will be updated in a future version of NDS. For instance, you'll be able to base replication on policies such as which parts of an object have changed, enabling NDS to hold off on replication if, for example, just a password has changed but force replication if a user is deleted.

7.4 Trust
Both new directories handle trust relationships much more efficiently than the NT 4.0 way. Every Windows NT administrator is familiar with the N*(N-1) problem, which alludes to NT 4.0's elaborate trust relationships. In this simple multiplication problem, N represents the number of NT domains, and the product of the problem represents the number of trust relationships required for any relationship. Thus, 15 domains would equal 15 * 14, or 210 trust relationships. This is so complex because trust in NT 4.0 is nontransitive; that is, if domain B trusts domain A, and domain C trusts domain B, domain C still won't have access to domain A.

AD includes automatic and completely transitive trust, as does NDS. However, as with all things directory related, the similarities end there. Intertwined with trust is the use of Access Control Lists (ACLs), which are attached to every object, defining who has access to it and what they can do with it.

To keep ACLs updated, NDS uses dynamic inheritance, which permits management and resource rights assigned to higher objects to automatically apply to subordinate objects when the modification is made, with the updates occurring at the time of queries. AD uses static inheritance, which forces an update to the ACL of all subordinate objects at the time of the modification.

This difference plays a huge role in the amount of data created for each object. If, for instance, you had to assign a new administrator to an organizational unit that contained 3,000 subordinate objects, NDS would have to update only one ACL at that time: the one for the OU itself. AD, on the other hand, would have to update the ACL on all 3,000 subordinate objects at the time of the modification. NDS's method reduces the amount of data, but it can introduce performance problems at runtime. This is because ACLs are updated when an object is queried, at which time permissions are determined by traveling up the directory and comparing the ACL of the queried object to that of every superior object in the tree.

7.5 Application Advantage
One of the most important aspects of a directory service is application support. In this area, Novell has dismally failed, giving Microsoft an optimistic shot at the upper hand. In the ten years of NDS's existence, only scant applications have been modified to take advantage of it. At the heart of this problem are the complex APIs necessary to write to NDS. Additionally, the schema of NDS's objects isn't exposed; thus applications must snap in at the desktop level. Novell has now adopted, Microsoft's Active Directory Services Interface (ADSI), providing a much cleaner and simpler interface to the directory structure than Novell's API or the cryptic LDAP API. Even though AD has not yet been released, Microsoft has garnered industrywide support for it, from the likes of Cisco Systems. Microsoft will also provide backward compatibility for applications by leaving the Security Accounts Manager (SAM) APIs intact.

Traditional applications such as Internet Information Server access the domain information stored in the Registry by way of the SAM. These same applications will now be able to access an AD without modification, although they won't be able to take advantage of AD's new features without being rewritten. Directory support will affect not only applications but also the underlying network infrastructure. Tomorrow's networks will use the directory to provision quality-of-service (QoS) parameters and offer features such as remote-access authentication.

7.6 Administration
NDS is more geared toward administration, allowing finer security control, more robust management between an entire NDS tree, and advanced features like ACL filters. These filters let you set up custom filters that direct the modification of an object when receiving a dynamic inheritance request. Using one of these filters, an administrator can still be dragged to the top of a tree and automatically gain access to all the subordinate objects. And if you want to deny access to one group only, you don't have to break out a new tree; just create a filter. Features like this show that NDS has been through an extensive shakeout, resulting in features real-world installations will need. However, the blue-screen, DOS-based utilities needed to administer NDS are inexcusable.

If the choice was between power or ease of use, Microsoft chose the latter with AD. Active Directory's GUIs are leagues ahead of Novell's offering, but the fact is when it comes to administering AD, the directory presents itself as a group of domains tied together with a shoestring. Management of AD is easy, but it must be done on a domain-by-domain basis--déjà vu.

Further, because currently there are no glaring technical differences between AD and NDS, the choice of a directory will likely come down to ISV support. This single criterion is Microsoft's ace in the hole. If NDS is unable to gain industry support in the form of ported applications, it's unlikely that developers will hop on the bandwagon when Microsoft presents a viable alternative. For these reasons, it is best to make sure all applications you buy are LDAP-compliant.

7.7 At a Glance NDS Vs Active Directory

|When it comes to... |
|who gets the nod... |
|and why... |
| |
|Availability |
|NDS |
|Although not a perfect directory service, NDS is here. Active Directory's ship date is still unknown. |
| |
|Developer support |
|Active Directory |
|Microsoft developed the ADSI standard (which Novell has adopted) for abstracting the complexities of LDAP's APIs. AD also |
|has the APIs needed to develop custom replication schemes. NDS does not. |
| |
|Interoperability |
|Active Directory |
|Active Directory offers support for a virtual container, which enables the attachment of an external directory at any |
|point in the directory. NDS doesn't interoperate with legacy domains. Also, Cisco has announced a license to port AD to |
|Unix. |
| |
|Migration & usability |
|Active Directory |
|Microsoft has demonstrated its migration utility, codeveloped with Computer Associates, which allows for automated |
|discovery and offline modeling of NetWare resources. It has also taken measures to ensure the cohabitation of legacy |
|domains with new Active Directories. Novell has not publicly demonstrated any migration tools and has made no provisions |
|for the cohabitation of existing domains, AD domains, and NDS. |
| |
|Replication |
|Active Directory |
|Although both vendors support a form of multimaster replication, Novell requires a single-master replica for all partition|
|modifications. Microsoft supports a "floating token," which can be passed between replicas so that at any time, a server |
|can be taken down and schemas can still be modified. |
| |
|Scalability |
|Active Directory |
|Novell limits the number of objects in a partition and further advises that partitions shouldn't span WANs. Microsoft |
|doesn't impose such limitations. |
| |
|Security |
|Active Directory |
|Both vendors have announced plans to support Kerberos and PKI, but Microsoft went a step further by supporting IPSec. |
| |

Reference:

1. Linux Unleashed ,book.
2. NFS Protocol Version 4 RFC 2624,3010.
3. Styx Architecture for distributed systems ,Rob Pike,Dennis M Ritchie
4. A Common Internet File System,Microsoft Documentation.
5. Novell Protocols, paper
6. Novell eDirectory 8.5 detailed view,online Documentation
7. NDS eDirectory Design 2000,online Documentation
8. Active Directory Overview, Windows 2000 server Documentation
9. Netware 5 Novell client ,white paper
10. Banyan VINES,cisco Documentation
11. Windows Networking Design Implementation Guide,Cisco Documentation
12. SAMBA file system, www.samba.org
13. Directory Enabled-Networking ,paper
14. SMB and Windows Networking ,paper