Do any commercial NAS vendors use the SSD ID mapping algorithm?

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.


[1]: https://github.com/SSSD/sssd/issues/6126

[Spike White]

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(a)runbox.com&gt; 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.
>
>
>  [1]: https://github.com/SSSD/sssd/issues/6126
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  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...

[2] 
https://docs.microsoft.com/en-gb/archive/blogs/activedirectoryua/identity...

[Spike White]

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/213f...


We are currently up to schema version 88 (Windows 2019).


Spike

On Sun, May 1, 2022 at 11:02 PM <mythmail(a)runbox.com&gt; 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...
>
>  [2]
>
>
> https://docs.microsoft.com/en-gb/archive/blogs/activedirectoryua/identity...
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  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(a)gmail.com&gt;:

> 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/213f...
>
> We are currently up to schema version 88 (Windows 2019).
>
> Spike

[Joakim Tjernlund]

On Wed, 2022-05-04 at 22:21 +0000, mythmail(a)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(a)gmail.com&gt;:
>  
>  > 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.mi...
>  > 
>  > We are currently up to schema version 88 (Windows 2019).
>  > 
>  > Spike
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
>  List Guidelines:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>  List Archives:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>  Do not reply to spam on the list, report it:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
>

[Joakim Tjernlund]

On Thu, 2022-05-05 at 00:49 +0200, Joakim Tjernlund wrote:
>  On Wed, 2022-05-04 at 22:21 +0000, mythmail(a)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(a)gmail.com&gt;:
>  > 
>  > > 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.mi...
>  > > 
>  > > We are currently up to schema version 88 (Windows 2019).
>  > > 
>  > > Spike
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > Fedora Code of Conduct:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
>  > List Guidelines:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>  > List Archives:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>  > Do not reply to spam on the list, report it:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure....
>  
>

[Spike White]

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(a)runbox.com&gt; 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(a)gmail.com&gt;:
>
>  > 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/213f...
>  >
>  > We are currently up to schema version 88 (Windows 2019).
>  >
>  > Spike
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  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

[Spike White]

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(a)runbox.com&gt; 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(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Bryan Smith]

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.


-- 
Sent from my phone, apologies for any brevity as well as autocorrect
Bryan J Smith - http://linkedin.com/in/bjsmith

On Mon, May 9, 2022, 09:44 Spike White <spikewhitetx(a)gmail.com&gt; wrote:

>  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(a)runbox.com&gt; 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(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

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. 

-- 
Sent from my phone, apologies for any brevity as well as autocorrect
Bryan J Smith - http://linkedin.com/in/bjsmith

[Patrick Goetz]

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(a)runbox.com 
> <mailto:[e-mail]>> 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(a)gmail.com
>     <mailto:[e-mail]>>:
> 
>      > 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/213f...
>    
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.mi...
>      >
>      > We are currently up to schema version 88 (Windows 2019).
>      >
>      > Spike
>     _______________________________________________
>     sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>     <mailto:[e-mail]>
>     To unsubscribe send an email to
>     sssd-users-leave(a)lists.fedorahosted.org
>     <mailto:[e-mail]>
>     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.fe...
>     List Guidelines:
>     https://fedoraproject.org/wiki/Mailing_list_guidelines
>    
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>     List Archives:
>     https://lists.fedorahosted.org/archives/list/[e-mail]...
>    
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>     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....
> 
> 
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
> 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.                        <<

[James Ralston]

On Thu, Apr 28, 2022 at 10:39 PM <mythmail(a)runbox.com&gt; 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