SMB over QUIC - how to network?

Question

SMB over QUIC in Windows Server 2022 Datacenter: Azure Edition looks interesting.

The description at...

https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic

...is a good starting point. But no more!

I can't find any detail about how networking would be handled!

I get that you would use split DNS, so the server name resolves differently internally and on the Internet.

Would you attach an interface with the server's public IPv4 address, and another interface with the server's internal IPv4 address?

Would you simply NAT on your Internet router?

Neither feels "right" in contemporary networking; typically, we use pre-authentication from the Internet (eg using Azure Application Proxy). SMB was never designed for pre-authentication, or "modern authentication".

So I'm unsure how it's meant to work.

It used to be that publishing an SMB file server to the Internet (445/TCP) was simply wrong. This seems like publishing a SMB file server to the Internet over 443/UDP with no pre-authentication. Doesn't seem all that different to me.

Ned Pyle described it as file sharing without VPN (https://techcommunity.microsoft.com/t5/itops-talk-blog/smb-over-quic-files-without-the-vpn/ba-p/1183449).

But this looks like you would put a file server in Azure, enable SMB over QUIC, then configure Azure network to permit access only from your on premises network. That works fine, of course, that doesn't accommodate mobile users.

Eliminating the VPN for mobile users scenario;

• people using their Windows 11 laptop on the organisational network accessing SMB directly to the internal IPv4 address
• take their device home and continuing their work, but the device seamlessly connects over QUIC instead

is the key use case.

Answer 1

Is the countermeasure to this...

• configure KDC proxy
• require client authentication [using a client certificate] to the KDC proxy
• disable NTLMv2 authentication on the file server (SHARE01.CONTOSO.COM) in my example

Now,

• SHARE01.CONTOSO.COM is on the Internet, but will ask SMB clients to come back with a Kerberos service token
• KDC proxy (let's call it KDCPROXY.CONTOSO.COM) is Internet-facing, but will only process requests where the client can authenticate itself with client certificate

That seems much better. There is at least a form of pre-authentication using KDC proxy. But I've not seen any write-ups of this.

Answer 2

Regarding a complete Test Implementation including KDC Proxy see:
https://www.starwindsoftware.com/blog/smb-over-quic-testing-guide-part-i
https://www.starwindsoftware.com/blog/smb-over-quic-testing-guide-part-2

Answer 3

Is Azure AD Kerberos part of a production-ready design?

1. Setup SMB over QUIC in Windows Server 2022 Datacenter: Azure Edition [on Azure Stack]; publish to the Internet using NAT, etc
2. Configure Windows Server 2022 Datacenter: Azure Edition to disable NTLMv2 authentication, so users must authenticate with Kerberos.
3. Authenticate/authorise against Azure AD Kerberos with Azure AD PRT?
4. Authenticate to share01.contoso.com using Kerberos

[happy to admit I might be putting 2 and 2 together to make a bajillion!]

But this would eliminate the need to put up KDC Proxy and CRL.
Could it also mean...

• the share can be protected with MFA purely in Azure AD
• the share is of course encrypted in transit [because it's over QUIC, which mandates TLS]

EDIT: probably not; Azure Active Directory Kerberos is for the kerberos.microsoftonline.com realm.

But this seems related;

How SSO to on-premises resources works on Azure AD joined devices
https://learn.microsoft.com/en-gb/azure/active-directory/devices/azuread-join-sso

During an access attempt to a resource requesting Kerberos or NTLM in the user's on-premises environment, the device:

Sends the on-premises domain information and user credentials to the located DC to get the user authenticated.

Well, is a KDC proxy good enough?

I still haven't worked out how client certificates fit in to this (maybe https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-certificate-based-authentication ?), but it seems like if I have...

• KDC proxy
• web servers [on the Internet] that permit Kerberos only (not basic)

...then I get SSO over the Internet. It would work conceptually similar to SAML (I get sent to my KDC proxy instead of IdP; I get service token instead of a SAML response; etc).

Answer 4

With SMB over QUIC now included in Server 2025, it seems even more important that these questions are answered. I do think the KDC proxy is the answer here, but I'm curious if this will work for Entra Joined clients as well? Can they use an on-premise domain KDC proxy just like a domain joined client would?