1: Introduction

At the time of writing, Samba is a 350 thousand line project of approximately twenty man-years development over the last ten years. It has within it an implementation of at least four separate Microsoft-compatible Protocols. It consists of at least fifteen independent services on each of those protocols. Incredibly, many people still think of Samba as just one program.

Samba TNG is in fact a suite of programs and libraries that make a fully-compliant POSIX system look, to all intents and purposes, like a Windows NT File, Print and Login Server. That includes full Windows NT Primary Domain Controller functionality.

There are unique problems associated with implementing Windows NT File, Print and Login Services on a POSIX platform, not least that the underlying POSIX OS knows absolutely ZERO about the Windows NT Security Model (which is originally the VAX/VMS Security Model, from the time when Dave Cutler and his team moved en-masse from DEC to Microsoft).

Understanding how to correctly map between the Unix and Windows NT security models, and narrowing down the best possible places to perform this mapping has taken an extraordinarily long time to crystallise. This has resulted in SURS http://cb1.com/~lkcl/cifs/draft-lkcl-sidtouidmap-00.txt and a first practical, if specifically targetted, implementation of SURS in Winbind (cite winbind ref).

There follows a brief description of the protocols and services included in Samba.

1.1: Protocols

The protocols implemented in Samba include:

NetBIOS
documented for TCP/IP in RFC 1001 and RFC 1002

SMB
documented originally in 1983 by IBM and The Open Group, and updated since by Microsoft as CIFS

DCE/RPC
documented originally by Apollo / HP and The Open Group, reimplemented by Microsoft as MSRPC and documented in their MSDN.

These protocols, and the services running on them, are inter-dependent along clearly defined lines. For example, DCE/RPC can use a surprisingly large number of protocols as its transport. There follows a short list of the known available protocols:

  • TCP/IP
  • UDP/IP
  • IPX/SPX
  • NetBIOS
  • NETBEUI
  • HTTP
  • DECnet 3.0
  • SMB

    • SMB is available over:

  • TCP/IP
  • NetBIOS

    • NetBIOS is also available over:

  • TCP/IP / UDP/IP
  • IPX/SPX
  • NETBEUI

    • 1.2: Services

    The services that available on NetBIOS include:

    WINS
    NetBIOS (aka Windows Internet) Naming Service

    Browsing
    A means to locate computers (aka the Network Neighbourhood)

    Domain Management
    A means to manage computers in a Windows NT Domain (aka Domain Master Browsing)

    Messaging
    A means to send messages to a user or a group of users

    HTML
    Microsoft's Web Server, IIS, can use NetBIOS as a transport.

    There are also several obsolete protocols. NetBIOS is actually a full transport that used to be implemented inside network cards.

    The services that are available over SMB include:

    File Sharing
    This is the core of the SMB protocol's purpose: to allow files to be accessed over a network.

    Print Sharing
    Printers can also be accessed remotely.

    Port Sharing
    There is a little-known means to access and share Modems and Parallel Ports over SMB.

    IPC
    Inter-process Communication. A means to communicate specific information between programs.

    Named Pipes
    SMB also provides a means for applications to easily locate and access remote services, and that includes DCE/RPC.

    The services that are available over DCE/RPC are too numerous to mention all of them here, particularly as DCE/RPC is used as the underlying mechanism behind DCOM. The ones that are relevant to this project are:

    SAM
    Secure Accounts Manager.

    LSA
    Local Security Authority.

    NETLOGON
    Windows NT Network Logon Service. Provides the back-end to the Username, Domain, Password Dialog box. Also provides Backup Domain Controller Synchronisation Services. aka "A hacker's delight".

    spoolss
    Spooler Service (Windows NT Total Print Management) - one of the largest and comprehensive DCE/RPC services in the whole of the Windows NT Operating System.

    svcctl
    Service Control Manager.

    winreg
    Windows Registry. For some obscure reason, winreg also provides the means to remotely shut down a Windows NT system.

    srvsvc
    Server Service. Mostly provides a means to list and manage SMB-related services such as shares, DFS (Microsoft's Distributed File System) Mount points.
    The other most popularly known DCE/RPC-based services and programs are Exchange (and Outlook), as MAPI is available over DCE/RPC, and MS-SQL 7 and MS-SQL 2000. Even Microsoft's DFS and WINS Services have a DCE/RPC Administrative Interface.

    All of this is undocumented. Microsoft fully realises the implications of releasing information regarding these protocols. It would be possible, with a specification, to implement a fully-compatible client and server of any one of these services, and so no information is publicly available on how they work. So, instead, network traffic must be observed for months at a time running these programs hour after hour, experimenting until it becomes clear how they operate.

    1.3: Paper's Aims

    When confronted with this plethora of protocols and services, it comes as no great surprise when people get quite seriously confused about what goes where, and just how much is involved. Leaving aside peoples' surprise over how Samba is able to outperform Windows NT and still be more reliable, their estimates of Samba's its performance and manageability vary considerably and way often off-the-mark: Samba TNG, with its ability to masquerade fully in a Windows NT Domain environment, is just as easily manageable with the standard Windows NT Administrative tools as it is using the standard Unix command-line interface.

    It is also quite daunting and a little discouraging to developers who may wish to take an active interest in the projects mentioned in this document when Samba is spread across a single combined codebase of 350 thousand lines - and only going up.

    So, this paper outlines the main aims behind TNG's architecture, explaining which components should do what, in the hope that this will encourage a more diverse range of development efforts, and also to help clarify the protocol boundaries that have long since become blurred, in the eyes of many Network Administrators and Open Source Developers alike, into one single application's domain.