Wednesday, 29 November 2017

Samba Server Security Modes Red Hat Enterprise Linux 7

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