From 99bde6889d3d8b7a9e950c86c30e82662e1dacdd Mon Sep 17 00:00:00 2001
From: Gerald Carter Table of Contents
+ Table of Contents
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.
-
+with configuring a Samba Domain Controller as described in chapter on setting up Samba as a PDC.
+
This is one of the most difficult chapters to summarise. 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. 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
+effectively using a totally different approach. In the event that you should have a persistent
+concern that is not addressed in this book 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.
+Controller. 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 iand 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
@@ -41,8 +40,9 @@ lets consider each possible option and look at the pro's and con's for each theo
Arguments Against: Complexity
- Passdb Backend is tdbsam based, BDCs use cron based "net rpc vampire" to
- suck down the Accounts database from the PDC
+ Passdb Backend is tdbsam based, BDCs use cron based net rpc vampire to
+ obtain the Accounts database from the PDC and place them into the Samba SAM.
+ net rpc vampire is a Samba function of the "net" command.
Arguments For: It would be a nice solution
@@ -63,7 +63,7 @@ lets consider each possible option and look at the pro's and con's for each theo
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.
@@ -73,7 +73,7 @@ and with it a new form of the network logon service that has extended functional
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 Professional 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
@@ -131,32 +131,29 @@ one of the BDCs can be promoted to a PDC. If this happens while the original PDC
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:
-
-Several other things like a [homes] and a [netlogon] share also need to be set along with
+ Example 6.1. Minimal smb.conf for being a PDC
+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.
-
+chapter, for more information please refer to the chapter about samba as a PDC.
+
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 Controller 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
@@ -164,22 +161,22 @@ of the machines it gets back from the queries is a domain controller and can ans
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.
-
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
+ since Samba 2.2.5. 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:
- The Unix user database has to be synchronized from the PDC to the
+root# net rpc getsid
+
+ 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
@@ -199,23 +196,30 @@ Several things have to be done:
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:
-
-in the [global]-section of the smb.conf of the BDC. This makes the BDC
+ Example 6.2. Minimal setup for being a BDC
+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
+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.
+
+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 of 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 it's behaviour. Do NOT set this parameter except where an LDAP backend (ldapsam) is in use.
+
As this is a rather new area for Samba there are not many examples that 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
@@ -226,18 +230,15 @@ to proceed and the account expiry error will be reported.
The solution: use a more robust passdb backend, such as the ldapsam backend, setting up
an slave LDAP server for each BDC, and a master LDAP server for the PDC.
-
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.
+but this work has not been finished for Samba-3.
-Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a
+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.
-
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.
@@ -251,9 +252,9 @@ 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 very broken domain. This method is
not recommended. Try using LDAP instead.
-
- workgroup = SAMBA
- domain master = yes
- domain logons = yes
-
workgroup = MIDEARTH domain master = yes domain logons = yes
- root# net rpc getsid
-
- workgroup = SAMBA
- domain master = no
- domain logons = yes
-
workgroup = MIDEARTH domain master = no domain logons = yes idmap backend = ldapsam://slave-ldap.quenya.org Note