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