Samba Directory Services, was Re: take on future events

[Dan Kaminsky]

>   * How to handle NT5?
>     - Samba should be able to function as an NT4 PDC
>       and get NT5 clients to use the domain model,
>       but what about new NT5 features?  Any thoughts?

A while ago, I was blathering that we shouldn't keep on following behind NT;
that we could actually implement features MS has failed to.  I haven't heard
a good reason why we can't implement a quick and dirty version of Directory
Services within the SMB system that already exists.  MS has given its
clients the ability to connect to multiple servers from a single director
using DFS, or Distributed File Systems.  The main flaw in the NT
implementation of this is that you can only run a single DFS off a given
host, and that the DFS's can only be one directory deep.  To illustrate:

NT DFS
-----------

\\Server\Share1 = \\OtherServer1
\\Server\Share2 = \\OtherServer2

but

\\Server\LameShares\Share1 != \\OtherServer3

I think MS was worried that \\Server\LameShares might be mapped to a machine
as well as to a deeper DFS structure, so they simply banned deep DFS
structures.  They *may* have linked the "Share" portion of a UNC name, which
of course would mean that deep DFS would be impossible to access by Windows
clients.

A further problem with DFS shares as implemented on NT is that there's no
means to check whether or not a given DFS share will be accessible--there
doesn't seem to be any lookup before a share is linked to.  This is a
serious flaw for environments(campuses) where machines go up and down all
the time.

Now, consider how Samba Directory Services could still operate under this
environment:

SDS
-------

Samba, unlike NT, can occupy multiple NetBIOS aliases, though as far as I
can tell all must reside under the same workgroup.  This gives Samba two
levels of server-definable heirarchy to play with.  We could have something
like this:

\\Printers\Downstairs_Printer = \\RandomBox\HPLJ5SIMX
\\Printers\Upstairs_Printer = \\DyingMachine\EpsonDotMatrix
\\LabComputers\Computer1 = \\Computer1

What'd be really nice under this system is, fitting with the Samba ethic,
maybe we can populate our DFS's with arbitrary and dynamically generated
contents.  Using a script, it'd be great to parse the present contents of
the WINS database and, say, have aliases and shares automatically generated
for each IP C class found.  For example, lets say the WINS database
contained the following:

COMPUTER1    10.0.30.1
COMPUTER2    10.0.30.5
COMPUTER3    10.0.35.58

A script should be able to easily set the following:

\\BUILDING1\COMPUTER1
\\BUILDING1\COMPUTER2
\\BUILDING2\COMPUTER3

This is *FAR* preferable to the Workgroup method of organizing machines, for
the following two reasons:

1)  Workgroup assignment occurs on the server side.  A good half of the
machines on campus are set to the wrong workgroup.  We don't have the
manpower to go room to room fixing that.

2)  Workgroups do not exist under UNC.  There's no way to see that COMPUTER3
is in Building 2 strictly by UNC unless SDS is used.

Of course, we'd have an issue with computers that were visible by NetBIOS
broadcast instead of by WINS, but sooner or later I guess I'll hack together
a solution to bridge the two databases.

This all isn't even taking into account the possibility that the DFS system
isn't tied into the Share portion of the UNC.  If it isn't, we could pretty
much go as crazy as NDS allows without the Novell side effects.

Feedback?