... 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
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:
| CIFS | TCP | 445 | |
| CIFS | UDP | 445 |
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
Add to DNS:
_ldap._tcp.dc._msdcs.EXAMPLE.COM SRV 0 0 389 ldap.example.com.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 192.168.1.55
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 0If 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.
Install SAMBA and make sure that you also install the client packages and winbind.
Create an smb.conf like this:
[global] #-----------------# # Naming settings # #-----------------# workgroup = EXAMPLE.COM server string = SMB server netbios name = FS01 os level = 44 #------------# # Networking # #------------# interfaces = 127.0.0.0/8 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 [homes] 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:
kadmin.local addprinc cifs/fs01.example.com
Add the password that you added for the cifs/fs01.example.com to the secrets.tdb file (this is the machine trust account password):
net changesecretpw -fIf you later on get an error message like:
ads_secrets_verify_ticket: failed to fetch machine passwordIn 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:
testparmand 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 ldapThis 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 LARIXThis should return the SIDs
Check to see if the user SIDs are there and correct:
net usersidlistThis 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 fs01.example.com -NThis 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 fs01.example.com -k
Connect to a share using our kerberos ticket:
smbclient -U testuser //fs01.example.com/testuser -kWith 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.