Forum Discussion
SMB over QUIC Client Access Control is inconsistent
We have set up SMB over QUIC on some Windows 2025 file servers and generally it works well. Unfortunately of course, it is not secure by design since there is no MFA or conditional access in the picture. Thus securing the connections falls to its Client Access Control feature where you can allowlist or blacklist connections using client certificates.
We implemented this in multiple environments (different domains) and although it works initially, it then starts failing with no changes having been made. The behavior is always the same across various domains once it starts failing - first the connection shows successful:
The SMB connection was successfully established.
Endpoint Name: FILES
Transport: Quic
Server socket address: x.x.x.x:443
Client socket address: x.x.x.x:8205
Connection ID: 0xB1D0039C01XXXXXX
Mutual authentication: Yes
Access control: Yes
Then immediately it fails less than a second later:
Quic connection shutdown.
Error: Mutual authentication failed.
Reason: Server close the connection.
Endpoint Name: FILES
Transport Name: \Device\SmbQUICIpv4_0006_x.x.x.x
Guidance:
This event indicates that the winquic connection is shutting down by the server. This event commonly occurs because the server certificate mapping is not created. It may also be caused by the server failed to configure the winquic connections.
In our case the issue was the certificate EKU. Almost 100% sure the guidance was followed when we set this up many months ago, so I believe the doc has since been updated - regardless it does clearly point out that Client Authentiation needs to be an EKU:
https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control
Once we reissued a cert with Client Auth in the EKU, CAC started working for us. w00t!
Check Server Certificate Mapping
One of the common causes for this issue is that the server certificate mapping for SMB over QUIC is not correctly set up or is missing. For SMB over QUIC to authenticate properly, the server needs to map its certificate correctly for the client to trust it.
- Verify the certificate used by the server: Ensure that the server certificate used by SMB over QUIC has the appropriate subject alternative name (SAN) entries and is trusted by the client machines. It should be mapped correctly to the server in question.
- Check the certificate mapping on the server:
- On the SMB server, open PowerShell as an administrator and run the following command to verify the certificate mapping for QUIC:
Verify Client Certificate Configuration
Since you are using Client Access Control with certificates, check if the client certificates are properly configured and valid. This is crucial for the authentication process. Ensure that:
- The client certificate is valid and issued by a trusted authority.
- The client certificate is correctly configured to use in the SMB over QUIC connection (for example, correctly enrolled in the Windows Certificate Store).
The client should be presenting a valid certificate when attempting to authenticate, and the server should trust this certificate based on your allowlist configuration.
3. Ensure Correct Group Policy Settings
SMB over QUIC may require specific Group Policy settings to be configured on both the server and client to work properly.
- On the SMB server:
- Open Group Policy Management and navigate to Computer Configuration > Administrative Templates > Network > SMB over QUIC.
- Ensure that Enable SMB over QUIC is enabled.
- On the client machine:
- Verify that the client is configured to accept SMB over QUIC connections and that it has the necessary certificate installed for mutual authentication.
- You may also want to check that the client is set up to trust the root certificate authority (CA) that issued the server's certificate.
4. Monitor Logs for Additional Details
Look at the Event Viewer logs for more details on why the authentication is failing. Specifically, check under the following logs:
- System Logs: Look for any SMB or QUIC related entries that might give you more information on the failure, especially regarding authentication errors.
- Application Logs: Check for any errors related to certificate validation or mutual authentication failures.
In the Event Viewer, you can filter for logs related to SMB or QUIC and check the timestamps around the failed connection attempts to see if there are any related warnings or errors.
5. Check for SSL/TLS Configuration Issues
Ensure that there are no issues with SSL/TLS configuration on both the server and client. For SMB over QUIC to function properly, the server must support the TLS 1.3 protocol, and both sides must have compatible cipher suites.
- Check the cipher suites supported by both the server and client:
- On the server, run the following command to list the supported TLS cipher suites:
In our case the issue was the certificate EKU. Almost 100% sure the guidance was followed when we set this up many months ago, so I believe the doc has since been updated - regardless it does clearly point out that Client Authentiation needs to be an EKU:
https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control
Once we reissued a cert with Client Auth in the EKU, CAC started working for us. w00t!
It sounds like you've resolved the issue by reissuing the certificate with the proper Client Authentication Extended Key Usage (EKU), which is essential for SMB over QUIC client access control.
This is a common pitfall in certificate-based configurations, where an incorrect EKU setting can prevent the correct functionality of secure communications, such as SMB over QUIC. For SMB over QUIC to function properly, the client certificate needs to include Client Authentication in its EKU.
The documentation may indeed have changed over time, and it’s great that you caught this detail. It's always a good idea to double-check the latest guidance, especially with certificates and security protocols, as they can have specific requirements that evolve over time.
I'm glad to hear that reissuing the certificate solved the issue and that Client Access Control (CAC) is now working for you.
