Forum Discussion

Matthew Brice's avatar
Matthew Brice
Copper Contributor
Sep 16, 2026

SMB over QUIC stops working when enable Cert based Access Control

Trying to test out SMB over QUIC so can eliminate need for vpn. When setting "Set-SmbServerCertificateMapping -RequireClientAuthentication $true" (enabling Access Control) client can no longer connect. "System error 67 has occurred. The network name cannot be found." which seems like a generic error. It works without Access Control enabled. I have:

 

  • Created a GoDaddy public cert for the Windows 2025 server, and installed it on the Windows 2025 server, used Powershell to make SMB Server Certificate mapping.
  • Used Intune Cloud PKI to create SCEP profile with Client Authentication EKU and pushed it out to test client. (This is also first time using Cloud PKI)
  • Exported Intune Cloud PKI root and issuer CA certs and installed on the Windows 2025 server to Trusted Root and Intermediary Cert Authorities
  • Grant-SmbClientAccessToServer with the Intune PKI issuer certificate.
  • The client is a Entra Only Windows 11 pc.

 

I've read the Access Control doc many times. Added/removed/re-added config over 5x. Obviously I'm missing something but I cannot figure out what. 

  • Is Goddady Cert not correct?
  • Intune Cloud PKI cert not correct?
  • something else?

I've looked at it ad nauseum in packet capture, but since tls 1.3, handshake is mostly encrypted. I've scoured Event Viewer, but nothing stood out. 

 

Any help greatly appreciated.

2 Replies

  • Matthew Brice's avatar
    Matthew Brice
    Copper Contributor

    First, full disclosure I'm not well versed with Certificate Authorities.  Just know the bare basics.

    But I run the 'Get-SmbClientAccessToServer -Name' command it does show the Cloud PKI issuing CA cert.  I also did try the using individual cert by SHA256 identifier per microsoft documentation, and that also did not work. But both are active, so not sure if that matters.

    Client Cert issued via Intune to the device (not user) and does have the Client Auth EKU and I verified it has the private key. So not sure if any other config changes needed there. Just did defaults. But not 100% confident it is correct.

    SMBClient > Connectivity log on client shows correct cert was offered to server

    SMBServer > Connectivity does not seem to have a cooresponding entry at all for the attempt in the server side logs.

    Get-SmbServerCertificateMapping -Name <fqdn> does return the GoDaddy cert as I expect.
    I verified the Cloud PKI Root CA cert is in "Trusted Root Certificate Authorities > Certificates" and verified Cloud PKI Issuer CA cert is in "Intermediate Certification Authorities > Certificates"

     

    Connection still fails even when server configured like this:

    Set-SmbServerCertificateMapping -Name <fqdn> -RequireClientAuthentication $true -SkipClientCertificateAccessCheck $true . Even skipping access check it fails. So makes me think it is not the certs causing issues as per se(?)

    Appreciate any more help. Or even how to collect more data to point me in the right direction because I'm stumped right now.



  • Since SMB over QUIC already works without client authentication, I would focus on the client certificate/access-control configuration rather than the GoDaddy server certificate.

     

    On the Windows 11 client, verify that the SCEP certificate is in the Local Computer personal store, contains the Client Authentication EKU, has a private key and chains to a CA trusted by the SMB server.

     

    On the server, run:

     

    Get-SmbClientAccessToServer -Name <server-fqdn>

     

    and verify that the CA/issuer you added actually matches one of the certificates in the client's certificate chain. As a test, you can also allow the individual client certificate by its SHA256 identifier instead of the issuer.

     

    Windows Server 2025 performs both certificate validation and the SMB access-control check when RequireClientAuthentication=$true. Entra-only clients are supported; an AD domain is not required for this mechanism. Also check Microsoft-Windows-SMBClient/Connectivity and Microsoft-Windows-SMBServer/Connectivity logs during the failed connection.