Introduction to SMB - http://samba.anu.edu.au/cifs/docs/what-is-smb.html
Information on Kerberos (mostly regarding WY2K implementation) -
    http://www.developer.com/journal/techworkshop/032400_kerberos.html
 

SMB is such a horrible protocol it can't be properly documented, as the real
spec for SMB is "what Windows clients do on the wire". This is one of the
reasons that Samba is becoming so popular as an OEM SMB solution, as
writing one's own SMB server from scratch is hard. People look at the
published specs, think, well this can't be so bad, and start coding. Then they
find the way the clients deviate from the spec and they're in a world of pain.
Many of them end up licensing Microsoft server code, or start using Samba.
SGI, Veritas, HP, Cobalt, Whistle (now IBM) and too many others to count
are all shipping Samba based products now.

Some questions about Samba I hope to answer by the end of this project:

1) Samba's Effect of Kerberos on Win2000
Kerberos is an authentication protocol (ie. it tells a server who you are).
It is not an authorization protocol (ie. it doesn't tell a server what you can
do). Authentication is all well and good, but in order to have useful
network security you also need authorization as well. In UNIX (and NT)
this is provided by your user id and a list of group id's to which you belong
(on NT both user and group lists are SID's - security ID's - globally unique
128 bit ID's).

Kerberos allows a user to get tokens called 'tickets' that allow them access
to services on the network. The initial ticket a user must obtain is called a
Ticket-granting -ticket, or TGT.

On standard UNIX implementations of kerberos, a users name (called a
"principal") is used to get a TGT and then this name is looked up using the
standard UNIX password database mechanisms (ie. /etc/passwd, NIS,
NIS+, LDAP etc.) into a uid and a list of associated gid's that represent the
authorization of that individual. When this user wants access to files or SYSV
shared objects (the only securable things in standard UNIX) then the uid/gid
list is checked against the access control of the object (usually user/group/world triple)
and access is allowed or denied. Custom servers that use Kerberos tickets (eg. an
Oracle database) use their own authentication mechanisms based on the name of
the ticket owner (kerberos tickets contain proof of the ticket owner in the ticket).

2) Samba's Virtual File System (VFS) layer's useability with
relational databases
The VFS layer has been integrated into the HEAD branch, it will be a
part of Samba 3.0 (along with the MS-DFS work done by Shirish at
Veritas). It is *amazingly* cool, and will allow us to duplicate the
functionality of Oracle8i (ie. the Windows client direct access via the
filesystem into a database) using *any* database for which the POSIX
bridge library is written (Informix, Sybase, Interbase, PostgreSQ, MySQL
etc.).

It appears that VFS will allow Samba to mount a database and give transparent
usage of that database to a regular Windows/Samba client. I thought it would be
interesting to brainstorm different things that you could do with this option.
 
 
 

3) SMB vs. NFS
The complexity of SMB is one of the main reasons that NT is so unstable
(Win2K isn't much better here) as it is not possible to do a safe and clean
kernel implementation of the entire protocol. They even process DCE/RPC
calls in kernel space for heavens sake!

Please don't ask for Samba to become part of the Linux kernel for speed
purposes (as some have done). Both Linus and the Samba Team don't
want this. I'd rather be slightly slower but running on a robust system, than
have kernel speed and NT stability :-).

As part of their CIFS/9000 product HP have added some UNIX to
UNIX SMB calls - allowing SMB to have UNIX-like semantics.
However, the SMB locking semantics are very crude compared to POSIX
locking semantics (no overlapping lock ranges, no spits/merges, no lock
upgrades/downgrades) so it makes a poor fit for a UNIX to UNIX
protocol (unless POSIX compatible locking calls are added).

SMB wasn't designed remember, it grew like a particularly ugly wart - with
layers and layers of glop added onto a simple DOS filesharing interface, so
it has no consistency at all. It has a basic header size of *39* bytes for
heavens sake !

NFS is also terrible, but for different reasons . The only nice
feature of SMB is server-terminated leases (aka Oplocks).
 

4)Access Control List Support
HP has contributed a large chunk of code to do
exactly this. The target is to get this code into the 2.0.8 release (sometime
before August). I already have code that allows a UNIX user and group
list to be displayed at the NT dialog box (I checked it in this morning), but
it will need to be heavilly re-written before it goes into the production
release. Currently it enumerates the *entire* passwd/group database each
time (imangine *that* CPU load on a busy NIS server :-). As for the ACL
work - we are adding a layer such that Samba will send NT style ACLs
into that layer on set, and get NT style ACLs back from the layer on get.
This layer will be replaceable so that the ACLs can be mapped into the
native ACLs that the filesystem supports, IRIX ACLs on XFS, HP ACLs
on HPUX, Solaris ACLs on Sun (you get the idea).

The default mapping will be the current user/group/world mapping we have
now. Unfortunately, until Linux gets support for POSIX ACLs then we will
only be able to use the default mapping on Linux. We have always been
against using a non-OS layer (ie. dot files containing ACLs) in Samba to
control access as this is just a *home* for security race conditions (just ask
the AT&T "Advanced Server for UNIX" vendors :-). Samba will always
map the native filesystem permissions into NT ACLs and vice versa, and
allow the underlying OS to perform the real access control. That's the only
secure way. The challenge is to provide a mapping between NT ACLs and
native filesystem ACLs that doesn't violate the principal of least suprises
for the admin.
 
 

5)  PDC Server Compatibility / Replacement
There are those of us (Andrew, myself), who see Samba as a UNIX
file/print server with PDC-like features. And there are others (Luke mainly)
who want to completely replicate all features of NT, whether they fit into
the UNIX model or not. My question to you is - why do you want Samba
to "save" you from NT? If you want the features of a PDC you know
where to get them - www.microsoft.com (and they're not very stable). The
Microsoft domain model is a *very* poor fit into the UNIX world, and it's
a constant battle to mangle the NT semantics to fit them into a UNIX
world. I *like* the UNIX model. I think it's a better, more stable, more
proven model than NT. I guess our (Andrew & I) motto is "as close to NT
as neccessary, but no closer".

Having said all that, Luke has made remarkable progress in the
Samba-TNG branch (The Next Generation, for all you Star Trek fans out
there :-) in getting NT PDC support working. However, this is not yet
production code. The current plan is to mine the TNG branch and bring
back as much of the working and *secure* PDC stuff to the HEAD
branch (which will become Samba 3.0) as possible, and provisinally ship
this by October this year (expect this to slip - no - *depend* on that date
slipping :-).

As Samba is having to reverse engineer *hundreds* of undocumented MS-RPC
calls, there will always be some areas where we don't have the exact functionality
that they do as a PDC/BDC. I'm not too unhappy with that - like I say, I consider that
model an inferior one anyway (and *definately* a less secure model - you
can trust me on that :-). If you need NT - you know where it lives....... just
don't complain when it crashes on you.

6) SAMBA and Active Directory
With the release of Windows2000 we saw the introduction of a new
computer, user, group managment system. Microsoft included some
ability to be backwards compatible with WindowsNT Servers,
Microsoft also included the ability to run Windows2000 in "native
mode." which effectivly disallows any NT client/server from
participating in it's user management. How will this affect Samba?
Will Samba include Windows2000 "native mode" support, also will
the AD tools used to administer a Windows2000 Server be able to
administer a Samba server?

Not initially. AD is just an LDAPv3 server. Samba doesn't serve
LDAP. However, Gerald Carter (one of the Samba Team) is getting ready
to start working on Samba/LDAP integration, so that a Samba server will
get all the user/group authentication info from an LDAP server. You really
need to ask this question of the OpenLDAP team, as it's important that
OpenLDAP get to LDAPv3 as soon as possible to work with AD.

This is another one of those "Samba won't become a version of NT on
UNIX" questions. We will just co-operate with other services running on
UNIX to provide the same functionality.

Right now Win2k client compatibility is being addressed (Samba 2.0.7)
but to be honest so few of our users are actually using it in anything more
than test servers right now it's too early to say what effect (if any) Win2k
will have.

Running Win2k in "native mode" will, as you point out, prevent any current
NT server from participating. Hands up how many companies are going to
convert *all* their NT servers to Win2k immediately..... you there at the
back, you're not fooling anyone... you know Microsoft, put your hand
down - you know that NT 4.x will be on your network for several years at
least.