Is there an ldap client compaitble with sssd?

[AutoTeam]

Hey all,

we have a linux server clients working with sssd and ad access provicder.

We are using sssd algorithm for resolving GID and UID from the SID of domain users (also known as id mapping)

This method cause us a problem while trying to Access nfs share. The main reason for this is problem with id mapping caused by the different algorithms (regular LDAP on NetApp controller against sssd algorithm in the linux client)

Right now we are working with auth=sys and extended groups authentication supported, and all ldap authentications failed and no one can access the files

😮

Tech details: Ontap 9.3 P10, nfs version 4, nfs_v4_id_mapping false, Linux 7.2 server,sssd version 1.16

Is there a method to resolve this issue?

Thanks

[kodiak_f]

Hi There,

My last facility had this exact same problem and after much back and forth with NetApp, we basically had to massage a full AD LDIF dump into a local passwd file  for the NetApp to use so that it knew that a given SID mapped to a given user.  As of about a year ago, per our NetApp folks, this was the ONLY way to make NetApp properly integrate with SSSD.

Lucky for me, my current facility just uses the user ID attribute in AD which when I get around to doing KRB5p, should allow this to work w/o having to feed the NetApp ONTAP devices a passwd file.

[parisi]

On a side note, we do have an open item for SSSD algorithms on our roadmap (no targeted release) so if you want to add some more use cases to justify it being added, have your sales team reach out to our product management.

[parisi · Accepted solution]

We don't currently support SSSD algorithm generated UIDs because ONTAP has no way to query those from the LDAP server; we don't translate the SIDs from AD into UIDs. Instead, we look for specific LDAP UNIX attributes. TR-4835 covers this on page 82.

https://www.netapp.com/us/media/tr-4835.pdf

We do have this on our potential roadmap. To get more traction, reach out to your NetApp sales rep and have them file an FPVR.

[AutoTeam]

another solution I thought about is to just cancel the lookup of extedned groups (by using the command nfs modify -auth-sys-extended-groups disabled) and to disabled nested lookups by the sssd (most of our groups are nested)

By default, I get that NFS accept automatically without resolving all the first 16 groups sent by the NFS client...So it might solve the problem for now, but it seems wierd that NetApp does not offer a proper integration with SSSD...😑

And a final note - I did saw a copy of the PDF file you sent - but it was with "deprecated" watermark than I just ignored it 😅

Sorry for the slow response thogh

[parisi]

NetApp does standard RFC-2307 LDAP compliance. What SSSD does is not an RFC standard; it's a simplicity workaround that adheres to the standard, but requires other LDAP clients to speak the same SSSD language. If you had OpenLDAP clients in this environment as well, they'd have the same issues.

Disabling auth_sys extended groups likely won't help here, as we still need to be able to look up the user and group IDs for authentication. Since those aren't really stored anywhere for ONTAP to look, we'd map Windows users to pcuser and UNIX users to no one if you tried to use NTFS sec style.

I didn't send you the deprecated TR; that's TR-4073.

I sent you TR-4835.

https://www.netapp.com/us/media/tr-4835.pdf

You must have found 4073 on your own. 🙂