Azure NetApp Files: SMB Volume Creation Fails Due to LDAP Bind Issue After October 2026 Domain Controller Updates

Question

Azure NetApp Files: SMB Volume Creation Fails Due to LDAP Bind Issue After October 2026 Domain Controller Updates

Jeff Goodman 0

SUMMARY

Creating an SMB volume in Azure NetApp Files fails while ANF creates its AD machine account.

ANF reports:

Failed to create the Active Directory machine account "ANF-xxxx". Reason: LDAP Error: The supplied credential is invalid ... Successfully connected to ip <DC>, port 88 using TCP ... Successfully connected to ip <DC>, port 389 using TCP ... Unable to connect to LDAP (Active Directory) service on <dc-fqdn> (Error: Invalid credentials) Result: RESULT_ERROR_LDAPSERVER_INVALID_CREDENTIALS

The credentials are not the problem. A packet capture on the DC shows that ANF authenticates its LDAP bind with a Kerberos service ticket for the CIFS service, cifs/<dc-fqdn>, where an LDAP service ticket, ldap/<dc-fqdn>, is expected. The DC rejects the bind because the ticket's target name is not an LDAP SPN.

**WHAT THE CAPTURE SHOWS (**DC side, filtered to the ANF source IP)

AS-REQ -> PREAUTH_REQUIRED -> AS-REQ -> AS-REP (TGT issued)
TGS-REQ -> TGS-REP (service ticket issued)
LDAP bindRequest, SASL/GSS-SPNEGO, TCP 389, in cleartext AP-REQ ticket sname: cifs/<dc-fqdn> (KRB5-NT-SRV-HST)
LDAP bindResponse: invalidCredentials (49) 80090303: LdapErr: DSID-0C0906D1, comment: The GSSAPI target name does not match any LDAP SPN's registered for this server., data 0, v4f7c

The KDC issues the cifs/ ticket because cifs/ is an alias of HOST/ on the DC computer account. The DC's LDAP service then rejects it because the bind must target an ldap/ SPN.

DC Security logs agree: every attempt shows 4768 (TGT, 0x0, AES-256), 4769 (service ticket for DC$, 0x0), and 4624 (Kerberos network logon, type 3) for the join account from the ANF IP. There are no 4625, 4771, or 4776 failures.

ENVIRONMENT

On-premises AD DS, single domain, 2 writable DCs in the configured AD site
Windows Server 2022 (build 20348), October 2026 security updates installed
LDAP server signing: not required (LDAPServerIntegrity = 1)
LDAP channel binding: not configured
Both DCs have the complete standard ldap/ SPN set; no duplicate SPNs
A/PTR records valid for both DCs; AD replication healthy
Target OU exists; join account has delegated computer-object rights

WHAT DOES NOT CHANGE THE RESULT

ANF AES Encryption on/off
ANF LDAP Signing on/off
ANF LDAP over TLS on/off. With LDAP over TLS enabled, StartTLS works from the ANF VNet to both DCs and the root CA is uploaded, but ANF still sends the machine-account bind in cleartext with no StartTLS, and still uses the cifs/ ticket.
Recreating the AD connection
Different join accounts and a simplified password
Explicit AES encryption types on the join account
Fails identically against either DC

RELATED

NetApp has published a KB with the identical error string for ONTAP after the October 2026 DC patches: "LDAP servers unavailable after October 2026 DC patches" https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/LDAP_servers_unavailable_after_October_2026_DC_patches

QUESTIONS

Is anyone else seeing ANF AD joins fail this way after the October 2026 DC updates?
Is there a supported ANF-side fix, or a supported DC-side mitigation that doesn't require removing security updates?
Can Microsoft confirm whether ANF is expected to request ldap/<dc-fqdn> for this bind?

A support case is open with Microsoft.

Sajin P S 0 Reputation points

2026-11-10T08:31:16.8833333+00:00

Hi,

Even after enabling LDAP Signing, and if you still see the Domain joining fail, then check if you different DNS namespace for the Domain controller PTR record. I have seen the similar issue with Netapp ONTAP systems. ONTAP canonicalizes the LDAP server hostname by reverse lookup zone, use the identified PTR record domain name space to construct the SPN request. This is more lightly applicable if you have third party DNS solution where DC forward lookup part of AD integrated DNS and reverse lookup zone record part of third party DNS solution with different name space ( DC FQDN - DC1.contoso.com, where PTR record point to DC1.contoso.ad.com).

Workaround from netapp is to create a host entry in ONTAP where it points Domain controller with actual FQDN, which will resolve the issue.

With above example, create a host entry with DC1.contoso.com to the IP Address.

Regards,

Sajin P S
Harshavardhan Sriramula 0 Reputation points Microsoft External Staff Moderator

2026-11-10T15:58:34.46+00:00
Hello @Jeff Goodman ,

Thank you for the very thorough write-up. Your analysis is correct, and Microsoft has since confirmed this.

KB5134907 – Access to NetApp SMB shares might fail after installing the October 2026 Windows security update

https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/10/access-to-netapp-smb-shares-might

Is anyone else seeing this?

Yes. This is a documented known issue affecting Azure NetApp Files and NetApp ONTAP after Windows Server security updates released on or after October 13, 2026 are installed on domain controllers. Symptoms include SMB volume creation failing with "Invalid credentials", as well as failures in other operations that depend on AD LDAP (domain discovery, name mapping, user/group lookups). Existing SMB volumes can also be affected.

Cause: the October 2026 updates add a hardening check on domain controllers. LDAP authentication now requires a Kerberos ticket that matches a registered LDAP SPN on the target DC, so a ticket issued for another service can no longer be used to authenticate to LDAP. When Azure NetApp Files / ONTAP connects to AD LDAP with LDAP client session security set to none, it authenticates with a ticket for the DC's cifs/<dc-fqdn> SPN. The DC rejects that bind with the 80090303 / DSID-0C0906D1 error you captured, and ANF reports RESULT_ERROR_LDAPSERVER_INVALID_CREDENTIALS. This matches your 4768/4769/4624 successes with no 4625/4771/4776 failures: Kerberos works, but the LDAP bind is refused.

Supported fix or DC-side mitigation?

Permanent fix: NetApp is working on a resolution so Azure NetApp Files works with the October updates installed. No ETA has been published yet; please follow KB5134907 and the NetApp Knowledge Base for updates.

Supported interim mitigation (no need to remove security updates):

For self-managed ONTAP, NetApp recommends setting LDAP session security to sign or seal. As your testing shows, the ANF AD connection options (AES, LDAP Signing, LDAP over TLS) do not change the ticket ANF uses for this bind. For Azure NetApp Files, the applicable interim step is therefore the DC-side setting documented in KB5134907.

On each domain controller ANF may contact:

Back up the registry.

Open Registry Editor and go to:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Create or modify:

   - Value name: LdapSPNVerificationLevel

   - Value type: REG_DWORD

   - Value data: 0

The setting takes effect immediately; no restart is required. It disables the new LDAP SPN check, so treat it as temporary and restore the default value of 1 once the Azure NetApp Files fix is available. Restoring it earlier will bring the bind failures back.

Please do not register additional or nonstandard SPNs (for example, mapping cifs/ to the LDAP service) or uninstall the October updates. Neither is necessary with the documented workaround.

Should ANF request ldap/<dc-fqdn> for this bind?

Yes. With the October 2026 hardening in place, the domain controller accepts LDAP binds only with a ticket for the LDAP SPN (ldap/<dc-fqdn>). Using cifs/<dc-fqdn> for the LDAP bind is the behavior KB5134907 identifies as the cause, and it is what the pending NetApp resolution is intended to address.

Next steps

Apply LdapSPNVerificationLevel = 0 on the DCs in the configured AD site.

Retry creating the SMB volume.

If it still fails, please open (or update) an Azure support case with the failure time (UTC), the correlation ID and the DC-side capture so the issue can be investigated further.

If this answer helped, please consider marking it as accepted so others with the same issue can find it.

Thank you!

1 answer

Your answer

Sajin P S 0 Reputation points

2026-11-10T08:31:16.8833333+00:00

Hi,

Even after enabling LDAP Signing, and if you still see the Domain joining fail, then check if you different DNS namespace for the Domain controller PTR record. I have seen the similar issue with Netapp ONTAP systems. ONTAP canonicalizes the LDAP server hostname by reverse lookup zone, use the identified PTR record domain name space to construct the SPN request. This is more lightly applicable if you have third party DNS solution where DC forward lookup part of AD integrated DNS and reverse lookup zone record part of third party DNS solution with different name space ( DC FQDN - DC1.contoso.com, where PTR record point to DC1.contoso.ad.com).

Workaround from netapp is to create a host entry in ONTAP where it points Domain controller with actual FQDN, which will resolve the issue.

With above example, create a host entry with DC1.contoso.com to the IP Address.

Regards,

Sajin P S

Answer 1

The packet capture makes this look different from an incorrect password, missing OU delegation or network-connectivity problem.

The important sequence is:

Kerberos authentication succeeds and a TGT is issued.
A service ticket is issued.
ANF sends a SASL/GSS-SPNEGO LDAP bind to TCP 389.
The AP-REQ contains cifs/<dc-fqdn> rather than ldap/<dc-fqdn>.
LDAP rejects it because the GSSAPI target name does not match an LDAP SPN.

The successful 4768, 4769 and 4624 events, together with the absence of 4625, 4771 and 4776 failures, support your conclusion that the supplied join credentials are not the underlying problem.

It would not be appropriate to “fix” this by registering a nonstandard SPN, weakening LDAP/Kerberos enforcement, or removing the October security updates. Those actions can introduce authentication ambiguity or reduce domain-controller security, and they do not correct which service principal the ANF client requests.

Recommended next steps:

Keep the Microsoft support case open and provide the packet capture, exact UTC reproduction time, ANF account/volume resource IDs, region, AD connection ID and both domain-controller FQDNs.
Explicitly call out that the LDAP GSS-SPNEGO AP-REQ uses cifs/<dc-fqdn> while the bind target is LDAP.
Include the DC error 80090303 and the message that the GSSAPI target name does not match an LDAP SPN.
Ask support to verify whether the ANF AD-join implementation is expected to request ldap/<dc-fqdn> and whether the October 2026 DC servicing change exposed a known ANF compatibility issue.
If possible, reproduce with a temporary AD connection and collect the ANF-side operation/correlation ID. Avoid repeatedly recreating the production AD connection because that is not changing the Kerberos target name.

Enabling LDAP signing, LDAPS or ANF AES encryption does not necessarily change the Kerberos service principal used for the SASL bind. Your captures show that those settings did not alter the failing request, so they should not be presented as a confirmed workaround.

Based on the supplied evidence, a supported resolution likely requires an ANF-side correction or a Microsoft-published mitigation. Only the ANF and Windows servicing teams can confirm whether this is the same interoperability issue documented for ONTAP after the October updates.

References: