Windows Server 2025 security baseline: LDAP signing, Kerberos encryption, and SMB encryption defaults

Windows Server 2025’s security baseline is less about new features than about defaults that harden authentication and data movement—LDAP signing, Kerberos encryption handling, and SMB encryption among them. Microsoft’s OSConfig can help control drift, but the real work is testing what will break in legacy directory, file-service, and backup workflows before rollout.

What is actually new in Windows Server 2025 security?

The most important change is not one single feature. It is the combination of defaults and framework. Microsoft has published Windows Server 2025 security baseline guidance through OSConfig, which is intended to give administrators a role-aware starting point and drift control. That baseline explicitly covers the Windows Server security baseline, Microsoft Defender Antivirus configuration, Local Administrator Password Solution, and Secured-core server configuration. Microsoft also says it is aiming that work at CIS Benchmarks and DISA STIG recommendations. (learn.microsoft.com)

That matters because most server estates do not fail through one dramatic weakness. They fail through accumulated exceptions: unsigned LDAP binds that were tolerated for years, SMB clients still using older assumptions, service accounts with brittle crypto settings, and build pipelines that quietly introduce untrusted code. Windows Server 2025 pushes against that drift. (learn.microsoft.com)

Does the new baseline replace traditional hardening guides?

No. It reduces the amount of hand-tuning, but it does not remove the need for judgement. Microsoft’s OSConfig model is a desired-state approach: apply the baseline, then keep the server in that known-good state. That is useful, but it only works if you understand what you are allowing to fail. A security baseline that blocks legacy LDAP binds or stricter SMB behaviour is sensible on paper; in production it can surface forgotten appliances, backup agents, printer integrations, or old admin tooling. (learn.microsoft.com)

So the right question is not “should we use the baseline?” but “where will it break, and is that breakage telling us something useful?” In most enterprise environments, the answer will be yes. A baseline that reveals unsupported dependencies is doing work. The risk is rolling it out as a blanket policy without a staged assessment. (learn.microsoft.com)

Which security changes matter most in practice?

1. LDAP signing and channel binding

Microsoft now documents that new Active Directory deployments on Windows Server 2025 require LDAP signing by default after SASL binds, and the company has also described LDAP support for TLS 1.3. LDAP signing and channel binding address a real problem: unauthenticated or weakly protected directory traffic is a gift to interception and tampering attacks. For organisations that still have scripts, scanners or legacy apps binding without signing, this is the first area likely to cause friction. (learn.microsoft.com)

From an operational point of view, this is one of the few security changes that usually deserves priority. If an application cannot handle LDAP signing, that is not just a Windows Server 2025 issue; it is a sign that the application is relying on obsolete directory assumptions. The fix may be configuration, but it may also be replacement. (learn.microsoft.com)

2. Kerberos encryption changes

Microsoft says Windows Server 2025 no longer honours the legacy SupportedEncryptionTypes registry key for Kerberos and recommends using Group Policy instead. That sounds like a narrow implementation detail, but it matters in estates where administrators have historically relied on registry edits to steer encryption behaviour for specific systems or service accounts. Those environments often have the highest risk of drift because the method of control is invisible to most management tooling. (learn.microsoft.com)

The practical judgment here is straightforward: if your Kerberos posture depends on hand-maintained registry configuration, you should treat that as technical debt, not as a valid long-term control. Expect to validate service accounts, legacy NAS devices, and cross-platform integrations, especially where older encryption expectations still lurk. (learn.microsoft.com)

3. SMB encryption and signing

Microsoft’s SMB documentation now states that SMB encryption is required by default for all outbound SMB client connections in Windows Server 2025 and Windows 11 24H2. It also reiterates that SMB 3.1.1 includes preauthentication integrity and that modern signing and encryption options are the current security path. For file services, this is a material change because it affects almost everything that touches shared storage: application servers, backup targets, copy jobs, and admin access. (learn.microsoft.com)

There is a trade-off. Stronger SMB security is welcome, but some older devices and third-party appliances may not be ready for the stricter behaviour. If you run backup software, edge storage, or migration tooling, verify that the product supports current SMB negotiation and encryption expectations before you treat Windows Server 2025 as a simple in-place upgrade. That is especially relevant for estates that include backup and replication workflows, such as those discussed in our Veeam Latest Updates coverage. (learn.microsoft.com)

4. Secured-core server and code integrity

Microsoft positions Secured-core server as a hardware-backed root of trust with defences against firmware-level attacks and unverified code. On Windows Server 2025, OSConfig also folds in Secured-core server configuration as part of the security baseline picture. This is the part of the story that tends to be oversold in marketing, because the benefit depends heavily on the hardware platform actually supporting the relevant protections. (learn.microsoft.com)

In practice, Secured-core is most valuable on systems that already merit a higher trust level: domain controllers, management servers, sensitive application hosts and virtualisation nodes. It is less about raising every server to the same absolute level, and more about preventing the most expensive compromise paths in the places that matter most. (learn.microsoft.com)

5. App Control for Business

Microsoft says it has a default policy for Windows Server 2025 and that App Control for Business is exposed through OSConfig. That is significant because application control is one of the few controls that can materially reduce the chance of untrusted code running at all. Microsoft also describes audit mode and enforcement mode, which is exactly where real-world deployments need to start: learn what will be blocked before you actually block it. (learn.microsoft.com)

This is also where a good security programme becomes a political problem. Application control improves resilience, but it can disrupt admin scripts, update tools, installers and niche monitoring agents. That does not make it a bad control. It makes it a control that needs change management, exception handling and a realistic pilot scope. (learn.microsoft.com)

Where should organisations start?

If you are planning Windows Server 2025 adoption, start with the controls most likely to expose hidden dependencies:

• Directory services: test LDAP signing, channel binding and Kerberos behaviour against every management tool, application and identity integration. (learn.microsoft.com)
• File services: verify SMB encryption and signing expectations on servers, appliances and backup targets. (learn.microsoft.com)
• Code integrity: pilot App Control in audit mode before enforcement. (learn.microsoft.com)
• Platform trust: align Secured-core server with hardware that actually supports the feature set you plan to use. (learn.microsoft.com)
• Baseline management: use OSConfig to keep policy from drifting back to convenience settings. (learn.microsoft.com)

FAQ

Is Windows Server 2025 automatically secure if I use the baseline?

No. The baseline is a strong starting point, not a guarantee. Microsoft’s own OSConfig documentation describes it as a recommended, role-aware posture with drift control. That helps, but your exposure still depends on identity design, patching discipline, application control, hardware trust and how much legacy protocol support remains in the environment. (learn.microsoft.com)

Will Windows Server 2025 break legacy apps?

It can. Anything relying on unsigned LDAP, outdated Kerberos configuration, weak SMB assumptions or unrestricted code execution deserves attention. That does not mean the server is broken; it means the application may have been depending on security gaps that are no longer acceptable. (learn.microsoft.com)

Is OSConfig worth adopting outside Microsoft-managed environments?

Yes, if you want a consistent state model across on-premises and Arc-managed servers. Microsoft says OSConfig integrates with Azure Policy, Microsoft Defender and Windows Admin Center, and can support compliance reporting and drift control. That makes it more than a one-off hardening script. But if your estate is heavily heterogeneous, you will still need a broader configuration strategy for non-Windows systems. (learn.microsoft.com)

Should I treat Secured-core as mandatory?

Not universally. It is a strong choice for high-value servers and platforms where firmware and boot-chain attacks would be especially damaging. But it depends on compatible hardware and may be hard to retrofit into older estates. The right approach is selective: prioritise the systems whose compromise would hurt most. (learn.microsoft.com)

What is the one thing most teams will underestimate?

Dependency mapping. The security changes in Windows Server 2025 are not cosmetic. LDAP signing, Kerberos control changes and SMB encryption can expose old tooling very quickly. The teams that do well will test this before rollout, not after users start reporting failures. (learn.microsoft.com)