The Server Message Block (SMB) protocol has been used by Windows Server (WS) and Windows OS for quite a while now. However, its compression issues were resolved and integrated by Microsoft only in 2020. SMB compression allows saving on storage and time required to transfer and store the shared files. It also has various use cases, each having its own nuances.
In Part 1, we talked about the security principle of two-factor authentication and how to prepare your existing Remote Desktop (RD) Gateway for Network Policy Server (NPS) Extension for Azure Multi-Factor Authentication (MFA). Now, it’s time to integrate the solution and look at the logs and tools for troubleshooting in case any issues occur.
Network Policy Server (NPS) Extension for Azure Multi-Factor Authentication (MFA) is a good choice to enhance the security of your Remote Desktop (RD) Gateway. This combination will use two-step verification for client authentication to add another protection layer to your NPS/RADIUS (Remote Authentication Dial-In User Server).
In Part 1 we focused on overall information on SMB over QUIC and how to make the necessary preparations for all to function well. Today, we’ll focus on the technicalities. It will be somewhat a tedious process but we’ve laid out everything in minute detail, so you don’t have to break your neck trying to figure it all out 😉
Previously, we discussed how Windows Server 2022 is continuing to push the QUIC networking transport protocol on top of UDP. In this article, we’ll focus on SMB storage protocol over QUIC, how it prevents server spoofing, how it’s integrated into the client and the server, how to prepare for its work, and other related topics.
Windows Server 2022 will see various novelties. Among others, it will push its QUIC, TLS 1.3, HTTP/3, and SMB 3.1.1 protocols as new standards. QUIC, specifically, is presented as an alternative to TCP and is often dubbed “TCP/2.” But are these protocols worth being standardized? And what are the challenges?
More transparency, fewer hardware restrictions, freedom of choice, clarity of control, and immutability — that’s where backups are headed. Microsoft has been taking too long to adapt its ReFS to those consumer demands. Veeam and Linux, on the other hand, leverage those trends and offer immutability with reasonable freedom of object and cloud storage choice.
Part 2 discussed adding the Linux server to Veeam managed servers and adding immutable repositories, along with incompatible configs that Veeam’ll block if you try using them. Today, you will learn about the entire configuration deeper: how immutability works, scenarios with bad actors, how they can succeed, and how to test if all is working fine.
Part 1 discussed what a hardened repository was, how Veeam B&R V11 had everything to achieve that, and how to set up Linux for those purposes. Now, you will learn how to add the Linux server to Veeam managed servers and how to add immutable repositories. You’ll also learn about incompatible configs that Veeam will block if you try to use them.
Veeam Backup & Replication V11 introduced the ability to build your own immutable, hardened backup repository. There’s no more need to use third-party compatible solutions, like WORM disk storage or others. Now, you can do that using any server with storage that meets the requirements plus several supported Linux distros and XFS.
