&author.jht; &author.vl; Before you continue reading in this section, please make sure that you are comfortable with configuring a Samba Domain Controller as described in the Domain Control Chapter. This is one of the most difficult chapters to summarise. It matters not what we say here for someone will still draw conclusions and / or approach the Samba-Team with expectations that are either not yet capable of being delivered, or that can be achieved for more effectively using a totally different approach. Since this HOWTO is already so large and extensive, we have taken the decision to provide sufficient (but not comprehensive) information regarding Backup Domain Control. In the event that you should have a persistent concern that is not addressed in this HOWTO document then please email John H Terpstra clearly setting out your requirements and / or question and we will do our best to provide a solution. Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can operate with a slave LDAP server for the Account backend. This effectively gives samba a high degree of scalability. This is a very sweet (nice) solution for large organisations. While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will need to figure out precisely what is the best way to replicate (copy / distribute) the user and machine Accounts backend. The use of a non-LDAP backend SAM database is particularly problematic because Domain member servers and workstations periodically change the machine trust account password. The new password is then stored only locally. This means that in the absence of a centrally stored accounts database (such as that provided with an LDAP based solution) if Samba-3 is running as a BDC, the PDC instance of the Domain member trust account password will not reach the PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs this results in overwriting of the SAM that contains the updated (changed) trust account password with resulting breakage of the domain trust. Considering the number of comments and questions raised concerning how to configure a BDC lets consider each possible option and look at the pro's and con's for each theoretical solution: Solution: Passwd Backend is LDAP based, BDCs use a slave LDAP server Arguments For: This is a neat and manageable solution. The LDAP based SAM (ldapsam) is constantly kept up to date. Arguments Against: Complexity Passdb Backend is tdbsam based, BDCs use cron based "net rcp vampire" to suck down the Accounts database from the PDC Arguments For: It would be a nice solution Arguments Against: It does not work because Samba-3 does not support the required protocols. This may become a later feature but is not available today. Make use of rsync to replicate (pull down) copies of the essential account files Arguments For: It is a simple solution, easy to set up as a scheduled job Arguments Against: This will over-write the locally changed machine trust account passwords. This is a broken and flawed solution. Do NOT do this. Operate with an entirely local accounts database (not recommended) Arguments For: Simple, easy to maintain Arguments Against: All machine trust accounts and user accounts will be locally maintained. Domain users will NOT be able to roam from office to office. This is a broken and flawed solution. Do NOT do this. A Domain Controller is a machine that is able to answer logon requests from network workstations. Microsoft LanManager and IBM LanServer were two early products that provided this capability. The technology has become known as the LanMan Netlogon service. When MS Windows NT3.10 was first released it supported an new style of Domain Control and with it a new form of the network logon service that has extended functionality. This service became known as the NT NetLogon Service. The nature of this service has changed with the evolution of MS Windows NT and today provides a very complex array of services that are implemented over a complex spectrum of technologies. Whenever a user logs into a Windows NT4 / 200x / XP Profresional Workstation, the workstation connects to a Domain Controller (authentication server) to validate the username and password that the user entered are valid. If the information entered does not validate against the account information that has been stored in the Domain Control database (the SAM, or Security Accounts Manager database) then a set of error codes is returned to the workstation that has made the authentication request. When the username / password pair has been validated, the Domain Controller (authentication server) will respond with full enumeration of the account information that has been stored regarding that user in the User and Machine Accounts database for that Domain. This information contains a complete network access profile for the user but excludes any information that is particular to the user's desktop profile, or for that matter it excludes all desktop profiles for groups that the user may belong to. It does include password time limits, password uniqueness controls, network access time limits, account validity information, machine names from which the user may access the network, and much more. All this information was stored in the SAM in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0). The account information (user and machine) on Domain Controllers is stored in two files, one containing the Security information and the other the SAM. These are stored in files by the same name in the C:\WinNT\System32\config directory. These are the files that are involved in replication of the SAM database where Backup Domain Controllers are present on the network. There are two situations in which it is desirable to install Backup Domain Controllers: On the local network that the Primary Domain Controller is on if there are many workstations and/or where the PDC is generally very busy. In this case the BDCs will pick up network logon requests and help to add robustness to network services. At each remote site, to reduce wide area network traffic and to add stability to remote network operations. The design of the network, the strategic placement of Backup Domain Controllers, together with an implementation that localises as much of network to client interchange as possible will help to minimise wide area network bandwidth needs (and thus costs). The PDC contains the master copy of the SAM. In the event that an administrator makes a change to the user account database while physically present on the local network that has the PDC, the change will likely be made directly to the PDC instance of the master copy of the SAM. In the event that this update may be performed in a branch office the change will likely be stored in a delta file on the local BDC. The BDC will then send a trigger to the PDC to commence the process of SAM synchronisation. The PDC will then request the delta from the BDC and apply it to the master SAM. THe PDC will then contact all the BDCs in the Domain and trigger them to obtain the update and then apply that to their own copy of the SAM. Thus the BDC is said to hold a read-only of the SAM from which it is able to process network logon requests and to authenticate users. The BDC can continue to provide this service, particularly while, for example, the wide area network link to the PDC is down. Thus a BDC plays a very important role in both maintenance of Domain security as well as in network integrity. In the event that the PDC should need to be taken out of service, or if it dies, then one of the BDCs can be promoted to a PDC. If this happens while the original PDC is on line then it is automatically demoted to a BDC. This is an important aspect of Domain Controller management. The tool that is used to affect a promotion or a demotion is the Server Manager for Domains. Since version 2.2 Samba officially supports domain logons for all current Windows Clients, including Windows NT4, 2003 and XP Professional. For samba to be enabled as a PDC some parameters in the [global]-section of the smb.conf have to be set: workgroup = SAMBA domain master = yes domain logons = yes Several other things like a [homes] and a [netlogon] share also need to be set along with settings for the profile path, the users home drive, etc.. This will not be covered in this chapter, for more information please refer to the chapter on Domain Control. As of the release of MS Windows 2000 and Active Directory, this information is now stored in a directory that can be replicated and for which partial or full administrative control can be delegated. Samba-3 is NOT able to be a Domain Controller within an Active Directory tree, and it can not be an Active Directory server. This means that Samba-3 also can NOT act as a Backup Domain Contoller to an Active Directory Domain Controller. Every machine that is a Domain Controller for the domain SAMBA has to register the NetBIOS group name SAMBA<#1c> with the WINS server and/or by broadcast on the local network. The PDC also registers the unique NetBIOS name SAMBA<#1b> with the WINS server. The name type <#1b> name is normally reserved for the Domain Master Browser, a role that has nothing to do with anything related to authentication, but the Microsoft Domain implementation requires the domain master browser to be on the same machine as the PDC. An MS Windows NT4 / 200x / XP Professional workstation in the domain SAMBA that wants a local user to be authenticated has to find the domain controller for SAMBA. It does this by doing a NetBIOS name query for the group name SAMBA<#1c>. It assumes that each of the machines it gets back from the queries is a domain controller and can answer logon requests. To not open security holes both the workstation and the selected domain controller authenticate each other. After that the workstation sends the user's credentials (name and password) to the local Domain Controller, for valdation. Several things have to be done: The domain SID has to be the same on the PDC and the BDC. This used to be stored in the file private/MACHINE.SID. This file is not created anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is stored in the file private/secrets.tdb. Simply copying the secrets.tdb from the PDC to the BDC does not work, as the BDC would generate a new SID for itself and override the domain SID with this new BDC SID. To retrieve the domain SID from the PDC or an existing BDC and store it in the secrets.tdb, execute 'net rpc getsid' on the BDC. 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. 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. 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: workgroup = SAMBA domain master = no domain logons = yes 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. As this is a rather new area for Samba there are not many examples thta we may refer to. Keep watching for updates to this section. This problem will occur when occur when the passdb (SAM) files are copied from a central server but the local Backup Domain Controllers. Local machine trust account password updates are not copied back to the central server. The newer machine account password is then over written when the SAM is copied from the PDC. The result is that the Domain member machine on start up will find that it's passwords does not match the one now in the database and since the startup security check will now fail, this machine will not allow logon attempts to procede and the account expiry error will be reported. With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully implemented. The Samba Team is working on understanding and implementing the protocols, but this work has not been finished for version 2.2. With version 3.0, the work on both the replication protocols and a suitable storage mechanism has progressed, and some form of NT4 BDC support is expected soon. Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to service logon requests whenever the PDC is down. Replication of the smbpasswd file is sensitive. It has to be done whenever changes to the SAM are made. Every user's password change 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. rsync can use ssh as a transport. Ssh itself can be set up to accept *only* rsync transfer without requiring the user to type a password. The simple answer is YES. Samba's pdb_ldap code supports binding to a replica LDAP server, and will also follow referrals and rebind to the master if it ever needs to make a modification to the database. (Normally BDCs are read only, so this will not occur often).