<?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 is it possible to override a cached SID mapping in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/is-it-possible-to-override-a-cached-SID-mapping/m-p/460375#M44929</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;We have a fairly restricted environment where the SVMs are joined to a domain in a forest where the SMB users all reside. No other domains in the forest matter from a CIFS perspective. The problem is we have several multiprotocol shares and at some point someone created an AD account called "root" in a domain we have no control over, much less can tell whether is being used or not, but in every SVM I see non-stop secd messages such as these&lt;/P&gt;&lt;P&gt;ERROR secd.nfsAuth.noCifsCred: vserver (svm01) NFS authorization cannot retrieve CIFS credentials. Error: Get user credentials procedure failed&lt;/P&gt;&lt;P&gt;Determined UNIX id 0 is UNIX user 'root'&lt;/P&gt;&lt;P&gt;UNIX user 'root' mapped to Windows user 'THATOTHERDOMAIN\root'&lt;/P&gt;&lt;P&gt;Using cached 'THATOTHERDOMAIN\root' SID mapping.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any legitimate root user has apparently zero access to shares it once was correctly mapped to Administrators.&lt;/P&gt;&lt;P&gt;I don't see anything "in the cache" which can be deleted, and I've tried creating what I thought would be "override" mappings to make THATOTHERDOMAIN\\root" map to a restricted or bogus local account, but it makes no diff.&lt;/P&gt;&lt;P&gt;How can I tell the SVM's when you see this account forget it exists or tell it to map to a defunct local account?&lt;/P&gt;&lt;P&gt;Or, as some articles seem to imply - having the trusts fully in place so tickets and such can be passed is the only way (that seems wrong in so many ways). All I know is this seems to really foil user mapping as it pertains to admins or proper root accounts we want to have full access by way of NTFS security.&lt;/P&gt;&lt;P&gt;9.14.1P11&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
    <pubDate>Mon, 28 Apr 2025 19:45:25 GMT</pubDate>
    <dc:creator>uphill</dc:creator>
    <dc:date>2025-04-28T19:45:25Z</dc:date>
    <item>
      <title>is it possible to override a cached SID mapping</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/is-it-possible-to-override-a-cached-SID-mapping/m-p/460375#M44929</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;We have a fairly restricted environment where the SVMs are joined to a domain in a forest where the SMB users all reside. No other domains in the forest matter from a CIFS perspective. The problem is we have several multiprotocol shares and at some point someone created an AD account called "root" in a domain we have no control over, much less can tell whether is being used or not, but in every SVM I see non-stop secd messages such as these&lt;/P&gt;&lt;P&gt;ERROR secd.nfsAuth.noCifsCred: vserver (svm01) NFS authorization cannot retrieve CIFS credentials. Error: Get user credentials procedure failed&lt;/P&gt;&lt;P&gt;Determined UNIX id 0 is UNIX user 'root'&lt;/P&gt;&lt;P&gt;UNIX user 'root' mapped to Windows user 'THATOTHERDOMAIN\root'&lt;/P&gt;&lt;P&gt;Using cached 'THATOTHERDOMAIN\root' SID mapping.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any legitimate root user has apparently zero access to shares it once was correctly mapped to Administrators.&lt;/P&gt;&lt;P&gt;I don't see anything "in the cache" which can be deleted, and I've tried creating what I thought would be "override" mappings to make THATOTHERDOMAIN\\root" map to a restricted or bogus local account, but it makes no diff.&lt;/P&gt;&lt;P&gt;How can I tell the SVM's when you see this account forget it exists or tell it to map to a defunct local account?&lt;/P&gt;&lt;P&gt;Or, as some articles seem to imply - having the trusts fully in place so tickets and such can be passed is the only way (that seems wrong in so many ways). All I know is this seems to really foil user mapping as it pertains to admins or proper root accounts we want to have full access by way of NTFS security.&lt;/P&gt;&lt;P&gt;9.14.1P11&lt;/P&gt;&lt;P&gt;thanks&lt;/P&gt;</description>
      <pubDate>Mon, 28 Apr 2025 19:45:25 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/is-it-possible-to-override-a-cached-SID-mapping/m-p/460375#M44929</guid>
      <dc:creator>uphill</dc:creator>
      <dc:date>2025-04-28T19:45:25Z</dc:date>
    </item>
  </channel>
</rss>

