 Well, hello everyone. Welcome to the Windows Server 2025 security session at the Windows Server Summit 2024. I am Ram Jay Raman. I work as a product manager in Azure Edge Security Team at Microsoft. And I will be joined by my colleague Matthew Reynolds for the session. I will talk to you about the various security enhancements and new capabilities in Windows Server 2025. I will talk to you in terms of specific pillars. First, we want Windows Server to be a trustworthy addition to your environment. And with that end, we have actually created a tailored security baseline and you can customize it. You can apply it and you can use the tools that we will provide to do that. And we will provide application control enabled in audit mode that will allow you to see the different applications that run on your system and get a view on whether those applications are allowed applications, not allowed applications, and you can take actions based on that. We have made improvements to Kerberos and we have reduced use of NTLM, old legacy authentication protocol. And we have reduced the need or actually got rid of the need to use passwords with service accounts. It's through a feature called delegated managed service account. We will cover all of those in the next few slides. So the next pillar is operational security. Once you enable Azure Arc on your server, you will have access to a number of Azure services. For instance, the Azure policy you can use to do a compliance assessment against security baselines. And you can use a drift protection mechanism that we have built in Windows Server 2025 and apply it against the security baseline. So the drift mechanism basically ensures that if there's a configuration drift that happens over time, it will automatically bring it back to the golden state. So that's a powerful mechanism. And the next pillar is workload security. You can enable Microsoft Defender for control for cloud on your workloads and it can do continuous monitoring and predict against advanced threats. The next is Silicon Assisted Security. No, many of the security features that we have built in the operating system really truly rely on the hardware level security capabilities. If you look at the server ecosystem today, many installations, in fact, many of them do not turn on secure both. That's a very basic fundamental thing. And many of the hardware out there, they don't have a physical DPM. That's the state of affairs. And in truth, many of the features that we have in the operating system can only be fully lit up if you have the right hardware foundation in terms of hardware security capabilities. So to that end, we work closely with the industry, the OEMs and the partners through the SecureCore program. The SecureCore program is essentially an additional qualification on top of the service certification program. And OEMs can actually certify their hardware for SecureCore and listed in the catalog so that your customers know for a fact those hardware systems have been certified from a SecureCore point of view. And with the SecureCore foundation in hardware, you can be rest assured that you'll be able to enable many of the security capabilities in the worst layer. Next one, security foundations. Security assurance is fundamental to any product or feature development. And at Microsoft, we have significant investments that we have made into ensuring that the features and the products that we develop follow the Microsoft security development lifecycle. And with respect to certification, we will certify Windows Server 2025 from common criteria and FIPS. And additionally, we will provide guidelines using which you can actually gain compliance to regulatory standards like HIPAA, PCI DSS and others. And those guidelines will guide you on what specific features and capabilities exist in the system, which will allow you to meet those regulatory requirements. Next, Matthew is going to talk to us about SecureStart and SecureOperations. And then I will come in and cover some of the security capabilities we touched on. Matthew. Great. Thanks, Ron. A core part of our SecureStart and SecureOperations story is, as Ron mentioned, security baselines. And historically, you could argue security baselines have kind of been left to the community to figure out rather than being a core part of the product. And frankly, people have done amazing work with documents and scripts and things, but there are some persistent challenges treating it this way. For example, security baselines have been hard to discover, so not that many systems wind up being protected. Baseline authorship has been kind of squishy and unclear, like who do you call in the middle of the night? And baseline tooling and even definitions have often not been available until long after a new OS has released, making it kind of impossible to use that new OS in lockdown environments. So with Server 2025, we're bringing baselines and other security protections, but we'll focus on baselines for now closer to the core product. And we're delivering a baseline experience which is developed by the Server 2025 security team. Rather than being available a year after release or a month after release, it's available now as part of the Server 2025 preview program. It's integrated with PowerShell. So no matter what deployment workflow you have, it's going to intersect PowerShell at some point, and so you can you can deploy it there. And we think the best time to apply it is during image customization. So by the time you get to a point where you're deploying VMs and masks, they're already preconfigured with the baseline. As Ram mentioned, we also have this new drift control feature powered by a new OS component called OS config. You'll hear more about as Server 2025 comes to market. And so if a random script comes along and undoes one of your security baseline settings, we'll set it right back. And then finally, we're driving good integration with the cloud and tools like Azure Policy, Defender for Cloud, even Windows Admin Center to make sure that not only do your system start secure, but that you can continue to maintain and sustain and monitor that compliance over time. I'll show you a little bit of the PowerShell experience. So what we have here is a we're installing this new module. So for those of you that are familiar with PowerShell and modules, this will be a familiar workflow. Once this module is installed, it's an pre-release state right now, then you can run these commandlets to configure security properties on your system, such as security baselines. Let me pause for a second here on this first commandlet name, set OS config desired configuration. It's a mouthful, but it means a lot. What we're saying here is not only just, hey, spread some settings onto my system, what we're saying here is, hey, operating system, please maintain yourself in this state over time. So this is a richer act than just writing some registry values or something. And then what happens is, so you say, I want you to apply to this configuration, and I want you to sustain yourself in that state over time. The configuration itself in this case is a security baseline, and you may have noticed as the video is going there, the tab completion, so this is all pretty easy to discover, easy to find different scenarios that are available. And once you run that, that's it. You can also customize, for example, let's say that the baseline has a min password length of 14, but you say, no, in my industry, actually use 16 or 30 or something, you can override certain settings as this example is showing, and those then become part of your version of the baseline, which again is sustained automatically by the operating system over time. In this particular example, the customization is turning off the firewall, which curious example, but you can customize these, and you can see the state of your customizations, then see how all of this plays out over time, even remove security configurations if you need to do in a diagnostic scenario. That's probably enough on that topic, so I will turn it back to Ron. Thank you very much. Well, thank you, Matthew. Love the demo. Next, I'll talk to you about application control. With application control, you as a customer, you can restrict the applications that are allowed to run on your system. Now, what we will do in Windows Server 2025 is Microsoft will provide a set of base policies that will be enabled in audit mode, not enforced, just audit. That would allow you to know what applications are running on your system, and those audit mode will generate events that you can view and you can visualize and take actions. Now, use a customer, you can obviously extend and you can customize those policies, and you can also create supplemental policies, and what we will do is provide you an Azure Monitor workbook from where you can actually view those various events from application control and also gain insights at scale. Next, I'll talk to you about service accounts. Those of you who have been playing with Active Directory, who have been installing systems and enterprise, you should be all familiar with service accounts. Service accounts are machine accounts, are actually user accounts that provide the security context that services need to be able to correctly run on the OS. Like, for example, a service may need to access a network resource, and the service account allows it to effectively go do that. The problem with service accounts is that people end up actually using weak passwords, and they actually reuse passwords across different service accounts, and they do not rotate passwords. Now, if I'm an attacker, I'm going to look at it and say, hey, that's a low-hanging fruit. I'm just simply going to take one of those, compromise one of those accounts, right? And it's not too difficult to do that, even what I just described, you know, weak passwords, you know, passwords getting reused. And once they get in, the attacker basically finds ways to elevate oneself into the system, and then they spread laterally. That's typically what happens. Now, with rather managed service accounts, things are better. You actually have the system generator password for you. It's a machine-generated password. It's relatively strong, and it gets auto-rotated. So far, so good. But still, the problem is you are using passwords. Now, that could be a malicious admin who can do bad things with the password, right? Or even if the admin is not malicious, inadvertent disclosure, right, leaking of passwords, suddenly it happens. You can't control it 100% all the time. So fundamentally, the point I'm making here is that there's a problem with using passwords, particularly with service accounts. So I'm going to talk to you about what's called a delegated managed service account. It's a feature that's up and coming in Windows Server 2025. And with this feature, we have endeavour to get rid of the use of passwords with service accounts. So now, since the delegated managed service account are in short, DMSA, it is a machine-bound service account. What do I mean by that? It uses the machine identity that is stored in the local machine, and it uses symmetric keys derived from the machine identity and uses the symmetric key to do the authentication flow at a very high level. So the way it works is you, as an admin, you have a set of service accounts that exist today. And all you have to do is specify which of those service accounts you want to migrate over or upgrade to at DMSA, a delegated managed service account. That's it. Once you specify which of those service accounts need to be superseded to a DMSA, then the protocol takes care of the rest. So what really happens behind the scenes is when the authentication system is engaged in the TGT, a ticket granting ticket key, TGT request comes through, a refresh comes through, the Kribberhausen basically kicked back and say, hey, this service account has been superseded because you, admin, your market are superseded with DMSA. You have left your intent. So that's an indication to the protocol that it has to just simply provision the DMSA account, the upgraded DMSA account with a symmetric key. And that's it. And the rest of the Kribberhausen's protocol just flows as it usually does. So that's it. And effectively, by doing this, we have gotten rid of use of passwords for service accounts. Now, this is based on machine identities that are bound to the machine, as I mentioned, and you can have a single machine, multiple service accounts bound to a single machine and a single DMSA bound to multiple machines. So all n by n combinations are possible. We should definitely wait for us to give you more details on how the protocol works. But rest assured that this delegated managed service account would allow you to eliminate passwords for service accounts. And also you can easily upgrade your existing service accounts to a delegated managed service account. Moving on to Kribberhaus, we have made, I'll actually touch on some of the improvements on Kribberhaus, not all. We have made changes to Kribberhaus where we have made the implementation more crypto agile. What I mean by that is, these crypto algorithms and ciphers, they continue to evolve over time. Existing ones get outdated and newer ones come in and crypto agility effectively gives you the ability to easily upgrade to the newer algorithms, crypto algorithms, without a wholesale change. And that's important for you to preserve your investment and continue forward. I'll talk about quantum safeness. So today, many of the crypto algorithms that exist today, they are based on the difficulty associated with solving complex mathematical problems like integer factorization and so on. Now the existing algorithms on the conventional computers can really break, you know, can really solve the difficulty and rather easily in human time. So that is the basis for existing algorithms. But with quantum computers, somebody in the future when they have a viable quantum computer that's powerful enough to break these complex mathematical problems, solve those problems rather, then they can basically, you know, take down these algorithms that exist today, they can crack it. For example, Diffie Helman Key Exchange today uses discrete logarithmic problem as the basis. Now if a quantum computer breaks discrete logarithmic problem and sure your Diffie Helman Key Exchange can be easily compromised. Now with crypto agility, we have actually ensured that as quantum safe algorithms come into place, you can easily upgrade to those. And that work is ongoing. NIST, National Institute of Standards and Technology has been doing some really good work. It's been leading the industry. Many companies are involved. Microsoft is involved. And you will see more quantum safe algorithms come through. And as they continue to evolve, you can be assured that with crypto agility, you can easily upgrade to those algorithms. The other change with Kerberos is we have got rid of RC4. RC4 is a cypher. It's been popular for a while, but it's getting outdated and it's got problems. In general with Kerberos, there's a type of an attack called Kerberosting attacks. So what attackers tend to do is they get a hold of the TGS, the ticket granting service ticket. Basically it's a service ticket and it's protected and encrypted using a hash derived from the service account password. Now, if that hash was produced using RC4 MD5, it makes it much easier to perform this Kerberos attack. So effectively by getting rid of RC4, we have reduced the chances of Kerberos attacks. So obviously more details to this and I encourage you to attend the session on the evolution of Windows authentication by one of my colleagues, Netpile. On to NTLM. As we discussed earlier, NTLM is an old legacy authentication protocol. It's been in Windows for a while. It has some nice attributes. It's simple. People have been using it and in fact, it's been widely used for many years and people are not changing over very fast. Instead of the weaknesses associated with that NTLM protocol. Now, fundamentally, the problems we have with NTLM is that it uses weak passwords. The password hashing, not weak passwords, but the password hashing algorithm is based on MD4, which is a weak algorithm. We're not able to collision attacks and the password hashes are stored in memory and people can sweep the memory and get a hold of the hash and once you have the hash, you can actually perform a lot of different types of attacks past the hash attack and such. Now, the problem with NTLM is that the client doesn't have a way to authenticate this server. It's not part of the protocol. You don't know who you're talking to. Somebody can come in the middle and play an intermediary but post themselves as the server and take control. That's the relay attack that's possible with NTLM. That said, our immediate goal is to reduce these NTLM. It's not possible to fully eliminate it for the reasons I mentioned earlier. There's a lot of legacy left over and people are just not completely giving up and moving on. It's just not happening as fast. We are working to reduce the use of NTLM in ways we can and ultimately our goal is to fully eliminate the use of NTLM. What we did with Windows Server 2025 was looked at really where the NTLM usage is coming from and we noticed that close to 50% of NTLM usage is actually coming through from the SD negative protocol. It's a negotiation protocol that is used by clients and servers to negotiate on the authentication mechanism that they need to use whether they use Kerberos or NTLM or something else. The negotiation protocol allows these clients and servers to go to the negotiation. What happens is that as part of the negotiation there's a fallback that happens. You look for authentication mechanism A or B or C. If nothing else works then you fall back to NTLM. That's what drives 50% of the usage of NTLM today and what we have actually done is increase the use of Kerberos in more scenarios and therefore reduce the fallback to NTLM. That's work that we have done with Windows Server 2025. Now also as we talked about with NTLM it's prone to man-on-the-middle attacks and the general guidance to protect against those type of attacks is to enable server signing and to have channel binding enabled as well. And what we have done in Windows Server 2025 is enable channel binding by default so you don't have to think about it twice. And also with SMB the server message block file sharing protocol you can make an intentional choice to ask Windows not to offer NTLM as an option when it negotiates protocol through SBNego negotiation mechanism. So that's there today and you can benefit from that. So effectively these are all ways by which you can circumvent NTLM. And NetPile is giving the talk as part of this summit. It's called the evolution of Windows authentication. It's the same talk I mentioned before. Please do listen to it and it is going to go deep into the topic. So that said thank you all for attending this session and it's been a pleasure connecting with you all. And if you have comments or questions you'd love to hear from you and we have a aka.ms link on the screen and a QR code. You can use that to send us feedback and also engage us in a conversation. We look forward to hearing back from you. Cheers.