Difference between revisions of "Configure SMB"

From Organic Design wiki
({{legacy}})
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{legacy}}
 
{{procedure
 
{{procedure
 
|description = The most convenient way for a user to managing their online files is through the standard filing system interface in their local desktop environment, i.e. as a normal file share. Because it's available via the Internet, it needs to be a secure solution. We have two methods of setting up this kind of secure access to users files which are described in this procedure.
 
|description = The most convenient way for a user to managing their online files is through the standard filing system interface in their local desktop environment, i.e. as a normal file share. Because it's available via the Internet, it needs to be a secure solution. We have two methods of setting up this kind of secure access to users files which are described in this procedure.
Line 5: Line 6:
 
}}__NOTOC__
 
}}__NOTOC__
  
== Samba ==
 
 
Here's an example of our samba configuration format for the '''/etc/samba/smb.conf''' file:
 
Here's an example of our samba configuration format for the '''/etc/samba/smb.conf''' file:
{{code|<pre>
+
<source>
 
[global]
 
[global]
 
workgroup = Foo
 
workgroup = Foo
Line 21: Line 21:
 
browseable = yes
 
browseable = yes
 
writable = yes
 
writable = yes
 +
create mask = 0777
 +
directory mask = 0777
  
 
[staff]
 
[staff]
Line 26: Line 28:
 
comment = Our staff files
 
comment = Our staff files
 
valid users = henry alan tabatha
 
valid users = henry alan tabatha
 
+
</source>
</pre>}}
 
 
*'''password level = 3''' means account ''foo'', ''Foo'' and ''FOO'' are all equivalent user names
 
*'''password level = 3''' means account ''foo'', ''Foo'' and ''FOO'' are all equivalent user names
 
*'''log level = 4''' can be used to debug authentication and other problems, also directing at a single log file can help (instead of one per user)
 
*'''log level = 4''' can be used to debug authentication and other problems, also directing at a single log file can help (instead of one per user)
Line 33: Line 34:
 
*'''Note:''' whatever password backend is used, ''smbpasswd'' needs to be run for each user before they can begin accessing shares
 
*'''Note:''' whatever password backend is used, ''smbpasswd'' needs to be run for each user before they can begin accessing shares
  
=== Account synchronisation ===
+
== Account synchronisation ==
 
The main issue with the initial configuration of Samba on the LAN server concerns the users and groups. What is the origin of the user/group information? and how does samba synchronise to it or use it to authenticate? Since all our servers run a wiki we decided to make the wiki the source of the users, passwords and groups information. To do this we instruct the local wiki daemon to set the unix and samba passwords whenever one is changed in the wiki. All this requires is to install the [[Extension:EventPipe|EventPipe extension]] on the server's administration wiki and ensure that it has a [[wikid.pl|wiki daemon]] configured and running.
 
The main issue with the initial configuration of Samba on the LAN server concerns the users and groups. What is the origin of the user/group information? and how does samba synchronise to it or use it to authenticate? Since all our servers run a wiki we decided to make the wiki the source of the users, passwords and groups information. To do this we instruct the local wiki daemon to set the unix and samba passwords whenever one is changed in the wiki. All this requires is to install the [[Extension:EventPipe|EventPipe extension]] on the server's administration wiki and ensure that it has a [[wikid.pl|wiki daemon]] configured and running.
 
*Later we need to only synchronise accounts that are in a particular wiki group
 
*Later we need to only synchronise accounts that are in a particular wiki group
 
*Later we should also allow the shares to be created and configured through FS records
 
*Later we should also allow the shares to be created and configured through FS records
  
== Internet access using Samba over VPN ==
+
== Next steps ==
This is basically just a normal Samba installation which is included in the [[install a new server]] procedure, but Samba is not a very secure protocol, and so if used to share resources to Internet clients, it must be protected with a [[w:VPN|VPN]] and so is probably only the best solution for file sharing if your organisation is already using a VPN to connect remote users into your LAN.
+
*You may want to [[configure VPN]] remote access to the smb shares
 
 
Once a [[w:VPN|VPN]] has been set up with the [[install a new VPN]] procedure, all the workstations which are connected to the same VPN connection form part of a "virtual LAN" and they can all publish and use resources shared in that LAN such as shared directories, printers and services. They all show up in the normal "network places" or equivalent even though the hosts can be located in diverse locations around the internet, and all these connections are encrypted and secure.
 
*To ensure that Samba ports are only exposed to the private VPN side, set the ''interfaces'' directive in ''/etc/samba/smbd.conf'' to ''tun0''.
 
 
 
== Internet access using SFTP ==
 
The first method is [[w:SFTP|SFTP]] which uses existing [[w:SSH|SSH]] protocol to transfer files, and the workstations can map this connectivity in to the file system like a normal file share.
 
*Don't forget that additional users created with ''adduser''' also need to be added to ''AllowedUsers'' in ''/etc/ssh/sshd_config''
 
*We really need to [http://www.debian-administration.org/articles/590 upgrade to openssh-server 4.8] for the chroot-jail option
 
*[http://blogs.techrepublic.com.com/opensource/?cat=11 Another OpenSSH4.9 chroot example]
 
*[http://adamsworld.name/chrootjailv5.php Chroot jail with OpenSSH5.0+]
 
 
 
=== Setting up access for Ubuntu workstations ===
 
On Ubuntu, SFTP integration with the file system is a standard feature, simply go in to ''Places/Connect to server'', select ''SSH'', fill in the authentication details and the resource will be mounted as usual.
 
  
 
== See also ==
 
== See also ==

Latest revision as of 21:25, 3 June 2018

Legacy.svg Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.
Procedure.svg Configure SMB
Organic Design procedure

Here's an example of our samba configuration format for the /etc/samba/smb.conf file:

[global]
	workgroup = Foo
	server string = Foo server
	wins support = yes

	security = user
	encrypt passwords = yes
	password level = 3
	passdb backend = tdbsam

	invalid users = root daemon bin sys mail sshd bind www-data
	browseable = yes
	writable = yes
	create mask = 0777
	directory mask = 0777

[staff]
	path = /shared/staff
	comment = Our staff files
	valid users = henry alan tabatha
  • password level = 3 means account foo, Foo and FOO are all equivalent user names
  • log level = 4 can be used to debug authentication and other problems, also directing at a single log file can help (instead of one per user)
  • passdb backend = tdbsam means use the basic password backend instead of the older smbpasswd format or scalable ldapsam
  • Note: whatever password backend is used, smbpasswd needs to be run for each user before they can begin accessing shares

Account synchronisation

The main issue with the initial configuration of Samba on the LAN server concerns the users and groups. What is the origin of the user/group information? and how does samba synchronise to it or use it to authenticate? Since all our servers run a wiki we decided to make the wiki the source of the users, passwords and groups information. To do this we instruct the local wiki daemon to set the unix and samba passwords whenever one is changed in the wiki. All this requires is to install the EventPipe extension on the server's administration wiki and ensure that it has a wiki daemon configured and running.

  • Later we need to only synchronise accounts that are in a particular wiki group
  • Later we should also allow the shares to be created and configured through FS records

Next steps

See also