| The creation of a BDC requires some steps to prepare the Samba server before smbd is executed for the first time. These steps are outlines as follows : -
The domain SID has to be the same on the PDC and the BDC. In Samba versions pre-2.2.5, the domain SID was stored in the file private/MACHINE.SID . The domain SID is now stored in the file private/secrets.tdb . This file is unique to each server and can not be copied from a PDC to a BDC, the BDC will generate a new SID at start-up. It will over-write the PDC domain SID with the newly created BDC SID. There is a procedure that will allow the BDC to aquire the Domain SID. This is described here. To retrieve the domain SID from the PDC or an existing BDC and store it in the secrets.tdb , execute: root# net rpc getsid -
Specification of the ldap admin dn is obligatory . This also requires the LDAP administration password to be set in the secrets.tdb using the smbpasswd -w mysecret . -
Either ldap suffix or ldap idmap suffix must be specified in the smb.conf file. -
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. Alternately, the PDC is set up as an NIS master server and the BDC as an 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. NIS is by no means the only method to synchronize passwords. An LDAP solution would also work. -
The Samba password database must be replicated from the PDC to the BDC. Although it is possible to synchronize the smbpasswd file with rsync and ssh , this method is broken and flawed, and is therefore not recommended. A better solution is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC. -
The netlogon share has to be replicated from the PDC to the BDC. This can be done manually whenever login scripts and changed, or it can be done automatically using a cron job that will replicate the directory structure in this share using a tool like rsync . 5.3.1 Example Configuration Finally, the BDC has to be found by the workstations. This can be done by setting Samba as shown in Example 5.3. Example 5.3 Minimal setup for being a BDC workgroup = MIDEARTH passdb backend = ldapsam:ldap://slave-ldap.quenya.org domain master = no domain logons = yes idmap backend = ldap:ldap://slave-ldap.quenya.org 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. The idmap backend will redirect the winbindd utility to use the LDAP database to resolve all UIDs and GIDs for UNIX accounts. N OTE  Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it allows greater flexibility in how user and group IDs are handled in respect to NT Domain User and Group SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values will be consistent on the PDC, all BDCs and all Domain Member servers. The parameter that controls this is called idmap backend . Please refer to the man page for smb.conf for more information regarding its behavior. |
The use of the idmap backend = ldap:ldap://master.quenya/org option on a BDC only make sense where ldapsam is used on a PDC. The purpose for an LDAP based idmap backend is also to allow a domain-member (without its own passdb backend) to use winbindd to resolve Windows network users and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on Domain Member servers. |
