|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
NAME="GENERATOR" CONTENT="Modular DocBook HTML
Stylesheet Version 1.7">
Samba configuration is straightforward. All modifications to
Samba are done in the /etc/samba/smb.conf
configuration file. Although the default smb.conf file is well documented, it does not
address complex topics such as LDAP, Active Directory, and the
numerous domain controller implementations.
The following sections describe the different ways a Samba
server can be configured. Keep in mind your needs and the changes
required to the smb.conf file for a
successful configuration.
A stand-alone server can be a workgroup server or a member of a
workgroup environment. A stand-alone server is not a domain
controller and does not participate in a domain in any way. The
following examples include several anonymous share-level security
configurations and one user-level security configuration. For more
information on share-level and user-level security modes, refer to
Section 14.4 Samba
Security Modes.
The following smb.conf file shows a
sample configuration needed to implement anonymous read-only file
sharing. The security = share parameter
makes a share anonymous. Note, security levels for a single Samba
server cannot be mixed. The security
directive is a global Samba parameter located in the [global] configuration section of the smb.conf file.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Documentation Samba Server
path = /export
read only = Yes
guest only = Yes
|
The following smb.conf file shows a
sample configuration needed to implement anonymous read/write file
sharing. To enable anonymous read/write file sharing, set the
read only directive to no. The force user and
force group directives are also added to
enforce the ownership of any newly placed files specified in the
share.
 |
Note |
| |
Although having an anonymous read/write server is possible, it
is not recommended. Any files placed in the share space, regardless
of user, are assigned the user/group combination as specified by a
generic user (force user) and group
(force group) in the smb.conf file.
|
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Data
path = /export
force user = docsbot
force group = users
read only = No
guest ok = Yes
|
The following smb.conf file shows a
sample configuration needed to implement an anonymous print server.
Setting browseable to no as shown does not list the printer in Windows
Network Neighborhood. Although hidden from
browsing, configuring the printer explicitly is possible. By
connecting to DOCS_SRV using NetBIOS, the
client can have access to the printer if the client is also part of
the DOCS workgroup. It is also assumed
that the client has the correct local printer driver installed, as
the use client driver directive is set to
Yes. In this case, the Samba server has no
responsibility for sharing printer drivers to the client.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
printcap name = cups
disable spools= Yes
show add printer wizard = No
printing = cups
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
|
The following smb.conf file shows a
sample configuration needed to implement a secure read/write print
server. Setting the security directive to
user forces Samba to authenticate client
connections. Notice the [homes] share does
not have a force user or force group directive as the [public] share does. The [homes] share uses the authenticated user details
for any files created as opposed to the force
user and force group in [public].
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
printcap name = cups
disable spools = Yes
show add printer wizard = No
printing = cups
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = john, ed, @admins
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
|
A domain member, while similar to a stand-alone server, is
logged into a domain controller (either Windows or Samba) and is
subject to the domain's security rules. An example of a domain
member server would be a departmental server running Samba that has
a machine account on the Primary Domain Controller (PDC). All of
the department's clients still authenticate with the PDC, and
desktop profiles and all network policy files are included. The
difference is that the departmental server has the ability to
control printer and network shares.
The following smb.conf file shows a
sample configuration needed to implement an Active Directory domain
member server. In this example, Samba authenticates users for
services being run locally but is also a client of the Active
Directory. Ensure that your kerberos realm
parameter is shown in all caps (for example realm = EXAMPLE.COM). Since Windows 2000/2003
requires Kerberos for Active Directory authentication, the
realm directive is required. If Active
Directory and Kerberos are running on different servers, the
password server directive may be required
to help the distinction.
[global]
realm = EXAMPLE.COM
security = ADS
encrypt passwords = yes
# Optional. Use only if Samba cannot determine the Kerberos server automatically.
password server = kerberos.example.com
|
In order to join a member server to an Active Directory domain,
the following steps must be completed:
-
Configuration of the smb.conf file on
the member server
-
Configuration of Kerberos, including the /etc/krb5.conf file, on the member server
-
Creation of the machine account on the Active Directory domain
server
-
Association of the member server to the Active Directory
domain
To create the machine account and join the Windows 2000/2003
Active Directory, Kerberos must first be initialized for the member
server wishing to join the Active Directory domain. To create an
administrative Kerberos ticket, type the following command as root
on the member server:
The kinit command is a Kerberos
initialization script that references the Active Directory
administrator account and Kerberos realm. Since Active Directory
requires Kerberos tickets, kinit obtains
and caches a Kerberos ticket-granting ticket for client/server
authentication. For more information on Kerberos, the /etc/krb5.conf file, and the kinit command, refer to Chapter 19 Kerberos.
To join an Active Directory server (windows1.example.com), type
the following command as root on the member server:
root# net ads join -S windows1.example.com -U administrator%password
|
Since the machine windows1 was
automatically found in the corresponding Kerberos realm (the
kinit command succeeded), the net command connects to the Active Directory server
using its required administrator account and password. This creates
the appropriate machine account on the Active Directory and grants
permissions to the Samba domain member server to join the
domain.
|
Note |
| |
Since security = ads and not security = user is used, a local password backend
such as smbpasswd is not needed. Older
clients that do not support security = ads
are authenticated as if security = domain
had been set. This change does not affect functionality and allows
local users not previously in the domain.
|
The following smb.conf file shows a
sample configuration needed to implement a Windows NT4-based domain
member server. Becoming a member server of an NT4-based domain is
similar to connecting to an Active Directory. The main difference
is NT4-based domains do not use Kerberos in their authentication
method, making the smb.conf file simpler.
In this instance, the Samba member server serves as a pass through
to the NT4-based domain server.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = domain
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
|
Having Samba as a domain member server can be useful in many
situations. There are times where the Samba server can have other
uses besides file and printer sharing. It may be beneficial to make
Samba a domain member server in instances where Linux-only
applications are required for use in the domain environment.
Administrators appreciate keeping track of all machines in the
domain, even if not Windows-based. In the event the Windows-based
server hardware is deprecated, it is quite easy to modify the
smb.conf file to convert the server to a
Samba-based PDC. If Windows NT-based servers are upgraded to
Windows 2000/2003, the smb.conf file is
easily modifiable to incorporate the infrastructure change to
Active Directory if needed.
 |
Important |
| |
After configuring the smb.conf file,
join the domain before starting Samba by
typing the following command as root:
root# net rpc join -U administrator%password
|
|
Note that the -S option, which specifies
the domain server hostname, does not need to be stated in the
net rpc join command. Samba uses the
hostname specified by the workgroup
directive in the smb.conf file instead of
it being stated explicitly.
A domain controller in Windows NT is functionally similar to a
Network Information Service (NIS) server in a Linux environment.
Domain controllers and NIS servers both host user/group information
databases as well as related services. Domain controllers are
mainly used for security, including the authentication of users
accessing domain resources. The service that maintains the
user/group database integrity is called the Security Account Manager (SAM). The SAM database is
stored differently between Windows and Linux Samba-based systems,
therefore SAM replication cannot be achieved and platforms cannot
be mixed in a PDC/BDC environment.
In a Samba environment, there can be only one PDC and zero or
more BDCs.
|
Important |
| |
Samba cannot exist in a mixed Samba/Windows domain controller
environment (Samba cannot be a BDC of a Windows PDC or vice versa).
Alternatively, Samba PDCs and BDCs can
coexist.
|
The simplest and most common implementation of a Samba PDC uses
the tdbsam password database backend.
Planned to replace the aging smbpasswd
backend, tdbsam has numerous improvements
that are explained in more detail in Section 14.5 Samba Account
Information Databases. The passdb
backend directive controls which backend is to be used for the
PDC.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit
logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
writable = Yes
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon/scripts
admin users = ed, john, sam
guest ok = No
browseable = No
writable = No
# For profiles to work, create a user directory under the
# path shown. mkdir -p /var/lib/samba/profiles/john
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
browseable = No
guest ok = Yes
profile acls = Yes
# Other resource shares
...
...
|
|
Note |
| |
If you need more than one domain controller or have more than
250 users, do not use a tdbsam authentication backend. LDAP is recommended
in these cases.
|
The most powerful and versatile implementation of a Samba PDC is
its ability to have an LDAP password backend. LDAP is highly
scalable. LDAP database servers can be used for redundancy and
fail-over by replicating to a Samba BDC. Groups of LDAP PDCs and
BDCs with load balancing are ideal for an enterprise environment.
On the other hand, LDAP configurations are inherently complex to
setup and maintain. If SSL is to be incorporated with LDAP, the
complexity instantly multiplies. Even so, with careful and precise
planning, LDAP is an ideal solution for enterprise
environments.
Note the passdb backend directive as
well as specific LDAP suffix specifications. Although the Samba
configuration for LDAP is straightforward, the installation of
OpenLDAP is not trivial. LDAP should be installed and configured
before any Samba configuration. Also notice that Samba and LDAP do
not need to be on the same server to function. It is highly
recommended to separate the two in an enterprise environment.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
|
|
Note |
| |
Implementing LDAP in this smb.conf
file assumes that a working LDAP server has been successfully
installed on ldap.example.com.
|
A BDC is an integral part of any enterprise Samba/LDAP solution.
The smb.conf files between the PDC and BDC
are virtually identical except for the domain
master directive. Make sure the PDC has a value of Yes and the BDC has a value of No. If you have multiple BDCs for a PDC, the
os level directive is useful in setting
the BDC election priority. The higher the value, the higher the
server priority for connecting clients.
|
Note |
| |
A BDC can either use the LDAP database of the PDC or have its
own LDAP database. This example uses the LDAP database of the PDC
as seen in the passdb backend
directive.
|
[global] workgroup = DOCS
netbios name = DOCS_SRV2
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = No
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
|
Although it is possible for Samba to be a member of an Active
Directory, it is not possible for Samba to operate as an Active
Directory domain controller.
|
|
|
