Samba on NonStop User Manual

4 Security Considerations
You should follow normal security best practices when configuring NS-Samba.
NS-Samba’s overall security infrastructure has less capability than the native NonStop server security
infrastructure. As examples:
Samba has a separate user/password management scheme.
Some configuration options, such as the SWAT demo mode, are not secure and should not
be used.
Samba has its own auditing and does not write events to syslog.
NS Samba should not be used to allow access to services on a production system without performing
detailed analysis of whether it is capable of being configured to support all of that production
system’s security policies.
User and password management:
NS Samba has its own, separate user/password management. To the degree possible, configure
NS Samba’s user and password management policies similarly to what you already have configured
for NonStop system users through Safeguard and other subsystems:
Set encrypt passwords = yes. Note that Samba encrypts passwords under multiple
algorithms for backward compatibility, and that some of the algorithms used have been
deprecated. There is no capability to disable use of the older algorithms.
Set null passwords = no.
Use tdbsam rather than smbpasswd so you can take advantage of additional user
management capabilities, and use pdbedit to set policy elements such as password expiration
and minimum length.
Eliminate, or at least minimize, use of the guest or public accounts, as they do not require
passwords.
Set map to guest = never to disallow connections to invalid users.
Do not use share-based authentication unless absolutely necessary. If you must use it, choose
a Samba client that sends session setup requests; otherwise, the user name is not available
to the host.
Encrypt user credentials in transit between the client and server. This is enabled by default.
If you should decide to uninstall NS-Samba and use the HP-provided script, note that any password
files are simply deleted with rm rf commands. They are not zeroized or otherwise wiped.
File permissions and access control:
Ensure that the permissions on NS-Samba files are appropriate. The permission bits for the
NS-Samba files shipped by HP are a good starting point, but consult with your system’s security
administrators to determine whether any of the settings should be modified for your environment.
If you must use secondary smb.conf files, make sure that they have the same rwx permission bit
settings as smb.conf.
NS-Samba log files are owned by super user. The default log security is drwxr-xr-x on the
directory containing the log files and -rw-r--r- on the individual log files, as is common for
other Samba implementations. You may wish to tighten their permissions.
Restrict file/share access to what is needed. Provide write access only where required.
Do not use force user, as it causes all file operations against a share to be performed by the
designated user regardless of which user actually was authenticated at connection or service access
time.
21