<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic LDAP config for SVM (to enable auth-sys-extended-groups) in Network and Storage Protocols</title>
    <link>https://community.netapp.com/t5/Network-and-Storage-Protocols/LDAP-config-for-SVM-to-enable-auth-sys-extended-groups/m-p/466496#M10233</link>
    <description>&lt;P&gt;Some years ago while trying to make multiprotocol shares work well accross a mixed bag of name services, we landed on configuring the data SVM to point to AD as the LDAP source. This seemed to solve several issues provided the accounts in AD have their unix attributes set, but we have since ran into issues around the "permission denied" due to too many groups, users being in substantially more than 16 groups, etc. Note the mixed bag means we have an entirely seperate LDAP DB which sort-of syncs from AD periodically, but it's a one-way street. Basically the NFS client machines do not use AD for LDAP but their own, and as such, the SVM can't talk to it to figure out group membership if the GID is beyond that 16 group limit.&lt;/P&gt;&lt;P&gt;Rather than risk breaking multiprotocol shares does anyone know if multiprotocol and SMB-only shares would be affected if the SVM is pointed to the open LDAP server (is SMB dependant on AD LDAP lookups?) or since it looks like we need to enable&amp;nbsp;auth-sys-extended-groups, would the better solution just be build a new SVM so it does nothing but NFS to that LDAP DB and essentially decouple NTFS from NFS entirely?&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
    <pubDate>Thu, 26 Mar 2026 20:29:20 GMT</pubDate>
    <dc:creator>uphill</dc:creator>
    <dc:date>2026-03-26T20:29:20Z</dc:date>
    <item>
      <title>LDAP config for SVM (to enable auth-sys-extended-groups)</title>
      <link>https://community.netapp.com/t5/Network-and-Storage-Protocols/LDAP-config-for-SVM-to-enable-auth-sys-extended-groups/m-p/466496#M10233</link>
      <description>&lt;P&gt;Some years ago while trying to make multiprotocol shares work well accross a mixed bag of name services, we landed on configuring the data SVM to point to AD as the LDAP source. This seemed to solve several issues provided the accounts in AD have their unix attributes set, but we have since ran into issues around the "permission denied" due to too many groups, users being in substantially more than 16 groups, etc. Note the mixed bag means we have an entirely seperate LDAP DB which sort-of syncs from AD periodically, but it's a one-way street. Basically the NFS client machines do not use AD for LDAP but their own, and as such, the SVM can't talk to it to figure out group membership if the GID is beyond that 16 group limit.&lt;/P&gt;&lt;P&gt;Rather than risk breaking multiprotocol shares does anyone know if multiprotocol and SMB-only shares would be affected if the SVM is pointed to the open LDAP server (is SMB dependant on AD LDAP lookups?) or since it looks like we need to enable&amp;nbsp;auth-sys-extended-groups, would the better solution just be build a new SVM so it does nothing but NFS to that LDAP DB and essentially decouple NTFS from NFS entirely?&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
      <pubDate>Thu, 26 Mar 2026 20:29:20 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Network-and-Storage-Protocols/LDAP-config-for-SVM-to-enable-auth-sys-extended-groups/m-p/466496#M10233</guid>
      <dc:creator>uphill</dc:creator>
      <dc:date>2026-03-26T20:29:20Z</dc:date>
    </item>
  </channel>
</rss>

