SMB over QUIC Testing Guide – Part II

Introduction

In part I, we explained what SMB over QUIC is and how it works. We also prepared the certificate needed. Here we dive into setting up and configuring SMB over QUIC for testing. We will show you how to configure SMB over QUIC with Windows Admin Center and PowerShell. Next to that, we will also show how to manually configure the KDC Proxy solution as it helps understand how it works.

Configure SMB Over QUIC

We already have a certificate for our SMB file server. Now, we have to configure SMB over QUIC. I will show you how to do this with Windows Admin Center and via PowerShell.

Using the Windows Admin Center GUI

Configuring SMB over QUIC is very easy using Windows Admin Center. Just make sure you have the most recent edition installed and update the Files & File Sharing extension for good measure. When you have left the default settings under Settings/Extensions/Automatically update extensions set to “On,” you will get those automatically.

Remotely connect to your Windows Server 2022 Datacenter Azure Edition that you deployed in a supported Azure region. In the early days of the preview, those were West Central US, South Central US, or North Europe. Twenty more came online a week later, and now it should be available in all.

Make sure you join your Windows Server 2022 Datacenter Azure Edition file server to your Active Directory domain. Configure your firewall to allow access from the internet to adding a firewall rule to allow inbound traffic for UDP/443. By blocking inbound traffic for TCP/445 to the file server, you will force QUIC. That might not be what you want on the internal firewall, but on the internet-facing/edge firewall, the latter is probably already in place.

The file server must have access to at least one domain controller for authentication. Heck, even in the lab, I have 2. There is no need to allow any access from (gulp!) or to the internet from your domain controllers.

Connect to the server using Windows Admin Center and click the Settings icon in the lower left. In the File Shares (SMB server) section, under File sharing across the internet with SMB over QUIC, click Configure.

Select the correct certificate, the one you requested based on the SmbOverQuic template we created, and select all the DNS names you want to use. These are all the Subject Alternate Names you used when filling out the cert details.

We leave everything as is by default under the advanced settings and click “Enable.” That’s it. Below you can see that SMB over QUIC is now enabled and configured with the SMB server addresses you selected.

Automation is king!

You can achieve the same with PowerShell, as shown below. You need to gather the data from the chosen cert and enter any DNS name from the Subject Alternate Names field that you want to use for access via SMB over QUIC.

If you want to remove the configuration, you can do so, as shown below

Verify that they are gone with Get-SmbServerCertificateMapping.

Firewalls

As a reminder from Part I, on the Windows Firewall, the rules exist to allow SMB traffic over both TCP/455 and UDP/443. You can block TCP/445 to force UDP/443 (QUIC).

The same goes for the internal and edge firewalls. On the latter, you usually block TCP/445 incoming and outgoing. That is fine, except for specific rules for access to Azure file shares. However, for QUIC to work for telecommuters and road warriors, you will want to allow UDP/443.

TIP! Do not forget that you also need to access that service via the Windows firewall if you run the KDC Proxy Service on your SMB over the QUIC file server. Also, don’t forget that the SMB client must resolve the public FQDN via DNS (or mess with the host file in the lab), and you need rules/NAT in place to make this work in the lab.

Finally, the clients should also be able to reach the CRL/OCSP to check the certificate’s revocation status. That works over TCP/80 and or TCP/443.

I simulate the internet with a separate VLAN with minimal firewall rules to make QUIC, DNS, and the KDC proxy work.

The KDC proxy

Why do we need a KDC proxy?

By default, an SMB client outside of the corporate network will not have access to an Active Directory domain controller when connecting to an SMB over QUIC file server. As a result, authentication uses NTLMv2, which means the file server authenticates on behalf of the client. The good news is that all NTLMv2 authentication or authorization occurs inside the TLS 1.3-encrypted QUIC tunnel.

Still, Kerberos is the better security best practice, and we shouldn’t introduce new NTLMv2 dependencies in deployments in 2021. To allow Kerberos with SMB over QUIC, we can configure the KDC proxy to forward ticket requests on the user’s behalf. Again, this works securely over an HTTPS encrypted communication channel.

The manual configuration is a bit tedious, but it does help you learn and understand how it works under the hood a bit better. That’s a good enough reason to do it manually.

In the future, Microsoft plans for automatic configuration of the KDC Proxy (via Windows Admin Center). That means you will no longer have to set this up manually. That is a big deal. To the best of my knowledge, this little-known feature in Windows that lets clients communicate with KDC servers over an HTTPS channel instead of TCP is officially only supported for the RDS Gateway and DirectAccess (which has been depreciated for VPN again). So, this means that this is a new official supported use case in the making, it seems.

How it works

In essence, the KDC proxy is a service that runs a web listener at https://+:443/kdcproxy and relays Kerberos messages to a Domain Controller for the clients inside a secure TLS tunnel. Clients know that a proxy exists via a GPO setting, so if they cannot reach a DC over Kerberos, they will try the proxy.

As a best practice, you might want to set up two KDC proxy servers in production for redundancy. In the lab, we set up just one.

Configuring the KDC proxy

The SMB over QUIC file server

The steps are tedious and error-prone. You will need to test if you got it right. The good news is that Windows Admin Center will take care of this for you, but I give you the manual steps to set it up before WAC offers this. It’s also good to learn how it works under the hood.

1. Add the URL reservation for the KDC Proxy Service
Open an elevated PowerShell prompt on the SMB file server and run

2. To access file shares, we do not use smart cards or cert-based authentication. That is why here, we disable those options and, by extension, enable password authentication (secured by TLS 1.3).
This entry disables smartcard / Windows Hello certificates

This entry allows password authentication (we are not using a cert for that)

You can achieve the same with PowerShell

Copy the thumbprint value from the certificate associated with SMB over QUIC certificate (there may be multiple lines but they will all have the same thumbprint) and paste it as the Certificate Hash value for the following command:

Check your work with netsh http show sslcert

4. Don’t forget that the PKCProxy has to be available over TCP/443.

5. Add the file server’s SMB over QUIC names as SPNs in Active Directory for Kerberos. In our example, this is

Set the KDC Proxy service to automatic and start it.

The SMB over QUIC client

A domain-joined Windows client will always use DCLocator to find a domain controller for Kerberos exchanges. It is only after this fails it will fall back to other options, such as NTLMv2. Using a KDC Proxy is not a standard fallback method. You need to configure the clients to know that a KDC Proxy exists and point them to it. Group Policies to the rescue!

Configure the following group policy to apply to the SMB client: Computers > Administrative templates > System > Kerberos > Specify KDC proxy servers for Kerberos clients

The “Specify KDC proxy servers for Kerberos clients” policy setting consists of a value name for the fully qualified Active Directory domain name, and the value will be the external domain name we specified for use with the QUIC server. In the lab, the Active Directory domain is named “datawisetech.corp”, the external DNS domain is named “datawisetech.com”:

What we have done above allows for Kerberos realm mapping. That means that if a user roadwarrior@ datawisetech.corp tries to connect to a file server name fsquic.datawisetech.com”, the KDC proxy will forward the Kerberos tickets to a domain controller in the datawisetech.corp domain. All communications happen over HTTPS/443, and no user credentials are exposed.

Apply the group policy and restart the SMB over QUIC client. Make sure the policy is in effect by running gpresult. If it is not, correct whatever is wrong.

If the client cannot get group policy updates anymore, you can use these registry settings:

If you cannot get to the cert revocation list, you can disable the check for that as well. Do this via a group policy setting or in the registry. Doing so is not recommended in production.

Finally, make sure that the Windows Defender Firewall on the SMB file server has a rule that allows inbound TCP/443 to receive authentication requests for the KDC Proxy service. Naturally, the edge firewall(s) must also allow HTTPS/443 inbound to the SMB file server.

You are now ready to access the file share via SMB over QUIC over the internet. Well done!

Do note there are some extra security measures you can take. Microsoft recommends that you provision read-only domain controllers with only the mobile users’ passwords available to the file server. That is outside of the scope of this article.

I hope the (mobile) users have strong passwords and leverage Windows Hello for Business multi-factor authentication (MFA). Make sure to configure an account lockout policy for mobile users with a fine-grained password policy. Finally, monitor force brute force or password spray attacks.

Testing and visualizing SMB over QUIC traffic

First of all, make sure you have logged on to the client with a domain user account before taking it out of the corporate network. You will need the cached credentials. Otherwise, you will need to use a local account and provide your domain credentials to access a file share.

To test whether SMB over QUIC works internally, we blocked TCP/445 on the Windows firewall on the file server. That way, we can show that SMB over QUIC works or not. If we leave TCP/455 open internally, TCP wins over QUIC as TCP gets a small head start. See SMB over QUIC process from the client-side in Part I (step 4 & 5).

Inside the corporate network, the SMB over QUIC client has a line of sight with an Active Directory domain controller.

Note the server’s name that we also added to the SAN list of our SmbOverQuic certificate. As long as the name (hostname or FQDN) is in the SAN list, you can use it.

Remember, we also added the “quicedge.datawisetech.corp” FQDN to the cert for access from outside the perimeter? That works natively via NTLMv2. It does mean that when you navigate to a UNC path, you will need to enter credentials.

You can mitigate this with saved credentials with share mappings, but there is a better way, the KDC Proxy Service.

Thanks to the KDC Proxy, we do not have to live with NTLMv2 authentication outside the corporate network. The KDC proxy forwards the ticket requests to the user. HTTPS ensures all communications are encrypted.

How do you know your KDC Proxy works? Well, on the KDC proxy server, you can enable logging for the Kerberos-KDCProxy\Operational log. I also enabled “Show Analytic and Debug Logs.”

When using NTLM, you will not see any Kerberos tickets, and the Kerberos-KDCProxy\Operational log will remain empty if you have not configured it.

Next to that, you will also see your Kerberos tickets when you run klist get krbtgt. When testing, you can use klist purge to

Remember, you can also use PowerShell and NET USE to map share and force QUIC.

NET USE * \\quicedge.datawisetech.com\BusinessPlans

This command automatically tries TCP, then QUIC. TCP will not work when we block TCP/445 on the server.

This command only tries QUIC.

This PowerShell command also only tries QUIC.

Bonus Time

When you have gotten the KDC Proxy to work, I will present you, free of charge, with a bonus capability that comes with it. You might already know if you looked at the KDC Proxy server image (figure 6) in detail.

That’s right! Your telecommuters/road warriors can use it to change their password securely over the internet. All this without a line of sight to a domain controller.

Conclusion

Previously, in part I of this article, we went over the theory and how SMB over QUIC works and started to prepare the lab. In Part II, which you just read, we dove into setting up and configuring SMB over QUIC for testing. We then showed you how to get it working by provisioning a certificate, configuring SMB over QUIC with Windows Admin Center and PowerShell.

Especially note the ease of use of this solution for knowledge workers when leveraging the KDC proxy! They log on to the client, and from there, things are transparent for them.

In essence, the preparation work takes more time than configuring SMB over QUIC. Having a permanent lab at the ready pays of and made sure I had all I needed in place to start testing.

Maybe this article triggered your interest. In that case, I hope it helps you get started with your testing.

I am not done with QUIC yet. Next, I will take a look at QUIC with Internet Information Server