From 992f1e6b8f86b346fddd266b04d29cde69585633 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 7 Apr 2004 10:15:11 +0000 Subject: Add all the source files from the old CVS tree, add the 5 missing chapters from the HOWTO and add jht's Samba by Example book. (This used to be commit 9fb5bcb93e57c5162b3ee6f9c7d777dc0269d100) --- docs/howto/BDC.xml | 637 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 637 insertions(+) create mode 100644 docs/howto/BDC.xml (limited to 'docs/howto/BDC.xml') diff --git a/docs/howto/BDC.xml b/docs/howto/BDC.xml new file mode 100644 index 0000000000..72dc69938e --- /dev/null +++ b/docs/howto/BDC.xml @@ -0,0 +1,637 @@ + + + + &author.jht; + &author.vl; + &person.gd;LDAP updates + + +Backup Domain Control + + +Before you continue reading this section, please make sure that you are comfortable +with configuring a Samba Domain Controller as described in Domain Control. + + + +Features and Benefits + + +This is one of the most difficult chapters to summarize. It does not matter 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 far more +effectively using a totally different approach. In the event that you should have a persistent +concern that is not addressed in this book, please email John H. Terpstra +clearly setting out your requirements and/or question and we will do our best to provide a solution. + + + +SAM backendLDAP +Samba-3 is capable of acting as a Backup Domain Controller (BDC) to another Samba Primary Domain +Controller (PDC). A Samba-3 PDC can operate with an LDAP Account backend. The LDAP backend can be +either a common master LDAP server, or a slave server. The use of a slave LDAP server has the +benefit that when the master is down, clients may still be able to log onto the network. +This effectively gives Samba a high degree of scalability and is an effective solution +for large organizations. If you use an LDAP slave server for a PDC, +you will need to ensure the master's continued availability - if the +slave finds it's master down at the wrong time, you will have +stability and operational problems. + + + +replicationSAM +While it is possible to run a Samba-3 BDC with non-LDAP backend, that +backend must allow some form of 'two way' propagation, of changes +from the BDC to the master. Only LDAP is capable of this at this stage. + + + +SAM backendnon-LDAP +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 BDC 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 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, +let's consider each possible option and look at the pros and cons for each possible solution. +Following table lists possible design configurations for a PDC/BDC infrastructure. +netrpc +SAM backendldapsam +SAM backendtdbsam +replicationSAM + + +Domain Backend Account Distribution Options + + + + + + + PDC BackendBDC BackendNotes/Discussion + + + + Master LDAP Server + Slave LDAP Server + The optimal solution that provides high integrity. The SAM will be + replicated to a common master LDAP server. + + + Single Central LDAP Server + Single Central LDAP Server + + A workable solution without fail-over ability. This is a usable solution, but not optimal. + + + + tdbsam + tdbsam + net rpc vampire + + Does not work with Samba-3.0.0; may be implemented in a later release. The downside of this solution + is that an external process will control account database integrity. This solution may appeal to sites + that wish to avoid the complexity of LDAP. The net rpc vampire is used to + synchronize domain accounts from the PDC to the BDC. + + + + tdbsam + tdbsam + rsync + + Do not use this configuration. + Does not work because the TDB files are live and data may not have been flushed to disk. + Use rsync to synchronize the TDB database files from the PDC to the BDC. + + + + smbpasswd file + smbpasswd file + + Do not use this configuration. + Not an elegant solution due to the delays in synchronization. + Use rsync to synchronize the smbpasswd file from the PDC to the BDC. + Can be made to work using a cron job to synchronize data from the PDC to the BDC. + + + + +
+ + + + +Essential Background Information + + +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 a 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 complex array of +services that are implemented over an intricate spectrum of technologies. + + + +MS Windows NT4-style Domain Control + + +Whenever a user logs into a Windows NT4/200x/XP Professional Workstation, +the workstation connects to a Domain Controller (authentication server) to validate that +the username and password the user entered are valid. If the information entered +does not match account information that has been stored in the Domain +Control database (the SAM, or Security Account Manager database), 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). + + + +replicationSAM +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:\Windows NT\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 localizes as much + of network to client interchange as possible will help to minimize wide area network + bandwidth needs (and thus costs). + + + + +The inter-operation of a PDC and its BDCs in a true Windows NT4 environment is worth +mentioning here. 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 synchronization. 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. + + + +Samba-3 can not participate in true SAM replication and is therefore not able to +employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will +not create SAM update delta files. It will not inter-operate with a PDC (NT4 or Samba) +to synchronize the SAM from delta files that are held by BDCs. + + + +Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 can not +function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows +NT4 can function as a BDC to its own type of PDC. + + + +The BDC is said to hold a read-only of the SAM from which +it is able to process network logon requests and authenticate users. The BDC can +continue to provide this service, particularly while, for example, the wide area +network link to the PDC is down. A BDC plays a very important role in both the +maintenance of Domain Security as well as in network integrity. + + + +In the event that the NT4 PDC should need to be taken out of service, or if it dies, +one of the NT4 BDCs can be promoted to a PDC. If this happens while the original NT4 PDC is on +line, it is automatically demoted to an NT4 BDC. This is an important aspect of Domain +Controller management. The tool that is used to effect a promotion or a demotion is the +Server Manager for Domains. It should be noted that Samba-3 BDCs can not be promoted +in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. + + + +Example PDC Configuration + + +Beginning with 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. +Refer to following configuration for an example of the minimum required settings. + + + +Minimal smb.conf for a PDC in Use With a BDC &smbmdash; LDAP Server on PDC. +workgroup&example.workgroup; +passdb backendldapsam://localhost:389 +domain masteryes +domain logonsyes + + + +Several other things like a [homes] and a +[netlogon] share also need to be set along with +settings for the profile path, the user's home drive, and so on. This is not covered in this +chapter; for more information please refer to Domain Control. + + + + + + +LDAP Configuration Notes + + +When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server +for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers, however, +many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs +may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the +entire network. + + + +When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure +this in the /etc/openldap/slapd.conf file. It must be noted that the DN of a +server certificate must use the CN attribute to name the server, and the CN must carry the servers' +fully qualified domain name. Additional alias names and wildcards may be present in the +subjectAltName certificate extension. More details on server certificate names are in RFC2830. + + + +It does not really fit within the scope of this document, but a working LDAP installation is +basic to LDAP enabled Samba operation. When using an OpenLDAP server with Transport Layer Security +(TLS), the machine name in /etc/ssl/certs/slapd.pem must be the +same as in /etc/openldap/sldap.conf. The Red Hat Linux startup script +creates the slapd.pem file with hostname localhost.localdomain. +It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the +certificate is recreated with a correct hostname. + + + +Do not install a Samba PDC on a OpenLDAP slave server. Joining client machines to the domain +will fail in this configuration because the change to the machine account in the LDAP tree +must take place on the master LDAP server. This is not replicated rapidly enough to the slave +server that the PDC queries. It therfore gives an error message on the client machine about +not being able to set up account credentials. The machine account is created on the LDAP server +but the password fields will be empty. + + + +Possible PDC/BDC plus LDAP configurations include: + + + + + PDC+BDC -> One Central LDAP Server. + + + PDC -> LDAP master server, BDC -> LDAP slave server. + + + PDC -> LDAP master, with secondary slave LDAP server. + + BDC -> LDAP master, with secondary slave LDAP server. + + + PDC -> LDAP master, with secondary slave LDAP server. + + BDC -> LDAP slave server, with secondary master LDAP server. + + + + +In order to have a fall-back configuration (secondary) LDAP server one would specify +the secondary LDAP server in the &smb.conf; file as shown in following example. + + + + +Multiple LDAP Servers in &smb.conf; +... +passdb backend +ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org" +... + + + + + + +Active Directory 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 cannot be an Active Directory server. This means that Samba-3 also cannot +act as a Backup Domain Controller to an Active Directory Domain Controller. + + + + + +What Qualifies a Domain Controller on the Network? + + +Every machine that is a Domain Controller for the domain MIDEARTH has to register the NetBIOS +group name MIDEARTH<#1c> with the WINS server and/or by broadcast on the local network. +The PDC also registers the unique NetBIOS name MIDEARTH<#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. + + + +Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to +Network Browsing: Discussion for more information regarding TCP/IP network protocols and how + SMB/CIFS names are handled. + + + + + +How does a Workstation find its Domain Controller? + + +There are two different mechanisms to locate a domain controller, one method is used when +NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP +network configuration. + + + +Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast +messaging over UDP, as well as Active Directory communication technologies. In this type of +environment all machines require appropriate DNS entries. More information may be found in +DNS and Active Directory. + + + +NetBIOS Over TCP/IP Enabled + +An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a +local user to be authenticated has to find the Domain Controller for MIDEARTH. It does this +by doing a NetBIOS name query for the group name MIDEARTH<#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 validation. + + + + + +NetBIOS Over TCP/IP Disabled + + +An MS Windows NT4/200x/XP Professional workstation in the realm quenya.org +that has a need to affect user logon authentication will locate the Domain Controller by +re-querying DNS servers for the _ldap._tcp.pdc._msdcs.quenya.org record. +More information regarding this subject may be found in DNS and Active Directory. + + + + + + + +Backup Domain Controller Configuration + + +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: +SID + + + + + 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: + + +&rootprompt;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. + + + +replicationSAM + 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 are 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. + + + + + +Example Configuration + + Finally, the BDC has to be found by the workstations. This can be +done by setting Samba as shown in the next example. + + + +Minimal setup for being a BDC +workgroup&example.workgroup; +passdb backendldapsam:ldap://slave-ldap.quenya.org +domain masterno +domain logonsyes +idmap backendldap:ldap://slave-ldap.quenya.org + + + +In the [global]-section of the &smb.conf; of the BDC. This makes the BDC +only register the name MIDEARTH<#1c> with the WINS server. This is no +problem as the name MIDEARTH<#1c> is a NetBIOS group name that is meant to +be registered by more than one machine. The parameter +domain masterno +forces the BDC not to register MIDEARTH<#1b> which as a unique NetBIOS +name is reserved for the Primary Domain Controller. + + + +idmap backend +winbindd +The idmap backend will redirect the winbindd utility to +use the LDAP database to resolve all UIDs and GIDs for UNIX accounts. + + + +Server TypeDomain Member +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 backendldap: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. + + + + + + +Common Errors + + +As this is a rather new area for Samba, there are not many examples that we may refer to. +Updates will be published as they become available and may be found in later Samba releases or +from the Samba web site. + + + +Machine Accounts Keep Expiring + + +Machine Trust Accounts +This problem will occur when the passdb (SAM) files are copied from a central +server but the local Backup Domain Controller is acting as a PDC. This results in the application of +Local Machine Trust Account password updates to the local SAM. Such updates +are not copied back to the central server. The newer machine account password is then over +written when the SAM is re-copied from the PDC. The result is that the Domain Member machine +on start up will find that its passwords do 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 proceed and the account expiry error will be reported. + + + +The solution is to use a more robust passdb backend, such as the ldapsam backend, setting up +a slave LDAP server for each BDC, and a master LDAP server for the PDC. + + + + + +Can Samba Be a Backup Domain Controller to an NT4 PDC? + + +replicationSAM +No. The native NT4 SAM replication protocols have not yet been fully implemented. + + + +Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.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. + + + + + +How Do I Replicate the smbpasswd File? + + +replicationSAM +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. + + + +As said a few times before, use of this method is broken and flawed. Machine trust +accounts will go out of sync, resulting in a broken domain. This method is +not recommended. Try using LDAP instead. + + + + + +Can I Do This All with LDAP? + + +The simple answer is yes. Samba's pdb_ldap code supports binding to a replica +LDAP server, and will also follow referrals and re-bind 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). + + + + + -- cgit