SAMBA SECURITY MODES
There
are only two types of security modes for Samba, share-level and user-level,
which are collectively known as security
levels. Share-level security is deprecated and has been removed from
Samba. Configurations containing this mode need to be migrated to use
user-level security. User-level security can be implemented in one of three
different ways. The different ways of implementing a security level are called security modes.
USER-LEVEL SECURITY
User-level
security is the default and recommended setting for Samba. Even if the security = user directive is not
listed in the /etc/samba/smb.conf file, it is used by Samba. If the
server accepts the client's user name
and password, the client can then mount multiple shares without specifying a password
for each instance. Samba can also accept session-based user name and password
requests. The client maintains multiple authentication contexts by using a
unique UID for each logon. In the /etc/samba/smb.conf file, the security = user directive that
sets user-level security is:
[GLOBAL]
...
security = user
...
SAMBA GUEST SHARES
As
mentioned above, share-level security mode is deprecated. To configure a Samba guest
share without using the security =
share parameter, follow the procedure below:
CONFIGURING SAMBA GUEST SHARES
1. Create a username map file, in this example /etc/samba/smbusers,
and add the following line to it:
nobody = guest
2. Add the following directives to the main section in the /etc/samba/smb.conf
file. Also, do not use the valid
users directive:
[GLOBAL]
…
security = user
map to guest = Bad User
username map = /etc/samba/smbusers
...
The username map directive provides a
path to the username map file specified in the
previous step.
3. Add the following directive to the share section in the /ect/samba/smb.conf
file. Do not use the valid
users directive.
[SHARE]
...
guest ok = yes
...
The following sections
describe other implementations of user-level security.
DOMAIN SECURITY MODE (USER-LEVEL SECURITY)
In
domain security mode, the Samba server has a machine account (domain security
trust account) and causes all authentication requests to be passed through to
the domain controllers. The Samba server is made into a domain member server by
using the following directives in the /etc/samba/smb.conf
file:
[GLOBAL]
...
security = domain
workgroup = MARKETING
...
ACTIVE DIRECTORY SECURITY MODE (USER-LEVEL SECURITY)
If you
have an Active Directory environment, it is possible to join the domain as a
native Active Directory member. Even if a security policy restricts the use of
NT-compatible authentication protocols, the Samba server can join an ADS using
Kerberos. Samba in Active Directory member mode can accept Kerberos tickets.
In the /etc/samba/smb.conf
file, the following directives make Samba an Active Directory member
server:
[GLOBAL]
...
security = ADS
realm = ABC.COM
password server = kerberos.abc.com
...
SHARE-LEVEL SECURITY
With
share-level security, the server accepts only a password without an explicit
user name from the client. The server expects a password for each share,
independent of the user name. There have been recent reports that Microsoft
Windows clients have compatibility issues with share-level security servers.
This mode is deprecated and has been removed from Samba. Configurations
containing security = share should
be updated to use user-level security.
SAMBA NETWORK BROWSING
Network browsing enables Windows and
Samba servers to appear in the Windows Network Neighborhood. Inside the Network
Neighborhood, icons are represented as servers and if opened, the server's
shares and printers that are available are displayed.
Network browsing
capabilities require NetBIOS over TCP/IP. NetBIOS-based
networking uses broadcast (UDP) messaging to accomplish browse list
management. Without NetBIOS and WINS as the primary method for TCP/IP
host name resolution, other methods such as static files ( /etc/hosts)
or DNS, must be used. A domain master browser collates the browse lists
from local master browsers on all subnets so that
browsing can occur
between workgroups and subnets. Also, the domain master browser should preferably
be the local master browser for its own subnet.
DOMAIN BROWSING
By
default, a Windows server PDC for a domain is also the domain master browser
for that domain. A Samba server must not
be set up as a domain master server in this type of situation. For
subnets that do not include the Windows server PDC, a Samba server can be
implemented as a local master browser. Configuring the /etc/samba/smb.conf file
for a local master browser (or no browsing at all) in a domain controller
environment is the same as workgroup configuration.
WINS (Windows Internet Name Server)
Either
a Samba server or a Windows NT server can function as a WINS server. When a
WINS server is used with NetBIOS enabled, UDP unicasts can be routed which
allows name resolution across networks. Without a WINS server, the UDP
broadcast is limited to the local subnet and therefore cannot be routed to
other subnets, workgroups, or domains. If WINS replication is necessary, do not
use Samba as your primary WINS server, as Samba does not currently support WINS
replication. In a mixed NT/2000/2003/2008 server and Samba environment, it is
recommended that you use the Microsoft WINS capabilities. In a Samba-only
environment, it is recommended that you use only one Samba server for WINS.
The following is an
example of the /etc/samba/smb.conf file in which the Samba server is
serving as a WINS server:
EXAMPLE FOR CONFIGURATION OF WINS SERVER
[global]
wins support = yes
IMPORTANT NOTE
All
servers (including Samba) should connect to a WINS server to resolve NetBIOS names.
Without WINS, browsing only occurs on the local subnet. Furthermore, even if a domain-wide
list is somehow obtained, hosts cannot be resolved for the client without WINS.
No comments:
Post a Comment