Hello,
I work in an enterprise environment which has both Linux and Windows systems and an Active Directory for identity.
For good reasons we need to move from Linux based file servers to a NAS. The problem is that all our Linux systems use the SSD ID mapping algorithm to calculate UID and GIDs (and it works great!). We've not found a commercial NAS vendor who supports this algorithm so we can't just drop their products in place.
Do you know of any who do please?
Surely there must be some as many NASs run on Linux and BSD and use open source software heavily.
My colleague asked this in a GitHub issue [1] but I thought that it might be best to ask here.
Thanks in advance! Ed.
Ed,
When you say "uses the SSSD ID mapping algorithm to calculate UID and GID", do you mean that algorithm that formulaically calculates the user's UID off the Windows SID?
We are a large company (~25 - 27k sssd clients), but we use the RFC 2307bis schema extension from Microsoft. Beaucoup NAS vendors support this, because they can do LDAP authentication and set their desired LDAP filters to pull the correct AD object attribute.
I thought that other SSSD algorithm is mainly used in smaller shops. Where they didn't want to extend the AD schema.
Spike
On Thu, Apr 28, 2022 at 9:39 PM mythmail@runbox.com wrote:
Hello,
I work in an enterprise environment which has both Linux and Windows systems and an Active Directory for identity.
For good reasons we need to move from Linux based file servers to a NAS. The problem is that all our Linux systems use the SSD ID mapping algorithm to calculate UID and GIDs (and it works great!). We've not found a commercial NAS vendor who supports this algorithm so we can't just drop their products in place.
Do you know of any who do please?
Surely there must be some as many NASs run on Linux and BSD and use open source software heavily.
My colleague asked this in a GitHub issue [1] but I thought that it might be best to ask here.
Thanks in advance! Ed.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi Spike,
Yes I mean exactly that.
From what I've read that RFC and the schema extension for AD has been deprecated for some time. (Sorry I can't find the link now on my phone but I'm confident that it's right)
Thanks! Ed
On 30/4/22 8:03 am, Ed wrote:
From what I've read that RFC and the schema extension for AD has been deprecated for some time. (Sorry I can't find the link now on my phone but I'm confident that it's right)
Hi Spike,
Turns out that I might be wrong. Microsoft pulled their "Identity Management for UNIX" product back in 2014 [1] and an article from back then [2] states that you could continue to use RFC 2307 GID/UID attributes with Active Directory. I'm struggling to find out if they can/should be added to a modern AD in 2022 now. Do you have any information on that or are you using an AD which has been running for years?
Thanks! Ed
[1] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-se...
[2] https://docs.microsoft.com/en-gb/archive/blogs/activedirectoryua/identity-ma...
Ed,
Got this from our AD team:
This MS article contains info regarding RFC 2307 and mentions it being included in Window 2003 and later. Hopefully, this helps.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515...
We are currently up to schema version 88 (Windows 2019).
Spike
On Sun, May 1, 2022 at 11:02 PM mythmail@runbox.com wrote:
On 30/4/22 8:03 am, Ed wrote:
From what I've read that RFC and the schema extension for AD has been
deprecated for some time. (Sorry I can't find the link now on my phone but I'm confident that it's right)
Hi Spike,
Turns out that I might be wrong. Microsoft pulled their "Identity Management for UNIX" product back in 2014 [1] and an article from back then [2] states that you could continue to use RFC 2307 GID/UID attributes with Active Directory. I'm struggling to find out if they can/should be added to a modern AD in 2022 now. Do you have any information on that or are you using an AD which has been running for years?
Thanks! Ed
[1]
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-se...
[2]
https://docs.microsoft.com/en-gb/archive/blogs/activedirectoryua/identity-ma... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Thanks Spike!
It looks like extending the AD to cater for UIDs and GIDs is the most supported and least effort change to allow us to use any NAS.
If we get approval, we'll likely come up with a system to populate these values in the AD from an existing SSSD Linux client so that they match, then we can transition all other Linux clients over from using the SSSD mapping algorithm to using these values from AD.
Ed
4 May 2022 12:26:01 am Spike White spikewhitetx@gmail.com:
Ed,
Got this from our AD team:
This MS article contains info regarding RFC 2307 and mentions it being included in Window 2003 and later. Hopefully, this helps. https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515...
We are currently up to schema version 88 (Windows 2019).
Spike
On Wed, 2022-05-04 at 22:21 +0000, mythmail@runbox.com wrote:
Thanks Spike!
It looks like extending the AD to cater for UIDs and GIDs is the most supported and least effort change to allow us to use any NAS.
If we get approval, we'll likely come up with a system to populate these values in the AD from an existing SSSD Linux client so that they match, then we can transition all other Linux clients over from using the SSSD mapping algorithm to using these values from AD.
This is what we do too. Only way to make sure UID/GID are known for all apps, NAS included.
Ed
4 May 2022 12:26:01 am Spike White spikewhitetx@gmail.com:
Ed,
Got this from our AD team:
This MS article contains info regarding RFC 2307 and mentions it being included in Window 2003 and later. Hopefully, this helps. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.micro...
We are currently up to schema version 88 (Windows 2019).
Spike
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor... List Guidelines: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj... List Archives: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo... Do not reply to spam on the list, report it: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%...
On Thu, 2022-05-05 at 00:49 +0200, Joakim Tjernlund wrote:
On Wed, 2022-05-04 at 22:21 +0000, mythmail@runbox.com wrote:
Thanks Spike!
It looks like extending the AD to cater for UIDs and GIDs is the most supported and least effort change to allow us to use any NAS.
If we get approval, we'll likely come up with a system to populate these values in the AD from an existing SSSD Linux client so that they match, then we can transition all other Linux clients over from using the SSSD mapping algorithm to using these values from AD.
This is what we do too. Only way to make sure UID/GID are known for all apps, NAS included.
And while you do the above, add SHELL and HOME too, possibly something more I cannot remember.
Ed
4 May 2022 12:26:01 am Spike White spikewhitetx@gmail.com:
Ed,
Got this from our AD team:
This MS article contains info regarding RFC 2307 and mentions it being included in Window 2003 and later. Hopefully, this helps. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.micro...
We are currently up to schema version 88 (Windows 2019).
Spike
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor... List Guidelines: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj... List Archives: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo... Do not reply to spam on the list, report it: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%...
Ed,
That sounds like an excellent plan. Every major NAS vendor (I work for one) supports LDAP authentication. Even against AD domain controllers.
(I'm a Linux engineer, not a storage engineer -- so I don't know the details of the NAS LDAP auth, only that it's fully supported and used here internally on the NAS mgmt heads.)
Are you doing NFSv3 or NFSv4? I believe that NFSv4 bases file/dir access on 'user@domain', not UIDs. NFSv3 uses traditional UIDs/GIDs. I'm guessing you're doing NFSv3.
(We do NFSv3 from the NAS shares onto our Linux servers whenever possible ourselves. We do NFSv4 only when one of the new NFSv4 features is required.)
Spike
On Wed, May 4, 2022 at 5:21 PM mythmail@runbox.com wrote:
Thanks Spike!
It looks like extending the AD to cater for UIDs and GIDs is the most supported and least effort change to allow us to use any NAS.
If we get approval, we'll likely come up with a system to populate these values in the AD from an existing SSSD Linux client so that they match, then we can transition all other Linux clients over from using the SSSD mapping algorithm to using these values from AD.
Ed
4 May 2022 12:26:01 am Spike White spikewhitetx@gmail.com:
Ed,
Got this from our AD team:
This MS article contains info regarding RFC 2307 and mentions it being
included in Window 2003 and later. Hopefully, this helps.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515...
We are currently up to schema version 88 (Windows 2019).
Spike
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hey Spike,
We need to use NFS v4 with Kerberos for security reasons.
This reminds me why we've kept running our file servers on Linux VMs - everything just worked with SSD and at a surprising scale. Now (if we go ahead) we've got a lot of work to do affecting all Linux systems, all to just add a NAS.
In this research I've found that other people share my thoughts about NAS vendors supporting Linux better. Life really would be easier for many of us if a NAS vendor just implemented the SSSD ID mapping algorithm. It's open source, there's nothing to stop them using it along with all the other FOSS they use!
FYI The only reason we're considering all this is an internal customer desperately wants to have a single "share" for windows and Linux larger than the 64TiB limit on LUNs our hypervisor dictates. We investigated other hacks to work around this but all would have increased data risk significantly. (I didn't mention this before as I wanted this conversation to stay on this topic and not stray to alternate solutions)
Thanks, Ed
Hey Spike,
I'm curious, why is it you previously said that SSSD based ID mapping is only used at small scale?
I understand that it's not using a single source of truth (the directory) to provide UID and GID values, but the algorithm is so consistent. I ran a test across all our systems in one network today and I couldn't find any UIDs which didn't match. We've even got different versions of SSSD (different RHEL and Ubuntu releases).
Thanks! Ed
Ed,
I'm a Linux engineer, reading and learning on this sssd mailing list. I had just never seen a large company that used that algorithm that's all.
Spike
On Mon, May 9, 2022 at 2:21 AM mythmail@runbox.com wrote:
Hey Spike,
I'm curious, why is it you previously said that SSSD based ID mapping is only used at small scale?
I understand that it's not using a single source of truth (the directory) to provide UID and GID values, but the algorithm is so consistent. I ran a test across all our systems in one network today and I couldn't find any UIDs which didn't match. We've even got different versions of SSSD (different RHEL and Ubuntu releases).
Thanks! Ed _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Define 'large'?
In general many NAS, SAN and even Network vendors have issues with LDAP trees and attributes any way.
So UID, GID and UPN (user@domain) and NT/Dom SID enumeration and mapping is a secondary issue.
I.e., I spend a lot more time dealing with maintaining a 'light' 389/RHDS or AD-LDS tree just for those Storage/Network devices than anything else. This is the biggest issue with AD and a lot of attributed and added schema.
There shouldn't be any issue with SSSD scaling to tens of thousands of records, and it's more of an issue of how the Storage/Network devices use or even search the LDAP attributes across a lot of records.
Thanks Bryan,
Yes, that's my point! I still feel that the issue is with the NAS vendors. Adding the SSSD algorithm would be a small amount of effort and "just work" for most of us working with Linux systems. As I mentioned before it seems that multiple people say they've asked their NAS vendor to do this, yet the vendors aren't interested.
Having to add and manage additional fields in AD just to cater for a NAS seems like a huge cost. We don't need to do so for any other reason and yet have a fully interoperable environment today.
Ed.
On 10/5/22 12:51 am, Bryan Smith wrote: Define 'large'?
In general many NAS, SAN and even Network vendors have issues with LDAP trees and attributes any way.
So UID, GID and UPN (user@domain) and NT/Dom SID enumeration and mapping is a secondary issue.
I.e., I spend a lot more time dealing with maintaining a 'light' 389/RHDS or AD-LDS tree just for those Storage/Network devices than anything else. This is the biggest issue with AD and a lot of attributed and added schema.
There shouldn't be any issue with SSSD scaling to tens of thousands of records, and it's more of an issue of how the Storage/Network devices use or even search the LDAP attributes across a lot of records.
On 5/5/22 08:31, Spike White wrote:
Ed,
That sounds like an excellent plan. Every major NAS vendor (I work for one) supports LDAP authentication. Even against AD domain controllers.
(I'm a Linux engineer, not a storage engineer -- so I don't know the details of the NAS LDAP auth, only that it's fully supported and used here internally on the NAS mgmt heads.)
Are you doing NFSv3 or NFSv4? I believe that NFSv4 bases file/dir access on 'user@domain', not UIDs. NFSv3 uses traditional UIDs/GIDs. I'm guessing you're doing NFSv3.
NFSv4 can also use traditional UIDs/GIDs for authorization. POSIX extended ACLs work as well.
(We do NFSv3 from the NAS shares onto our Linux servers whenever possible ourselves. We do NFSv4 only when one of the new NFSv4 features is required.)
Spike
On Wed, May 4, 2022 at 5:21 PM <mythmail@runbox.com mailto:mythmail@runbox.com> wrote:
Thanks Spike! It looks like extending the AD to cater for UIDs and GIDs is the most supported and least effort change to allow us to use any NAS. If we get approval, we'll likely come up with a system to populate these values in the AD from an existing SSSD Linux client so that they match, then we can transition all other Linux clients over from using the SSSD mapping algorithm to using these values from AD. Ed 4 May 2022 12:26:01 am Spike White <spikewhitetx@gmail.com <mailto:spikewhitetx@gmail.com>>: > Ed, > > Got this from our AD team: > > This MS article contains info regarding RFC 2307 and mentions it being included in Window 2003 and later. Hopefully, this helps. > > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515b-9cf2-43e8-b6c8-47b13cd61281 <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-adts%2F213f515b-9cf2-43e8-b6c8-47b13cd61281&data=05%7C01%7C%7Cd49d4a8104ef45f18a1308da2e9b8e68%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637873542902207635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X8rbAV7xug4rhBGtkk9tg3B7hibz%2F7qeVVO75rvcLOU%3D&reserved=0> > > We are currently up to schema version 88 (Windows 2019). > > Spike _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org <mailto:sssd-users-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C01%7C%7Cd49d4a8104ef45f18a1308da2e9b8e68%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637873542902207635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=GsIqoo2x%2FIZs%2BsrP5aoL4v0mpclw5artiXdscO7dblQ%3D&reserved=0> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C01%7C%7Cd49d4a8104ef45f18a1308da2e9b8e68%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637873542902207635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=PUAfqvxnTInq%2BfjRSCWsNjoq%2Fh8axP6Ju%2BFAsAlnCSw%3D&reserved=0> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org&data=05%7C01%7C%7Cd49d4a8104ef45f18a1308da2e9b8e68%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637873542902207635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=wMaXkzMfqqvp4KLwkSz1lXMb9ybgOUJVXKEVpBEEoj8%3D&reserved=0> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructure&data=05%7C01%7C%7Cd49d4a8104ef45f18a1308da2e9b8e68%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C637873542902207635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=VRQnpOQaHGyk7%2B5C4PihSMHK8fSs%2BXNHY1o4r3KpZ7Y%3D&reserved=0>
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
This message is from an external sender. Learn more about why this << matters at https://links.utexas.edu/rtyclf. <<
On Thu, Apr 28, 2022 at 10:39 PM mythmail@runbox.com wrote:
For good reasons we need to move from Linux based file servers to a NAS. The problem is that all our Linux systems use the SSD ID mapping algorithm to calculate UID and GIDs (and it works great!). We've not found a commercial NAS vendor who supports this algorithm so we can't just drop their products in place.
We use a NetApp device, and although we have asked NetApp to implement the sssd algorithm as a way to map the SIDs of AD users/groups to Unix uids/gids, and they have said they will eventually do so, they have not given us a timeframe for implementation.
But NetApp can synchronize its passwd/group files via an external URL. So what we did instead was to set up a web server that serves passwd and group files for the NetApp.
To generate the files, I wrote a utility called genent that reads AD LDIF data and synthesizes passwd(5) and group(5) files the same as sssd does, but only needs one call to getgrnam(3) to do so:
https://github.com/qralston/genent
If you find it useful, I welcome and encourage feedback…
Thanks for the suggestion James!
That sounds similar to what our existing SAN vendor (Hitachi) does with their NAS devices. We avoided it as it had a very low maximum user limit (from memory only 1000 at a time) and it sounded unmanageable through automation anyway (no API etc).
It sounds like you've got something which is manageable, but what are the security implications?
Thanks again, I'll look in to your utility now.
I had heard rumour that the (now Dell) Isilon NAS devices (which are a clustered BSD based system) may support the algorithm, but I was (perhaps naively) hoping people here might be able to confirm and could know of more options.
Why is Linux interoperability so hard in NASs in 2022 without using a deprecated AD schema extension?!
Ed
sssd-users@lists.fedorahosted.org
-
Bryan Smith -
James Ralston -
Joakim Tjernlund -
mythmail＠runbox.com -
Patrick Goetz -
Spike White