mirror of
https://github.com/samba-team/samba.git
synced 2025-08-03 04:22:09 +03:00
John Terpstra
committed by
Gerald W. Carter
Gerald W. Carter
parent
6a953e9f9e
commit
01a4f306d7
@ -46,9 +46,11 @@ you will have stability and operational problems.
|
||||
<indexterm><primary>two-way</primary><secondary>propagation</secondary></indexterm>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
|
||||
While it is possible to run a Samba-3 BDC with a non-LDAP backend, that
|
||||
backend must allow some form of "two-way" propagation of changes
|
||||
from the BDC to the master. Only LDAP has such capability at this stage.
|
||||
<indexterm><primary>propagate</primary></indexterm>
|
||||
While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of
|
||||
"two-way" propagation of changes from the BDC to the master. At this time only LDAP delivers the capability
|
||||
to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it
|
||||
is preferable for the PDC to use as its primary an LDAP master server.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -141,12 +143,18 @@ possible design configurations for a PDC/BDC infrastructure.
|
||||
<title>Essential Background Information</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>domain controller</primary></indexterm>
|
||||
<indexterm><primary>logon requests</primary></indexterm>
|
||||
<indexterm><primary>LanMan</primary></indexterm>
|
||||
<indexterm><primary>Netlogon</primary></indexterm>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm>network<primary></primary><secondary>logon</secondary><tertiary>service</tertiary></indexterm>
|
||||
<indexterm><primary>Windows NT3.10</primary></indexterm>
|
||||
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
|
||||
@ -158,6 +166,13 @@ services that are implemented over an intricate spectrum of technologies.
|
||||
<title>MS Windows NT4-style Domain Control</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>domain controller</primary></indexterm>
|
||||
<indexterm><primary>authentication server</primary></indexterm>
|
||||
<indexterm><primary>username</primary></indexterm>
|
||||
<indexterm><primary>password</primary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm>
|
||||
<indexterm><primary>domain control database</primary><see>SAM</see></indexterm>
|
||||
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
|
||||
@ -167,6 +182,11 @@ codes is returned to the workstation that has made the authentication request.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>account information</primary></indexterm>
|
||||
<indexterm><primary>machine accounts database</primary></indexterm>
|
||||
<indexterm><primary>profile</primary></indexterm>
|
||||
<indexterm><primary>network access profile</primary></indexterm>
|
||||
<indexterm><primary>desktop profile</primary></indexterm>
|
||||
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
|
||||
@ -181,6 +201,10 @@ in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).
|
||||
|
||||
<para>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>%SystemRoot%\System32\config</primary></indexterm>
|
||||
<indexterm><primary>C:\WinNT\System32\config</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
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 <filename>%SystemRoot%\System32\config</filename> directory.
|
||||
@ -195,21 +219,29 @@ There are two situations in which it is desirable to install BDCs:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
On the local network that the PDC 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.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm>
|
||||
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
|
||||
BDCs, 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).
|
||||
remote network operations. The design of the network, and the strategic placement of
|
||||
BDCs, 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).
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
<indexterm><primary>user account database</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>trigger</primary></indexterm>
|
||||
The interoperation 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
|
||||
@ -223,6 +255,10 @@ trigger them to obtain the update and then apply that to their own copy of the S
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>SAM</primary><secondary>replication</secondary></indexterm>
|
||||
<indexterm><primary>SAM</primary><secondary>delta file</secondary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
Samba-3 cannot 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 interoperate with a PDC (NT4 or Samba)
|
||||
@ -230,12 +266,17 @@ to synchronize the SAM from delta files that are held by BDCs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>domain security</primary></indexterm>
|
||||
The BDC is said to hold a <emphasis>read-only</emphasis> 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
|
||||
@ -244,23 +285,29 @@ maintenance of domain security as well as in network integrity.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 online, 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 cannot be promoted
|
||||
in this manner because reconfiguration of Samba requires changes to the &smb.conf; file.
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>promoted</primary></indexterm>
|
||||
<indexterm><primary>demoted</primary></indexterm>
|
||||
<indexterm><primary>reconfiguration</primary></indexterm>
|
||||
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 online, 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 cannot be
|
||||
promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy
|
||||
enough to manuall change the &smb.conf; file and then restart relevant Samba network services.
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>Example PDC Configuration</title>
|
||||
|
||||
<para>
|
||||
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 <smbconfsection name="[global]"/> section of the &smb.conf; have to be set.
|
||||
Refer to <link linkend="minimalPDC">the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on
|
||||
PDC section</link> for an example of the minimum required settings.
|
||||
<indexterm><primary>domain logon</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
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
|
||||
<smbconfsection name="[global]"/> section of the &smb.conf; have to be set. Refer to <link
|
||||
linkend="minimalPDC">the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC
|
||||
section</link> for an example of the minimum required settings.
|
||||
</para>
|
||||
|
||||
<example id="minimalPDC">
|
||||
@ -274,6 +321,8 @@ PDC section</link> for an example of the minimum required settings.
|
||||
</example>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>profile path</primary></indexterm>
|
||||
<indexterm><primary>home drive</primary></indexterm>
|
||||
Several other things like a <smbconfsection name="[homes]"/> and a
|
||||
<smbconfsection name="[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
|
||||
@ -287,6 +336,9 @@ chapter; for more information please refer to <link linkend="samba-pdc">Domain C
|
||||
<title>LDAP Configuration Notes</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm>
|
||||
<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
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
|
||||
@ -295,36 +347,51 @@ entire network.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure
|
||||
this in the <filename>/etc/openldap/slapd.conf</filename> 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.
|
||||
<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm>
|
||||
<indexterm><primary>LDAP</primary><secondary>server</secondary></indexterm>
|
||||
<indexterm><primary>CN</primary></indexterm>
|
||||
<indexterm><primary>DN</primary></indexterm>
|
||||
<indexterm><primary>RFC2830</primary></indexterm>
|
||||
When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in
|
||||
the <filename>/etc/openldap/slapd.conf</filename> 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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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 <filename>/etc/ssl/certs/slapd.pem</filename> must be the
|
||||
same as in <filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script
|
||||
creates the <filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote>
|
||||
It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the
|
||||
certificate is re-created with a correct hostname.
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>OpenLDAP</primary></indexterm>
|
||||
<indexterm><primary>transport layer security</primary><see>TLS</see></indexterm>
|
||||
<indexterm><primary>/etc/ssl/certs/slapd.pem</primary></indexterm>
|
||||
<indexterm><primary>slapd.pem</primary></indexterm>
|
||||
<indexterm><primary>Red Hat Linux</primary></indexterm>
|
||||
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 <filename>/etc/ssl/certs/slapd.pem</filename> must be the same as in
|
||||
<filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script creates the
|
||||
<filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote> It is impossible to
|
||||
access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is re-created with
|
||||
a correct hostname.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For preference, 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 therefore 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. Unfortunately, some sites are
|
||||
unable to avoid such configurations, and these sites should review the
|
||||
<smbconfoption name="ldap replication sleep"/> parameter, intended to slow down Samba sufficiently
|
||||
for the replication to catch up. This is a kludge, and one that the
|
||||
administrator must manually duplicate in any scripts (such as the
|
||||
<smbconfoption name="add machine script"/>) that
|
||||
they use.
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>OpenLDAP</primary></indexterm>
|
||||
<indexterm><primary>machine account</primary></indexterm>
|
||||
<indexterm><primary>credentials</primary></indexterm>
|
||||
<indexterm><primary>replication</primary></indexterm>
|
||||
<indexterm><primary>duplicate</primary></indexterm>
|
||||
Do not install a Samba PDC so that is uses an LDAP 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
|
||||
therefore 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. Unfortunately, some
|
||||
sites are unable to avoid such configurations, and these sites should review the <smbconfoption name="ldap
|
||||
replication sleep"/> parameter, intended to slow down Samba sufficiently for the replication to catch up.
|
||||
This is a kludge, and one that the administrator must manually duplicate in any scripts (such as the
|
||||
<smbconfoption name="add machine script"/>) that they use.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -369,6 +436,12 @@ Servers in &smb.conf; example</link>.
|
||||
<title>Active Directory Domain Control</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>MS Windows 2000</primary></indexterm>
|
||||
<indexterm><primary>Active Directory</primary></indexterm>
|
||||
<indexterm><primary>directory</primary></indexterm>
|
||||
<indexterm><primary>replicated</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>domain controller</primary></indexterm>
|
||||
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
|
||||
@ -382,15 +455,22 @@ act as a BDC to an Active Directory domain controller.
|
||||
<title>What Qualifies a Domain Controller on the Network?</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>DMB</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>WINS</primary></indexterm>
|
||||
<indexterm><primary>NetBIOS</primary></indexterm>
|
||||
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 (DMB), a role
|
||||
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 (DMB), a role
|
||||
that has nothing to do with anything related to authentication, but the Microsoft domain
|
||||
implementation requires the DMB to be on the same machine as the PDC.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>broadcast</primary></indexterm>
|
||||
<indexterm><primary>name registration</primary></indexterm>
|
||||
<indexterm><primary>SMB/CIFS</primary></indexterm>
|
||||
Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to
|
||||
<link linkend="NetworkBrowsing">Network Browsing</link>,<link linkend="netdiscuss">Discussion</link>
|
||||
for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled.
|
||||
@ -402,12 +482,16 @@ for more information regarding TCP/IP network protocols and how SMB/CIFS names a
|
||||
<title>How Does a Workstation find its Domain Controller?</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>locate domain controller</primary></indexterm>
|
||||
<indexterm><primary>NetBIOS</primary></indexterm>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>DNS</primary></indexterm>
|
||||
<indexterm><primary>broadcast messaging</primary></indexterm>
|
||||
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
|
||||
@ -417,6 +501,10 @@ environment all machines require appropriate DNS entries. More information may b
|
||||
<sect3>
|
||||
<title>NetBIOS Over TCP/IP Enabled</title>
|
||||
<para>
|
||||
<indexterm><primary>Windows NT4/200x/XP</primary></indexterm>
|
||||
<indexterm><primary>domain controller</primary></indexterm>
|
||||
<indexterm><primary>logon requests</primary></indexterm>
|
||||
<indexterm><primary>credentials validation</primary></indexterm>
|
||||
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
|
||||
@ -432,6 +520,10 @@ password) to the local domain controller for validation.
|
||||
<title>NetBIOS Over TCP/IP Disabled</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>realm</primary></indexterm>
|
||||
<indexterm><primary>logon authentication</primary></indexterm>
|
||||
<indexterm><primary>DNS</primary></indexterm>
|
||||
<indexterm><primary>_ldap._tcp.pdc._msdcs.quenya.org</primary></indexterm>
|
||||
An MS Windows NT4/200x/XP Professional workstation in the realm <constant>quenya.org</constant>
|
||||
that has a need to affect user logon authentication will locate the domain controller by
|
||||
re-querying DNS servers for the <constant>_ldap._tcp.pdc._msdcs.quenya.org</constant> record.
|
||||
@ -446,13 +538,19 @@ More information regarding this subject may be found in <link linkend="adsdnstec
|
||||
<title>Backup Domain Controller Configuration</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
The creation of a BDC requires some steps to prepare the Samba server before
|
||||
&smbd; is executed for the first time. These steps are as follows:
|
||||
<indexterm><primary>SID</primary></indexterm>
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<listitem><para>
|
||||
<indexterm><primary>SID</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>private/secrets.tdb</primary></indexterm>
|
||||
<indexterm><primary>private/MACHINE.SID</primary></indexterm>
|
||||
<indexterm><primary>domain SID</primary></indexterm>
|
||||
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 <filename>private/MACHINE.SID</filename>.
|
||||
The domain SID is now stored in the file <filename>private/secrets.tdb</filename>. This file
|
||||
@ -462,6 +560,11 @@ The creation of a BDC requires some steps to prepare the Samba server before
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>domain SID</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>secrets.tdb</primary></indexterm>
|
||||
<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm>
|
||||
To retrieve the domain SID from the PDC or an existing BDC and store it in the
|
||||
<filename>secrets.tdb</filename>, execute:
|
||||
</para>
|
||||
@ -471,6 +574,9 @@ The creation of a BDC requires some steps to prepare the Samba server before
|
||||
</listitem>
|
||||
|
||||
<listitem><para>
|
||||
<indexterm><primary>secrets.tdb</primary></indexterm>
|
||||
<indexterm><primary>smbpasswd</primary></indexterm>
|
||||
<indexterm><primary>LDAP administration password</primary></indexterm>
|
||||
Specification of the <smbconfoption name="ldap admin dn"/> is obligatory.
|
||||
This also requires the LDAP administration password to be set in the <filename>secrets.tdb</filename>
|
||||
using the <command>smbpasswd -w <replaceable>mysecret</replaceable></command>.
|
||||
@ -483,7 +589,10 @@ The creation of a BDC requires some steps to prepare the Samba server before
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>user database</primary></indexterm>
|
||||
<indexterm><primary>synchronized</primary></indexterm>
|
||||
<indexterm><primary>NIS</primary></indexterm>
|
||||
The UNIX user database has to be synchronized from the PDC to the
|
||||
BDC. This means that both the <filename>/etc/passwd</filename> and
|
||||
<filename>/etc/group</filename> have to be replicated from the PDC
|
||||
@ -497,6 +606,14 @@ The creation of a BDC requires some steps to prepare the Samba server before
|
||||
</listitem>
|
||||
|
||||
<listitem><para>
|
||||
<indexterm><primary>password database</primary></indexterm>
|
||||
<indexterm><primary>replicated</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>smbpasswd</primary></indexterm>
|
||||
<indexterm><primary>rsync</primary></indexterm>
|
||||
<indexterm><primary>ssh</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
The Samba password database must be replicated from the PDC to the BDC.
|
||||
Although it is possible to synchronize the <filename>smbpasswd</filename>
|
||||
file with <command>rsync</command> and <command>ssh</command>, this method
|
||||
@ -505,6 +622,12 @@ The creation of a BDC requires some steps to prepare the Samba server before
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<indexterm><primary>netlogon share</primary></indexterm>
|
||||
<indexterm><primary>replicate</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>cron</primary></indexterm>
|
||||
<indexterm><primary>rsync</primary></indexterm>
|
||||
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 <command>cron</command> job
|
||||
@ -534,23 +657,35 @@ as shown in <link linkend="minim-bdc">Minimal Setup for Being a BDC</link>.
|
||||
</example>
|
||||
|
||||
<para>
|
||||
This configuration causes the BDC to register only the name MIDEARTH<#1c> with the
|
||||
WINS server. This is not a problem, as the name MIDEARTH<#1c> is a NetBIOS group name
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>NetBIOS</primary></indexterm>
|
||||
<indexterm><primary>group</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
This configuration causes the BDC to register only the name MIDEARTH<#1C> with the
|
||||
WINS server. This is not a problem, as the name MIDEARTH<#1C> is a NetBIOS group name
|
||||
that is meant to be registered by more than one machine. The parameter
|
||||
<smbconfoption name="domain master">no</smbconfoption>
|
||||
forces the BDC not to register MIDEARTH<#1b>, which is a unique NetBIOS name that
|
||||
forces the BDC not to register MIDEARTH<#1B>, which is a unique NetBIOS name that
|
||||
is reserved for the PDC.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>idmap backend</primary></indexterm>
|
||||
<indexterm><primary>winbindd</primary></indexterm>
|
||||
<indexterm><primary>redirect</primary></indexterm>
|
||||
<indexterm><primary>winbindd</primary></indexterm>
|
||||
<indexterm><primary>LDAP database</primary></indexterm>
|
||||
<indexterm><primary>UID</primary></indexterm>
|
||||
<indexterm><primary>GID</primary></indexterm>
|
||||
The <parameter>idmap backend</parameter> will redirect the <command>winbindd</command> utility to
|
||||
use the LDAP database to resolve all UIDs and GIDs for UNIX accounts.
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
<indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm>
|
||||
<indexterm><primary>ID mapping</primary></indexterm>
|
||||
<indexterm><primary>domain member server</primary></indexterm>
|
||||
<indexterm><primary>idmap backend</primary></indexterm>
|
||||
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
|
||||
@ -560,6 +695,9 @@ regarding its behavior.
|
||||
</para></note>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>winbindd</primary></indexterm>
|
||||
<indexterm><primary>domain member servers</primary></indexterm>
|
||||
The use of the <smbconfoption name="idmap backend">ldap:ldap://master.quenya.org</smbconfoption>
|
||||
option on a BDC only makes sense where ldapsam is used on a PDC. The purpose of 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
|
||||
@ -574,6 +712,7 @@ member servers.
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>domain control</primary></indexterm>
|
||||
As domain control 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 <ulink url="http://samba.org">site</ulink>.
|
||||
@ -584,6 +723,9 @@ from the Samba Web <ulink url="http://samba.org">site</ulink>.
|
||||
|
||||
<para>
|
||||
<indexterm><primary>Machine Trust Accounts</primary></indexterm>
|
||||
<indexterm><primary>passdb</primary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
<indexterm><primary>Local Machine Trust Account</primary></indexterm>
|
||||
This problem will occur when the passdb (SAM) files are copied from a central
|
||||
server but the local BDC is acting as a PDC. This results in the application of
|
||||
Local Machine Trust Account password updates to the local SAM. Such updates
|
||||
@ -606,10 +748,14 @@ a slave LDAP server for each BDC and a master LDAP server for the PDC.
|
||||
|
||||
<para>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
No. The native NT4 SAM replication protocols have not yet been fully implemented.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>PDC</primary></indexterm>
|
||||
<indexterm><primary>logon requests</primary></indexterm>
|
||||
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
|
||||
@ -623,12 +769,17 @@ the PDC is down.
|
||||
|
||||
<para>
|
||||
<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
|
||||
<indexterm><primary>smbpasswd</primary></indexterm>
|
||||
<indexterm><primary>SAM</primary></indexterm>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>plaintext password</primary></indexterm>
|
||||
<indexterm><primary>ssh</primary></indexterm>
|
||||
<indexterm><primary>rsync</primary></indexterm>
|
||||
As the smbpasswd file contains plaintext 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.
|
||||
@ -637,6 +788,8 @@ the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>machine trust accounts</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
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
|
||||
<emphasis>not</emphasis> recommended. Try using LDAP instead.
|
||||
@ -648,6 +801,8 @@ accounts will go out of sync, resulting in a broken domain. This method is
|
||||
<title>Can I Do This All with LDAP?</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>pdb_ldap</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
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
|
||||
|
||||
@ -243,55 +243,171 @@ Information Databases</link>.
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Comparison of Single Sign-on and Domain Security</title>
|
||||
<title>Single Sign-On and Domain Security</title>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>single sign-on</primary><see>SSO</see></indexterm>
|
||||
<indexterm><primary>SSO</primary></indexterm>
|
||||
<indexterm><primary>active directory</primary></indexterm>
|
||||
<indexterm><primary>authentication</primary></indexterm>
|
||||
<indexterm><primary>validation</primary></indexterm>
|
||||
<indexterm><primary>password uniqueness</primary></indexterm>
|
||||
<indexterm><primary>password history</primary></indexterm>
|
||||
When network administrators are asked to describe the benefits of Windows NT4 and active directory networking
|
||||
the most often mentioned feature is that of SSO. Many companies have implemented SSO solutions. The mode of
|
||||
implementation of a single sign-on solution is an important factor in the practice of networking in general,
|
||||
and is critical in respect of Windows networking. Where a company may have a wide variety of information
|
||||
systems, each of which require some form of user authentication and validation it is not uncommon that users
|
||||
may need to remember more than a dozen login IDs and passwords. The problem will be compounded when the
|
||||
password for each system must be changed at regular intervals, and particularly so where password uniqueness
|
||||
and history limits are applied.
|
||||
the most often mentioned feature is that of single sign-on (SSO). Many companies have implemented SSO
|
||||
solutions. The mode of implementation of a single sign-on solution is an important factor in the practice of
|
||||
networking in general, and is critical in respect of Windows networking. A company may have a wide variety of
|
||||
information systems, each of which requires a form of user authentication and validation, thus it is not
|
||||
uncommon that users may need to remember more than ten login IDs and passwords. This problem is compounded
|
||||
when the password for each system must be changed at regular intervals, and particularly so where password
|
||||
uniqueness and history limits are applied.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is a wide perception that SSO is the answer to the problem of users having to deal with too many
|
||||
information system access credentials. Many elaborate schemes have been devised to make it possible to deliver
|
||||
a user-friendly SSO solution. The trouble is that if this implementation is not done correctly, the site may
|
||||
end up paying dearly by way of complexity and management overheads. Simply put, many SSO solutions are an
|
||||
administrative nightmare.
|
||||
<indexterm><primary>management overheads</primary></indexterm>
|
||||
There is a broadly held perception that SSO is the answer to the problem of users having to deal with too many
|
||||
information system access credentials (username/password pairs). Many elaborate schemes have been devised to
|
||||
make it possible to deliver a user-friendly SSO solution. The trouble is that if this implementation is not
|
||||
done correctly, the site may end up paying dearly by way of complexity and management overheads. Simply put,
|
||||
many SSO solutions are an administrative nightmare.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
SSO implementations may involve centralization of all user account information in one repository. Depending on
|
||||
environmental complexity and the age of the systems over which a SSO solution is implemented, it may not be
|
||||
possible to change the solution architecture so as to accomodate a new identity management and user
|
||||
authentication system. Many SSO solutions involving legacy systems consist of a new super-structure that
|
||||
handles authentication on behalf of the user. The software that gets layered over the old system may simply
|
||||
implement a proxy authentication system. This means that the addition of SSO increases over-all information
|
||||
systems complexity. Ideally, the implementation of SSO should reduce complexity and reduce administative
|
||||
overheads.
|
||||
<indexterm><primary>identity management</primary></indexterm>
|
||||
<indexterm><primary>authentication system</primary></indexterm>
|
||||
<indexterm><primary>SSO</primary></indexterm>
|
||||
SSO implementations utilize centralization of all user account information. Depending on environmental
|
||||
complexity and the age of the systems over which a SSO solution is implemented, it may not be possible to
|
||||
change the solution architecture so as to accomodate a new identity management and user authentication system.
|
||||
Many SSO solutions involving legacy systems consist of a new super-structure that handles authentication on
|
||||
behalf of the user. The software that gets layered over the old system may simply implement a proxy
|
||||
authentication system. This means that the addition of SSO increases over-all information systems complexity.
|
||||
Ideally, the implementation of SSO should reduce complexity and reduce administative overheads.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
JJJ More Info HERE!
|
||||
<indexterm><primary>centralized identity management</primary></indexterm>
|
||||
<indexterm><primary>identity management</primary><secondary>centralized</secondary></indexterm>
|
||||
<indexterm><primary>centralized</primary><secondary>authentication</secondary></indexterm>
|
||||
<indexterm><primary>legacy systems</primary></indexterm>
|
||||
<indexterm><primary>access control</primary></indexterm>
|
||||
The initial goal of many network administrators is often to create and use a centralized identity management
|
||||
system. It is often assumed that such a centralized system will use a single authentication infrastructure
|
||||
that can be used by all information systems. The Microsoft Windows NT4 security domain architecture and the
|
||||
Micrsoft active directory service are often put forward as the ideal foundation for such a system. It is
|
||||
conceptually simple to install an external authentication agent on each of the disparate infromation systems
|
||||
that can then use the Microsoft (NT4 domain or ads service) for user authentication and access control. The
|
||||
wonderful dream of a single centralized authentication service is commonly broken when realities are realized.
|
||||
The problem with legacy systems is often the inability to externalize the authentication and access control
|
||||
system it uses because its implementation will be excessively invasive from a re-engineering perspective, or
|
||||
because application software has built-in dependencies on particular elements of the way user authentication
|
||||
and access control were designed and built.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Briefly describe: 1. New auth system that uses external auth.
|
||||
2. SSO system that stores info about all IT systems, and provides front-end
|
||||
app. that hides the IT systems beneath a veneer of its own.
|
||||
3. Meta-directories and distribution if ID info.
|
||||
4. The significance of Samba in the context of SSO
|
||||
5. Implications of domain security
|
||||
a) with NT4 domain
|
||||
b) with ADS
|
||||
<indexterm><primary>meta-directory</primary></indexterm>
|
||||
<indexterm><primary>credentials</primary></indexterm>
|
||||
<indexterm><primary>disparate information systems</primary></indexterm>
|
||||
<indexterm><primary>management procedures</primary></indexterm>
|
||||
<indexterm><primary>work-flow protocol</primary></indexterm>
|
||||
<indexterm><primary>rights</primary></indexterm>
|
||||
<indexterm><primary>privileges</primary></indexterm>
|
||||
<indexterm><primary>provisioned</primary></indexterm>
|
||||
Over the past decade an industry has been developed around the various methods that have been built to get
|
||||
around the key limitations of legacy information technology systems. One approach that is often used involves
|
||||
the use of a meta-directory. The meta-directory stores user credentials for all disparate information systems
|
||||
in the format that is particular to each system. An elaborate set of management procedures is coupled with a
|
||||
rigidly enforced work-flow protocol for managing user rights and privileges within the maze of systems that
|
||||
are provisioned by the new infrastructure makes possible user access to all systems using a single set of user
|
||||
credentials.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Other considerations: Should this stuff go elsewhere? Should it be dropped? Should this chapter be revamped?
|
||||
<indexterm><primary>Organization for the Advancement of Structured Information Standards</primary><see>OASIS</see></indexterm>
|
||||
<indexterm><primary>Security Assertion Markup Language</primary><see>SAML</see></indexterm>
|
||||
<indexterm><primary>Federated Identity Management</primary><see>FIM</see></indexterm>
|
||||
<indexterm><primary>secure access</primary></indexterm>
|
||||
The Organization for the Advancement of Structured Information Standards (OASIS) has developed the Security
|
||||
Assertion Markup Language (SAML), a structured method for communication of authentication information. The
|
||||
over-all umbrella name for the technologies and methods that deploy SAML is called Federated Identity
|
||||
Management (FIM). FIM depends on each system in the complex maze of disparate information systems to
|
||||
authenticate their respective users and vouch for secure access to the services each provides.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>Simple Object Access Protocol</primary><see>SOAP</see></indexterm>
|
||||
<indexterm><primary>federated organizations</primary></indexterm>
|
||||
<indexterm><primary>Liberty Alliance</primary></indexterm>
|
||||
<indexterm><primary>federated-identity</primary></indexterm>
|
||||
<indexterm><primary></primary></indexterm>
|
||||
<indexterm><primary></primary></indexterm>
|
||||
SAML documents can be wrapped in a Simple Object Access Protocol (SOAP) message for the computer-to-computer
|
||||
communications needed for Web services. Or they may be passed between Web servers of federated organizations
|
||||
that share live services. The Liberty Alliance, an industry group formed to promote federated-identity
|
||||
standards, has adopted SAML 1.1 as part of its application framework. Microsoft and IBM have proposed an
|
||||
alternative specification called WS-Security. Some believe that the competing technologies and methods may
|
||||
converge when the SAML 2.0 standard is introduced. A few Web access-management products support SAML today,
|
||||
but implemention of the technology mostly requires customization to integrate applications and develop user
|
||||
interfaces. In a nust-shell, that is why FIM is a big and growing industry.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>interoperability</primary></indexterm>
|
||||
<indexterm><primary>ADS</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
<indexterm><primary>GSSAPI</primary></indexterm>
|
||||
<indexterm><primary>general security service application programming interface</primary><see>GSSAPI</see></indexterm>
|
||||
Ignoring the bigger picture, which is beyond the scope of this book, the migration of all user and group
|
||||
management to a centralized system is a step in the right direction. It is essential for interoperability
|
||||
reasons to locate the identity management system data in a directory such as Microsoft Active Directory
|
||||
Service (ADS), or any proprietary or open source system that provides a standard protocol for information
|
||||
access (such as LDAP) and that can be coupled with a flexible array of authentication mechanisms (such as
|
||||
kerberos) that use the protocols that are defined by the various general security service application
|
||||
programming interface (GSSAPI) services.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>OpenLDAP</primary></indexterm>
|
||||
<indexterm><primary>ADS</primary></indexterm>
|
||||
<indexterm><primary>authentication agents</primary></indexterm>
|
||||
A growing number of companies provide authentication agents for disparate legacy platforms to permit the use
|
||||
of LDAP systems. Thus the use of OpenLDAP, the dominant open source software implementation of the light
|
||||
weight directory access protocol standard. This fact, means that by providing support in Samba for the use of
|
||||
LDAP and Microsoft ADS make Samba a highly scalable and forward reaching organizational networking technology.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>ADS</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
<indexterm><primary>authentication architecture</primary></indexterm>
|
||||
<indexterm><primary>ntlm_auth</primary></indexterm>
|
||||
<indexterm><primary>SQUID</primary></indexterm>
|
||||
<indexterm><primary>FIM</primary></indexterm>
|
||||
Microsoft ADS provides purely proprietary services that, with limitation, can be extended to provide a
|
||||
centralized authentication infrastructure. Samba plus LDAP provides a similar opportunity for extension of a
|
||||
centralized authentication architecture, but it is the fact that the Samba Team are pro-active in introducing
|
||||
the extension of authentication services, using LDAP or otherwise, to applications such as SQUID (the open
|
||||
source proxy server) through tools such as the <command>ntlm_auth</command> utility, that does much to create
|
||||
sustainable choice and competition in the FIM market place.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
<indexterm><primary>OpenLDAP</primary></indexterm>
|
||||
<indexterm><primary>identity information</primary></indexterm>
|
||||
Primary domain control, if it is to be scalable to meet the needs of large sites, must therefore be capable of
|
||||
using LDAP. The rapid adoption of OpenLDAP, and Samba configurations that use it, is ample proof that the era
|
||||
of the directoy has started. Samba-3 does not demand the use of LDAP, but the demand for a mechanism by which
|
||||
user and group identity information can be distributed makes it an an unavoidable option.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>BDC</primary></indexterm>
|
||||
<indexterm><primary>LDAP</primary></indexterm>
|
||||
<indexterm><primary>e-Directory</primary></indexterm>
|
||||
At this time, the use of Samba based BDCs, necessitates the use of LDAP. The most commonly used LDAP
|
||||
implementation used by Samba sites is OpenLDAP. It is possible to use any standards compliant LDAP server.
|
||||
Those known to work includes those manufactured by: IBM, CA, Novell (e-Directory), and others.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
Reference in New Issue
Block a user