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.
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:
SMB is available over:
NetBIOS is also available over:
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:
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:
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.
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.