# Samba Securing & SSO

## ct85711

I am trying to setup Samba so that it will be also secure.  The one problem I am having, is how to setup samba, to be like ssh in that you can authenticate using public/private key and/or a certificate instead of relying on a weak password.  I know the users that will be using is computer illiterate and prefer to make it as easy as possible for them to access/use the shares while maintaining security.  Do note, the end users are using Windows 10 machines not linux nor is any system connected to a domain, so no AD DC.  Most documentation I've been seeing, all want to point to working within a domain setup, not as a stand alone server.

From my research, it seems there is 2 possible routes, one is setting up kerberos service to authenticate against.  The other, is possibly is compiling samba with ssl and using SSLeay.  Most of that seems to be pretty outdated, and possibly not applicable.  If someone can direct me could direct me to some applicable references would be helpful.

```
ct85711@Oate ~ $ emerge -pv samba

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] net-fs/samba-4.11.4::gentoo  USE="acl client cups pam syslog system-mitkrb5 zeroconf -addc -addns -ads -ceph -cluster -debug (-dmapi) (-fam) -gpg -iprint -json -ldap -profiling-data -python -quota (-selinux) (-system-heimdal) -systemd -test -winbind" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python3_6 -python3_7" PYTHON_TARGETS="python3_6 python3_7" 0 KiB

```

----------

## seifn06

Hi ct85711, did you ever find a solution here? I'm working on a Samba file server for a very similar environment (8 x Win10 Pro desktops to access a shared drive on my Gentoo Samba file server) and would be interested in your findings if you are willing and able to share. Thank you!

----------

## ct85711

I ended up on giving up on this route, as it was going to cost more work/time than it was worth for my end.  From my findings, Samba as a whole has thought out how to encrypt the communication, but hasn't touched any authentication side since they implemented it.  As for my other findings, the ssl/SSLeay was just garbage.  A lot of it is that it was meant for a severely old version of samba that, when they did not think about encryption.  So that part, was more of to work around samba's lack of encrypting the communication and had nothing to do with authentication.

The only part I have found, is samba does allow authentication through a kerberos server (one part of the backbone to a AD setup).  Now the good part, is that kerberos does support SSO and is pretty secure.  The downsides, is that guides for setting up a kerberos server are generally only setting it up to connect to a domain controller, so you are going to have to scrounge around to piece together information to set it up as a stand alone.  The second part is, that to use kerberos authentication on Windows, you will need to install a kerberos client on each machine, so that it can communicate with the kerberos server and get it's authentication/authorization ticket (which is then used to authenticate who you are to the services like samba).

Depending on how far into setting up samba, you may have run into another issue with it and windows.  Simply said, the issue is being that Windows will not see the Samba server if you try browsing for it.  The cause for it, is that Windows 10 (1709 and later), was disabled and later completely ripped out all support for smb1.  The issue on this, is that smb 1.0 contains all of the parts to have Samba be visible to a Windows machine; and sadly the Samba devs has completely shoved their heads so far into the ground they don't want to even acknowledge this is an issue (it is a on going open bug that hasn't ever been addressed for about 2 years).  So in the end, samba does not support what windows is now using; WS-Discovery to identify services and machines.  Sadly it doesn't end here, linux as a whole as more of moved onto supporting and using Avahi/mdns which only has a laughable support in windows (it is said the MS is trying to add more support, but more like a 3rd party solution, in that it isn't integrated into anything.  The only good solution I have found, is that you need to download and install a small python program (wsdd).  All it is, is that it is a small ws-discovery deamon that sends out the WS-Discovery packet, saying that this machine is available (it can work right outside the box without any configuration).  Sadly, wsdd is not in the tree; so it is more of a thing that you get to download and install it yourself.  It does have a openrc/systemd files so you have have the service started when the machine starts.

Contains information about Windows and Samba: https://superuser.com/questions/1322497/did-windows-10-april-update-break-network-discovery-and-samba-support?rq=1

Link to the wsdd: https://github.com/christgau/wsdd

----------

## ct85711

Another option if you are not set on samba, may be to use NFS instead.  I sadly could not use it; as there is no NFS clients for windows Home (nor could I find any 3rd party solutions either).  Supposedly, there is a NFS client available on Windows 10 Pro (or higher) as an optional service/addon from MS that does integrate into the system.  This may do what you need, and be a lighter weight solution than the bloated samba service.  Sure, nfs doesn't share printers, but that part has never been needed in samba to begin with.  Cups has the option to share printers over the network by it's self (including to Windows machine with no additional configuration), that all samba was being, is being a un-needed middleman passing stuff through.

----------

## seifn06

Thank you for the info!

FWIW, I have net-fs/samba-4.11.6-r2 installed on a Gentoo machine running Gentoo Sources kernel 5.4.28. My Win10 pro machines are on version 1903 and while they cannot see my Samba server in the Windows Network Neighborhood (I don't have wsdd installed on the Gentoo machine), they are able to access Samba file shares over my local network. My understanding is that SMB is a protocol upon which the Samba software runs and SMBv1 is disabled by default in Win10 Pro due to a security vulnerability. I'm unsure which SMB protocol version (ex: 2 or 3) net-fs/samba-4.11.6-r2 runs, but it's working with my Win10 Pro desktop machines. 

I used the Gentoo Samba Guide to set up my Samba server as a very basic means to share a folder on my office network. I ignored all the cups and printer stuff. 

https://wiki.gentoo.org/wiki/Samba/Guide

I used the testparm to check my config file before running the service and the smbpasswd program to add users and passwords that I could use to log into Samba from my Win10 desktops. (I'm unsure how/where these passwords are stored, but they are not the same as the Linux usernames and passwords. And this is where I was interested in your security input!) 

```
# testparm

Load smb config files from /etc/samba/smb.conf

Loaded services file OK.

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# smbpasswd -a <username>
```

And now I have to enter a username and password when my Win10 desktop connects to the Samba server. 

I'm pasting my /etc/samba/smb.cnf file in case this helps you:

```
[global]

# Replace MYWORKGROUPNAME with your workgroup/domain

workgroup = MYWORKGROUPNAME

# Of course this has no REAL purpose other than letting

# everyone knows it's not Windows!

# %v prints the version of Samba we are using.

server string = Samba Server %v

# We are going to use cups, so we are going to put it in here ;-)

#printcap name = cups

#printing = cups

#load printers = yes

# We want a log file and we do not want it to get bigger than 50kb.

log file = /var/log/samba/log.%m

max log size = 500

# 4-9-2020: output more debug/verbose logging

log level = 3

# We are going to set some options for our interfaces...

# 4-9-2020: at advise of samba's testparm script, I'm disabling socket options since Linux OS does a lot of network optimizations?

#socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# This is a good idea, what we are doing is binding the

# samba server to our local network.

# For example, if eth0 is our local network device

interfaces = lo enp4s0

bind interfaces only = yes

# Now we are going to specify who we allow, we are afterall

# very security conscience, since this configuration does

# not use passwords!

hosts allow = 127.0.0.1 nnn.nnn.nnn.0/24

hosts deny = 0.0.0.0/0 nnn.nnn.nnn.1/24

# 4-9-2020: commented out the smb ports settings as it's not present in the current Gentoo Samba example.

#smb ports = 139

# Other options for this are USER, DOMAIN, ADS, and SERVER

# The default is user

# 4-9-2020: changed security = share to = user since share seems to be no longer valid.

#security = share

security = user

# No passwords, so we're going to use a guest account!

guest ok = yes

# 4-9-2020: commented out acl check permissions line after running testparm and seeing its use is deprecated.

#acl check permissions = No

# # Create a new share that can read from or written to anywhere.

# This is kind of like a temp public share; anyone can do what

# they want here:

[public]

comment = Public Files

browseable = yes

create mode = 0766

guest ok = yes

path = /home/samba/public
```

----------

## AJM

 *ct85711 wrote:*   

> Do note, the end users are using Windows 10 machines not linux nor is any system connected to a domain, so no AD DC.  Most documentation I've been seeing, all want to point to working within a domain setup, not as a stand alone server.

 

Out of interest, if you basically want SSO why not use SAMBA as a domain controller?  I confess I haven't yet used it in production but I have set it up fairly recently on a test server and it worked perfectly with Windows and Linux clients - it's also manageable with either the cli tools directly from Linux or the normal Windows AD management tools.

----------

## ct85711

With smb, Samba uses smb 1 for discovery, but smb 2+ for the actual file transfer, where smb 3.1 added in encryption and integrity checking. Windows 10, probably will probably try using smb 3.1 before dropping down to smb2.

seifn06:

A Domain Controller may be great for some purposes, but there is several areas it does not perform ideally and/or being a lot bigger tool than is necessary.  One of the biggest issues with maintaining a domain, is that the machines need to regularly communicate with the DC.  This isn't something to worry about for a machine that is always connected to the network/internet; but if the machine is only booted/connect to the network once every few months or more; you now need an admin to re-add the machine back into the domain every time.  Another big issue, is that MS removed the option for Home edition machines for joining a domain, there may be a work around but how that works is questionable.

In my case, having a domain controller in general adds in more complexity and overhead than is needed.  I am simply making some files accessible to 2-3 people on the network (where I am one of them, and will be the admin).  Everyone else will NOT access/user accounts to any other machines on the network, nor is printing/dns/ntp being shared to anyone on the network (2 of the key parts of a domain).  So in my use case, using a DC is just like the proverbial saying of using a sledge hammer to do a regular hammer's job.  Overall, using Samba in general is simply overkill for my purposes, but more of lack of options.  If anything, NFS would work great my for needs if I can find a client for windows.  The SSO part for me isn't a major requirement, but more of making it easier for people to connect to the server.  I can easily work around without the SSO easily enough, the biggest criteria is more of securing the service down.

 *Quote:*   

> Server role: ROLE_STANDALONE 

 

On a side note, Standalone role means samba is not running as a DC, but as a regular server (which is what I'm using it as right now).  When it is running as a DC, it adds in that all machines in the domain must be registered into the domain to use the provided services, along with dns/ntp services being necessary.

----------

## AJM

 *ct85711 wrote:*   

> On a side note, Standalone role means samba is not running as a DC, but as a regular server (which is what I'm using it as right now).  When it is running as a DC, it adds in that all machines in the domain must be registered into the domain to use the provided services, along with dns/ntp services being necessary.

 

PCs don't actually need to be domain members in order to access file shares on domain servers - you can just map a network drive in Windows Explorer (using a valid domain username and password to authenticate.)  This persists across reboots if you select that option when mapping the drive.

If you are only sharing with one or two users / PCs I agree that a full domain is probably overkill and standalone Samba is fine... my point was mostly that although it's true you need NTP etc for a domain controller, getting Samba to work as a DC is really very straightforward (I did it on Alpine but it'd be virtually identical on Gentoo.)  In fact, for someone already comfortable with Linux I'd say it's probably more straightforward than creating an AD DC on Windows Server!

----------

## ct85711

 *Quote:*   

> PCs don't actually need to be domain members in order to access file shares on domain servers - you can just map a network drive in Windows Explorer (using a valid domain username and password to authenticate.) 

 

Just mounting the share outside of the domain, is going around the main part I am concerned about, which is security.  By going around the domain, you are not letting the domain authenticate or authorize that you should have permissions to that share to begin with.  The main part of security, is controlling access to only allow authorized people.  Meaning if some unknown gets access to the network, they should never have access to anything.  My expected user's knowledge is low enough they have trouble with a password, so they are not a concern for security.

----------

## AJM

 *ct85711 wrote:*   

> Just mounting the share outside of the domain, is going around the main part I am concerned about, which is security.  By going around the domain, you are not letting the domain authenticate or authorize that you should have permissions to that share to begin with.  The main part of security, is controlling access to only allow authorized people.  Meaning if some unknown gets access to the network, they should never have access to anything.  My expected user's knowledge is low enough they have trouble with a password, so they are not a concern for security.

 

What I'm talking about isn't going round the domain at all - you still need domain credentials to connect to the mapped drive in the first place, you just don't need the PC itself to be a domain member... whether or not you save those credentials on the PCs for convenience or require the user to enter them after reboots is a matter of choice.

I have a few customers where they have a functioning AD domain with various file servers but the majority of the client PCs aren't domain members.  There's really no material difference in security at all, you still need a domain user account to access the file shares.

----------

## ct85711

Well, if anyone is interested; I did find an alternative that fulfills all of my requirements.  In short, it ended up being using sshfs.  While it does require the people to have an account on the server, it can be mitigated on what they can do/access.  On the windows side, sshfs isn't too well supported, but nothing new there as MS doesn't support any network sharing protocols besides it's own smb protocol (evidently, MS designed the smb protocol, Samba is more of grew to port it over from Windows and is following what MS is doing).  There has been a couple sshfs projects that started (like the Google Code projects) top get the support, but sadly after the projects got it's initial goal done, they abandoned the projects.  The one that I found that is still active and working, is sshfs-win (ported from win-sshfs that was abandoned).

sshfs-win:  https://github.com/billziss-gh/sshfs-win

To get sshfs work on windows, you need to install 2 programs, winfsp (Windows Fuse) and sshfs-win.  From there, it is as simple, as mapping a network drive, but with a slight difference.  To map the ssh mount, you do it in the format as \\sshfs\REMUSER@HOST[\PATH].  The nice part is, sshfs-win is one of the few that also supports logging in using a private key, thus also allowing SSO capabilities.  Securing all this is done on ssh side, so it is easy to lock it down so only login using a private key and other parts.  For my uses, I more of made a private key with no password for their account (not too secure, but I can work around on that, to mitigate that vulnerability like only allowing certain ip addresses).   If you want, you could also chroot that user to their home directory; so they can't access anything outside (you can also remove that account's groups they are a member in, for just sharing files they only need that account's group, users and any others that isn't needed).

----------

## AJM

I'm interested and not just trying to be awkward, but... I honestly think that what you've achieved is much more difficult and potentially less secure than just using samba as a DC.

That would provide you with Kerberos & LDAP based SSO, per file / folder / share permissions as fine-grained or broad as you desire "out of the box" as it were in one ready-to-go and widely used package.

The users you create in samba can (if you desire) be "Windows only" users, without any kind of working unix account on the server - making it more secure again.

Again, you're clearly free to use whatever you like and I'm happy you've cobbled something together that works for you - but I'm genuinely interested in why you wouldn't just use the straightforward samba DC approach which is arguably more secure and easier.

----------

## ct85711

One of the biggest things, why I am refusing on going with a full DC setup, is because I'd rather have a light weight setup.  Considerring, I only have a hand full of users; having a the full thing is a complete waste on resources.  I don't need anything beyond file sharing capabilities, on a very limited amount of machines.  When I start having quite a few more machines/users and/or the users move between the machines, then a DC would have more benefits.

Since I have no intention of using the DC's dns capabilities (kerberos does not like authenticating machines by IP address, it more of goes by it's machine/domain name).  There is partial support, in that you could turn on kerberos's ability to ticket based with ip address on the server side.  However, you still get a double whammy, by Windows refusing to use kerberos authentication when mapping by IP address (it defaults to password authentication when mapping by IP address, instead of DNS name).  Again, you have to do a registry work around, to get windows to even consider allowing kerberos by ip address.  Now, the fun part; even assuming you did the work arounds for all that; you now get into another interesting issue; host.domain != ip address.  In short kerberos does not translate from the dns name to ip address (it is specifically designed to not have that ability), so now you have multiple records for everything; even more when their ip addresses change.

----------

