Question: Are there NAS vendors who support the SSSD ID-Mapping Algorithm?

[donateur]

Hello,
Please let me know if this is better asked in a mailing list (I strongly prefer not to join mailing lists at work).

I have a client who, for various reasons, needs a commercial NAS. They have a fully interoperable environment with both Linux (RHEL & Ubuntu) and Windows clients working on the same files. They use MS Active Directory.

All our Linux systems work happily with SSSD using the SSSD ID-Mapping algorithm for converting SIDs to UIDs and GIDs. Even though the algorithm isn't 100% guaranteed to match between systems, we've never observed a problem across thousands of Linux clients.

Does anyone know of a NAS vendor who supports this algorithm?

In my previous research most seemed to support only "winbind" but this does not guarantee common UIDs and GIDs from different Linux clients.

Thank you very much!

Background
Currently a RHEL based fileserver running Samba and NFS is used. However the client have reached some complex limits unrelated to the Linux software and we really need this storage moved to a NAS where a dedicated storage engineer can maintain it.

[hortimech]

If you use the same basic smb.conf on all Linux machines, you will get the same UIDs and GIDs everywhere.

[donateur]

If you use the same basic smb.conf on all Linux machines, you will get the same UIDs and GIDs everywhere.

Thank you. Unfortunately I think you are not understanding the problem. Most Linux systems we have don't need to run samba.

We need a NAS which can act like a Linux server and use the SSSD ID mapping algorithm to determine SIDs and GIDs - all other solutions we've found are either a lot of work and increase maintenance or have been found to be complex and unreliable, especially at scale.

While I appreciate suggestions, is anyone able to answer my original question please?

[jakub-vavra-cz]

Hello,
it is worth noting that uid/gid can be stored in the Active Directory for users/groups so there might be another way to approach this. Depending on the size/complexity of the deployment it might be possible to generate uid/gid and push it directly to the AD. Samba can make use of the uid in AD. If the NAS is running samba it might work.

Nasty hack:
To keep the ids consistent, with/without id mapping, they can be generated with the murmur3 algorithm (as done in sssd).
There is some code in tests that can be used as a reference for computing the uid/gid based on the range size, domain sid and object rid.
https://github.com/SSSD/sssd/blob/master/src/tests/multihost/sssd/testlib/common/utils.py#L1841
https://github.com/SSSD/sssd/blob/master/src/tests/multihost/ad/test_adschema.py#L77

Note that the specific algorithm of current id mapping is an internal implementation detail that can be changed in the future.
This would not be supported solution.

Regards,
Jakub

[donateur]

Hello, it is worth noting that uid/gid can be stored in the Active Directory for users/groups so there might be another way to approach this. Depending on the size/complexity of the deployment it might be possible to generate uid/gid and push it directly to the AD. Samba can make use of the uid in AD. If the NAS is running samba it might work.

Hey @jakub-vavra-cz thanks for that. A colleague started a discussion in the mailing list and this option was raised. We thought that RFC 2307 (support for adding UIDs and GIDs to AD) was deprecated by Microsoft in 2014, but it turns out that only Microsoft's "Identity Management for UNIX" was. Having said that, we are still unclear if Microsoft supports the schema extensions in a modern AD. Do you know please?

To keep the ids consistent, with/without id mapping, they can be generated with the murmur3 algorithm (as done in sssd). There is some code in tests that can be used as a reference for computing the uid/gid based on the range size, domain sid and object rid. https://github.com/SSSD/sssd/blob/master/src/tests/multihost/sssd/testlib/common/utils.py#L1841 https://github.com/SSSD/sssd/blob/master/src/tests/multihost/ad/test_adschema.py#L77

Note that the specific algorithm of current id mapping is an internal implementation detail that can be changed in the future. This would not be supported solution. </nasty hack>

Thanks for that. This is what I was hoping a NAS vendor would be doing as it would be the best for us and for many others based on what I've read. I called it the "SSSD ID-Mapping Algorithm" as that's the exact language used in the manpage for sssd-ad.

I wish there was a consistent convention (even if not a standard RFC) across vendors for this calculation of SID to UID etc. Adding another identifier for each user to our ADs is going to be painful and the generation of valid GIDs and UIDs is another cog we need to keep moving. When all our clients use SSSD things just work - we've never had a UID collision or a problem with file access.

[jakub-vavra-cz]

In SSSD QE we are testing with uid/gid and other posix attributes stored in AD including Windows 2019 so I can confirm that this still works.

MS did drop IDMU/NIS roles form the server but the RFC2307 attributes for uid, gid, home, shell ... are still present and can be configured in GUI or via command line.

We are adding the posix attributes to user accounts either by accessing AD ldap or by using powershell so it is scriptable and it can be automated.

[donateur]

In SSSD QE we are testing with uid/gid and other posix attributes stored in AD including Windows 2019 so I can confirm that this still works.

We are adding the posix attributes to user accounts either by accessing AD ldap or by using powershell so it is scriptable and it can be automated.

Thank you for that. While life would be much easier if a NAS vendor supported something other than winbind, we'll investigate using powershell to automate mapping all our existing users (based on SSSD) and then put in a process for creating a valid ID for new users and groups.

[donateur]

A colleague has had a slightly longer discussion in the mailing list:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/H6FDQOTD63YOHZCOZA3XJMGBKS6XQJUZ/

I'll close this as it's not something the SSSD developers can fix. However I share the thoughts of my colleague - it would not be hard for a NAS vendor to add support for this algorithm and doing so would make life so much easier for Linux Admins.