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.Security baseline for Windows Server 2025, version 2506
Microsoft is pleased to announce the June 2025 revision of the security baseline package for Windows Server 2025 (v2506)! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Starting with this release, we plan to revise the Windows Server baseline more frequently to keep pace with evolving threats, new Windows features, and community feedback. Summary of Changes in This Release (v2506) This release includes several changes made since the last release of the security baseline for Windows Server 2025 in January 2025 to further assist in the security of enterprise customers along with better aligning with the latest standards. The changes include what is now depicted in the table below. Security Policy Change Summary Deny log on through Remote Desktop Services Allow remote logon for non-admin local accounts on MS and add “BUILTIN\Guests” to both DC and MS. WDigest Authentication Remove from the baseline Allow Windows Ink Workspace Remove from the baseline Audit Authorization Policy Change Set to “Success” in both DC and MS Include command line in process creation events Enable in both DC and MS Control whether exclusions are visible to local users Moved to Not Configured as it is overridden by the parent setting. Deny log on through Remote Desktop Services We updated SeDenyRemoteInteractiveLogonRight on member servers to use S-1-5-114 (Local account and member of Administrators group) instead of S-1-5-113 (all local accounts) to strike a better balance between security and operational flexibility. This change continues to block remote RDP access for high-risk local admin accounts—our primary threat vector—while enabling legitimate use cases for non-admin local accounts, such as remote troubleshooting and maintenance during failover or domain unavailability. By allowing non-admin local accounts to log on interactively, we preserve a secure recovery path without weakening protection for privileged accounts. In addition, to strengthen the Remote Desktop Services (RDS) posture on both Windows Server 2025 Domain Controllers and Member Servers, we added the Guests group to the "Deny log on through Remote Desktop Services" policy. While the Guest account is disabled by default, explicitly denying its RDP access adds a defense-in-depth measure that helps prevent misuse if the group is ever enabled or misconfigured. This complements the existing restriction on Local Account logon for DCs and helps ensure a consistent security posture across server roles. WDigest Authentication We removed the policy "WDigest Authentication (disabling may require KB2871997)" from the security baseline because it is no longer necessary for Windows Server 2025. This policy was originally enforced to prevent WDigest from storing users plaintext passwords in memory, which posed a serious credential theft risk. However, starting with 24H2 update (KB5041160) for Windows Server 2022 and continuing into Windows Server 2025, the engineering teams have deprecated this policy. As a result, there is no longer a need to explicitly enforce this setting, and the policy has been removed from the baseline to reflect the current default behavior. Allow Windows Ink Workspace We removed the policy “Allow Windows Ink Workspace” from the Windows Server 2025 security baseline. This policy applies only to Windows client editions and is not available on Windows Server. Including it in the baseline caused confusion removing an unnecessary setting from the baseline reduces GPO processing time and helps ensure all recommended settings are applicable for the Windows Server environment. Audit Authorization Policy Change We set Audit Authorization Policy Change (Success) on the baseline for both Domain Controllers and Member Servers to ensure visibility into any changes that affect the system’s security posture, including modifications to user rights and audit policies. These changes directly impact how access is granted and how activity is monitored, making them critical to detect for both security and compliance purposes. Logging successful changes helps identify misconfigurations, unauthorized privilege assignments, or malicious tampering — especially in cases of lateral movement or privilege escalation. Because these events occur infrequently, they generate minimal log volume while offering high forensic and operational value. While Failure auditing is not set, it is available as an optional setting on both Domain Controllers and Member Servers for organizations that have the monitoring capability to interpret and act on failed attempts to modify security policies. This provides an added layer of visibility in high-assurance or tightly controlled environments. Include command line in process creation events We added Include command line in process creation events in the baseline to improve visibility into how processes are executed across the system. Capturing command-line arguments allows defenders to detect and investigate malicious activity that may otherwise appear legitimate, such as abuse of scripting engines, credential theft tools, or obfuscated payloads using native binaries. This setting supports modern threat detection techniques with minimal performance overhead and is widely recommended. Visibility of Microsoft Defender Antivirus Exclusions We updated the configuration for the policy "Control whether exclusions are visible to local users" (Computer Configuration\Windows Components\Microsoft Defender Antivirus) to Not Configured in this release. This change was made because the parent policy "Control whether or not exclusions are visible to Local Admins" is already set to Enabled, which takes precedence and effectively overrides the behavior of the former setting. As a result, explicitly configuring the child policy is unnecessary and may introduce confusion without impacting actual behavior. You can continue to manage exclusion visibility through the parent policy, which provides the intended control over whether local administrators can view exclusion lists. UEFI Lock and Virtualization-Based Protections In Windows, some security features are protected by Secure Boot and the TPM. When combined with firmware protections that lock UEFI configuration variables, these protections become tamper-resistant: Windows can detect and respond to unauthorized hardware changes or tamper attempts, making it significantly harder for attackers to disable key security features after deployment. In the Windows Server 2025 security baseline, two policy categories are configured to take advantage of UEFI lock: Virtualization-Based Security (VBS) — managed via the policy: System\Device Guard\Turn On Virtualization Based Security Local Security Authority (LSA) Protection — managed via the policy: System\Local Security Authority\Configure LSASS to run as a protected process While there are no changes to the recommended settings for these policies in this release, we want to highlight their role in strengthening system defenses and provide guidance to help you make informed deployment decisions. UEFI lock enforces these protections in a way that prevents local or remote tampering—even by administrators. This aligns with strong security requirements in sensitive or high-assurance environments. However, it also introduces important operational considerations: Some hardware platforms may not fully support UEFI lock Compatibility issues, reduced performance, or system instability may occur Once enabled, UEFI lock is difficult to reverse Please let us know your thoughts by commenting on this post or through the Security Baseline Community.
