Skip to main content
NetApp Knowledge Base

ONTAP Guidance for Microsoft Security Update KB5073381 (CVE‑2026‑20833)

  1. Last updated
  2. Save as PDF
Views:
8,586
Visibility:
Public
Votes:
1
Category:
ontap-9
Specialty:
nas
Last Updated:

Applies to

  • ONTAP 9
  • Cloud Volumes ONTAP (CVO)
  • CIFS/SMB with Kerberos authentication
  • Active Directory (AD)
  • Microsoft Security Update KB5073381
  • CVE-2026-20833

Answer

Accounts that do not have a value set for the msds-SupportedEncryptionTypes Active Directory attribute

  • By default, ONTAP always sets a value for msds-SupportedEncryptionTypes when the CIFS server is joined to Windows Active Directory
    • Consequently, this change should not impact most ONTAP CIFS servers
    • However, in rare cases, if a DC-side problem causes the msds-SupportedEncryptionTypes Active Directory attribute to be blank, the CIFS server will be impacted 
  • Question: How can we check whether our CIFS server is going to be disrupted by this CVE-fix?
    • If Powershell or the Active Directory Attibute Editor show that the CIFS server's machine account in Active Directory does not have a value set for the msds-SupportedEncryptionTypes attribute, then the CIFS server will be disrupted by the CVE-fix
    • In the below examples, msDS-SupportedEncryptionTypes does not have a value set, so the CVE-fix will be disrupt the CIFS server
      • PS> get-adcomputer svm1 -properties * | select msDS-SupportedEncryptionTypes,KerberosEncryptionType msDS-SupportedEncryptionTypes KerberosEncryptionType ----------------------------- ---------------------- {}
      • clipboard_db2bcab8-73ef-4d71-9c0e-b33f10ca9a64.png
    • In the below example, msDS-SupportedEncryptionTypes has a value set, so the CVE-fix will not disrupt the CIFS server
      • PS> get-adcomputer svm1 -properties * | select msDS-SupportedEncryptionTypes,KerberosEncryptionType msDS-SupportedEncryptionTypes KerberosEncryptionType ----------------------------- ---------------------- 4 {RC4}
  • If the msds-SupportedEncryptionTypes Active Directory attribute is blank, populate it using the steps in the below KB

Cannot change security encryption types on a vserver error: LDAP attribute missing

  • Question: What are the symptom of being impacted.
    • AD Machine account is missing configured encryption types.  (this is the single defining signature for this issue)

How to check supported encryption types for Kerberos in Active Directory

    • CIFS access denied via hostname

Windows cannot access \\hostname
Error code: 0x80004005
Unspecified error

    • Access via IP works
    • Packet capture shows session setup response of KRB5KRB_AP_ERR_MODIFIED
    • Secd contains

 KRB5KRB_AP_ERR_NOT_US

    • klist shows that the client host lacks a working Kerberos ticket for the SVM
    • cifs password-reset fails with

Error: command failed: Password update failed. Reason SecD Error: LDAP attribute missing.

Additional Information

  • Microsoft identifies RC4 as a weak encryption type and recommends transitioning Kerberos environments to AES (AES‑128 / AES‑256).
    • ONTAP shares the same guidance and  recommends disabling RC4 for Kerberos authentication and using AES‑128 / AES‑256.
    • To mitigate RC4-related risks, configure the CIFS server to use AES‑128 / AES‑256.
      • SVMs created in ONTAP 9.13.1 and after have AES enabled by default, so they will not be disrupted by the CVE-fix
      • SVMs created before ONTAP 9.13.1 do not have AES enabled by defaullt, so AES will need to be enabled manually
  • Question: When is this change scheduled to occur?
    • January 2026: Audit phase
    • April 2026: AES becomes the default (RC4 fallback disabled)
    • July 2026: Full RC4 deprecation (enforcement)
  • To view the SVM's currently enabled Kerberos encryption types, run 

cifs security show -vserver svm1 -fields advertised-enc-types

  • To find the name of the SVM's Active Directory machine account

cifs show -vserver svm1 -fields cifs-server

  • Question: What happens to existing RC4-encrypted Kerberos service tickets after switching from RC4/DES to AES?
    • When the client presents its RC4‑encrypted ticket to ONTAP, ONTAP cannot decrypt it, so Kerberos authentication fails
    • After a failed Kerberos authentication attempt, the client should automatically request a new AES‑encrypted ticket from the KDC
    • Consequently, the failure is not visible to the end-user
  • Question: How do we manually force the client to request a new AES‑encrypted ticket from the KDC?

In the client's Powershell, run klist purge

  • Question: Do we need to remove rc4 and des from ONTAP to comply with the Microsoft KB? (ONTAP has 4 permitted Kerberos encryption types: aes-256, aes-128, rc4, des)
    • Theoretically, No; If AES‑128 or AES‑256 is enabledin ONTAP, ONTAP does not require RC4 or DES to be removed.
      • Microsoft’s phased deprecation plan disables RC4 fallback on the KDC/Windows side, not on the storage side.
      • Once Windows AD and clients stop issuing or accepting RC4 tickets, the remaining ONTAP RC4/DES advertisement becomes irrelevant.
      • Note: Starting from ONTAP 9.13.1, AES is enabled by default for Kerberos authentication without requiring manual configuration.
    • Practically, Yes; Netapp recommends disabling RC4 and DES as a precaution, as those encryption types are insecure and in some instances been observed to cause bad interactions with DCs

SMB share slow to load because DC does not accept RC4 encryption

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.