ANF SMB volume creation fails after October 2026 DC updates – LDAP 80090303 "GSSAPI target name does not match any LDAP SPN"

Open an Azure NetApp Files support request with the packet trace and correlation details; Microsoft has not publicly documented this exact ANF LDAP GSSAPI target-name regression, a backend-fix schedule, or a supported domain-controller mitigation.

Current published status

• Neither the Windows Server 2022 October update article nor the corresponding release-health information lists ANF machine-account creation failing with LDAP error 80090303. The documented October known issue concerns Exchange/Endpoint Mapper, not LDAP SPN validation.^1^^2^
• The Server 2025 update and release-health pages likewise do not identify this ANF failure. The authentication change documented for KB5126646 concerns NTLMv1-derived SSO credentials under specific conditions, whereas this trace shows successful Kerberos followed by an LDAP GSSAPI target-name rejection.^3^^4^
• Therefore, public information cannot confirm whether Microsoft has internally associated the issue with ANF or committed to an ANF backend correction.

When opening the request, select Azure NetApp Files → Error creating a volume → Resolve issues with creating or deleting an SMB volume. Include:

1. Subscription, region, NetApp account, and failed operation timestamps in UTC.
2. ANF volume deployment correlation/activity IDs.
3. DC versions and exact post-update builds.
4. The LDAP diagnostic text containing DSID-0C0906D1 and 80090303.
5. A filtered packet capture showing:
   • tickets requested for cifs/<dc-fqdn> and host/<dc-fqdn>;
   • successful AS/TGS exchanges;
   • the subsequent failed LDAP SASL/GSSAPI bind.
6. Events 4768, 4769, and 4624 for the same attempt.
7. Confirmation that the behavior reproduces against both Server 2022 and Server 2025 DCs.
8. The successful pre-update baseline, if available, and the matching NetApp KB title.

Ask support to route the case jointly to Azure NetApp Files engineering and Windows AD/LDAP engineering, and specifically request confirmation of whether an ANF-side change or a Windows servicing mitigation is planned.

DC-side mitigation

There is currently no published, supported DC-side registry value, policy change, Known Issue Rollback, or hotfix for this exact target-name rejection. Do not apply the Exchange Endpoint Mapper workaround: it addresses a different documented issue.

Also avoid these unsupported or mismatched workarounds:

• Do not add duplicate or nonstandard LDAP SPNs when ldap/<dc-fqdn> is already correctly registered. Microsoft’s supported SPN tooling can list and safely add an actually missing SPN with setspn -L and setspn -S, but your checks have already ruled out a missing default DC SPN.^5^
• Do not weaken LDAP signing or Kerberos encryption. The ANF troubleshooting guidance enables LDAP signing when the DC requires strong authentication; your connection already has signing enabled and is failing later with a different error.^6^
• Do not apply LDAPS certificate/CNAME registry guidance. LDAP over TLS is disabled here, so LDAPS certificate-name matching and UseHostnameAsAlias are not applicable.
• Avoid uninstalling security updates except under explicit Microsoft Support direction and an approved security exception.

The usual ANF computer-account checks—account enabled, valid msDS-SupportedEncryptionTypes, and delegated permissions—remain relevant only if diagnostics produce attribute or access errors. They do not explain the captured GSSAPI target-name mismatch, so repeating them should not replace escalation.^7^

Existing SMB volumes

Existing volumes are not proven to be universally affected by the evidence available. The failing path is the LDAP operation used while creating the AD machine account for a new SMB volume. Normal SMB data access uses an already-established AD connection and computer account, so successful access to existing shares should not be treated as evidence that new joins will work—or vice versa.

However, existing volumes can require AD/LDAP operations during lifecycle or recovery activities. Microsoft documents possible symptoms after AD changes as:

• user access failures;
• failed CIFS health checks;
• CIFS password-reset failures;
• failures caused by invalid or missing computer-account attributes.^7^

Until Microsoft defines the affected operation set:

• Monitor existing volumes’ CIFS health and user access.
• Avoid unnecessary AD-connection edits or computer-account recreation; ANF documentation warns that AD-connection changes can disrupt client access.^8^
• Report any password-reset, health-check, rejoin, or recovery failure under the same support case with exact timestamps.
• Do not delete/recreate healthy ANF computer accounts as a test.

References

1. October 13, 2026—KB5126655 (OS Build 20348.5761)
2. Windows Server 2022
3. October 13, 2026—KB5126646 (OS Build 26100.33650) | Microsoft Support
4. Windows Server 2025 known issues and notifications
5. How to configure SPN
6. Troubleshoot volume errors for Azure NetApp Files
7. Troubleshoot Azure NetApp Files SMB authentication and CIFS password ...
8. Create and manage Active Directory connections for Azure NetApp Files