Hi there,
I have done some more research on the topic of setting a BDC. Several things have to be done:
1. The file private/MACHINE.SID identifies the domain. When a samba
server is first started, it is created on the fly and must never be changed again. This file has to be the same on the PDC and the BDC, so the MACHINE.SID has to be copied from the PDC to the BDC. Note that in the latest Samba 2.2.x releases, the machine SID (and therefore domain SID) is stored in the private/secrets.tdb database. This file cannot just be copied because Samba looks under the key SECRETS/SID/DOMAIN. where DOMAIN is the machine's netbios name. Since this name has to be unique for each SAMBA server, this lookup will fail.
2. A new option has been added to the smbpasswd(

command to help ease
this problem. When running smbpasswd -S as the root user, the domain SID will be retrieved from a domain controller matching the value of the workgroup parameter in smb.conf and stored as the new Samba server's machine SID. See the smbpasswd(

man page for more details on this functionality.
3. The Unix user database has to be synchronized from the PDC to the
BDC. This means that both the /etc/passwd and /etc/group have to be replicated from the PDC to the BDC. This can be done manually whenever changes are made, or the PDC is set up as a NIS master server and the BDC as a NIS slave server. To set up the BDC as a mere NIS client would not be enough, as the BDC would not be able to access its user database in case of a PDC failure. LDAP is also a potential vehicle for sharing this information.
4. The Samba password database in the file private/smbpasswd has to be
replicated from the PDC to the BDC. This is a bit tricky, see the next section.
5. Any netlogon share has to be replicated from the PDC to the BDC.
This can be done manually whenever login scripts are changed, or it can be done automatically together with the smbpasswd synchronization.
Finally, the BDC has to be found by the workstations. This can be done by setting [global]
workgroup = SAMBA
domain master = yes
domain logons = yes
encrypt passwords = yes
security = user
....
in the [global]-section of the smb.conf of the BDC. This makes the BDC only register the name SAMBA#1c with the WINS server. This is no problem as the name SAMBA#1c is a NetBIOS group name that is meant to be registered by more than one machine. The parameter 'domain master = no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS name is reserved for the Primary Domain Controller.
How do I replicate the smbpasswd file?
Replication of the smbpasswd file is sensitive. It has to be done whenever changes to the SAM are made. Every user's password change (including machine trust account password changes) is done in the smbpasswd file and has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.
As the smbpasswd file contains plain text password equivalents, it must not be sent unencrypted over the wire. The best way to set up smbpasswd replication from the PDC to the BDC is to use the utility rsync(1). rsync can use ssh(1) as a transport. ssh itself can be set up to accept only rsync transfer without requiring the user to type a password. Refer to the man pages for these two tools for more details.
Another solution with high potential is to use Samba's --with-ldapsam for sharing and/or replicating the list of sambaAccount entries. This can all be done over SSL to ensure security. See the Samba-LDAP-HOWTO
(
http://us3.samba.org/samba/ftp/docs/htmldocs/Samba-LDAP-HOWTO.html) for more details.
This info can be obtained from pretty much any samba mirror, I used this
URL:
http://us3.samba.org/samba/ftp/docs/htmldocs/Samba-BDC-HOWTO.htmlI understand what is has to be done, but I lack the knowledge of the e-smith configuration to be able to complete the full configuration of a BDC. When I tackled the first item that had to be completed I was presented with the problem of being unable to discover the location of "MACHINE.SID". When it comes to replication of the user-database I have completed a LDAP replication model using "slurpd.conf" and adding a few entires to "slapd.conf". I am not sure whether this would send sufficient user-account information for the BDC. I am going post all of the steps to complete a LDAP replication model in another posting to the mailing list.
I hope this is of interest to some of you out there. If anyone has any suggestions or questions, please feel free to fire when ready!

From
Ashley Shaw