Interoperability of PC Netlink
PC NetLink interoperates well with both Windows and Unix servers and clients, and with Windows 2000 when it's supporting NT 4.0 and earlier SMB servers.
PC NetLink interoperates well with both Windows and Unix servers and clients, and with Windows 2000 when it's supporting NT 4.0 and earlier SMB servers.
This paper is for customers and SEs who need to know to what extent various SMB programs will interwork with each other. It's read like a marketing feature-chart: if there is a X, a server provides a service which will work with every other server which has a X on the same line, and can be used with every client with a small x:
In this example, the first line says that Windows 9x/Millennium only uses Primary Domain Controller (PDC) functions in an restricted way (indicated by the white small x), while everything else interoperates fully.
Here's the first table describing the product's interoperability: it's followed by a detailed discussion of the individual cases on See Detailed Functionality Descriptions.
A server is marked X (providing a service) if it provides it natively and x (partially providing a service) if it does so only in part, or only in a backwards-compatibility mode
A client is marked X (using a service) for a service like PDC if it will use the service natively, or if it simply uses the service via the underlying OS. It is marked x (partially using a service) if it uses the service only partially or via a backwards-compatibility mode.
This part of the paper discusses the various services in more detail, with some suggestions for workarounds for missing services. While we cannot support all save a few products directly, we do wish to see them all interworking cleanly and appreciate suggestions and updates to this document from our readers.
Please note this is about interoperability: it may look like a features comparison, but it's purpose is not to praise particular products, but instead to indicate the (considerable) degree to which they all work with each other.
The Unix servers and clients mentioned here all run on Solaris, and most run on other Unix and Unix-like operating systems, including those on "appliance" computers or dedicated network fileservers such as Cobalt.
All of the SMB servers provide Primary Domain Controller (PDC) and Backup Domain Controller (BDC) functionality, and so each can serve as the primary machine of an NT domain. Similarly, all the clients can log on to domains as well as to the older "workgroups" without any special administration.
Windows 2000 clients connect using an NT 4.0 compatibility option, and Windows 95/98 clients use an even older backwards-compatibility option, but none require special configuration.
Samba servers can be the master authentication servers in workgroups, the immediate predecessors of NT domains.
PDCs and BDCs provide a combined authentication server and browse master for an NT domain: they have a master password file like an nis master, and also a dynamic list of machines active in the domain to allow clients to "browse" through a list of servers they might want to connect to. The latter is an early form of a service directory: see also See Active Directory. and See Browsing.
Currently, only Windows 2000 server and client support Active Directory (AD).
Active directory is a more scalable replacement for NT domains, based on Kerberos, LDAP and dynamic DNS: it replaces PDC/BDCs and WINS servers with AD domain servers, which can be organized into explicit hierarchies, much like DNS domain hierarchies. It also replaces browsing with directory lookups, allowing convenient searching for particular services. And it provides extensible replacements for various fixed-format registry and security tables.
Because it is quite new, substantial backwards compatibility is provided for Microsoft's own NT 4.0, Windows 95, 98 and Millennium servers and clients. This allows all the other clients compatible with them to interoperates until such time as Microsoft drops support for NT 4 and Win 95/98/Millennium.
Near-term and future Microsoft programs (such as Exchange2000 Server, the MS mail product) will depend on AD for both shared data such as mail routing information, and private configuration information that currently is placed in local registries.
All current servers can be file and print servers in workgroups and domains, ("Member Servers").
All clients can access member servers, just like they do PDC/BDC servers.
Member servers provide file and printer "shares", and provide their names to browse masters to allow clients to find them by browsing the "network neighborhood", as do PDCs/BDCs.
Previous to the creation of NT domains, all servers were member servers, and were members of workgroups. These had the same function as NT domains, but authentication was done on the individual servers. Unix servers often used nis or nis+ to provide the same authentication information to all member servers, making them members of a "Unix domain". See also See NIS/NIS+.
Wins is the "Windows Internet Name Service", a DNS-like service for finding NetBIOS names and addresses. All the servers will act as wins servers, and all except Samba will synchronize multiple wins servers. Samba only provides for single wins servers, although it will use multiple non-samba wins servers.
Wins is being phased out in Windows 2000 in favor of dynamic dns (see See Dynamic DNS) but will be supported in backwards compatibility mode for some considerable time. In NT 4, DHCP (see See DHCP) will update WINS with names and addresses if they are assigned via DHCP.
Wins does not support names like "www.sun.com": it only supports simple names like "www", which must be unique. Nevertheless, it is far less network-intensive than the Windows 3.1.1 scheme of broadcasting name queries to all the machines on your network.
When used with DNS, the usual practice of the servers is to use the first part of the DNS name as the NetBIOS name, so www.sun.com would be just "www".
Nis and nis+ are optionally provided by the operating system to Unix servers and clients: they in turn may use nis/nis+ to store user authentication information such as user name, uid/gid and, when not using Microsoft-format encrypted passwords.
Servers have used this OS functionality to add SMB servers to pre-existing Unix domains, without introducing NT authentication domains. This gave "workgroup" servers the same functionality as NT domain servers, and off-loaded the administration and authentication to preexisting nis server programs. This is still possible if encrypted passwords are turned off on the clients.
For those organizations using both nis and automounter to provide home directories via NFS, Samba has an nis-awareness option that provides the same automatic homedir service to windows users.
Lightweight Directory Access protocol is used by both Unix and Windows 2000 for "directory services". However, the two worlds are storing quite different data in it, so while Unixes may all support it, as of November 2000, none of the SMB servers were actually interworking using LDAP.
Clients other than Windows 2000 are just quietly using whatever the server sends, and are not aware of LDAP use.
LDAP is one of the main data-stores in active directory (see above, See Active Directory), along with DNS and Kerberos, but only Windows 2000 and TAS 6.0 use it extensively.
Other vendors appear to be doing the same thing as the Samba team: defining schemas that will eventually store user data needed by both Windows and Unix, and looking for other things they could usefully put into database-like tables.
The Distributed Host Control Protocol is used by Windows and Unix to provide dynamically allocated IP addresses to client machines. DHCP clients and servers are available on both Windows and Unix, and interwork reliably, including with third-party IP management software.
DHCP is used in Windows NT 4 and Windows 2000 to allocate IP addresses to client machines at boot time, choosing them dynamically from pools of available addresses. DHCP uses dynamic DNS facilities (see See Dynamic DNS) to update the DNS with new address assignments, allowing the newly configured machines to be found in DNS. NT 4 DHCP updates WINS similarly (see See WINS).
Like LDAP, Kerberos is used by both Unix and Windows 2000 for authentication. However, Windows uses a private binary data structure passed with the Kerberos data such that only Windows 2000 servers can authenticate Windows 2000 clients. Interworking is currently limited to Windows 2000 servers and clients.
In principle, Windows 2000 servers can authenticate non-windows clients, as those clients don't need the private data.
Kerberos is an authentication protocol and secure password storage service. Like LDAP it is one of the main data-stores in active directory (see above, See Active Directory), along with DNS, but only Windows 2000 uses it extensively. Other vendors support the standard version of the protocol, which cannot currently provide the required binary data structure to Windows 2000 clients.
Both Windows 2000 and Unix support dynamic updates to DNS. Servers and clients who use DNS use it transparently. Servers and clients using Samba or NT 4.0 WINS servers can interwork with those using DNS because the MS and Samba WINS implementation can update DNS servers via the RFC 2136 protocol.
All the servers and clients support "browsing", browse servers and browse server elections.
Browsing is a pair of services, the first of which lists machines in the "network neighborhood" that are in the same domain/workgroup. This requires a server per subnet, but it's deliberately light-weight so the Windows clients can provide them. The machine, called a "local browse master" is elected via a simple scheme which prefers to give the job to stable servers. The job of global browse master for an NT domain is always grabbed by the PDC.
Once a master is elected, clients send queries to it, and it returns list of machines to display in the network neighborhood.
If a user clicks on a machine in the neighborhood, a normal SMB over TCP/IP connection is made and the names disk and printer shares are returned. Clicking on these starts a logon process, followed by a connection, just as if a user has selected "map remote disk" in Windows Explorer.
Until NT 4.0 patchlevel 3, servers could provide single sign-on to Unix and Windows by arranging to update their password files when Windows clients changed them. This update could include Unix (and any other) password files at the same time. This changed with patch SP 3, when a Windows-specific encryption was introduced.
This is only an issue when trying to synchronize Windows and Unix passwords: it does not affect clients logging onto servers. Any PDC or BDC can process logins from clients.
Single-signon is possible if a Windows-compatible encryption scheme is used. This is done by Solaris TAS, by Digital Unix and by Samba on Linux using Pluggable Authentication Modules. It is achievable in principle if the servers use Kerberos and authenticate via a Windows 2000 domain controller.
The change to encrypted passwords was made to avoid the sending of plain-text passwords across the internet by Internet Explorer, which supports the CIFS (SMB) protocols.
All the servers will provide logon scripts (batch files) and profiles (desktop configuration files) to Windows clients connecting to them.
Unix and Mac clients do not require either of these files, so only Windows clients are shown as using them.
NT and PC NetLink servers support directory replication. Clients are generally unaware of the replication, and quietly interwork with it.
Replication is the duplication and updating of directories between servers, in a master-slave relationship. The well-known use of directory duplication is for the export of login scripts from the PDC to the BDC(s), so that updates can be applied in just one place (the PDC).
NT, PC NetLink, Samba and TAS servers can take part in trust relationships. Windows 2000 servers can take part in trust relationships with NT via a NT 4.0 backwards-compatibility option.
Trust relationships are bilateral agreements between NT domains, such that one domain trusts all the users of another, and will let them use services as if they were full-fledged members. Windows 2000 Active directory provides for hierarchies of subdomains, a more general facility, with similar results.
Syntax TAS and all Windows servers and clients can interwork using NetBEUI. PC NetLink and Samba servers cannot: they use only TCP/IP. All clients and servers interwork via TCP/IP.
The NetBEUI is a simple, efficient and historically widely-used protocol, but it's non-routable. It is supported by Windows clients and servers, and was the original transport protocol for Windows SMB servers.
TCP/IP is routable, and, with the advent of the Internet, is now far more widely available than NetBEUI. It is universally supported by servers and clients.
All servers provide file service, and all clients can use it. Windows clients can provide file service to a limited degree.
All servers provide some level of access permissions bits or access control lists (ACLs). NT 4.0, PC NetLink support NT ACLs, Samba and TAS support POSIX ACLs, which are a large subset of NT ACLs.
All servers also support a small set of DOS attributes (notably "read-only").
Modern Windows clients support NT ACLs and DOS attributes, while Unix and Mac clients support just unix permissions.
Windows 2000 servers and clients have both additional and renamed ACLs in NTFS filesystems.
All servers support Windows case insensitivity and "8.3" names, although they use slightly different "name mangling" algorithms.
Old DOS filesystems only supported single-case names, which were limited to eight characters, a single X, and 3 additional characters, all in one case. Unix allows mixed-case names of up to 255 characters, and Windows 95/98 and NT allows 127, but in only one case. Each server therefor has a facility to map unix names to 8.3 single-case names to the clients on demand. The resulting names usually look like INTEGR~9.BAT, which is an 8.3 representation of Integration.bak.
At this time, we don't know of a server which will convert Unix LF line-endings automatically to Windows CR/LF line-endings. This normally requires human judgement.
The DAVE client for Macintosh can use Apple's "PC Exchange" service to covert files. Stand-alone file conversion programs are available for all servers and clients.
All servers have facilities to let unauthenticated users obtain basic services, which may include listing disk and printers shares and, optionally, printing.
Most servers have Windows-compatible filesystem times and time-synchronization programs. TAS and previous versions of PC NetLink did not have time synchronization programs.
Windows filesystems timestamps have only a two-second granularity, and Windows stores creation dates for files and directories instead of the attribute modification dates stored by Unix. This requires emulation in order for Windows "make" programs and programming environments to avoid recompiling files unnecessarily.
NT and Samba servers support change notification.
This feature allows a browser program such as NT Explorer to register an interest in updates to a given directory. In turn, this allows the browser to update it's window quickly after a change.
All servers support DOS and Windows locks and client-side file caching, called "oplocks".
Oplocks are locks used to allow opportunistic caching on the clients. When only one client is using a file, the client can take a lock in order to be told if another client wants the file: at that point it must write the file back to the server and stop caching. The local caching is beneficial in reducing the load on pc-based NT servers, and also improves client performance substantially.
Unix clients will trigger oplock processing, but updating files with "cat" will not. Windows and Mac clients which have files cached won't know the file has changed, so it is important to use Unix clients to update files that are being shared by Unix and Windows users.
DOS and NT filesystem locks are somewhat different from Unix/Posix locks, and require emulation. Servers vary to the extent that they support the same locks on Unix, SMB and NFS: PC NetLink and Samba support locks between Windows and Unix, but not between Windows and NFS.
All servers provide print shares to the clients. Most provide full control and status reporting to the client, but the mechanisms are different.
PC NetLink provides full control and status, but by defaults limits printing to printers attached to the server. Samba provides connections to all printers, but cannot guarantee status or print cancellation with remote printers.
All servers support the provision of the (invisible) PRINTER$ share, containing client-downloadable printer driver files.
These files are not printer drivers in the Unix sense, but instead are collections of filters, plus tables of the allowable fonts and printer capabilities. The table are used by Windows applications to provide WYSIWYG behavior when editing the files. Once edited, the print jobs are sent through the filters in the "drivers" to put them into the proper format, and only then sent to the server.
PC NetLink and Samba servers allow creation of multiple logical SMB servers on a single physical host. In addition, PC NetLink and TAS can create one SMB server per domain on a multiprocessor supporting Solaris domains (a form of virtual host)
This allows different server processes to identify themselves as, for example, ACCOUNTING, SALES and ENGINEERING, but only require one set of disks and printers, and a single administration team.
Unix TCP/IP includes a mechanism to detect dead clients and report this to SMB servers. This reduces server load if Windows users habitually turn their machine off rather than logging out.
Without dead-client detection via keepalive, the SMB server would have to wait, possibly forever, for the long-dead client to return. The default time period is 4 hours, but some servers can reduce this to a few minutes.
In general, servers for the SMB protocol interwork seamlessly at the protocol level, and vary moderately in areas that have to do with the mapping of Windows services and ideas to Unix ones. Customers with different SMB servers can depend on their compatibility "on the wire" and can pick and choose products for their fit with the organization and Unix.
PC NetLink 1.0 was derived from AS/U, Advanced Server for Unix, a port of the Windows NT SMB server, described at http://www.att.com/unix_asu/whatis.html. Older versions are available on most Unix systems.
DAVE is a client for Apple Macintosh, available from Thursby Software Systems at http://www.thursby.com/products/dave.htm.
Sharity is a gateway between the SMB protocol and NFS: any NFS client can access SMB servers via Sharity. It is a product of from Objective Development at http://www.obdev.at/Products/Sharity.html.
TAS is a server for SMB, Novel and AppleTalk, running on a Unix platform, available from Syntax Systems Inc., at http://www.syntax.com/totalnet.
Samba is an open source SMB server available from http://ww.samba.org, and is used by HP and SGI, as well as in dedicated network file-server products such as Cobalt.