Thanks for your work on this! Unfortunately, the saga continues.
After modifying the LDAP users to have the GID of 100 (users), I still couldn’t authenticate on an SMB share. For testing, I wanted to see if the SSSD setup would allow an LDAP user to login to the console. That way I could make sure that LDAP authentication through SSSD was working properly. I had to adjust some things related to SSSD and PAM. I think the thing that finally got it working was running the command: pam-config -a --sss. After that, I was able to log into the console as an LDAP user. So SSSD is working correctly and able to authenticate using the LDAP server. At that point, I knew the share authentication had to be related to samba.
After much googling, it seems that it just may not be possible to get current versions of samba to work correctly with SSSD. I found the following on the samba mailing list:
“You cannot use sssd with Samba >= 4.8.0 even red-hat tells you this.”
While this is just one post on the internet, it seems to be supported by information I found on other software based NAS sites, with people trying to get samba authentication to work. Apparently, it used to work, but made use of some now deprecated NT functions. The only successful implementations of directory based samba authentication that I could find, were using AD or something AD-like and based on Kerberos. So at this point, it seems I’m out of luck handling this through LDAP.
There may be a way to use our main identity management system to build local accounts directly on Rockstor, which would still give me what I’m looking for. I’ll have to spend some time to see if that will work. But I have another pressing project over the next couple of weeks, so will have to put this aside for now.
I haven’t given up on Rockstor, as it does check a lot of boxes for me. Also, the dedication of the Rockstor team has impressed me. This is the kind of product I want to be using/supporting. Thanks again for all the help!
LDAP and Samba are indeed rather fraught with a complicated history, isn’t it? I unfortunately do not have an easy and simple answer for you here but I’d like to provide some additional information and clarification–mostly because I too went through a similar search about LDAP-AD-Samba-SSSD-Winbind quite some time ago and confusion was unfortunately plentiful. Because this topic is somewhat fresh, I thought I would lay out a few bits of information in case that helps you as well.
But first:
Thanks! We may want to include that upon joining an AD/LDAP domain.
Clarifications on SSSD and Samba shares in AD domain members
OK, so let’s get into the meat of the clarifications now…
This is something rather complex but not that much, in a way, so I’ll start with the main statement that inaccurately summarizes the current state of things as I understand it:
“You cannot use sssd with Samba >= 4.8.0 even red-hat tells you this.”
You can very well use SSSD with Samba >+ 4.8.0: have a look at the recent thread here where I confirmed just that: Access control with Active Directory and group based permissions - #9 by Flox. The actual statement by Red Hat (or samba for that matters, see further below) is that you cannot use SSSD-only for id-mapping anymore, and must use Winbind for AD authentication.
In reality, the situation is that you need to take some precautions and there are a couple of limitation if one chooses to rely on SSSD only for id-mapping without Winbind. The best way to explain this would be to paste the actual full statement by Red Hat on the matter (emphasis mine) that I could find in their documentation:
SSSD does not support all the services that Winbind provides. For example, SSSD does not support authentication using the NT LAN Manager (NTLM) or NetBIOS name lookup. If you need these services, use Winbind. Note that in Identity Management domains, Kerberos authentication and DNS name lookup are available for the same purposes.
As you can see, the actual statement is a recommendation on a Winbind vs SSSD choice based on some feature differences (rather well detailed in the second part of that statement); it’s not as simple as “you cannot use SSSD with Samba >= 4.8.0”. You in fact very well can and Red Hat even lays out the instructions to do so on that same page, or in a separate document (How to configure a Samba server with SSSD in RHEL with Winbind handling AD Join - Red Hat Customer Portal).
More important to us, SUSE’s instructions on using SSSD or Winbind for SMB shares to AD users provide the same information: https://www.suse.com/support/kb/doc/?id=000020593
On that page, we can see a clear explanation of our user resolution and authentication is handled in such case:
If you choose to use SSSD, but also want to run a samba file server, then running winbindd is mandatory since samba 4.8. In that situation, when a user establishes an SMB session, SSSD provides the NSS information and smbd delegates the user authentication to Winbind. Additionally, it requires careful setup because both services will attempt to renew the computer account password at regular intervals which can end in one daemon or another not able to login.
The quote above underlines why I highlighted the fact that Red Hat’s statement related to the ID mapping plugin and not SSSD itself. One can still use SSSD to gather user identification from the AD server, “giving” that information to NSS. Then you can instruct Samba to use the nss id-mapping backend to lookup that information.
In practice, this is described very well in SUSE’s instructions to configure the id mapping in smb.conf as such:
idmap config * : backend = tdb
idmap config * : range = 10000-19999
idmap config EXAMPLE : backend = nss
idmap config EXAMPLE : range = 200000-2000200000
Setups with “security = domain” or “security = ads” require a running ‘winbindd’ now. The fallback that smbd directly contacts domain controllers is gone.
A more detailed illustration of how that causes an issue with the pre-Samba 4.8.0 way of doing things illustrates how it was close to being considered a “mis-feature”: https://www.suse.com/support/kb/doc/?id=000020533
As you gathered, it was indeed deprecated for security reasons.
What are the limitations of using SSSD over Winbind for id-mapping?
As described in Red Hat’s statement, using the sss id-mapping plugin has some limitations over the winbind plugin. These relate to NTLM authentication and from what I could gather, would mostly impact access to a Samba share from client machines not joined to an AD domain, for instance, or those AD servers still configured to rely on NTLM. To the best of my understanding, the SSSD project will most likely not put further effort in supporting NTLM as it is considered “legacy” by some and a security risk, especially when compared to alternatives such as Kerberos.
Back to the main topic
@bhotrock, sorry for the rather large distraction here but I really wanted to lay this out for myself (before I forget the details), and for anyone else who might be interested/concerned in the matter.
The question of using LDAP authentication for Samba shares seems indeed a very tricky one (somewhat surprisingly). As you may have probably seen, there used to be a Samba schema available for LDAP but from what I could see it has or will be deprecated (and would require some adjustments to the LDAP server configuration). Another solution floated around seems to be relying on Kerberos authentication via FreeIPA, for instance.
On that matter:
Let us know if/how we can help with that once you get to testing that. Rockstor is very much a “doaucracy” and if a feature will benefit most users without impending existing or other planned features, than it may be worth working on implementing/supporting it.
On this topic, would NFS rather than Samba be an option to you?
I haven’t been able to much time into this due to other projects. A couple of quick thoughts:
Unfortunately, I don’t think NFS would work for this. Main usage is for Windows mapped drives. While it might be possible using NFS, we’re straying far away from “normal” and I want this to be easy to manage for the next IT person.
As I’m looking at other provisioning options, I’m wondering if there’s a way to create Rockstor users (just like you would through the Rockstor GUI) through the API or even the command line. I looked around a bit and didn’t find any documentation for the API, but probably just didn’t look in the right place. But if users can be created in one of those ways, I might be able to leverage that in our IMS to provision Rockstor users.
Hopefully I’ll be able to really spend some time on this again after next week. Thanks again!