Windows Server 2025, security baseline
Microsoft is pleased to announce the release of the security baseline package for Windows Sever 2025! Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize / implement as appropriate. This release includes several changes to further assist in the security of enterprise customers, including changes to account lockout, Local Security Authority, LAPS, Kerberos, Microsoft Defender Antivirus, Windows Protected Print, Windows Update, and more. In an upcoming release planned for early 2025, we will include additional configuration settings to reflect the recently introduced baseline applied via OSConfig so that administrators will have more flexibility and control to fine-tune their configuration to better align with their specific security and operational needs. This enhancement aims to streamline the management process and ensure that the baseline settings are consistently applied across all systems. Although we do not have a specific date yet, users can look forward to benefiting from these improvements soon. Account lockout In this release, we have made several changes to account lockout policies that raise the security bar. Account lockout threshold: 3 attempts (previously 10 attempts). Account lockout duration: 15 minutes (remains the same). Reset account lockout counter after: 15 minutes (remains the same). Configure hash algorithms for certificate logon The policy Configure hash algorithms for certificate logon has been added for smart card crypto agility, located at System\KDC and System\Kerberos. This setting lets users configure the hash algorithm to be used in certificate-based smart card (PKINIT) authentication of Kerberos. With this configuration, customers have the option to prevent SHA-1 from being used. It’s important to note these settings are useful only if both the client and KDC (Windows Server 2025) are configured this way in the environment. Disabling SHA-1 for PKINIT is more secure for your environment. However, the authentication might fail if your domain controller does not support PKINIT SHA-2. For that reason, we leave the SHA-1 option as default in the baseline and suggest you test your own environment before making a decision. Delegated Managed Service Account (dMSA) logons The new policy Enable delegated Managed Service Account (dMSA) Logons controls dMSA logons for the machine, located at System\Kerberos. Delegated Managed Service Account (dMSA) is an Active Directory account designed for secure and efficient management of credentials, with automatic password management and device-specific access. If you enable this policy setting, dMSA logons will be supported by Kerberos client. Please review the prerequisites before adjusting the policy setting. By default, dMSA is disabled because the Domain Controller (DC) must also be upgraded to Windows Server 2025 for the feature to function properly. If the DC is running a version earlier than Windows Server 2025, the necessary schema updates for dMSA will not be present. If your DC has been upgraded to Windows Server 2025, we suggest enabling this policy on both the client and DC sides. When enabled, you may need to specify realms, i.e., which domains or parts of the directory can authenticate and access the dMSA account. A child domain on an older Windows Server version can still interact with the accounts while maintaining security boundaries. It allows for a smoother transition and coexistence of features across a mixed-version environment. For example, if you have a primary domain called corp.contoso.com running on Windows Server 2025 and an older child domain called legacy.corp.contoso.com running on an older version of Windows Server (e.g., Windows Server 2022), you may specify the realm as legacy.corp.contoso.com. To learn more, see Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025. Event Log service You can use the newly added policy Limit remote access to the Event Log Service, located at Windows Components\Event Log Service, to control which remote users will be allowed to connect to the Event Log service on the machine. This helps reduce the attack surface for an adversary to capture machine credentials when configured to limit access to Administrators on Domain Controllers and other systems where the machine credentials are trusted to remotely connect to other systems. We recommend you test everything thoroughly and provide clear guidance for users before enabling this policy to avoid compatibility risks and workflow disruption. For example, when the policy is set to limit access to Administrators, IT pros cannot view events from a machine remotely without actually logging in to that machine. This setting does not control access to individual logs. Once a remote connection is allowed, the account will still need access to the specific resources it is attempting to use. Local Administrator Password Solution (LAPS) In our ongoing effort to enhance security and streamline management for our customers, there is a series of new policies aimed at controlling Local Administrator Password Solution (LAPS). Size of Encrypted Password History allows administrators to define the number of previous encrypted passwords stored in Active Directory. By managing password history effectively, we enhance security by preventing the reuse of old passwords. Post-authentication Actions specifies the actions that should be taken after an authentication by the managed account. Administrators can choose to reset the password, log off the managed account, reboot the device, or terminate processes. A grace period can also be configured before these actions are executed, ensuring robust security measures are in place. Configure Automatic Account Management configures options for automatic account management, allowing administrators to specify the target account, whether it be the built-in admin account or a custom account. Administrators can define the name or prefix for the managed account and decide if the managed account should be enabled or disabled. Additionally, there is an option to add a random numeric suffix to the managed account name, enhancing security through complexity and uniqueness. With these new policies, we aim to provide you with more control and flexibility in managing your security settings, thereby ensuring a safer and more efficient environment. Local logon We have adjusted the configuration recommendation for the policy Allow log on locally, located under User Right Assignments in this version. For Domain Controllers (DCs), we now recommend you allow both the Administrators and Enterprise Domain Controllers groups to log on locally. We’re changing this recommendation to address an issue that arises when a component calls lsalogonuser() under the context of the machine account to update PKINIT machine credentials. LDAP server signing requirements for DC A new policy, Domain controller: LDAP server signing requirements Enforcement, has been introduced and overlaps the old one, Domain controller: LDAP server signing requirements. As a result, we’ve made an update on the baseline which is to leave the old policy as default and enforce the new one for domain controllers to ensure the capability still functions as expected to secure your environment. Local Security Authority The new policy Allow Custom SSPs and APs to be loaded into LSASS controls whether custom Security Support Providers (SSPs) and Authentication Packages (APs) are allowed to load into the Local Security Authority Subsystem Service (LSASS). In addition, you can also use the new policy, Configures LSASS to run as a protected process to control the configuration under which LSASS is run. For the most secure posture, enabling LSA protection with UEFI is the most secure option. However, locking with UEFI adds some dependencies and may cause some compatibility risks. For that reason, we highly recommend evaluating your environment carefully before enabling the policy with UEFI lock. To see more details, refer to this document. Microsoft Defender Antivirus Attack Surface Reduction (ASR) We recently added a rule specifically designed for server environments to the baseline. We strongly recommend that you thoroughly test this ASR rule in your environment before implementing it to ensure it aligns with your security needs and does not interfere with your operational processes. ASR Rule GUID Block Webshell creation for Servers a8f5898e-1dc8-49a9-9878-85004b8a61e6 We also removed certain Attack Surface Reduction (ASR) rules that are no longer applicable to the server side. These rules will now only be applicable to the client version. This adjustment ensures that our security measures are more accurately tailored to specific needs and environments. Please see those rules below. ASR Rule GUID Adobe Reader from creating child processes 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c Block executable content from email client and webmail be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 Block all Office applications from creating child processes d4f940ab-401b-4efc-aadc-ad5f3c50688a Block Office communication application from creating child processes 26190899-1602-49e8-8b27-eb1d0a1ce869 Block Office applications from creating executable content 3b576869-a4ec-4529-8536-b80a7769e899 Block Office applications from injecting code into other processes 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 Block Win32 API calls from Office macros 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b Control the visibility of exclusions The settings Control whether exclusions are visible to local users and Control whether or not exclusions are visible to Local Admins in Microsoft Defender Antivirus policy determine whether local users and local administrators can view the list of configured exclusions. We recommend enabling both policies to prevent local administrators and users from seeing the exclusions in the Windows Security app or via PowerShell. When configured this way, only administrators with access to the management tools can view and manage these exclusions. This helps organizations ensure that only authorized personnel can view or modify these settings. Configure the update channel Microsoft Defender Antivirus has introduced three policies to select the update channel, tailored to different environments. These policies allow administrators to choose the channel for daily Security Intelligence updates, monthly Engine updates, and monthly Platform updates. We suggest configuring these three policies as below Select the channel for Microsoft Defender daily Security Intelligence updates - Current Channel (Broad) Select the channel for Microsoft Defender monthly Engine updates - Current Channel (Broad) Select the channel for Microsoft Defender monthly Platform updates - Current Channel (Broad) Device control Microsoft Defender Antivirus has introduced a suite of new device control policies to allow administrators to regulate access to peripheral devices such as USB drives, CDs, printers, and Bluetooth devices, effectively preventing data loss and malware infections. By integrating with BitLocker, device control can enforce encryption on removable media, ensuring that sensitive data remains protected even when transferred. You can find those policies at Windows Components\Microsoft Defender Antivirus\Device Control. Dynamic Signature dropped events You can determine whether to report events where dynamic signatures are dropped with the policy Configure whether to report Dynamic Signature dropped events. Dynamic signatures are used to detect and block new and emerging threats. When this policy is enabled, any dropped dynamic signature events are reported, allowing administrators to monitor and investigate why certain threats were not detected or blocked. If you leave it as default or configure this setting to disabled, Dynamic Signature dropped events will not be reported. EDR in block mode Endpoint detection and response (EDR) in block mode, also known as passive remediation, is a feature of Microsoft Defender for Endpoint that provides an additional layer of protection for devices. When enabled, it allows Microsoft Defender Antivirus to take action on post-breach, behavioral detections even if it is not the primary antivirus solution on the device. This means that if the primary antivirus misses a threat, EDR in block mode can step in to block and remediate malicious artifacts, helping to prevent further damage. To learn more, refer to Endpoint detection and response in block mode. Network Protection on Windows Server In Windows Server, network protection is controlled using the registry key AllowNetworkProtectionOnWinServer, which maps to the policy This setting controls whether Network Protection is allowed to be configured into block or audit mode on Windows Server. This policy ensures that users and applications are prevented from accessing dangerous websites by either blocking or auditing their access attempts. On the other hand, Windows client devices use the policy Prevent users and apps from accessing dangerous websites to achieve similar protection. Therefore, for the server baseline, Prevent users and apps from accessing dangerous websites is deprecated, and the policy This setting controls whether Network Protection is allowed to be configured into block or audit mode on Windows Server is set to Block for both domain controllers (DC) and member servers. Real-time protection The policy Configure real-time protection and Security Intelligence Updates during OOBE allows you to configure whether real-time protection and Security Intelligence Updates are enabled before OOBE (out of box experience) is complete. We recommend enabling this setting for both domain controllers and member servers to ensure that the device is secure and protected from the moment it is set up. Run and customize on-demand scans We recommend enabling the policy Scan excluded files and directories during quick scans so that all files and directories that are excluded from real-time protection using contextual exclusions are scanned during a quick scan. SMB and file server Audit capability To enhance the security capabilities of the Server Message Block (SMB) protocol, three new audit policy settings have been introduced in Windows Server 2025. Audit client does not support encryption ensures that the SMB server logs events when an SMB client does not support encryption. Audit client does not support signing enables the SMB server to log events when an SMB client does not support signing Audit insecure guest logon allows the SMB server to log events when a client logs on using a guest account. These new audit policies provide increased logging capabilities, helping to identify and mitigate potential security risks more effectively. We recommend enabling all three settings for both the domain controller and member server. Authentication rate limiter The new policy Enable authentication rate limiter lets you control whether the SMB server will enable or disable the authentication rate limiter. We recommend you enabling this policy. You can set the invalid authentication delay in milliseconds with the policy Set authentication rate limiter delay (milliseconds). The recommended delay value is 2000 milliseconds. Block NTLM To enhance robust protection against NTLM relay attacks while maintaining necessary compatibility with existing systems, two new security policies have been introduced for configuring SMB to block NTLM. These policies align with the ongoing effort to mitigate NTLM Relay Attacks including enabling Extended Protection for Authentication (EPA) and LDAP channel binding by default. Block NTLM provides administrators an option to configure SMB to block NTLM. When enabled, the SMB client will not use NTLM for remote connection authentication, thereby reducing the risk of NTLM-based attack. It’s not enabled by default. Block NTLM Server Exception List allows administrators to specify servers that can still use NTLM for remote connection authentication, even if the Block NTLM policy is enabled. This setting is useful for maintaining compatibility with legacy systems that require NTLM while still enforcing stricter security measures for other connections. To learn more about our effort of enabling NTLM Relay Attacks protection by default, see Mitigating NTLM Relay Attacks by Default | MSRC Blog | Microsoft Security Response Center Manage alternative ports To further enhance the security and flexibility of SMB client connections, Windows Server 2025 introduces new capabilities that allow you to establish SMB client connections using different ports than the well-defined defaults. The two new policies below enable you to manage the alternative ports. Enable Alternative Ports allows administrators to authorize the use of non-standard ports for SMB client communications, providing adaptability to various network configurations and needs while ensuring a robust security posture when needed. Alternative Port Mappings facilitates the detailed specification of alternative port mappings, allowing precise control over which ports and transport types the SMB client can use. Mandate the minimum version of SMB We recommend enforcing the minimum version of SMB to 3.0.0 by setting the policy Mandate the minimum version of SMB. Remote mailslots disabled by default In Windows Server 2025, SMB Remote Mailslots is disabled by default. You can enable it using the policy Enable remote mailslots, which we don’t recommend. Require encryption You can enforce encryption on all SMB clients by setting the policy Require Encryption. If enabled, the SMB client will require the SMB server to support encryption and encrypt the data (SMB 3.0 or later). If you disable or do not configure this policy setting, the SMB client will not require encryption. This policy is combined with per-share, per-server, and per-mapped-drive connection properties through which SMB encryption may be required. The SMB server must support and enable SMB encryption. For example, should this policy be disabled or not configured, the SMB client may still perform encryption if an SMB server share has required encryption. Virtualization Based Security While we don't explicitly enforce the two configurations mentioned below due to potential dependency issues, we highly recommend considering them in audit mode. This approach allows you to evaluate their impact before full enforcement, ensuring that you can leverage our advanced security capabilities without disrupting your existing setup. By doing so, you can enhance your security posture and make informed decisions about implementing these configurations. Machine Identity Isolation Configuration Kernel-mode Hardware-enforced Stack Protection In addition, for the most secure posture, enabling LSA protection with UEFI is the most secure option. However, locking with UEFI adds some dependencies and may cause some compatibility risks. For that reason, we highly recommend evaluating your environment carefully before enabling the policy with UEFI lock. Windows Protected Print Windows Protected Print (WPP) is the new, modern and more secure print for Windows built from the ground up with security in mind. WPP blocks 3 rd party drivers and hardens the entire print stack from attacks. WPP is designed to work with Mopria certified printers. While not yet configured in the security baseline, we recommend you consider the setting Printers\Configure Windows protected print as later versions of the baselines will look to enable this very important feature. You can learn more about the security benefits in our blog post.
