SAMBA Configuration

... to share or no to share.

© 2010, 2011 Dennis Leeuw dleeuw at made-it dot com
With a big THANKS to Eric Toirkens for his help with the Windows section.
License: GPLv2 or later


    1. CIFS is a fileserver
    2. NetBIOS, SMB or CIFS
    3. Pre-SAMBA settings
      1. DNS
      2. Kerberos
      3. SELinux
    4. SAMBA smb.conf
      1. Testing

CIFS is a fileserver

SAMBA in this setup will not act as a logon server. The configuration described in this section will setup SAMBA as a CIFS server, and only that. It is assumed that users and clients logon against Kerberos and LDAP as described in previous documents.

After users have received their Kerberos ticket, they can start using the SAMBA services. Meaning that SAMBA has to honour connections with a valid ticket. And deny all other access.


To configure SAMBA you need a bit of knowledge about Microsoft Networking. Pre-Windows 2000 systems used NetBIOS over TCP/IP to provide you with SMB (Service Message Block) connections. Windows 2000 and later systems are equiped with SMB over TCP/IP. As Microsoft states in their Direct hosting of SMB over TCP/IP document this has a couple of advantages:

With NetBIOS over TCP/IP or NBT for short the following ports are used:
NetBIOS name UDP 137
NetBIOS name TCP 137
NetBIOS datagram UDP 138
NetBIOS session TCP 139

Within SAMBAs smb.conf this can be controlled by:

disable netbios = no
smb ports = 139

NetBIOS on you LAN can be an annoiance due to the amount of broadcasts that it sents. However NetBIOS over the Internet is an enormous security risk. The NetBIOS protocol gives people the ability to obtain all kind of information from your systems like: your domain, workgroup and system names, as well as account information. To prevent this from happening make sure that on your border gateways you filter out all in- and outgoing traffic for ports 137, 138 and 139.

SMB of TCP/IP or CIFS (Common Internet File System) uses:

Within SAMBAs smb.conf this can be controlled by:

disable netbios = yes
smb ports = 445

If you want to support both use:

disable netbios = no
smb ports = 139 445

The big question now is: How does a Microsoft Client handle all this? Windows 2000 and later systems setup two connections simultaniously to a server one on port 445 and one on port 139. If it gets a response from port 445 it will reset (RST) the port 139 connection. If it only gets a response from port 139, that one is used. If you disable NBT on your client only port 445 is being tried.

Pre-Windows 2000 clients only use port 139.

So if you do not have systems that pre-date Windows 2000 on your network I would suggest to go with SMB over TCP/IP option in your smb.conf.

For those that realy want to get into the details of NetBIOS, SMB and CIFS I suggest reading: Implementing CIFS

Pre-SAMBA settings


Add to DNS:

_ldap._tcp.dc._msdcs.EXAMPLE.COM	SRV 0 0 389
This entry is need when we direct SAMBA to act as a ADS member server. It is used to locate the PDC (LDAP server).

Also add a DNS entry for your samba server. We are assuming:

fs01		CNAME	larix
larix		A


Configure your host to use your LDAP and Kerberos server (on Red Hat based systems run authconfig-tui).

Create the krb5.keytab file.


I have sometimes been struggeling for too long to just figure out I was bitten by SELinux. To prevent that happening make sure that SELinux is set to permissive on your SAMBA server:

setenforce 0
If you later on get messages from smbclient telling you NT_STATUS_BAD_NETWORK_NAME it might be SELinux that is not set to permissive. You have been warned.

SAMBA smb.conf

Install SAMBA and make sure that you also install the client packages and winbind.

Create an smb.conf like this:

   # Naming settings #
   workgroup = EXAMPLE.COM
   server string = SMB server
   netbios name = FS01
   os level = 44

   # Networking #
   interfaces = eth0
   bind interfaces only = yes
   name resolve order = host
   disable netbios = yes
   smb ports = 445
   domain logons = Yes
   preferred master = Yes
   domain master = Yes

   # Kerberos Settings #
   security = ADS
   realm = EXAMPLE.COM

   # Security Settings #
   encrypt passwords = yes
   dont descend = /proc,/dev,/etc,/lib,/lost+found,/initrd

   # Logging #
   log level = 3 auth:10
   log file = /var/log/samba/%m.log
   max log size = 10000
   syslog = 0

   comment = Home Directories
   browseable = no
   writeable = yes
   force create mode = 0660
   force directory mode = 0770

Create a machine trust for our CIFS server. Run on kerberos host:

addprinc cifs/

Add the password that you added for the cifs/ to the secrets.tdb file (this is the machine trust account password):

net changesecretpw -f
If you later on get an error message like:
ads_secrets_verify_ticket: failed to fetch machine password
In your machine log file, it means that the passwords in Kerberos and in the secrets.tdb file are out of sync. Also note that the password is stored in plain text in the secrets.tdb file, so make sure this file is very secure (chmod 600).

Create the home directory for our user:

mkdir /home/testuser
chown testuser:Domain\ Users /home/testuser/

Test the configuration parameters in the smb.conf file:

and start the samba services. Note that on Red Hat machines nmbd is automatically started. So if you do not want nmbd (which I said we wouldn't) comment the corresponding lines in /etc/init.d/smb out.
service smb start
service winbind start


Check network connectivity:

net lookup ldap
This should return the IP address of the LDAP server and its port number.

Check domain SIDs. SAMBA should have created it's own machine domain SID and should have read the domain SID from LDAP:

net lookup name EXAMPLE.COM
net lookup name LARIX
This should return the SIDs

Check to see if the user SIDs are there and correct:

net usersidlist
This should return testuser and nobody.

If all the above is fine, we should be able to connect to our file server with kerberos:

kinit testuser
smbclient -L -N
This is an anonymous logon check. Just to see if we can list the shares available on the server.

List the services available on our server as user testuser using our kerberos ticket:

smbclient -U testuser -L -k

Connect to a share using our kerberos ticket:

smbclient -U testuser // -k
With ls you should be able to view the contents of the share. With put you can transfer a file from your local system to the remote. Samba acts as an FTP server, so if you are familair with FTP, do as you like to test the share. ? will give you an over view of the available commands. Quit closes the connection.