LDAP Service breaks Users and Shares interface

Troubleshooting
4

Thanks so much for the reply! Here are the results:

Here’s the output from that command. This response is the same whether the LDAP Service is running or not.

shares:/opt/rockstor # poetry run python3 -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'system'

I do not have any usernames on BOTH systems. I only have one local user and they are not in LDAP.

The output was:

shares:/opt/rockstor # poetry run python3 run_combined_users.py
Traceback (most recent call last):
  File "run_combined_users.py", line 1, in <module>
    import django
ModuleNotFoundError: No module named 'django'

Here are the results:

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*" uint32:"0"
method return time=1694523856.668428 sender=:1.23 -> destination=:1.28 serial=6 reply_serial=2
   array [
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1061"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1236"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/14181"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1238"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1240"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1234"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/9523"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1233"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/2858"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/13760"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1229"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1232"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1237"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1235"
   ]

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*@<your.fulldomain.com>" uint32:"0"
Error sbus.Error.Errno: 1432158243: Cannot parse input

Hopefully this will provide something useful. Thanks for the help!

1 Like
5

Hi Philip!

Thanks for jumping in on this! I would be happy to update to 4.6.1-0. I THOUGHT I was installing a stable version, but obviously didn’t get that right. I read a lot, and while I understand how the final testing build becomes the next stable release, it wasn’t completely clear to me how to tell what is considered a stable version.

Do I need to just start from scratch with 4.6.1-0, or is there a way to update to that from 4.5.8-0? If this all works out, I’m planning on getting the subscription, but haven’t done that yet since this is still a Proof-Of-Concept.

Thanks again!

6

Thanks @phillxnet for the correction here… I was a bit too focused on the SSSD bit here, unfortunately.

@bhotrock , my apologies for the inaccurate instructions. You can run the same instructions but make sure to replace python3 with python.
Also, good idea with running them with and without the LDAP service turned ON; it can be helpful in case they return an error when LDAP is ON.

Sorry again for my confusion earlier.

7

Just to keep you updated, I did figure out how to update to 4.6.1-0. So I’ll run through the troubleshooting listed by @Flox based on 4.6.1-0.

3 Likes
8

Thanks @Flox
Here are the results using “python”

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/rockstor/src/rockstor/system/users.py", line 38, in <module>
    from osi import run_command
  File "/opt/rockstor/src/rockstor/system/osi.py", line 55, in <module>
    SHUTDOWN = settings.SHUTDOWN
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 56, in __getattr__
    self._setup(name)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 39, in _setup
    % (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting SHUTDOWN, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

I get this same result both with and without LDAP running.

shares:/opt/rockstor # poetry run python run_combined_users.py
Traceback (most recent call last):
  File "run_combined_users.py", line 3, in <module>
    django.setup()
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/__init__.py", line 22, in setup
    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 56, in __getattr__
    self._setup(name)
  File "/opt/rockstor/.venv/lib/python2.7/site-packages/django/conf/__init__.py", line 39, in _setup
    % (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting LOGGING_CONFIG, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

And lastly, I discovered that I hadn’t properly formatted the domain information in:

The result from that is:

shares:/opt/rockstor # poetry run dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.ListByName string:"*@ldap.mydomain.net" uint32:"0"
method return time=1694535029.103214 sender=:1.74 -> destination=:1.97 serial=30 reply_serial=2
   array [
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1061"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1236"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/14181"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1238"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1240"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1234"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/9523"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1233"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/2858"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/13760"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1229"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1232"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1237"
      object path "/org/freedesktop/sssd/infopipe/Users/ldap_2ejfhp_2eorg/1235"
   ]

I appreciate the help!

3 Likes
9

My bad… I forgot yet another crucial bit: you need to define the DJANGO_SETTINGS_MODULE first. This would thus be:

cd /opt/rockstor
export DJANGO_SETTINGS_MODULE=settings
poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"

My sincere apologies for all these errors on my end… I’m obviously not really focused lately.

2 Likes
10

No problem at all. I’m just really impressed by the team’s responsiveness!!
So here’s the output with LDAP running:

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
{u'mdavis': (1229, 1229, ''), u'dherr': (1234, 1234, ''), u'rpc': (492, 65534, '/sbin/nologin'), u'bmage': (13760, 13760, ''), u'at': (25, 25, '/usr/sbin/nologin'), u'dockremap': (489, 477, '/bin/false'), u'upsd': (493, 480, '/usr/sbin/nologin'), u'polkitd': (485, 472, '/sbin/nologin'), u'jlebman': (1232, 1232, ''), u'statd': (491, 65533, '/sbin/nologin'), u'shellinabox': (482, 468, '/bin/false'), u'lp': (495, 487, '/usr/sbin/nologin'), u'mail': (494, 481, '/usr/sbin/nologin'), u'rkirk': (1240, 1240, ''), u'jforman': (9523, 9523, ''), u'postgres': (490, 479, '/bin/bash'), u'messagebus': (499, 499, '/usr/bin/false'), u'pesign': (488, 476, '/bin/false'), u'ntp': (74, 474, '/bin/false'), u'sbillings': (2858, 2858, ''), u'nobody': (65534, 65534, '/bin/bash'), u'sshd': (484, 471, '/usr/sbin/nologin'), u'nginx': (483, 470, '/usr/sbin/nologin'), u'ouradmin': (14181, 14181, ''), u'systemd-timesync': (496, 496, '/usr/sbin/nologin'), u'mhoffman': (1235, 1235, ''), u'bradf': (1000, 100, '/bin/bash'), u'rjennings': (1233, 1233, ''), u'daemon': (2, 2, '/usr/sbin/nologin'), u'systemd-network': (497, 497, '/usr/sbin/nologin'), u'slolly': (1237, 1237, ''), u'postfix': (51, 51, '/usr/sbin/nologin'), u'chrony': (486, 473, '/usr/sbin/nologin'), u'asanderson': (1238, 1238, ''), u'bfindley': (1061, 1061, ''), u'avahi': (487, 475, '/usr/sbin/nologin'), u'bhannson': (1236, 1236, ''), u'root': (0, 0, '/bin/bash')}

bradf is the local user.
Without LDAP running:

shares:/opt/rockstor # poetry run python -c "from system.users import get_users;sys_users = get_users();print(sys_users)"
{u'rpc': (492, 65534, '/sbin/nologin'), u'at': (25, 25, '/usr/sbin/nologin'), u'dockremap': (489, 477, '/bin/false'), u'upsd': (493, 480, '/usr/sbin/nologin'), u'polkitd': (485, 472, '/sbin/nologin'), u'statd': (491, 65533, '/sbin/nologin'), u'shellinabox': (482, 468, '/bin/false'), u'lp': (495, 487, '/usr/sbin/nologin'), u'mail': (494, 481, '/usr/sbin/nologin'), u'postgres': (490, 479, '/bin/bash'), u'messagebus': (499, 499, '/usr/bin/false'), u'pesign': (488, 476, '/bin/false'), u'ntp': (74, 474, '/bin/false'), u'nobody': (65534, 65534, '/bin/bash'), u'sshd': (484, 471, '/usr/sbin/nologin'), u'nginx': (483, 470, '/usr/sbin/nologin'), u'systemd-timesync': (496, 496, '/usr/sbin/nologin'), u'bradf': (1000, 100, '/bin/bash'), u'daemon': (2, 2, '/usr/sbin/nologin'), u'systemd-network': (497, 497, '/usr/sbin/nologin'), u'postfix': (51, 51, '/usr/sbin/nologin'), u'chrony': (486, 473, '/usr/sbin/nologin'), u'avahi': (487, 475, '/usr/sbin/nologin'), u'root': (0, 0, '/bin/bash')}

With LDAP running, here are the combined_users:

shares:/opt/rockstor # poetry run python run_combined_users.py
asanderson
at
avahi
bfindley
bhannson
rkirk
bmage
bradf
mdavis
chrony
daemon
dherr
jlebman
dockremap
ouradmin
jforman
slolly
lp
mail
messagebus
mhoffman
nginx
nobody
ntp
pesign
polkitd
postfix
postgres
rjennings
root
rpc
sbillings
shellinabox
sshd
statd
systemd-network
systemd-timesync
upsd

I’ve mangled the usernames since this is a public forum. combined_users originally displayed in alphabetical order.

And without LDAP running:

shares:/opt/rockstor # poetry run python run_combined_users.py
at
avahi
bradf
chrony
daemon
dockremap
lp
mail
messagebus
nginx
nobody
ntp
pesign
polkitd
postfix
postgres
root
rpc
shellinabox
sshd
statd
systemd-network
systemd-timesync
upsd

Let me know what’s next. Thanks!

3 Likes
11

Thanks a lot, @bhotrock …

So everything looks OK so far, which is both good and puzzling.

That being said… I’ve “played” a lot more with that, tried a few things, and I am now in a situation where I do get the same error as you do. BUT, given this may very well result from different causes, let’s see if it is actually the same as you.
Could you please do the following?

  1. enable debug mode:
cd /opt/rockstor
export DJANGO_SETTINGS_MODULE=settings
poetry run debug-mode ON
  1. Open your browser developer tools (usually with Ctrl + Shift + I). The lines below may differ slightly depending on the browser but I think they should be fairly similar; below is what I have in Firefox.
  2. Go to the “Network” tab.
  3. In your browser, navigate to the “Users” page in Rockstor. You should see a single line in the Developer tools window (“Network” tab) with a 500 return code. It should be the GET call to users?page=...
  4. Click on this error, and you should now be able to see more details about that request.
  5. These details should be organized in multiple tabs, click on the “Response” tab. Do the first few lines look as what I have (see below)?
    image
    image1459×661 106 KB

Let me know if you cannot find this information due differences in browser and I’ll try to walk you through it better.

2 Likes
12

Thanks for your work on this. Glad you were able to duplicate it. Yes, they look the same. See attached screenshot.

Screen Shot 2023-09-12 at 4.57.52 PM
Screen Shot 2023-09-12 at 4.57.52 PM1595×595 95.3 KB

1 Like
13

Thanks a lot for looking at it and confirming!

So, it seems we have some issue with LDAP users that belong to a group with a gid that does not exist on the Rockstor machine. I still don’t know exactly at what steps we fail here but at least we now seem to have a reproducer so I can dig deeper into it.
I’ve had to dig quite a bit into SSSD and AD in the past few days so I’ll keep looking into this LDAP issue; hopefully I’ll figure out how exactly we are failing here.

Thanks for your help and patience, that is extremely helpful!

1 Like
14

I wanted to mention: The users in LDAP don’t currently have any LDAP group memberships. The memberOf infrastructure exists and I have one group in the tree, just for testing purposes, but no users are a member of that group.

I believe we’re just setting the posixAccount gidNumber to be the same as the uidNumber. I THINK this would be the user’s “primary” group. If it would make more sense to set that to a specific group, that would exist in Rockstor, I could do that. I’d probably just create a “staff” or “users” group. (Not sure if “users” already exists or not.)

I’m not really interested in creating/populating groups and their memberships from LDAP, and have planned to manage group membership directly on the Rockstor server. I’m really only looking for Rockstor to be able to authenticate using the LDAP provided username/password.

Just wanted to make sure you had a clear picture of what’s happening on my side of things. Thanks again for all the help!!

3 Likes
15

@Flox I just wanted to confirm the following:
I changed each user’s gidNumber in OpenLDAP to 100, for the “user” group, which matches my local Rockstor account. I then disabled the LDAP Service, cleared the sssd cache, re-enabled the LDAP Service and verified that each user was showing as gid 100 using getent passwd. At that point, the error on the Users page went away and the LDAP users were listed on the Users page, under Other system users.

So I think you’re on the right path with the issue relating to nonexistent gids. However, it’s interesting that LDAP groups don’t have this same issue. My one LDAP group has a gidNumber of 2000 and that shows up without issue.

While I could move forward with this work around, I’m wondering if you could confirm something for me: Will this impact the use/security/permissions of private user home directories within Rockstor?

Also, is there a way to “promote” an LDAP user so they can login to the Rockstor Web UI (like checking the box when manually setting up a new user?

Thanks again for your help!

3 Likes
16

Hi @bhotrock,

Thanks a lot for going through all that trouble; that is an excellent confirmation indeed!

The TL;DR is that we are wrongly assuming that a LDAP user belongs to a LDAP PosixGroup and we thus fail to get a groupname when querying the associated gidNumber. This is why we get the error you saw.

This is not intentional but a result of a “particularity” for LDAP users that we did not account for. This was tested with Active Directory users (which do have associated groupnames, and thus the process worked) but not with LDAP. This was entirely my doing, though, so thank you so much for bringing this to light.

Now, for the details:
You were on point when you noticed that this error appears in all pages where we fetch users. This is usually done from our front-end where we fetch a UserCollection. For instance:

When we fetch this UserCollection, we “collect” all entries from our User model through the /api/users API endpoint:

This in turn trigger our back-end:

There, you can see that we return all entries of our storageadmin.models.user model via combined_users(); this is why I originally wanted to see what it returned for you.

Now, when we fetch our User model entries, we also trigger the following that we use to get the groupname:

The first part of this tries to use the grp python library to get the groupname but fails as expected for an LDAP/AD user. We catch this error and then try again using InfoPipe which uses SSSD to get that information from the LDAP/AD user. This works for an AD user. For an LDAP user, however, we fail because the gidNumber will not correspond to a posix group that SSSD can see unless it is set as a objectClass: posixGroup in the LDAP server. When no group is found for that gidNumber, InfoPipe returns the file not found error that you saw above.

To resolve this, I can think of (at first):

  • catching that infopipe error and return the gidNumber as groupname. This might be problematic down the line if Rockstor expects a true name here. I’m unsure of that, however, so it would need more investigation here.
  • catching that infopipe error and do nothing. Groupname would be empty; we would need to verify it does not cause more problems, though, as for the first option.

Interesting indeed… would this group be a objectClass: posixGroup group? Does it show in getent group and getent group -s sss?
Note that we fetch groups a bit differently than we fetch users, though, so that’s probably why you see it without a problem in the Groups page UI.

Not that I can think of, no. This would need to be verified though. Being able to log in to Rockstor’s webUI is only intended for “administrator” users, but it is true that these users being from LDAP could be a possibility.

With this workaround, my understanding is that your LDAP users would belong to the gid 100 (users) primary group. As a result, you can use that group to control permissions in the Shares UI (Shares — Rockstor documentation). Let me know if that answers your question.

I’m more than open to integrate your needs, though. I’m personally not an LDAP “user” so feel free to describe as much as you’d like what you would need or how you would envision using LDAP in Rockstor. We’re always seeking user feedback on what is really needed and this kind of feedback is particularly needed for AD/LDAP; this thread and participation is thus particularly appreciated.

2 Likes
17

Thanks @Flox !!

Yes, this is a posixGroup. And it does show up in getent group and in getent group -s sss.

I’m not sure if it’s “standard” for the uid (uidNumber) and gid (gidNumber) to match or not. I have seen some systems that are setup that way, and others that are not. I THINK that some systems may use a user’s “private” GID (the one that matches their UID) as a way to provide access to and security for a user’s “home” directory. However, I’m not CERTAIN of any of this. :grin: I’m not sure how Rockstor works with home directories, since I haven’t been able to work with these LDAP users until now. I was mainly just wanting to verify that if every LDAP user’s primary group is 100, that they will still be able to have a private home directory share, with access controlled by UID rather than GID. I hope that makes sense. I’m pretty sure that will work, but haven’t had time to test it out yet.

Thank you again for all your work on this! Assuming this Rockstor “proof of concept” ends up working for us, I’ll be happy to help with any LDAP based testing in the future. Again, I’m just very impressed with the responsiveness of your team!! Great job!!

3 Likes
18

Good, that makes sense, then!

As you said, it is dependent on the distribution–to the best of my knowledge. For instance, in our CentOS days, the default when creating a new user account was to have a new uid and gid created, and thus identical. In openSUSE, the default is to create a new uid and set the default gid to the users group (gid: 100). That being said, it feels like there may be some standardization towards the former as I’ve seen, for instance, talks from the openSUSE folks to move away from the default gid:100 to a dedicated uid/gid for each new user (might be related to the security aspect you mentioned, for instance). Not sure if/when that would happen, though. All of this to say that it really depends.

You should be able to set the LDAP user as owner of a Share and then limit permissions for that Share as you wish at the owner level (Shares — Rockstor documentation). If you remove any permission to the Group or Other, then the Share should remain accessible to the owner only.

Note that there also are more options available to you with access control lists (Access control lists in Linux | Security and Hardening Guide | openSUSE Leap 15.5). While we do not offer a GUI for these yet, this is something that has been brought up already (ACLs on shares request · Issue #981 · rockstor/rockstor-core · GitHub) and I recently had to get myself a bit more acquainted with those (Access control with Active Directory and group based permissions - #9 by Flox) so personally, my interest in seeing these integrated has grown quite a bit.

By the way, what would be the workflow about which you are thinking with regards to home directories of your LDAP users? You would like to have their home dir created on their workstation(s) when they log into them, but have the data stored in Rockstor? Something else?

1 Like
19

A corresponding issue has been created in our rockstor-core repo:

2 Likes
20

A pull request with a fix has now been submitted:

1 Like
21

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!

3 Likes
22

Sorry you’re running into another problem here.

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:

Using SSSD as a client in IdM or Active Directory domains has certain limitations, and Red Hat does not recommend using SSSD as ID mapping plug-in for Winbind. For further details, see the “What is the support status for Samba file server running on IdM clients or directly enrolled AD clients where SSSD is used as the client daemon” article.

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

Why Samba 4.8?

Here’s what happened in Samba 4.8, from their abbreviated release notes (Samba Features added/changed - SambaWiki):

Domain member setups require winbindd

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?

2 Likes
23

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!

3 Likes