samba - Oct 2005 - Samba as a Multiple Domain Controller on a complex setup

Hi all,

I've run across this problem before but this time it's a rather  
complicated setup.

a. We have a long list of local users, all of them resident at the  
system level /etc/passwd, and on three different primary groups (each  
of these groups corresponds to what needs to be a different Windows  
Domain)

b. Some of these users will actually belong to more than one Domain,  
meaning that user 'joe' will be a regular user at domain1 and an  
administrator at domain2 but with no access at all to domain3

c. All of these users and domains will reside on the same, single  
machine

d. The LAN is segmentated into 3 different IP networks, but they all  
share the same 'cable'

e. The LAN(s) and the Samba DC are in different _physical_ networks,  
with a Linux router/fw in between them, that also gives access to the  
Internet link and to an external VPN. So network logons into the  
Samba Server must work across subnets.


                         (Internet link)
                                |
                               eth0
                                |
+-------+                  +---+----+
| Samba |                  |  Linux |
|  Box  +-eth0--------eth2-+ router +-eth3------( LAN )
+-------+                  |   FW   |
                            +--------+
                                |
                               eth1
                                |
                            (VPN link)


So far I've come with the following solution:

In the FW/Router box, the eth3 physical interfaces has 4 aliased,  
virtual interfaces, one for each of the three LAN segments (which  
will correspond to a different Windows Domain) plus what will be a  
public, DHCP assigned network: 10.1.0.0/24 (domain1), 10.2.0.0/24  
(domain2), 10.3.0.0/24 (domain3), 10.4.0.0/24 (public).

In the Samba box, the eth0 physical interface has also been aliased  
to 4 virtual interfaces, one for each Samba Domain Controller for  
each domain, plus one public fileserver for common access between my  
4 networks: 10.0.1.1 (DC1), 10.0.2.1 (DC2), 10.0.3.1 (DC3) and  
10.0.4.1 (public).

For the latter to work I also had to create the corresponding aliased  
interfaces to the eth2 physical interface of the FW/Router, as I want  
it to be the one that makes all the routing and filtering (instead  
of, say, route all traffic to the different DCs networks to the Samba  
box and enable routing there).

My idea is to run a different instance of Samba for each of these  
DCs, on a single virtual interface, with a different root directory  
and both config and runtime files for each one of them. To do that  
I've used the following smb.conf directives on the global section:

  root directory
  pid directory
  log file
  private dir
  smb passwd file

However, there are still some files being created and mantained in a  
generic location (namely tdb files like /var/lib/samba/) for which I  
can't seem to find a configuration directive, so I've tried changing  
to a smbpasswd backend on the DCs. But for cross-network browsing  
(and authenticacion) to work I need to make each of the DC instances  
of samba to work as a WINS server for its own domain, however the  
WINS database is also being shared between them (at /var/cache/samba/ 
wins.dat, along with browse.dat on the same location).

I haven't been able to isolate those files and I don't know how  
'hazardous' could it be for them to be shared by the different Samba  
instances (but common sense tells me that it isn't a good idea to do  
so), so I thought of enabling a generic WINS server instance of Samba  
(say, the public one at 10.0.4.1) for all of the Domains, and point  
each of the DC instances to it, but I don't know if that WINS server  
can be accessed/shared from different workgroups/domains

I have thought as a last resource to create a true chroot environment  
for each of the Samba instances to run in there, but for the sake of  
maintenance I'd prefer to avoid that unless it's the only possible  
solution.

I'd like to hear of your comments and recommendations on this  
situation, if this is the optimal solution or if it's possible to  
create a better environment that suits these needs.

Best regards,

--
Carlos Oliva G.
Igloo Sistemas Ltda.
carlos.oliva@igloo.cl - http://www.igloo.cl
Tel/Fax: +56 32 485634