SSSD really needs to be an idmap option

BloodyIron

Contributor
Joined
Feb 28, 2013
Messages
133
Hi Folks,

I've recently been doing thorough comparison between winbind methods and SSSD methods for SID -> GID/UID translation.

To say it another way, when systems (such as FreeNAS and others) join an Active Directory (AD) domain, the method options in translating Security IDs (SIDs), which are the universal, unique, identifiers for users, groups and other objects, to Group IDs (GIDs) and User IDs (UIDs) as in Linux/Unix environments (in this case FreeNAS).

Now, there are two primary candidates that are talked about extensively, winbind and SSSD. And I'm here to try and convince iX to properly implement SSSD support, in addition to the existing winbind IDMAP methods.

Now, with samba, and winbind, there are 3x backends that the samba documentation talk about ( https://wiki.samba.org/index.php/Identity_Mapping_Back_Ends ), they are:
  1. ad
  2. rid
  3. autorid
Now, while they do _WORK_, each of them have their own limitations, functions, and technical "costs". Here are a few example reasons why these options are not universal for all use-cases (more info can be found in the above link to the mapping backends):
  1. ad - You need to manually set UIDs and GIDs for _EVERY_ object in AD if you want to use this method and have them resolve. This is particularly laborious in terms of IT admin time.
  2. rid - Cannot handle multiple domains, domain trusts, or forest trusts, due to duplicate ID translation for different SIDs.
  3. autorid - Similar restrictions to rid
Now, in basic cases, rid is probably going to work for a lot of people, and so far as I can tell, it is reliable, and when configured correctly, is consistent. However, this ignores a growing schism in the open source/Linux/Unix environment, and that is, that many environments use SSSD for idmap translation, and a lot of official documentation (including RHEL) exclusively instructs IT staff to use SSSD in favour of any other idmap method. Furthermore, there are tangible benefits to other parts of their environments, such as SSSD enabling GPO HBAC stuff apply to Linux systems. So far as I can tell, something completely impossible with winbind IDMAP methods (ad/rid/autorid).

So, where does the issue lay?

Well, for environments where SSSD is already in-place, or they want to roll out SSSD, FreeNAS/TrueNAS is completely infeasible for them. Because their ENTIRE ENVIRONMENT would need to be migrated FROM SSSD to winbind idmapping (ad/rid/autorid), just so that FreeNAS/TrueNAS SMB/CIFS shares could authenticate access via AD user/group permissions. This is due to FreeNAS/TrueNAS not comprehensively having SSSD available for idmapping (ad method).

How do I know this? Because the sole bug report that talks about it ( https://redmine.ixsystems.com/issues/9812 ) is closed, and has not been touched in over a year.

Now, how do I know that RHEL and others are directing people to use SSSD? Well, because it's in their official documentation ( https://access.redhat.com/documenta...inux/7/html/windows_integration_guide/sssd-ad ), it's also in debian documentation ( https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectorySssd ), and there is compelling reasoning to use it, from as far back as 2015 ( https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/ ).

Almost every time I read about someone talking about connecting samba to an existing AD DC/domain, they talk about SSSD. Not just for shares, but user and group enumeration, for logins too.

So, I think it's about time iX systems takes SSSD seriously, and implements it as a proper idmap method for FreeNAS/TrueNAS. Because until you do iX, you will never be able to get FNAS/TNAS into RHEL environments, or many other environments that are using SSSD, and have zero interest in switching idmap methods.

Please reconsider opening the bug I linked, and implementing this. I want FNAS/TNAS to be in more environments, and with the direction of the industry, Linux/Unix environments are only going to grow, and are already massive.

I want to see you continue to be a part of that.
 

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457
The devs are seldom seen here. Feel free to enter a feature request and site this post though.
 

BloodyIron

Contributor
Joined
Feb 28, 2013
Messages
133
Haven't checked in a while, where do you think is the best place to file a Feature Request?

Also, hoping this particular forum post can stimulate discussion on the topic :)

The devs are seldom seen here. Feel free to enter a feature request and site this post though.
 

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457

kdragon75

Wizard
Joined
Aug 7, 2016
Messages
2,457
Ok I tried.
 

Alvin

Explorer
Joined
Aug 12, 2013
Messages
65
FreeIPA also used SSSD, and Corral supported it. It worked really well for the short time I tried.
 

anmnz

Patron
Joined
Feb 17, 2018
Messages
286
That's the very place that the bug report resides... that ISN'T getting attention though...
The ticket is marked as closed. Of course it's not getting attention! If you read the comments on the ticket, it looks like it may have been a casualty of FreeNAS 10.

If you want to communicate with the FreeNAS developers then opening a new feature request ticket like @kdragon75 says really is the right thing.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,545
Since this post has come to my attention via bugtrackers, I would like to clarify.
(1) It is possible to use Samba's idmap backends to configure trusted domains. Currently they can be added as auxiliary parameters under services->SMB. In the future we will add GUI support for this.
(2) It is possible to configure idmap_rid so that the IDs allocated by the backend match the default allocation strategy for SSSD. The algorithm in SSSD is basically to generate a murmur3 hash of the Domain's objectSID, then take the modulus of this value with the total available slices (default 10000), then multiply the value by the slice size (default 200000), and add a single slice to it (an additional 200000). This gives the low range that the RID value is then added to. I wrote a small C utility to do this for you if you feed the objectSID for the domain into it. https://github.com/anodos325/samba_scripts/blob/master/sssd_idmap_compat/sssd_idmap_compat.c

The place where this breaks down is if the AD domain exceeds 200000 objects (or whatever the slice size is in SSSD). We will not duplicate this behavior because at this point SSSD's allocation strategy becomes non-deterministic, which is _bad_.

In 11.3 we are removing SSSD support and will use a different software package for handling LDAP binds.
 
Top