From: Gerald Carter
When the IP address of the destination interface has been -determined a protocol called ARP/RARP isused to identify +determined a protocol called ARP/RARP is used to identify the MAC address of the target interface. ARP stands for Address Resolution Protocol, and is a broadcast oriented method that uses UDP (User Datagram Protocol) to send a request to all @@ -414,7 +414,7 @@ architecture of the MS Windows network. The term "workgroup" indicates that the primary nature of the network environment is that of a peer-to-peer design. In a WORKGROUP all machines are responsible for their own security, and generally such security is limited to use of -just a password (known as SHARE MORE security). In most situations +just a password (known as SHARE MODE security). In most situations with peer-to-peer networking the users who control their own machines will simply opt to have no security at all. It is possible to have USER MODE security in a WORKGROUP environment, thus requiring use @@ -444,8 +444,8 @@ NAME="AEN100" >
All MS Windows machines employ an in memory buffer in which is -stored the NetBIOS names and their IP addresses for all external -machines that that the local machine has communicated with over the +stored the NetBIOS names and IP addresses for all external +machines that that machine has communicated with over the past 10-15 minutes. It is more efficient to obtain an IP address for a machine from the local cache than it is to go through all the configured name resolution mechanisms.
If a machine whose name is in the local name cache has been shut down before the name had been expired and flushed from the cache, then an attempt to exchange a message with that machine will be subject -to time-out delays. ie: It's name is in the cache, so a name resolution +to time-out delays. i.e.: Its name is in the cache, so a name resolution lookup will succeed, but the machine can not respond. This can be frustrating for users - but it is a characteristic of the protocol.As stated above, MS Windows machines register their NetBIOS names -(ie: the machine name for each service type in operation) on start +(i.e.: the machine name for each service type in operation) on start up. Also, as stated above, the exact method by which this name registration takes place is determined by whether or not the MS Windows client/server has been given a WINS server address, whether or not LMHOSTS lookup @@ -685,7 +685,7 @@ Instead, the domain master browser serves the role of contacting each local master browser (found by asking WINS or from LMHOSTS) and exchanging browse list contents. This way every master browser will eventually obtain a complete list of all machines that are on the network. Every 11-15 minutes an election -is held to determine which machine will be the master browser. By nature of +is held to determine which machine will be the master browser. By the nature of the election criteria used, the machine with the highest uptime, or the most senior protocol version, or other criteria, will win the election as domain master browser.
MS Windows clients have a habit of dropping network mappings that have been idle for 10 minutes or longer. When the user attempts to -use the mapped drive connection that has been dropped the SMB protocol -has a mechanism by which the connection can be re-established using +use the mapped drive connection that has been dropped, the client +re-establishes the connection using a cached copy of the password.
When Microsoft changed the default password mode, they dropped support for @@ -959,7 +959,7 @@ NAME="AEN196" >
This mode of authentication demands that there be on the -Unix/Linux system both a Unix style account as well as and +Unix/Linux system both a Unix style account as well as an smbpasswd entry for the user. The Unix system account can be locked if required as only the encrypted password will be used for SMB client authentication.
workgroup = SAMBA -domain master = yes -domain logons = yes[global] + workgroup = SAMBA + domain master = yes + domain logons = yes + encrypt passwords = yes + security = user + ....
Several other things like a [homes] and a [netlogon] share also may be @@ -171,33 +175,93 @@ NAME="AEN28" >
The file private/MACHINE.SID identifies the domain. When a samba -server is first started, it is created on the fly and must never be -changed again. This file has to be the same on the PDC and the BDC, -so the MACHINE.SID has to be copied from the PDC to the BDC.
The file private/MACHINE.SID identifies the domain. When a samba + server is first started, it is created on the fly and must never be + changed again. This file has to be the same on the PDC and the BDC, + so the MACHINE.SID has to be copied from the PDC to the BDC. Note that in the + latest Samba 2.2.x releases, the machine SID (and therefore domain SID) is stored + in the private/secrets.tdb database. This file cannot just + be copied because Samba looks under the key SECRETS/SID/DOMAIN. + where DOMAIN is the machine's netbios name. Since this name has + to be unique for each SAMBA server, this lookup will fail.A new option has been added to the smbpasswd(8) + command to help ease this problem. When running smbpasswd -S as the root user, + the domain SID will be retrieved from a domain controller matching the value of the + workgroup parameter in smb.conf and stored as the + new Samba server's machine SID. See the smbpasswd(8) + man page for more details on this functionality. +
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 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. LDAP is also a + potential vehicle for sharing this information. +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.
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.
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. +workgroup = samba -domain master = no -domain logons = yes[global] + workgroup = SAMBA + domain master = yes + domain logons = yes + encrypt passwords = yes + security = user + ....
in the [global]-section of the smb.conf of the BDC. This makes the BDC @@ -222,21 +290,58 @@ CLASS="SECT2" >
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 +whenever changes to the SAM are made. Every user's password change +(including machine trust account password changes) 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.
rsync(1). rsync can use +ssh(1) as a transport. ssh itself +can be set up to accept only rsync transfer without requiring the user to +type a password. Refer to the man pages for these two tools for more details.Another solution with high potential is to use Samba's --with-ldapsam +for sharing and/or replicating the list of sambaAccount entries. +This can all be done over SSL to ensure security. See the Samba-LDAP-HOWTO +for more details.
O'Reilly Publishing is working on a guide to LDAP for System Administrators which has a planned release date of -early summer, 2002.Two additional Samba resources which may prove to be helpful are
IDEALX that are - geared to manage users and group in such a Samba-LDAP Domain Controller configuration. + geared to manage users and group in such a Samba-LDAP Domain Controller configuration. These scripts can + be found in the Samba 2.2.5 release in the examples/LDAP/smbldap-tools/ directory.
The first is that all lookups must be performed sequentially. Given that there are approximately two lookups per domain logon (one for a normal session connection such as when mapping a network drive or printer), this -is a performance bottleneck for lareg sites. What is needed is an indexed approach +is a performance bottleneck for large sites. What is needed is an indexed approach such as is used in databases.
As a result of these defeciencies, a more robust means of storing user attributes -used by smbd was developed. The API which defines access to user accounts +used by smbd was developed. The API which defines access to user accounts is commonly referred to as the samdb interface (previously this was called the passdb API, and is still so named in the CVS trees). In Samba 2.2.3, enabling support for a samdb backend (e.g. --with-ldapsam autoconf -option, smbd (and associated tools) will store and lookup user accounts in +option, smbd (and associated tools) will store and lookup user accounts in an LDAP directory. In reality, this is very easy to understand. If you are comfortable with using an smbpasswd file, simply replace "smbpasswd" with "LDAP directory" in all the documentation.
objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
+>objectclass ( 1.3.1.5.1.4.1.7165.2.2.3 NAME 'sambaAccount' SUP top AUXILARY
DESC 'Samba Account'
MUST ( uid $ rid )
MAY ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
@@ -261,7 +271,10 @@ CLASS="PROGRAMLISTING"
description $ userWorkstations $ primaryGroupID $ domain ))The samba.schema file has been formatted for OpenLDAP 2.0. The OID's are +>The samba.schema file has been formatted for OpenLDAP 2.0 & 2.1. The OID's are owned by the Samba Team and as such is legal to be openly published. If you translate the schema to be used with Netscape DS, please submit the modified schema file as a patch to jerry@samba.org
Since the original release, schema files for
IBM's SecureWay Server
Netscape Directory Server version 4.x and 5.x
have been submitted and included in the Samba source distribution. I cannot +personally comment on the integration of these commercial directory servers since +I have not had the oppotinuity to work with them.
Just as the smbpasswd file is mean to store information which supplements a user's /etc/passwd entry, so is the sambaAccount object -meant to supplement the UNIX user account information. A sambaAccount is a +meant to supplement the UNIX user account information. A sambaAccount is now an STRUCTURAL objectclass so it can be stored individually -in the directory. However, there are several fields (e.g. uid) which overlap -with the posixAccount objectclass outlined in RFC2307. This is by design.
AUXILARY objectclass so it can be stored alongside +a posixAccount or person objectclass in the directory. Note that there are +several fields (e.g. uid) which overlap with the posixAccount objectclass +outlined in RFC2307. This is by design. The move from a STRUCTURAL objectclass +to an AUXILIARY one was compliance with the LDAP data model which states that +an entry can contain only one STRUCTURAL objectclass per entry. This is now +enforced by the OpenLDAP 2.1 server.In order to store all user account information (UNIX and Samba) in the directory, it is necessary to use the sambaAccount and posixAccount objectclasses in -combination. However, smbd will still obtain the user's UNIX account +combination. However, smbd will still obtain the user's UNIX account information via the standard C library calls (e.g. getpwnam(), et. al.). This means that the Samba server must also have the LDAP NSS library installed and functioning correctly. This division of information makes it possible to @@ -297,7 +335,7 @@ CLASS="SECT1" >
Import existing user entries from an smbpasswd can be trivially done using +a Perl script named import_smbpasswd.pl included in the +examples/LDAP/ directory of the Samba source distribution. There are +two main requirements of this script:
All users to be imported to the directory must have a valid uid on the + local system. This can be a problem if using a machinej different from the Samba server + to import the file.
The local system must have a working installation of the Net::LDAP perl + module which can be obtained from with http://search.cpan.org/ + by searching for perl-ldap or directly from http://perl-ldap.sf.net/. +
Please refer to the documentation in the same directory as the script for more details.
jerry@samba.org. This documents was -last updated to reflect the Samba 2.2.3 release.