new smb.conf option

Mike Brodbelt m.brodbelt at
Mon Oct 9 16:05:21 GMT 2000

Jean Francois Micouleau wrote:
> On Mon, 9 Oct 2000, Kevin Colby wrote:
> > Eventually, wouldn't remote user/group configuration tools need to
> > able to manipulate the domain group list as well as the local group
> > list?  A parameter string in smb.conf would make that rather difficult.
> yep.
> So if someone comes to a solution to the group mapping problem, be my
> guest :-)
> And I mean a real solution, local/domain groups, builtin groups, samba as
> a pdc, samba as a domain member, with/without winbind.

One option would be to use a single tdb, or a group of tdb's to
represent all the Windows "authentication objects". You would need
support for Domain groups, Local Groups, Users, and Machines - basically
all the things that can have accounts in a Windows SAM. You could also
place trust account information in this repository.

Then, your code could allow RPC calls to create/destroy/change these
objects, and you could provide some command line *nix tools to
manipulate them, as well as allowing management via Windows GUI tools.
You would need to have all the normal Windows information, and also at
least one extra field to map Unix users to NT users, though this could
perhaps be solved by moving the current "username map" to a tdb.

Advantages of this that I can think of:-

1/ If you had a library that implemented the RPC calls, all your command
line tools could link against that. You could then have
Perl/Python/whatever bindings to this library, so scripting domain
administration would be a breeze.

2/ You could implement PAM type authentication modules that linked
against said library, if you felt the need.

3/ You'd get rid of machine accounts and such like from /etc/passwd.

4/ You separate the security critical files for your Windows domain from
the local security context.

5/ If this were all a bunch of TDB's, you could use rsync quite easily
for domain replication and redundancy.

6/ This kind of interface would allow for easy extensibility - If I
wanted to get rid of the tdb arrangement, it shouldn't be too hard to
replicate the lot in a network available RDBMS, and convince the back
end to talk to that.

7/ All your Windows type information is in one place - next time MS come
up with a new SID or similar that needs storing, it'd be obvious where
to put it.

8/ No really an advantage of this specifically, but, for migration, it
should be possible to use rpcclient or similar to query an NT PDC, and
populate a Samba machine's data structures. Then simply switch off the
NT box, and restart Samba, or such like. MS go out of their way to make
it easy for customers to ditch other products and move to theirs.
Perhaps Samba should try to smooth this road a bit...


1/ Would probably break a number of existing tools.

2/ Would require the code base to be shifted around to encapsulate all
the MS-RPC's in such a library.

This may be out of the window for reasons I haven't considered, but I
thought it might be worth mentioning...


(Who can't code this stuff nearly well enough to contribute yet, but
likes to stick the odd oar in anyway :-))

More information about the samba-technical mailing list