ad rid autorid

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. rid - Cannot handle multiple domains, domain trusts, or forest trusts, due to duplicate ID translation for different SIDs. autorid - Similar restrictions to rid

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