Storage at Microsoft articles

SMB security hardening in Windows Server 2025 & Windows 11

NedPyle — Fri, 23 Aug 2024 16:19:30 GMT

Heya folks, Ned here again. Last November, Microsoft launched the Secure Future Initiative (SFI) to prepare for the increasing scale and high stakes of cyberattacks. SFI brings together every part of Microsoft to advance cybersecurity protection across our company and products.

Windows has focused on security options with each major release, and Windows 11 24H2 and Windows Server 2025 are no exception: they include a dozen new SMB features that make your data, your users, and your organization safer – and most are on by default. Today I’ll explain their usefulness, share some demos, and point to further details.

The new OSes will soon be generally available and you can preview them right now: download Windows Server 2025 and Windows 11 24H2.

On to the security.

SMB signing required by default

What it is

We now require signing by default for all Windows 11 24H2 SMB outbound and inbound connections and for all outbound connections in Windows Server 2025. This changes legacy behavior, where we required SMB signing by default only when connecting to shares named SYSVOL and NETLOGON and where Active Directory domain controllers required SMB signing for their clients.

How it helps you

SMB signing has been available for decades and prevents data tampering and relay attacks that steal credentials. By requiring signing by default, we ensure that an admin or user must opt out of this safer configuration, instead of requiring them to be very knowledgeable about SMB network protocol security and turn signing on.

Learn more

SMB NTLM blocking

What it is

The SMB client now supports blocking NTLM authentication for remote outbound connections. This changes the legacy behavior of always using negotiated authentication that could downgrade from Kerberos to NTLM.

How it helps you

Blocking NTLM authentication prevents tricking clients into sending NTLM requests to malicious servers, which counteracts brute force, cracking, relay, and pass-the-hash attacks. NTLM blocking is also required for forcing an organization's authentication to Kerberos, which is more secure because it verifies identities with its ticket system and better cryptography. Admins can specify exceptions to allow NTLM authentication over SMB to certain servers.

Learn more

SMB authentication rate limiter

What it is

The SMB server service now throttles failed authentication attempts by default. This applies to SMB sharing files on both Windows Server and Windows.

How it helps you

Brute force authentication attacks bombard the SMB server with multiple username and password-guesses and the frequency can range from dozens to thousands of attempts per second. The SMB authentication rate limiter is enabled by default with a 2 second delay between each failed NTLM or Local KDC Kerberos-based authentication attempt. An attack that sends 300 guesses per second for 5 minutes, for example - 90,000 attempts - would now take 50 hours to complete. An attacker is far more likely to simply give up than keep trying this method.

Learn more

SMB insecure guest auth now off by default in Windows Pro editions

What it is

Windows 11 Pro no longer allows SMB client guest connections or guest fallback to an SMB server by default. This makes Windows 11 Pro operate like Windows 10 and Windows 11 Enterprise, Education, and Pro for Workstation editions have for years.

How it helps you

Guest logons don't require passwords & don't support standard security features like signing and encryption. Allowing a client to use guest logons makes the user vulnerable to attacker-in-the-middle scenarios or malicious server scenarios - for instance, a phishing attack that tricks a user into opening a file on a remote share or a spoofed server that makes a client think it's legitimate. The attacker doesn't need to know the user's credentials and a bad password is ignored. Only third-party remote devices might require guest access by default. Microsoft-provided operating systems haven't enabled guest in server scenarios since Windows 2000.

Learn more

SMB dialect management

What it is

You can now mandate the SMB 2 and 3 protocol versions used.

How it helps you

Previously, the SMB server and client only supported automatically negotiating the highest matched dialect from SMB 2.0.2 to 3.1.1. This means you can intentionally block older protocol versions or devices from connecting. For example, you can specify connections to only use SMB 3.1.1, the most secure dialect of the protocol. The minimum and maximum can be set independently on both the SMB client and server, and you can set just a minimum if desired.

Learn more

SMB client encryption mandate now supported

What it is

The SMB client now supports requiring encryption of all outbound SMB connections.

How it helps you

Encryption of all outbound SMB client connections enforces the highest level of network security and brings management parity to SMB signing. When enabled, the SMB client won't connect to an SMB server that doesn't support SMB 3.0 or later, or that doesn't support SMB encryption. For example, a third-party SMB server might support SMB 3.0 but not SMB encryption. Unlike SMB signing, encryption is not required by default.

Learn more

Remote Mailslots deprecated and disabled by default

What it is

Remote Mailslots are deprecated and disabled by default for SMB and for DC locator protocol usage with Active Directory.

How it helps you

The Remote Mailslot protocol is an obsolete, simple, unreliable, IPC method first introduced in MS DOS. It is completely unsafe and has no authentication or authorization mechanisms.

Learn more

SMB over QUIC in Windows Server all editions

What it is

SMB over QUIC is now included in all Windows Server 2025 editions (Datacenter, Standard, Azure Edition), not just on Azure Edition like it was in Windows Server 2022.

How it helps you

SMB over QUIC is an alternative to the legacy TCP protocol and is designed for use on untrusted networks like the Internet. It uses TLS 1.3 and certificates to ensure that all SMB traffic is encrypted and usable through edge firewalls for mobile and remote users without the need for a VPN. The user experience does not change at all.

Learn more

SMB over QUIC client access control

What it is

SMB over QUIC client access control lets you restrict which clients can access SMB over QUIC servers. The legacy behavior allowed connection attempts from any client that trusts the QUIC server’s certificate issuance chain.

How it helps you

Client access control creates allow and block lists for devices to connect to the file server. A client would now need its own certificate and be on an allow list to complete the QUIC connection before any SMB connection occurs. Client access control gives organizations more protection without changing the authentication used when making the SMB connection and the user experience does not change. You can also completely disable the SMB over QUIC client or only allow connection to specific servers.

Learn more

SMB alternative ports

What it is

You can use the SMB client to connect to alternative TCP, QUIC, and RDMA ports than their IANA/IETF defaults of 445, 5445, and 443.

How it helps you

With Windows Server, this allows you to host an SMB over QUIC connection on an allowed firewall port other than 443. You can only connect to alternative ports if the SMB server is configured to support listening on that port. You can also configure your deployment to block configuring alternative ports or specify that ports can only connect to certain servers.

Learn more

SMB Firewall default port changes

What it is

The built-in firewall rules don’t contain the SMB NetBIOS ports anymore.

How it helps you

The NetBIOS ports were only necessary for SMB1 usage, and that protocol is deprecated and removed by default. This change brings SMB firewall rules more in line with the standard behavior for the Windows Server File Server role. Administrators can reconfigure the rules to restore the legacy ports.

Learn more

SMB auditing improvements

What it is

SMB now supports auditing use of SMB over QUIC, missing third party support for encryption, and missing third party support for signing. These all operate at the SMB server and SMB client level.

How it helps you

It is much easier for you to determine if Windows and Windows Server devices are making SMB over QUIC connections. It is also much easier to determine if third parties support signing and encryption before mandating their usage.

Learn more

Windows Insider build 26090 brings small changes for SMB - Microsoft Community Hub

Summary

With the release of Windows Server 2025 and Windows 11 24H2, we have made the most changes to SMB security since the introduction of SMB 2 in Windows Vista. Deploying these operating systems fundamentally alters your security posture and reduces risk to this ubiquitous remote file and data fabric protocol used by organizations worldwide.

For more information on changes in Windows Server 2025, visit Windows Server Summit 2024 - March 26-28, 2024 | Microsoft Event. You will find dozens of presentations and demos on the latest features arriving this fall in our latest operating system.

And remember, you can try all of this right now: preview Windows Server 2025 and Windows 11 24H2.

Until next time,

- Ned Pyle

Windows Server 2025 Storage Performance with Diskspd

DanCuomo — Fri, 14 Jun 2024 20:59:34 GMT

Windows Server 2025 is the most secure and performant release yet! Download the evaluation now!

Looking to migrate from VMware to Windows Server 2025? Contact your Microsoft account team!

Windows Server 2025 Storage Performance with Diskspd

Hi Folks - Dan Cuomo here to talk about some improvements in Diskspd storage measurement and the improvements you'll see in Windows Server 2025 storage performance.

If you manage on-premises servers, you know one of the final tests you run before going to production is a performance test. You want to ensure that when you migrate virtual machines to that host, or you install SQL server on that machine, that you’re going to get the expected IOPS, the expected latency, or whatever other metrics you deem important for your business’ workloads.

So, after all the group policies have been applied, firewall rules are set, agents are installed and configured (or anything else you do in your deployment playbook), you download Diskspd, NTTTCP, and other performance testing tools you use to test this server compared to your baseline (if you don’t do this, you should be!).

Having this performance baseline allows you to answer questions like, “Is this cluster ready for production” or “Is my VM performing as expected on this hardware?” Without a solid performance baseline, you simply cannot answer these questions with confidence. In Azure, we operate some of the most performance demanding workloads in the world, so it is equally important for Microsoft to understand the storage performance of our servers. To do this, teams across Microsoft use Diskspd, our in-house developed and publicly available storage measurement tool. We continually improve Diskspd’s measurement capability so both you and our internal Microsoft teams can be confident and informed as you’re running your Windows Server workloads.

In this article, we’ll discuss two significant improvements (known as Batched Completions and Look-a-sides) in Diskspd measurement and what you need to know as a result. But before we begin, let’s put your mind at ease. Nothing is getting worse!

To that end, you may be wondering about the genesis of these improvements. Diskspd is being updated to handle modern workloads and hardware like NVMe. Our storage stack in Windows Server 2025 was also updated to leverage advances in NVMe storage (you can hear more about the storage performance improvements in Windows Server 2025 here and here)! During our testing of these capabilities, we improved our methods of latency measurement and found that we were now hitting the disk device limits when using Windows Server 2025!

The changes outlined in this article are available in Diskspd 2.2 and later. Download now!

New: Batched Completions

First, some background. When Diskspd starts, you specify the -o parameter which indicates the number of outstanding I/O requests to keep “in-flight.” If you specify -o 1 for example, Diskspd would issue one I/O, wait for its completion, then reissue another I/O. The higher the number of outstanding I/O’s, the more taxing in terms of performance requirements on the physical hardware.

Let’s use an analogy to understand how Diskspd measurement accuracy is improved with batched completions.

It’s that time of the day again – time to check the mailbox. You walk to the mailbox and find that there are 16 letters ready for you to pick up before you return to your home. Unless you’re counting steps for fitness-tracking, you’ll grab all the mail in the mailbox at one time before returning. How inefficient would it be to retrieve only one piece of mail from the mailbox, return to your home, read it, then go and get the next piece of mail from the mailbox again?! But that’s how Diskspd historically worked without batched completions.

Previously Diskspd would issue the requested number of I/Os (T0), then receive and record one I/O at a time (T1), then reissue that I/O (T2) before receiving and recording the other completed I/O (T3) even though it completed at the same time. This is the equivalent of taking one letter out of the mailbox, walking back to the house, reading and writing a response to the letter, then walking back to the mailbox, and picking up the next letter <repeat until all letters (I/Os) are read from the mailbox>. Historically, this wasn't a big problem because disks simply weren't fast enough for this issue to be observed anyway.

The processing of completed I/Os one at a time caused Diskspd to report higher storage latency than you could actually achieve on your system. Simply put, as disks have become faster, Diskspd needed a new way to track, record, and reissue completed I/Os.

Diskspd with Batched Completions

Now, with batched completions, Diskspd will receive all completed I/Os (letters in the mailbox) and record them as soon as they complete (T1). This reflects the actual time that I/Os completed and prevents Diskspd from inflating the storage latency.

To continue the mailbox example, now we walk to the mailbox once, pick up all the mail and return back inside the house. We still respond to the mail (reissue I/Os) one at a time.

New: Look-a-sides

Now let’s imagine you’re moving into a new home and have several new household items being delivered to the house. To simplify your move-in-day, you order some pizza for dinner as well.

The doorbell rings so you open your door and see the delivery truck with household items and the pizza delivery in front of your house. You take the box with all the household items, ignoring the pizza which is now sitting on your front porch getting cold, and begin to unbox everything in it. Once the box has been unpacked, you reopen your front door and pick up the pizza. For those of you that really enjoy cold pizza, this analogy might not seem like a big problem!

Diskspd recently implemented functionality called “look-a-sides” intended to address a scenario similar to the analogy above.

To understand the challenge, imagine there are 16 I/Os issued (T0) and 2 of those I/Os complete shortly after. Next, Diskspd receives I/O 1 and 2 (T1 using batched completions). While Diskspd is receiving the first set of completed I/Os, more I/Os (3 and 4) complete.

But Diskspd doesn’t record I/Os 3 and 4 as having completed yet. Instead, it continues its goal of reissuing I/Os 1 and 2. This delay in receiving and recording completed I/Os inflates the latency time measured by Diskspd unnecessarily. The more I/Os kept in-flight (the larger value for -o parameter) the more prominent this issue will become.

Diskspd with Look-a-sides

Now, with look-a-sides, Diskspd will receive I/Os 1 and 2 (T1) and begin to reissue IO 1 (T2). At the earliest possible opportunity, Diskspd will look at the completion queue to see if there are more I/Os that it can receive, and record as completed (T3).

Note: If there are no I/Os to receive, Diskspd simply moves on. In either event Diskspd continues reissuing any I/Os it has received (T4).

Recommendation #1: Re-baseline your storage performance

Since these changes can be so dramatic, you should re-baseline your storage performance using the latest version of Diskspd. Here are comparisons we ran using some representative hardware.

The numbers reinforce two things. First, the latency reduction is fairly dramatic regardless of the drive you use. The example on the right includes enterprise grade hardware. Next, you can see that the more IO’s Diskspd is told to keep in flight (Queue Depth) the more dramatic the measurement improvement.

Recommendation #2: Test IOPS and Latency Separately

There is a chance that when Diskspd performs a look-a-side it will find no additional competed I/Os. This is sort of a "Schrödinger's cat" situation because Diskspd cannot know there are no I/O’s waiting without looking in the completion queue (look-a-side) which uses a small amount of CPU resources.

Each time Diskspd performs a latency test the extra CPU used to perform the look-a-side effects the overall amount of I/O that can be pushed and lowers the reported amount of IOPS on the system. In a simple test using single thread, random 4K reads on a consumer disk, we found that IOPS reduced nearly 6% (59.5K IOPS to 56.1K IOPS) when testing latency with look-a-sides.

So, you might be asking yourself, “can I turn look-a-sides off if I just want to test IOPS?” The good news is that look-a-sides are only enabled once you specify the latency parameter (-L) with Diskspd. Therefore we recommend you perform two separate performance tests: one for IOPS (without -L) and one for latency (with -L). When using -L, your IOPS measurements will be a bit lower than the maximum achievable on the system.

Here are some example Diskspd commands for Latency and IOPS testing:

IOPS Testing
Diskspd.exe -t8 -o8 -b4k -r -w0 -Suw

Note: This is only an example. You may need to try various values for -o to find the maximum.

Latency Testing
Diskspd.exe -t1 -o1 -b4k -r -w0 -Suw -L

Note: With the fixes here, you could also try small increases like -o2 or -o4

Summary

To keep pace with the advances in disk speeds and the improvements in Windows Server 2025, we’ve made investments in our storage performance benchmark tool to get you an accurate measure of latency. These improvements were so drastic that we recommend that you run separate performance tests for latency and IOPS and re-baseline the server performance in your environment. Remember to download the latest version of Diskspd along with Windows Server 2025 evaluation.

As always, we’d love to hear your feedback below as we continue to improve these tools.

Dan "Latency Reducer" Cuomo

Accessing a third-party NAS with SMB in Windows 11 24H2 may fail

NedPyle — Fri, 14 Jun 2024 16:26:34 GMT

Heya folks, Ned here again. With the publication of Windows 11 24H2 Release Preview, customers are trying out the new OS prior to general availability. If you were in the Windows Insider Canary or Dev release program for the past few years, nothing I'm about to share is new. But if you weren't and you're now having issues mapping a drive to your third-party network attached storage (NAS) devices using SMB, this article is for you.

What changed

In Windows 11 24H2, we've made two major security changes that can affect mapping drives to third-party consumer NAS or routers with USB storage:

By default, SMB signing is required on all connections. This increases your security by preventing tampering on the network and stops relay attacks that send your credentials to malicious servers.
Guest fallback is disabled on Windows 11 Pro edition. This increases your security when connecting to untrustworthy devices. Guest allows you to connect to an SMB server with no username or password. While convenient for the maker of your NAS, it means that your device can be tricked into connecting to a malicious server without prompting for credentials, then given ransomware or having your data stolen.

SMB signing has been available in Windows for 30 years but, for the first time, is now required by default on all connections. Guest has been disabled in Windows for 25 years and SMB guest fallback disabled since Windows 10 in Enterprise, Education, and Pro for Workstation editions. Both changes will make billions of devices - not just Windows, but everything running SMB that wants to talk to Windows - more secure. They've been in Windows Insider Dev and Canary builds for a year.

What happens with a third-party NAS

There's one unavoidable consequence, though: we don't know when someone intended to be unsafe.

We don't know the difference between a NAS that doesn't have SMB signing enabled and an evil server that doesn't want SMB signing enabled.
We also don't know the difference between a consumer NAS - where the manufacturer used guest access to simplify connecting to their storage at the expense of security - and an evil server that wants you to connect without any security prompts in order to steal all of your files and or deliver malware. Furthermore, SMB signing cannot be used with guest credentials. So even if you have guest fallback enabled, SMB signing will prevent it from working.

If you have installed Windows 11 24H2 Release Preview and see one of these errors trying to connect to your third-party device afterwards that was working fine previously, you're in the right place.

If signing isn't supported by your third-party device, you may get error:

0xc000a000
-1073700864
STATUS_INVALID_SIGNATURE
The cryptographic signature is invalid

If guest access is required by your third party, you may get error:

You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network
0x80070035
0x800704f8
The network path was not found
System error 3227320323 has occurred

How to solve the issues

To solve these issues, we recommend you do the following in this order. It's ordered from the safest to the least safe approach, and our goal is for your data to be protected, not to help third parties sell you unsafe products.

Enable SMB signing in your third-party NAS. Your vendor will have steps to do this online if it's possible in the device's management software.
Disable guest access in your third-party NAS. Your vendor will have steps to do this online if it's possible in the device's management software.
Enable a username and password in your third-party NAS. Your vendor will have steps to do this online if it's possible in the device's management software.
Upgrade your NAS if you cannot enable signing, cannot disable guest, or cannot use a username and password. The NAS will usually have an upgrade option in its management software, possibly labeled as "firmware update."
Replace your NAS if you cannot upgrade your NAS software to support signing and credentials (you will need to use steps 6 and later to copy your data off of it to your new NAS first)

Now we're into the less recommended steps, as they will make your Windows device and your data much less safe. They will, however, let you access this unsafe NAS.

6. Disable the SMB client signing requirement:

a. On the Start Menu search, type gpedit and start the Edit Group Policy app (i.e. Local Group Policy Editor). If you are using Home edition, skip to step 8.

b. In the console tree, select Computer Configuration > Windows Settings > Security Settings> Local Policies > Security Options.

c. Double-click Microsoft network client: Digitally sign communications (always).

d. Select Disabled > OK.

7. Disable the guest fallback protection:

a. On the Start Menu search, type gpedit and start the Edit Group Policy app (i.e. Local Group Policy Editor). If you are using Home edition, skip to step e.

b. In the console tree, select Computer Configuration > Administrative Templates> Network > Lanman Workstation.

c. Double-click Enable insecure guest logons

d. Select Enabled > OK.

8. If you're running Windows 11 Home edition, the guest fallback option is still enabled by default, so you're probably not reading this blog post. But if for some reason it is on, or you need to turn off SMB signing due to some third-party NAS, you will need to use PowerShell to configure your machine because there is no gpedit tool by default. To do this:

a. On the Start Menu search, type powershell then under the Windows PowerShell app, click Run as administrator. Accept the elevation prompt.

b. To disable SMB signing requirement, type:

Set-SmbClientConfiguration -RequireSecuritySignature $false

d. Hit enter, then hit Y to accept.

c. To disable guest fallback, type:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true

e. Hit enter, then hit Y to accept.

At this point you will be working if Signing or Guest were your real problems.

Important: we have not removed your ability to enable SMB1. All editions of Windows 11 have SMB1 disabled by default - this has been the case for over a year now and, in some editions, going back to Windows 10 - but you are free to re-enable it if you have a third-party NAS that only supports SMB1. SMB1 supports signing but your NAS may not, so the steps above for disabling signing can still apply. SMB1 always allows guest fallback and it cannot be stopped, so the guest steps are not applicable. If your third-party NAS still requires SMB1, it's likely listed here https://aka.ms/stillneedssmb1. If you find that it also doesn't support SMB signing, please let us know with the email address below.

Learning more & helping the community

If you have a third-party NAS device that doesn't support SMB signing, we want to hear about it. Please email wontsignsmb@microsoft.com with the make and model of your NAS device so we can share with the world and perhaps get the vendor to fix it with an update.

For more details on these technologies, what they do, and what the future holds, review blog posts:

For the official MS Learn docs, review:

Until next time,

Ned Pyle

Completing DFSR SYSVOL migration of domains that use Entra ID passwordless SSO

NedPyle — Mon, 13 May 2024 21:18:19 GMT

Heya folks, Ned here again. A customer recently reached out to me in the comments section of the well-worn Streamlined Migration of FRS to DFSR SYSVOL article, asking about a problem he was seeing with a single DC that wouldn't complete the process. Today I'll explain how to fix the issue introduced by a very modern authentication add-on.

Background

Decades after Windows 2000 first shipped and introduced the world to Domain Controllers, the File Replication Service, and SYSVOL, Azure released the Entra ID Passwordless security key sign-in to on-premises resources. With it, Entra ID can issue Kerberos ticket-granting tickets for your Active Directory domain. Users can sign in to Windows with modern credentials, such as FIDO2 security keys, and then access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises DCs.

Under the covers, this works by an admin provisioning an Entra DC. A pseudo-Domain Controller, as it were, named "AzureADKerberos". It's not a real physical or virtual DC, but simply a computer object in AD pretending to be a DC so that Entra ID works in this scenario.

The Issue

So, with that in mind, you're following the DFSR migration steps and notice that one domain controller named "AzureADKerberos" is not migrating, but instead always stays in the Started state:

dfsrmig.exe /getmigrationstate

The following domain controllers have not reached Global state ('Eliminated'):

Domain Controller (Local Migration State) - DC Type
===================================================

AzureADKerberos ('Start') - Writable DC

Migration has not yet reached a consistent state on all domain controllers.
State information might be stale due to Active Directory Domain Services latency.

Since this isn't a real domain controller, it's not participating in FRS or DFSR SYSVOL replication. It doesn't even have the AD leaf object and links to do so! But DFSRMIG doesn't know this, it just sees a DC and therefore thinks it must be migrated.

Fixing the issue

OK, so how do we fix this pseudo-domain controller blocking the migration? It's pretty straightforward once you understand how migration state works under the covers. For that, take a look at Verifying the State of SYSVOL Migration and the equally well-worn AskDS blog post DFSR SYSVOL Migration FAQ: Useful trivia that may save your follicles.

Anyway, let's do this:

1. Logon to one of your DCs as a domain admin.

2. Run ADSIEDIT.MSC, right click ADSI Edit and connect to the 'Default Naming Context'.
3. Navigate to the Domain Controllers OU.
4 Right click the "AzureADKerberos" computer object and click New > Object.
5. In 'Select a class', choose msDFSR-LocalSettings and click Next.
6. In 'Value', type DFSR-LocalSettings and click Next.
7. Click Finish.
8. Right-click the new 'DFSR-LocalSettings' leaf object and click Properties.
9. Scroll to 'msDFSR-Flags' and set it to a value of 48.
10. Click ok and ok, close ADSIEDIT.MSC.
11. Allow AD replication to complete.
12 Continue your migration until completed and verify all DCs are now in Global state eliminated by running:

dfsrmig.exe /getmigrationstate

All domain controllers have migrated successfully to the Global state ('Eliminated').
Migration has reached a consistent state on all domain controllers.
Succeeded.

Last thoughts

Technical debt is a real pita, but you already knew that! Just be glad that you're finally getting that old FRS system out and moving to DFSR for your SYSVOL.

That streamlined migration article has 702,000 views even after being migrated from the old TechNet blog platform. But the old dog still learns new tricks :).

Until next time,

Ned Pyle

Storage in Windows Server 2025, from the Server Summit

NedPyle — Thu, 28 Mar 2024 22:02:51 GMT

Heya folks, Ned here again. The three-day Windows Server Summit 2024 just completed and there are great on-demand sessions about Windows Server 2025 and Windows vNext. Some of the most interesting ones for this blog's audience are below, but the whole summit is worth a watch if you're an IT Pro, decision maker, consultant, architect, or C-level.

Next-generation SMB file services | Windows Server Summit 2024 (microsoft.com) – “Radical changes are coming to the Server Message Block (SMB) and file services in Windows Server 2025 and Windows 11. Learn about new security behaviors, new functionality, and new scenarios available to your organization.” Speaker: Ned Pyle

New storage features in Windows Server 2025 | Windows Server Summit 2024 (microsoft.com) - "Explore storage features in Windows Server 2025. We'll showcase exciting new capabilities in the ReFS file system, software-defined storage with Storage Spaces, innovation in Storage-spaces Direct (S2D), and new enhancements for Storage Area Networks (SANs) such as NVMe over Fabrics (NVMeoF). We will also show some of the incredible storage performance enhancements that make upgrading to Windows Server 2025 a must. Come for an overview of everything new, then dive into demos and a look "under the hood" of storage in Windows Server." Speaker: Dan Cuomo

Demo bytes: SSH for Azure Arc, Storage Replica | Windows Server Summit 2024 (microsoft.com) - "Storage Replica was first released in Windows Server 2016 and has come a long way. See how we've improved performance by enhancing logs and compression. Watch demos where we replace DFSR with this modern replication system that will replicate in-use files and protect your organization from disasters." Speaker: Ned Pyle

Windows Server 2025 ReFS booted images for confidential VMs | Windows Server Summit 2024 (microsoft.com) - "The Resilient File System (ReFS) is Microsoft's newest file system, designed to maximize data availability, scale efficiently to large data sets across diverse workloads, and provide integrity against data tampering. There is an initiative in the Windows Storage team to make ReFS the default filesystem for all Windows customers and the first step is to enable ReFS boot so that it can be leveraged by confidential VMs (CVMs). With Windows ReFS support for confidential VMs, we are introducing new features such as data integrity protection and rollback protection for the OS disk to further improve the security posture and protect your data end to end." Speakers: Simran Parkhe, Tina Wu, and Vikas Tikoo

The evolution of Windows authentication | Windows Server Summit 2024 (microsoft.com) – “As the security landscape evolves, Windows must continue to change to protect users and organizations. Foundational to this is user authentication. In Windows Server 2025 and Windows vNext, we have created completely new Kerberos features to minimize use of NTLM in your environments. This session explains and demonstrates IAKerb, Local KDC, IP SPN, and the roadmap to the end of NTLM.” Speaker: Ned Pyle

Hotpatching: Improving server security and productivity | Windows Server Summit 2024 (microsoft.com) – “When it comes to installing securing updates, organizations are often concerned about the potential for business disruption and reduced system availability. This is a thing of the past with Hotpatching! Come see how Hotpatching enables you to apply critical security updates without rebooting your servers, reducing downtime and improving productivity. Hear from the Xbox team, who have successfully adopted Hotpatching for the online gaming platform. Discover what is in store as we expand the service and make it more broadly available.” Speakers: Vishal Bajaj, Viraj Desai, Tim Dreyling

Windows Server 2025 OS security for IT and security pros | Windows Server Summit 2024 (microsoft.com) – “Advancements in security have been a core part of Windows Server 2025 development. Come for an overview of service account hardening, Secured-core, security baselines as a first-class product feature, authentication protocols, and more. Want a deeper dive on NTLM and Kerberos? See The evolution of Windows authentication.” Speakers: Dona Mukherjee, Matthew Reynolds

Windows Server 2025: The upgrade and update experience | Windows Server Summit 2024 (microsoft.com) - "Discover the streamlined upgrade process to Windows Server 2025 in our session. We will cover N-4 media-based upgrades, feature upgrades through Windows Update, and efficient management of feature and quality updates with Windows Server Update Services (WSUS). Gain insights into best practices and tools for a smooth transition, ensuring your infrastructure aligns seamlessly with the latest advancements. Don't miss this opportunity for valuable insights, practical tips, and a roadmap to upgrade your Windows Servers effectively." Speakers: Yutong Liao, Harpreet Kaur, Rob Hindman, Riddhi Ameser

What's new in Windows Server 2025 | Windows Server Summit 2024 (microsoft.com) - "Get a closer look at Windows Server 2025. Explore improvements, enhancements, and new capabilities. We'll walk you through the big picture and offer a guide to which Windows Server Summit sessions will help you learn more." Speaker: Elden Christensen

There are 30+ sessions at the Windows Server Summit - I learned all kinds of stuff myself! Dive in.

Until next time,

- Ned Pyle

Windows Insider build 26090 brings small changes for SMB

NedPyle — Wed, 10 Apr 2024 23:28:13 GMT

Heya folks, Ned here again. We continue to make SMB changes to Windows vNext and Windows Server 2025 based on customer feedback and last mile work. With the release of Windows 11 Insider Preview Build 26090 (Canary and Dev Channels), we have a few more small ones. Some of these were based on Insider feedback from customers - your opinions really do matter to us!

SMB over QUIC client disable: Administrators can now disable the SMB over QUIC client with Group Policy and PowerShell. To disable SMB over QUIC using PowerShell, run the following command in an elevated console:

Set-SmbClientConfiguration -EnableSMBQUIC $false

To disable SMB over QUIC using Group Policy, use GPMC.MSC or GPEDIT.MSC to configure the following setting:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Enable SMB over QUIC

This option already exists for the SMB over QUIC server in two ways: either you can actively disable it with group policy and PowerShell, or you can simply not configure SMB over QUIC with a certificate, which accomplishes the same thing and is the out of box experience, obviously.

SMB over QUIC client connection auditing: Successful SMB over QUIC client connection events are now written to the event log to include the QUIC transport. You can view these events using EVENTVWR.MSC under the following path:

Applications and Services Logs \ Microsoft \ Windows\ SMBClient \ Connectivity (Event ID: 30832)

SMB signing and encryption auditing: Administrators can now enable auditing of the SMB server and client for support of SMB signing and encryption. This shows if a third-party client or server doesn’t support SMB encryption or signing. If your third-party device or software claims to support SMB 3.1.1 but doesn't support SMB signing, you need to get your money back, as that breaks the strict pre-authentication integrity protocol requirement, and they are only using SMB 3.0.2 or older!

You can configure these settings with PowerShell and Group Policy.

To configure SMB client or server signing or encryption auditing using Group Policy, use GPMC.MSC or GPEDIT.MSC to configure the following settings:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Audit server does not support encryption
Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Audit server does not support signing
Computer Configuration \ Administrative Templates \ Network \ Lanman Server \ Audit client does not support encryption
Computer Configuration \ Administrative Templates \ Network \ Lanman Server \ Audit client does not support signing

To configure SMB client or server signing or encryption auditing using using PowerShell, run the following command in an elevated console:

Set-SmbClientConfiguration -AuditServerDoesNotSupportEncryption $true

Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

You can view these events using EVENTVWR.MSC under the following paths:

Applications and Services Logs \ Microsoft \ Windows\ SMBClient \ Audit (Event ID: 31998 and Event ID: 31999)
Applications and Services Logs \ Microsoft \ Windows\ SMBServer \ Audit (Event ID: 3021 and Event ID: 3022)

For more information on SMB over QUIC in Windows and Windows Server Insider Preview builds, review https://aka.ms/SMBoverQUICServer and https://aka.ms/SmbOverQuicCAC.

For more information on SMB signing and encryption in Windows and Windows Server Insider Preview builds, review https://aka.ms/SmbSigningRequired and https://aka.ms/SmbClientEncrypt.

The changes will keep coming, our work is never done. Keep checking back here for news and new things to try out in Windows and Windows Server Insider.

Until next time,

Ned Pyle

Windows Server Insider Preview 26040 is out - and so is the new name

NedPyle — Fri, 26 Jan 2024 19:24:44 GMT

Heya folks, Ned here again. We've resumed the Windows Server Insider program after our winter break and there's a new build, new features, and - finally - the official branding: Windows Server 2025.

New features in 26040

Windows Server Flighting: Windows Server Insider now support flighting and downloadable in-place upgrades, exactly like Windows 11; no need to grab ISOs and run manual setup. For more info, visit Welcome to Windows Insider flighting on Windows Server
SMB over QUIC alternative ports: Change from using the default UDP/443 port for SMB over QUIC to any port you define. For more info, visit SMB alternative ports now supported in Windows Insiders

Windows Server 2025 and Insider Previews

Release notes, feedback links: Announcing Windows Server Preview Build 26040
Download: Download Windows Server Insider Preview (microsoft.com)
Review the SMB changes in Windows Insiders and Windows Server Insiders:

Catch up on all the other new features and scenarios disclosed so far: Introducing Windows Server 2025!

Until next time,

- Ned Pyle

What's new in Windows Server vNext Ignite Session Now Available

NedPyle — Tue, 28 Nov 2023 17:42:59 GMT

Heya folks, Ned here again. The Microsoft Ignite 2023 session "What's new in Windows Server vNext" is now up if you weren't able to attend in person. It covers many of the new features coming to Windows Server including Active Directory, File Server, Hyper-V, storage, and more. Many announcements were made - Hotpatch and SMB over QUIC for Datacenter and Standard editions, for example - along with some big surprises and some great demos.

What’s New in Windows Server v.Next (microsoft.com)

You can stream it or download the video for offline viewing, and the slides are available too. It's a really fun & interesting session; Jeff Woolsey and Elden Christensen are great speakers, and it was standing room only.

Enjoy!

- Ned Pyle

SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions

NedPyle — Tue, 02 Jul 2024 17:50:04 GMT

Heya folks, Ned here again. Starting with Windows Server Insider Preview Build 25997, the SMB over QUIC server feature is now available in Datacenter and Standard editions. This changes the previous behavior where it was only available in Windows Server Azure Edition.

SMB over QUIC

SMB over QUIC introduced an alternative to TCP and RDMA, supplying secure connectivity to edge file servers over untrusted networks like the Internet. QUIC has significant advantages, the largest being mandatory certificate-based encryption instead of relying on passwords.

SMB over QUIC offers an "SMB VPN" for telecommuters, mobile device users, and on highest security internal networks. The server certificate creates a TLS 1.3-encrypted tunnel over a UDP port instead of the legacy TCP/445. No SMB traffic - including authentication and authorization - is exposed to the underlying network. SMB behaves normally within the QUIC tunnel, meaning the user experience doesn't change and capabilities like multichannel and compression continue to work.

A file server administrator must opt in to enabling SMB over QUIC, it isn't on by default and a client can't force a file server to enable SMB over QUIC. We recently added an additional option called Client Access Control that lets you further secure the file server through an allow-list for clients.

What changed

In Windows Server 2022, the SMB over QUIC server is limited to Azure Edition machines. Now in Windows Server Insider Preview servers, you can configure SMB over QUIC on all editions, including Datacenter and Standard. There are no additional requirements, it is now just available everywhere. Azure Edition is designed to be a cutting-edge platform for new features and organizations who want state-of-the-art-technology, but it is not a final destination for all of them. Windows 11, Windows Server 2022, Windows Insider clients, and third parties can connect to the server like usual.

Because Windows Admin Center still checks that you're on Azure Edition for now, you'll need to use PowerShell to configure the feature. Follow the configuration steps at https://aka.ms/smboverquic to get your certificate, but skip the WAC steps and use the New-SmbServerCertificateMapping command to setup the server for now:

New-SmbServerCertificateMapping -Name server FQDN -ThumbPrint certificate thumbprint -Storename My

You can also now specify the SMB over QUIC listening ports, as mentioned in the SMB alternative ports blog post recently. The default is UDP/443 but you can now change it using:

Set-SmbServerAlternativePort -TransportType QUIC -Port <a number between 0 and 65536> -EnableInstances Default

You can then connect to it using that port from a recent Windows 11 Insider client using NET USE /QUICPORT or New-SmbMapping -QuicPort:

Final Notes

As mentioned in the SMB alternative ports blog post recently, you will also be able to configure SMB over QUIC to listen on a UDP port other than the default 443. Look for this option in a coming Windows Server Insiders release.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

SMB alternative ports now supported in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:51:09 GMT

Heya folks, Ned here again. Starting with Windows 11 Insider preview Build 25992 (Canary) and Windows Server Preview Build 25997, the SMB client now supports connecting to an SMB server over TCP, QUIC, or RDMA using alternative network ports. Today I'll explain how to configure this and talk about the near future of this in Windows and Windows Server Insiders a bit.

Update April 3, 2024: official documentation now available at Configure alternative SMB ports for Windows Server (preview) | Microsoft Learn

Update: Windows Server Insider build 26040 now allows configuring alternative ports for SMB over QUIC. See below for details.

Previous port behaviors

SMB server in Windows has required inbound connections using the IANA-registered port TCP/445 for decades, and the SMB TCP client has only supported connecting outbound to that TCP port. The newer SMB over QUIC protocol requires the QUIC-mandated UDP/443, both for server and client. Until now these were hard-coded and unalterable.

Configuring alternative ports

You can now connect to alternative TCP, QUIC, and RDMA ports with the SMB client as long as the SMB server supports listening on that port and has been configured to do so. You can do this through mapped drive commands NET USE or New-SmbMapping now, and in a coming release, specify ports to connect to on specific servers using Group Policy or PowerShell or through DNS SRV records. An administrator can also block the use of SMB client alterative ports completely using Group Policy.

Map an alternative port with NET USE

To map an alternative TCP port using NET USE, use the following syntax:

NET USE \\server\share /TCPPORT:<some port between 0 and 65536>
NET USE \\server\share /QUICPORT:<some port between 0 and 65536>
NET USE \\server\share /RDMAPORT:<some port between 0 and 65536>

For example, to map the G: drive port to TCP/847, use:

NET USE G: \\waukeganfs1.contoso.com\share /TCPPORT:847

Map an alternative port with New-SmbMapping

To map an alternative TCP port using New-SmbMapping PowerShell, use the following syntax:

New-SmbMapping -RemotePath \\server\share -TcpPort <some port between 0 and 65536>
New-SmbMapping -RemotePath \\server\share -QuicPort <some port between 0 and 65536>
New-SmbMapping -RemotePath \\server\share -RdmaPort <some port between 0 and 65536>

For example, to map the G: drive port to TCP/847, use:

New-SmbMapping -LocalPath G -RemotePath \\waukeganfs1.contoso.com\share -TcpPort 847

Control use of SMB client alternative ports

To control SMB client alternative port usage, configure the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Enable Alternative Ports

Configuring SMB over QUIC alternative listening port

Windows Server Insider does not support changing the SMB server TCP listening port to something besides the default 445. However, you can configure the SMB over QUIC server to use an alternative port, via the following powershell cmdlets:

Get-SmbServerAlternativePort
New-SmbServerAlternativePort
Remove-SmbServerAlternativePort
Set-SmbServerAlternativePort

The configure the SMB over QUIC listener to use a port other than its default UDP/443, use the New-SMBServerAlternativePort cmdlet. For example, to configure the port to UDP/1775, run the following on the Windows Server Insider SMB over QUIC machine:

New-SmbServerAlternativePort -TransportType QUIC -port 1775 -EnableInstances Default

If you then run NETSTAT you'll see the server listening on that UDP port

NETSTAT -anob
...
 UDP 0.0.0.0:1775 *:* 2848
LanmanServer

Final notes

Windows Server does not support configuring alternative SMB server TCP ports, but third parties such as Samba do. For more information on configuring non-standard SMB server ports in third parties, consult their product documentation.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

SMB firewall rule changes in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:51:53 GMT

Heya folks, Ned here again. Starting with Windows 11 Insider preview Build 25992 (Canary) and Windows Server Preview Build 25997, creating SMB shares changes a longtime Windows Defender Firewall default behavior.

Update April 4, 2024: official documentation now available at Secure SMB Traffic in Windows Server | Microsoft Learn

Before

Previously, creating a share automatically configured the firewall to enable the rules in the “File and Printer Sharing” group for the given firewall profiles. This began in Windows XP SP2 with the introduction of the then-new built in firewall, and the rule was designed for both SMB1 and ease of deployment of a wide array of SMB-using technology, including printing, legacy group policy, and others.

Now

Windows now automatically configures the new “File and Printer Sharing (Restrictive)” group when you create an SMB share, which no longer contains inbound NetBIOS ports 137-139. Those ports are not used by SMB2 or later and are an artifact of SMB1. If you reinstall SMB1 server for some legacy compatibility reason, you will need to ensure that those firewall ports are reopened.

This change enforces a higher degree of default of network security as well as bringing SMB firewall rules closer to the Windows Server “File Server” role behavior, which only opens the minimum ports needed to connect and manage sharing. Administrators can still configure the “File and Printer Sharing” group if necessary as well as modify this new firewall group, these are just default behaviors.

Final Note

We plan future updates for this rule to also remove inbound ICMP, LLMNR, and Spooler Service ports and restrict down to the SMB sharing-necessary ports only.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

DR 2.0: Migrating from DFSR to Storage Replica

NedPyle — Tue, 07 Nov 2023 19:06:12 GMT

Heya folks, Ned here again. Today I’m sharing advice on migrating from Distributed File System Replication (DFSR) to Storage Replica. This includes deciding when SR is a good replacement, inventorying your DFSR and DFS Namespaces, backing up your existing configuration, validating your existing replication and converging it, migrating to SR, then updating your disaster recovery runbook.

Let’s get to re-replicating!

What is Storage Replica?

We introduced Storage Replica in Windows Server 2016. SR replicates volumes between servers, between clusters and within stretch clusters. We designed SR for disaster recovery – I prefer the term disaster prevention – scenarios where organizations need to protect critical data from floods, fires, superstorms, and war. It supports synchronous and asynchronous replication:

Synchronous replication mirrors data over short range, low latency networks with zero data loss during a disaster
Asynchronous replication mirrors data over long range, high latency networks with minimal data loss during a disaster

In the first release, SR supported bandwidth throttling, encryption, delegation, network constraint, and was available only on Datacenter edition. In Windows Server 2019 we offered an additional limited version for Standard edition servers and the ability to mount a destination volume for testing or backups. In Windows Server 2022 Azure Edition, we offered compression to improve performance for over congested or lower-throughput networks. In September 2021, we began previewing that greatly lowers synchronous replication latency and is the future of SR. For instance, using DISKSPD on our test hardware here, you can see the improvement in IO on the source device when writing a volume protected by SR with the new enhanced (“RAW”) log is far better than the legacy (“CLFS”) log:

IO size	CLFS (in MiB/s)	RAW (in MiB/s)
4K	35.25	56.53
8K	68.16	112.16
2MB	521.32	1450.57

When to replace DFSR with Storage Replica

Customers have deployed DFSR for 17 years. It shipped in Windows Server 2003 R2 and millions of organizations use it to replicate domain controller SYSVOL and file servers. DFSR scales to thousands of nodes across extremely poor networks for smaller datasets and has an excellent differential compression algorithm, but has significant limitations as a modern DR solution:

It doesn't replicate in-use files.
It doesn't replicate synchronously.
Its asynchronous replication latency can be many minutes, hours, or even days.
Its maximum size limits are low by modern standards
Its initial replication is much slower than just copying data manually, requiring additional steps like preseeding and database cloning for larger datasets
It relies on a database that can require lengthy consistency checks after interruption.
It's often configured for multi-writer replication, which allows changes to flow in many directions to many servers, leading to (perceived) data loss from user updates and latency.
It does not scale well on clusters.
It’s not supported with the modern ReFS file system.
While still supported, we no longer actively develop or improve DFSR.

Storage Replica is an excellent alternative under the right circumstances:

You need zero or minimal data loss during a disaster.
You have good throughput – lower latency, higher bandwidth - networks between locations.
You only need two copies of the data and don’t need users or applications writing to multiple copies at once.

Important: DFSR is still required for domain controller SYSVOL replication and you can't replace it with SR. It's ok, that replica is usually pretty small and self-managing. Usually.

That’s the “if”. Let’s get to the “how”.

1. Inventorying your environment

Before migrating to Storage Replica, inventory your organization for their current DFS Replication and DFS Namespace topologies and your file server versions. You need this to build your project and future DR plan. Locating domain-based DFSN is easy but standalone DFSN requires knowing your namespace hosts.

Inventory domain-based DFSN

Use DFSMGMT, PowerShell or DFSUTIL to inventory all your domain-based DFSN including roots, links (“folders”), and link targets (“folder targets”). If you end up adding new servers or using the switch to Storage Replica as an opportunity to replace servers, you can modify the DSFUTIL export’s XML files to become easy input files.

There’s a sample script from IT Pro BritV8 for listing all the domain-based DFSN folder targets in the domain out to the console:

Powershell – Get List Of All Folder Targets In Domain Namespace | BritV8

#Requires -modules DFSN
#Gets a list of all the folder targets in the Domain Namespace

#Example use

#$results Get-DfsnAllFolderTargets

#$results |select namespacepath,TargetPath,ReferralPriorityRank,ReferralPriorityClass,state |ogv

function Get-DfsnAllFolderTargets ()

{

#Get a list of all Namespaces in the Domain

Write-Progress -Activity "1/3 - Getting List of Domain NameSpaces"

$RootList = Get-DfsnRoot

#Get a list of all FolderPaths in the Namespaces

Write-Progress -Activity "2/3 - Getting List of Domain Folder Paths"

$FolderPaths = foreach ($item in $RootList)

{

Get-DfsnFolder -Path "$($item.path)\*"

}

#Get a list of all Folder Targets in the Folder Paths, in the Namespaces"

Write-Progress -Activity "2/3 - Getting List of Folder Targets"

$FolderTargets = foreach ($item in $FolderPaths)

{

Get-DfsnFolderTarget -Path $item.Path

}

return $FolderTargets

}

Get-DfsnAllFolderTargets

You can use Get-SmbShare -CimSession to dig deeper into the shared folders and their volume usage, or just look at the folders in File Explorer.

Reminder: Standalone DFSN doesn’t store any data in Active Directory, making inventory difficult. You’ll need to know which servers are hosting data in a standalone namespace and inventory them manually. Hopefully you’ve kept good records.

Inventory DFSR

The DFSR PowerShell module is the best way to inventory your replication groups and associated replicated folders. To get all DFSR member machines and their storage configuration in the domain, just run:

Get-DFSRMembership

You can format table the output for this inventory using:

Get-DfsrMembership | FT groupname,computername,contentpath,dfsnpath

Notice how you can’t rely on DfsnPath – that value is only set when you used DFSMGMT to create replication of an DFS Namespace. You can create replication groups without DFSN or even a shared folder, so be sure to reconcile that in your plans.

DFSMGMT is the graphical alternative:

Inventory OS Versions

If you are running Windows Server 2012 R2 and older or Windows Server 2016/2019/2022 Standard edition, you’ll also need to inventory the machines you collected from DFSN and DFSR above – remember that Storage Replica only became available in WS2016 and is limited on Standard Edition WS2019+. This migration to SR may be an OS upgrade, hardware replacement, or data migration story.

The easiest way is to use the Active Directory PowerShell module to query AD, either based on your list of identified servers or all of them:

Get-ADComputer -Filter 'OperatingSystem -Like "Windows *Server*"' -Property * | Format-Table Name,OperatingSystem -Wrap -Auto

Look for machines running Standard Edition or older OSes, they may need upgrade or replacement before you can get to Storage Replica.

2. Backup DFSN and DFSR

Before you migrate, ensure you backup your DFSR and domain-based DFSN configurations. A normal Active Directory System State backup contains all that info, and you’re getting those backups nightly, right?

Besides that, you can save the domain-based DNS targets into XML files using DFSUTIL inside PowerShell:

$formatString = ".\dfsn-{0:D2}.xml"

$i = 0

$root = get-dfsnroot | Get-DfsnRootTarget

foreach ($targetpath in $root)

{

$i = $i + 1

$fileName = $formatString -f $i

dfsutil.exe root export ($targetpath).targetpath $fileName verbose

}

These DFSR PowerShell commands will save the configuration for later review or recreation:

Get-DFSReplicationGroup > rgs.txt
Get-DFSReplicatedFolder > rfs.txt
Get-DFSRMember > members.txt
Get-DFSRMembership > memberships.txt
Get-DFSRConnection > conns.txt

3. Pick your Primaries, examine volume & log storage

Now you will determine who will be primary and evaluate your storage options.

Unlike DFSR, Storage Replica doesn’t have “multi-master” replication, there is always just one source and one destination. You need to pick which of your DFSR servers that you want to become primary – where all writes occur – and then existing or new servers to make secondary, where you will replicate data for safety. Your other DFSR servers get repurposed or discarded. You can replicate from a single server to many servers with SR, but only with many volumes on the source, each replicating to a different destination.
You will also need to ensure there is SR log space set aside. Storage Replica doesn’t use a database like DFSR, it uses several types of logs in a separate partition. Both the source and destination server will need at least one volume and by default, it must be at least 9GB (this is adjustable). You can use the Windows Server disk management tools like DISKMGMT.MSC, the PowerShell Storage Module to create this new volume by shrinking an existing one or you can add additional storage.
Finally, because SR perfectly mirrors the source volume to the destination server, ensure that the new SR destination has the same amount of disk space and exactly the same-sized volumes.

You can use the Test-SRTopology tool to ensure you have met all of these requirements.

4. Remove DFSR, adjust DFSN, add SMB

Having selected your first set of servers to migrate and having backed up all your DFSR and DFSN settings, you can now:

Remove all of the DFSR settings using DFSMGMT.MSC or Remove-DfsReplicationGroup from your first group of servers
Disable any DFSN folder targets that point to servers that will not be the source for Storage Replica.
If you plan to replicate to new servers, you will also need to create and configure your shared folders and shares on the destination volume (without any data) using Windows Admin Center, New-SmbShare, or NET SHARE, using the inventory you gathered in step 1. Once SR starts running, that volume will dismount and you will not be able to create the SMB shares anymore. They will reappear if you ever disable replication, mount the replicated volume with Mount-SRDestination, or switch replication direction – the SMB server service won’t forget them when the drive dismounts temporarily.

5. Deploy Storage Replica

Now that the infrastructure is ready, you can deploy Storage Replica.

Use Windows Admin Center for a graphical management experience or familiarize yourself with the Storage Replica Powershell.
Follow the steps in Server-to-server storage replication to configure your first replica partnership either as synchronous or asynchronous.

6. Evaluate health

Now that you’re using your first new Storage Replica set and updated DFSN and file server settings, validate that it’s working to your requirements:

Ensure user and application IO performance is acceptable by copying files, opening files remotely, etc.
Temporarily mount the destination volume with Mount-SRDestination and ensure access to an SMB share works.
Schedule a change control window and perform a disaster recovery test, switching replication direction to the secondary site and then back again to the primary site.

7. Repeat migration for all remaining servers

Having confirmed that your first migration to Storage Replica meets your requirements, migrate the remainder of your servers. Store all your inventory and configuration backups for at least 60 days to ensure you can roll back servers if necessary.

8. Write down your DR plan

Write down your configuration and how to fail it over in the event of a disaster.

Ensure you keep up with the inventory of these protected servers so that your team can execute your plan across the fleet.
Write it so that anyone can follow it! When a disaster strikes, you may not be there, and your plan should be understandable and complete enough that your most junior new hire can execute it without supervision.
You should test your runbook document at least once a year - using that most junior person.

Final notes

Azure File Sync is also a replacement for DFSR, especially since they are both file-based replication features, with the flexibility and file server-oriented workload that it provides. You can even use SR and AFS on the same server with the same replicated folders and volumes, where you want some data to tier to the cloud and some to directly replicate to other on-prem servers. Read more at Deploy Azure File Sync.

I want to give a huge shoutout to Gabriel Luiz, MVP, who encouraged the creation of this blog post and always does what’s right for his customers and the Windows Server IT community. Obrigado, Gabriel!

Until next time,

Ned Pyle

SMB client encryption mandate now supported in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:52:29 GMT

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25982 (Canary Channel) and Windows Server Preview Build 25997, SMB now supports requiring encryption of all outbound SMB client connections. With this new option, administrators can mandate that all destination servers support SMB 3.x and encryption, and if missing those capabilities, the client won’t connect. This enforces the highest level of network security as well as bringing management parity to SMB signing, which allows both client and server requirements.

Update April 3, 2024: official documentation now available at Configure the SMB client to require encryption in Windows (preview) | Microsoft Learn

SMB encryption

SMB Encryption supplies SMB data end-to-end protection from interception attacks and snooping. It first shipped in SMB 3.0 on Windows 8 and Windows Server 2012. Windows 10 and Windows Server 2019 added AES-GCM support for better hardware-accelerated encryption, then Windows 11 and Windows Server 2022 introduced AES-256-GCM cryptographic suites. Today you can configure SMB encryption on a per share basis, for the entire file server, when mapping drives, or when using UNC Hardening.

SMB client encryption mandate

You can now also configure the SMB client to always require encryption, no matter what the server, share, UNC hardening, or a mapped drive requires. This means an administrator can globally force a Windows machine to use SMB encryption – and therefore SMB 3.x – on all connections and refuse to connect if the SMB server does not support either.

Configuring SMB encryption mandate

You can configure this new option with both Group Policy and PowerShell.

Group Policy

To configure SMB client for required encryption to all SMB servers (i.e., for outbound connections), enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Require encryption

Setting the policy to disabled or not configured removes the encryption requirement.

Important: use care when deploying SMB encryption through group policy to a heterogenous fleet. Any legacy SMB servers such as Windows Server 2008 R2 won’t support SMB 3.0. Older third-party SMB servers might support SMB 3.0 but not encryption.

PowerShell

To configure the SMB client for required encryption to all SMB servers (i.e., for outbound connections), set the following PowerShell parameter:

Set-SmbClientConfiguration -RequireEncryption $true

To see the effective setting on a machine:

Get-SmbClientConfiguration | FL RequireEncryption

Final notes

SMB encryption has performance overhead and compatibility overhead, and you should balance that against SMB signing - which has better performance and tamper protection but no snooping protection – or against no use of encryption or signing at all, which has best performance but no security besides the connection authorization and pre-auth integrity protection. SMB encryption supersedes SMB signing and supplies the same level of tamper protection, meaning that if your SMC client requires signing, SMB encryption turns it off; there is no point requiring both because encryption wins.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

- Ned Pyle

New CISA Stop Ransomware Guide

NedPyle — Fri, 20 Oct 2023 17:23:19 GMT

Heya folks, Ned here again. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) just released their updated #StopRansomware Guide with a number of new contributions from Microsoft, including a substantial section on hardening SMB and remote file services.

See page 8 and 9 for the new SMB and remote file services recommendations. If you've been following my blogs and articles for the past few years, they should be familiar.

The guide is substantial but very readable and full of practical advice for IT shops of all sizes. In their own words:

"These ransomware and data extortion prevention and response best practices and recommendations are based on operational insight from CISA, MS-ISAC, the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI). This guide was developed through the U.S. Joint Ransomware Task Force (JRTF). The JRTF, co-chaired by CISA and FBI, is an interagency, collaborative effort to combat the growing threat of ransomware attacks.

The audience for this guide includes information technology (IT) professionals as well as others within an organization involved in developing cyber incident response policies and procedures or coordinating cyber incident response."

It was a genuine pleasure to work with the dedicated civil servants who created this guide. It also highlighted that we need to consolidate, expand, & modernize our SMB and file services documentation at learn.microsoft.com. I've started a substantial project with my technical writing team and will have more news on this in a few months.

Until next time,

Ned Pyle

SMB over QUIC client access control now supported in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:53:09 GMT

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25977 (Canary Channel) and Windows Server Preview Build 25997, SMB over QUIC now supports access control for clients. Today I’ll explain how this works, what the advantages are, and how to set it up.

SMB over QUIC

SMB over QUIC offers an "SMB VPN" for telecommuters, mobile device users, and high security organizations. The server certificate creates a TLS 1.3-encrypted tunnel over the internet-friendly UDP port 443* instead of the legacy TCP port 445. No SMB traffic - including authentication and authorization - is exposed to the underlying network. SMB behaves normally within the QUIC tunnel, meaning the user experience doesn't change and capabilities like multichannel and compression work.

A file server administrator must opt in to enabling SMB over QUIC, it isn't on by default and a client can't force a file server to enable SMB over QUIC. It’s available in Windows 11 and Windows Server 2022 as an SMB client and in Windows Server 2022 Azure Edition* as an SMB server.

* Update Nov 15, 2023. We just announced that SMB over QUIC is now part of Windows Server Datacenter and Standard editions for the next release of Windows Server and that you can now control the QUIC network port. You can try it out in Insiders Preview. For more info, review https://aka.ms/SMBoverQUICServer

SMB over QUIC Client Access Control

SMB over QUIC client access control (CAC) improves the existing SMB over QUIC feature. Previously, servers trusted all clients if they were issued the same certificate root chain as the server’s SMB over QUIC server certificate. With this new option, administrators can restrict which clients can access SMB over QUIC servers – an allowlist for devices trusted to connect to the file server. This gives organizations more protection but does not change the Windows authentication used to make the SMB connection nor does it alter the end user experience.

This feature works by a client trusting the SMB over QUIC server via a valid shared root authority key. An admin also gives the client a certificate from the same issuer, and that certificate’s hash (or issuer) is added to a trust list maintained by the server. When the client connects, it sends the certificate info to the server for comparison against the allow list, granting or denying access to QUIC. Then SMB authentication occurs inside the QUIC TLS tunnel, and the user connects to their share. An admin can also explicitly deny access or just revoke certificates. CAC is optional and – for now – not on by default.

Update November 8, 2023:

Starting with Build 25992, the SMB over QUIC client access control feature now supports using certificates with subject alternative names and not just a single subject. This means the client access control feature now supports using a Microsoft AD Certificate Authority and multiple endpoint names, just like the currently released version of SMB over QUIC. You can now evaluate the feature using the recommended options and not require self-signed test certificates.

Configuring SMB over QUIC client access control

The steps to configure SMB over QUIC CAC are nearly identical for the server-side. The steps for clients are quite different. This is the typical trade-off between security and ease of management.

Prerequisites

To evaluate CAC, you’ll need:

One Windows Server vNext Azure Edition Preview Build 25977 or later VM. You’re allowed to run Windows Server Azure Edition outside of Azure IaaS and Azure Stack HCI for evaluation and testing purposes.
One Windows 11 Insider Preview Build 25977 (Canary Channel) or later client.

Configure SMB over QUIC CAC

To configure SMB over QUIC CAC, we’re going to use a self-signed certificate and PowerShell.

These steps are strictly for Insider Preview evaluation purposes; the released CAC feature will fully support a Certificate Authority and Windows Admin Center, and you should never use a self-signed certificate with SMB over QUIC in a production environment.

Open an administrator-elevated PowerShell console on the SMB over QUIC server.
Create server self-signed certificate (where “Server DNS name” is the fully-qualified name of the SMB over QUIC server):

$serverCert = New-SelfSignedCertificate -DnsName Server DNS name -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(6) -KeyAlgorithm "RSA" -KeyLength "2048"

Configure the server certificate mapping requiring client authentication:

New-SmbServerCertificateMapping -Name Server DNS name -Thumbprint $serverCert.Thumbprint -Store My -Requireclientauthentication $true

Export the certificate:

Export-Certificate -Cert $serverCert -FilePath path\serverCert.cer

Copy the servercert.cer file to the client machine and on the client, open an administrator-elevated PowerShell console
Install the certificate into the trusted root store on the client:

Import-Certificate -FilePath path\serverCert.cer -CertStoreLocation Cert:\LocalMachine\root

Create the client’s certificate for use with the server allow list:

$clientCert = New-SelfSignedCertificate -DnsName Server DNS name -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(6) -KeyAlgorithm "RSA" -KeyLength "2048"

Configure the client certificate mapping on the client machine:

New-SmbClientCertificateMapping -Namespace Server DNS name -Thumbprint $clientCert.Thumbprint -Store My

Obtain client certificate SHA256 hash by running certutil to examine the Cert Hash(sha256) field:

Export-Certificate -Cert $clientCert -FilePath path\clientCert.cer


certutil.exe path\clientCert.cer | findstr /i /c:"Cert Hash(sha256)"

10. Return to the server.

11. Install the client certificate into the trusted root store on the server:

Import-Certificate -FilePath path\ClientCert.cer -CertStoreLocation Cert:\LocalMachine\root

12. Grant access to the client by its SHA256 entry:

Grant-SmbClientAccessToServer -Name Server DNS name -IdentifierType SHA256 -Identifier Cert Hash(sha256)

Note: you can also grant access by Issuer, meaning instead of adding a certificate SHA256 hash from every single client, you can instead add the Issuer DN by using -IdentifierType ISSUER. While not as granular or secure, this is useful for large client fleets when using a trusted certificate authority and not self-signed evaluation certs.

12. You have now configured SMB over QUIC CAC. Connect to the server using either:

NET USE \\server DNS name\share /TRANSPORT:QUIC

New-SmbMapping -RemotePath \\server DNS name\share -TransportType QUIC

Final Notes

SMB over QUIC isn’t just for mobile users and edge servers in Internet DMZs, it’s a practical defensive layer to prevent leakage of NTLM credentials and makes attacking internal files servers harder without first subverting a trusted client. TCP had its time, QUIC is the future of user and application transport.

We also just announced that a replacement for KDC Proxy - IAKerb - is coming to Windows Insider Previews along with a local KDC. These combined options mean the beginning of the end for NTLM, which will make SMB over QUIC Kerberos usage much easier. Read about it at The evolution of Windows authentication.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

SMB dialect management now supported in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:54:12 GMT

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25951 (Canary) and Windows Server Insider Preview Build 25951, the SMB server now supports controlling which SMB 2 and 3 dialects it will negotiate. This changes legacy behavior, where Windows SMB server always negotiated the highest matched server dialect from SMB 2.0.2 to 3.1.1 clients. Beginning in Windows 10, support was added for controlling SMB client dialects, but not server dialects.

With this new option, an administrator can remove specific SMB protocols from usage in the organization, blocking older, less secure, and less capable Windows devices and third parties from connecting. For example, they can specify only the use of SMB 3.1.1, the most secure dialect of the protocol.

Configuring SMB dialect min and max

You can configure this option with Group Policy and PowerShell. Both SMB client and server now include complete management support (previously the client support was only manual registry editing).

Group Policy (SMB Server)

To configure SMB dialect minimum and maximum for the SMB server (i.e. for inbound connection), enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Server \ Mandate the minimum version of SMB

Computer Configuration \ Administrative Templates \ Network \ Lanman Server \ Mandate the Maximum version of SMB

Select the minimum and maximum version of the dialects using a dropdown menu when the policy is enabled.

Group Policy (SMB client)

To configure SMB dialect minimum and maximum for the SMB client (i.e. for outbound connection), enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation\ Mandate the minimum version of SMB

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Mandate the Maximum version of SMB

Select the minimum and maximum version of the dialects using a dropdown menu when the policy is enabled.

PowerShell (SMB server)

To configure SMB dialect minimum and maximum for the SMB server service (i.e. for inbound connections) with PowerShell, set with the following syntax:

Set-SmbServerConfiguration -Smb2DialectMax {SMB202 | SMB210 |
SMB300 | SMB302 | SMB311 | None} -Smb2DialectMin {None | SMB202 | SMB210 | SMB300 | SMB302 | SMB311}

PowerShell (SMB client)

To configure SMB dialect minimum and maximum for the SMB client service (i.e. for outbound connections) with PowerShell, set with the following syntax:

Set-SmbClientConfiguration -Smb2DialectMax {SMB202 | SMB210 |
SMB300 | SMB302 | SMB311 | None} -Smb2DialectMin {None | SMB202 | SMB210 | SMB300 | SMB302 | SMB311}

Final notes

To see this new behavior in action, use a network capture tool like Wireshark and examine the client and server responses for the SMB2 Negotiate Protocol. For instance, here the client requests only SMB 3.1.1 because it's been configured with a minimum and maximum dialect of 3.1.1:

Final Notes

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

SMB NTLM blocking now supported in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:53:45 GMT

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25951 (Canary) and Windows Server Preview Build 25951, the SMB client now supports blocking NTLM for remote outbound connections. This changes legacy behavior, where Windows SPNEGO would negotiate Kerberos, NTLM, and other mechanisms with the destination server to decide on a supported security package. NTLM in this case refers to all versions of the LAN Manager security package: LM, NTLM, and NTLMv2.

With this new option, an administrator can intentionally block Windows from offering NTLM via SMB. An attacker who tricks a user or application into sending NTLM challenge responses to a malicious server will no longer receive any NTLM data and cannot brute force, crack, or pass hashes. This adds a new level of protection for enterprises without a requirement to entirely disable NTLM usage in the OS.

Note: This setting has no effect on loopback SMB NTLM usage, i.e. mapping a drive locally on a device with a local account.

Update April 3, 2024: official documentation now available at Block NTLM connections on SMB (preview) | Microsoft Learn.

Update Oct 11, 2023: We also just announced that a new local KDC is coming to Windows Insider Previews along with a replacement for KDC Proxy called IAKerb. These combined options mean the beginning of the end for NTLM. Read about it at The evolution of Windows authentication.

Update November 8, 2023:

Starting with Build 25992, the new SMB NTLM blocking feature now supports specifying exception lists for NTLM usage. This allows an administrator to configure a general block on NTLM usage while still allowing clients to use NTLM for specific servers that do not support Kerberos, either because they are not Active Directory domain joined or are a third party without Kerberos support.

Configuring SMB NTLM Blocking

You can configure this option with Group Policy and PowerShell. You can also block NTLM SMB connections on demand with NET USE and PowerShell.

Group Policy

To configure SMB NTLM blocking for the entire Windows machine, enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Block NTLM (LM, NTLM, NTLMv2)

To configure SMB NTLM blocking with exceptions for certain remote devices, enable the group policy under:

Computer Configuration \ Administrative Templates \ Network \ Lanman Workstation \ Block NTLM Server Exception List

You can then add IP addresses, fully qualified DNS, and NetBIOS names of remote machines where you want SMB to allow NTLM authentication.

PowerShell (global)

To configure SMB NTLM blocking for the entire Windows machine with PowerShell, set with the following syntax:

Set-SMbClientConfiguration -BlockNTLM $true

NET USE

To specify SMB NTLM blocking when mapping a drive with NET USE, use the following syntax:

NET USE \\server\share /BLOCKNTLM

New-SmbMapping

To specify SMB NTLM blocking when mapping a drive with PowerShell, use the following syntax:

New-SmbMapping -RemotePath \\server\share -BlockNTLM $true

Troubleshooting SMB NTLM Blocking

Connecting to Active Directory domain-joined computers with SMB while using a domain user account should always result in Kerberos authentication. Blocking NTLM should have no consequences to connectivity in this case. If you are expecting Kerberos to work when blocking NTLM and you are unable to connect, this section will help troubleshoot.

When NTLM is expected

You should expect NTLM usage under the following circumstances:

The client connects using an IP address.
The Kerberos CIFS Service Principal Name is missing in AD for the SMB server.
The credential used for the SMB server is a local user account.

The possible errors shown when NTLM blocking is preventing connection are:

0x43

ERROR_BAD_NET_NAME

The network name cannot be found

Troubleshooting

If you expect to connect but NTLM blocking is preventing you, use the following steps:

Verify that NTLM blocking is the culprit by temporarily disabling it on the client. The nature of NTLM blocking's current errors in Windows Insider means that it is easy to confuse NTLM blocking with unrelated networking problems like DNS name resolution.
If connecting with IP address, switch to using a fully-qualified domain name. To use IP addresses with Kerberos, review Configuring Kerberos for IP Address.
Verify the destination SMB server has its HOST SPN records registered by using SETSPN -L SMBSERVERNAME. For example:

setspn -L FS2
Registered ServicePrincipalNames for CN=FS2,CN=Computers,DC=corp,DC=contoso,DC=com:
WSMAN/fs2
WSMAN/fs2.corp.contoso.com
TERMSRV/FS2.corp.contoso.com
RestrictedKrbHost/FS2.corp.contoso.com
HOST/FS2.corp.contoso.com
TERMSRV/FS2
RestrictedKrbHost/FS2
HOST/FS2

If still unable to connect, use a network capture tool like Wireshark to examine the client and server messages for DNS, SMB2, and Kerberos.

Final notes

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned Pyle

SMB Signing and Guest Authentication

NedPyle — Tue, 09 Apr 2024 22:14:45 GMT

Heya folks, Ned here again. We recently made SMB signing the default in Windows Insider and Windows Server Insider builds. In doing so, we were quickly reminded of a consequence from an old unsafe SMB behavior that some folks still use: guest authentication. Today I'll explain all this and give you the steps to both fix and workaround the issue.

If you're in a hurry, skip down to the fixes and workarounds section below.

Signing and guest authentication

To sign a message, the key is derived from a secret both the user client and server share - the user's password. Without that password, the client and server can't sign the SMB traffic because they have no way to validate the sender. And what doesn't a guest logon have? A password. That makes guest authentication and SMB signing mutually exclusive. When we see that the client requires SMB signing, we don't allow even an attempt at guest authentication, we just fail the connection.

Insecure guest authentication fallback

Microsoft stopped enabling the built-in Guest account years ago - Windows 2000! - and stopped allowing guest logons by default (keep in mind that the built-in Guest user and guest-type access are two different things). Later, we started actively denying the built-in Guest account the ability to connect to Windows clients remotely using any protocol. Starting in Windows 10 and SMB2+, we the SMB team stopped SMB2+ guest access in general as well as a particular behavior called insecure guest fallback. Besides blocking anyone from intentionally using guest with SMB2+, we also prevent an old SMB1 behavior where if you sent along a non-existent user, the SMB2+ server could then ask you to logon as a guest silently. Again, Windows SMB2+ servers would not do this, but you can see how a malicious attacker would love for you to connect to their evil file server and start executing evil file code without even needing a password.

Fixes and workarounds

Now, remember at the top where I said we recently made SMB signing the default in Windows Insider Enterprise client builds? When you try to connect to third-party devices that use guest for "ease of use", you'll get one of these errors:

You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
Error code: 0x80070035
The network path was not found.

Even if you follow our steps in Guest access in SMB2 and SMB3 is disabled to enable guest in SMB again, they won't work. Because we disable guest access when you require SMB signing and you will receive error

"System error 3227320323 has occurred."

But there are options:

Fix

The Microsoft recommended fix is to stop accessing your third-party devices using guest credentials. Anyone - anyone - who can see that device can access all your data without any password or audit trail. Device makers configure guest access so they won't have to deal with their customers forgetting their passwords or require a more complex setup process. These are unsafe places to store your personal or professional life. Many of these devices do have the ability to configure a username and password - consult your vendor docs. Others might have the ability with a software upgrade. And others might just be unsafe - for those, you should replace them with a trustworthy product and move all your data off the old device, ensure you wipe its drives clean, then recycle it.

Workaround

If you cannot disable the use of guest for your third party, you must disable the requirement of SMB signing. Obviously, this means that now not only are you using guest access, but you're also preventing your client from guaranteeing signing to a trusted device. That's why this is just a workaround, and we don't recommend it.

You can disable the SMB signing requirement three ways:

Graphical (local group policy on one device)

Open the Local Group Policy Editor (gpedit.msc) on your Windows device.
In the console tree, select Computer Configuration > Windows Settings > Security Settings> Local Policies > Security Options.
Double-click Microsoft network client: Digitally sign communications (always).
Select Disabled > OK.

Command-line (PowerShell on one device)

Open an administrator-elevated PowerShell console.
Run

Set-SmbClientConfiguration -RequireSecuritySignature $false

Domain-based group policy (on IT-managed fleets)

Locate the security policy applying this setting to your Windows devices (you can use GPRESULT /H on a client to generate a resultant set of policy report to show which group policy is requiring SMB signing.
In GPMC.MSC, change the
Computer Configuration > Policies > Windows Settings > Security Settings> Local Policies > Security Options.
Set Microsoft network client: Digitally sign communications (always) to Disabled.
Apply the updated policy to Windows devices needing guest access over SMB.

Final thoughts

Now, we can make this easier to understand and are doing so in a future Insiders release. We'll have a better error message and better description in the group policy, and I'll also update our various MS Learn documentation on signing and guest access. But I mostly hope everyone will stop using third party devices with guest access - they are dangerous.

Reminder: with SMB1, all bets are off. None of what I mentioned above will stop guest access or myriad other unsafe behaviors. If your SMB server device still requires SMB1, you should assume anyone can access its data; even with a strong password, even without guest, even with SMB signing enabled. If you're unsure if your device requires SMB1, review its documentation and the Still Needs SMB1 product clearinghouse.

Don't invite them in!

Until next time,

Ned Pyle

SMB signing required by default in Windows Insider

NedPyle — Tue, 02 Jul 2024 17:54:44 GMT

Heya folks, Ned here again. Beginning in Windows 11 Insider Preview Build 25381 (Canary, zn_release) Enterprise editions, Windows 11 Insider Preview Build 25905 (Canary) Pro and Education editions, and Windows Server Preview Build 25931 signing is now required by default for all SMB outbound connections. Signing is not yet required by default on Windows 11 Insider Home editions. Furthermore, signing is required for all inbound SMB connections on all Windows 11 Insider editions. Signing is not yet required by default on Windows Server Insider Preview inbound connections (you can of course require it, like the last 25 years of Windows Server).

This changes legacy behavior, where Windows 10 and 11 required SMB signing by default only when connecting to shares named SYSVOL and NETLOGON and where Active Directory domain controllers required SMB signing when any client connected to them.

Important: if you have found a third-party vendor SMB product that does not support signing or does not enable SMB signing by default, please email wontsignsmb@microsoft.com with direct quote or documentation from the vendor of that product, including their website, knowledgebase, support forums, or other vendor channels. I am building a clearinghouse to help our customers get ahead of this before we ship the feature.

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

You'll recall the Windows 10 and Windows Server 2019 campaigns against SMB1 and guest auth fallback. Before that, we introduced functionality like encryption and pre-authentication integrity.

Security is a never-ending quest.

SMB signing

SMB signing ensures every message contains a signature generated using session key and cipher suite. The client puts a hash of the entire message into the signature field of the SMB header. If anyone changes the message itself later on the wire, the hash won't match and SMB knows that someone tampered with the data. It also confirms to sender and receiver that they are who they say they are, breaking relay attacks. Ideally, you are using Kerberos instead of NTLMv2 so that your session key starts strong; don't connect to shares with IP addresses and don't use CNAME records. Signing is a key defensive tactic.

Signing algorithms have evolved over time; SMB 2.02 signing was improved with HMAC SHA-256, replacing the old MD5 method from the late 1990s and SMB1. SMB 3.0 added AES-CMAC. In Windows Server 2022 and Windows 11, we added AES-128-GMAC signing acceleration.

Controlling the new signing behavior

All versions of Windows and Windows Server support SMB signing (back to Windows NT!). But a third-party might disable or not support it. If you attempt to connect to a remote share on a third-party SMB server that does not allow SMB signing, you should receive one of the following error messages:

0xc000a000

-1073700864

STATUS_INVALID_SIGNATURE

The cryptographic signature is invalid.

To resolve this issue, configure your third-party SMB server to support SMB signing. This is Microsoft's official recommended guidance. Do not disable SMB signing in Windows or use SMB1 to work around this behavior (SMB1 supports signing but does not enforce it). An SMB device that does not support signing allows interception and relay attacks from malicious parties. I can't speculate what errors a third-party SMB client will throw if it doesn't support signing and then connects to your Windows 11 client, but I'll update this post if someone reports one.

SMB signing will at least slightly reduce the performance of SMB copy operations. No, I cannot tell you how much; it depends entirely on the speed and number of your cores, as well as their utilization from all the other processes vying for their time. You'll need to evaluate against your workloads and decide if those with extremely high performance and latency requirements override the lack of security brought by unsigned traffic. This is no different than the past 30 years of SMB signing, it's just a change in defaults.

To see the current SMB signing settings, run the following PowerShell commands:

Get-SmbServerConfiguration | FL requiresecuritysignature

Get-SmbClientConfiguration | FL requiresecuritysignature

To disable the SMB signing requirement in client (outbound to other devices) connections, run the following PowerShell command as an elevated administrator:

Set-SmbClientConfiguration -RequireSecuritySignature $false

To disable the SMB signing requirement in server (inbound to your Windows 11 Canary Insider Enterprise, Pro, or Education edition device), run the following PowerShell command as an elevated administrator:

Set-SmbServerConfiguration -RequireSecuritySignature $false

With this new behavior, you can no longer examine the registry RequireSecuritySignature settings to know if Windows is requiring signing, because if they don't exist, Windows will still require signing. Any auditing tools that look at the registry could give false information. Use Get-SmbServerConfiguration and Get-SmbClientConfiguration or the CIM classes MSFT_SmbClientConfiguration and MSFT_SmbServerConfiguration and ensure any scripts or auditing tools use them (this has been the right approach for all SMB settings for a decade).

You don't need to reboot but existing SMB connections will still use signing until you close them or restart the device. If you disable the new default requirement for SMB signing with PowerShell or using Group Policy, it won't come back on automatically, it will just return to the legacy behaviors of Windows 11.

Important: signing (and encryption) also disable guest access. If you need to use guest for some third-party device, you must disable the requirement for signing. Read more on this at SMB Signing and Guest Authentication - Microsoft Community Hub.

Final thoughts

Expect this default change for signing to come to Home edition as well as to Windows Server in their Insider programs. Depending on how things go, it will then start to appear in major releases.

SMB encryption is far more secure than signing but environments still run legacy systems that don't support SMB 3.0 and later. If I could time travel to the 1990s, SMB signing would've always been on and we'd have introduced SMB encryption much sooner; sadly, I was both in high school and not in charge. We'll continue to push out more secure SMB defaults and many new SMB security options in the coming years; I know they can be painful for application compatibility and Windows has a legacy of ensuring ease of use, but security cannot be left to chance.

To get the latest Canary Windows insider ISO, visit Download Windows Insider Preview ISO (microsoft.com)

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

Ned "I had Nevermind on cassette" Pyle

The beginning of the end of Remote Mailslots as part of Windows Insider

NedPyle — Tue, 02 Jul 2024 17:55:21 GMT

Heya folks, Ned here again. With the release of Windows 11 Insider Preview Build 25314 and Windows Server Preview Build 25314, we have started disabling the Remote Mailslot protocol by default. This is a precursor to deprecation and eventual removal from Windows. You aren't using this extremely legacy protocol unless you're also using the deprecated and disabled-by-default SMB1 protocol, so 99.97% of you have nothing to worry about. For those who are, a bit more information:

Remote Mailslots

The Remote Mailslot protocol is a very old, simple, unreliable, insecure IPC method. A server creates a mailslot and a client writes messages to it using NetBIOS datagrams as a transport when operating over a network with Windows. The sender of the mailslot message formats the SMB_COM_TRANSACTION message and sends it as a NetBIOS datagram. The Proto-SMB1 Common Internet File System (CIFS) Browser Protocol uses "\MAILSLOT\LANMAN" and "\MAILSLOT\BROWSE", for instance.

Mailslots are older than Windows NT, dating back to LAN Manager DOS days. It goes without saying that this protocol is disgusting. If you've been an IT Pro for a few decades, you might recall people using the anonymous NET SEND command (MAILSLOT\Messngr) to broadcast important messages to all logged on users, or more likely, this kind of crap:

What changed

Starting with Windows 11 Insider Preview Build 25314, remote mailslot is disabled by default. If you have manually re-enabled SMB1 (which has been disabled by default since Windows 10) and some application is still using a Remote Mailslot, they will see one of the following errors:

3025

ERROR_REMOTE_MAILSLOTS_DEPRECATED

“The requested operation failed. Remote mailslots have been deprecated.”

Contact your vendor about updating their software to join the 21st century, as it both requires SMB1 and Remote Mailslot. This protocol is not secure, was replaced decades ago by better technology, and should not be used under any circumstances.

If you need to re-enable Remote Mailslots temporarily while you yell at your vendor or developer, use the following PowerShell command:

PS C:\> Set-SmbClientConfiguration -EnableMailslots $true

Remote Mailslots will get officially deprecated in the next release of Windows and Windows Server, meaning that it can eventually be removed altogether. That will take time and there will be plenty of public warning, just like SMB1 had.

Final notes

This is part of a campaign to improve the security of Windows and Windows Server for the modern landscape. You've read my posts on SMB security changes over the past year:

SMB alternative ports (November 2023)
SMB Firewall changes in Windows insider (November 2023)
SMB over QUIC now available in Windows Server Insider Datacenter and Standard editions (November 2023)
SMB client encryption mandate now supported in Windows Insider (October 2023)
SMB over QUIC client access control now supported in Windows Insider (October 2023, updated Nov 2023)
SMB NTLM blocking (September 2023, updated Nov 2023)
SMB dialect management (September 2023)
SMB signing required by default in Windows Insider (June 2023)
The beginning of the end of Remote Mailslots (March 2023)
SMB insecure guest auth now off by default in Windows Insider Pro editions (January 2023)
SMB authentication rate limiter now on by default in Windows Insider (September 2022)
SMB1 now disabled by default for Windows 11 Home Insiders builds (April 2022)

For more information on securing SMB on Windows in-market, check out:

Until next time,

- Ned Pyle