1

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:

  1. s-sy-00.local is my Synology NAS where the home directories will live.
  2. /home is UNC of the home directory share that Synology serves up for the user defined in username=.

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:

  1. the one that is obvious to every one else but not to me;
  2. using the SSH key to mount a credentials file per user (possibly dynamically generated from LDAP) from an SSHFS share;
  3. 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?

2 Answers 2

1

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 with kinit... Again I think the latter is more versatile.

1
  • Lots of good stuff here. I think I knew in my heart of hearts that I would have to go with Kerberos. I actually had a Kerberos set-up on Linux about 15 years ago and then replaced it with MacOS Server because after a few apt update; apt upgrade cycles Kerberos stopped working...:-) Perhaps Kerberos will be less intimidating the second time around, Jan 9, 2021 at 21:18
0

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.

  1. I created a user on the NAS that I called smbowner and assigned a password to it. I gave smbowner admin rights on the NAS, which means that it can mount an SMB share.

  2. 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:

username=smbowner
password=whatever

Note that the credentials file does not contain a domain definition.

  1. I changed the LDAP entry to the following:
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,credentials=/etc/samba/credentials/s-sy-00,uid=&,gid=& ://s-sy-00.local/&

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. The uid=& and gid=& 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

1
  • What remains for me is annoyance. Getting this set up has cost me far longer than it should have. I only moved to SMB and Samba because Apple, whose products I use as client devices, is dropping support for other solutions. But SMB is an appalling match for MacOS and Linux architectures. It speaks reams for the excellent Samba that it is even possible. But, although my network is completely devoid of Windows, my LDAP is littered with SIDs and NTPasswords. Jan 14, 2021 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .