I have spent some time setting up LDAP-based authentication in my MacOS, iOS and Linux network, taking account of the special quirks of MacOS and Synology (my NAS). SSH login (SSH keys etc.) works and Samba share mounts work. It was all quite fiddly, and I now know more about LDAP than I ever anticipated.
However...
Having reached a point where I could (at least in theory) log into any machine in my network, I thought it would be nice for users to also have access to the same home directory everywhere. No problem: autofs
, which can also be managed from LDAP! Or so I thought...
I'm trying something like the following to set up Samba home directories for autofs
:
cn=*,ou=auto.home,cn=automount,cn=etc,dc=home,dc=arpa
cn: *
objectClass: automount
objectClass: top
automountInformation: -fstype=cifs,vers=3.0,domain=HOME,rw,username=&,uid=&,gid=& ://s-sy-00.local/home
Some background:
s-sy-00.local
is my Synology NAS where the home directories will live./home
is UNC of the home directory share that Synology serves up for the user defined inusername=
.
The problems start when I log in to a remote machine with SSH. autofs
tries to mount the user's home directory, but needs the user's password. I can put the password into a password=
parameter in the automountInformation
line, or I can put the username and the password into a credentials file that I pass with the credentials=
parameter. Both approaches lead to added complexity (an automount
entry for each user) and duplication (same username and password in two different places: LDAP and the credentials file or the automount
and the posixUser
in LDAP).
Is there a standard way of dealing with this problem? My search engine skills have not turned anything up yet.
It seems to me that there are three possible solutions:
- the one that is obvious to every one else but not to me;
- using the SSH key to mount a credentials file per user (possibly dynamically generated from LDAP) from an SSHFS share;
- using Kerberos for a full-blown SSO.
I would prefer number 1 :-) I have an aversion to Kerberos: it seems to be overkill and is certainly relatively complex.
Can anyone offer some words of wisdom to give me a flying start into the new year?
Well, as long as you're on Linux and if you use password authentication for the initial login, then you can have a PAM module which stashes the password in a kernel keyring where mount.cifs can pick it up. I'm not 100% sure whether cifs-utils currently comes with one, but it does have a
cifscreds
CLI tool which does the same.Still, personally I would just set up Kerberos authentication instead of LDAP. (That is, leaving LDAP to do only the job of a directory service.) Overall Kerberos is just like LDAP: looks complex from the outside, turns out to be very simple when you look closer, except for the million quirks, edge cases and odd decisions going back to 1980s that make it complex again.
It's going to be a bit more versatile than SMB-specific PAM hacks – the same tickets can be used for accessing SMB, NFS, LDAP, HTTP, SSH... You can even reuse your existing LDAP server as the KDC database backend, getting replication for free without having to deal with kprop.
Note that with mount.cifs, both Kerberos and cifscreds are intended to be used when mounting the share with the
multiuser
option, which gives you NFS-like behavior – the same SMB mount can be accessed by several users, and the kernel will automatically use the correct SMB credentials for each uid.And as for SSH public-key authentication, there's not much you can do automatically – either you retrieve a credentials file and use it with
cifscreds
, or you retrieve a credentials file and use it withkinit
... Again I think the latter is more versatile.Although I think that @user1686's answer is the right one, I would still like to share to share the work-around that I found and will use until I can find time to move to a Kerberos solution.
I created a user on the NAS that I called
smbowner
and assigned a password to it. I gavesmbowner
admin rights on the NAS, which means that it can mount an SMB share.I created a Samba credentials file on the machine that needed to mount the SMB share. I put it into
/etc/samba/credentials/s-sy-00
and it looks like this:Note that the credentials file does not contain a domain definition.
In its defence, it can be said that this solution works, though I'm not sure how safe it would be in a more hostile environment than mine.
How does it work?
smbowner
has sufficient permissions to mount any share on the NAS. Theuid=&
andgid=&
parameters ensure that the share is accessible to the local user. I will experiment later with settings permissions for the share on the NAS.Perhaps this will help someone else.
Steve