diff --git a/windows/security/threat-protection/security-policy-settings/TOC.yml b/windows/security/threat-protection/security-policy-settings/TOC.yml deleted file mode 100644 index df9030461f..0000000000 --- a/windows/security/threat-protection/security-policy-settings/TOC.yml +++ /dev/null @@ -1,345 +0,0 @@ - - name: Security policy settings - href: security-policy-settings.md - items: - - name: Administer security policy settings - href: administer-security-policy-settings.md - items: - - name: Network List Manager policies - href: network-list-manager-policies.md - - name: Configure security policy settings - href: how-to-configure-security-policy-settings.md - - name: Security policy settings reference - href: security-policy-settings-reference.md - items: - - name: Account Policies - href: account-policies.md - items: - - name: Password Policy - href: password-policy.md - items: - - name: Enforce password history - href: enforce-password-history.md - - name: Maximum password age - href: maximum-password-age.md - - name: Minimum password age - href: minimum-password-age.md - - name: Minimum password length - href: minimum-password-length.md - - name: Password must meet complexity requirements - href: password-must-meet-complexity-requirements.md - - name: Store passwords using reversible encryption - href: store-passwords-using-reversible-encryption.md - - name: Account Lockout Policy - href: account-lockout-policy.md - items: - - name: Account lockout duration - href: account-lockout-duration.md - - name: Account lockout threshold - href: account-lockout-threshold.md - - name: Reset account lockout counter after - href: reset-account-lockout-counter-after.md - - name: Kerberos Policy - href: kerberos-policy.md - items: - - name: Enforce user logon restrictions - href: enforce-user-logon-restrictions.md - - name: Maximum lifetime for service ticket - href: maximum-lifetime-for-service-ticket.md - - name: Maximum lifetime for user ticket - href: maximum-lifetime-for-user-ticket.md - - name: Maximum lifetime for user ticket renewal - href: maximum-lifetime-for-user-ticket-renewal.md - - name: Maximum tolerance for computer clock synchronization - href: maximum-tolerance-for-computer-clock-synchronization.md - - name: Audit Policy - href: audit-policy.md - - name: Security Options - href: security-options.md - items: - - name: "Accounts: Administrator account status" - href: accounts-administrator-account-status.md - - name: "Accounts: Block Microsoft accounts" - href: accounts-block-microsoft-accounts.md - - name: "Accounts: Guest account status" - href: accounts-guest-account-status.md - - name: "Accounts: Limit local account use of blank passwords to console logon only" - href: accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md - - name: "Accounts: Rename administrator account" - href: accounts-rename-administrator-account.md - - name: "Accounts: Rename guest account" - href: accounts-rename-guest-account.md - - name: "Audit: Audit the access of global system objects" - href: audit-audit-the-access-of-global-system-objects.md - - name: "Audit: Audit the use of Backup and Restore privilege" - href: audit-audit-the-use-of-backup-and-restore-privilege.md - - name: "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" - href: audit-force-audit-policy-subcategory-settings-to-override.md - - name: "Audit: Shut down system immediately if unable to log security audits" - href: audit-shut-down-system-immediately-if-unable-to-log-security-audits.md - - name: "DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax" - href: dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md - - name: "DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax" - href: dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md - - name: "Devices: Allow undock without having to log on" - href: devices-allow-undock-without-having-to-log-on.md - - name: "Devices: Allowed to format and eject removable media" - href: devices-allowed-to-format-and-eject-removable-media.md - - name: "Devices: Prevent users from installing printer drivers" - href: devices-prevent-users-from-installing-printer-drivers.md - - name: "Devices: Restrict CD-ROM access to locally logged-on user only" - href: devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md - - name: "Devices: Restrict floppy access to locally logged-on user only" - href: devices-restrict-floppy-access-to-locally-logged-on-user-only.md - - name: "Domain controller: Allow server operators to schedule tasks" - href: domain-controller-allow-server-operators-to-schedule-tasks.md - - name: "Domain controller: LDAP server channel binding token requirements" - href: domain-controller-ldap-server-channel-binding-token-requirements.md - - name: "Domain controller: LDAP server signing requirements" - href: domain-controller-ldap-server-signing-requirements.md - - name: "Domain controller: Refuse machine account password changes" - href: domain-controller-refuse-machine-account-password-changes.md - - name: "Domain member: Digitally encrypt or sign secure channel data (always)" - href: domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md - - name: "Domain member: Digitally encrypt secure channel data (when possible)" - href: domain-member-digitally-encrypt-secure-channel-data-when-possible.md - - name: "Domain member: Digitally sign secure channel data (when possible)" - href: domain-member-digitally-sign-secure-channel-data-when-possible.md - - name: "Domain member: Disable machine account password changes" - href: domain-member-disable-machine-account-password-changes.md - - name: "Domain member: Maximum machine account password age" - href: domain-member-maximum-machine-account-password-age.md - - name: "Domain member: Require strong (Windows 2000 or later) session key" - href: domain-member-require-strong-windows-2000-or-later-session-key.md - - name: "Interactive logon: Display user information when the session is locked" - href: interactive-logon-display-user-information-when-the-session-is-locked.md - - name: "Interactive logon: Don't display last signed-in" - href: interactive-logon-do-not-display-last-user-name.md - - name: "Interactive logon: Don't display username at sign-in" - href: interactive-logon-dont-display-username-at-sign-in.md - - name: "Interactive logon: Do not require CTRL+ALT+DEL" - href: interactive-logon-do-not-require-ctrl-alt-del.md - - name: "Interactive logon: Machine account lockout threshold" - href: interactive-logon-machine-account-lockout-threshold.md - - name: "Interactive logon: Machine inactivity limit" - href: interactive-logon-machine-inactivity-limit.md - - name: "Interactive logon: Message text for users attempting to log on" - href: interactive-logon-message-text-for-users-attempting-to-log-on.md - - name: "Interactive logon: Message title for users attempting to log on" - href: interactive-logon-message-title-for-users-attempting-to-log-on.md - - name: "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" - href: interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md - - name: "Interactive logon: Prompt user to change password before expiration" - href: interactive-logon-prompt-user-to-change-password-before-expiration.md - - name: "Interactive logon: Require Domain Controller authentication to unlock workstation" - href: interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md - - name: "Interactive logon: Require smart card" - href: interactive-logon-require-smart-card.md - - name: "Interactive logon: Smart card removal behavior" - href: interactive-logon-smart-card-removal-behavior.md - - name: "Microsoft network client: Digitally sign communications (always)" - href: microsoft-network-client-digitally-sign-communications-always.md - - name: "Microsoft network client: Send unencrypted password to third-party SMB servers" - href: microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md - - name: "Microsoft network server: Amount of idle time required before suspending session" - href: microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md - - name: "Microsoft network server: Attempt S4U2Self to obtain claim information" - href: microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md - - name: "Microsoft network server: Digitally sign communications (always)" - href: microsoft-network-server-digitally-sign-communications-always.md - - name: "Microsoft network server: Disconnect clients when logon hours expire" - href: microsoft-network-server-disconnect-clients-when-logon-hours-expire.md - - name: "Microsoft network server: Server SPN target name validation level" - href: microsoft-network-server-server-spn-target-name-validation-level.md - - name: "Network access: Allow anonymous SID/Name translation" - href: network-access-allow-anonymous-sidname-translation.md - - name: "Network access: Do not allow anonymous enumeration of SAM accounts" - href: network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md - - name: "Network access: Do not allow anonymous enumeration of SAM accounts and shares" - href: network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md - - name: "Network access: Do not allow storage of passwords and credentials for network authentication" - href: network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md - - name: "Network access: Let Everyone permissions apply to anonymous users" - href: network-access-let-everyone-permissions-apply-to-anonymous-users.md - - name: "Network access: Named Pipes that can be accessed anonymously" - href: network-access-named-pipes-that-can-be-accessed-anonymously.md - - name: "Network access: Remotely accessible registry paths" - href: network-access-remotely-accessible-registry-paths.md - - name: "Network access: Remotely accessible registry paths and subpaths" - href: network-access-remotely-accessible-registry-paths-and-subpaths.md - - name: "Network access: Restrict anonymous access to Named Pipes and Shares" - href: network-access-restrict-anonymous-access-to-named-pipes-and-shares.md - - name: "Network access: Restrict clients allowed to make remote calls to SAM" - href: network-access-restrict-clients-allowed-to-make-remote-sam-calls.md - - name: "Network access: Shares that can be accessed anonymously" - href: network-access-shares-that-can-be-accessed-anonymously.md - - name: "Network access: Sharing and security model for local accounts" - href: network-access-sharing-and-security-model-for-local-accounts.md - - name: "Network security: Allow Local System to use computer identity for NTLM" - href: network-security-allow-local-system-to-use-computer-identity-for-ntlm.md - - name: "Network security: Allow LocalSystem NULL session fallback" - href: network-security-allow-localsystem-null-session-fallback.md - - name: "Network security: Allow PKU2U authentication requests to this computer to use online identities" - href: network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md - - name: "Network security: Configure encryption types allowed for Kerberos" - href: network-security-configure-encryption-types-allowed-for-kerberos.md - - name: "Network security: Do not store LAN Manager hash value on next password change" - href: network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md - - name: "Network security: Force logoff when logon hours expire" - href: network-security-force-logoff-when-logon-hours-expire.md - - name: "Network security: LAN Manager authentication level" - href: network-security-lan-manager-authentication-level.md - - name: "Network security: LDAP client signing requirements" - href: network-security-ldap-client-signing-requirements.md - - name: "Network security: Minimum session security for NTLM SSP based (including secure RPC) clients" - href: network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md - - name: "Network security: Minimum session security for NTLM SSP based (including secure RPC) servers" - href: network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md - - name: "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication" - href: network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md - - name: "Network security: Restrict NTLM: Add server exceptions in this domain" - href: network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md - - name: "Network security: Restrict NTLM: Audit incoming NTLM traffic" - href: network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md - - name: "Network security: Restrict NTLM: Audit NTLM authentication in this domain" - href: network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md - - name: "Network security: Restrict NTLM: Incoming NTLM traffic" - href: network-security-restrict-ntlm-incoming-ntlm-traffic.md - - name: "Network security: Restrict NTLM: NTLM authentication in this domain" - href: network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md - - name: "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" - href: network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md - - name: "Recovery console: Allow automatic administrative logon" - href: recovery-console-allow-automatic-administrative-logon.md - - name: "Recovery console: Allow floppy copy and access to all drives and folders" - href: recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md - - name: "Shutdown: Allow system to be shut down without having to log on" - href: shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md - - name: "Shutdown: Clear virtual memory pagefile" - href: shutdown-clear-virtual-memory-pagefile.md - - name: "System cryptography: Force strong key protection for user keys stored on the computer" - href: system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md - - name: "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" - href: system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md - - name: "System objects: Require case insensitivity for non-Windows subsystems" - href: system-objects-require-case-insensitivity-for-non-windows-subsystems.md - - name: "System objects: Strengthen default permissions of internal system objects (Symbolic Links)" - href: system-objects-strengthen-default-permissions-of-internal-system-objects.md - - name: "System settings: Optional subsystems" - href: system-settings-optional-subsystems.md - - name: "System settings: Use certificate rules on Windows executables for Software Restriction Policies" - href: system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md - - name: "User Account Control: Admin Approval Mode for the Built-in Administrator account" - href: user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md - - name: "User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop" - href: user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md - - name: "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" - href: user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md - - name: "User Account Control: Behavior of the elevation prompt for standard users" - href: user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md - - name: "User Account Control: Detect application installations and prompt for elevation" - href: user-account-control-detect-application-installations-and-prompt-for-elevation.md - - name: "User Account Control: Only elevate executables that are signed and validated" - href: user-account-control-only-elevate-executables-that-are-signed-and-validated.md - - name: "User Account Control: Only elevate UIAccess applications that are installed in secure locations" - href: user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md - - name: "User Account Control: Run all administrators in Admin Approval Mode" - href: user-account-control-run-all-administrators-in-admin-approval-mode.md - - name: "User Account Control: Switch to the secure desktop when prompting for elevation" - href: user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md - - name: "User Account Control: Virtualize file and registry write failures to per-user locations" - href: user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md - - name: Advanced security audit policy settings - href: secpol-advanced-security-audit-policy-settings.md - - name: User Rights Assignment - href: user-rights-assignment.md - items: - - name: Access Credential Manager as a trusted caller - href: access-credential-manager-as-a-trusted-caller.md - - name: Access this computer from the network - href: access-this-computer-from-the-network.md - - name: Act as part of the operating system - href: act-as-part-of-the-operating-system.md - - name: Add workstations to domain - href: add-workstations-to-domain.md - - name: Adjust memory quotas for a process - href: adjust-memory-quotas-for-a-process.md - - name: Allow log on locally - href: allow-log-on-locally.md - - name: Allow log on through Remote Desktop Services - href: allow-log-on-through-remote-desktop-services.md - - name: Back up files and directories - href: back-up-files-and-directories.md - - name: Bypass traverse checking - href: bypass-traverse-checking.md - - name: Change the system time - href: change-the-system-time.md - - name: Change the time zone - href: change-the-time-zone.md - - name: Create a pagefile - href: create-a-pagefile.md - - name: Create a token object - href: create-a-token-object.md - - name: Create global objects - href: create-global-objects.md - - name: Create permanent shared objects - href: create-permanent-shared-objects.md - - name: Create symbolic links - href: create-symbolic-links.md - - name: Debug programs - href: debug-programs.md - - name: Deny access to this computer from the network - href: deny-access-to-this-computer-from-the-network.md - - name: Deny log on as a batch job - href: deny-log-on-as-a-batch-job.md - - name: Deny log on as a service - href: deny-log-on-as-a-service.md - - name: Deny log on locally - href: deny-log-on-locally.md - - name: Deny log on through Remote Desktop Services - href: deny-log-on-through-remote-desktop-services.md - - name: Enable computer and user accounts to be trusted for delegation - href: enable-computer-and-user-accounts-to-be-trusted-for-delegation.md - - name: Force shutdown from a remote system - href: force-shutdown-from-a-remote-system.md - - name: Generate security audits - href: generate-security-audits.md - - name: Impersonate a client after authentication - href: impersonate-a-client-after-authentication.md - - name: Increase a process working set - href: increase-a-process-working-set.md - - name: Increase scheduling priority - href: increase-scheduling-priority.md - - name: Load and unload device drivers - href: load-and-unload-device-drivers.md - - name: Lock pages in memory - href: lock-pages-in-memory.md - - name: Log on as a batch job - href: log-on-as-a-batch-job.md - - name: Log on as a service - href: log-on-as-a-service.md - - name: Manage auditing and security log - href: manage-auditing-and-security-log.md - - name: Modify an object label - href: modify-an-object-label.md - - name: Modify firmware environment values - href: modify-firmware-environment-values.md - - name: Perform volume maintenance tasks - href: perform-volume-maintenance-tasks.md - - name: Profile single process - href: profile-single-process.md - - name: Profile system performance - href: profile-system-performance.md - - name: Remove computer from docking station - href: remove-computer-from-docking-station.md - - name: Replace a process level token - href: replace-a-process-level-token.md - - name: Restore files and directories - href: restore-files-and-directories.md - - name: Shut down the system - href: shut-down-the-system.md - - name: Synchronize directory service data - href: synchronize-directory-service-data.md - - name: Take ownership of files or other objects - href: take-ownership-of-files-or-other-objects.md - - name: Windows security - href: /windows/security/ \ No newline at end of file diff --git a/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md b/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md deleted file mode 100644 index 61b895b145..0000000000 --- a/windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Access Credential Manager as a trusted caller -description: Describes best practices, security considerations, and more for the security policy setting, Access Credential Manager as a trusted caller. -ms.assetid: a51820d2-ca5b-47dd-8e9b-d7008603db88 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Access Credential Manager as a trusted caller - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Access Credential Manager as a trusted caller** security policy setting. - -## Reference - -The **Access Credential Manager as a trusted caller** policy setting is used by Credential Manager during backup and restore. No accounts should have this privilege because it's assigned only to the Winlogon service. Saved credentials of users may be compromised if this privilege is given to other entities. - -Constant: SeTrustedCredManAccessPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- Don't modify this policy setting from the default. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table shows the default value for the server type or Group Policy Object (GPO). - -| Server type or GPO | Default value | -| - | - | -| Default domain policy | Not defined | -| Default domain controller policy | Not defined | -| Stand-alone server default settings | Not defined | -| Domain controller effective default settings | Not defined | -| Member server effective default settings | Not defined | -| Client computer effective default settings | Not defined | - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If an account is given this user right, the user of the account may create an application that calls into Credential Manager and is returned the credentials for another user. - -### Countermeasure - -Don't define the **Access Credential Manager as a trusted caller** policy setting for any accounts besides Credential Manager. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics -[User Rights Assignment](user-rights-assignment.md) - diff --git a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md deleted file mode 100644 index 58ab435398..0000000000 --- a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Access this computer from the network - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Access this computer from the network security policy setting. -ms.assetid: f6767bc2-83d1-45f1-847c-54f5362db022 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 06/11/2021 ---- - -# Access this computer from the network - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 -- Windows Server 2022 -- Windows Server 2019 -- Windows Server 2016 -- Azure Stack HCI - -Describes the best practices, location, values, policy management, and security considerations for the **Access this computer from the network** security policy setting. - -> [!WARNING] -> If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the **Access this computer from the network** policy setting. Doing so may induce an unexpected production outage. This is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR is not a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly. - -## Reference - -The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by many network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+). - -Users, devices, and service accounts gain or lose the **Access this computer from network** user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers. -By default, user accounts and machine accounts are granted the **Access this computer from network** user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO). - -Constant: SeNetworkLogonRight - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- On desktop devices or member servers, grant this right only to users and administrators. -- On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators. -- On failover clusters, make sure this right is granted to authenticated users. -- This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you've verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -|Server type of GPO | Default value | -| - | - | -| Default domain policy | Not defined | -| Default domain controller policy | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access | -| Stand-alone server default settings |Everyone, Administrators, Users, Backup Operators | -| Domain controller effective default settings | Everyone, Administrators, Authenticated Users, Enterprise Domain Controllers, Pre-Windows 2000 Compatible Access | -| Member server effective default settings | Everyone, Administrators, Users, Backup Operators | -| Client computer effective default settings |Everyone, Administrators, Users, Backup Operators | - -## Policy management - -When you modify this user right, the following actions might cause users and services to experience network access issues: - -- Removing the Enterprise Domain Controllers security group -- Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network -- Removing all user and machine accounts - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the **Access this computer from the network** user right is required for users to connect to shared printers and folders. If this user right is assigned to the **Everyone** group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 don't include the **Everyone** group. However, if a device is upgraded and the original device includes the **Everyone** group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device. - -### Countermeasure - -Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who sign in to the domain can access resources that are shared -from servers in the domain if members of the **Domain Users** group are included in the local **Users** group. - -> **Note** If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement. - -### Potential impact - -If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can sign in to the domain or use network resources. If you remove this user right on member servers, users can't connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to other accounts that are required by those components. It's important to verify that authorized users are assigned this user right for the devices that they need to access the network. - -If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This outage is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR isn't a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly. - -## Related topics -[User Rights Assignment](user-rights-assignment.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md b/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md deleted file mode 100644 index 23acbe9b1c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Account lockout duration -description: Describes the best practices, location, values, and security considerations for the Account lockout duration security policy setting. -ms.assetid: a4167bf4-27c3-4a9b-8ef0-04e3c6ec3aa4 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 08/16/2021 ---- - -# Account lockout duration - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. - -## Reference - -The **Account lockout duration** policy setting determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md). -This policy setting is dependent on the **Account lockout threshold** policy setting that is defined, and it must be greater than or equal to the value specified for the [Reset account lockout counter after](reset-account-lockout-counter-after.md) policy setting. - -### Possible values - -- A user-defined number of minutes from 0 through 99,999 -- Not defined - -If [Account lockout threshold](account-lockout-threshold.md) is configured, after the specified number of failed attempts, the account will be locked out. If the **Account lockout duration** is set to 0, the account will remain locked until an administrator unlocks it manually. - -It's advisable to set **Account lockout duration** to approximately 15 minutes. To specify that the account will never be locked out, set the **Account lockout threshold** value to 0. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy | Not defined | -| Default domain controller policy | Not defined | -| Stand-alone server default settings | Not applicable | -| Domain controller effective default settings | Not defined | -| Member server effective default settings | Not defined | -| Client computer effective default settings | Not applicable | - -## Security considerations - -More than a few unsuccessful password submissions during an attempt to sign in to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track sign-in attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached. - -### Vulnerability - -A denial-of-service (DoS) condition can be created if an attacker abuses the [Account lockout threshold](account-lockout-threshold.md) policy setting and repeatedly attempts to sign in with a specific account. After you configure the Account lockout threshold policy setting, the account will be locked out after the specified number of failed attempts. If you configure the **Account lockout duration** policy setting to 0, the account remains locked until you unlock it manually. - -### Countermeasure - -Configure the **Account lockout duration** policy setting to an appropriate value for your environment. To specify that the account will remain locked until you manually unlock it, configure the value to 0. When the **Account lockout duration** policy setting is configured to a nonzero value, automated attempts to guess account passwords are delayed for this interval before resuming attempts against a specific account. Using this setting in combination with the [Account lockout threshold](account-lockout-threshold.md) policy setting makes automated password guessing attempts more difficult. - -### Potential impact - -Configuring the **Account lockout duration** policy setting to 0 so that accounts can't be automatically unlocked can increase the number of requests that your organization's Help Desk receives to unlock accounts that were locked by mistake. - -## Related topics - -[Account Lockout Policy](account-lockout-policy.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-policy.md b/windows/security/threat-protection/security-policy-settings/account-lockout-policy.md deleted file mode 100644 index 25df645272..0000000000 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-policy.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Account Lockout Policy -description: Describes the Account Lockout Policy settings and links to information about each policy setting. -ms.assetid: eb968c28-17c5-405f-b413-50728cb7b724 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 10/11/2018 ---- - -# Account Lockout Policy - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the Account Lockout Policy settings and links to information about each policy setting. - -Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system might be a malicious user who is attempting to determine an account password by trial and error. Windows domain controllers keep track of logon attempts, and domain controllers can be configured to respond to this type of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the threshold for this response and the actions to be taken after the threshold is reached. The Account Lockout Policy settings can be configured in the following location in the Group Policy Management Console: **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy**. - -The following topics provide a discussion of each policy setting's implementation and best practices considerations, policy location, default values for the server type or Group Policy Object (GPO), relevant differences in operating system versions, and security considerations (including the possible vulnerabilities of each policy setting), countermeasures that you can implement, and the potential impact of implementing the countermeasures. - ->[!NOTE] ->Account lockout settings for remote access clients can be configured separately by editing the Registry on the server that manages the remote access. For more information, see [How to configure remote access client account lockout](/troubleshoot/windows-server/networking/configure-remote-access-client-account-lockout). - -[!INCLUDE [account-lockout-policy](../../../../includes/licensing/account-lockout-policy.md)] - -## In this section - -| Topic | Description | -| - | - | -| [Account lockout threshold](account-lockout-threshold.md) | Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. | -| [Account lockout duration](account-lockout-duration.md) | Describes the best practices, location, values, and security considerations for the **Account lockout duration** security policy setting. | -| [Reset account lockout counter after](reset-account-lockout-counter-after.md) | Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting. | - -## Related topics - -[Configure security policy settings](how-to-configure-security-policy-settings.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md deleted file mode 100644 index 7902e5d1c9..0000000000 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Account lockout threshold -description: Describes the best practices, location, values, and security considerations for the Account lockout threshold security policy setting. -ms.assetid: 4904bb40-a2bd-4fef-a102-260ba8d74e30 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 11/02/2018 ---- - -# Account lockout threshold - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Account lockout threshold** security policy setting. - -## Reference - -The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account can't be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md). - -Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks. -However, it's important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account. - -Failed attempts to unlock a workstation can cause account lockout even if the [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) security option is disabled. Windows doesn't need to contact a domain controller for an unlock if you enter the same password that you logged on with, but if you enter a different password, Windows has to contact a domain controller in case you had changed your password from another machine. - -### Possible values - -It's possible to configure the following values for the **Account lockout threshold** policy setting: -- A user-defined number from 0 through 999 -- Not defined - -Because vulnerabilities can exist when this value is configured and when it's not, organizations should weigh their identified threats and the risks that they're trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this article. - -### Best practices - -The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, [Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) recommend a value of 10 could be an acceptable starting point for your organization. - -As with other account lockout settings, this value is more of a guideline than a rule or best practice because there's no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout). - -Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this article. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the property page for the policy setting. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy | 0 invalid sign-in attempts | -| Default domain controller policy | Not defined | -| Stand-alone server default settings | 0 invalid sign-in attempts | -| Domain controller effective default settings | 0 invalid sign-in attempts | -| Member server effective default settings |0 invalid sign-in attempts | -| Effective GPO default settings on client computers |0 invalid sign-in attempts | - -### Policy management - -This section describes features and tools that are available to help you manage this policy setting. - -### Restart requirements - -None. Changes to this policy setting become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Implementation considerations - -Implementation of this policy setting depends on your operational environment. Consider threat vectors, deployed operating systems, and deployed apps. For example: - -- The likelihood of an account theft or a DoS attack is based on the security design for your systems and environment. Set the account lockout threshold in consideration of the known and perceived risk of those threats. - -- When there's a negotiation of encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases. - -- Not all apps that are used in your environment effectively manage how many times a user can attempt to sign in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold. - -For more information about Windows security baseline recommendations for account lockout, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -> [!NOTE] -> A lockout threshold policy will apply to both local member computer users and domain users, in order to allow mitigation of issues as described under "Vulnerability". The built-in Administrator account, however, whilst a highly privileged account, has a different risk profile and is excluded from this policy. This ensures there is no scenario where an administrator cannot sign in to remediate an issue. As an administrator, there are additional mitigation strategies available, such as a strong password. See also [Appendix D: Securing Built-In Administrator Accounts in Active Directory](/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d--securing-built-in-administrator-accounts-in-active-directory). - -### Vulnerability - -Brute force password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed sign-in attempts that can be performed. -However, a DoS attack could be performed on a domain that has an account lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker might be able to lock every account without needing any special privileges or being authenticated in the network. - -> [!NOTE] -> Offline password attacks are not countered by this policy setting. - - -### Countermeasure - -Because vulnerabilities can exist when this value is configured and when it's not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are: - -- Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts won't be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users can't accidentally lock themselves out of their accounts. Because it doesn't prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met: - - - The password policy setting requires all users to have complex passwords of eight or more characters. - - A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occurs in the environment. - -- Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account. - - [Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but doesn't prevent a DoS attack. - - Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it's needed to help mitigate massive lockouts caused by an attack on your systems. - -### Potential impact - -If this policy setting is enabled, a locked account isn't usable until it's reset by an administrator or until the account lockout duration expires. Enabling this setting will likely generate many more Help Desk calls. - -If you configure the **Account lockout threshold** policy setting to 0, there's a possibility that a malicious user's attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism isn't in place. - -If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which the account name is known. This situation is especially dangerous considering that no credentials other than access to the network are necessary to lock the accounts. - -## Related topics -[Account Lockout Policy](account-lockout-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/account-policies.md b/windows/security/threat-protection/security-policy-settings/account-policies.md deleted file mode 100644 index 979811c1da..0000000000 --- a/windows/security/threat-protection/security-policy-settings/account-policies.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Account Policies -description: An overview of account policies in Windows and provides links to policy descriptions. -ms.assetid: 711b3797-b87a-4cd9-a2e3-1f8ef18688fb -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Account Policies - -**Applies to** -- Windows 11 -- Windows 10 - -An overview of account policies in Windows and provides links to policy descriptions. - -All account policies settings applied by using Group Policy are applied at the domain level. Default values are present in the built-in default domain controller policy for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain account policy becomes the default local account policy of any device that is a member of the domain. If these policies are set at any level below the domain level in Active Directory Domain Services (AD DS), they affect only local accounts on member servers. -> [!NOTE] -> Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO). - -The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users sign in to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where both an OU account policy and a domain policy don't apply. - -## In this section - -| Topic | Description | -| - | - | -| [Password Policy](password-policy.md) | An overview of password policies for Windows and links to information for each policy setting. | -| [Account Lockout Policy](account-lockout-policy.md) | Describes the Account Lockout Policy settings and links to information about each policy setting. | -| [Kerberos Policy](kerberos-policy.md) | Describes the Kerberos Policy settings and provides links to policy setting descriptions. | - -## Related topics - -[Configure security policy settings](how-to-configure-security-policy-settings.md) diff --git a/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md b/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md deleted file mode 100644 index 2525359221..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Accounts Administrator account status -description: Describes the best practices, location, values, and security considerations for the Accounts Administrator account status security policy setting. -ms.assetid: 71a3bd48-1014-49e0-a936-bfe9433af23e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 08/01/2017 ---- - -# Accounts: Administrator account status - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting. - -## Reference - -This security setting determines whether the local Administrator account is enabled or disabled. - -The following conditions prevent disabling the Administrator account, even if this security setting is disabled. - -1. The Administrator account is currently in use -2. The Administrators group has no other members -3. All other members of the Administrators group are: - 1. Disabled - 2. Listed in the [Deny log on locally](deny-log-on-locally.md) User Rights Assignment - -If the Administrator account is disabled, you can't enable it if the password doesn't meet requirements. In this case, another member of the Administrators group must reset the password. - -### Possible values -- Enabled -- Disabled -- Not defined - -By default, this setting is **Not defined** on domain controllers and **Enabled** on stand-alone servers. - -### Best practices - -- Disabling the administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there's no other local administrator account, you must restart the computer in safe mode to fix the problem that broke your connection status. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy |Not defined | -| Stand-Alone Server Default Settings | Enabled | -| DC Effective Default Settings | Enabled | -| Member Server Effective Default Settings | Enabled | -| Client Computer Effective Default Settings | Disabled | - -  -## Policy management - -Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an organization might consider disabling the built-in administrator account include: - -- For some organizations, periodically changing the passwords for local accounts can be a daunting management challenge. -- By default, the administrator account can't be locked—no matter how many failed attempts to sign in a user accrue. This open state of the account makes it a prime target for brute-force, password-guessing attacks. -- This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This authentication approach means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Safe mode considerations - -When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. In this case, you can access the computer by using safe mode with the current administrative credentials. If the computer is joined to a domain, the disabled administrator account isn't enabled. - -### How to access a disabled Administrator account - -You can use the following methods to access a disabled Administrator account: -- For non-domain joined computers: when all the local administrator accounts are disabled, start the device in safe mode (locally or over a network), and sign in by using the credentials for the default local administrator account on that computer. -- For domain-joined computers: remotely run the command **net user administrator /active: yes** by using psexec to enable the default local administrator account. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The built-in administrator account can't be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to sign in. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum. - -### Countermeasure - -Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account can't be used in a normal system startup. -If it's difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack. - -### Potential impact - -Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there's no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail. -If the current administrator password doesn't meet the password requirements, you can't enable the administrator account after it's disabled. If this situation occurs, another member of the administrators' group must set the password on the administrator account. - -## Related topics - -[Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md b/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md deleted file mode 100644 index 63a3b327b9..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Accounts Block Microsoft accounts -description: Describes the best practices, location, values, management, and security considerations for the Accounts Block Microsoft accounts security policy setting. -ms.assetid: 94c76f45-057c-4d80-8d01-033cf28ef2f7 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 08/10/2017 ---- - -# Accounts: Block Microsoft accounts - -**Applies to** -- Windows 10, version 1607 and earlier - -Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting. - -> [!IMPORTANT] -> In Windows 10, version 1703 and later, this policy is no longer effective because the process for adding Microsoft Accounts changed. For Windows 10, version 1703 and later, instead of using this policy use the "Block all consumer Microsoft user account authentication" policy located under Computer Configuration\Administrative Templates\Windows Components\Microsoft account. - -## Reference - -This setting prevents using the **Settings** app to add a Microsoft account for single sign-on (SSO) authentication for Microsoft services and some background services, or using a Microsoft account for single sign-on to other applications or services. For more information, see [Microsoft Accounts](/windows-server/identity/ad-ds/manage/understand-microsoft-accounts). - -There are two options if this setting is enabled: - -- **Users can’t add Microsoft accounts** means that existing connected accounts can still sign in to the device (and appear on the sign-in screen). However, users can't use the **Settings** app to add new connected accounts (or connect local accounts to Microsoft accounts). - -- **Users can’t add or log on with Microsoft accounts** means that users can't add new connected accounts (or connect local accounts to Microsoft accounts) or use existing connected accounts through **Settings**. - -If you disable or don't configure this policy (recommended), users will be able to use Microsoft accounts with Windows. - -### Possible values -- This policy is disabled -- Users can’t add Microsoft accounts -- Users can’t add or sign in with Microsoft accounts - -By default, this setting isn't defined on domain controllers and disabled on stand-alone servers. - -### Best practices - -- If this policy setting is disabled or isn't configured on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This ability to connect provides a convenient option for your users. -- If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users won't be able to use the **Settings** app to add new connected accounts. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure implementation. - -### Vulnerability - -Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of the enterprise. Additionally, if the owner of a Microsoft account isn't easily distinguishable, auditing and forensics become more difficult. - -### Countermeasure - -Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the **Users can’t add Microsoft accounts** setting option so that users won't be able to create new Microsoft accounts on a device, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. - -### Potential impact - -Establishing greater control over accounts in your organization can give you more secure management capabilities, including procedures around password resets. - -## Related topics - -[Security Options](security-options.md) - diff --git a/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md b/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md deleted file mode 100644 index a61f1e0d49..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Accounts Guest account status - security policy setting -description: Describes the best practices, location, values, and security considerations for the Accounts Guest account status security policy setting. -ms.assetid: 07e53fc5-b495-4d02-ab42-5b245d10d0ce -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Accounts: Guest account status - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting. - -## Reference - -The **Accounts: Guest account status** policy setting determines whether the Guest account is enabled or disabled. -This account allows unauthenticated network users to gain access to the system by signing in as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This privilege means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This accessibility can lead to the exposure or corruption of data. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -Set **Accounts: Guest account status** to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md) is set to **Guest only**, network logons—such as those logons performed by the SMB Service—will fail. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled | - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The default Guest account allows unauthenticated network users to sign in as a Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data. - -### Countermeasure - -Disable the **Accounts: Guest account status** setting so that the built-in Guest account can't be used. - -### Potential impact - -All network users must be authenticated before they can access shared resources. If you disable the Guest account and the **Network Access: Sharing and Security Model** option is set to **Guest Only**, network logons, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it's the default setting starting with Windows Vista and Windows Server 2003. - -## Related topics - -[Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md b/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md deleted file mode 100644 index a04536f260..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Accounts Limit local account use of blank passwords -description: Learn best practices, security considerations, and more for the policy setting, Accounts Limit local account use of blank passwords to console logon only. -ms.assetid: a1bfb58b-1ae8-4de9-832b-aa889a6e64bd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Accounts: Limit local account use of blank passwords to console logon only - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting. - -## Reference - -The **Accounts: Limit local account use of blank passwords to console logon only** policy setting determines whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client. - -This policy setting doesn't affect interactive logons that are performed physically at the console or logons that use domain accounts. It's possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting. -Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to sign in to systems. - -Devices that aren't in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can sign in by using a user account that doesn't have a password. This policy is especially important for portable devices. - -If you apply this security policy to the Everyone group, no one will be able to sign in through Remote Desktop Services. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- It's advisable to set **Accounts: Limit local account use of blank passwords to console logon only** to Enabled. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Enabled | -| DC Effective Default Settings | Enabled | -| Member Server Effective Default Settings | Enabled | -| Client Computer Effective Default Settings | Enabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -The policy as distributed through the GPO takes precedence over the locally configured policy setting on a computer joined to a domain. On the domain controller, use ADSI Edit or the dsquery command to determine effective minimum password length. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Blank passwords are a serious threat to computer security, and they should be forbidden through organizational policy and suitable technical measures. From Windows Server 2003, the default settings for Active Directory domains require complex passwords of at least seven characters, and eight characters starting with Windows Server 2008. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to sign in. - -### Countermeasure - -Enable the **Accounts: Limit local account use of blank passwords to console logon only** setting. - -### Potential impact - -None. This non-impact behavior is the default configuration. - -## Related topics -[Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md b/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md deleted file mode 100644 index 3740084b0b..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Accounts Rename administrator account -description: This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting. -ms.assetid: d21308eb-7c60-4e48-8747-62b8109844f9 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Accounts: Rename administrator account - -**Applies to** -- Windows 11 -- Windows 10 - -This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting. - -## Reference - -The **Accounts: Rename administrator account** policy setting determines whether a different account name is associated with the security identifier (SID) for the administrator account. - -Because the administrator account exists on all Windows 10 for desktop editions (Home, Pro, Enterprise, and Education), renaming the account makes it slightly more difficult for attackers to guess this user name and password combination. - -Rename the Administrator account by specifying a value for the **Accounts: Rename administrator account** policy setting. - -### Possible values -- User-defined text -- Not defined - -### Best practices -- Be sure to inform users who are authorized to use this account of the new account name. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Administrator | -| DC Effective Default Settings | Administrator | -| Member Server Effective Default Settings | Administrator | -| Client Computer Effective Default Settings | Administrator | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it's slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer so this countermeasure is applied by default on new installations. If a device is upgraded from a previous version of Windows, the account with the name administrator is retained with all the rights and privileges that were defined for the account in the previous installation. - -The built-in administrator account can't be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to sign in. - -### Countermeasure - -Specify a new name in the **Accounts: Rename administrator account** setting to rename the Administrator account. - -### Potential impact - -You must provide users who are authorized to use this account with the new account name. (The guidance for this setting assumes that the Administrator account wasn't disabled.) - -## Related topics - -[Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md b/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md deleted file mode 100644 index 1f3dd3b5f6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Accounts Rename guest account - security policy setting -description: Describes the best practices, location, values, and security considerations for the Accounts Rename guest account security policy setting. -ms.assetid: 9b8052b4-bbb9-4cc1-bfee-ce25390db707 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Accounts: Rename guest account - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting. - -## Reference - -The **Accounts: Rename guest account** policy setting determines whether a different account name is associated with the security identifier (SID) for the Guest account. - -### Possible values - -- *User-defined text* -- Guest - -### Best practices - -1. For devices in unsecured locations, renaming the account makes it more difficult for unauthorized users to guess it. -2. For computers in secured or trusted locations, keeping the name of the account as Guest provides consistency among devices - -### Location - -Computer Configuration\\Windows Settings\\Security Settings - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Guest | -| Default Domain Controller Policy | Guest | -| Stand-Alone Server Default Settings | Guest | -| DC Effective Default Settings | Guest | -| Member Server Effective Default Settings | Guest | -| Client Computer Effective Default Settings | *User-defined text* | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The guest account exists in all Windows server and client operating system versions beginning with Windows Server 2003 and Windows XP Professional. Because the account name is well known, it provides a vector for a malicious user to get access to network resources and attempt to elevate privileges -or install software that could be used for a later attack on your system. - -### Countermeasure - -Specify a new name in the **Accounts: Rename guest account** setting to rename the Guest account. If you rename this account, it's slightly more difficult for unauthorized persons to guess this privileged user name and password combination. - -### Potential impact - -There should be little impact because the Guest account is disabled by default in Windows 2000 Server, Windows Server 2003, and Windows XP. For later operating systems, the policy is enabled with **Guest** as the default. - -## Related topics - -[Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md deleted file mode 100644 index cf116b92be..0000000000 --- a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Act as part of the operating system -description: Describes the best practices, location, values, policy management, and security considerations for the Act as part of the operating system security policy setting. -ms.assetid: c1b7e084-a9f7-4377-b678-07cc913c8b0c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Act as part of the operating system - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Act as part of the operating system** security policy setting. - -## Reference - -The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access isn't limited to what is associated with the user by default. The calling process may request that arbitrary extra privileges be added to the access token. The calling process may also build an access token that doesn't provide a primary identity for auditing in the system event logs. - -Constant: SeTcbPrivilege - -### Possible values -- User-defined list of accounts -- Not defined - -### Best practices -- Don't assign this right to any user accounts. Only assign this user right to trusted users. -- If a service requires this user right, configure the service to sign in by using the local System account, which inherently includes this user right. Don't create a separate account and assign this user right to it. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default domain policy | Not defined | -| Default domain controller policy| Not defined | -| Stand-alone server default settings | Not defined | -| Domain controller effective default settings | Not defined | -| Member server effective default settings | Not defined | -| Client computer effective default settings | Not defined | - -## Policy management - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Act as part of the operating system** user right is powerful. Users with this user right can take complete control of the device and erase evidence of their activities. - -### Countermeasure - -Restrict the **Act as part of the operating system** user right to as few accounts as possible—it shouldn't even be assigned to the Administrators group under typical circumstances. When a service requires this user right, configure the service to sign in with the Local System account, which inherently includes this privilege. Don't create a separate account and assign this user right to it. - -### Potential impact - -There should be little or no impact because the **Act as part of the operating system** user right is rarely needed by any accounts other than the Local System account. - -## Related topics -[User Rights Assignment](user-rights-assignment.md) - diff --git a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md b/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md deleted file mode 100644 index f73cdd251d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Add workstations to domain -description: Describes the best practices, location, values, policy management and security considerations for the Add workstations to domain security policy setting. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Add workstations to domain - -**Applies to** -- Windows Server - -Describes the best practices, location, values, policy management and security considerations for the **Add workstations to domain** security policy setting. - -## Reference - -This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to 10 workstations to the domain. -Adding a machine account to the domain allows the device to participate in Active Directory-based networking. - -Constant: SeMachineAccountPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Configure this setting so that only authorized members of the IT team are allowed to add devices to the domain. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\User Rights Assignment\\ - -### Default values - -By default, this setting allows access for Authenticated Users on domain controllers, and it isn't defined on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined | -| Default Domain Controller Policy | Not Defined | -| Stand-Alone Server Default Settings | Not Defined | -| Domain Controller Effective Default Settings | Authenticated Users | -| Member Server Effective Default Settings | Not Defined | -| Client Computer Effective Default Settings | Not Defined | - -## Policy management - -Users can also join a computer to a domain if they've the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of devices to the domain regardless of whether they've the **Add workstations to domain** user right. - -Furthermore, machine accounts that are created through the **Add workstations to domain** user right have Domain Administrators as the owner of the machine account. Machine accounts that are created through permissions on the computer’s container use the creator as the owner of the machine account. If a user has permissions on the container and also has the **Add workstation to domain** user right, the device is added based on the computer container permissions rather than the user right. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This policy has the following security considerations: - -### Vulnerability - -The **Add workstations to domain** user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization doesn't want its users to have administrative -privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could sign in with that account, and then add a personal domain account to the local Administrators group. - -### Countermeasure - -Configure this setting so that only authorized members of the IT team are allowed to add computers to the domain. - -### Potential impact - -For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those organizations that have allowed some or all users to configure their own devices, this countermeasure forces the organization to establish a formal process for these procedures going forward. It doesn't affect existing computers unless they're removed from and then added to the domain. - -## Related topics -- [User Rights Assignment](user-rights-assignment.md) -  -  diff --git a/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md b/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md deleted file mode 100644 index 6a963f20cf..0000000000 --- a/windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Adjust memory quotas for a process -description: Describes the best practices, location, values, policy management, and security considerations for the Adjust memory quotas for a process security policy setting. -ms.assetid: 6754a2c8-6d07-4567-9af3-335fd8dd7626 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Adjust memory quotas for a process - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Adjust memory quotas for a process** security policy setting. - -## Reference - -This privilege determines who can change the maximum memory that can be consumed by a process. This privilege is useful for system tuning on a group or user basis. - -This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers. - -Constant: SeIncreaseQuotaPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -1. Restrict the **Adjust memory quotas for a process** user right to only users who require the ability to adjust memory quotas to perform their jobs. -2. If this user right is necessary for a user account, it can be assigned to a local machine account instead of to a domain account. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\User Rights Assignment\\ - -### Default values - -By default, members of the Administrators, Local Service, and Network Service groups have this right. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Administrators
Local Service
Network Service | -| Default Domain Controller Policy | Administrators
Local Service
Network Service | -| Stand-Alone Server Default Settings | Administrators
Local Service
Network Service | -| Domain Controller Effective Default Settings | Administrators
Local Service
Network Service | -| Member Server Effective Default Settings | Administrators
Local Service
Network Service | -| Client Computer Effective Default Settings | Administrators
Local Service
Network Service | - -## Policy management - -A restart of the device is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A user with the **Adjust memory quotas for a process** privilege can reduce the amount of memory that is available to any process, which could cause business-critical network applications to become slow or to fail. This privilege could be used by a malicious user to start a denial-of-service (DoS) attack. - -### Countermeasure - -Restrict the **Adjust memory quotas for a process** user right to users who require it to perform their jobs, such as application administrators who maintain database management systems or domain administrators who manage the organization's directory and its supporting infrastructure. - -### Potential impact - -Organizations that have not restricted users to roles with limited privileges may find it difficult to impose this countermeasure. Also, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Adjust memory quotas for a process** user right to additional accounts that are required by those components. IIS requires that this privilege be explicitly assigned to the IWAM\_<ComputerName>, Network Service, and Service accounts. Otherwise, this countermeasure should have no impact on most computers. If this user right is necessary for a user account, it can be assigned to a local computer account instead of to a domain account. - -## Related topics -- [User Rights Assignment](user-rights-assignment.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md b/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md deleted file mode 100644 index be7eb4d379..0000000000 --- a/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md +++ /dev/null @@ -1,314 +0,0 @@ ---- -title: Administer security policy settings -description: This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization. -ms.assetid: 7617d885-9d28-437a-9371-171197407599 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Administer security policy settings - -**Applies to** - -- Windows 11 -- Windows 10 - -This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization. - -Security policy settings should be used as part of your overall security implementation to help secure domain controllers, servers, client devices, and other resources in your organization. - -Security settings policies are rules that you can configure on a device, or multiple devices, for protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in (Gpedit.msc) allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, and organizational units, and they enable administrators to manage security settings for multiple computers from any device joined to the domain. - -Security settings can control: - -- User authentication to a network or device. -- The resources that users are permitted to access. -- Whether to record a user's or group's actions in the event log. -- Membership in a group. - -For info about each setting, including descriptions, default settings, and management and security considerations, see [Security policy settings reference](security-policy-settings-reference.md). - -To manage security configurations for multiple computers, you can use one of the following options: - -- Edit specific security settings in a GPO. -- Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template into a Group Policy Object. A security template is a file that represents a security configuration, and it can be imported to a GPO, or applied to a local device, or it can be used to analyze security. - -## What's changed in how settings are administered - -Over time, new ways to manage security policy settings have been introduced, which include new operating system features and the addition of new settings. The following table lists different means by which security policy settings can be administered. - -|Tool or feature |Description and use | -|---------|---------| -|[Security Policy snap-in](#using-the-local-security-policy-snap-in)|Secpol.msc
MMC snap-in designed to manage only security policy settings.| -|[Security editor command line tool](#using-the-secedit-command-line-tool) |Secedit.exe
Configures and analyzes system security by comparing your current configuration to specified security templates.| -|[Security Compliance Manager](#using-the-security-compliance-manager)|Tool download
A Solution Accelerator that helps you plan, deploy, operate, and manage your security baselines for Windows client and server operating systems, and Microsoft applications.| -|[Security Configuration Wizard](#using-the-security-configuration-wizard)|Scw.exe
SCW is a role-based tool available on servers only: You can use it to create a policy that enables services, firewall rules, and settings that are required for a selected server to perform specific roles.| -|[Security Configuration Manager tool](#working-with-the-security-configuration-manager)|This tool set allows you to create, apply, and edit the security for your local device, organizational unit, or domain.| -|[Group Policy](#working-with-group-policy-tools)|Gpmc.msc and Gpedit.msc
The Group Policy Management Console uses the Group Policy Object editor to expose the local Security options, which can then be incorporated into Group Policy Objects for distribution throughout the domain. The Local Group Policy Editor performs similar functions on the local device.| -|Software Restriction Policies
See [Administer Software Restriction Policies](/windows-server/identity/software-restriction-policies/administer-software-restriction-policies)|Gpedit.msc
Software Restriction Policies (SRP) is a Group Policy-based feature that identifies software programs running on computers in a domain, and it controls the ability of those programs to run.| -|Administer AppLocker
See [Administer AppLocker](/windows/device-security/applocker/administer-applocker)|Gpedit.msc
Prevents malicious software (malware) and unsupported applications from affecting computers in your environment, and it prevents users in your organization from installing and using unauthorized applications.| - -## Using the Local Security Policy snap-in - -The Local Security Policy snap-in (Secpol.msc) restricts the view of local policy objects to the following policies and features: - -- Account Policies -- Local Policies -- Windows Firewall with Advanced Security -- Network List Manager Policies -- Public Key Policies -- Software Restriction Policies -- Application Control Policies -- IP Security Policies on Local Computer -- Advanced Audit Policy Configuration - -Policies set locally might be overwritten if the computer is joined to the domain. - -The Local Security Policy snap-in is part of the Security Configuration Manager tool set. For info about other tools in this tool set, see [Working with the Security Configuration Manager](#bkmk-scmtool) in this topic. - -## Using the secedit command-line tool - -The secedit command-line tool works with security templates and provides six primary functions: - -- The **Configure** parameter helps you resolve security discrepancies between devices by applying the correct security template to the errant server. -- The **Analyze** parameter compares the server's security configuration with the selected template. -- The **Import** parameter allows you to create a database from an existing template. The Security Configuration and Analysis tool does this cloning also. -- The **Export** parameter allows you to export the settings from a database into a security settings template. -- The **Validate** parameter allows you to validate the syntax of each or any lines of text that you created or added to a security template. This validation ensures that if the template fails to apply syntax, the template won't be the issue. -- The **Generate Rollback** parameter saves the server's current security settings into a security template so it can be used to restore most of the server's security settings to a known state. The exceptions are that, when applied, the rollback template won't change access control list entries on files or registry entries that were changed by the most recently applied template. - -## Using the Security Compliance Manager - -The Security Compliance Manager is a downloadable tool that helps you plan, deploy, operate, and manage your security baselines for Windows client and server operating systems, and for Microsoft applications. It contains a complete database of recommended security settings, methods to customize your baselines, and the option to implement those settings in multiple formats—including XLS, GPOs, Desired Configuration Management (DCM) packs, or Security Content Automation Protocol (SCAP). The Security Compliance Manager is used to export the baselines to your environment to automate the security baseline deployment and compliance verification process. - -**To administer security policies by using the Security Compliance Manager** - -1. Download the most recent version. You can find more info on the [Microsoft Security Baselines](https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines) blog. -1. Read the relevant security baseline documentation that is included in this tool. -1. Download and import the relevant security baselines. The installation process steps you through baseline selection. -1. Open the Help and follow instructions how to customize, compare, or merge your security baselines before deploying those baselines. - -## Using the Security Configuration Wizard - -The Security Configuration Wizard (SCW) guides you through the process of creating, editing, applying, or rolling back a security policy. A security policy that you create with SCW is an .xml file that, when applied, configures services, network security, specific registry values, and audit policy. -SCW is a role-based tool: You can use it to create a policy that enables services, firewall rules, and settings that are required for a selected server to perform specific roles. For example, a server might be a file server, a print server, or a domain controller. - -The following are considerations for using SCW: - -- SCW disables unnecessary services and provides Windows Firewall with Advanced Security support. -- Security policies that are created with SCW aren't the same as security templates, which are files with an .inf extension. Security templates contain more security settings than those settings that can be set with SCW. However, it's possible to include a security template in an SCW security policy file. -- You can deploy security policies that you create with SCW by using Group Policy. -- SCW doesn't install or uninstall the features necessary for the server to perform a role. You can install server role-specific features through Server Manager. -- SCW detects server role dependencies. If you select a server role, it automatically selects dependent server roles. -- All apps that use the IP protocol and ports must be running on the server when you run SCW. -- In some cases, you must be connected to the Internet to use the links in the SCW help. - > [!NOTE] - > The SCW is available only on Windows Server and only applicable to server installations. - -The SCW can be accessed through Server Manager or by running scw.exe. The wizard steps you through server security configuration to: - -- Create a security policy that can be applied to any server on your network. -- Edit an existing security policy. -- Apply an existing security policy. -- Roll back the last applied security policy. - -The Security Policy Wizard configures services and network security based on the server's role, as well as configures auditing and registry settings. - -For more information about SCW, including procedures, see [Security Configuration Wizard](/previous-versions/orphan-topics/ws.11/cc754997(v=ws.11)). - -## Working with the Security Configuration Manager - -The Security Configuration Manager tool set allows you to create, apply, and edit the security for your local device, organizational unit, or domain. - -For procedures on how to use the Security Configuration Manager, see [Security Configuration Manager](/previous-versions/windows/it-pro/windows-server-2003/cc758219(v=ws.10)). - -The following table lists the features of the Security Configuration Manager. - -|Security Configuration Manager tools |Description | -|---------|---------| -|[Security Configuration and Analysis](#security-configuration-and-analysis) |Defines a security policy in a template. These templates can be applied to Group Policy or to your local computer.| -|[Security templates](#security-templates) |Defines a security policy in a template. These templates can be applied to Group Policy or to your local computer.| -|[Security Settings extension to Group Policy](#security-settings-extension-to-group-policy) |Edits individual security settings on a domain, site, or organizational unit.| -|[Local Security Policy](#local-security-policy)|Edits individual security settings on your local computer.| -|Secedit |Automates security configuration tasks at a command prompt.| - -### Security Configuration and Analysis - -Security Configuration and Analysis is an MMC snap-in for analyzing and configuring local system security. - -### Security analysis - -The state of the operating system and apps on a device is dynamic. For example, you may need to temporarily change security levels so that you can immediately resolve an administration or network issue. However, this change can often go unreversed. This unreversed state of the changes means that a computer may no longer meet the requirements for enterprise security. - -Regular analysis enables you to track and ensure an adequate level of security on each computer as part of an enterprise risk management program. You can tune the security levels and, most importantly, detect any security flaws that may occur in the system over time. - -Security Configuration and Analysis enables you to quickly review security analysis results. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings don't match the proposed level of security. Security Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals. - -### Security configuration - -Security Configuration and Analysis can also be used to directly configure local system security. Through its use of personal databases, you can import security templates that have been created with Security Templates and apply these templates to the local computer. These security templates immediately configure the system security with the levels specified in the template. - -### Security templates - -With the Security Templates snap-in for Microsoft Management Console, you can create a security policy for your device or for your network. It's a single point of entry where the full range of system security can be taken into account. The Security Templates snap-in doesn't introduce new security parameters, it simply organizes all existing security attributes into one place to ease security administration. - -Importing a security template to a Group Policy Object eases domain administration by configuring security for a domain or organizational unit at once. - -To apply a security template to your local device, you can use Security Configuration and Analysis or the secedit command-line tool. - -Security templates can be used to define: - -- Account Policies - - Password Policy - - Account Lockout Policy - - Kerberos Policy -- Local Policies - - Audit Policy - - User Rights Assignment - - Security Options -- Event Log: Application, system, and security Event Log settings -- Restricted Groups: Membership of security-sensitive groups -- System Services: Startup and permissions for system services -- Registry: Permissions for registry keys -- File System: Permissions for folders and files - -Each template is saved as a text-based .inf file. This file enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes can be contained in a security template. - -### Security settings extension to Group Policy - -Organizational units, domains, and sites are linked to Group Policy Objects. The security settings tool allows you to change the security configuration of the Group Policy Object, in turn, affecting multiple computers. With security settings, you can modify the security settings of many devices, depending on the Group Policy Object you modify, from just one device joined to a domain. - -Security settings or security policies are rules that are configured on a device or multiple devices for protecting resources on a device or network. Security settings can control: - -- How users are authenticated to a network or device -- What resources users are authorized to use -- Whether or not a user's or group's actions are recorded in the event log -- Group membership - -You can change the security configuration on multiple computers in two ways: - -- Create a security policy by using a security template with Security Templates, and then import the template through security settings to a Group Policy Object. -- Change a few select settings with security settings. - -### Local Security Policy - -A security policy is a combination of security settings that affect the security on a device. You can use your local security policy to edit account policies and local policies on your local device - -With the local security policy, you can control: - -- Who accesses your device -- What resources users are authorized to use on your device -- Whether or not a user's or group's actions are recorded in the event log - -If your local device is joined to a domain, you're subject to obtaining a security policy from the domain's policy or from the policy of any organizational unit that you're a member of. If you're getting a policy from more than one source, conflicts are resolved in the following order of precedence. - -1. Organizational unit policy -1. Domain policy -1. Site policy -1. Local computer policy - -If you modify the security settings on your local device by using the local security policy, then you're directly modifying the settings on your device. Therefore, the settings take effect immediately, but this effect may only be temporary. The settings will actually remain in effect on your local device until the next refresh of Group Policy security settings, when the security settings that are received from Group Policy will override your local settings wherever there are conflicts. - -### Using the Security Configuration Manager - -For procedures on how to use the Security Configuration Manager, see [Security Configuration Manager How To](/previous-versions/windows/it-pro/windows-server-2003/cc784762(v=ws.10)). This section contains information in this topic about: - -- [Applying security settings](#applying-security-settings) -- [Importing and exporting security templates](#importing-and-exporting-security-templates) -- [Analyzing security and viewing results](#analyzing-security-and-viewing-results) -- [Resolving security discrepancies](#resolving-security-discrepancies) -- [Automating security configuration tasks](#automating-security-configuration-tasks) - -### Applying security settings - -Once you've edited the security settings, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object: - -- When a device is restarted, the settings on that device will be refreshed. -- To force a device to refresh its security settings and all Group Policy settings, use gpupdate.exe. - -**Precedence of a policy when more than one policy is applied to a computer** - -For security settings that are defined by more than one policy, the following order of precedence is observed: - -1. Organizational Unit Policy -1. Domain Policy -1. Site Policy -1. Local computer Policy - -For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there's a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override -both the domain and local settings. If the workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately contains the workstation has the highest order of precedence. - -> [!NOTE] -> Use gpresult.exe to find out what policies are applied to a device and in what order. -For domain accounts, there can be only one account policy that includes password policies, account lockout policies, and Kerberos policies. - -**Persistence in security settings** - -Security settings may still persist even if a setting is no longer defined in the policy that originally applied it. - -Persistence in security settings occurs when: - -- The setting hasn't been previously defined for the device. -- The setting is for a registry object. -- The setting is for a file system object. - -All settings applied through local policy or a Group Policy Object are stored in a local database on your device. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the device. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value doesn't exist in the database, then the setting doesn't revert to anything and remains defined as is. This behavior is sometimes called "tattooing." - -Registry and file settings will maintain the values applied through policy until that setting is set to other values. - -**Filtering security settings based on group membership** - -You can also decide what users or groups will or won't have a Group Policy Object applied to them regardless of what computer they've signed into by denying them either the Apply Group Policy or Read permission on that Group Policy Object. Both of these permissions are needed to apply Group Policy. - -### Importing and exporting security templates - -Security Configuration and Analysis enables import and export of security templates into or from a database. - -If you have made any changes to the analysis database, you can save those settings by exporting them into a template. The export feature enables saving the analysis database settings as a new template file. This template file can then be used to analyze or configure a system, or it can be imported to a Group Policy Object. - -### Analyzing security and viewing results - -Security Configuration and Analysis performs security analysis by comparing the current state of system security against an *analysis database*. During creation, the analysis database uses at least one security template. If you choose to import more than one security template, the database will merge the various templates and create one composite template. It resolves conflicts in order of import; the last template that is imported takes precedence. - -Security Configuration and Analysis displays the analysis results by security area, using visual flags to indicate problems. It displays the current system and base configuration settings for each security attribute in the security areas. To change the analysis database settings, right-click the entry, and then click **Properties**. - -|Visual flag |Meaning | -|---------|---------| -|Red X |The entry is defined in the analysis database and on the system, but the security setting values don't match.| -|Green check mark |The entry is defined in the analysis database and on the system and the setting values match.| -|Question mark |The entry isn't defined in the analysis database and, therefore, wasn't analyzed.
If an entry isn't analyzed, it may be that it wasn't defined in the analysis database or that the user who is running the analysis may not have sufficient permission to perform analysis on a specific object or area.| -|Exclamation point |This item is defined in the analysis database, but doesn't exist on the actual system. For example, there may be a restricted group that is defined in the analysis database but doesn't actually exist on the analyzed system.| -|No highlight |The item isn't defined in the analysis database or on the system.| - -If you choose to accept the current settings, the corresponding value in the base configuration is modified to match them. If you change the system setting to match the base configuration, the change will be reflected when you configure the system with Security Configuration and Analysis. - -To avoid continued flagging of settings that you've investigated and determined to be reasonable, you can modify the base configuration. The changes are made to a copy of the template. - -### Resolving security discrepancies - -You can resolve discrepancies between analysis database and system settings by: - -- Accepting or changing some or all of the values that are flagged or not included in the configuration, if you determine that the local system security levels are valid due to the context (or role) of that computer. These attribute values are then updated in the database and applied to the system when you click **Configure Computer Now**. -- Configuring the system to the analysis database values, if you determine the system isn't in compliance with valid security levels. -- Importing a more appropriate template for the role of that computer into the database as the new base configuration and applying it to the system. -Changes to the analysis database are made to the stored template in the database, not to the security template file. The security template file will only be modified if you either return to Security Templates and edit that template or export the stored configuration to the same template file. -You should use **Configure Computer Now** only to modify security areas *not* affected by Group Policy settings, such as security on local files and folders, registry keys, and system services. Otherwise, when the Group Policy settings are applied, it will take precedence over local settings—such as account policies. -In general, don't use **Configure Computer Now** when you're analyzing security for domain-based clients, since you'll have to configure each client individually. In this case, you should return to Security Templates, modify the template, and reapply it to the appropriate Group Policy Object. - -### Automating security configuration tasks - -By calling the secedit.exe tool at a command prompt from a batch file or automatic task scheduler, you can use it to automatically create and apply templates, and analyze system security. You can also run it dynamically from a command prompt. -Secedit.exe is useful when you have multiple devices on which security must be analyzed or configured, and you need to perform these tasks during off-hours. - -## Working with Group Policy tools - -Group Policy is an infrastructure that allows you to specify managed configurations for users and computers through Group Policy settings and Group Policy Preferences. For Group Policy settings that affect only a local device or user, you can use the Local Group Policy Editor. You can manage Group Policy settings and Group Policy Preferences in an Active Directory Domain Services (AD DS) environment through the Group Policy Management Console (GPMC). Group Policy management tools also are included in the Remote Server Administration Tools pack to provide a way for you to administer Group Policy settings from your desktop. diff --git a/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md b/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md deleted file mode 100644 index 0bb7fa0b5a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Allow log on locally - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Allow log on locally security policy setting. -ms.assetid: d9e5e1f3-3bff-4da7-a9a2-4bb3e0c79055 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Allow log on locally - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Allow log on locally** security policy setting. - -## Reference - -This policy setting determines which users can start an interactive session on the device. Users must have this user right to log on over a Remote Desktop Services session that is running on a Windows-based member device or domain controller. -> **Note:**  Users who do not have this right are still able to start a remote interactive session on the device if they have the **Allow logon through Remote Desktop Services** right. - -Constant: SeInteractiveLogonRight - -### Possible values - -- User-defined list of accounts -- Not Defined - -By default, the members of the following groups have this right on workstations and servers: - -- Administrators -- Backup Operators -- Users - -By default, the members of the following groups have this right on domain controllers: - -- Account Operators -- Administrators -- Backup Operators -- Enterprise Domain Controllers -- Print Operators -- Server Operators - -### Best practices - -1. Restrict this user right to legitimate users who must log on to the console of the device. -2. If you selectively remove default groups, you can limit the abilities of users who are assigned to specific administrative roles in your organization. - -### Location - -Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not Defined | -| Default Domain Controller Policy | Account Operators
Administrators
Backup Operators
Enterprise Domain Controllers
Print Operators
Server Operators | -| Stand-Alone Server Default Settings| Administrators
Backup Operators
Users | -| Domain Controller Effective Default Settings | Account Operators
Administrators
Backup Operators
Enterprise Domain Controllers
Print Operators
Server Operators | -| Member Server Effective Default Settings | Administrators
Backup Operators
Users | -| Client Computer Effective Default Settings | Administrators
Backup Operators
Users | - -## Policy management - -Restarting the device is not required to implement this change. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Modifying this setting might affect compatibility with clients, services, and applications. Use caution when removing service accounts that are used by components and by programs on member devices and on domain controllers in the domain from the default domain controller's policy. Also use caution when removing users or security groups that log on to the console of member devices in the domain, or removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member devices or of workgroup devices. -If you want to grant a user account the ability to log on locally to a domain controller, you must make that user a member of a group that already has the **Allowed logon locally** system right or grant the right to that user account. -The domain controllers in the domain share the Default Domain Controllers Group Policy Object (GPO). When you grant an account the **Allow logon locally** right, you are allowing that account to log on locally to all domain controllers in the domain. -If the Users group is listed in the **Allow log on locally** setting for a GPO, all domain users can log on locally. The Users built-in group contains Domain Users as a member. - -### Group Policy - -Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any account with the **Allow log on locally** user right can log on to the console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges. - -### Countermeasure - -For domain controllers, assign the **Allow log on locally** user right only to the Administrators group. For other server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you should also assign this right to the Users group. -Alternatively, you can assign groups such as Account Operators, Server Operators, and Guests to the **Deny log on locally** user right. - -### Potential impact - -If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to assign the **Allow log on locally** user right to additional accounts that are required by those components. IIS requires that this user right be assigned to the IUSR\_*<ComputerName>* account. You should confirm that delegated activities are not adversely affected by any changes that you make to the **Allow log on locally** user rights assignments. - -## Related topics -- [User Rights Assignment](user-rights-assignment.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md deleted file mode 100644 index 1d44efc4b3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Allow log on through Remote Desktop Services -description: Best practices, location, values, policy management, and security considerations for the security policy setting. Allow a sign-in through Remote Desktop Services. -ms.assetid: 6267c376-8199-4f2b-ae56-9c5424e76798 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Allow log on through Remote Desktop Services - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Allow log on through Remote Desktop Services** security policy setting. - -## Reference - -This policy setting determines which users or groups can access the sign-in screen of a remote device through a Remote Desktop Services connection. It's possible for a user to establish a Remote Desktop Services connection to a particular server but not be able to sign in to the console of that same server. - -Constant: SeRemoteInteractiveLogonRight - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- To control who can open a Remote Desktop Services connection and sign in to the device, add users to or remove users from the Remote Desktop Users group. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators group have this right on domain controllers, workstations, and servers. The Remote Desktops Users group also has this right on workstations and servers. -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined | -| Default Domain Controller Policy | Not Defined | -| Domain Controller Local Security Policy | Administrators | -| Stand-Alone Server Default Settings | Administrators
Remote Desktop Users | -| Domain Controller Effective Default Settings | Administrators | -| Member Server Effective Default Settings | Administrators
Remote Desktop Users | -| Client Computer Effective Default Settings | Administrators
Remote Desktop Users | - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Group Policy - -To use Remote Desktop Services to successfully sign in to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the **Allow log on through Remote Desktop Services** right. It's possible for a user to establish a Remote Desktop Services session to a particular server, but not be able to sign in to the console of that same server. - -To exclude users or groups, you can assign the **Deny log on through Remote Desktop Services** user right to those users or groups. However, be careful when you use this method because you could create conflicts for legitimate users or groups that have been allowed access through the **Allow log on through Remote Desktop Services** user right. - -For more information, see [Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md). - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any account with the **Allow log on through Remote Desktop Services** user right can sign in to the remote console of the device. If you don't restrict this user right to legitimate users who must sign in to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges. - -### Countermeasure - -For domain controllers, assign the **Allow log on through Remote Desktop Services** user right only to the Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that have the Remote Desktop (RD) Session Host role service enabled and don't run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to these groups. - -> **Caution:**  For RD Session Host servers that run in Application Server mode, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group because this built-in group has this logon right by default. - -Alternatively, you can assign the **Deny log on through Remote Desktop Services** user right to groups such as Account Operators, Server Operators, and Guests. However, be careful when you use this method because you could block access to legitimate administrators who also belong to a group that has the **Deny log on through Remote Desktop Services** user right. - -### Potential impact - -Removal of the **Allow log on through Remote Desktop Services** user right from other groups (or membership changes in these default groups) could limit the abilities of users who perform specific administrative roles in your environment. You should confirm that delegated activities aren't adversely affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/audit-audit-the-access-of-global-system-objects.md b/windows/security/threat-protection/security-policy-settings/audit-audit-the-access-of-global-system-objects.md deleted file mode 100644 index 179941bc1c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/audit-audit-the-access-of-global-system-objects.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: Audit the access of global system objects -description: Describes the best practices, location, values, and security considerations for the audit of the access to global system objects security policy setting. -ms.assetid: 20d40a79-ce89-45e6-9bb4-148f83958460 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Audit: Audit the access of global system objects - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting. - -## Reference - -If you enable this policy setting, a default system access control list (SACL) is applied when the device creates system objects such as mutexes, events, semaphores, and MS-DOS® devices. If you also enable the [Audit object access](../auditing/basic-audit-object-access.md) audit setting, access to these system objects is audited. - -Global system objects, also known as "base system objects" or "base named objects", are temporary kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because they have names, these objects are global in scope and, therefore, visible to all processes on the device. These objects all have a security descriptor; but typically, they don't have a NULL SACL. If you enable this policy setting and it takes effect at startup time, the kernel assigns a SACL to these objects when they're created. - -The threat is that a globally visible-named object, if incorrectly secured, might be acted on by a malicious program that knows the name of the object. For instance, if a synchronization object such as a mutex has a poorly constructed discretionary access control list (DACL), a malicious program can access that mutex by name and cause the program that created it to malfunction. However, the risk of this occurring is very low. - -Enabling this policy setting can generate a large number of security events, especially on busy domain controllers and application servers. This might cause servers to respond slowly and force the security log to record numerous events of little significance. Auditing for access to global system objects is an all-or-nothing affair; there's no way to filter which events get recorded and which don't. Even if an organization has the resources to analyze events generated when this policy setting is enabled, it's unlikely to have the source code or a description of what each named object is used for; therefore, it's unlikely that many organizations could benefit from enabling this policy setting. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Use the advanced security audit policy option, [Audit Kernel Object](../auditing/audit-kernel-object.md) in Advanced Security Audit Policy Settings\\Object Access, to reduce the number of unrelated audit events that you generate. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -A restart of the computer is required before this policy will be effective when changes to this policy are saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -### Auditing - -To audit the attempts to access global system objects, you can use one of the two security audit policy settings: - -- [Audit Kernel Object](../auditing/audit-kernel-object.md) in Advanced Security Audit Policy Settings\\Object Access -- [Audit Object Access](../auditing/basic-audit-object-access.md) under Security Settings\\Local Policies\\Audit Policy - -If possible, use the Advanced Security Audit Policy option to reduce the number of unrelated audit events that you generate. - -If the [Audit Kernel Object](../auditing/audit-kernel-object.md) setting is configured, the following events are generated: - -| Event ID | Event message | -| - | - | -| 4659 | A handle to an object was requested with intent to delete. | -| 4660 | An object was deleted. | -| 4661 | A handle to an object was requested. | -| 4663 | An attempt was made to access an object. | - -If the [Audit Object Access](../auditing/basic-audit-object-access.md) setting is configured, the following events are generated: - -| Event ID | Event message | -| - | - | -| 560 | Access was granted to an already existing object. | -| 562 | A handle to an object was closed. | -| 563 | An attempt was made to open an object with the intent to delete it.
**Note:** This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile() | -| 564 | A protected object was deleted. | -| 565 | Access was granted to an already existing object type. | -| 567 | A permission associated with a handle was used.
**Note:** A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used. | -| 569 | The resource manager in Authorization Manager attempted to create a client context. | -| 570 | A client attempted to access an object.
**Note:** An event will be generated for every attempted operation on the object. | - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A globally visible named object, if incorrectly secured, could be acted upon by malicious software by using the name of the object. For instance, if a synchronization object such as a mutex had a poorly chosen discretionary access control list (DACL), malicious software could access that mutex by name and cause the program that created it to malfunction. However, the risk of such an occurrence is very low. - -### Countermeasure - -Enable the **Audit: Audit the access of global system objects** setting. - -### Potential impact - -If you enable the **Audit: Audit the access of global system objects** setting, a large number of security events could be generated, especially on busy domain controllers and application servers. Such an occurrence could cause servers to respond slowly and force the Security log to record numerous events of little significance. This policy setting can only be enabled or disabled, and there's no way to choose which events are recorded from this setting. Even organizations that have the resources to analyze events that are generated by this policy setting aren't likely to have the source code or a description of what each named object is used for. Therefore, it's unlikely that most organizations would benefit by enabling this policy setting. -To reduce the number of audit events generated, use the advanced audit policy. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md b/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md deleted file mode 100644 index 05c570e013..0000000000 --- a/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: "Audit: Audit the use of Backup and Restore privilege (Windows 10)" -description: "Describes the best practices, location, values, and security considerations for the 'Audit: Audit the use of Backup and Restore privilege' security policy setting." -ms.assetid: f656a2bb-e8d6-447b-8902-53df3a7756c5 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/01/2019 ---- - -# Audit: Audit the use of Backup and Restore privilege - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting. - -## Reference - -The **Audit: Audit the use of Backup and Restore privilege** policy setting determines whether to audit the use of all user rights, including Backup and Restore, when the **Audit privilege use** policy setting is configured. Enabling both policy settings generates an audit event for every file that is backed up or restored. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set **Audit: Audit the use of Backup and Restore privilege** to Disabled. Enabling this policy setting can generate a large number of security events, which might cause servers to respond slowly and force the security event log to record numerous events of little significance. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Auditing - -Enabling this policy setting in conjunction with the **Audit privilege use** policy setting records any instance of user rights that are being exercised in the security log. If **Audit privilege use** is enabled but **Audit: Audit the use of Backup and Restore privilege** is disabled, when users back up or restore user rights, those events won't be audited. - -Enabling this policy setting when the **Audit privilege use** policy setting is also enabled generates an audit event for every file that is backed up or restored. This setup can help you to track down an administrator who is accidentally or maliciously restoring data in an unauthorized manner. - -Alternately, you can use the advanced audit policy, [Audit Sensitive Privilege Use](../auditing/audit-sensitive-privilege-use.md), which can help you manage the number of events generated. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When the backup and restore function is used, it creates a copy of the file system that is identical to the target of the backup. Making regular backup and restore volumes is an important part of your incident response plan. However, a malicious user could use a legitimate backup copy to gain access to information or to impersonate a legitimate network resource to compromise your enterprise. - -### Countermeasure - -Enable the **Audit: Audit the use of Backup and Restore privilege** setting. Alternatively, implement automatic log backup by configuring the **AutoBackupLogFiles** registry key. If you enable this option when the [Audit privilege use](../auditing/basic-audit-privilege-use.md) setting is also enabled, an audit event is generated for every file that is backed up or restored. This information could help you to identify an account that was used to accidentally or maliciously restore data in an unauthorized manner. -For more information about configuring this key, see [Eventlog Key](/windows/desktop/EventLog/eventlog-key). - -### Potential impact - -If you enable this policy setting, a large number of security events could be generated, which could cause servers to respond slowly and force the security event log to record numerous events of little significance. If you increase the security event log size to reduce the chances of a system shutdown, an excessively large log file may affect system performance. - -## Related topics - -- [Security Options](security-options.md) - diff --git a/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md b/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md deleted file mode 100644 index 1d81955c37..0000000000 --- a/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Audit Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings -description: Learn more about the security policy setting, Audit Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. -ms.assetid: 8ddc06bc-b6d6-4bac-9051-e0d77035bd4e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** security policy setting. - -## Reference - -You can manage your audit policy in a more precise way by using audit policy subcategories. - -There are over 40 auditing subcategories that provide precise details about activities on a device. For info about these subcategories, see the [Advanced security audit policy settings](../auditing/advanced-security-audit-policy-settings.md). - -### Possible values - -- Enabled -- Disabled - -### Best practices - -- Leave the setting enabled. This "enabled" state helps audit events at the category level without revising a policy. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Enabled | -| DC Effective Default Settings | Enabled | -| Member Server Effective Default Settings | Enabled | -| Client Computer Effective Default Settings | Enabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -### Auditing - -To manage an audit policy by using subcategories without requiring a change to Group Policy, the SCENoApplyLegacyAuditPolicy registry value prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool. - -If the category level audit policy that is set here isn't consistent with the events that are currently being generated, the cause might be that this registry key is set. - -### Command-line tools - -You can use auditpol.exe to display and manage audit policies from a command prompt. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Prior to the introduction of auditing subcategories in Windows Vista, it was difficult to track events at a per-system or per-user level. The larger event categories created too many events, and the key information that needed to be audited was difficult to find. - -### Countermeasure - -Enable audit policy subcategories as needed to track specific events. - -### Potential impacts - -If you attempt to modify an audit setting by using Group Policy after enabling this setting through the command-line tools, the Group Policy audit setting is ignored in favor of the custom policy setting. To modify audit settings by using Group Policy, you must first disable the -**SCENoApplyLegacyAuditPolicy** key. -> **Important:**  Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events that are generated can make it difficult to find other types of entries in the security event log. Such a configuration could also have a significant impact on system performance. - -## Related topics - -- [Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/audit-policy.md b/windows/security/threat-protection/security-policy-settings/audit-policy.md deleted file mode 100644 index 72c1169cf3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/audit-policy.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Audit Policy -description: Provides information about basic audit policies that are available in Windows and links to information about each setting. -ms.assetid: 2e8ea400-e555-43e5-89d6-0898cb89da90 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Audit Policy - -**Applies to** -- Windows 11 -- Windows 10 - -Provides information about basic audit policies that are available in Windows and links to information about each setting. - -The security audit policy settings under **Security Settings\\Local Policies\\Audit Policy** provide broad security audit capabilities for client devices and servers that can't use advanced security audit policy settings. - -The basic audit policy settings under **Security Settings\\Local Policies\\Audit Policy** are: -- [Audit account logon events](../auditing/basic-audit-account-logon-events.md) -- [Audit account management](../auditing/basic-audit-account-management.md) -- [Audit directory service access](../auditing/basic-audit-directory-service-access.md) -- [Audit logon events](../auditing/basic-audit-logon-events.md) -- [Audit object access](../auditing/basic-audit-object-access.md) -- [Audit policy change](../auditing/basic-audit-policy-change.md) -- [Audit privilege use](../auditing/basic-audit-privilege-use.md) -- [Audit process tracking](../auditing/basic-audit-process-tracking.md) -- [Audit system events](../auditing/basic-audit-system-events.md) - -## Related topics - -- [Configure security policy settings](how-to-configure-security-policy-settings.md) -- [Security auditing](../auditing/security-auditing-overview.md) -  -  diff --git a/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md b/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md deleted file mode 100644 index 4d0ab7c979..0000000000 --- a/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Audit Shut down system immediately if unable to log security audits -description: Best practices, security considerations, and more for the security policy setting, Audit Shut down system immediately if unable to log security audits. -ms.assetid: 2cd23cd9-0e44-4d0b-a1f1-39fc29303826 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Audit: Shut down system immediately if unable to log security audits - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management practices, and security considerations for the **Audit: Shut down system immediately if unable to log security audits** security policy setting. - -## Reference - -The **Audit: Shut down system immediately if unable to log security audits** policy setting determines whether the system shuts down if it's unable to log security events. This policy setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a Stop message if there's a failure of the auditing system. Enabling this policy setting stops the system if a security audit can't be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the value of **Retention method for security log** is **Do not overwrite events (clear log manually)** or **Overwrite events by days**. - -With **Audit: Shut down system immediately if unable to log security audits** set to **Enabled**, if the security log is full and an existing entry can't be overwritten, the following Stop message appears: - -**STOP: C0000244 {Audit Failed}**: An attempt to generate a security audit failed. - -To recover, you must sign in, archive the log (optional), clear the log, and reset this option as desired. - -If the computer is unable to record events to the security log, critical evidence or important troubleshooting information might not be available for review after a security incident. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Depending on your security audit requirements, you can enable the **Audit: Shut down system immediately if unable to log security audits** setting to ensure that security auditing information is captured for review. However, enabling this setting will increase the number of events logged. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined -| Default Domain Controller Policy | Not defined -| Stand-Alone Server Default Settings | Disabled -| DC Effective Default Settings | Disabled -| Member Server Effective Default Settings | Disabled -| Client Computer Effective Default Settings | Disabled - -## Policy management - -This section describes features and tools that are available to help you manage this policy. -The administrative burden of enabling this policy setting can be high, especially if you also set the **Retention method for security log** to **Do not overwrite events (clear log manually)**. This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be forced to shut down if it's overwhelmed with sign-in events and other security events that are written to the security log. Additionally, because the shutdown isn't graceful, it's possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system will guarantee that the file system's integrity will be maintained during a sudden system shutdown, it can't guarantee that every data file for every application will still be in a usable form when the system is restarted. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Modifying this setting may affect compatibility with clients, services, and applications. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If the computer is unable to record events to the security event log, critical evidence or important troubleshooting information may not be available for review after a security incident. Also, an attacker could potentially generate a large volume of security event log events to purposely force a shutdown. - -### Countermeasure - -Enable the **Audit: Shut down system immediately if unable to log security audits** setting to ensure that security auditing information is captured for review. - -### Potential impact - -If you enable this policy setting, the administrative burden can be significant, especially if you also configure the **Retention method for the Security log** to **Do not overwrite events** (clear log manually). This configuration causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a denial of service (DoS) vulnerability because a server could be forced to shut down if it's overwhelmed with sign-in events and other security events that are written to the security event log. Also, because the shutdown is abrupt, it's possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system maintains its integrity when this type of computer shutdown occurs, there's no guarantee that every data file for every application will still be in a usable form when the device restarts. - -## Related topics - -- [Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md b/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md deleted file mode 100644 index 1ba7777a2b..0000000000 --- a/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: Back up files and directories - security policy setting -description: Describes the recommended practices, location, values, policy management, and security considerations for the Back up files and directories security policy setting. -ms.assetid: 1cd6bdd5-1501-41f4-98b9-acf29ac173ae -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Back up files and directories - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Back up files and directories** security policy setting. - -## Reference - -This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. This user right is effective only when an application attempts access through the NTFS backup application programming interface (API) through a tool such as NTBACKUP.EXE. Otherwise, standard file and directory permissions apply. - -This user right is similar to granting the following permissions to the user or group you selected on all files and folders on the system: - -- Traverse Folder/Execute File -- List Folder/Read Data -- Read Attributes -- Read Extended Attributes -- Read Permissions - -Default on workstations and servers: - -- Administrators -- Backup Operators - -Default on domain controllers: - -- Administrators -- Backup Operators -- Server Operators - -Constant: SeBackupPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -1. Restrict the **Back up files and directories** user right to members of the IT team who must back up organizational data as part of their daily job responsibilities. Because there's no way to be sure that a user is backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users. -2. If your backup software runs under specific service accounts, only these accounts (and not the IT staff) should have the user right to back up files and directories. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this right is granted to Administrators and Backup Operators on workstations and servers. On domain controllers, Administrators, Backup Operators, and Server Operators have this right. - -The following table lists the actual and effective default policy values for the server type or Group Policy Object (GPO). Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined | -| Default Domain Controller Policy | Administrators
Backup Operators
Server Operators| -| Stand-Alone Server Default Settings | Administrators
Backup Operators| -| Domain Controller Effective Default Settings | Administrators
Backup Operators
Server Operators| -| Member Server Effective Default Settings | Administrators
Backup Operators| -| Client Computer Effective Default Settings | Administrators
Backup Operators| - -## Policy management - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a GPO, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can back up data from a device to separate media could take the media to a non-domain computer on which they have administrative privileges, and then restore the data. They could take ownership of the files and view any unencrypted data that is contained within the data set. - -### Countermeasure - -Restrict the **Back up files and directories** user right to members of the IT team who must back up organizational data as part of their daily job responsibilities. If you use software that backs up data under specific service accounts, only these accounts (and not the IT staff) should have the right to back up files and directories. - -### Potential impact - -Changes in the membership of the groups that have the user right to back up files and directories could limit the abilities of users who are assigned to specific administrative roles in your environment. Confirm that authorized administrators can still back up files and directories. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md b/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md deleted file mode 100644 index 153da82af0..0000000000 --- a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Bypass traverse checking -description: Describes the best practices, location, values, policy management, and security considerations for the Bypass traverse checking security policy setting. -ms.assetid: 1c828655-68d3-4140-aa0f-caa903a7087e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Bypass traverse checking - -**Applies to** -- Windows 11 -- Windows 10 - ->Learn more about what features and functionality are supported in each Windows edition at [Compare Windows 10 Editions](https://www.microsoft.com/WindowsForBusiness/Compare). - -Describes the best practices, location, values, policy management, and security considerations for the **Bypass traverse checking** security policy setting. - -## Reference - -This policy setting determines which users (or a process that acts on behalf of the user’s account) have permission to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder special access permission. This user right doesn't allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders. - -Constant: SeChangeNotifyPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -1. Use access–based enumeration when you want to prevent users from seeing any folder or file to which they don't have access. -2. Use the default settings of this policy in most cases. If you change the settings, verify your intent through testing. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not Defined | -| Default Domain Controller Policy | Administrators
Authenticated Users
Everyone
Local Service
Network Service
Pre-Windows 2000 Compatible Access| -| Stand-Alone Server Default Settings | Administrators
Backup Operators
Users
Everyone
Local Service
Network Service| -| Domain Controller Effective Default Settings | Administrators
Authenticated Users
Everyone
Local Service
Network Service
Pre-Windows 2000 Compatible Access| -| Member Server Effective Default Settings | Administrators
Backup Operators
Users
Everyone
Local Service
Network Service| -| Client Computer Effective Default Settings | Administrators
Backup Operators
Users
Everyone
Local Service
Network Service| - -## Policy management - -Permissions to files and folders are controlled through the appropriate configuration of file system access control lists (ACLs). The ability to traverse the folder doesn't provide any Read or Write permissions to the user. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The default configuration for the **Bypass traverse checking** setting is to allow all users to bypass traverse checking. Permissions to files and folders are controlled through the appropriate configuration of file system access control lists (ACLs) because the ability to traverse the folder doesn't provide any Read or Write permissions to the user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who configures permissions doesn't understand how this policy setting works. For example, the administrator might expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a situation is unlikely, and, therefore, this vulnerability presents little risk. - -### Countermeasure - -Organizations that are concerned about security may want to remove the Everyone group from the list of groups that have the **Bypass traverse checking** user right. Taking explicit control over traversal assignments can be an effective way to limit access to sensitive information. Access–based enumeration can also be used. If you use access–based enumeration, users can't see any folder or file to which they don't have access. For more info about this feature, see [Access-based Enumeration](/previous-versions/windows/it-pro/windows-server-2003/cc784710(v=ws.10)). - -### Potential impact - -The Windows operating systems and many applications were designed with the expectation that anyone who can legitimately access the computer will have this user right. Therefore, we recommend that you thoroughly test any changes to assignments of the **Bypass traverse checking** user right before you make such changes to production systems. In particular, IIS requires this user right to be assigned to the Network Service, Local Service, IIS\_WPG, IUSR\_*<ComputerName>*, and IWAM\_*<ComputerName>* accounts. (It must also be assigned to the ASPNET account through its membership in the Users group.) We recommend that you leave this policy setting at its default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) - diff --git a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md b/windows/security/threat-protection/security-policy-settings/change-the-system-time.md deleted file mode 100644 index 7c3ac55c23..0000000000 --- a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Change the system time - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Change the system time security policy setting. -ms.assetid: f2f6637d-acbc-4352-8ca3-ec563f918e65 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Change the system time - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Change the system time** security policy setting. - -## Reference - -This policy setting determines which users can adjust the time on the device's internal clock. This right allows the computer user to change the date and time associated with records in the event logs, database transactions, and the file system. This right is also required by the process that performs time synchronization. This setting doesn't impact the user’s ability to change the time zone or other display characteristics of the system time. For info about assigning the right to change the time zone, see [Change the time zone](change-the-time-zone.md). - -Constant: SeSystemtimePrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Restrict the **Change the system time** user right to users with a legitimate need to change the system time. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators and Local Service groups have this right on workstations and servers. Members of the Administrators, Server Operators, and Local Service groups have this right on domain controllers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not Defined | -| Default Domain Controller Policy | Administrators
Server Operators
Local Service| -| Stand-Alone Server Default Settings | Administrators
Local Service| -| DC Effective Default Settings | Administrators
Server Operators
Local Service| -| Member Server Effective Default Settings | Administrators
Local Service| -| Client Computer Effective Default Settings | Administrators
Local Service| - -## Policy management - -This section describes features, tools and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can change the time on a computer could cause several problems. For example: - -- Time stamps on event log entries could be made inaccurate -- Time stamps on files and folders that are created or modified could be incorrect -- Computers that belong to a domain might not be able to authenticate themselves -- Users who try to sign in to the domain from devices with inaccurate time might not be able to authenticate. - -Also, because the Kerberos authentication protocol requires that the requester and authenticator have their clocks synchronized within an administrator-defined skew period, an attacker who changes a device's time may cause that computer to be unable to obtain or grant Kerberos protocol tickets. - -The risk from these types of events is mitigated on most domain controllers, member servers, and end-user computers because the Windows Time Service automatically synchronizes time with domain controllers in the following ways: - -- All desktop client devices and member servers use the authenticating domain controller as their inbound time partner. -- All domain controllers in a domain nominate the primary domain controller (PDC) emulator operations master as their inbound time partner. -- All PDC emulator operations masters follow the hierarchy of domains in the selection of their inbound time partner. -- The PDC emulator operations master at the root of the domain is authoritative for the organization. Therefore, we recommend that you configure this computer to synchronize with a reliable external time server. - -This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the Windows Time Service or reconfigure it to synchronize with a time server that isn't accurate. - -### Countermeasure - -Restrict the **Change the system time** user right to users with a legitimate need to change the system time, such as members of the IT team. - -### Potential impact - -There should be no impact because time synchronization for most organizations should be fully automated for all computers that belong to the domain. Computers that don't belong to the domain should be configured to synchronize with an external source, such as a web service. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md b/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md deleted file mode 100644 index 0c3b2e17fd..0000000000 --- a/windows/security/threat-protection/security-policy-settings/change-the-time-zone.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Change the time zone - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Change the time zone security policy setting. -ms.assetid: 3b1afae4-68bb-472f-a43e-49e300d73e50 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Change the time zone - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Change the time zone** security policy setting. - -## Reference - -This policy setting determines which users can adjust the time zone that is used by the device for displaying the local time, which includes the device's system time plus the time zone offset. - -Constant: SeTimeZonePrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -None. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not Defined| -| Default Domain Controller Policy | Administrators
Users| -| Stand-Alone Server Default Settings | Administrators
Users| -| Domain Controller Effective Default Settings | Administrators
Users| -| Member Server Effective Default Settings | Administrators
Users| -| Client Computer Effective Default Settings | Administrators
Users| - -## Policy management - -A restart of the device is not required for this policy setting to be effective. - -Any change to the account for this user right assignment becomes effective the next time the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Changing the time zone represents little vulnerability because the system time is not affected. This setting merely enables users to display their preferred time zone while being synchronized with domain controllers in different time zones. - -### Countermeasure - -Countermeasures are not required because system time is not affected by this setting. - -### Potential impact - -None. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md b/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md deleted file mode 100644 index 4b5f9a7ed6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Create a pagefile - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Create a pagefile security policy setting. -ms.assetid: dc087897-459d-414b-abe0-cd86c8dccdea -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Create a pagefile - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Create a pagefile** security policy setting. - -## Reference - -Windows designates a section of the hard drive as virtual memory known as the page file, or more specifically, as pagefile.sys. It's used to supplement the computer’s Random Access Memory (RAM) to improve performance for frequently used programs and data. Although the file is hidden from browsing, you can manage it using the system settings. - -This policy setting determines which users can create and change the size of a page file. It determines whether users can specify a page file size for a particular drive in the **Performance Options** box located on the **Advanced** tab of the **System Properties** dialog box or through using internal application interfaces (APIs). - -Constant: SeCreatePagefilePrivilege - -### Possible values - -- User-defined list of accounts -- Administrators - -### Best practices - -- Restrict the **Create a pagefile** user right to Administrators, which is the default. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators group have this right. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Administrators | -| Default Domain Controller Policy | Administrators | -| Stand-Alone Server Default Settings | Administrators | -| Domain Controller Effective Default Settings | Administrators | -| Member Server Effective Default Settings | Administrators | -| Client Computer Effective Default Settings | Administrators | - -## Policy management - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can change the page file size could make it small or move the file to a highly fragmented storage volume, which could cause reduced device performance. - -### Countermeasure - -Restrict the **Create a pagefile** user right to members of the Administrators group. - -### Potential impact - -None. Restricting this right to members of the Administrators group is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md b/windows/security/threat-protection/security-policy-settings/create-a-token-object.md deleted file mode 100644 index e45a81f726..0000000000 --- a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Create a token object -description: Describes the best practices, location, values, policy management, and security considerations for the Create a token object security policy setting. -ms.assetid: bfbf52fc-6ba4-442a-9df7-bd277e55729c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Create a token object - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Create a token object** security policy setting. - -## Reference - -This policy setting determines which accounts a process can use to create a token, and which accounts it can then use to gain access to local resources when the process uses NtCreateToken() or other token-creation APIs. - -When a user signs in to the local device or connects to a remote device through a network, Windows builds the user’s access token. Then the system examines the token to determine the level of the user's privileges. When you revoke a privilege, the change is immediately recorded, but the change isn't reflected in the user's access token until the next time the user logs on or connects. - -Constant: SeCreateTokenPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- This user right is used internally by the operating system. Unless it's necessary, don't assign this user right to a user, group, or process other than Local System. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -This user right is used internally by the operating system. By default, it isn't assigned to any user groups. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined | -| Default Domain Controller Policy | Not Defined | -| Stand-Alone Server Default Settings | Not Defined | -| Domain Controller Effective Default Settings | Local System | -| Member Server Effective Default Settings | Local System | -| Client Computer Effective Default Settings | Local System | - -## Policy management - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - ->**Caution:**  A user account that is given this user right has complete control over the system, and it can lead to the system being compromised. We highly recommend that you do not assign this right to any user accounts. - -Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users sign in to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change isn't reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any account on a computer if they're currently logged on. They could escalate their privileges or create a DoS condition. - -### Countermeasure - -Don't assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account that has this user right assigned. - -### Potential impact - -None. Not Defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/create-global-objects.md b/windows/security/threat-protection/security-policy-settings/create-global-objects.md deleted file mode 100644 index e20df384f0..0000000000 --- a/windows/security/threat-protection/security-policy-settings/create-global-objects.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Create global objects -description: Describes the best practices, location, values, policy management, and security considerations for the Create global objects security policy setting. -ms.assetid: 9cb6247b-44fc-4815-86f2-cb59b6f0221e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Create global objects - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Create global objects** security policy setting. - -## Reference - -This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they don't have this user right. - -A global object is an object that can be used by any number of processes or threads, even those processes or threads not started within the user’s session. Remote Desktop Services uses global objects in its processes to facilitate connections and access. - -Constant: SeCreateGlobalPrivilege - -### Possible values - -- User-defined list of accounts -- Default accounts listed below - -### Best practices - -- Don't assign any user accounts this right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators group have this right, as do Local Service and Network Service accounts on the supported versions of Windows. Service is included for backwards compatibility with earlier versions of Windows. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined | -| Default Domain Controller Policy | Administrators
Local Service
Network Service
Service| -| Stand-Alone Server Default Settings | Administrators
Local Service
Network Service
Service| -| Domain Controller Effective Default Settings | Administrators
Local Service
Network Service
Service| -| Member Server Effective Default Settings | Administrators
Local Service
Network Service
Service| -| Client Computer Effective Default Settings | Administrators
Local Service
Network Service
Service| - -## Policy management - -A restart of the device isn't required for this policy setting to take effect. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Create global objects** user right is required for a user account to create global file mapping and symbolic link objects. Users can still create session-specfic objects without being assigned this user right. Assigning this right can be a security risk. - -By default, members of the **Administrators** group, the System account, and services that are started by the Service Control Manager are assigned the **Create global objects** user right. Users who are added to the **Remote Desktop Users** group also have this user right. - -### Countermeasure - -When non-administrators need to access a server using Remote Desktop, add the users to the **Remote Desktop Users** group rather than assigning them this user right. - -### Potential impact - -None. Not Defined is the default domain policy configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md b/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md deleted file mode 100644 index 8e28020f73..0000000000 --- a/windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Create permanent shared objects -description: Describes the best practices, location, values, policy management, and security considerations for the Create permanent shared objects security policy setting. -ms.assetid: 6a58438d-65ca-4c4a-a584-450eed976649 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Create permanent shared objects - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Create permanent shared objects** security policy setting. - -## Reference - -This user right determines which accounts can be used by processes to create a directory object by using the object manager. Directory objects include Active Directory objects, files and folders, printers, registry keys, processes, and threads. Users who have this capability can create permanent shared objects, including devices, semaphores, and mutexes. This user right is useful to kernel-mode components that extend the object namespace. Because components that are running in kernel-mode inherently have this user right assigned to them, it is not necessary to specifically assign it. - -Constant: SeCreatePermanentPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Users who have the **Create permanent shared objects** user right could create new shared objects and expose sensitive data to the network. Therefore, do not assign this right to any users. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, **LocalSystem** is the only account that has this right. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined| -| Default Domain Controller Policy | Not Defined | -| Stand-Alone Server Default Settings | Not Defined| -| Domain Controller Effective Default Settings | **LocalSystem**| -| Member Server Effective Default Settings | **LocalSystem**| -| Client Computer Effective Default Settings | **LocalSystem**| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -A restart of the device is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who have the **Create permanent shared objects** user right could create new shared objects and expose sensitive data to the network. - -### Countermeasure - -Do not assign the **Create permanent shared objects** user right to any users. Processes that require this user right should use the System account, which already includes this user right, instead of a separate user account. - -### Potential impact - -None. Not Defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md deleted file mode 100644 index d0a05e5cde..0000000000 --- a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Create symbolic links -description: Describes the best practices, location, values, policy management, and security considerations for the Create symbolic links security policy setting. -ms.assetid: 882922b9-0ff8-4ee9-8afc-4475515ee3fd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Create symbolic links - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Create symbolic links** security policy setting. - -## Reference - -This user right determines if users can create a symbolic link from the device they're logged on to. - -A symbolic link is a file system object that points to another file system object that is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links. - -> [!WARNING] -> This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them. - -Constant: SeCreateSymbolicLinkPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Only trusted users should get this user right. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators group have this right. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not Defined| -| Default Domain Controller Policy | Not Defined| -| Stand-Alone Server Default Settings | Not Defined| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -- Local policy settings -- Site policy settings -- Domain policy settings -- OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -### Command-line tools - -This setting can be used in conjunction with a symbolic link file system setting that can be manipulated with the command-line tool to control the kinds of symlinks that are allowed on the device. For more info, type `fsutil behavior set symlinkevaluation /?` at the command prompt. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who have the **Create symbolic links** user right could inadvertently or maliciously expose your system to symbolic link attacks. Symbolic link attacks can be used to change the permissions on a file, to corrupt data, to destroy data, or as a DoS attack. - -### Countermeasure - -Don't assign the **Create symbolic links** user right to standard users. Restrict this right to trusted administrators. You can use the **fsutil** command to establish a symbolic link file system setting that controls the kind of symbolic links that can be created on a computer. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md deleted file mode 100644 index 784e63d190..0000000000 --- a/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax -description: Learn about best practices and more for the syntax policy setting, DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL). -ms.assetid: 0fe3521a-5252-44df-8a47-8d92cf936e7c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. - -## Reference - -This policy setting allows you to define other computer-wide controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a device. These controls restrict call, activation, or launch requests on the device. A simple way to think about these access controls is as an extra access check that is performed against a device-wide access control list (ACL) on each call, activation, or launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM-based server. This policy setting controls access permissions to cover call rights. - -These device-wide ACLs provide a way to override weak security settings that are specified by an application through the CoInitializeSecurity function or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific server. - -These ACLs also provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers on the device. - -This policy setting allows you to specify an ACL in two different ways. You can type the security descriptor in SDDL, or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you're running. - -### Possible values - -- *User-defined input* of the SDDL representation of the groups and privileges - - When you specify the users or groups that are to be given permissions, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges for local access and remote access. - -- Blank - - This value represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it as Not defined. To set a blank value, select "Define this policy setting" and leave the Security descriptor empty, and then select OK. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value -| - | - | -| Default Domain Policy | Blank | -| Default Domain Controller Policy | Blank | -| Stand-Alone Server Default Settings | Blank | -| DC Effective Default Settings | Not defined | -| Member Server Effective Default Settings | Not defined | -| Client Computer Effective Default Settings | Not defined | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -The registry settings that are created as a result of enabling the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting take precedence over the previous registry settings when this policy setting was configured. The Remote Procedure Call (RPC) service checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This precedence means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, device access permissions for users aren't changed. Use care in configuring the list of users and groups. - -If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in the Windows operating system, the administrator can use the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting to manage DCOM access to the computer. The administrator can use this setting to specify which users and groups can access the DCOM application on the computer locally and remotely. This setting will restore control of the DCOM application to the administrator and users. To define this setting, open the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click -**Edit Security**. Specify the users or groups you want to include and the computer access permissions for those users or groups. This information defines the setting and sets the appropriate SDDL value. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. Administrators can't override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls. - -Also, the COM infrastructure includes the Remote Procedure Call Services (RPCSS), a system service that runs during and after computer startup. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote access, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers. - -### Countermeasure - -To protect individual COM-based applications or services, set the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting to an appropriate device-wide ACL. - -### Potential impact - -Windows implements default COM ACLs when they're installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific call permissions that ACL assigns are the correct permissions for appropriate users. If it doesn't, you must change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM don't fail. - -## Related topics - -- [Security Options](security-options.md) - - diff --git a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md deleted file mode 100644 index 6f20c35a59..0000000000 --- a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax -description: Best practices and more for the security policy setting, DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax. -ms.assetid: 4b95d45f-dd62-4c34-ba32-43954528dabe -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting. - -## Reference - -This policy setting is similar to the [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md) setting in that it allows you to define more computer-wide controls that govern access to all DCOM–based applications on a device. However, the ACLs that are specified in this policy setting control local and remote COM launch requests (not access requests) on the device. A simple way to think about this access control is as an extra access check that is performed against a device-wide ACL on each launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM-based server. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting differs in that it provides a minimum access check that is applied to attempts to access an already launched COM-based server. - -These device-wide ACLs provide a way to override weak security settings that are specified by an application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific COM-based server. These ACLs provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers. -The **DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax** setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can grant or deny Local -Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you're running. - -### Possible values - -- Blank - - This value represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it as Not defined. To set a blank value, select "Define this policy setting" and leave the Security descriptor empty, then select OK. - -- *User-defined input* of the SDDL representation of the groups and privileges - - When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Blank | -| Default Domain Controller Policy | Blank| -| Stand-Alone Server Default Settings |Blank | -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined | -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -The registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. The Remote Procedure Call (RPC) service (RpcSs) checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE. - -If you're denied access to activate and launch DCOM applications due to the changes made to DCOM in the Windows operating system, this policy setting can be used to control the DCOM activation and launch to the device. - -You can specify which users and groups can launch and activate DCOM applications on the device locally and remotely by using the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. This setting restores control of the DCOM application to the administrator and specified users. To define this setting, open the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click **Edit Security**. Specify the groups that you want to include and the device launch permissions for those groups. This information defines the setting and sets the appropriate SDDL value. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. You can't override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls. - -Also, the COM infrastructure includes the Remote Procedure Call Service (RPCSS), a system service that runs during computer startup and always runs after the startup. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote component activation, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users using remote, unauthenticated computers. - -### Countermeasure - -To protect individual COM-based applications or services, set this policy setting to an appropriate computer-wide ACL. - -### Potential impact - -Windows implements default COM ACLs when they're installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific launch permissions ACL assigns include activation permissions to appropriate users. If it doesn't, you must change your application-specific launch permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM don't fail. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/debug-programs.md b/windows/security/threat-protection/security-policy-settings/debug-programs.md deleted file mode 100644 index f0d787d7a9..0000000000 --- a/windows/security/threat-protection/security-policy-settings/debug-programs.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Debug programs -description: Describes the best practices, location, values, policy management, and security considerations for the Debug programs security policy setting. -ms.assetid: 594d9f2c-8ffc-444b-9522-75615ec87786 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Debug programs - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Debug programs** security policy setting. - -## Reference - -This policy setting determines which users can attach to or open any process, even a process they do not own. Developers who are debugging their own applications do not need this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating-system components. - -Constant: SeDebugPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- Assign this user right only to trusted users to reduce security vulnerabilities. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, members of the Administrators group have this right. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Administrators | -| Stand-Alone Server Default Settings | Administrators | -| Domain Controller Effective Default Settings | Administrators | -| Member Server Effective Default Settings | Administrators | -| Client Computer Effective Default Settings | Administrators | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -A restart of the device is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Debug programs** user right can be exploited to capture sensitive device information from system memory or to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed passwords and other private security information or to insert malware. -By default, the **Debug programs** user right is assigned only to administrators, which helps mitigate risk from this vulnerability. - -### Countermeasure - -Remove the accounts of all users and groups that do not require the **Debug programs** user right. - -### Potential impact - -If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this capability on production devices. If an issue arises that requires an application to be debugged on a production server, you can move the server to a different organizational unit (OU) -temporarily and assign the **Debug programs** user right to a separate Group Policy for that OU. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md deleted file mode 100644 index 446fad10ca..0000000000 --- a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Deny access to this computer from the network -description: Best practices, location, values, policy management, and security considerations for the Deny access to this computer from the network security policy setting. -ms.assetid: 935e9f89-951b-4163-b186-fc325682bb0b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 05/19/2021 ---- - -# Deny access to this computer from the network - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Deny access to this computer from the network** security policy setting. - -## Reference - -This security setting determines which users are prevented from accessing a device over the network. - -Constant: SeDenyNetworkLogonRight - -### Possible values - -- User-defined list of accounts -- Guest - -### Best practices - -- Because all Active Directory Domain Services programs use a network logon for access, use caution when you assign this user right on domain controllers. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this setting is Guest on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Guest | -| Stand-Alone Server Default Settings | Guest | -| Domain Controller Effective Default Settings | Guest | -| Member Server Effective Default Settings | Guest | -| Client Computer Effective Default Settings | Guest | - -## Policy management - -This section describes features and tools available to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -This policy setting supersedes the **Access this computer from the network** policy setting if a user account is subject to both policies. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can sign in to the device over the network can enumerate lists of account names, group names, and shared resources. Users with permission to access shared folders and files can connect over the network and possibly view or modify data. - -### Countermeasure - -Assign the **Deny access to this computer from the network** user right to the following accounts: - -- Anonymous sign in -- Built-in local Administrator account -- Local Guest account -- All service accounts - -An important exception to this list is any service accounts that are used to start services that must connect to the device over the network. For example, let’s say you've configured a shared folder for web servers to access, and you present content within that folder through a website. You may need to allow the account that runs IIS to sign in to the server with the shared folder from the network. This user right is effective when you must configure servers and workstations on which sensitive information is handled because of regulatory compliance concerns. - -> [!NOTE] -> If the service account is configured in the logon properties of a Windows service, it requires network logon rights to the domain controllers to start properly. - -### Potential impact - -If you configure the **Deny access to this computer from the network** user right for other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify that delegated tasks aren't negatively affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md deleted file mode 100644 index 49ad4d216d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Deny log on as a batch job -description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a batch job security policy setting. -ms.assetid: 0ac36ebd-5e28-4b6a-9b4e-8924c6ecf44b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Deny log on as a batch job - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Deny log on as a batch job** security policy setting. - -## Reference - -This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to schedule and start jobs automatically in the future. The ability to sign in by using a batch-queue tool is needed for any account that is used to start scheduled jobs with the Task Scheduler. - -Constant: SeDenyBatchLogonRight - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -1. When you assign this user right, thoroughly test that the effect is what you intended. -2. Within a domain, modify this setting on the applicable Group Policy Object (GPO). -3. **Deny log on as a batch job** prevents administrators or operators from using their personal accounts to schedule tasks. This restriction helps with business continuity when that person transitions to other positions or responsibilities. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Not defined | -| Domain Controller Effective Default Settings | Not defined | -| Member Server Effective Default Settings | Not defined | -| Client Computer Effective Default Settings | Not defined | - -## Policy management - -This section describes features and tools available to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -This policy setting might conflict with and negate the **Log on as a batch job** setting. - -### Group Policy - -On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting. - -For example, to configure Task Scheduler on your domain controller, check the Settings tab of your two domain controller policy and domain policy GPOs in the Group Policy Management Console (GPMC). Verify the targeted account isn't present in the **Deny log on as a batch job** setting. - -User Rights Assignment and also correctly configured in the **Log on as a batch job** setting. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Accounts that have the **Log on as a batch job** user right could be used to schedule jobs that could consume excessive computer resources and cause a denial-of-service condition. - -### Countermeasure - -Assign the **Deny log on as a batch job** user right to the local Guest account. - -### Potential impact - -If you assign the **Deny log on as a batch job** user right to other accounts, you could deny the ability to perform required job activities to users who are assigned specific administrative roles. Confirm that delegated tasks aren't affected adversely. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md deleted file mode 100644 index d2a042c022..0000000000 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Deny log on as a service -description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a service security policy setting. -ms.assetid: f1114964-df86-4278-9b11-e35c66949794 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Deny log on as a service - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Deny log on as a service** security policy setting. - -## Reference - -This policy setting determines which users are prevented from logging on to the service applications on a device. - -A service is an application type that runs in the system background without a user interface. It provides core operating system features, such as web serving, event logging, file serving, printing, cryptography, and error reporting. - -Constant: SeDenyServiceLogonRight - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -1. When you assign this user right, thoroughly test that the effect is what you intended. -2. Within a domain, modify this setting on the applicable Group Policy Object (GPO). - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined | -| Domain Controller Effective Default Settings | Not defined | -| Member Server Effective Default Settings | Not defined | -| Client Computer Effective Default Settings | Not defined | - -## Policy management - -This section describes features and tools available to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting. - -This policy setting might conflict with and negate the **Log on as a service** setting. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Accounts that can sign in to a service application could be used to configure and start new unauthorized services, such as a keylogger or other malware. The benefit of the specified countermeasure is reduced by the fact that only users with administrative rights can install and configure -services, and an attacker who already has that level of access could configure the service to run by using the System account. - -### Countermeasure - -We recommend that you don't assign the **Deny log on as a service** user right to any accounts. This configuration is the default. Organizations that have strong concerns about security might assign this user right to groups and accounts when they're certain that they'll never need to sign in to a service application. - -### Potential impact - -If you assign the **Deny log on as a service** user right to specific accounts, services may not start and a denial-of-service condition could result. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md deleted file mode 100644 index 709c72bee4..0000000000 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Deny log on locally -description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on locally security policy setting. -ms.assetid: 00150e88-ec9c-43e1-a70d-33bfe10434db -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Deny log on locally - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Deny log on locally** security policy setting. - -## Reference - -This policy setting determines which users are prevented from logging on directly at the device's console. - -Constant: SeDenyInteractiveLogonRight - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -1. Assign the **Deny log on locally** user right to the local guest account to restrict access by potentially unauthorized users. -2. Test your modifications to this policy setting in conjunction with the **Allow log on locally** policy setting to determine if the user account is subject to both policies. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -If you apply this policy setting to the Everyone group, no one will be able to sign in locally. - -### Group Policy - -This policy setting supersedes the **Allow log on locally** policy setting if a user account is subject to both policies. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any account with the ability to sign in locally could be used to sign in at the console of the device. If this user right isn't restricted to legitimate users who must sign in to the console of the device, unauthorized users might download and run malicious software that elevates their user rights. - -### Countermeasure - -Assign the **Deny log on locally** user right to the local Guest account. If you have installed optional components such as ASP.NET, you may want to assign this user right to other accounts that are required by those components. - -### Potential impact - -If you assign the **Deny log on locally** user right to other accounts, you could limit the abilities of users who are assigned to specific roles in your environment. However, this user right should explicitly be assigned to the ASPNET account on devices that are configured with the Web Server role. You should confirm that delegated activities aren't adversely affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md deleted file mode 100644 index c6dfb97ab1..0000000000 --- a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Deny log on through Remote Desktop Services -description: Best practices, location, values, policy management, and security considerations for the security policy setting, Deny log on through Remote Desktop Services. -ms.assetid: 84bbb807-287c-4acc-a094-cf0ffdcbca67 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Deny log on through Remote Desktop Services - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Deny log on through Remote Desktop Services** security policy setting. - -## Reference - -This policy setting determines which users are prevented from logging on to the device through a Remote Desktop connection through Remote Desktop Services. It's possible for a user to establish a Remote Desktop connection to a particular server, but not be able to sign in to the console of that server. - -Constant: SeDenyRemoteInteractiveLogonRight - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- To control who can open a Remote Desktop connection and sign in to the device, add the user account to or remove user accounts from the Remote Desktop Users group. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -The **Remote System** property controls settings for Remote Desktop Services (**Allow or prevent remote connections to the computer**) and for Remote Assistance (**Allow Remote Assistance connections to this computer**). - -### Group Policy - -This policy setting supersedes the [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md) policy setting if a user account is subject to both policies. - -Group Policy settings are applied in the following order. They overwrite settings on the local device at the next Group Policy update. - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. Organizational unit policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any account with the right to sign in through Remote Desktop Services could be used to sign in to the remote console of the device. If this user right isn't restricted to legitimate users who need to sign in to the console of the computer, malicious users might download and run software that elevates their user rights. - -### Countermeasure - -Assign the **Deny log on through Remote Desktop Services** user right to the built-in local guest account and all service accounts. If you have installed optional components, such as ASP.NET, you may want to assign this user right to other accounts that are required by those components. - -### Potential impact - -If you assign the **Deny log on through Remote Desktop Services** user right to other groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. Accounts that have this user right can't connect to the device through Remote Desktop Services or Remote Assistance. You should confirm that delegated tasks aren't negatively affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md b/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md deleted file mode 100644 index a2514e41a3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Devices Allow undock without having to log on -description: Describes the best practices, location, values, and security considerations for the Devices Allow undock without having to sign in security policy setting. -ms.assetid: 1d403f5d-ad41-4bb4-9f4a-0779c1c14b8c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Devices: Allow undock without having to log on - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting. - -## Reference - -This policy setting enables or disables the ability of a user to remove a portable device from a docking station without logging on. If you enable this policy setting, users can press a docked portable device's physical eject button to safely undock the device. If you disable this policy setting, the user must sign in to receive permission to undock the device. Only users who have the **Remove Computer from Docking Station** privilege can obtain this permission. - ->**Note:**  Disabling this policy setting only reduces theft risk for portable devices that cannot be mechanically undocked. Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality. - -Enabling this policy setting means that anyone with physical access to a device that has been placed in its docking station can remove the computer and possibly tamper with it. For devices that don't have docking stations, this policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access to these devices - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -It's advisable to disable the **Devices: Allow undock without having to log on** policy setting. Users who have docked their devices will have to sign in to the local console before they can undock their systems. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings | Enabled| -| Client Computer Effective Default Settings| Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If this policy setting is enabled, anyone with physical access to portable computers in docking stations could remove them and possibly tamper with them. - -### Countermeasure - -Disable the **Devices: Allow undock without having to log on** setting. - -### Potential impact - -Users who have docked their device must sign in to the local console before they can undock their computers. For devices that don't have docking stations, this policy setting has no impact. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md b/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md deleted file mode 100644 index 515856c7f7..0000000000 --- a/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Devices Allowed to format and eject removable media -description: Describes the best practices, location, values, and security considerations for the Devices Allowed to format and eject removable media security policy setting. -ms.assetid: d1b42425-7244-4ab1-9d46-d68de823459c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Devices: Allowed to format and eject removable media - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting. - -## Reference - -This policy setting determines who is allowed to format and eject removable media. - -Users can move removable disks to a different device where they have administrative user rights and then take ownership of any file, assign themselves full control, and view or modify any file. The advantage of configuring this policy setting is diminished by the fact that most removable storage devices will eject media with the press of a button. - -### Possible values - -- Administrators -- Administrators and Power Users -- Administrators and Interactive Users (not applicable to Windows Server 2008 R2 or Windows 7 and later) -- Not defined - -### Best practices - -- It's advisable to set **Allowed to format and eject removable media** to **Administrators**. Only administrators will be able to eject NTFS-formatted removable media. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Administrators| -| DC Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users could move data on removable disks to a different computer where they have administrative privileges. The user could then take ownership of any file, grant themselves full control, and view or modify any file. The fact that most removable storage devices eject media when a mechanical button -is pressed diminishes the advantage of this policy setting. - -### Countermeasure - -Configure the **Devices: Allowed to format and eject removable media** setting to **Administrators**. - -### Potential impact - -Only administrators can format and eject removable media. If users are in the habit of using removable media for file transfers and storage, they must be informed of the change in policy. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md b/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md deleted file mode 100644 index 9590fbf54b..0000000000 --- a/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Devices Prevent users from installing printer drivers -description: Describes the best practices, location, values, and security considerations for the Devices Prevent users from installing printer drivers security policy setting. -ms.assetid: ab70a122-f7f9-47e0-ad8c-541f30a27ec3 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 01/05/2022 ---- - -# Devices: Prevent users from installing printer drivers - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting. - -## Reference - -For a device to print to a network printer, the driver for that network printer must be installed locally. The **Devices: Prevent users from installing printer drivers** policy setting determines who can install a printer driver as part of adding a network printer. When you set the value to **Enabled**, only Administrators and Power Users can install a printer driver as part of adding a network printer. Setting the value to **Disabled** allows any user to install a printer driver as part of adding a network printer. This setting prevents unprivileged users from downloading and installing an untrusted printer driver. - -This setting has no impact if you've configured a trusted path for downloading drivers. If trusted paths are being used, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver isn't installed and the network printer isn't added. - -Although it might be appropriate in some organizations to allow users to install printer drivers on their own workstations, this idea isn't suitable for servers. Installing a printer driver on a server can cause the system to become less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to damage the system by installing inappropriate printer drivers. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- It's advisable to set **Devices: Prevent users from installing printer drivers** to Enabled. Only users in the Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy setting is enabled, but the driver for a network printer already exists on the local computer, users can still add the network printer. This policy setting doesn't affect a user's ability to add a local printer. - -> [!NOTE] -> After applying the [July 6, 2021 updates](https://support.microsoft.com/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7), non-administrators, including delegated admin groups like printer operators, cannot install signed and unsigned printer drivers to a print server. By default, only administrators can install both signed and unsigned printer drivers to a print server. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings | Enabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -It may be appropriate in some organizations to allow users to install printer drivers on their own workstations. However, you should allow only administrators, not users, to do so on servers because printer driver installation on a server may unintentionally cause the computer to become less -stable. A malicious user could install inappropriate printer drivers in a deliberate attempt to damage the computer, or a user might accidentally install malicious software that masquerades as a printer driver. - -### Countermeasure - -Enable the **Devices: Prevent users from installing printer drivers** setting. - -### Potential impact - -Only members of the Administrator, Power Users, or Server Operator groups can install printers on the servers. If this policy setting is enabled but the driver for a network printer already exists on the local computer, users can still add the network printer. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md b/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md deleted file mode 100644 index 5ccf446d9e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Restrict CD-ROM access to locally logged-on user -description: Describes the best practices, location, values, and security considerations for the Devices Restrict CD-ROM access to locally logged-on user only security policy setting. -ms.assetid: 8b8f44bb-84ce-4f18-af30-ab89910e234d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Devices: Restrict CD-ROM access to locally logged-on user only - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Devices: Restrict CD-ROM access to locally logged-on user only** security policy setting. - -## Reference - -This policy setting determines whether a CD is accessible to local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CDs. If this policy setting is enabled and no one is logged on interactively, the CD can be accessed over the network. - -The security benefit of enabling this policy setting is small because it only prevents network users from accessing the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives aren't automatically made available as network shared drives; you must deliberately choose to share the drive. This setting to share is important when administrators are installing software or copying data from a CD-ROM, and they don't want network users to be able to execute the applications or view the data. - -If this policy setting is enabled, users who connect to the server over the network won't be able to use any CD drives that are installed on the server when anyone is logged on to the local console of the server. Enabling this policy setting isn't suitable for a system that serves as a CD jukebox for network users. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Best practices are dependent on your security and user accessibility requirements for CD drives. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because CD drives aren't automatically made available as shared drives; you must deliberately choose to share the drive. However, you can deny network users the ability to view data or run -applications from removable media on the server. - -### Countermeasure -Enable the **Devices: Restrict CD-ROM drive access to locally logged-on user only** setting. - -### Potential impact -Users who connect to the server over the network can't use any CD drives that are installed on the server when anyone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the computer when it initializes, and if the service can't access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. This policy setting wouldn't be suitable for a computer that serves as a CD jukebox for network users. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md b/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md deleted file mode 100644 index b4a13d2337..0000000000 --- a/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Devices Restrict floppy access to locally logged-on user only -description: Describes the best practices, location, values, and security considerations for the Devices Restrict floppy access to locally logged-on user only security policy setting. -ms.assetid: 92997910-da95-4c03-ae6f-832915423898 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Devices: Restrict floppy access to locally logged-on user only - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Devices: Restrict floppy access to locally logged-on user only** security policy setting. - -## Reference - -This policy setting determines whether removable floppy disks are accessible to local and remote users simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable floppy disks. If this policy setting is enabled and no one is logged on interactively, the floppy disk can be accessed over the network. - -The security benefit of enabling this policy setting is small because it only prevents network users from accessing the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally, floppy disk drives aren't automatically made available as network shared drives; you must deliberately choose to share the drive. This setting to share becomes important when you're installing software or copying data from a floppy disk and they don't want network users to be able to execute the applications or view the data. - -If this policy setting is enabled, users who connect to the server over the network won't be able to use any floppy disk drives that are installed on the server when anyone is logged on to the local console of the server. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Best practices are dependent on your security and user accessibility requirements for CD drives. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small because floppy disk drives aren't automatically shared; administrators must deliberately choose to share the drive. However, you can deny network users the ability to view data or run applications from removable media on the server. - -### Countermeasure - -Enable the **Devices: Restrict floppy access to locally logged-on user only** setting. - -### Potential impact - -Users who connect to the server over the network can't use any floppy disk drives that are installed on the device when anyone is logged on to the local console of the server. System tools that require access to floppy disk drives fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are present on the computer when it initializes, and if the service can't access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md b/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md deleted file mode 100644 index 2757a09e31..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Domain controller Allow server operators to schedule tasks -description: Describes the best practices, location, values, and security considerations for the Domain controller Allow server operators to schedule tasks security policy setting. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain controller: Allow server operators to schedule tasks - -**Applies to** -- Windows Server - -Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting. - -## Reference - -This policy setting determines whether server operators can use the **at** command to submit jobs. If you enable this policy setting, jobs that are created by server operators by means of the **at** command run in the context of the account that runs the Task Scheduler service. By default, that account is the Local System account. - ->**Note:**  This security option setting affects only the scheduler tool for the **at** command. It does not affect the Task Scheduler tool. - -Enabling this policy setting means jobs that are created by server operators through the **at** command will be executed in the context of the account that is running that service—by default, that is, the Local System account. This synchronization with the local account means that server operators can perform tasks that the Local System account is able to do, but server operators would normally not be able to do, such as add their account to the local Administrators group. - -The impact of enabling this policy setting should be small for most organizations. Users, including those users in the Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run in the context of the account that the user authenticates with when setting up the job. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Best practices for this policy are dependent on your security and operational requirements for task scheduling. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Command-line tools - -The **at** command schedules commands and programs to run on a computer at a specified time and date. The Schedule service must be running to use the **at** command. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Tasks that run under the context of the Local System account can affect resources that are at a higher privilege level than the user account that scheduled the task. - -### Countermeasure - -Disable the **Domain controller: Allow server operators to schedule tasks** setting. - -### Potential impact - -The impact should be small for most organizations. Users (including those users in the Server Operators group) can still create jobs through the Task Scheduler snap-in. However, those jobs run in the context of the account that the user authenticates with when setting up the job. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-channel-binding-token-requirements.md b/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-channel-binding-token-requirements.md deleted file mode 100644 index ecf16ca65c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-channel-binding-token-requirements.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Domain controller LDAP server channel binding token requirements -description: Describes the best practices, location, values, and security considerations for the Domain controller LDAP server channel binding token requirements security policy setting. -ms.reviewer: waynmc -ms.author: waynmc -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 04/26/2023 ---- - -# Domain controller: LDAP server channel binding token requirements - -**Applies to**: - -- Windows Server - -This article describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server channel binding token requirements** security policy setting. - -## Reference - -This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate channel bindings (EPA). - -Unsigned/Unprotected network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the example of an LDAP server, a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks difficult. - -- If channel binding is set to Always, LDAP clients who don't support channel bindings will be rejected. -- If channel binding is set to when supported, only incorrect channel bindings will be blocked, and clients who don't support channel binding can continue to connect via LDAP over TLS. - -CBT or EPA is used with TLS sessions when a SASL authentication method is used to authenticate the user. SASL means you use NTLM or Kerberos for user authentication. LDAP Simple Bind over TLS doesn't offer channel binding token protection and is therefore not recommended. - -### Possible values - -- **Never**: No channel binding validation is performed. This is the behavior of all servers that haven't been updated. -- **When Supported**: Clients that advertise support for Channel Binding Tokens must provide the correct token when authenticating over TLS/SSL connections; clients that don't advertise such support and/or don't use TLS/SSL connections aren't impacted. This is an intermediate option that allows for application compatibility. -- **Always**: All clients must provide channel binding information over LDAPS. The server rejects LDAPS authentication requests from clients that don't do so. - -### Best practices - -We recommend that you set **Domain controller: LDAP server channel binding token requirements** to **Always**. Clients that don't support LDAP channel binding will be unable to execute LDAP queries against the domain controllers. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -|--------------------------------------------|---------------| -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Not defined | -| DC Effective Default Settings | None | -| Member Server Effective Default Settings | None | -| Client Computer Effective Default Settings | None | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Unsigned/Unprotected network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client device, modifies them, and then forwards them to the client device. Regarding LDAP servers, an attacker could cause a client device to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks difficult. - -### Countermeasure - -Configure the **Domain controller: LDAP server channel binding token requirements** setting to **Always**. - -### Potential impact - -Client devices that don't support LDAP channel binding can't run LDAP queries against the domain controllers. - -## Related articles - -- [Security Options](security-options.md) -- [LDAP session security settings and requirements after ADV190023 is installed](/troubleshoot/windows-server/identity/ldap-session-security-settings-requirements-adv190023) -- [2020 LDAP channel binding and LDAP signing requirements for Windows (KB4520412)](https://support.microsoft.com/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a) -- [KB4034879: Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure](https://support.microsoft.com/topic/kb4034879-use-the-ldapenforcechannelbinding-registry-entry-to-make-ldap-authentication-over-ssl-tls-more-secure-e9ecfa27-5e57-8519-6ba3-d2c06b21812e) diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md deleted file mode 100644 index b46d83e1d6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Domain controller LDAP server signing requirements -description: Describes the best practices, location, values, and security considerations for the Domain controller LDAP server signing requirements security policy setting. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain controller: LDAP server signing requirements - -**Applies to** -- Windows Server - -This article describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting. - -## Reference - -This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing. - -Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the example of an LDAP server, a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks difficult. - -This setting doesn't have any impact on LDAP simple bind through SSL (LDAP TCP/636). - -If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389). - ->**Caution:**  If you set the server to Require signature, you must also set the client device. Not setting the client device results in loss of connection with the server. - -### Possible values - -- None. Data signatures aren't required to bind with the server. If the client computer requests data signing, the server supports it. -- Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use. -- Not defined. - -### Best practices - -- We recommend that you set **Domain controller: LDAP server signing requirements** to **Require signature**. Clients that don't support LDAP signing will be unable to execute LDAP queries against the domain controllers. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | None| -| Member Server Effective Default Settings | None| -| Client Computer Effective Default Settings | None| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client device, modifies them, and then forwards them to the client device. Regarding LDAP servers, an attacker could cause a client device to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks difficult. - -### Countermeasure - -Configure the **Domain controller: LDAP server signing requirements** setting to **Require signature**. - -### Potential impact - -Client devices that don't support LDAP signing can't run LDAP queries against the domain controllers. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md b/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md deleted file mode 100644 index 453dae2c04..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Refuse machine account password changes policy -description: Describes the best practices, location, values, and security considerations for the Domain controller Refuse machine account password changes security policy setting. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 12/31/2017 ---- - -# Domain controller: Refuse machine account password changes - -**Applies to** -- Windows Server - -Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting. - -## Reference - -This policy setting enables or disables blocking a domain controller from accepting password change requests for machine accounts. By default, devices joined to the domain change their machine account passwords every 30 days. If enabled, the domain controller will refuse machine account password change requests. - -### Possible values - -- **Enabled** When enabled, this setting doesn't allow a domain controller to accept any changes to a machine account's password. - -- **Disabled** When disabled, this setting allows a domain controller to accept any changes to a machine account's password. - -- **Not defined** Same as Disabled. - -### Best practices - -- Enabling this policy setting on all domain controllers in a domain prevents domain members from changing their machine account passwords. This prevention, in turn, leaves those passwords susceptible to attack. Ensure that this setting conforms to your overall security policy for the domain. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -The policy referenced configures the following registry value: - -Registry Hive: HKEY_LOCAL_MACHINE -Registry Path: \System\CurrentControlSet\Services\Netlogon\Parameters\ - -Value Name: RefusePasswordChange - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -|---|---| -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Not defined | -| DC Effective Default Settings | Disabled | -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Not applicable | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you enable this policy setting on all domain controllers in a domain, domain members can't change their machine account passwords, and those passwords are more susceptible to attack. - -### Countermeasure - -Disable the **Domain controller: Refuse machine account password changes** setting. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md deleted file mode 100644 index 00874bb080..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Domain member Digitally encrypt or sign secure channel data (always) -description: Best practices, location, values, and security considerations for the policy setting, Domain member Digitally encrypt or sign secure channel data (always). -ms.assetid: 4480c7cb-adca-4f29-b4b8-06eb68d272bf -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain member: Digitally encrypt or sign secure channel data (always) - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt or sign secure channel data (always)** security policy setting. - -## Reference - -This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. Sign-in information that is transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated. - -The following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic: - -- Domain member: Digitally encrypt or sign secure channel data (always) -- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) -- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) - -Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data. - -To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a device running Windows that has joined a domain to have access to the user account database in its domain and in any trusted domains. - -To enable the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of signing or encrypting all secure-channel data. - -Enabling the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting automatically enables the [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) policy setting. - -When a device joins a domain, a machine account is created. After being connected to the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass-through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Possible values - -- Enabled - - The policy [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) is assumed to be enabled regardless of its current setting. This enablement ensures that the domain member attempts to negotiate at least signing of the secure - channel traffic. - -- Disabled - - The encryption and signing of all secure channel traffic is negotiated with the domain controller, in which case the level of signing and encryption depends on the version of the domain controller and the settings of the following policies: - - 1. [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) - 2. [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) - -- Not defined - ### Best practices - -- Set **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled**. -- Set [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) to **Enabled**. -- Set [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) to **Enabled**. - ->**Note:**  You can enable the policy settings [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) and [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) on all devices in the domain that support these policy settings without affecting earlier-version clients and applications. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Enabled | -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings | Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Distribution of this policy through Group Policy overrides the Local Security Policy setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and -sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the device is configured to encrypt or sign secure channel data, when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Countermeasure - -Select one of the following settings as appropriate for your environment to configure the computers in your domain to encrypt or sign secure channel data. - -- **Domain member: Digitally encrypt or sign secure channel data (always)** -- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) -- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) - -### Potential impact - -Digital encryption and signing of the secure channel is a good idea because the secure channel protects domain credentials as they're sent to the domain controller. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md deleted file mode 100644 index d66e753fe4..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Domain member Digitally encrypt secure channel data (when possible) -description: Best practices, security considerations, and more for the security policy setting, Domain member Digitally encrypt secure channel data (when possible). -ms.assetid: 73e6023e-0af3-4531-8238-82f0f0e4965b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain member: Digitally encrypt secure channel data (when possible) - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt secure channel data (when possible)** security policy setting. - -## Reference - -This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be encrypted. Sign-in information that is transmitted over -the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated. - -In addition to this policy setting, the following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic: - -- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) -- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) - -Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data. - -To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains. - -Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting. - -When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Possible values - -- Enabled - - The domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise, only sign-in information that is transmitted over the secure channel will be encrypted. - -- Disabled - - The domain member won't attempt to negotiate secure channel encryption. - - >**Note:**  If the security policy setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled, this setting will be overwritten. - -- Not defined - -### Best practices - -- Set [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled**. -- Set **Domain member: Digitally encrypt secure channel data (when possible)** to **Enabled**. -- Set [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) to **Enabled**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Enabled| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Distribution of this policy through Group Policy doesn't override the Local Security Policy setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Countermeasure - -Select one of the following settings as appropriate for your environment to configure the computers in your domain to encrypt or sign secure channel data: - -- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) -- **Domain member: Digitally encrypt secure channel data (when possible)** -- [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) - -### Potential impact - -Digital signing of the secure channel is a good idea because it protects domain credentials as they're sent to the domain controller. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md deleted file mode 100644 index 07861eeed3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Domain member Digitally sign secure channel data (when possible) -description: Best practices, location, values, and security considerations for the security policy setting, Domain member Digitally sign secure channel data (when possible). -ms.assetid: a643e491-4f45-40ea-b12c-4dbe47e54f34 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain member: Digitally sign secure channel data (when possible) - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting. - -## Reference - -This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed. Sign-in information that is transmitted over the -secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated. - -The following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic: -- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) -- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) -- Domain member: Digitally sign secure channel data (when possible) - -Setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data. - -To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains. - -Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting. -When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Possible values - -- Enabled - - The domain member will request to sign all secure channel traffic. If the domain controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it can't be tampered with in transit. - -- Disabled - - Signing won't be negotiated unless the policy [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled. - -- Not defined - -### Best practices - -- Set [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled**. -- Set [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) to **Enabled**. -- Set **Domain member: Digitally sign secure channel data (when possible)** to **Enabled**. - >**Note:** You can enable the other two policy settings, Domain member: [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) and **Domain member: Digitally sign secure channel data (when possible)**, on all devices joined to the domain that support these policy settings without affecting earlier-version clients and applications. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Enabled | -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Distribution of this policy through Group Policy doesn't override the Local Security Policy setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated. - -### Countermeasure - -Because these policies are closely related and useful depending on your environment, select one of the following settings as appropriate to configure the devices in your domain to encrypt or sign secure channel data when possible. - -- [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) -- [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md) -- **Domain member: Digitally sign secure channel data (when possible)** - -### Potential impact - -Digital signing of the secure channel is a good idea because the secure channel protects domain credentials as they're sent to the domain controller. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md b/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md deleted file mode 100644 index 83bc426b58..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Domain member Disable machine account password changes -description: Describes the best practices, location, values, and security considerations for the Domain member Disable machine account password changes security policy setting. -ms.assetid: 1f660300-a07a-4243-a09f-140aa1ab8867 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 06/27/2019 ---- - -# Domain member: Disable machine account password changes - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting. - -## Reference - -The **Domain member: Disable machine account password changes** policy setting determines whether a domain member periodically changes its machine account password. Setting its value to **Enabled** prevents the domain member from changing the machine account password. Setting it to **Disabled** allows the domain member to change the machine account password as specified by the value of the [Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md) policy setting, which is every 30 days by default. - -By default, devices that belong to a domain are automatically required to change the passwords for their accounts every 30 days. Devices that are no longer able to automatically change their machine password are at risk of a malicious user determining the password for the system's domain account. -Verify that the **Domain member: Disable machine account password changes** option is set to **Disabled**. - -### Possible values - -- Enabled -- Disabled - -### Best practices - -1. Don't enable this policy setting. Machine account passwords are used to establish secure channel communications between members and domain controllers and between the domain controllers within the domain. After it's established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions. -2. Don't use this policy setting to try to support dual-boot scenarios that use the same machine account. If you want to configure dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to help organizations that stockpile pre-built computers that are put into production months later. Those devices don't have to be rejoined to the domain. -3. You may want to consider using this policy setting in specific environments, such as the following ones: - - - Non-persistent Virtual Desktop Infrastructure implementations. In such implementations, each session starts from a read-only base image. - - Embedded devices that don't have write access to the OS volume. - - In either case, a password change that was made during normal operations would be lost as soon as the session ends. We strongly recommend that you plan password changes for maintenance windows. Add the password changes to the updates and modifications that Windows performs during maintenance windows. To trigger a password update on a specific OS volume, run the following command: - - ``` - Nltest /sc_change_pwd: - ``` - - In this command, \ represents the domain of the local computer. For more information about maintenance windows and non-persistent VDI implementations, see [Optimizing Windows 10, version 1803, for a Virtual Desktop Infrastructure (VDI) role: VDI optimization principles: Non-Persistent VDI](/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-1803#vdi-optimization-principles). - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Disabled | -| Default Domain Controller Policy | Disabled| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -By default, devices running Windows Server that belong to a domain automatically change their passwords for their accounts every certain number of days, typically 30. If you disable this policy setting, devices that run Windows Server retain the same passwords as their machine accounts. Devices -that can't automatically change their account password are at risk from an attacker who could determine the password for the machine's domain account. - -### Countermeasure - -Verify that the **Domain member: Disable machine account password changes** setting is configured to **Disabled**. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md b/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md deleted file mode 100644 index b5f6a01f3e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Domain member Maximum machine account password age -description: Describes the best practices, location, values, and security considerations for the Domain member Maximum machine account password age security policy setting. -ms.assetid: 0ec6f7c1-4d82-4339-94c0-debb2d1ac109 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 05/29/2020 ---- - -# Domain member: Maximum machine account password age - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Maximum machine account password age** security policy setting. - -## Reference - -The **Domain member: Maximum machine account password age** policy setting determines when a domain member submits a password change. - -In Active Directory–based domains, each device has an account and password. By default, the domain members submit a password change every 30 days. You can extend or reduce this interval. Additionally, you can use the **Domain member: Disable machine account password changes** policy to disable the password change requirement completely. However, before you consider this option, review the implications as described in [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md). - -> [!IMPORTANT] -> Significantly increasing the password change interval (or disabling password changes) gives an attacker more time to undertake a brute-force password-guessing attack against one of the machine accounts. - -For more information, see [Machine Account Password Process](https://techcommunity.microsoft.com/t5/Ask-the-Directory-Services-Team/Machine-Account-Password-Process/ba-p/396026). - -### Possible values - -- User-defined number of days between 1 and 999, inclusive -- Not defined - -### Best practices - -We recommend that you set **Domain member: Maximum machine account password age** to about 30 days. Setting the value to fewer days can increase replication and affect domain controllers. For example, in Windows NT domains, machine passwords were changed every 7 days. The extra replication churn would affect domain controllers in large organizations that have many computers or slow links between sites. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | 30 days| -| DC Effective Default Settings | 30 days| -| Member Server Effective Default Settings|30 days| -| Client Computer Effective Default Settings | 30 days| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -By default, the domain members submit a password change every 30 days. If you increase this interval so that the computers no longer submit a password change, an attacker has more time to undertake a brute-force attack to guess the password of one or more computer accounts. - -### Countermeasure - -Configure the **Domain member: Maximum machine account password age** setting to 30 days. - -### Potential impact - -None. This non-impact state is the default configuration. -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md b/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md deleted file mode 100644 index e0b22d6cf2..0000000000 --- a/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Domain member Require strong (Windows 2000 or later) session key -description: Best practices, location, values, and security considerations for the security policy setting, Domain member Require strong (Windows 2000 or later) session key. -ms.assetid: 5ab8993c-5086-4f09-bc88-1b27454526bd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Domain member: Require strong (Windows 2000 or later) session key - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Domain member: Require strong (Windows 2000 or later) session key** security policy setting. - -## Reference - -The **Domain member: Require strong (Windows 2000 or later) session key** policy setting determines whether a secure channel can be established with a domain controller that isn't capable of encrypting secure channel traffic with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any domain controller that can't encrypt secure channel data with a strong key. Disabling this policy setting allows 64-bit session keys. - -Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and session-hijacking network attacks. Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the name of the sender, or it can be redirected. - -### Possible values - -- Enabled - - When enabled on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This capability means that all such domain controllers must be running at least Windows 2000 Server. - -- Disabled - - Allows 64-bit session keys to be used. - -- Not defined. - -### Best practices - -- It's advisable to set **Domain member: Require strong (Windows 2000 or later) session key** to Enabled. Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong encryption key. Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain controllers in all trusted domains support strong keys. By default, this value is disabled. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO - -| Default value | -|--------------------------------------------| -| Default Domain Policy | -| Default Domain Controller Policy | -| Stand-Alone Server Default Settings | -| DC Effective Default Settings | -| Member Server Effective Default Settings | -| Client Computer Effective Default Settings | - -## Policy management - - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Misuse of this policy setting is a common error that can cause data loss or problems with data access or security. - -You'll you be able to join devices that don't support this policy setting to domains where the domain controllers have this policy setting enabled. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger starting with Windows 2000. - -Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from attacks that attempt to hijack network sessions and eavesdrop. (Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or be redirected.) - -### Countermeasure - -Enable the **Domain member: Require strong (Windows 2000 or later) session key** setting. - -If you enable this policy setting, all outgoing secure channel traffic requires a strong encryption key. If you disable this policy setting, the key strength is negotiated. You should enable this policy setting only if the domain controllers in all trusted domains support strong keys. By default, this policy setting is disabled. - -### Potential impact - -Devices that don't support this policy setting can't join domains in which the domain controllers have this policy setting enabled. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md b/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md deleted file mode 100644 index ca2112846d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Trust computer and user accounts for delegation -description: Learn about best practices, security considerations and more for the security policy setting, Enable computer and user accounts to be trusted for delegation. -ms.assetid: 524062d4-1595-41f3-8ce1-9c85fd21497b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Enable computer and user accounts to be trusted for delegation - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Enable computer and user accounts to be trusted for delegation** security policy setting. - -## Reference - -This policy setting determines which users can set the **Trusted for Delegation** setting on a user or computer object. -Security account delegation enables connection to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation. - -Only administrators who have the **Enable computer and user accounts to be trusted for delegation** credential can set up delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to be trusted for delegation depends on the functionality level of the domain. - -The user or machine object that is granted this right must have write access to the account control flags. A server process running on a device (or under a user context) that is trusted for delegation can access resources on another computer by using the delegated credentials of a client. However, the client account must have Write access to the account control flags on the object. - -Constant: SeEnableDelegationPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- There's no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It's only relevant on domain controllers and stand-alone devices. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools and guidance to help you manage this policy. - -Modifying this setting might affect compatibility with clients, services, and applications. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -> [!NOTE] -> More information about configuring the policy can be found [here](how-to-configure-security-policy-settings.md). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Misuse of the **Enable computer and user accounts to be trusted for delegation** user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain access to network resources and make it difficult to determine what has happened -after a security incident. - -### Countermeasure - -The **Enable computer and user accounts to be trusted for delegation** user right should be assigned only if there's a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default. - ->**Note:**  There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone computers. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/enforce-password-history.md b/windows/security/threat-protection/security-policy-settings/enforce-password-history.md deleted file mode 100644 index ed174c38a8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/enforce-password-history.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Enforce password history -description: Describes the best practices, location, values, policy management, and security considerations for the Enforce password history security policy setting. -ms.assetid: 8b2ab871-3e52-4dd1-9776-68bb1e935442 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Enforce password history - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Enforce password history** security policy setting. - -## Reference - -The **Enforce password history** policy setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused. -Password reuse is an important concern in any organization. Many users want to reuse the same password for their account over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but they can reuse an old password, the effectiveness of a good password policy is greatly reduced. - -Specifying a low number for **Enforce password history** allows users to continually use the same small number of passwords repeatedly. If you don't also set [Minimum password age](minimum-password-age.md), users can change their password as many times in a row as necessary to reuse their original password. - -### Possible values - -- User-specified number from 0 through 24 -- Not defined - -### Best practices - -- Set **Enforce password history** to 24. This setting will help mitigate vulnerabilities that are caused by password reuse. -- Set [Maximum password age](maximum-password-age.md) to expire passwords between 60 and 90 days. Try to expire the passwords between major business cycles to prevent work loss. -- Configure [Minimum password age](minimum-password-age.md) so that you don't allow passwords to be changed immediately. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default domain policy | 24 passwords remembered| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | 0 passwords remembered| -| Domain controller effective default settings | 24 passwords remembered| -| Member server effective default settings | 24 passwords remembered| -| Effective GPO default settings on client computers | 24 passwords remembered| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse isn't prevented, or if users continually reuse a few passwords, the effectiveness of a good password policy is greatly reduced. - -If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If you don't also configure the [Minimum password age](minimum-password-age.md) policy setting, users might repeatedly change their passwords until they can reuse their original password. - ->**Note:**  After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised. - -### Countermeasure - -Configure the **Enforce password history** policy setting to 24 (the maximum setting) to help minimize the number of vulnerabilities that are caused by password reuse. - -For this policy setting to be effective, you should also configure effective values for the [Minimum password age](minimum-password-age.md) and [Maximum password age](maximum-password-age.md) policy settings. - -### Potential impact - -The major impact of configuring the **Enforce password history** setting to 24 is that users must create a new password every time they're required to change their old one. If users are required to change their passwords to new unique values, there's an increased risk of users who write their passwords somewhere so that they don't forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization, but these passwords make it easier for an attacker to guess. Also, an excessively low value for the [Maximum password age](maximum-password-age.md) policy setting is likely to increase administrative overhead because users who forget their passwords might ask the Help Desk to reset them frequently. - -## Related topics - -- [Password Policy](password-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md b/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md deleted file mode 100644 index 5879883e45..0000000000 --- a/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Enforce user logon restrictions -description: Describes the best practices, location, values, policy management, and security considerations for the Enforce user logon restrictions security policy setting. -ms.assetid: 5891cb73-f1ec-48b9-b703-39249e48a29f -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Enforce user logon restrictions - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting. - -## Reference - -The **Enforce user logon restrictions** policy setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validating each request for a session ticket is optional because the extra step takes time, and that can slow network access to services. - -The possible values for this Group Policy setting are: - -- Enabled -- Disabled -- Not defined - -### Best practices - -- If this policy setting is disabled, users might be granted session tickets for services that they don't have the right to use. - - We recommend setting **Enforce user logon restrictions** to Enabled. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy** - -### Default Values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server Type or GPO | Default Value | -| - | - | -| Default Domain Policy | Enabled| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings| Not applicable | -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Not applicable| -| Client Computer Effective Default Settings | Not applicable| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -### Group Policy - -Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you disable this policy setting, users could receive session tickets for services that they no longer have the right to use because the right was removed after they logged on. - -### Countermeasure - -Enable the **Enforce user logon restrictions** setting. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Kerberos Policy](kerberos-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md b/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md deleted file mode 100644 index e2e2fbba6b..0000000000 --- a/windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: Force shutdown from a remote system -description: Describes the best practices, location, values, policy management, and security considerations for the Force shutdown from a remote system security policy setting. -ms.assetid: 63129243-31ea-42a4-a598-c7064f48a3df -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Force shutdown from a remote system - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Force shutdown from a remote system** security policy setting. - -## Reference - -This security setting determines which users are allowed to shut down a device from a remote location on the network. This setting allows members of the Administrators group or specific users to manage computers (for tasks such as a restart) from a remote location. - -Constant: SeRemoteShutdownPrivilege - -### Possible values - -- User-defined list of accounts -- Administrators - -### Best practices - -- Explicitly restrict this user right to members of the Administrators group or other assigned roles that require this capability, such as non-administrative operations staff. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators and Server Operators on domain controllers and Administrators on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators
Server Operators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators
Server Operators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -This policy setting must be applied on the computer that is being accessed remotely. - -### Group Policy - -This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any user who can shut down a device could cause a denial-of-service condition to occur. Therefore, this user right should be tightly restricted. - -### Countermeasure - -Restrict the **Force shutdown from a remote system** user right to members of the Administrators group or other assigned roles that require this capability, such as non-administrative operations staff. - -### Potential impact - -On a domain controller, if you remove the **Force shutdown from a remote system** user right from the Server Operator group, you could limit the abilities of users who are assigned to specific administrative roles in your environment. Confirm that delegated activities are not adversely affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/generate-security-audits.md b/windows/security/threat-protection/security-policy-settings/generate-security-audits.md deleted file mode 100644 index a9c54c538d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/generate-security-audits.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Generate security audits -description: Describes the best practices, location, values, policy management, and security considerations for the Generate security audits security policy setting. -ms.assetid: c0e1cd80-840e-4c74-917c-5c2349de885f -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Generate security audits - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Generate security audits** security policy setting. - -## Reference - -This policy setting determines which accounts can be used by a process to generate audit records in the security event log. The Local Security Authority Subsystem Service (LSASS) writes events to the log. You can use the information in the security event log to trace unauthorized device access. - -Constant: SeAuditPrivilege - -### Possible values - -- User-defined list of accounts -- Local Service -- Network Service - -### Best practices - -- Because the audit log can potentially be an attack vector if an account is compromised, ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this setting is Local Service and Network Service on domain controllers and stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Local Service
Network Service| -| Stand-Alone Server Default Settings | Local Service
Network Service| -| Domain Controller Effective Default Settings | Local Service
Network Service| -| Member Server Effective Default Settings | Local Service
Network Service| -| Client Computer Effective Default Settings | Local Service
Network Service| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial-of-service (DoS) if the [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md) security policy setting is enabled. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A malicious user could use accounts that can write to the Security log to fill that log with meaningless events. If the computer is configured to overwrite events as needed, malicious users could use this method to remove evidence of their unauthorized activities. If the computer is configured to shut down when it is unable to write to the Security log, and it is not configured to automatically back up the log files, this method could be used to create a DoS condition. - -### Countermeasure - -Ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them. - -### Potential impact - -None. Restricting the **Generate security audits** user right to the Local Service and Network Service accounts is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/how-to-configure-security-policy-settings.md b/windows/security/threat-protection/security-policy-settings/how-to-configure-security-policy-settings.md deleted file mode 100644 index 37573dfb33..0000000000 --- a/windows/security/threat-protection/security-policy-settings/how-to-configure-security-policy-settings.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Configure security policy settings -description: Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller. -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.collection: -- highpri -- tier3 -ms.topic: reference -ms.date: 06/07/2023 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 ---- - -# Configure security policy settings - -This article describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller. You must have Administrators rights on the local device, or you must have the appropriate permissions to update a Group Policy Object (GPO) on the domain controller to perform these procedures. - -When a local setting is inaccessible, it indicates that a GPO currently controls that setting. - -## To configure a setting using the Local Security Policy console - -1. To open Local Security Policy, on the **Start** screen, type **secpol.msc**, and then press ENTER. -1. Under **Security Settings** of the console tree, do one of the following: - - Select **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**. - - Select **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**. -1. When you find the policy setting in the details pane, double-click the security policy that you want to modify. -1. Modify the security policy setting, and then select **OK**. - -> [!NOTE] -> -> - Some security policy settings require that the device be restarted before the setting takes effect. -> - Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -## To configure a security policy setting using the Local Group Policy Editor console - -You must have the appropriate permissions to install and use the Microsoft Management Console (MMC), and to update a Group Policy Object (GPO) on the domain controller to perform these procedures. - -1. Open the Local Group Policy Editor (gpedit.msc). -1. In the console tree, click **Computer Configuration**, select **Windows Settings**, and then select **Security Settings**. -1. Do one of the following: - - Select **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**. - - Select **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**. -1. In the details pane, double-click the security policy setting that you want to modify. - - > [!NOTE] - > If this security policy has not yet been defined, select the **Define these policy settings** check box. - -1. Modify the security policy setting, and then select **OK**. - -> [!NOTE] -> If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console. - -## To configure a setting for a domain controller - -The following procedure describes how to configure a security policy setting for only a domain controller (from the domain controller). - -1. To open the domain controller security policy, in the console tree, locate *GroupPolicyObject \[ComputerName\]* Policy, click **Computer Configuration**, click **Windows Settings**, and then click **Security Settings**. -1. Do one of the following: - - - Double-click **Account Policies** to edit the **Password Policy**, **Account Lockout Policy**, or **Kerberos Policy**. - - Select **Local Policies** to edit the **Audit Policy**, a **User Rights Assignment**, or **Security Options**. - -1. In the details pane, double-click the security policy that you want to modify. - - > [!NOTE] - > If this security policy has not yet been defined, select the **Define these policy settings** check box. - -1. Modify the security policy setting, and then select **OK**. - -> [!IMPORTANT] -> -> - Always test a newly created policy in a test organizational unit before you apply it to your network. -> - When you change a security setting through a GPO and click **OK**, that setting will take effect the next time you refresh the settings. - -## Related articles - -- [Security policy settings reference](security-policy-settings-reference.md) diff --git a/windows/security/threat-protection/security-policy-settings/images/privacy-setting-in-sign-in-options.png b/windows/security/threat-protection/security-policy-settings/images/privacy-setting-in-sign-in-options.png deleted file mode 100644 index cf2e499e04..0000000000 Binary files a/windows/security/threat-protection/security-policy-settings/images/privacy-setting-in-sign-in-options.png and /dev/null differ diff --git a/windows/security/threat-protection/security-policy-settings/images/secpol-architecture.gif b/windows/security/threat-protection/security-policy-settings/images/secpol-architecture.gif deleted file mode 100644 index aa7f16b61a..0000000000 Binary files a/windows/security/threat-protection/security-policy-settings/images/secpol-architecture.gif and /dev/null differ diff --git a/windows/security/threat-protection/security-policy-settings/images/secpol-components.gif b/windows/security/threat-protection/security-policy-settings/images/secpol-components.gif deleted file mode 100644 index df39c95345..0000000000 Binary files a/windows/security/threat-protection/security-policy-settings/images/secpol-components.gif and /dev/null differ diff --git a/windows/security/threat-protection/security-policy-settings/images/secpol-multigpomerge.gif b/windows/security/threat-protection/security-policy-settings/images/secpol-multigpomerge.gif deleted file mode 100644 index 8a637c8319..0000000000 Binary files a/windows/security/threat-protection/security-policy-settings/images/secpol-multigpomerge.gif and /dev/null differ diff --git a/windows/security/threat-protection/security-policy-settings/images/secpol-processes.gif b/windows/security/threat-protection/security-policy-settings/images/secpol-processes.gif deleted file mode 100644 index a1fc126115..0000000000 Binary files a/windows/security/threat-protection/security-policy-settings/images/secpol-processes.gif and /dev/null differ diff --git a/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md b/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md deleted file mode 100644 index 59a5523281..0000000000 --- a/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Impersonate a client after authentication -description: Describes the best practices, location, values, policy management, and security considerations for the Impersonate a client after authentication security policy setting. -ms.assetid: 4cd241e2-c680-4b43-8ed0-3b391925cec5 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Impersonate a client after authentication - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Impersonate a client after authentication** security policy setting. - -## Reference - -This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.) - -Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access. -The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do. - -Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started. - -Constant: SeImpersonatePrivilege - -### Possible values - -- User-defined list of accounts -- Default values -- Not defined - -### Best practices - -- A user can impersonate an access token if any of the following conditions exist: - - - The access token that is being impersonated is for this user. - - The user in this session logged on to the network with explicit credentials to create the access token. - - The requested level is less than Impersonate, such as Anonymous or Identify. - - Because of these factors, users do not usually need to have this user right assigned. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined | -| Default Domain Controller Policy| Administrators
Local Service
Network Service
Service| -| Stand-Alone Server Default Settings | Administrators
Local Service
Network Service
Service| -| Domain Controller Effective Default Settings | Administrators
Local Service
Network Service
Service| -| Member Server Effective Default Settings | Administrators
Local Service
Network Service
Service| -| Client Computer Effective Default Settings | Administrators
Local Service
Network Service
Service| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker with the **Impersonate a client after authentication** user right could create a service, mislead a client into connecting to the service, and then impersonate that computer to elevate the attacker's level of access to that of the device. - -### Countermeasure - -On member servers, ensure that only the Administrators and Service groups (Local Service, Network Service, and Service) have the **Impersonate a client after authentication** user right assigned to them. - -### Potential impact - -In most cases, this configuration has no impact. If you have installed optional components such as ASP.NET or IIS, you may need to assign the **Impersonate a client after authentication** user right to additional accounts that are required by those components, such as IUSR\_*<ComputerName>*, IIS\_WPG, ASP.NET, or IWAM\_*<ComputerName>*. - -In IIS 7.0 and later, a built-in account (IUSR) replaces the IUSR_MachineName account. Additionally, a group that is named IIS_IUSRS replaces the IIS_WPG group. Because the IUSR account is a built-in account, the IUSR account no longer requires a password. The IUSR account resembles a network or local service account. For more details, see [Default permissions and user rights for IIS 7.0 and later](/troubleshoot/iis/default-permissions-user-rights). - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md b/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md deleted file mode 100644 index f65a5700dd..0000000000 --- a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Increase a process working set -description: Describes the best practices, location, values, policy management, and security considerations for the Increase a process working set security policy setting. -ms.assetid: b742ad96-37f3-4686-b8f7-f2b48367105b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Increase a process working set - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Increase a process working set** security policy setting. - -## Reference - -This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they're available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process. - -Constant: SeIncreaseWorkingSetPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- You should make users aware that adverse performance issues may occur if they modify this security setting. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, standard users have this right. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not Defined| -| Default Domain Controller Policy | Users| -| Stand-Alone Server Default Settings| Users| -| Domain Controller Effective Default Settings| Users| -| Member Server Effective Default Settings | Users| -| Client Computer Effective Default Settings | Users| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Increasing the working set size for a process decreases the amount of physical memory that is available to the rest of the system. - -### Countermeasure - -Increase user’s awareness about the impact of increasing the working set of a process and how to recognize that their system is adversely affected if they change this setting. - -### Potential impact -None. Allowing standard users to increase the working set of a process is the default configuration. -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md b/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md deleted file mode 100644 index 156b06d265..0000000000 --- a/windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Increase scheduling priority -description: Describes the best practices, location, values, policy management, and security considerations for the Increase scheduling priority security policy setting. -ms.assetid: fbec5973-d35e-4797-9626-d0d56061527f -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 2/6/2020 ---- - -# Increase scheduling priority - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Increase scheduling priority** security policy setting. - -## Reference - -This policy setting determines which user accounts can increase the base priority class of a process. It is not a privileged operation to increase relative priority within a priority class. This user right is not required by administrative tools that are supplied with the operating system, but it might be required by software development tools. - -Specifically, this security setting determines which accounts can use a process with Write Property access to another process to increase the run priority that is assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface. - -Constant: SeIncreaseBasePriorityPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined -- Administrators - -### Best practices - -- Retain the default value as the only accounts responsible for controlling process scheduling priorities. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A user who is assigned this user right could increase the scheduling priority of a process to Real-Time, which would leave little processing time for all other processes and could lead to a denial-of-service condition. - -### Countermeasure - -Verify that only Administrators and Window Manager\Window Manager Group have the **Increase scheduling priority** user right assigned to them. - -### Potential impact - -None. Restricting the **Increase scheduling priority** user right to members of the Administrators group and Window Manager\Window Manager Group is the default configuration. - -> [!Warning] -> If you remove **Window Manager\Window Manager Group** from the **Increase scheduling priority** user right, certain applications and computers do not function correctly. In particular, the INK workspace does not function correctly on unified memory architecture (UMA) laptop and desktop computers that run Windows 10, version 1903 (or later) and that use the Intel GFX driver. -> -> On affected computers, the display blinks when users draw on INK workspaces such as those that are used by Microsoft Edge, Microsoft PowerPoint, or Microsoft OneNote. The blinking occurs because the inking-related processes repeatedly try to use the Real-Time priority, but are denied permission. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) -- [Increase scheduling priority for Windows Server 2012 and earlier](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221960(v%3dws.11)) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md deleted file mode 100644 index 2f420b21cf..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Interactive logon Display user information when the session is locked -description: Best practices, security considerations, and more for the security policy setting, Interactive logon Display user information when the session is locked. -ms.assetid: 9146aa3d-9b2f-47ba-ac03-ff43efb10530 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Display user information when the session is locked - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting. - -## Reference -This security setting controls whether details such as email address or domain\username appear with the username on the sign-in screen. -For clients that run Windows 10 version 1511 and 1507 (RTM), this setting works similarly to previous versions of Windows. -However, because of a new **Privacy** setting introduced in Windows 10 version 1607, this security setting affects those clients differently. - -### Changes beginning with Windows 10 version 1607 - -Beginning with Windows 10 version 1607, new functionality was added to Windows 10 to hide username details such as email address by default, with the ability to change the default to show the details. -This functionality is controlled by a new **Privacy** setting in **Settings** > **Accounts** > **Sign-in options**. -The Privacy setting is off by default, which hides the details. - -![Privacy setting.](images/privacy-setting-in-sign-in-options.png) - -The **Interactive logon: Display user information when the session is locked** Group Policy setting controls the same functionality. - -This setting has these possible values: - -- **User display name, domain and user names** - - For a local sign in, the user's full name is displayed. - If the user signed in using a Microsoft account, the user's email address is displayed. - For a domain sign in, the domain\username is displayed. - This setting has the same effect as turning on the **Privacy** setting. - -- **User display name only** - - The full name of the user who locked the session is displayed. - This setting has the same effect as turning off the **Privacy** setting. - -- **Do not display user information** - - No names are displayed. - Beginning with Windows 10 version 1607, this option isn't supported. - If this option is chosen, the full name of the user who locked the session is displayed instead. - This change makes this setting consistent with the functionality of the new **Privacy** setting. - To display no user information, enable the Group Policy setting **Interactive logon: Don't display last signed-in**. - -- **Domain and user names only** - - For a domain sign in only, the domain\username is displayed. - The **Privacy** setting is automatically on and grayed out. - -- **Blank** - - Default setting. - This setting translates to “Not defined,” but it will display the user's full name in the same manner as the option **User display name only**. - When an option is set, you can't reset this policy to blank, or not defined. - -### Hotfix for Windows 10 version 1607 - -Clients that run Windows 10 version 1607 won't show details on the sign-in screen even if the **User display name, domain and user names** option is chosen because the **Privacy** setting is off. -If the **Privacy** setting is turned on, details will show. - -The **Privacy** setting can't be changed for clients in bulk. -Instead, apply [KB 4013429](https://www.catalog.update.microsoft.com/Search.aspx?q=KB4013429) to clients that run Windows 10 version 1607 so they behave similarly to previous versions of Windows. -Clients that run later versions of Windows 10 don't require a hotfix. - -There are related Group Policy settings: - -- **Computer Configuration\Policies\Administrative Templates\System\Logon\Block user from showing account details on sign-in** prevents users from showing account details on the sign-in screen. -- **Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Don’t display last signed-in** prevents the username of the last user to sign in from being shown. -- **Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Don’t display username at sign-in** prevents the username from being shown at Windows sign-in and immediately after credentials are entered and before the desktop appears. - -### Interaction with related Group Policy settings - -For all versions of Windows 10, only the user display name is shown by default. - -If **Block user from showing account details on sign-in** is enabled, then only the user display name is shown regardless of any other Group Policy settings. -Users won't be able to show details. - -If **Block user from showing account details on sign-in** isn't enabled, then you can set **Interactive logon: Display user information when the session is locked** to **User display name, domain and user names** or **Domain and user names only** to show other details such as domain\username. -In this case, clients that run Windows 10 version 1607 need [KB 4013429](https://www.catalog.update.microsoft.com/Search.aspx?q=KB4013429) applied. -Users won't be able to hide other details. - -If **Block user from showing account details on sign-in** isn't enabled and **Don’t display last signed-in** is enabled, the username won't be shown. - -### Best practices - -Your implementation of this policy depends on your security requirements for displayed sign-in information. If you run computers that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy. - -Depending on your security policy, you might also want to enable the [Interactive logon: Don't display last user name](interactive-logon-do-not-display-last-user-name.md) policy. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or Group Policy object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | **User display name, domain and user names**| -| Member server effective default settings | **User display name, domain and user names**| -| Effective GPO default settings on client computers | **User display name, domain and user names**| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When a computer displays the Secure Desktop in an unsecured area, certain user information can be readily available to anyone looking at the monitor, either physically or through a remote connection. The displayed user information could include the domain user account name or the full name of the user who locked the session or who had logged on last. - -### Countermeasure - -Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the sign-in tiles are displayed for each signed-in user. - -You might also want to enable the [Interactive logon: Don't display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the sign-in name and sign-in tile of the last user to sign in. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md deleted file mode 100644 index 66d276bacf..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Interactive logon Don't display last signed-in -description: Describes the best practices, location, values, and security considerations for the Interactive logon Don't display last user name security policy setting. -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 -ms.reviewer: -ms.author: vinpa ---- - -# Interactive logon: Don't display last signed-in - -**Applies to** -- Windows 11 -- Windows 10 -- Windows Server 2022 -- Windows Server 2019 -- Windows Server 2016 - -Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display last signed-in** security policy setting. Before Windows 10 version 1703, this policy setting was named **Interactive logon:Do not display last user name.** - -## Reference - -This security policy setting determines whether the name of the last user to sign in to the device is displayed on the Secure Desktop. - -If this policy is enabled, the full name of the last user to successfully sign in isn't displayed on the Secure Desktop, nor is the user’s sign-in tile displayed. Additionally, if the **Switch user** feature is used, the full name and sign-in tile aren't displayed. The sign-in screen requests a qualified domain account name (or local user name) and password. - -If this policy is disabled, the full name of the last user to sign in is displayed, and the user’s sign-in tile is displayed. This behavior is the same when the **Switch user** feature is used. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -Your implementation of this policy depends on your security requirements for displayed sign-in information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or Group Policy object (GPO) | Default value| -| - | - | -| Default domain policy| Disabled| -| Default domain controller policy| Disabled| -| Stand-alone server default settings | Disabled| -| Domain controller effective default settings | Disabled| -| Member server effective default settings | Disabled| -| Effective GPO default settings on client computers | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to sign in. - -### Countermeasure - -Enable the **Interactive logon: Do not display last user name** setting. - -### Potential impact - -Users must always type their user names and passwords when they sign in locally or to the domain. The sign-in tiles of all logged on users aren't displayed. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md deleted file mode 100644 index ab27093a1c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Interactive logon Do not require CTRL+ALT+DEL -description: Describes the best practices, location, values, and security considerations for the Interactive logon Do not require CTRL+ALT+DEL security policy setting. -ms.assetid: 04e2c000-2eb2-4d4b-8179-1e2cb4793e18 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- -# Interactive logon: Do not require CTRL+ALT+DEL - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting. - -## Reference - -This security setting determines whether pressing CTRL+ALT+DEL is required before a user can sign in. - -If this policy setting is enabled on a device, a user isn't required to press CTRL+ALT+DEL to sign in. - -If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to the Windows operating system (unless they're using a smart card for signing in). - -Microsoft developed this feature to make it easier for users with certain types of physical impairments to sign in to a device running the Windows operating system; however, not having to press the CTRL+ALT+DELETE key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DELETE before users sign in ensures that users are communicating through a trusted path when entering their passwords. - -A malicious user might install malware that looks like the standard sign-in dialog box for the Windows operating system, and capture a user's password. The attacker can then sign in to the compromised account with whatever level of user rights that user has. - -> [!NOTE] -> When the policy is defined, registry value **DisableCAD** located in **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System** is created. To revert the changes made by this policy, it is not enough to set its value to **Not defined**, this registry value needs to be removed as well. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- We recommend that you set **Disable CTRL+ALT+DEL requirement for logon** to **Not configured**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -Beginning with Windows Server 2008 and Windows Vista, the CTRL+ALT+DELETE key combination is required to authenticate if this policy is disabled. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This setting makes it easier for users with certain types of physical impairments to sign in to devices that run the Windows operating system. However, if users aren't required to press CTRL+ALT+DEL, they're susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before signing in, user passwords are communicated through a trusted path. - -If this setting is enabled, an attacker could install malware that looks like the standard sign-in dialog box in the Windows operating system, and capture the user's password. The attacker would then be able to sign in to the compromised account with whatever level of privilege that user has. - -### Countermeasure - -Disable the **Interactive logon: Do not require CTRL+ALT+DEL** setting. - -### Potential impact - -Unless they use a smart card to sign in, users must simultaneously press the three keys before the sign-in dialog box is displayed. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md deleted file mode 100644 index 05151970da..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Interactive logon Don't display username at sign-in -description: Describes the best practices, location, values, and security considerations for the Interactive logon Don't display username at sign-in security policy setting. -ms.assetid: 98b24b03-95fe-4edc-8e97-cbdaa8e314fd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Don't display username at sign-in - -**Applies to** -- Windows 11 -- Windows 10 -- Windows Server 2022 -- Windows Server 2019 -- Windows Server 2016 - -Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display username at sign-in** security policy setting. - -## Reference - -A new policy setting has been introduced in Windows 10 starting with Windows 10 version 1703. This security policy setting determines whether the username is displayed during sign in. This setting only affects the **Other user** tile. - -If the policy is enabled and a user signs in as **Other user**, the full name of the user isn't displayed during sign-in. In the same context, if users type their email address and password at the sign-in screen and press **Enter**, the displayed text “Other user” remains unchanged, and is no longer replaced by the user’s first and last name, as in previous versions of Windows 10. Additionally,if users enter their domain user name and password and click **Submit**, their full name isn't shown until the Start screen displays. - -If the policy is disabled and a user signs in as **Other user**, the “Other user” text is replaced by the user’s first and last name during sign-in. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -Your implementation of this policy depends on your security requirements for displayed logon information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or Group Policy object (GPO) | Default value| -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy| Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Effective GPO default settings on client computers | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to sign in. - -### Countermeasure - -Enable the **Interactive logon: Don't display user name at sign-in** setting. - -### Potential impact - -Users must always type their usernames and passwords when they log on locally or to the domain. The sign in tiles of all logged on users aren't displayed. When this policy is enabled, you will be unable to change the default credential provider to anything other than username/password. In addition, this policy may be incompatible with autologon and multi-factor unlock. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md deleted file mode 100644 index fba7a86ac4..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Interactive logon Machine account lockout threshold -description: Best practices, location, values, management, and security considerations for the security policy setting, Interactive logon Machine account lockout threshold. -ms.assetid: ebbd8e22-2611-4ebe-9db9-d49344e631e4 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Machine account lockout threshold - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting. - -## Reference - -Beginning with Windows Server 2012 and Windows 8, the **Interactive logon: Machine account threshold** security policy setting enforces the lockout policy on those computers that have BitLocker enabled to protect operating system volumes. - -The security setting allows you to set a threshold for the number of failed sign-in attempts that causes the device to be locked by using BitLocker. This threshold means, if the specified maximum number of failed sign-in attempts is exceeded, the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to restore full access. - -Failed password attempts on workstations or member servers that have been locked by using either Ctrl+Alt+Delete or password-protected screen savers count as failed sign-in attempts. - -### Possible values - -You can set the **invalid logon attempts** value between 1 and 999. Values from 1 to 3 are interpreted as 4. If you set the value to 0, or leave blank, the computer or device will never be locked as a result of this policy setting. - -### Best practices - -Use this policy setting in conjunction with your other failed account sign-in attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings| Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled | -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -A restart is required for changes to this policy to become effective when they're saved locally or distributed through Group Policy. - -### Group Policy - -Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on those devices that contain this policy setting, but it can be set and distributed through Group Policy to any computer running the Windows operating system that supports Group Policy and is BitLocker-enabled. - -When setting this policy, consider the [Account lockout threshold](account-lockout-threshold.md) policy setting, which determines the number of failed sign-in attempts that will cause a user account to be locked out. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This policy setting helps protect a BitLocker-encrypted device from attackers attempting to brute-force guess the Windows sign-in password. If not set, then attackers can attempt innumerable passwords, if no other account protection mechanisms are in place. - -### Countermeasure - -Use this policy setting in conjunction with your other failed account sign-in attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out. - -### Potential impact - -If not set, the device could be compromised by an attacker using brute-force password cracking software. - -If set too low, productivity might be hindered because users who become locked out will be unable to access the device without providing the 48-digit BitLocker recovery password. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md deleted file mode 100644 index 93e24a9961..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Interactive logon Machine inactivity limit -description: Describes the best practices, location, values, management, and security considerations for the Interactive logon Machine inactivity limit security policy setting. -ms.assetid: 7065b4a9-0d52-41d5-afc4-5aedfc4162b5 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 09/18/2018 ---- - -# Interactive logon: Machine inactivity limit - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting. - -## Reference - -Beginning with Windows Server 2012 and Windows 8, Windows detects user-input inactivity of a sign-in (logon) session by using the security policy setting **Interactive logon: Machine inactivity limit**. If the amount of inactive time exceeds the inactivity limit set by this policy, then the user's session locks by invoking the screen saver (screen saver should be active on the destination machine). You can activate the screen saver by enabling the Group Policy **User Configuration\Administrative Templates\Control Panel\Personalization\Enable screen saver**. This policy setting allows you to control the locking time by using Group Policy. - -> [!NOTE] -> If the **Interactive logon: Machine inactivity limit** security policy setting is configured, the device locks not only when inactive time exceeds the inactivity limit, but also when the screensaver activates or when the display turns off because of power settings. - -### Possible values - -The automatic lock of the device is set in elapsed seconds of inactivity, which can range from zero (0) to 599,940 seconds (166.65 hours). - -If **Machine will be locked after** is set to zero (0) or has no value (blank), the policy setting is disabled and a user sign-in session is never locked after any inactivity. - -### Best practices - -Set the time for elapsed user-input inactivity based on the device's usage and location requirements. For example, if the device or device is in a public area, you might want to have the device automatically lock after a short period of inactivity to prevent unauthorized access. However, if the device is used by an individual or group of trusted individuals, such as in a restricted manufacturing area, automatically locking the device might hinder productivity. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options (While creating and linking group policy on server) - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -Restart is required for changes to this policy to become effective when they're saved locally or distributed through Group Policy. - -### Group Policy - -Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on those computers that contain this policy setting, but it can be set and distributed through Group Policy to any computer running the Windows operating system that supports Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This policy setting helps you prevent unauthorized access to devices under your control when the currently signed-in user leaves without deliberately locking the desktop. In versions earlier than Windows Server 2012 and Windows 8, the desktop-locking mechanism was set on individual computers in Personalization in Control Panel. - -### Countermeasure - -Set the time for elapsed user-input inactivity time by using the security policy setting **Interactive logon: Machine inactivity limit** based on the device's usage and location requirements. - -### Potential impact - -This security policy setting can limit unauthorized access to unsecured computers; however, that requirement must be balanced with the productivity requirements of the intended user. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md deleted file mode 100644 index cc406c3e45..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Interactive Logon Message text -description: Learn about best practices, security considerations and more for the security policy setting, Interactive logon Message text for users attempting to log on. -ms.assetid: fcfe8a6d-ca65-4403-b9e6-2fa017a31c2e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Message text for users attempting to log on - -**Applies to:** - -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Message text for users attempting to log on** security policy setting. - -## Reference - -The **Interactive logon: Message text for users attempting to log on** and [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) policy settings are closely related. - -**Interactive logon: Message text for users attempting to log on** specifies a text message to be displayed to users when they sign in. - -**Interactive logon: Message title for users attempting to log on** specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited. - -When these policy settings are configured, users will see a dialog box before they can sign in to the server console. - -### Possible values - -The possible values for this setting are: - -- User-defined text -- Not defined - -### Best practices - -- It's advisable to set **Interactive logon: Message text for users attempting to log on** to a value similar to one of the following: - - 1. IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION. - 2. This system is restricted to authorized users. Individuals who attempt unauthorized access will be prosecuted. If you're unauthorized, terminate access now. Click OK to indicate your acceptance of this information. - > [!IMPORTANT] - > Any warning that you display in the title or text should be approved by representatives from your organization's legal and human resources departments. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes different requirements to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -There are two policy settings that relate to sign-in displays: - -- **Interactive logon: Message text for users attempting to log on** -- [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) - -The first policy setting specifies a text message that displays to users when they sign in, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited. - -### Vulnerability - -Users often don't understand the importance of security practices. However, the display of a warning message before signing in may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the sign-in process. - -### Countermeasure - -Configure the **Interactive logon: Message text for users attempting to log on** and [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) settings to an appropriate value for your organization. - -### Potential impact - -Users see a message in a dialog box before they can sign in to the server console. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md deleted file mode 100644 index 20776c7140..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Interactive logon Message title for users attempting to log on -description: Best practices, security considerations, and more for the security policy setting, Interactive logon Message title for users attempting to log on. -ms.assetid: f2596470-4cc0-4ef1-849c-bef9dc3533c6 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Message title for users attempting to log on - -**Applies to** - -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Message title for users attempting to log on** security policy setting. - -## Reference - -This security setting allows you to specify a title that appears in the title bar of the window that contains the **Interactive logon: Message title for users attempting to log on**. This text is often used for legal reasons—for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited. - -The **Interactive logon: Message title for users attempting to log on** and [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) policy settings are closely related. **Interactive logon: Message title for users attempting to log on** specifies a message title to be displayed to users when they log on. This text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited. - -When these policy settings are configured, users will see a dialog box before they can sign in the server console. - -### Possible values - -- *User-defined title* -- Not defined - -### Best practices - -1. It is advisable to set **Interactive logon: Message title for users attempting to log on** to a value similar to one the following: - - - RESTRICTED SYSTEM - - or - - - WARNING: This system is restricted to authorized users. - -2. Set the policy [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) to reinforce the meaning of the message’s title. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -|Server type or GPO | Default value| -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -There are two policy settings that relate to sign-in displays: - -- [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) -- **Interactive logon: Message title for users attempting to log on** - -The first policy setting specifies a text message that displays to users when they sign in, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited. - -### Vulnerability - -Users often don't understand the importance of security practices. However, the display of a warning message with an appropriate title before signing in may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the sign-in process. - -### Countermeasure - -Configure the [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) and **Interactive logon: Message title for users attempting to log on** settings to an appropriate value for your organization. - -> [!NOTE] -> Any warning message that displays should be approved by your organization's legal and human resources representatives. - -### Potential impact - -Users see a message in a dialog box before they can sign in to the server console. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md deleted file mode 100644 index 3817c2a334..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Interactive logon Number of previous logons to cache (in case domain controller is not available) -description: Best practices and more for the security policy setting, Interactive logon Number of previous logons to cache (in case domain controller is not available). -ms.assetid: 660e925e-cc3e-4098-a41e-eb8db8062d8d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 08/27/2018 ---- - -# Interactive logon: Number of previous logons to cache (in case domain controller is not available) - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting. - -## Reference - -The **Interactive logon: Number of previous logons to cache (in case domain controller is not available**) policy setting determines whether a user can sign in to a Windows domain by using cached account information. Sign-in information for domain accounts can be cached locally so that, if a domain controller can't be contacted on subsequent logons, a user can still sign in. This policy setting determines the number of unique users whose sign-in information is cached locally. - -If a domain controller is unavailable and a user's sign-in information is cached, the user is prompted with the following message: - -A domain controller for your domain couldn't be contacted. You've been logged on using cached account information. Changes to your profile since you last logged on might not be available. - -If a domain controller is unavailable and a user's sign-in information isn't cached, the user is prompted with this message: - -The system can't log you on now because the domain *DOMAIN NAME* isn't available. - -The value of this policy setting indicates the number of users whose sign-in information the server caches locally. If the value is 10, the server caches sign-in information for 10 users. When an 11th user signs in to the device, the server overwrites the oldest cached sign-in session. - -Users who access the server console will have their sign-in credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by -encrypting the information and keeping the cached credentials in the system's registries, which are spread across numerous physical locations. - -> [!NOTE] -> The cached account information does not expire, but can get overwritten, as previously described. - -### Possible values - -- A user-defined number from 0 through 50 -- Not defined - -### Best practices - -The [Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) don't recommend configuring this setting. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | 10 logons| -| DC Effective Default Settings | No effect| -| Member Server Effective Default Settings | 10 logons| -| Client Computer Effective Default Settings| 10 logons| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The number that is assigned to this policy setting indicates the number of users whose sign-in information is cached locally by the servers. If the number is set to 10, the server caches sign-in information for 10 users. When an 11th user signs in to the device, the server overwrites the oldest cached sign-in session. - -Users who access the server console have their sign-in credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords. - -To mitigate this type of attack, Windows encrypts the information and obscures its physical location. - -### Countermeasure - -Configure the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** setting to 0, which disables the local caching of sign-in information. Other countermeasures include enforcement of strong password policies and physically secure locations for the computers. - -### Potential impact - -Users can't sign in to any devices if there's no domain controller available to authenticate them. Organizations can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user's sign-in information is still in the cache, even if a -member of the IT department has recently logged on to the device to perform system maintenance. This method allows users to sign in to their computers when they aren't connected to the organization's network. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-prompt-user-to-change-password-before-expiration.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-prompt-user-to-change-password-before-expiration.md deleted file mode 100644 index 14eb3e7e3a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-prompt-user-to-change-password-before-expiration.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Interactive log-on prompt user to change password before expiration -description: Best practices and security considerations for an interactive log-on prompt for users to change passwords before expiration. -ms.assetid: 8fe94781-40f7-4fbe-8cfd-5e116e6833e9 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive log on: Prompt the user to change passwords before expiration - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Prompt user to change password before expiration** security policy setting. - -## Reference - -This policy setting determines when users are warned that their passwords are about to expire. This warning gives users time to select a strong password before their current password expires to avoid losing system access. - -### Possible values - -- A user-defined number of days from 0 through 999 -- Not defined - -### Best practices - -- Configure user passwords to expire periodically. Users need warning that their password is going to expire, or they might get locked out of the system. -- Set **Interactive logon: Prompt user to change password before expiration** to five days. When their password expiration date is five or fewer days away, users will see a dialog box each time that they log on to the domain. -- When you set the policy to zero, there is no password expiration warning when the user logs on. During a long-running logon session, you would get the warning on the day the password expires or when it already has expired. - -### Location - -*Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options* - -### Default values - -The following table lists the default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Five days| -| DC Effective Default Settings | Five days | -| Member Server Effective Default Settings| Five days | -| Client Computer Effective Default Settings | Five days| - -## Policy management - -This section describes features and tools that you can use to manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -Configure this policy setting by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, it can be configured on the local computer through the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and possible negative consequences of the countermeasure. - -### Vulnerability - -If user passwords are configured to expire periodically in your organization, users need to be warned before expiration. Otherwise, they may get locked out of the devices inadvertently. - -### Countermeasure - -Configure the **Interactive logon: Prompt user to change password before expiration** setting to five days. - -### Potential impact - -Users see a dialog-box that prompts them to change their password each time that they log on to the domain when their password is configured to expire in 5 or fewer days. - -## Related topics - -- [Security options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md deleted file mode 100644 index 2249b7889f..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Interactive logon Require Domain Controller authentication to unlock workstation -description: Best practices security considerations, and more for the policy setting, Interactive logon Require Domain Controller authentication to unlock workstation. -ms.assetid: 97618ed3-e946-47db-a212-b5e7a4fc6ffc -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Require Domain Controller authentication to unlock workstation - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Domain Controller authentication to unlock workstation** security policy setting. - -## Reference - -Unlocking a locked device requires sign-in information. For domain accounts, the **Interactive logon: Require Domain Controller authentication to unlock workstation** policy setting determines whether it's necessary to contact a domain controller to unlock a device. Enabling this policy setting requires a domain controller to authenticate the domain account that is being used to unlock the device. Disabling this policy setting allows a user to unlock the device without the computer verifying the sign-in information with a domain controller. However, if [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) is set to a value greater than zero, the user's cached credentials will be used to unlock the system. - -The device caches (locally in memory) the credentials of any users who have been authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console. - -When cached credentials are used, any changes that have recently been made to the account (such as user rights assignments, account lockout, or the account being disabled) aren't considered or applied after this authentication process. This result means not only that user rights aren't updated, but more importantly that disabled accounts are still able to unlock the console of the system. - -It's advisable to set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to reauthenticate to the domain controller. If no domain controller is available, users can't unlock their devices. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to reauthenticate to the domain controller. If no domain controller is available, users can't unlock their devices. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -By default, the device caches locally in memory the credentials of any users who are authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—aren't considered or applied after the account is authenticated. User privileges aren't updated, and disabled accounts are still able to unlock the console of the device - -### Countermeasure - -Configure the **Interactive logon: Require Domain Controller authentication to unlock workstation** setting to Enabled and configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0. - -### Potential impact - -When the console on a device is locked by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can reauthenticate to the domain controller. If no domain controller is available, users can't unlock their workstations. If you configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) can't sign in. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md deleted file mode 100644 index fab0a761f3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: "Interactive logon: Require Windows Hello for Business or smart card" -description: "Describes the best practices, location, values, policy management, and security considerations for the 'Interactive logon: Require Windows Hello for Business or smart card' security policy setting." -author: vinaypamnani-msft -ms.author: vinpa -manager: aaroncz -ms.reviewer: -ms.localizationpriority: medium -ms.topic: reference -ms.date: 01/13/2023 ---- - -# Interactive logon: Require Windows Hello for Business or smart card - -**Applies to** - -- Windows 11 -- Windows 10, version 1703 or later - -Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Windows Hello for Business or smart card** security policy setting. - -> [!NOTE] -> You may need to download the ADMX template for your version of Windows to apply this policy. - -## Reference - -The **Interactive logon: Require Windows Hello for Business or smart card** policy setting requires users to sign in to a device by using a smart card or Windows Hello for Business method. - -Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This requirement reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it's nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to sign in must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it difficult to decrypt the traffic: even if they do, the next time the user signs in to the network, a new session key will be generated for encrypting traffic between the user and the domain controller. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set **Interactive logon: Require Windows Hello for Business or smart card** to Enabled. All users will have to use smart cards to sign in to the network, or a Windows Hello for Business method. This requirement means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users. For more information about password-less authentication, see [Windows Hello for Business overview](../../identity-protection/hello-for-business/index.md). - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy, by server type or group policy object (GPO). Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through group policy. - -### Policy conflict considerations - -None. - -### Group policy - -This policy setting can be configured by using the group policy management console (GPMC) to be distributed through GPOs. If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the local security policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -It can be difficult to make users choose strong passwords, and even strong passwords are vulnerable to brute-force attacks if an attacker has sufficient time and computing resources. - -### Countermeasure - -For users with access to computers that contain sensitive data, issue smart cards to users or configure Windows Hello for Business. Then configure the **Interactive logon: Require Windows Hello for Business or smart card** setting to Enabled. - -### Potential effect - -All users of a device with this setting enabled must use smart cards or a Windows Hello for Business method to sign in locally. The organization must have a reliable public key infrastructure (PKI), smart cards, and smart card readers for these users, or have enabled Windows Hello for Business. These requirements are significant challenges because expertise and resources are required to plan for and deploy these technologies. Active Directory Certificate Services can be used to implement and manage certificates. You can use automatic user and device enrollment and renewal on the client. - -## Related articles - -- [Security Options](security-options.md) -- [Windows Hello for Business overview](../../identity-protection/hello-for-business/index.md) diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-smart-card-removal-behavior.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-smart-card-removal-behavior.md deleted file mode 100644 index 3101ddf604..0000000000 --- a/windows/security/threat-protection/security-policy-settings/interactive-logon-smart-card-removal-behavior.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Interactive logon Smart card removal behavior -description: Best practices, location, values, policy management, and security considerations for the security policy setting, Interactive logon Smart card removal behavior. -ms.assetid: 61487820-9d49-4979-b15d-c7e735999460 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Interactive logon: Smart card removal behavior - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the recommended practices, location, values, policy management, and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting. - -## Reference - -This policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader. - -If smart cards are used for authentication, the device should automatically lock itself when the card is removed. So if users forget to manually lock their devices when they leave, malicious users cannot gain access. - -If you select **Force Logoff** in the property sheet for this policy setting, the user is automatically logged off when the smart card is removed. Users will have to reinsert their smart cards and reenter their PINs when they return to their workstations. - -> [!NOTE] -> This policy depends on **Smart Card Removal Policy** service. The service must be running for the policy to take effect, so it is recommended to set the startup type of the service to **Automatic**. - -### Possible values - -- No Action -- Lock Workstation - - If you use this setting, the workstation is locked when the smart card is removed. So users can leave the area, take their smart card with them, and still maintain a protected session. - -- Force Logoff - - If you use this setting, the user is automatically logged off when the smart card is removed. - -- Disconnect if a remote Remote Desktop Services session - - If you use this setting, removal of the smart card disconnects the session without logging off the user. So the user can insert the smart card and resume the session later, or at another smart card reader-equipped computer, without having to log on again. If the session is local, this policy functions identically to Lock Workstation. - -- Not Defined - -### Best practices - -- Set **Interactive logon: Smart card removal behavior** to **Lock Workstation**. If you select **Lock Workstation** in the property sheet for this policy setting, the workstation is locked when the smart card is removed. So users can leave the area, take their smart card with them, and still maintain a protected session. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy, by server type or Group Policy Object (GPO). Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | No Action| -| DC Effective Default Settings | No Action| -| Member Server Effective Default Settings | No Action| -| Client Computer Effective Default Settings | No Action| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through GPOs. If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users sometimes forget to lock their workstations when they're away from them, allowing the possibility for malicious users to access their devices. If smart cards are used for authentication, the device should automatically lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by using those credentials. - -### Countermeasure - -Configure the **Interactive logon: Smart card removal behavior** setting to **Lock Workstation**. - -If you select **Lock Workstation** for this policy setting, the device locks when the smart card is removed. Users can leave the area, take their smart card with them, and still maintain a protected session. This behavior is similar to the setting that requires users to log on when resuming work on the device after the screen saver has started. - -If you select **Force Logoff** for this policy setting, the user is automatically logged off when the smart card is removed. This setting is useful when a device is deployed as a public access point, such as a kiosk or other type of shared device - -### Potential impact - -If you select **Force Logoff**, users must insert their smart cards and enter their PINs when they return to their workstations. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/kerberos-policy.md b/windows/security/threat-protection/security-policy-settings/kerberos-policy.md deleted file mode 100644 index b2d778abd6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/kerberos-policy.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Kerberos Policy -description: Describes the Kerberos Policy settings and provides links to policy setting descriptions. -ms.assetid: 94017dd9-b1a3-4624-af9f-b29161b4bf38 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Kerberos Policy - -**Applies to** -- Windows 10 - -Describes the Kerberos Policy settings and provides links to policy setting descriptions. - -The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used by an attacker. However, this ticket lifetime reduction also increases the authorization overhead. In most environments, these settings shouldn't need to be changed. - -These policy settings are located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**. - -The following topics provide a discussion of implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible settings vulnerabilities of each setting), -countermeasures you can take, and the potential impact for each setting. - -## In this section - -| Topic | Description | -|-----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [Enforce user logon restrictions](enforce-user-logon-restrictions.md) | Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting. | -| [Maximum lifetime for service ticket](maximum-lifetime-for-service-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting. | -| [Maximum lifetime for user ticket](maximum-lifetime-for-user-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting. | -| [Maximum lifetime for user ticket renewal](maximum-lifetime-for-user-ticket-renewal.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting. | -| [Maximum tolerance for computer clock synchronization](maximum-tolerance-for-computer-clock-synchronization.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** security | - -## Related topics - -- [Configure security policy settings](how-to-configure-security-policy-settings.md) diff --git a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md b/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md deleted file mode 100644 index f51292c134..0000000000 --- a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Load and unload device drivers -description: Describes the best practices, location, values, policy management, and security considerations for the Load and unload device drivers security policy setting. -ms.assetid: 66262532-c610-470c-9792-35ff4389430f -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Load and unload device drivers - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Load and unload device drivers** security policy setting. - -## Reference - -This policy setting determines which users can dynamically load and unload device drivers. This user right isn't required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code. -Windows supports the Plug and Play specifications that define how a computer can detect and configure newly added hardware, and then automatically install the device driver. Prior to Plug and Play, users needed to manually configure devices before attaching them to the device. This model allows a user to plug in the hardware, then Windows searches for an appropriate device driver package and automatically configures it to work without interfering with other devices. - -Because device driver software runs as if it's a part of the operating system with unrestricted access to the entire computer, it's critical that only known and authorized device drivers be permitted. - -Constant: SeLoadDriverPrivilege - -### Possible values - -- User-defined list of accounts -- Default values -- Not Defined - -### Best practices - -- Because of the potential security risk, don't assign this user right to any user, group, or process that you don't want to take over the system. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators and Print Operators on domain controllers and Administrators on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators
Print Operators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators
Print Operators | -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Device drivers run as highly privileged code. A user who has the **Load and unload device drivers** user right could unintentionally install malware that masquerades as a device driver. Administrators should exercise care and install only drivers with verified digital signatures. - ->**Note:**  You must have this user right or be a member of the local Administrators group to install a new driver for a local printer or to manage a local printer and configure defaults for options such as duplex printing. - -### Countermeasure - -Don't assign the **Load and unload device drivers** user right to any user or group other than Administrators on member servers. On domain controllers, don't assign this user right to any user or group other than Domain Admins. - -### Potential impact - -If you remove the **Load and unload device drivers** user right from the Print Operators group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks aren't negatively affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md deleted file mode 100644 index 8efc6d6d5e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Lock pages in memory -description: Describes the best practices, location, values, policy management, and security considerations for the Lock pages in memory security policy setting. -ms.assetid: cc724979-aec0-496d-be4e-7009aef660a3 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Lock pages in memory - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Lock pages in memory** security policy setting. - -## Reference - -This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk. - -Normally, an application running on Windows can negotiate for more physical memory, and in response to the request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use. - -Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This limitation could lead to performance degradation. - -> [!NOTE] -> By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system. - -Constant: SeLockMemoryPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -Best practices are dependent on the platform architecture and the applications running on those platforms. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users with the **Lock pages in memory** user right could assign physical memory to several processes, which could leave little or no RAM for other processes and result in a denial-of-service condition. - -### Countermeasure - -Don't assign the **Lock pages in memory** user right to any accounts. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md deleted file mode 100644 index 9be27bb7d6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Log on as a batch job -description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a batch job security policy setting. -ms.assetid: 4eaddb51-0a18-470e-9d3d-5e7cd7970b41 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Log on as a batch job - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting. - -## Reference - -This policy setting determines which accounts can sign in by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the **Log on as a batch job** user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user's security context. - -Constant: SeBatchLogonRight - -### Possible values - -- User-defined list of accounts -- Default values -- Not Defined - -### Best practices - -- Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient in most cases. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators
Backup Operators
Performance Log Users| -| Stand-Alone Server Default Settings | Administrators
Backup Operators
Performance Log Users| -| Domain Controller Effective Default Settings | Administrators
Backup Operators
Performance Log Users| -| Member Server Effective Default Settings | Administrators
Backup Operators
Performance Log Users| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Task Scheduler automatically grants this right when a user schedules a task. To override this behavior, use the [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) User Rights Assignment setting. - -Group Policy settings are applied in the following order, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration. It describes how to apply the countermeasure and the possible negative consequences of countermeasure. - -### Vulnerability - -The **Log on as a batch job** user right presents a low-risk vulnerability that allows non-administrators to perform administrator-like functions. If not assessed, understood, and restricted accordingly, attackers can easily exploit this potential attack vector to compromise systems, credentials, and data. For most organizations, the default settings are sufficient. Members of the local Administrators group have this right by default. - -### Countermeasure - -Allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you don't want to use the Task Scheduler in this manner, configure the **Log on as a batch job** user right for only the Local Service account. - -For IIS servers, configure this policy locally instead of through domain–based Group Policy settings so that you can ensure the local IUSR\_*<ComputerName>* and IWAM\_*<ComputerName>* accounts have this user right. - -### Potential impact - -If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer can't assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you might need to assign this user right to other accounts that those components require. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right isn't assigned to this group and these accounts, IIS can't run some COM objects that are necessary for proper functionality. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md b/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md deleted file mode 100644 index b9d7dcc0af..0000000000 --- a/windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Log on as a service -description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a service security policy setting. -ms.assetid: acc9a9e0-fd88-4cda-ab54-503120ba1f42 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Log on as a service - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting. - -## Reference - -This policy setting determines which service accounts can register a process as a service. Running a process under a service account circumvents the need for human intervention. - -Constant: SeServiceLogonRight - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Minimize the number of accounts that are granted this user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Network Service on domain controllers and Network Service on stand-alone servers. - -The following table lists the actual and effective default policy values. The policy's property page also lists default values. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Network Service| -| Member Server Effective Default Settings| Network Service| -| Client Computer Effective Default Settings | Network Service| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -The policy setting **Deny logon as a service** supersedes this policy setting if a user account is subject to both policies. - -Group Policy settings are applied in the following order, which will overwrite settings on the local device at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration. It explains the countermeasure. And it addresses the possible negative consequences of the countermeasure. - -### Vulnerability - -The **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced because only users who have administrative privileges can install and configure services. An -attacker who has already reached that level of access could configure the service to run with the Local System account. - -### Countermeasure - -By definition, the Network Service account has the **Log on as a service** user right. This right isn't granted through the Group Policy setting. Minimize the number of other accounts that are granted this user right. - -### Potential impact - -On most computers, the **Log on as a service** user right is restricted to the Local System, Local Service, and Network Service built-in accounts by default, and there's no negative impact. But if you have optional components such as ASP.NET or IIS, you might need to -assign the user right to the additional accounts that those components require. IIS requires this user right to be explicitly granted to the ASPNET user account. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md b/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md deleted file mode 100644 index eae4a7c4b6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Manage auditing and security log -description: Describes the best practices, location, values, policy management, and security considerations for the Manage auditing and security log security policy setting. -ms.assetid: 4b946c0d-f904-43db-b2d5-7f0917575347 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Manage auditing and security log - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Manage auditing and security log** security policy setting. - -## Reference - -This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the Security log in Event Viewer. For more information about the Object Access audit policy, see [Audit object access](../auditing/basic-audit-object-access.md). - -Constant: SeSecurityPrivilege - -### Possible values -- User-defined list of accounts -- Administrators -- Not Defined - -### Best practices - -1. Before removing this right from a group, investigate whether applications are dependent on this right. -2. Generally, assigning this user right to groups other than Administrators isn't necessary. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings| Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Audits for object access aren't performed unless you enable them by using the Local Group Policy Editor, the Group Policy Management Console (GPMC), or the Auditpol command-line tool. - -For more information about the Object Access audit policy, see [Audit object access](../auditing/basic-audit-object-access.md). - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Anyone with the **Manage auditing and security log** user right can clear the Security log to erase important evidence of unauthorized activity. - -### Countermeasure - -Ensure that only the local Administrators group has the **Manage auditing and security log** user right. - -### Potential impact - -Restricting the **Manage auditing and security log** user right to the local Administrators group is the default configuration. - ->**Warning:**  If groups other than the local Administrators group have been assigned this user right, removing this user right might cause performance issues with other applications. Before removing this right from a group, investigate whether applications are dependent on this right. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md deleted file mode 100644 index e7ac39b82a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Maximum lifetime for service ticket -description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for service ticket security policy setting. -ms.assetid: 484bf05a-3858-47fc-bc02-6599ca860247 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Maximum lifetime for service ticket - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting. - -## Reference - -The **Maximum lifetime for service ticket** policy setting determines the maximum number of minutes that a granted session ticket can be used to access a particular service. The value must be 10 minutes or greater, and it must be less than or equal to the value of the **Maximum lifetime for service ticket** policy setting. - -The possible values for this Group Policy setting are: - -- A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets don't expire). -- Not defined. - -If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations aren't interrupted if the session ticket that authenticated the connection expires during the connection. - -If the value for this policy setting is too high, users might be able to access network resources outside of their sign-in hours. In addition, users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire. - -### Best practices - -- It's advisable to set **Maximum lifetime for service ticket** to **600** minutes. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server Type or GPO | Default Value | -| - | - | -| Default Domain Policy| 600 minutes| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not applicable| -| DC Effective Default Settings | 600 minutes| -| Member Server Effective Default Settings | Not applicable| -| Client Computer Effective Default Settings | Not applicable| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -This policy setting is configured on the domain controller. - -### Group Policy - -Client computers will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you configure the value for the **Maximum lifetime for service ticket** setting too high, users might be able to access network resources outside of their sign-in hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled. - -### Countermeasure - -Configure the **Maximum lifetime for service ticket** setting to 600 minutes. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Kerberos Policy](kerberos-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md deleted file mode 100644 index 6d0137547d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Maximum lifetime for user ticket renewal -description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket renewal security policy setting. -ms.assetid: f88cd819-3dd1-4e38-b560-13fe6881b609 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Maximum lifetime for user ticket renewal - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting. - -## Reference - -The **Maximum lifetime for user ticket renewal** policy setting determines the period of time (in days) during which a user’s ticket-granting ticket can be renewed. - -The possible values for this Group Policy setting are: - -- A user-defined number of days from 0 through 99,999 -- Not defined - -### Best practices - -- If the value for this policy setting is too high, users may be able to renew old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire. - - It's advisable to set **Maximum lifetime for user ticket renewal** to **7** days. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| 7 days| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Not applicable| -| Domain Controller Effective Default Settings | 7 days| -| Member Server Effective Default Settings | Not applicable| -| Client Computer Effective Default Settings | Not applicable| - -### Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -This policy setting is configured on the domain controller. - -### Group Policy - -Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If the value for the **Maximum lifetime for user ticket renewal** setting is too high, users might be able to renew old user tickets. - -### Countermeasure - -Configure the **Maximum lifetime for user ticket renewal** setting to 7 days. - -### Potential impact - -Seven (7) days is the default configuration. Changing the default configuration is a tradeoff between user convenience and security. A shorter time period requires users to authenticate with a DC more often, but remote users who authenticate with a DC infrequently can be locked out of services until they reauthenticate. - -## Related topics - -- [Kerberos Policy](kerberos-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md deleted file mode 100644 index 3cc212c913..0000000000 --- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Maximum lifetime for user ticket -description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket policy setting. -ms.assetid: bcb4ff59-334d-4c2f-99af-eca2b64011dc -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Maximum lifetime for user ticket - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting. - -## Reference - -The **Maximum lifetime for user ticket** policy setting determines the maximum amount of time (in hours) that a user’s ticket-granting ticket can be used. When a user’s ticket-granting ticket expires, a new one must be requested or the existing one must be renewed. - -The possible values for this Group Policy setting are: - -- A user-defined number of hours from 0 through 99,999 -- Not defined - -If the value for this policy setting is too high, users might be able to access network resources outside of their sign-in hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire. - -### Best practices - -- We recommend that you set the **Maximum lifetime for user ticket** to 10 hours. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy - -### Default Values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server Type or GPO | Default Value | -| - | - | -| Default Domain Policy| 10 hours| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Not applicable| -| Domain Controller Effective Default Settings | 10 hours| -| Member Server Effective Default Settings | Not applicable| -| Client Computer Effective Default Settings | Not applicable| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -This policy setting is configured on the domain controller. - -### Group Policy - -Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local computer, the Security Configuration Engine will refresh this setting in about five minutes. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you configure the value for the **Maximum lifetime for user ticket** setting too high, users might be able to access network resources outside of their sign-in hours. Also, users whose accounts were disabled might continue to have access to network services with valid user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack. - -### Countermeasure - -Configure the **Maximum lifetime for user ticket** setting with a value between 4 and 10 hours. - -### Potential impact - -Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to access resources that the user doesn't have rights to. However, it requires more frequent requests to the KDC for ticket-granting tickets on behalf of users. Most KDCs can support a value of 4 hours without any extra burden. - -## Related topics - -- [Kerberos Policy](kerberos-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md b/windows/security/threat-protection/security-policy-settings/maximum-password-age.md deleted file mode 100644 index 2bd4c4aa31..0000000000 --- a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Maximum password age -description: Describes the best practices, location, values, policy management, and security considerations for the Maximum password age security policy setting. -ms.assetid: 2d6e70e7-c8b0-44fb-8113-870c6120871d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Maximum password age - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Maximum password age** security policy setting. - -## Reference - -The **Maximum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a certain number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If **Maximum password age** is between 1 and 999 days, the minimum password age must be less than the maximum password age. If **Maximum password age** is set to 0, [Minimum password age](minimum-password-age.md) can be any value between 0 and 998 days. - ->**Note:**  Setting **Maximum password age** to -1 is equivalent to 0, which means it never expires. Setting it to any other negative number is equivalent to setting it to **Not Defined**. - -### Possible values - -- User-specified number of days between 0 and 999 -- Not defined - -### Best practices - -Set **Maximum password age** to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources. - -> [!NOTE] -> The security baseline recommended by Microsoft doesn't contain the password-expiration policy, as it is less effective than modern mitigations. However, companies that didn't implement Microsoft Entra Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| 42 days| -| Default domain controller policy| Not defined| -| Stand-alone server default settings | 42 days| -| Domain controller effective default settings | 42 days| -| Member server effective default settings | 42 days| -| Effective GPO default settings on client computers| 42 days| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of implementation. - -### Vulnerability - -The longer a password exists, the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the **Maximum password age** policy setting to 0 so that users are never required to change their passwords allows a compromised password to be used by the malicious user for as long as the valid user is authorized access. - -### Considerations - -Mandated password changes are a long-standing security practice, but current research strongly indicates that password expiration has a negative effect. For more information, see [Microsoft Password Guidance](https://www.microsoft.com/research/publication/password-guidance/). - -Configure the **Maximum password age** policy setting to a value that is suitable for your organization's business requirements. For example, many organizations have compliance or insurance mandates requiring a short lifespan on passwords. Where such a requirement exists, the **Maximum password age** policy setting can be used to meet business requirements. - -### Potential impact - -If the **Maximum password age** policy setting is too low, users are required to change their passwords often. Such a configuration can reduce security in the organization because users might keep their passwords in an unsecured location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts. - -## Related topics - -- [Password Policy](password-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md b/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md deleted file mode 100644 index 164df232e6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Maximum tolerance for computer clock synchronization -description: Best practices, location, values, policy management, and security considerations for the policy setting, Maximum tolerance for computer clock synchronization. -ms.assetid: ba2cf59e-d69d-469e-95e3-8e6a0ba643af -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Maximum tolerance for computer clock synchronization - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** security policy setting. - -## Reference - -This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller that provides Kerberos authentication. - -To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both devices must be set to the same time and date. -Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any timestamp that's used in a session between the two devices is considered to be authentic. - -The possible values for this Group Policy setting are: - -- A user-defined number of minutes from 1 through 99,999 -- Not defined - -### Best practices - -- It's advisable to set **Maximum tolerance for computer clock synchronization** to a value of 5 minutes. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| 5 minutes| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not applicable| -| Domain Controller Effective Default Settings| 5 minutes| -| Member Server Effective Default Settings | Not applicable| -| Client Computer Effective Default Settings | Not applicable| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -This policy setting is configured on the domain controller. - -### Group Policy - -Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes. - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock and a domain controller clock. If the difference between the client computer clock and the domain controller clock is less than the maximum time difference specified in this setting, any timestamp that's used in a session between the two computers is considered to be authentic. - -### Countermeasure - -Configure the **Maximum tolerance for computer clock synchronization** setting to 5 minutes. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Kerberos Policy](kerberos-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md deleted file mode 100644 index 658dc72de2..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Microsoft network client Digitally sign communications (always) -description: Best practices and security considerations for the Microsoft network client Digitally sign communications (always) security policy setting. -ms.reviewer: -manager: aaroncz -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -ms.date: 01/13/2023 -ms.topic: reference ---- - -# Microsoft network client: Digitally sign communications (always) - -**Applies to** - -- Windows 11 -- Windows 10 -- Windows Server - -This article describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. - -> [!NOTE] -> This article is about the server message block (SMB) v2 and v3 protocols. SMBv1 isn't secure and has been deprecated in Windows. Starting with Windows 10, version 1709, and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -> [!IMPORTANT] -> Microsoft doesn't recommend using the following group policy settings: -> -> - **Microsoft network server: Digitally sign communications (if client agrees)** -> - **Microsoft network client: Digitally sign communications (if server agrees)** -> -> Also don't use the **EnableSecuritySignature** registry settings. -> -> These options only affect the SMBv1 behavior. They can be effectively replaced by the **Digitally sign communications (always)** group policy setting or the **RequireSecuritySignature** registry setting. - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports digital signing of SMB packets. - -Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." Misuse of these policy settings is a common error that can cause data access failure. - -Beginning with SMBv2 clients and servers, signing can be either *required* or *not required*. If this policy setting is enabled, SMBv2 clients will digitally sign all packets. Another policy setting determines whether signing is required for SMBv3 and SMBv2 server communications: [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md). - -Negotiation occurs between the SMB client and the SMB server to decide whether signing will be used. The following table shows the effective behavior for SMBv3 and SMBv2. - -| Client | Server - required | Server - not required | -|---------------------------|---------------------|------------------------| -| **Client - required** | Signed | Signed | -| **Client - not required** | Signed 1 | Not signed2 | - -
-1 Default for domain controller SMB traffic
-2 Default for all other SMB traffic - -Performance of SMB signing is improved in SMBv2. For more information, see [Potential effect](#potential-effect). - -### Possible values - -- Enabled -- Disabled - -### Best practice - -Enable **Microsoft network client: Digitally sign communications (always)**. - -### Location - -*Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options* - -### Default values - -The following table lists the default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Disabled| -| Default Domain Controller Policy | Disabled| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that you can use to manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets and then modify the traffic and forward it to make the server perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication and gain unauthorized access to data. - -SMB is the resource-sharing protocol that's supported by many versions of the Windows operating system. It's the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't happen. - -### Countermeasure - -Enable **Microsoft network client: Digitally sign communications (always)**. - -> [!NOTE] -> An alternative countermeasure that could protect all network traffic is to implement digital signatures through IPsec. There are hardware-based accelerators for IPsec encryption and signing that can be used to minimize the performance impact on servers. No such accelerators are available for SMB signing. - -### Potential effect - -Storage speeds affect performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage for signing. If you're using a 1-Gb Ethernet network or slower storage speed with a modern CPU, there's limited degradation in performance. If you're using a faster network (such as 10 Gb), the performance impact of signing may be greater. - -## Related articles - -- [Security options](security-options.md) -- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md deleted file mode 100644 index de1a65cacc..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Microsoft network client Send unencrypted password -description: Learn about best practices and more for the security policy setting, Microsoft network client Send unencrypted password to third-party SMB servers. -ms.assetid: 97a76b93-afa7-4dd9-bb52-7c9e289b6017 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - - -# Microsoft network client: Send unencrypted password to third-party SMB servers - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting. - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. This policy setting allows or prevents the SMB redirector to send plaintext passwords to a non-Microsoft server service that doesn't support password encryption during authentication. - -### Possible values - -- Enabled - - The Server Message Block (SMB) redirector is allowed to send plaintext passwords to a non-Microsoft server service that doesn't support password encryption during authentication. - -- Disabled - - The Server Message Block (SMB) redirector only sends encrypted passwords to non-Microsoft SMB server services. If those server services don't support password encryption, the authentication request will fail. - -- Not defined - -### Best practices - -- It's advisable to set **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** to Disabled. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings| Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you enable this policy setting, the server can transmit plaintext passwords across the network to other computers that offer SMB services. These other devices might not use any of the SMB security mechanisms that are included with Windows Server 2003 or later. - -### Countermeasure - -Disable the **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** setting. - -### Potential impact - -Some older applications may not be able to communicate with the servers in your organization through the SMB protocol. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md deleted file mode 100644 index 7add3c22bb..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Microsoft network server Amount of idle time required before suspending session -description: Best practices, security considerations, and more for the policy setting, Microsoft network server Amount of idle time required before suspending session. -ms.assetid: 8227842a-569d-480f-b43c-43450bbaa722 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Microsoft network server: Amount of idle time required before suspending session - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting. - -## Reference - -Each Server Message Block (SMB) session consumes server resources. Establishing numerous null sessions will cause the server to slow down or possibly fail. A malicious user might repeatedly establish SMB sessions until the server stops responding; at this point, SMB services will become slow or unresponsive. - -The **Microsoft network server: Amount of idle time required before suspending session** policy setting determines the amount of continuous idle time that must pass in an SMB session before the session is suspended due to inactivity. You can use this policy setting to control when a device suspends an inactive SMB session. The session is automatically reestablished when client device activity resumes. - -### Possible values - -- A user-defined number of minutes from 0 through 99,999. - - For this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99999 (8 business hours per day), which is 208 days. In effect, this value disables the policy. - -- Not defined - -### Best practices - -- It's advisable to set this policy to 15 minutes. There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - - -| Server type or GPO Default value | -|--------------------------------------------| -| Default Domain Policy | -| Default Domain Controller Policy | -| Stand-Alone Server Default Settings | -| DC Effective Default Settings | -| Member Server Effective Default Settings | -| Client Computer Effective Default Settings | - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Each SMB session consumes server resources, and numerous null sessions slow the server or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until the server's SMB services become slow or unresponsive. - -### Countermeasure - -The default behavior on a server mitigates this threat by design. - -### Potential impact - -There's little impact because SMB sessions are reestablished automatically if the client computer resumes activity. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md deleted file mode 100644 index e9667f8aeb..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Microsoft network server Attempt S4U2Self -description: Learn about the security policy setting, Microsoft network server Attempt S4U2Self to obtain claim information. -ms.assetid: e4508387-35ed-4a3f-a47c-27f8396adbba -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Microsoft network server: Attempt S4U2Self to obtain claim information - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting. - -## Reference - -This security setting supports client devices running a version of Windows prior to Windows 8 that are trying to access a file share that requires user claims. This setting determines whether the local file server will attempt to use Kerberos Service-for-User-to-Self (S4U2Self) functionality to obtain a network client principal’s claims from the client’s account domain. This setting should only be enabled if the file server is using user claims to control access to files, and if the file server will support client principals whose accounts might be in a domain that has client computers -and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012. - -When enabled, this security setting causes the Windows file server to examine the access token of an authenticated network client principal and determines if claim information is present. If claims aren't present, the file server will then use the Kerberos S4U2Self feature to attempt to contact a Windows Server 2012 domain controller in the client’s account domain and obtain a claims-enabled access token for the client principal. A claims-enabled token might be needed to access files or folders that have claim-based access control policy applied. - -If this setting is disabled, the Windows file server won't attempt to obtain a claim-enabled access token for the client principal. - -### Possible values - -- **Default** - - The Windows file server will examine the access token of an authenticated network client principal and determine if claim information is present. - -- **Enabled** - - Same as **Default**. - -- **Disabled** - -- **Not defined** - - Same as **Disabled**. - -### Best practices - -This setting should be set to **Default** so that the file server can automatically evaluate whether claims are needed for the user. You should explicitly configure this setting to **Enabled** only if there are local file access policies that include user claims. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings| Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -This setting should only be enabled if the file server is using user claims to control access to files, and if the file server will support client principals whose accounts might be in a domain that has client computers and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -None. Enabling this policy setting allows you to take advantage of features in Windows Server 2012 and Windows 8 and later for specific scenarios to use claims-enabled tokens to access files or folders that have claim-based access control policy applied on Windows operating systems prior to Windows Server 2012 -and Windows 8. - -### Countermeasure - -Not applicable. - -### Potential impact - -None. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md deleted file mode 100644 index afe2dc3cac..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Microsoft network server Digitally sign communications (always) -description: Best practices, security considerations, and more for the security policy setting, Microsoft network server Digitally sign communications (always). -author: vinaypamnani-msft -ms.author: vinpa -ms.reviewer: -manager: aaroncz -ms.localizationpriority: medium -ms.topic: reference -ms.date: 01/13/2023 ---- - -# Microsoft network server: Digitally sign communications (always) - -**Applies to** - -- Windows 11 -- Windows 10 -- Windows Server - -Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. - -> [!NOTE] -> This article is about the server message block (SMB) v2 and v3 protocols. SMBv1 isn't secure and has been deprecated in Windows. Starting with Windows 10, version 1709, and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows). - -> [!IMPORTANT] -> Microsoft doesn't recommend using the following group policy settings: -> -> - **Microsoft network server: Digitally sign communications (if client agrees)** -> - **Microsoft network client: Digitally sign communications (if server agrees)** -> -> Also don't use the **EnableSecuritySignature** registry settings. -> -> These options only affect the SMBv1 behavior. They can be effectively replaced by the **Digitally sign communications (always)** group policy setting or the **RequireSecuritySignature** registry setting. - -## Reference - -The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. - -Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings can cause data access failure. - -Beginning with SMBv2 clients and servers, signing can be either required or not required. If this policy setting is enabled, SMBv2 clients will digitally sign all packets. Another policy setting determines whether signing is required for SMBv3 and SMBv2 server communications: [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md). - -There's a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. The following table has the effective behavior for SMBv3 and SMBv2. - -| Client | Server - Required | Server - Not Required | -|---------------------------|---------------------|------------------------| -| **Client - Required** | Signed | Signed | -| **Client - Not Required** | Signed 1 | Not Signed2 | - -
-1 Default for domain controller SMB traffic
-2 Default for all other SMB traffic - -Performance of SMB signing is improved in SMBv2. For more information, see [Potential effect](#potential-effect). - -### Possible values - -- Enabled -- Disabled - -### Best practices - -Enable **Microsoft network server: Digitally sign communications (always)**. - -### Location - -*Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options* - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Disabled| -| Default Domain Controller Policy | Enabled| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data. - -SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. If either side fails the authentication process, data transmission doesn't take place. - -### Countermeasure - -Enable **Microsoft network server: Digitally sign communications (always)**. - -> [!NOTE] -> An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing. - -### Potential effect - -Storage speeds impact performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. If you're using a 1-GB Ethernet network or slower storage speed with a modern CPU, there's limited degradation in performance. If you're using a faster network (such as 10 Gb), the performance impact of signing may be greater. - -## Related articles - -- [Security Options](security-options.md) -- [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md deleted file mode 100644 index f502ed6336..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Microsoft network server Disconnect clients when sign-in hours expire -description: Best practices, location, values, and security considerations for the policy setting, Microsoft network server Disconnect clients when sign-in hours expire. -ms.assetid: 48b5c424-9ba8-416d-be7d-ccaabb3f49af -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Microsoft network server: Disconnect clients when sign-in hours expire - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting. - -## Reference - -This policy setting enables or disables the forced disconnection of users who are connected to the local device outside their user account's valid sign-in hours. It affects the SMB component. If you enable this policy setting, client computer sessions with the SMB service are forcibly disconnected when the client's sign-in hours expire. If you disable this policy setting, established client device sessions are maintained after the client device's sign-in hours expire. - -### Possible values - -- Enabled - - Client device sessions with the SMB service are forcibly disconnected when the client device's sign-in hours expire. If sign-in hours aren't used in your organization, enabling this policy setting will have no impact. - -- Disabled - - The system maintains an established client device session after the client device's sign-in hours have expired. - -- Not defined - -### Best practices - -- If you enable this policy setting, you should also enable [Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md). - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings| Enabled | -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If your organization configures sign-in hours for users, it makes sense to enable this policy setting. Otherwise, users who shouldn't have access to network resources outside of their sign-in hours can continue to use those resources with sessions that were established during allowed hours. - -### Countermeasure - -Enable the **Microsoft network server: Disconnect clients when logon hours expire** setting. - -### Potential impact - -If sign-in hours aren't used in your organization, this policy setting has no impact. If sign-in hours are used, existing user sessions are forcibly terminated when their sign-in hours expire. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md deleted file mode 100644 index 2d618461c5..0000000000 --- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Microsoft network server Server SPN target name validation level -description: Best practices, security considerations, and more for the security policy setting, Microsoft network server Server SPN target name validation level. -ms.assetid: 18337f78-eb45-42fd-bdbd-f8cd02c3e154 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Microsoft network server: Server SPN target name validation level - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, and values, policy management and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting. - -## Reference - -This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the Server Message Block (SMB) protocol. The level of validation can help prevent a class of attacks against SMB services (referred to as SMB relay attacks). This setting affects both SMB1 and SMB2. - -Servers that use SMB provide availability to their file systems and other resources, such as printers, to networked client devices. Most servers that use SMB validate user access to resources by using NT Domain authentication (NTLMv1 and NTLMv2) and the Kerberos protocol. - -### Possible values - -The options for validation levels are: - -- **Off** - - The SPN from an SMB client isn't required or validated by the SMB server. - -- **Accept if provided by client** - - The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be established if it matches the SMB server’s list of SPNs. If the SPN doesn't match, the session request for that SMB client will be denied. - -- **Required from client** - - The SMB client must send an SPN name in session setup, and the SPN name provided must match the SMB server that is being requested to establish a connection. If no SPN is provided by the client device, or the SPN provided doesn't match, the session is denied. - -The default setting is Off. - -### Best practices - -This setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent disruptions to file and print serving capabilities. - ->**Note:**  All Windows operating systems support a client-side SMB component and a server-side SMB component. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy object (GPO) | Default value | -| - | - | -| Default domain policy | Off | -| Default domain controller policy| Off| -| Stand-alone server default settings | Off| -| Domain controller effective default settings| Validation level check not implemented| -| Member server effective default settings | Validation level check not implemented| -| Effective GPO default settings on client computers | Validation level check not implemented| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -None. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This policy setting controls the level of validation that a server with shared folders or printers performs on the service principal name (SPN) that is provided by the client device when the client device establishes a session by using the SMB protocol. The level of validation can help prevent a class of attacks against SMB servers (referred to as SMB relay attacks). This setting will affect both SMB1 and SMB2. - -### Countermeasure - -For countermeasures that are appropriate to your environment, see **Possible values** above. - -### Potential impact - -All Windows operating systems support a client-side SMB component and a server-side SMB component. This setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent disruptions to file and print serving capabilities. - -Because the SMB protocol is widely deployed, setting the options to **Accept if provided by client** or **Required from client** will prevent some clients from successfully authenticating to some servers in your environment. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/minimum-password-age.md b/windows/security/threat-protection/security-policy-settings/minimum-password-age.md deleted file mode 100644 index 4922c645e8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/minimum-password-age.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Minimum password age -description: Describes the best practices, location, values, policy management, and security considerations for the Minimum password age security policy setting. -ms.assetid: 91915cb2-1b3f-4fb7-afa0-d03df95e8161 -ms.reviewer: -manager: aaroncz -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -ms.date: 11/13/2018 -ms.topic: reference ---- - -# Minimum password age - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Minimum password age** security policy setting. - -## Reference - -The **Minimum password age** policy setting determines the period of time (in days) that a password must be used before the user can change it. You can set a value between 1 and 998 days, or you can allow password changes immediately by setting the number of days to 0. The minimum password age must be less than the Maximum password age, unless the maximum password age is set to 0, indicating that passwords will never expire. If the maximum password age is set to 0, the minimum password age can be set to any value between 0 and 998. - -### Possible values - -- User-specified number of days between 0 and 998 -- Not defined - -### Best practices - -[Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) recommend setting **Minimum password age** to one day. - -Setting the number of days to 0 allows immediate password changes. This setting isn't recommended. -Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again. -For example, suppose a password is "Ra1ny day!" and the history requirement is 24. -If the minimum password age is 0, the password can be changed 24 times in a row until finally changed back to "Ra1ny day!". -The minimum password age of 1 day prevents that. - -If you set a password for a user and you want that user to change the administrator-defined password, you must select the **User must change password at next logon** check box. -Otherwise, the user won't be able to change the password until the number of days specified by **Minimum password age**. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| 1 day| -| Default domain controller policy| Not defined| -| Stand-alone server default settings | 0 days| -| Domain controller effective default settings | 1 day| -| Member server effective default settings | 1 day| -| Effective GPO default settings on client computers| 1 day| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users may have favorite passwords that they like to use because they're easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach. - -To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users can't reuse any of their last 12 passwords, but you don't configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. Configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective. - -### Countermeasure - -Configure the **Minimum password age** policy setting to a value of 1 day. Users should know about this limitation and contact the Help Desk to change a password sooner. If you configure the number of days to 0, immediate password changes would be allowed, which we don't recommend. - -### Potential impact - -If you set a password for a user but want that user to change the password when the user first logs on, the administrator must select the **User must change password at next logon** check box, or the user can't change the password until the next day. - -## Related topics - -- [Password Policy](password-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/minimum-password-length.md b/windows/security/threat-protection/security-policy-settings/minimum-password-length.md deleted file mode 100644 index f6edea308a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/minimum-password-length.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Minimum password length -description: Describes the best practices, location, values, policy management, and security considerations for the Minimum password length security policy setting. -ms.assetid: 3d22eb9a-859a-4b6f-82f5-c270c427e17e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 03/30/2022 ---- - -# Minimum password length - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the recommended practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting. - -## Reference - -The **Minimum password length** policy setting determines the least number of characters that can make up a password for a user account. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0. - -### Possible values - -- User-specified number of characters between 0 and 14 -- Not defined - -### Best practices - -Set minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it's long enough to provide adequate security and still short enough for users to easily remember. A minimum password length greater than 14 isn't supported at this time. This value will help provide adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. For more info, see [Password must meet complexity requirements](password-must-meet-complexity-requirements.md). - -Permitting short passwords reduces security because short passwords can be easily broken with tools that do dictionary or brute force attacks against the passwords. Requiring long passwords can result in mistyped passwords that might cause account lockouts and might increase the volume of Help Desk calls. - -In addition, requiring long passwords can actually decrease the security of an organization because users might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to remember. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Seven characters| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Zero characters| -| Domain controller effective default settings | Seven characters| -| Member server effective default settings | Seven characters| -| Effective GPO default settings on client computers | Zero characters| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords. - -### Countermeasure - -Configure the **Minimum password length** policy setting to a value of 8 or more. If the number of characters is set to 0, no password will be required. - -In most environments, we recommend an eight-character password because it's long enough to provide adequate security, but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) policy setting in addition to the **Minimum password length** setting helps reduce the possibility of a dictionary attack. - -> [!NOTE] -> Some jurisdictions have established legal requirements for password length as part of establishing security regulations. - -### Potential impact - -Requirements for long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords because of password length requirements, consider teaching your users about passphrases, which are often easier to remember and, because of the larger number of character combinations, much harder to discover. - -## Related topics - -- [Password Policy](password-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md b/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md deleted file mode 100644 index dbd4f943f7..0000000000 --- a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Modify an object label -description: Describes the best practices, location, values, policy management, and security considerations for the Modify an object label security policy setting. -ms.assetid: 3e5a97dd-d363-43a8-ae80-452e866ebfd5 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Modify an object label - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Modify an object label** security policy setting. - -## Reference - -This privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by that user to a lower level without this privilege. - -The integrity label is used by the Windows Integrity Controls (WIC) feature, which was introduced in Windows Server 2008 and Windows Vista. WIC keeps lower integrity processes from modifying higher integrity processes by assigning one of six possible labels to objects on the system. Although -similar to NTFS file and folder permissions, which are discretionary controls on objects, the WIC integrity levels are mandatory controls that are put in place and enforced by the operating system. The following list describes the integrity levels from lowest to highest: - -- **Untrusted**   Default assignment for processes that are logged on anonymously. -- **Low**   Default assignment for processes that interact with the Internet. -- **Medium**   Default assignment for standard user accounts and any object that isn't explicitly designated with a lower or higher integrity level. -- **High**  Default assignment for administrator accounts and processes that request to run using administrative rights. -- **System**   Default assignment for Windows kernel and core services. -- **Installer**   Used by setup programs to install software. It's important that only trusted software is installed on computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all other objects. - -Constant: SeRelabelPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Don't give any group this user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Not defined on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Anyone with the **Modify an object label** user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower integrity processes. Either of these states effectively circumvents the protection that is offered by -Windows Integrity Controls and makes your system vulnerable to attacks by malicious software. - -If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator accounts don't have sufficient integrity levels to delete the program from the system. In that case, use of the **Modify an object label** right is mandated so that the object can be relabeled. However, the relabeling must occur by using a process that is at the same or a higher level of integrity than the object that you're attempting to relabel. - -### Countermeasure - -Don't give any group this right. If necessary, implement it for a constrained period of time to a trusted individual to respond to a specific organizational need. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md b/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md deleted file mode 100644 index 58d6be0e68..0000000000 --- a/windows/security/threat-protection/security-policy-settings/modify-firmware-environment-values.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Modify firmware environment values -description: Describes the best practices, location, values, policy management, and security considerations for the Modify firmware environment values security policy setting. -ms.assetid: 80bad5c4-d9eb-4e3a-a5dc-dcb742b83fca -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Modify firmware environment values - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Modify firmware environment values** security policy setting. - -## Reference - -This security setting determines who can modify firmware environment values. Firmware environment values are settings that are stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor. - -On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the **Last Known Good Configuration** setting, which should only be modified by the system. - -On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the **Default Operating System** setting using the **Startup and Recovery** feature on the **Advanced** tab of **System Properties**. - -The exact setting for firmware environment values is determined by the boot firmware. The location of these values is also specified by the firmware. For example, on a UEFI-based system, NVRAM contains firmware environment values that specify system boot settings. - -On all computers, this user right is required to install or upgrade Windows. - -Constant: SeSystemEnvironmentPrivilege - -### Possible values - -- User-defined list of accounts -- Administrators -- Not Defined - -### Best practices - -- Ensure that only the local Administrators group is assigned the **Modify firmware environment values** user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO |Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Adminstrators| -| Stand-Alone Server Default Settings | Adminstrators| -| Domain Controller Effective Default Settings | Adminstrators| -| Member Server Effective Default Settings | Adminstrators| -| Client Computer Effective Default Settings | Adminstrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -This security setting does not affect who can modify the system environment values and user environment values that are displayed on the **Advanced** tab of **System Properties**. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Anyone who is assigned the **Modify firmware environment values** user right could configure the settings of a hardware component to cause it to fail, which could lead to data corruption or a denial-of-service condition. - -### Countermeasure - -Ensure that only the local Administrators group is assigned the **Modify firmware environment values** user right. - -### Potential impact - -Removing the local Administrators group from the **Modify firmware environment values** user right could cause inoperability of the BitLocker Drive Encryption feature. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md b/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md deleted file mode 100644 index e0d4fc62d5..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Network access Allow anonymous SID/Name translation -description: Best practices, location, values, policy management and security considerations for the policy setting, Network access Allow anonymous SID/Name translation. -ms.assetid: 0144477f-22a6-4d06-b70a-9c9c2196e99e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Allow anonymous SID/Name translation - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting. - -## Reference - -This policy setting enables or disables the ability of an anonymous user to request security identifier (SID) attributes for another user. - -If this policy setting is enabled, a user might use the well-known Administrators SID to get the real name of the built-in Administrator account, even if the account has been renamed. That person might then use the account name to initiate a brute-force password-guessing attack. - -Misuse of this policy setting is a common error that can cause data loss or problems with data access or security. - -### Possible values - -- Enabled - - An anonymous user can request the SID attribute for another user. An anonymous user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name. This setting affects the SID-to-name translation and the name-to-SID translation. - -- Disabled - - Prevents an anonymous user from requesting the SID attribute for another user. - -- Not defined - -### Best practices - -- Set this policy to Disabled, which is the default value on member computers; therefore, it will have no impact on them. The default value for domain controllers is Enabled. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Disabled| -| Client Computer Effective Default Settings | Disabled| - -### Operating system version differences - -The default value of this setting has changed between operating systems as follows: - -- The default on domain controllers running Windows Server 2003 R2 or earlier was set to Enabled. -- The default on domain controllers running Windows Server 2008 and later is set to Disabled. - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Modifying this setting may affect compatibility with client computers, services, and applications. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If this policy setting is enabled, a user with local access could use the well-known Administrator's SID to learn the real name of the built-in Administrator account, even if it has been renamed. That person could then use the account name to initiate a password-guessing attack. - -### Countermeasure - -Disable the **Network access: Allow anonymous SID/Name translation** setting. - -### Potential impact - -Disabled is the default configuration for this policy setting on member devices; therefore, it has no impact on them. The default configuration for domain controllers is Enabled. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md deleted file mode 100644 index 50e1eddf2c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Network access Do not allow anonymous enumeration -description: Learn about best practices and more for the security policy setting, Network access Do not allow anonymous enumeration of SAM accounts and shares. -ms.assetid: 3686788d-4cc7-4222-9163-cbc7c3362d73 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Do not allow anonymous enumeration of SAM accounts and shares - -**Applies to** -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** security policy setting. - -## Reference - -This policy setting determines which other permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This permission is convenient, for example, when an administrator wants to give access to users in a trusted domain that doesn't maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON. - -This policy setting has no impact on domain controllers. -Misuse of this policy setting is a common error that can cause data loss or problems with data access or security. - -### Possible values - -- Enabled - -- Disabled - - No other permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions. However, an unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks. - -- Not defined - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflicts - -Even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and Windows Vista). - -### Group Policy - -This policy has no impact on domain controllers. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social-engineering attacks. - -### Countermeasure - -Enable the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** setting. - -### Potential impact - -It's impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md deleted file mode 100644 index 4eb9c91bd1..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Network access Do not allow anonymous enumeration of SAM accounts -description: Describes the best practices, location, values, and security considerations for the Network access Do not allow anonymous enumeration of SAM accounts security policy setting. -ms.assetid: 6ee25b33-ad43-4097-b031-7be680f64c7c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Do not allow anonymous enumeration of SAM accounts - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting. - -## Reference - -This policy setting determines which other permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This permission is convenient, for example, when an administrator wants to give access to users in a trusted domain that doesn't maintain a reciprocal trust. - -This policy setting has no impact on domain controllers. - -Misuse of this policy setting is a common error that can cause data loss or problems with data access or security. - -### Possible values - -- Enabled - -- Disabled - - No other permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions. - -- Not defined - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflicts - -Even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON (on systems earlier than Windows Server 2008 and Windows Vista). - -### Group Policy - -This policy has no impact on domain controllers. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An unauthorized user could anonymously list account names and use the information to perform social engineering attacks or attempt to guess passwords. Social engineering attackers try to deceive users in some way to obtain passwords or some form of security information. - -### Countermeasure - -Enable the **Network access: Do not allow anonymous enumeration of SAM accounts** setting. - -### Potential impact - -It's impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md deleted file mode 100644 index 2787a6af79..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Network access Do not allow storage of passwords and credentials for network authentication -description: Learn about best practices and more for the security policy setting, Network access Do not allow storage of passwords and credentials for network authentication -ms.assetid: b9b64360-36ea-40fa-b795-2d6558c46563 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 07/01/2021 ---- - -# Network access: Do not allow storage of passwords and credentials for network authentication - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting. - -## Reference - -This security setting determines whether Credential Manager saves passwords and credentials for later use when it gains domain authentication. - -### Possible values - -- Enabled - - Credential Manager doesn't store passwords and credentials on the device - -- Disabled - - Credential Manager will store passwords and credentials on this computer for later use for domain authentication. - -- Not defined - -### Best practices - -It's a recommended practice to disable the ability of the Windows operating system to cache credentials on any device where credentials aren't needed. Evaluate your servers and workstations to determine the requirements. Cached credentials are designed primarily to be used on laptops that require domain credentials when disconnected from the domain. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy| Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings| Disabled| -| Member server effective default settings | Disabled| -| Effective GPO default settings on client computers |Disabled| - -### Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -A restart of the device is required before this policy will be effective when changes to this policy are saved locally or distributed through Group Policy. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Passwords that are cached can be accessed by the user when logged on to the device. Although this information may sound obvious, a problem can arise if the user unknowingly runs malicious software that reads the passwords and forwards them to another, unauthorized user. - ->**Note:**  The chances of success for this exploit and others that involve malicious software are reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies. - -Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the administrator's password may be overwritten. This procedure requires physical access to the device. Utilities exist that can help overwrite the cached verifier. With the help of one of these utilities, an attacker can authenticate by using the overwritten value. - -Overwriting the administrator's password doesn't help the attacker access data that is encrypted by using that password. Also, overwriting the password doesn't help the attacker access any Encrypting File System (EFS) data that belongs to other users on that device. Overwriting the password doesn't help an attacker replace the verifier, because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or by using the Data Protection API (DPAPI) won't decrypt. - -### Countermeasure - -Enable the **Network access: Do not allow storage of passwords and credentials for network authentication** setting. - -To limit the number of cached domain credentials that are stored on the computer, set the **cachedlogonscount** registry entry. By default, the operating system caches the verifier for each unique user's 10 most recent valid logons. This value can be set to any value between 0 and 50. By default, all versions of the Windows operating system remember 10 cached logons, except Windows Server 2008 and later, which are set at 25. - -When you try to sign in to a domain from a Windows-based client device, and a domain controller is unavailable, you don't receive an error message. Therefore, you may not notice that you logged on with cached domain credentials. You can set a notification of a sign in that uses cached domain credentials with the ReportDC registry entry. - -### Potential impact - -Users are forced to type passwords whenever they sign in to their Microsoft Account or other network resources that aren't accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md b/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md deleted file mode 100644 index eba40fa8db..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Let Everyone permissions apply to anonymous users -description: Learn about best practices, security considerations and more for the security policy setting, Network access Let Everyone permissions apply to anonymous users. -ms.assetid: cdbc5159-9173-497e-b46b-7325f4256353 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Let Everyone permissions apply to anonymous users - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting. - -## Reference - -This policy setting determines what other permissions are granted for anonymous connections to the device. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders and perform certain other activities. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust. - -By default, the token that is created for anonymous connections doesn't include the Everyone SID. Therefore, permissions that are assigned to the Everyone group don't apply to anonymous users. - -### Possible values - -- Enabled - - The Everyone SID is added to the token that is created for anonymous connections, and anonymous users can access any resource for which the Everyone group has been assigned permissions. - -- Disabled - - The Everyone SID is removed from the token that is created for anonymous connections. - -- Not defined - -### Best practices - -- Set this policy to **Disabled**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Polices\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords, perform social engineering attacks, or launch DoS attacks. - -### Countermeasure - -Disable the **Network access: Let Everyone permissions apply to anonymous users** setting. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md deleted file mode 100644 index c43a8bc781..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Network access Named Pipes that can be accessed anonymously -description: Describes best practices, security considerations and more for the security policy setting, Network access Named Pipes that can be accessed anonymously. -ms.assetid: 8897d2a4-813e-4d2b-8518-fcee71e1cf2c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Named Pipes that can be accessed anonymously - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting. - -## Reference - -This policy setting determines which communication sessions, or pipes, have attributes and permissions that allow anonymous access. - -Restricting access over named pipes such as COMNAP and LOCATOR helps prevent unauthorized access to the network. - -### Possible values - -- User-defined list of shared folders -- Not defined - -### Best practices - -- Set this policy to a null value; that is, enable the policy setting, but don't enter named pipes in the text box. This setting will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined | -| Default Domain Controller Policy | Netlogon, samr, lsarpc| -| Stand-Alone Server Default Settings | Null| -| DC Effective Default Settings | Netlogon, samr, lsarpc| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -For this policy setting to take effect, you must also enable the [Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md) setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent unauthorized access to the network. The following list describes available named pipes and their purpose. These pipes were granted anonymous access in earlier versions of Windows and some legacy applications may still use them. - -| Named pipe | Purpose | -| - | - | -| COMNAP | SNABase named pipe. Systems network Architecture (SNA) is a collection of network protocols that were originally developed for IBM mainframe computers.| -| COMNODE| SNA Server named pipe.| -| SQL\QUERY | Default named pipe for SQL Server.| -| SPOOLSS | Named pipe for the Print Spooler service.| -| EPMAPPER | End Point Mapper named pipe.| -| LOCATOR | Remote Procedure Call Locator service named pipe.| -| TrlWks | Distributed Link Tracking Client named pipe.| -| TrkSvr | Distributed Link Tracking Server named pipe.| - -### Countermeasure - -Configure the **Network access: Named Pipes that can be accessed anonymously** setting to a null value (enable the setting but don't specify named pipes in the text box). - -### Potential impact - -This configuration disables null-session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes no longer function. This result may break trust between Windows Server 2003 domains in a mixed mode environment. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md deleted file mode 100644 index ca04da80eb..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Network access Remotely accessible registry paths and subpaths -description: Describes best practices, location, values, and security considerations for the policy setting, Network access Remotely accessible registry paths and subpaths. -ms.assetid: 3fcbbf70-a002-4f85-8e86-8dabad21928e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Remotely accessible registry paths and subpaths - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting. - -## Reference - -This policy setting determines which registry paths and subpaths are accessible when an application or process references the WinReg key to determine access permissions. - -The registry is a database for device configuration information, much of which is sensitive. A malicious user can use it to facilitate unauthorized activities. The chance of this happening is reduced by the fact that the default ACLs that are assigned throughout the registry are fairly restrictive, -and they help protect it from access by unauthorized users. - -To allow remote access, you must also enable the Remote Registry service. - -### Possible values - -- User-defined list of paths -- Not Defined - -### Best practices - -- Set this policy to a null value; that is, enable the policy setting, but don't enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | See the following registry key combination| -| DC Effective Default Settings | See the following registry key combination| -| Member Server Effective Default Settings | See the following registry key combination| -| Client Computer Effective Default Settings | See the following registry key combination| - -The combination of all the following registry keys apply to the previous settings: - -1. System\\CurrentControlSet\\Control\\Print\\Printers -2. System\\CurrentControlSet\\Services\\Eventlog -3. Software\\Microsoft\\OLAP Server -4. Software\\Microsoft\\Windows NT\\CurrentVersion\\Print -5. Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows -6. System\\CurrentControlSet\\Control\\ContentIndex -7. System\\CurrentControlSet\\Control\\Terminal Server -8. System\\CurrentControlSet\\Control\\Terminal Server\\UserConfig -9. System\\CurrentControlSet\\Control\\Terminal Server\\DefaultUserConfiguration -10. Software\\Microsoft\\Windows NT\\CurrentVersion\\Perflib -11. System\\CurrentControlSet\\Services\\SysmonLog - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The registry contains sensitive device configuration information that could be used by an attacker to facilitate unauthorized activities. The fact that the default ACLs that are assigned throughout the registry are fairly restrictive and help to protect the registry from access by unauthorized users reduces the risk of such an attack. - -### Countermeasure - -Configure the **Network access: Remotely accessible registry paths and sub-paths** setting to a null value (enable the setting but don't enter any paths in the text box). - -### Potential impact - -Remote management tools such as MBSA and Configuration Manager require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail. - ->**Note:**  If you want to allow remote access, you must also enable the Remote Registry service. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md deleted file mode 100644 index b7cd9c9122..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Network access Remotely accessible registry paths -description: Best practices, location, values, policy management and security considerations for the policy setting, Network access Remotely accessible registry paths. -ms.assetid: 977f86ea-864f-4f1b-9756-22220efce0bd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Remotely accessible registry paths - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Remotely accessible registry paths** security policy setting. - -## Reference - -This policy setting determines which registry paths are accessible when an application or process references the WinReg key to determine access permissions. - -The registry is a database for device configuration information, much of which is sensitive. A malicious user can use the registry to facilitate unauthorized activities. To reduce the risk of this happening, suitable access control lists (ACLs) are assigned throughout the registry to help protect it from access by unauthorized users. - -To allow remote access, you must also enable the Remote Registry service. - -### Possible values - -- User-defined list of paths -- Not Defined - -### Best practices - -- Set this policy to a null value; that is, enable the policy setting but don't enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | See the following registry key combination| -| DC Effective Default Settings | See the following registry key combination| -| Member Server Effective Default Settings | See the following registry key combination| -| Client Computer Effective Default Settings | See the following registry key combination| - -The combination of all the following registry keys apply to the previous settings: - -1. System\\CurrentControlSet\\Control\\ProductOptions -2. System\\CurrentControlSet\\Control\\Server Applications -3. Software\\Microsoft\\Windows NT\\CurrentVersion - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker could use information in the registry to facilitate unauthorized activities. To reduce the risk of such an attack, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users. - -### Countermeasure - -Configure the **Network access: Remotely accessible registry paths** setting to a null value (enable the setting, but don't enter any paths in the text box). - -### Potential impact - -Remote management tools such as the Microsoft Baseline Security Analyzer (MBSA) and Configuration Manager require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail. - ->**Note:**  If you want to allow remote access, you must also enable the Remote Registry service. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md deleted file mode 100644 index 048ad3f0b8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Network access Restrict anonymous access to Named Pipes and Shares -description: Best practices, security considerations, and more for the security policy setting, Network access Restrict anonymous access to Named Pipes and Shares. -ms.assetid: e66cd708-7322-4d49-9b57-1bf8ec7a4c10 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Restrict anonymous access to Named Pipes and Shares - -**Applies to** -- Windows 11 -- Windows 10 -- Windows 8.1 -- Windows Server 2022 -- Windows Server 2019 -- Windows Server 2016 -- Windows Server 2012 R2 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Restrict anonymous access to Named Pipes and Shares** security policy setting. - -## Reference - -This policy setting enables or disables the restriction of anonymous access to only those shared folders and pipes that are named in the **Network access: Named pipes that can be accessed anonymously** and [Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md) settings. The setting controls null session access to shared folders on your computers by adding RestrictNullSessAccess with the value 1 in the registry key -**HKEY\_LOCAL\_MACHINE\\System\\CurrentControlSet\\Services\\LanManServer\\Parameters**. This registry value toggles null session shared folders on or off to control whether the Server service restricts unauthenticated clients' access to named resources. - -Null sessions are a weakness that can be exploited through the various shared folders on the devices in your environment. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set this policy to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all server pipes and shared folders except those server pipes and shared folders listed in the **NullSessionPipes** and **NullSessionShares** registry entries. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings | Enabled| -| Client Computer Effective Default Settings| Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Null sessions are a weakness that can be exploited through shared folders (including the default shared folders) on devices in your environment. - -### Countermeasure - -Enable the **Network access: Restrict anonymous access to Named Pipes and Shares** setting. - -### Potential impact - -You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and shared folders except those server pipes and shared folders that are listed in the NullSessionPipes and NullSessionShares entries. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md deleted file mode 100644 index cf13b74c2e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md +++ /dev/null @@ -1,173 +0,0 @@ ---- -title: Network access - Restrict clients allowed to make remote calls to SAM -description: Security policy setting that controls which users can enumerate users and groups in the local Security Accounts Manager (SAM) database. -ms.localizationpriority: medium -ms.date: 09/17/2018 -author: vinaypamnani-msft -ms.author: vinpa -ms.reviewer: -manager: aaroncz -ms.collection: - - highpri - - tier3 -ms.topic: reference ---- - -# Network access: Restrict clients allowed to make remote calls to SAM - -**Applies to** - -- Windows 10 -- Windows 8.1 -- Windows Server 2019 -- Windows Server 2016 -- Windows Server 2012 R2 - -The **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting controls which users can enumerate users and groups in the local Security Accounts Manager (SAM) database and Active Directory. -The setting was first supported by Windows 10 version 1607 and Windows Server 2016 (RTM) and can be configured on earlier Windows client and server operating systems. - -This article describes the default values for this security policy setting in different versions of Windows. -By default, computers beginning with Windows 10 version 1607 and Windows Server 2016 are more restrictive than earlier versions of Windows. -This restrictive characteristic means that if you have a mix of computers, such as member servers that run both Windows Server 2016 and Windows Server 2012 R2, the servers that run Windows Server 2016 may fail to enumerate accounts by default where the servers that run Windows Server 2012 R2 succeed. - -This article also covers related events, and how to enable audit mode before constraining the security principals that are allowed to remotely enumerate users and groups so that your environment remains secure without impacting application compatibility. - -> [!NOTE] -> Implementation of this policy [could affect offline address book generation](/troubleshoot/windows-server/group-policy/authz-fails-access-denied-error-application-access-check) on servers running Microsoft Exchange 2016 or Microsoft Exchange 2013. - -## Reference - -The SAMRPC protocol makes it possible for a low privileged user to query a machine on a network for data. -For example, a user can use SAMRPC to enumerate users, including privileged accounts such as local or domain administrators, or to enumerate groups and group memberships from the local SAM and Active Directory. -This information can provide important context and serve as a starting point for an attacker to compromise a domain or networking environment. - -To mitigate this risk, you can configure the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting to force the security accounts manager (SAM) to do an access check against remote calls. -The access check allows or denies remote RPC connections to SAM and Active Directory for users and groups that you define. - -By default, the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting isn't defined. -If you define it, you can edit the default Security Descriptor Definition Language (SDDL) string to explicitly allow or deny users and groups to make remote calls to the SAM. -If the policy setting is left blank after the policy is defined, the policy isn't enforced. - -The default security descriptor on computers beginning with Windows 10 version 1607 and Windows Server 2016 allows only the local (built-in) Administrators group remote access to SAM on non-domain controllers, and allows Everyone access on domain controllers. -You can edit the default security descriptor to allow or deny other users and groups, including the built-in Administrators. - -The default security descriptor on computers that run earlier versions of Windows doesn't restrict any remote calls to SAM, but an administrator can edit the security descriptor to enforce restrictions. -This less restrictive default allows for testing the affect of enabling restrictions on existing applications. - -## Policy and Registry Names - -| | Description | -|:---|:---| -| **Policy Name** | Network access: Restrict clients allowed to make remote calls to SAM | -| **Location** | Computer Configuration\|Windows Settings\|Security Settings\|Local Policies\|Security Options | -| **Possible values** |
- Not defined
- Defined, along with the security descriptor for users and groups who are allowed or denied to use SAMRPC to remotely access either the local SAM or Active Directory. | -| **Registry location** | `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSam` | -| **Registry type** | REG_SZ | -| **Registry value** | A string that will contain the SDDL of the security descriptor to be deployed. | - -The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later. -These computers are the only option to configure this setting by using a user interface (UI). - -On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy Preferences. -To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server 2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same registry key exists on every computer after the corresponding KB is installed. - -> [!NOTE] -> This policy is implemented similarly to other "Network access" policies in that there is a single policy element at the registry path listed. There is no notion of a local policy versus an enterprise policy; there is just one policy setting and whichever writes last wins. -> -> For example, suppose a local administrator configures this setting as part of a local policy using the Local Security Policy snap-in (Secpol.msc), which edits that same registry path. If an enterprise administrator configures this setting as part of an enterprise GPO, that enterprise GPO will overwrite the same registry path. - -## Default values - -Beginning with Windows 10, version 1607 and Windows Server 2016, computers have hard-coded and more restrictive default values than earlier versions of Windows. -The different default values help strike a balance where recent Windows versions are more secure by default and older versions don't undergo any disruptive behavior changes. -Administrators can test whether applying the same restriction earlier versions of Windows will cause compatibility problems for existing applications before implementing this security policy setting in a production environment. - -In other words, the hotfix in each KB article provides the necessary code and functionality, but you need to configure the restriction after you install the hotfix—no restrictions are enabled by default after the hotfix is installed on earlier versions of Windows. - -| |Default SDDL |Translated SDDL| Comments | -|---|---|---|---| -|**Windows Server 2016 (or later) domain controller (reading Active Directory)**|""|-|Everyone has read permissions to preserve compatibility.| -|**Earlier domain controller** |-|-|No access check is performed by default.| -|**Windows 10, version 1607 (or later) non-domain controller**|`O:SYG:SYD:(A;;RC;;;BA)`| Owner: NTAUTHORITY/SYSTEM (WellKnownGroup) (S-1-5-18)
Primary group: NTAUTHORITY/SYSTEM (WellKnownGroup) (S-1-5-18)
DACL:
- Revision: 0x02
- Size: 0x0020
- Ace Count: 0x001
- Ace[00]-------------------------
  AceType:0x00
  (ACCESS\_ALLOWED_ACE_TYPE)
  AceSize:0x0018
  InheritFlags:0x00
  Access Mask:0x00020000
  AceSid: BUILTIN\Administrators (Alias) (S-1-5-32-544)

  SACL: Not present |Grants RC access (READ_CONTROL, also known as STANDARD_RIGHTS_READ) only to members of the local (built-in) Administrators group. | -|**Earlier non-domain controller** |-|-|No access check is performed by default.| - -## Policy management - -This section explains how to configure audit-only mode, how to analyze related events that are logged when the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting is enabled, and how to configure event throttling to prevent flooding the event log. - -### Audit only mode - -Audit-only mode configures the SAMRPC protocol to do the access check against the currently configured security descriptor but won't fail the call if the access check fails. Instead, the call will be allowed, but SAMRPC will log an event describing what would have happened if the feature had been enabled. This mode provides administrators a way to test their applications before enabling the policy in production. Audit only mode isn't configured by default. To configure it, add the following registry setting. - -|Registry|Details| -|---|---| -|Path|HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa| -|Setting|RestrictRemoteSamAuditOnlyMode| -|Data Type|REG_DWORD| -|Value|1| -|Notes|This setting can't be added or removed by using predefined Group Policy settings. Administrators may create a custom policy to set the registry value if needed. SAM responds dynamically to changes in this registry value without a reboot. | - -### Related events - -There are corresponding events that indicate when remote calls to the SAM are restricted, what accounts attempted to read from the SAM database, and more. The following workflow is recommended to identify applications that may be affected by restricting remote calls to SAM: - -1. Dump event logs to a common share. -1. Right click the System log, select **Filter Current Log**, and specify `16962-16969` in the Event IDs field. -1. Review Event IDs 16962 to 16969, as listed in the following table, with event source **Directory-Service-SAM**. -1. Identify which security contexts are enumerating users or groups in the SAM database. -1. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string. - -|Event ID|Event Message Text|Explanation | -|---|---|---| -|16962|"Remote calls to the SAM database are being restricted using the default security descriptor: %1.%n "

%2- "Default SD String:" |Emit event when registry SDDL is absent, causing fallback to default hard-coded SDDL (event should include a copy of the default SDDL).| -|16963|Message Text: "Remote calls to the SAM database are being restricted using the configured registry security descriptor: %1.%n"

%1 - "Registry SD String:" |Emit event when a new SDDL is read from the registry (either on startup or change) and is considered valid. The event includes the source and a copy of the queried SDDL. -|16964|"The registry security descriptor is malformed: %1.%n Remote calls to the SAM database are being restricted using the default security descriptor: %2.%n"

%1- "Malformed SD String:"
%2- "Default SD String:"|Emit event when registry SDDL is mal-formed, causing fallback to default hard-coded SDDL (event should include a copy of the default SDDL). -|16965|Message Text: "A remote call to the SAM database has been denied.%nClient SID: %1%n Network address: %2%n"

%1- "Client SID:" %2- "Client Network Address | Emit event when access is denied to a remote client. Event should include identity and network address of the client. -|16966|Audit Mode is enabled-

Message Text: "Audit only mode is now enabled for remote calls to the SAM database. SAM will log an event for clients who would have been denied access in normal mode. %n"|Emit event whenever training mode (see 16968) is enabled or disabled. -|16967|Audit Mode is disabled-

Message Text: "Audit only mode is now disabled for remote calls to the SAM database.%n For more information"|Emit event whenever training mode (see 16968) is enabled or disabled. -|16968| Message Text: "Audit only mode is currently enabled for remote calls to the SAM database.%n The following client would have been normally denied access:%nClient SID: %1 from network address: %2. %n"
%1- "Client SID:"
%2- "Client Network Address:"|Emit event when access would have been denied to a remote client, but was allowed through due to training mode being enabled. Event should include identity and network address of the client.| -|16969|Message Text: "%2 remote calls to the SAM database have been denied in the past %1-seconds throttling window.%n
"%1- "Throttle window:"
%2- "Suppressed Message Count:"| Throttling may be necessary for some events due to expected high volume on some servers causing the event log to wrap.

Note: There's no throttling of events when audit mode is enabled. Environments with a large number of low-privilege and anonymous querying of the remote database may see large numbers of events logged to the System log. For more info, see the [Event Throttling](#event-throttling) section. - -Compare the security context attempting to remotely enumerate accounts with the default security descriptor. Then edit the security descriptor to add accounts that require remote access. - -### Event throttling - -A busy server can flood event logs with events related to the remote enumeration access check. To prevent this, access-denied events are logged once every 15 minutes by default. The length of this period is controlled by the following registry value. - -|Registry Path|HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ | -|---|---| -Setting |RestrictRemoteSamEventThrottlingWindow| -Data Type |DWORD| -|Value|seconds| -|Reboot Required?|No| -|Notes|**Default** is 900 seconds (15 minutes).
The throttling uses a suppressed events counter that starts at 0 and gets incremented during the throttling window.
For example, X events were suppressed in the last 15 minutes.
The counter is restarted after the event 16969 is logged. - -### Restart requirement - -Restarts aren't required to enable, disable or modify the **Network access: Restrict clients allowed to make remote calls to SAM security** policy setting, including audit only mode. Changes become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The SAMRPC protocol has a default security posture that makes it possible for low-privileged attackers to query a machine on the network for data that is critical to their further hacking and penetration plans. - -The following example illustrates how an attacker might exploit remote SAM enumeration: - -1. A low-privileged attacker gains a foothold on a network. -2. The attacker then queries all machines on the network to determine which ones have a highly privileged domain user configured as a local administrator on that machine. -3. If the attacker can, then find any other vulnerability on that machine that allows taking it over, the attacker can then squat on the machine waiting for the high-privileged user to sign in and then steal or impersonate those credentials. - -### Countermeasure - -You can mitigate this vulnerability by enabling the **Network access: Restrict clients allowed to make remote calls** to SAM security policy setting and configuring the SDDL for only those accounts that are explicitly allowed access. - -### Potential affect - -If the policy is defined, admin tools, scripts and software that formerly enumerated users, groups and group membership may fail. To identify accounts that may be affected, test this setting in [audit only mode](#audit-only-mode). - -## Next steps - -[Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md deleted file mode 100644 index d4d2161114..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Network access Shares that can be accessed anonymously -description: Learn about best practices, security considerations, and more for the security policy setting, Network access Shares that can be accessed anonymously. -ms.assetid: f3e4b919-8279-4972-b415-5f815e2f0a1a -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Shares that can be accessed anonymously - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting. - -## Reference - -This policy setting determines which shared folders can be accessed by anonymous users. - -### Possible values - -- User-defined list of shared folders -- Not Defined - -### Best practices - -- Set this policy to a null value. There should be little impact because this null value is the default one. All users will have to be authenticated before they can access shared resources on the server. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any shared folders that are listed can be accessed by any network user, which could lead to the exposure or corruption of sensitive data. - -### Countermeasure - -Configure the **Network access: Shares that can be accessed anonymously** setting to a null value. - -### Potential impact - -There should be little impact because this state is the default configuration. Only authenticated users have access to shared resources on the server. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md deleted file mode 100644 index 3e5ed1f57e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Network access Sharing and security model for local accounts -description: Best practices, security considerations, and more for the security policy setting, Network access Sharing and security model for local accounts. -ms.assetid: 0b3d703c-ea27-488f-8f59-b345af75b994 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network access: Sharing and security model for local accounts - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting. - -## Reference - -This policy setting determines how network logons that use local accounts are authenticated. If you configure this policy setting to Classic, network logons that use local account credentials authenticate with those credentials. If you configure this policy setting to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The Classic model provides precise control over access to resources, and it enables you to grant different types of access to different users for the same resource. Conversely, the Guest only model treats all users equally, and they all receive the same level of access to a given resource, which can be either Read Only or Modify. - ->**Note:**  This policy setting does not affect network logons that use domain accounts. Nor does this policy setting affect interactive logons that are performed remotely through services such as Telnet or Remote Desktop Services. -When the device is not joined to a domain, this policy setting also tailors the **Sharing** and **Security** tabs in Windows Explorer to correspond to the sharing and security model that is being used. - -When the value of this policy setting is **Guest only - local users authenticate as Guest**, any user who can access your device over the network does so with Guest user rights. This privilege means that they'll probably be unable to write to shared folders. Although this restriction does increase security, it makes it impossible for authorized users to access shared resources on those systems. When the value is **Classic - local users authenticate as themselves**, local accounts must be password-protected; otherwise, anyone can use those user accounts to access shared system resources. - -### Possible values - -- Classic - Local users authenticate as themselves -- Guest only - Local users authenticate as Guest -- Not defined - -### Best practices - -1. For network servers, set this policy to **Classic - local users authenticate as themselves**. -2. On end-user systems, set this policy to **Guest only - local users authenticate as Guest**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Classic (local users authenticate as themselves)| -| DC Effective Default Settings | Classic (local users authenticate as themselves)| -| Member Server Effective Default Settings | Classic (local users authenticate as themselves)| -| Client Computer Effective Default Settings | Classic (local users authenticate as themselves)| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -With the Guest only model, any user who can authenticate to your device over the network does so with Guest privileges, which probably means that they don't have Write access to shared resources on that device. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources. - -### Countermeasure - -For network servers, configure the **Network access: Sharing and security model for local accounts setting** to **Classic – local users authenticate as themselves**. On end-user computers, configure this policy setting to **Guest only – local users authenticate as guest**. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-list-manager-policies.md b/windows/security/threat-protection/security-policy-settings/network-list-manager-policies.md deleted file mode 100644 index 36e4ff299e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-list-manager-policies.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Network List Manager policies -description: Network List Manager policies are security settings that configure different aspects of how networks are listed and displayed on one device or on many devices. -ms.assetid: bd8109d4-b07c-4beb-a9a6-affae2ba2fda -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network List Manager policies - -**Applies to** -- Windows 11 -- Windows 10 - -Network List Manager policies are security settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices. - -To configure Network List Manager Policies for one device, you can use the Microsoft Management Console (MMC) with the Group Policy Object Editor snap-in, and edit the local computer policy. The Network List Manager Policies are located at the following path in Group Policy Object Editor: -**Computer Configuration | Windows Settings | Security Settings | Network List Manager Policies** - -To configure Network List Manager Policies for many computers, such as for all of the Domain Computers in an Active Directory domain, follow Group Policy documentation to learn how to edit the policies for the object that you require. The path to the Network List Manager Policies is the same as the path listed above. - -### Policy settings for Network List Manager Policies - -The following policy settings are provided for Network List Manager Policies. These policy settings are located in the details pane of the Group Policy Object Editor, in **Network Name**. - -### Unidentified Networks - -This policy setting allows you to configure the **Network Location**, including the location type and the user permissions, for networks that Windows cannot identify due to a network issue or a lack of identifiable characters in the network information received by the operating system from the -network. A network location identifies the type of network that a computer is connected to and automatically sets the appropriate firewall settings for that location. You can configure the following items for this policy setting: - -- **Location type**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not apply a location type to unidentified network connections. - - **Private**. If you select this option, this policy setting applies a location type of Private to unidentified network connections. A private network, such as a home or work network, is a location type that assumes that you trust the other computers on the network. Do not select this item if there is a possibility that an active, unidentified network is in a public place. - - - **Public**. If you select this option, this policy setting applies a location type of Public to unidentified network connections. A public network, such as a wireless network at an airport or coffee shop, is a location type that assumes that you do not trust the other computers on the network. - -- **User permissions**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not specify whether users can change the location for unidentified network connections. - - **User can change location**. If you select this option, this policy setting allows users to change an unidentified network connection location from Private to Public or from Public to Private. - - **User cannot change location**. If you select this option, this policy setting does not allow users to change the location of an unidentified network connection. - -### Identifying Networks - -This policy setting allows you to configure the **Network Location** for networks that are in a temporary state while Windows works to identify the network and location type. A network location identifies the type of network that a computer is connected to and automatically sets the appropriate firewall settings for that location. You can configure the following items for this policy setting: - -- **Location type**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not apply a location type to network connections that are in the process of being identified by Windows. - - **Private**. If you select this option, this policy setting applies a location type of Private to network connections that are in the process of being identified. A private network, such as a home or work network, is a location type that assumes that you trust the other devices on the network. Do not select this item if there is a possibility that an active, unidentified network is in a public place. - - **Public**. If you select this option, this policy setting applies a location type of Public to network connections that are in the process of being identified by Windows. A public network, such as a wireless network at an airport or coffee shop, is a location type that assumes that you do not trust the other devices on the network. - -### All Networks - -This policy setting allows you to specify the **User Permissions** that control whether users can change the network name, location, or icon, for all networks to which the user connects. You can configure the following items for this policy setting: - -- **Network name**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not specify whether users can change the network name for all network connections. - - **User can change name**. If you select this option, users can change the network name for all networks to which they connect. - - **User cannot change name**. If you select this option, users cannot change the network name for any networks to which they connect. - -- **Network location**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not specify whether users can change the location for all network connections. - - **User can change location**. If you select this option, this policy setting allows users to change all network locations from Private to Public or from Public to Private. - - **User cannot change location**. If you select this option, this policy setting does not allow users to change the location for any networks to which they connect. - -- **Network icon**. For this item, the following options are available: - - - **Not configured**. If you select this option, this policy setting does not specify whether users can change the network icon for all network connections. - - **User can change icon**. If you select this option, this policy setting allows users to change the network icon for all networks to which the user connects. - - **User cannot change icon**. If you select this option, this policy setting does not allow users to change the network icon for any networks to which the user connects. diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md deleted file mode 100644 index 9d920c4925..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: "Network security: Allow Local System to use computer identity for NTLM (Windows 10)" -description: Location, values, policy management, and security considerations for the policy setting, Network security Allow Local System to use computer identity for NTLM. -ms.assetid: c46a658d-b7a4-4139-b7ea-b9268c240053 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 10/04/2021 ---- - -# Network security: Allow Local System to use computer identity for NTLM - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting. - -## Reference - -When services connect to devices that are running versions of the Windows operating system earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will authenticate anonymously. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity. - -When a service connects with the device identity, signing and encryption are supported to provide data protection. (When a service connects anonymously, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors. Anonymous authentication uses a NULL session, which is a session with a server in which no user authentication is performed; and therefore, anonymous access is allowed.) - -### Possible values - -| Setting | Windows Server 2008 and Windows Vista | At least Windows Server 2008 R2 and Windows 7 | -| - | - | - | -| Enabled | Services running as Local System that use Negotiate will use the computer identity. This value might cause some authentication requests between Windows operating systems to fail and log an error.| Services running as Local System that use Negotiate will use the computer identity. This behavior is the default behavior. | -| Disabled| Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously. This behavior is the default behavior.| Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously.| -|Neither|Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously. | Services running as Local System that uses Negotiate will use the computer identity. This behavior might cause some authentication requests between Windows operating systems to fail and log an error.| - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not applicable| -| Member server effective default settings | Not applicable| -| Effective GPO default settings on client computers | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy conflict considerations - -The policy [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md), if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. This privilege will increase the success of interoperability at the expense of security. - -The anonymous authentication behavior is different for Windows Server 2008 and Windows Vista than later versions of Windows. Configuring and applying this policy setting on those systems might not produce the same results. - -### Group Policy - -This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When a service connects to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL session. In Windows Server 2008 R2 and Windows 7 and later, if a service connects to a computer running Windows Server 2008 or Windows Vista, the system service uses the computer identity. - -When a service connects with the computer identity, signing and encryption are supported to provide data protection. When a service connects with a NULL session, a system-generated session key is created, which provides no protection, but it allows applications to sign and encrypt data without errors. - -### Countermeasure - -You can configure the **Network security: Allow Local System to use computer identity for NTLM** security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication. - -### Potential impact - -If you don't configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local System that uses the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008. -Beginning with Windows Server 2008 R2 and Windows 7, the system allows Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication. - -## Related articles - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md deleted file mode 100644 index db63f8cfbc..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Network security Allow LocalSystem NULL session fallback -description: Describes the best practices, location, values, and security considerations for the Network security Allow LocalSystem NULL session fallback security policy setting. -ms.assetid: 5b72edaa-bec7-4572-b6f0-648fc38f5395 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Allow LocalSystem NULL session fallback - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting. - -## Reference - -This policy affects session security during the authentication process between devices running Windows Server 2008 R2 and Windows 7 and later and those devices running earlier versions of the Windows operating system. For computers running Windows Server 2008 R2 and Windows 7 and later, services running as Local System require a service principal name (SPN) to generate the session key. However, if [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md) is set to disabled, services running as Local -System will fall back to using NULL session authentication when they transmit data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session doesn't establish a unique session key for each authentication; and thus, it can't provide integrity or confidentiality protection. The setting **Network security: Allow LocalSystem NULL session fallback** determines whether services that request the use of session security are allowed to perform signature or encryption functions with a well-known key for application compatibility. - -### Possible values - -- **Enabled** - - When a service running as Local System connects with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. This increases application compatibility, but it degrades the level of security. - -- **Disabled** - - When a service running as Local System connects with a NULL session, session security will be unavailable. Calls seeking encryption or signing will fail. This setting is more secure, but at the risk of degrading application incompatibility. Calls that are using the device identity instead of a - NULL session will still have full use of session security. - -- Not defined. When this policy isn't defined, the default takes effect. This policy is Enabled for versions of the Windows operating system earlier than Windows Server 2008 R2 and Windows 7, and it's Disabled otherwise. - -### Best practices - -When services connect with the device identity, signing and encryption are supported to provide data protection. When services connect with a NULL session, this level of data protection isn't provided. However, you'll need to evaluate your environment to determine the Windows operating system versions that you support. If this policy is enabled, some services may not be able to authenticate. - -This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer requires support for Windows NT 4, this policy should be disabled. By default, it's disabled in Windows 7 and Windows Server 2008 R2 and later. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not applicable| -| Member server effective default settings | Not applicable | -| Effective GPO default settings on client computers | Not applicable| - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If this setting is Enabled, when a service connects with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. Data that is intended to be protected might be exposed. - -### Countermeasure - -You can configure the computer to use the computer identity for Local System with the policy **Network security: Allow Local System to use computer identity for NTLM**. If that isn't possible, this policy can be used to prevent data from being exposed in transit if it was protected with a well-known key. - -### Potential impact - -If you enable this policy, services that use NULL session with Local System could fail to authenticate because they'll be prohibited from using signing and encryption. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md deleted file mode 100644 index 9ebd32dab8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Network security Allow PKU2U authentication requests to this computer to use online identities -description: Best practices for the Network Security Allow PKU2U authentication requests to this computer to use online identities security setting. -ms.assetid: e04a854e-d94d-4306-9fb3-56e9bd7bb926 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 01/03/2022 ---- - -# Network security: Allow PKU2U authentication requests to this computer to use online identities - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting. - -## Reference - -From Windows Server 2008 R2 and Windows 7, the Negotiate Security Support Provider (SSP) supports an extension SSP, Negoexts.dll. This extension SSP is treated as an authentication protocol by the Windows operating system. It supports SSPs from Microsoft, including PKU2U. You can also develop or add other SSPs. - -When devices are configured to accept authentication requests by using online IDs, Negoexts.dll calls the PKU2U SSP on the computer that's used to sign in. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When it's validated on the peer computer, the certificate within the metadata is sent to the sign-in peer for validation. It associates the user's certificate to a security token, and then the sign-in process completes. - -> [!NOTE] -> Linking online IDs can be performed by anyone who has an account that has standard user’s credentials through Credential Manager. - -This policy isn't configured by default on domain-joined devices. This disablement would disallow the online identities to authenticate to domain-joined computers from Windows 7 up to Windows 10, Version 1607. This policy is enabled by default in Windows 10, Version 1607, and later. - -### Possible values - -- **Enabled**: This setting allows authentication to successfully complete between the two (or more) computers that have established a peer relationship by using online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer devices. When validated on the peer computer, the certificate within the metadata is sent to the sign-in peer for validation. It associates the user's certificate to a security token, and then the sign-in process completes. - - > [!NOTE] - > PKU2U is disabled by default on Windows Server. If PKU2U is disabled, Remote Desktop connections from a Microsoft Entra hybrid joined server to a Microsoft Entra joined Windows 10 device or a Microsoft Entra hybrid joined domain member Windows 10 device fail. To resolve this, enable PKU2U on the server and the client. - -- **Disabled**: This setting prevents online IDs from being used to authenticate the user to another computer in a peer-to-peer relationship. - -- ***Not set***: Not configuring this policy prevents online IDs from being used to authenticate the user. This option is the default on domain-joined devices. - -### Best practices - -Within a domain, domain accounts should be used for authentication. Set this policy to **Disabled** or don't configure this policy to exclude online identities from being used to authenticate for on-premises only environments. Set this policy to **Enabled** for hybrid and Microsoft Entra joined environments. - -### Location - -*Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options* - -### Default values - -The following table lists the effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Disabled| -| Member server effective default settings | Disabled| -| Effective GPO default settings on client computers prior to Windows 10, Version 1607 | Disabled| -| Effective GPO default settings on client computers Windows 10, Version 1607 and later| Enabled| - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of the countermeasure. - -### Vulnerability - -Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or a Microsoft Entra account. That account can then sign in to a peer device (if the peer device is likewise configured) without the use of a Windows sign-in account (domain or local). This setup isn't only beneficial, but required for Microsoft Entra joined devices, where they're signed in with an online identity and are issued certificates by Microsoft Entra ID. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it doesn't pose any threats in a hybrid environment where Microsoft Entra ID is used as it relies on the user's online identity and Microsoft Entra ID to authenticate. - -### Countermeasure - -Set this policy to *Disabled* or don't configure this security policy for *on-premises only* environments. - -### Potential impact - -If you don't set or you disable this policy, the PKU2U protocol won't be used to authenticate between peer devices, which forces users to follow domain-defined access control policies. This disablement is a valid configuration in *on-premises only* environments. Some roles/features (such as Failover Clustering) don't utilize a domain account for its PKU2U authentication and will cease to function properly when disabling this policy. - -If you enable this policy in a hybrid environment, you allow your users to authenticate by using certificates issued by Microsoft Entra ID and their online identity between the corresponding devices. This configuration allows users to share resources between such devices. If this policy isn't enabled, remote connections to a Microsoft Entra joined device won't work. - -### Fix/Remediation - -This vulnerability was fixed on February 9, 2021, in the [CVE-2021-25195](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-25195) Security Update. - -## Related topics - -- [Security options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md b/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md deleted file mode 100644 index dddf04ec16..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Network security Configure encryption types allowed for Kerberos -description: Best practices, location, values and security considerations for the policy setting, Network security Configure encryption types allowed for Kerberos Win7 only. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Configure encryption types allowed for Kerberos - -**Applies to** -- Windows 11 -- Windows 10 -- Windows Server - -Describes the best practices, location, values, and security considerations for the **Network security: Configure encryption types allowed for Kerberos** security policy setting. - -## Reference - -This policy setting allows you to set the encryption types that the Kerberos protocol is allowed to use. If it isn't selected, the encryption type won't be allowed. This setting might affect compatibility with client computers or services and applications. Multiple selections are permitted. - -For more information, see [KDC event ID 16 or 27 is logged if DES for Kerberos is disabled](/troubleshoot/windows-server/windows-security/kdc-event-16-27-des-encryption-disabled). - -The following table lists and explains the allowed encryption types. - - -| Encryption type | Description and version support | -| - | - | -| DES_CBC_CRC | Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, and later operating systems don't support DES by default. | -| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, and later operating systems don't support DES by default. | -| RC4_HMAC_MD5| Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.| -| AES128_HMAC_SHA1| Advanced Encryption Standard in 128-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | -| AES256_HMAC_SHA1| Advanced Encryption Standard in 256-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003.
Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. | -| Future encryption types| Reserved by Microsoft for other encryption types that might be implemented.| - -### Possible values - - -The encryption type options include: - -- DES\_CBC\_CRC -- DES\_CBC\_MD5 -- RC4\_HMAC\_MD5 -- AES128\_HMAC\_SHA1 -- AES256\_HMAC\_SHA1 -- Future encryption types - - As of the release of Windows 7 and Windows Server 2008 R2, these options are reserved by Microsoft for other encryption types that might be implemented. - -### Best practices - -Analyze your environment to determine which encryption types will be supported and then select the types that meet that evaluation. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy| Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | The default OS setting applies, DES suites aren't supported by default.| -| Member server effective default settings | The default OS setting applies, DES suites aren't supported by default.| -| Effective GPO default settings on client computers | The default OS setting applies, DES suites aren't supported by default.| - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Windows Server 2008 R2, Windows 7, and Windows 10, don't support the DES cryptographic suites because stronger ones are available. To enable Kerberos interoperability with non-Windows versions of the Kerberos protocol, these suites can be enabled. However, doing so might open attack vectors on computers running -Windows Server 2008 R2, Windows 7 and Windows 10. You can also disable DES for your computers running Windows Vista and Windows Server 2008. - -### Countermeasure - -Don't configure this policy. This disablement will force the computers running Windows Server 2008 R2, Windows 7, and Windows 10 to use the AES or RC4 cryptographic suites. - -### Potential impact - -If you don't select any of the encryption types, computers running Windows Server 2008 R2, Windows 7 and Windows 10, might have Kerberos authentication failures when connecting with computers running non-Windows versions of the Kerberos protocol. - - -If you do select any encryption type, you'll lower the effectiveness of encryption for Kerberos authentication but you'll improve interoperability with computers running older versions of Windows. -Contemporary non-Windows implementations of the Kerberos protocol support RC4 and AES 128-bit and AES 256-bit encryption. Most implementations, including the MIT Kerberos protocol and the Windows Kerberos protocol, are deprecating DES encryption. - -## Related articles - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md b/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md deleted file mode 100644 index a421232bf4..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Network security Do not store LAN Manager hash value on next password change -description: Best practices, security considerations, and more for the security policy setting, Network security Do not store LAN Manager hash value on next password change. -ms.assetid: 6452b268-e5ba-4889-9d38-db28f919af51 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Do not store LAN Manager hash value on next password change - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting. - -## Reference - -This policy setting determines whether LAN Manager is prevented from storing hash values for the new password the next time the password is changed. Hash values are a representation of the password after the encryption algorithm is applied that corresponds to the format that is specified by the algorithm. To decrypt the hash value, the encryption algorithm must be determined and then reversed. The LAN Manager hash is relatively weak and prone to attack compared to the cryptographically stronger NTLM hash. Because the LM hash is stored on the local device in the security database, the passwords can be compromised if the security database, Security Accounts Manager (SAM), is attacked. - -When the attackers attack the SAM file, they can potentially gain access to user names and password hashes. Attackers can use a password-cracking tool to determine what the password is. After they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this policy setting won't prevent these types of attacks, but it will make them much more difficult. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - - - Set **Network security: Do not store LAN Manager hash value on next password change** to **Enabled**. - - Require all users to set new passwords the next time they sign in to the domain so that LAN Manager hashes are removed. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings|Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The SAM file can be targeted by attackers who seek access to user names and password hashes. Such attacks use special tools to discover passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks aren't prevented by enabling this policy setting because LAN Manager hashes are much weaker than NTLM hashes, but it's much more difficult for these attacks to succeed. - -### Countermeasure - -Enable the **Network security: Do not store LAN Manager hash value on next password change** setting. Require all users to set new passwords the next time they sign in to the domain so that LAN Manager hashes are removed. - -### Potential impact - -Some non-Microsoft applications might not be able to connect to the system. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md deleted file mode 100644 index 7af8f09acd..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Network security Force logoff when logon hours expire -description: Best practices, location, values, policy management, and security considerations for the policy setting, Network security Force logoff when logon hours expire. -ms.assetid: 64d5dde4-58e4-4217-b2c4-73bd554ec926 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Force logoff when logon hours expire - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting. - -## Reference - -This security setting determines whether to disconnect users who are connected to the local device outside their user account's valid sign-in hours. This setting affects the Server Message Block (SMB) component. - -This policy setting doesn't apply to administrator accounts, but it behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it's enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy Object (GPO), even if there's a different account policy that is applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member devices) also receive the same account policy for their local accounts. However, local account policies for member devices can be different from the domain account policy by defining an account policy for the organizational unit that contains the member devices. Kerberos settings aren't applied to member devices. - -### Possible values - -- Enabled - - When enabled, this policy causes client sessions with the SMB server to be forcibly disconnected when the client's sign-in hours expire. - -- Disabled - - When disabled, this policy allows for the continuation of an established client session after the client's sign-in hours have expired. - -- Not defined - -### Best practices - -- Set **Network security: Force logoff when logon hours expire** to Enabled. SMB sessions will be terminated on member servers when a user's sign-in time expires, and the user will be unable to sign in to the system until their next scheduled access time begins. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Disabled| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If you disable this policy setting, users can remain connected to the computer outside of their allotted sign-in hours. - -### Countermeasure - -Enable the **Network security: Force logoff when logon hours expire** setting. This policy setting doesn't apply to administrator accounts. - -### Potential impact - -When a user's sign-in time expires, SMB sessions terminate. The user can't sign in to the device until the next scheduled access time commences. - -## Related articles - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md b/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md deleted file mode 100644 index 806700542f..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Network security LAN Manager authentication level -description: Best practices, location, values, policy management and security considerations for the policy setting, Network security LAN Manager authentication level. -ms.assetid: bbe1a98c-420a-41e7-9d3c-3a2fe0f1843e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: LAN Manager authentication level - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network security: LAN Manager authentication level** security policy setting. - -## Reference - -This policy setting determines which challenge or response authentication protocol is used for network logons. LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal devices together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol isn't negotiated for some reason, Active Directory uses LM, NTLM, or NTLM version 2 (NTLMv2). - -LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it's the protocol that is used to authenticate all client devices running the Windows operating system when they perform the following operations: - -- Join a domain -- Authenticate between Active Directory forests -- Authenticate to domains based on earlier versions of the Windows operating system -- Authenticate to computers that don't run Windows operating systems, beginning with Windows 2000 -- Authenticate to computers that aren't in the domain - -### Possible values - -- Send LM & NTLM responses -- Send LM & NTLM - use NTLMv2 session security if negotiated -- Send NTLM responses only -- Send NTLMv2 responses only -- Send NTLMv2 responses only. Refuse LM -- Send NTLMv2 responses only. Refuse LM & NTLM -- Not Defined - -The **Network security: LAN Manager authentication level** setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the -authentication level that servers accept. The following table identifies the policy settings, describes the setting, and identifies the security level used in the corresponding registry setting if you choose to use the registry to control this setting instead of the policy setting. - -| Setting | Description | Registry security level | -| - | - | - | -| Send LM & NTLM responses | Client devices use LM and NTLM authentication, and they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 0| -| Send LM & NTLM – use NTLMv2 session security if negotiated | Client devices use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 1| -| Send NTLM response only| Client devices use NTLMv1 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 2| -| Send NTLMv2 response only | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 3| -| Send NTLMv2 response only. Refuse LM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they'll accept only NTLM and NTLMv2 authentication.| 4| -| Send NTLMv2 response only. Refuse LM & NTLM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they'll accept only NTLMv2 authentication.| 5| - -### Best practices - -- Best practices are dependent on your specific security and authentication requirements. - -### Policy Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Registry Location - -HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Send NTLMv2 response only| -| DC Effective Default Settings | Send NTLMv2 response only| -| Member Server Effective Default Settings | Send NTLMv2 response only| -| Client Computer Effective Default Settings | Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Modifying this setting may affect compatibility with client devices, services, and applications. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -In Windows 7 and Windows Vista, this setting is undefined. In Windows Server 2008 R2 and later, this setting is configured to **Send NTLMv2 responses only**. - -### Countermeasure - -Configure the **Network security: LAN Manager Authentication Level** setting to **Send NTLMv2 responses only**. Microsoft and many independent organizations strongly recommend this level of authentication when all client computers support NTLMv2. - -### Potential impact - -Client devices that don't support NTLMv2 authentication can't authenticate in the domain and access domain resources by using LM and NTLM. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md deleted file mode 100644 index 1c8757c3f8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Network security LDAP client signing requirements -description: Best practices, location, values, policy management and security considerations for the policy setting, Network security LDAP client signing requirements. -ms.assetid: 38b35489-eb5b-4035-bc87-df63de50509c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: LDAP client signing requirements - -**Applies to** -- Windows 11 -- Windows 10 - -This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system. - -## Reference - -This policy setting determines the level of data signing that is requested on behalf of client devices that issue LDAP BIND requests. The levels of data signing are described in the following list: - -- **None**. The LDAP BIND request is issued with the caller-specified options. -- **Negotiate signing**. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) hasn't been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options. -- **Require signing**. This level is the same as **Negotiate signing**. However, if the LDAP server's intermediate saslBindInProgress response doesn't indicate that LDAP traffic signing is required, the caller is returned a message that the LDAP BIND command request failed. - -Misuse of this policy setting is a common error that can cause data loss or problems with data access or security. - -### Possible values - -- None -- Negotiate signing -- Require signature -- Not Defined - -### Best practices - -- Set both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings to **Require signing**. To avoid usage of unsigned traffic, set both client and server sides to require signing. Not setting one of the sides will prevent client computers from communicating with the server. This prevention can cause many features to fail, including user authentication, Group Policy, and logon scripts. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Negotiate signing| -| DC Effective Default Settings | Negotiate signing| -| Member Server Effective Default Settings | Negotiate signing| -| Client Computer Effective Default Settings | Negotiate signing| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Modifying this setting may affect compatibility with client devices, services, and applications. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures the packets between the client computer and server, modifies them, and then forwards them to the server. For an LDAP server, this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered data from the LDAP queries. To lower this risk in your network, you can implement strong physical security measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks difficult if you require digital signatures on all network packets throughs IPsec authentication headers. - -### Countermeasure - -Configure the **Network security: LDAP client signing requirements** setting to **Require signing**. - -### Potential impact - -If you configure the client to require LDAP signatures, it may fail to communicate with the LDAP servers that don't require requests to be signed. To avoid this issue, make sure that both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings are set to **Require signing**. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md deleted file mode 100644 index 5c12f9b876..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Network security Minimum session security for NTLM SSP based (including secure RPC) clients -description: Best practices and more for the security policy setting, Network security Minimum session security for NTLM SSP based (including secure RPC) clients. -ms.assetid: 89903de8-23d0-4e0f-9bef-c00cb7aebf00 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 07/27/2017 ---- - -# Network security: Minimum session security for NTLM SSP based (including secure RPC) clients - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting. - -## Reference - -This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session security. These values are dependent on the **Network security: LAN Manager Authentication Level policy** setting value. - -### Possible values - -- Require NTLMv2 session security - - The connection fails if the NTLMv2 protocol is not negotiated. - -- Require 128-bit encryption - - The connection fails if strong encryption (128-bit) is not negotiated. - -### Best practices - -Practices in setting this policy are dependent on your security requirements. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Require 128-bit encryption| -| DC Effective Default Settings | Require 128-bit encryption| -| Member Server Effective Default Settings | Require 128-bit encryption| -| Client Computer Effective Default Settings | Require 128-bit encryption| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy. - -### Policy conflicts - -The settings for this security policy are dependent on the **Network security: LAN Manager Authentication Level policy** setting value. For info about this policy, see [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks. - -### Countermeasure - -Enable all options that are available for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients policy** setting. - -### Potential impact - -Client devices that enforce these settings cannot communicate with older servers that do not support them. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md deleted file mode 100644 index 952c7a8873..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Network security Minimum session security for NTLM SSP based (including secure RPC) servers -description: Best practices and security considerations for the policy setting, Network security Minimum session security for NTLM SSP based (including secure RPC) servers. -ms.assetid: c6a60c1b-bc8d-4d02-9481-f847a411b4fc -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Minimum session security for NTLM SSP based (including secure RPC) servers - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting. - -## Reference - -This policy setting allows a client device to require the negotiation of 128-bit encryption or NTLMv2 session security. These values are dependent on the [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md) policy setting value. - -Setting all of these values for this policy setting will help protect network traffic that uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered with by a malicious user who has gained access to the same network. That is, these settings help protect against man-in-the-middle attacks. - -### Possible values - -- Require 128-bit encryption. The connection fails if strong encryption (128-bit) isn't negotiated. -- Require NTLMv2 session security. The connection fails if the NTLMv2 protocol isn't negotiated. -- Not Defined. - -### Best practices - -- Enable all values that are available for this security policy. Legacy client devices that don't support these policy settings will be unable to communicate with the server. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Require 128-bit encryption| -| DC Effective Default Settings | Require 128-bit encryption| -| Member Server Effective Default Settings | Require 128-bit encryption| -| Client Computer Effective Default Settings | Require 128-bit encryption| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Policy dependencies - -The settings for this security policy are dependent on the [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md) setting value. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks. - -### Countermeasure - -Enable all options that are available for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** policy setting. - -### Potential impact - -Older client devices that don't support these security settings can't communicate with the computer on which this policy is set. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md deleted file mode 100644 index bc6bb0004a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Network security Restrict NTLM Add remote server exceptions for NTLM authentication -description: Best practices, security considerations, and more for the policy setting, Network security Restrict NTLM Add remote server exceptions for NTLM authentication. -ms.assetid: 9b017399-0a54-4580-bfae-614c2beda3a1 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** security policy setting. - -## Reference - -The **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** policy setting allows you to create an exception list of remote servers to which client devices are allowed to use NTLM authentication if the [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) policy setting is configured. - -If you configure this policy setting, you can define a list of remote servers to which client devices are allowed to use NTLM authentication. - -If you don't configure this policy setting, no exceptions will be applied, and if [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, NTLM authentication attempts from the client devices will fail. - -List the NetBIOS server names that are used by the applications as the naming format, one per line. To ensure exceptions, the names that are used by all applications need to be in the list. A single asterisk (\*) can be used anywhere in the string as a wildcard character. - -### Possible values - -- User-defined list of remote servers - - When you enter a list of remote servers to which clients are allowed to use NTLM authentication, the policy is defined and enabled. - -- Not defined - - If you don't configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied. - -### Best practices - -1. First enforce the [Network Security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md) or [Network Security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md) policy setting and then review the operational event log to understand which servers are involved in these authentication attempts so you can decide which servers to exempt. - -2. After you have set the server exception list, enforce the [Network Security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md) or [Network Security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md) policy setting and then review the operational event log again before setting the policies to block NTLM traffic. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings| Not defined| - -## Policy management - -This section describes the features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy through Group Policy takes precedence over the setting on the local device. If the Group Policy setting is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if your server exception list is functioning as intended. Audit and block events are recorded on this device in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. - -There are no security audit policies that can be configured to view output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When it has been determined that the NTLM authentication protocol shouldn't be used from a client device to any remote servers because you're required to use a more secure protocol such as Kerberos, there might be some client applications that still use NTLM. If so, and you set [Network Security: -Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) to any of the deny options, those applications will fail because the outbound NTLM authentication traffic from the client computer will be blocked. - -If you define an exception list of servers to which client devices are allowed to use NTLM authentication, then NTLM authentication traffic will continue to flow between those client applications and servers. The servers then are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM. - -### Countermeasure - -When you use [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the remote -servers in your environment. When assessed, you'll have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, the client application has to be upgraded to use something other than NTLM authentication. - -### Potential impact - -Defining a list of servers for this policy setting will enable NTLM authentication traffic from the client application that uses those servers, and this traffic might result in a security vulnerability. - -If this list isn't defined and [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, then client applications that use NTLM will fail to authenticate to those servers that they've previously used. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md deleted file mode 100644 index fe6fa9e00a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Network security Restrict NTLM Add server exceptions in this domain -description: Best practices, security considerations, and more for the security policy setting, Network security Restrict NTLM Add server exceptions in this domain. -ms.assetid: 2f981b68-6aa7-4dd9-b53d-d88551277cc0 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Restrict NTLM: Add server exceptions in this domain - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add server exceptions in this domain** security policy setting. - -## Reference - -The **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting allows you to create an exception list of servers in this domain to which client devices are allowed to use NTLM pass-through authentication if any of the deny options are set in the [Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) policy setting. - -If you configure this policy setting, you can define a list of servers in this domain to which client devices are allowed to use NTLM authentication. - -If you don't configure this policy setting, no exceptions will be applied, and if **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, all NTLM authentication attempts in the domain will fail. - -List the NetBIOS server names as the naming format, one per line. A single asterisk (\*) can be used anywhere in the string as a wildcard character. - -### Possible values - -- User-defined list of servers - - When you enter a list of servers in this domain to which clients are allowed to use NTLM authentication, the policy is defined and enabled. - -- Not defined - - If you don't configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied. - -### Best practices - -1. First enforce the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the operational event log to understand what domain controllers are involved in these authentication attempts so you can decide which servers to exempt. -2. After you have set the server exception list, enforce the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the operational event log again before setting the policies to block NTLM traffic. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined | -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy via Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if your server exception list is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. - -There are no security audit policies that can be configured to view output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -When it has been determined that the NTLM authentication protocol shouldn't be used within a domain because you're required to use a more secure protocol such as Kerberos, there might be some NTLM authentication traffic that is still present in the domain. If so, and you set Network Security: -[Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) to any of the deny options, any NTLM authentication request will fail because the pass-through member server will block the NTLM request. - -If you define an exception list of servers in this domain to which client computers are allowed to use NTLM pass-through authentication, then NTLM authentication traffic will continue to flow between those servers, which make them vulnerable to any malicious attack that takes advantage of security -weaknesses in NTLM. - -### Countermeasure - -When you use **Network Security: Restrict NTLM: NTLM authentication in this domain** in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the pass-through authentication servers. When assessed, you'll have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. - -### Potential impact - -Defining a list of servers for this policy setting will enable NTLM authentication traffic between those servers might result in a security vulnerability. - -If this list isn't defined and **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, then NTLM authentication will fail on those pass-through servers in the domain that they've previously used - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md deleted file mode 100644 index 23ba1014a2..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Network security Restrict NTLM Audit incoming NTLM traffic -description: Best practices, security considerations and more for the security policy setting, Network Security Restrict NTLM Audit incoming NTLM traffic. -ms.assetid: 37e380c2-22e1-44cd-9993-e12815b845cf -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Restrict NTLM: Audit incoming NTLM traffic - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit incoming NTLM traffic** security policy setting. - -## Reference - -The **Network Security: Restrict NTLM: Audit incoming NTLM traffic** policy setting allows you to audit incoming NTLM traffic. - -When this audit policy is enabled within Group Policy, it's enforced on any server where that Group Policy is distributed. The events will be recorded in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently. - -When you enable this policy on a server, only authentication traffic to that server will be logged. - -When you enable this audit policy, it functions in the same way as the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy, but it doesn't actually block any traffic. Therefore, you can use it effectively to understand the -authentication traffic in your environment, and when you're ready to block that traffic, you can enable the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting and select **Deny all accounts** or **Deny all domain accounts**. - -### Possible values - -- Disable - - The server on which this policy is set won't log events for incoming NTLM traffic. - -- Enable auditing for domain accounts - - The server on which this policy is set will log events for NTLM pass-through authentication requests only for accounts in the domain that would be blocked when the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy setting is set to **Deny all domain accounts**. - -- Enable auditing for all accounts - - The server on which this policy is set will log events for all NTLM authentication requests that would be blocked when the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy setting is set to **Deny all accounts**. - -- Not defined - - This state of not being defined is the same as **Disable**, and it results in no auditing of NTLM traffic. - -### Best practices - -Depending on your environment and the duration of your testing, monitor the log size regularly. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently. - -There are no security audit event policies that can be configured to view output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards. - -### Vulnerability - -Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting doesn't prevent or mitigate any vulnerability because it is for audit purposes only. - -### Countermeasure - -Restrict access to the log files when this policy setting is enabled in your production environment. - -### Potential impact - -If you don't enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md deleted file mode 100644 index 533e169c84..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Network security Restrict NTLM Audit NTLM authentication in this domain -description: Best practices, security considerations, and more for the security policy setting, Network Security Restrict NTLM Audit NTLM authentication in this domain. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Restrict NTLM: Audit NTLM authentication in this domain - -**Applies to** -- Windows Server - -Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** security policy setting. - -## Reference - -The **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting allows you to audit on the domain controller NTLM authentication in that domain. - -When you enable this policy setting on the domain controller, only authentication traffic to that domain controller will be logged. - -When you enable this audit policy, it functions in the same way as the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting, but it doesn't actually block any traffic. Therefore, you can use it effectively to understand the authentication traffic to your domain controllers and when you're ready to block that traffic, you can enable the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting and select **Deny for domain accounts to domain servers**, **Deny for domain servers**, or **Deny for domain accounts**. - -### Possible values - -- **Disable** - - The domain controller on which this policy is set won't log events for incoming NTLM traffic. - -- **Enable for domain accounts to domain servers** - - The domain controller on which this policy is set will log events for NTLM authentication sign-in attempts for accounts in the domain to domain servers when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts to domain servers**. - -- **Enable for domain accounts** - - The domain controller will log events for NTLM authentication sign-in attempts that use domain accounts when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts**. - -- **Enable for domain servers** - - The domain controller will log events for NTLM authentication requests to all servers in the domain when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain servers**. - -- **Enable all** - - The domain controller on which this policy is set will log all events for incoming NTLM traffic. - -### Best practices - -Depending on your environment and the duration of your testing, monitor the operational event log size regularly. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently. - -There are no security audit event policies that can be configured to view output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the -Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards. - -### Vulnerability - -Enabling this policy setting will reveal through logging which devices within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting doesn't prevent or mitigate any vulnerability because it is for audit purposes only. -### Countermeasure - -Restrict access to the log files when this policy setting is enabled in your production environment. - -### Potential impact - -If you don't enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md deleted file mode 100644 index 9432404d9c..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Network security Restrict NTLM Incoming NTLM traffic -description: Best practices, security considerations, and more for the security policy setting, Network Security Restrict NTLM Incoming NTLM traffic. -ms.assetid: c0eff7d3-ed59-4004-908a-2205295fefb8 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Network security: Restrict NTLM: Incoming NTLM traffic - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Incoming NTLM traffic** security policy setting. - -## Reference - -The **Network Security: Restrict NTLM: Incoming NTLM traffic** policy setting allows you to deny or allow incoming NTLM traffic from client computers, other member servers, or a domain controller. - -### Possible values - -- **Allow all** - - The server will allow all NTLM authentication requests. - -- **Deny all domain accounts** - - The server will deny NTLM authentication requests for domain sign in, return an NTLM blocked error message to the client device, and log the error, but the server will allow local account sign in. - - -- **Deny all accounts** - - The server will deny NTLM authentication requests from all incoming traffic (whether domain account sign in or local account sign in), return an NTLM blocked error message to the client device, and log the error. - -- Not defined - - This state of not being defined is the same as **Allow all**, and the server will allow all NTLM authentication requests. - -### Best practices - -If you select **Deny all domain accounts** or **Deny all accounts**, incoming NTLM traffic to the member server will be restricted. It's better to set the **Network Security: Restrict NTLM: Audit Incoming NTLM traffic** policy setting and then review the Operational log to understand what authentication attempts are made to the member servers, and then what client applications are using NTLM. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined | -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. - -There are no Security Audit Event policies that can be configured to view event output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards. - -### Vulnerability - -Malicious attacks on NTLM authentication traffic that result in a compromised server can occur only if the server handles NTLM requests. If those requests are denied, brute force attacks on NTLM are eliminated. - -### Countermeasure - -When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as Kerberos, you can select one of several options that this security policy setting offers to restrict NTLM usage. - -### Potential impact - -If you configure this policy setting, numerous NTLM authentication requests could fail within your network, which could degrade productivity. Before implementing this change through this policy setting, set **Network security: Restrict NTLM: Audit Incoming NTLM traffic** to the same option so that -you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md). - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md deleted file mode 100644 index 039bfedb88..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Network security Restrict NTLM in this domain -description: Learn about best practices, security considerations and more for the security policy setting, Network Security Restrict NTLM NTLM authentication in this domain. -ms.reviewer: -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 12/31/2017 ---- - -# Network security: Restrict NTLM: NTLM authentication in this domain - -**Applies to** -- Windows Server - -Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: NTLM authentication in this domain** security policy setting. - -## Reference - -The **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy setting doesn't affect interactive logon to this domain controller. - -### Possible values - -- **Disable** - - The domain controller will allow all NTLM pass-through authentication requests within the domain. - -- **Deny for domain accounts to domain servers** - - The domain controller will deny all NTLM authentication sign-in attempts using accounts from this domain to all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. - - NTLM can be used if the users are connecting to other domains, depending on whether any Restrict NTLM policies have been set on those domains. - -- **Deny for domain accounts** - - Only the domain controller will deny all NTLM authentication sign-in attempts from domain accounts and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. - -- **Deny for domain servers** - - The domain controller will deny NTLM authentication requests to all servers in the domain and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. Servers that aren't joined to the domain won't be affected if this policy setting is configured. - -- **Deny all** - - The domain controller will deny all NTLM pass-through authentication requests from its servers and for its accounts and return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. - -- Not defined - - The domain controller will allow all NTLM authentication requests in the domain where the policy is deployed. - -### Best practices - -If you select any of the deny options, incoming NTLM traffic to the domain will be restricted. First, set the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** policy setting, and then review the Operational log to understand what authentication attempts are made to the member servers. You can then add those member server names to a server exception list by using the [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md) policy setting. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not configured| -| Default domain controller policy | Not configured| -| Stand-alone server default settings | Not configured| -| Domain controller effective default settings | Not configured| -| Member server effective default settings | Not configured | -| Client computer effective default settings | Not configured| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. The policy is applicable to domain controllers only. - -### Auditing - -View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. - -There are no security audit event policies that can be configured to view output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards. - -### Vulnerability - -Malicious attacks on NTLM authentication traffic resulting in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated. - -### Countermeasure - -When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as the Kerberos protocol, then you can select one of several options that this security policy setting offers to restrict NTLM usage -within the domain. - -### Potential impact - -If you configure this policy setting, numerous NTLM authentication requests could fail within the domain, which could degrade productivity. Before implementing this change through this policy setting, set **Network security: Restrict NTLM: Audit NTLM authentication in this domain** to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md). - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md deleted file mode 100644 index fe152c8d75..0000000000 --- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Network security Restrict NTLM Outgoing traffic -description: Learn about best practices, security considerations and more for the policy setting, Network Security Restrict NTLM Outgoing NTLM traffic to remote servers. -ms.assetid: 63437a90-764b-4f06-aed8-a4a26cf81bd1 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 06/15/2022 ---- - -# Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting. - - -> [!NOTE] -> For more information about configuring a server to be accessed remotely, see [Remote Desktop - Allow access to your PC](/windows-server/remote/remote-desktop-services/clients/remote-desktop-allow-access). - -## Reference - -The **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** policy setting allows you to deny or audit outgoing NTLM traffic from a computer running Windows 7, Windows Server 2008, or later to any remote server running the Windows operating system. - ->**Warning:**  Modifying this policy setting may affect compatibility with client computers, services, and applications. - -### Possible values - -- **Allow all** - - The device can authenticate identities to a remote server by using NTLM authentication because no restrictions exist. - -- **Audit all** - - The device that sends the NTLM authentication request to a remote server logs an event for each request. This event allows you to identify those servers that receive NTLM authentication requests from the client device. - -- **Deny all** - - The device can't authenticate any identities to a remote server by using NTLM authentication. You can use the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting to define a list of remote servers to which client devices are allowed to use NTLM authentication while denying others. This setting will also log an event on the device that is making the authentication request. - -- Not defined - - This state of being not defined is the same as **Allow all**, and the device will allow all NTLM authentication requests when the policy is deployed. - -### Best practices - -If you select **Deny all**, the client device can't authenticate identities to a remote server by using NTLM authentication. First, select **Audit all** and then review the operational event log to understand which servers are involved in these authentication attempts. You can then add those server names to a server exception list by using the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -| Server type or GPO | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not defined| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not defined| - -## Policy management - -This section describes different features and tools available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a restart when saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -### Auditing - -View the operational event log to see if this policy is functioning as intended. Audit and block events are recorded on this computer in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. - -There are no security audit event policies that can be configured to view event output from this policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards. - -### Vulnerability - -Malicious attacks on NTLM authentication traffic that result in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated. - -### Countermeasure - -When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as Kerberos, then you can select from several options to restrict NTLM usage to servers. - -### Potential impact - -If you configure this policy setting to deny all requests, numerous NTLM authentication requests to remote servers could fail, which could degrade productivity. Before implementing this restriction through this policy setting, select **Audit all** so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) -. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md b/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md deleted file mode 100644 index a00661af55..0000000000 --- a/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Password must meet complexity requirements -description: Describes the best practices, location, values, and security considerations for the Password must meet complexity requirements security policy setting. -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 06/07/2023 ---- - - # Password must meet complexity requirements - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Password must meet complexity requirements** security policy setting. - -## Reference - -The **Passwords must meet complexity requirements** policy setting determines whether passwords must meet a series of strong-password guidelines. When enabled, this setting requires passwords to meet the following requirements: - -1. Passwords may not contain the user's samAccountName (Account Name) value or entire displayName (Full Name value). Neither of these checks is case-sensitive. - - The samAccountName is checked in its entirety only to determine whether it's part of the password. If the samAccountName is fewer than three characters long, this check is skipped. The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are shorter than three characters are ignored, and substrings of the tokens aren't checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it's ignored. So, this user couldn't have a password that included either "erin" or "hagens" as a substring anywhere in the password. - -2. The password contains characters from three of the following categories: - - - Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters). - - - Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters). - - - Base 10 digits (0 through 9). - - - Non-alphanumeric characters (special characters): - - ``` - '-!"#$%&()*,./:;?@[]^_`{|}~+<=> - ``` - - Currency symbols such as the Euro or British Pound aren't counted as special characters for this policy setting. - - - Any Unicode character that's categorized as an alphabetic character but isn't uppercase or lowercase. This group includes Unicode characters from Asian languages. - -Complexity requirements are enforced when passwords are changed or created. - -The rules that are included in the Windows Server password complexity requirements are part of `Passfilt.dll`, and they can't be directly modified. - -When enabled, the default Passfilt.dll may cause some more Help Desk calls for locked-out accounts, because users are used to passwords that contain only characters that are in the alphabet. But this policy setting is liberal enough that all users should get used to it. - -Other settings that can be included in a custom `Passfilt.dll` are the use of non-upper-row characters. To type upper-row characters, you hold the SHIFT key and press one of any of the keys on the number row of the keyboard (from 1 through 9 and 0). - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -> [!TIP] -> For the latest best practices, see [Password Guidance](https://www.microsoft.com/research/publication/password-guidance). - -Set **Passwords must meet complexity requirements** to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 159,238,157,238,528 different possibilities for a single password. This setting makes a brute force attack difficult, but still not impossible. - -The use of ALT key character combinations may greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements might result in unhappy users and an over-worked Help Desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of that range can represent standard alphanumeric characters that don't add more complexity to the password.) - -Short passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To prevent this vulnerability, passwords should contain other characters and/or meet complexity requirements. - -### Location - -`Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy` - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page. - -| Server type or Group Policy Object (GPO) | Default value | -|----------------------------------------------------|---------------| -| Default domain policy | Enabled | -| Default domain controller policy | Enabled | -| Stand-alone server default settings | Disabled | -| Domain controller effective default settings | Enabled | -| Member server effective default settings | Enabled | -| Effective GPO default settings on client computers | Disabled | - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Passwords that contain only alphanumeric characters are easy to discover with several publicly available tools. - -### Countermeasure - -Configure the **Passwords must meet complexity requirements** policy setting to _Enabled_ and advise users to use various characters in their passwords. - -When combined with a [Minimum password length](minimum-password-length.md) of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it's difficult (but possible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.) - -### Potential impact - -If the default configuration for password complexity is kept, more Help Desk calls for locked-out accounts could occur because users might not be used to passwords that contain non-alphabetical characters, or they might have problems entering passwords that contain accented characters or symbols on keyboards with different layouts. However, all users should be able to follow the complexity requirement with minimal difficulty. - -If your organization has more stringent security requirements, you can create a custom version of the `Passfilt.dll` file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper-row symbols. (Upper-row symbols are those symbols that require you to press and hold the SHIFT key and then press any of the keys on the number row of the keyboard, from 1 through 9 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password doesn't contain common dictionary words or fragments. - -The use of ALT key character combinations may greatly enhance the complexity of a password. However, such stringent password requirements might result in more Help Desk requests. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128-0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that wouldn't add more complexity to the password.) - -## Related articles - -- [Password Policy](/microsoft-365/admin/misc/password-policy-recommendations) - diff --git a/windows/security/threat-protection/security-policy-settings/password-policy.md b/windows/security/threat-protection/security-policy-settings/password-policy.md deleted file mode 100644 index c9050c5e21..0000000000 --- a/windows/security/threat-protection/security-policy-settings/password-policy.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Password Policy -description: An overview of password policies for Windows and links to information for each policy setting. -ms.assetid: aec1220d-a875-4575-9050-f02f9c54a3b6 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Password Policy - -**Applies to** -- Windows 11 -- Windows 10 - -An overview of password policies for Windows and links to information for each policy setting. - -In many operating systems, the most common method to authenticate a user's identity is to use a secret passphrase or password. A secure network environment requires all users to use strong passwords, which have at least eight characters and include a combination of letters, numbers, and symbols. These passwords help prevent the compromise of user accounts and administrative accounts by unauthorized users who use manual methods or automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a successful password attack. - -Introduced in Windows Server 2008 R2 and Windows Server 2008, Windows supports fine-grained password policies. This feature provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. For more details, see [AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770842(v=ws.10)). - -To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups. - -Fine-grained password policies include attributes for all the settings that can be defined in the default domain policy (except Kerberos settings) in addition to account lockout settings. When you specify a fine-grained password policy, you must specify all of these settings. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain must be running at least Windows Server 2008 R2 or Windows Server 2008 to use fine-grained password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly. - -You can enforce the use of strong passwords through an appropriate password policy. There are password policy settings that control the complexity and lifetime of passwords, such as the **Passwords must meet complexity requirements** policy setting. - -You can configure the password policy settings in the following location by using the Group Policy Management Console: - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy** - -This group policy is applied on the domain level. If individual groups require distinct password policies, consider using fine-grained password policies, as described above. - -The following topics provide a discussion of password policy implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible vulnerabilities of each setting), countermeasures that you can take, and the potential impact for each setting. - -## In this section - -| Topic | Description | -| - | - | -| [Enforce password history](enforce-password-history.md)| Describes the best practices, location, values, policy management, and security considerations for the **Enforce password history** security policy setting.| -| [Maximum password age](maximum-password-age.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum password age** security policy setting.| -| [Minimum password age](minimum-password-age.md) | Describes the best practices, location, values, policy management, and security considerations for the **Minimum password age** security policy setting.| -| [Minimum password length](minimum-password-length.md) | Describes the best practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting.| -| [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) | Describes the best practices, location, values, and security considerations for the **Password must meet complexity requirements** security policy setting.| -| [Store passwords using reversible encryption](store-passwords-using-reversible-encryption.md) | Describes the best practices, location, values, and security considerations for the **Store passwords using reversible encryption** security policy setting.| - -## Related topics - -- [Configure security policy settings](how-to-configure-security-policy-settings.md) - diff --git a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md b/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md deleted file mode 100644 index 5f1bb7b6cd..0000000000 --- a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Perform volume maintenance tasks -description: Describes the best practices, location, values, policy management, and security considerations for the Perform volume maintenance tasks security policy setting. -ms.assetid: b6990813-3898-43e2-8221-c9c06d893244 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Perform volume maintenance tasks - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Perform volume maintenance tasks** security policy setting. - -## Reference - -This policy setting determines which users can perform volume or disk management tasks, such as defragmenting an existing volume, creating or removing volumes, and running the Disk Cleanup tool. - -Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data. - -Constant: SeManageVolumePrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| DC Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -A user who is assigned the **Perform volume maintenance tasks** user right could delete a volume, which could result in the loss of data or a denial-of- service condition. Also, disk maintenance tasks can be used to modify data on the disk, such as user rights assignments that might lead to escalation of privileges. - -### Countermeasure - -Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right. - -### Potential impact - -None. Restricting the **Perform volume maintenance tasks** user right to the local Administrators group is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/profile-single-process.md b/windows/security/threat-protection/security-policy-settings/profile-single-process.md deleted file mode 100644 index 565b612a6f..0000000000 --- a/windows/security/threat-protection/security-policy-settings/profile-single-process.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Profile single process -description: Describes the best practices, location, values, policy management, and security considerations for the Profile single process security policy setting. -ms.assetid: c0963de4-4f5e-430e-bfcd-dfd68e66a075 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Profile single process - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Profile single process** security policy setting. - -## Reference - -This policy setting determines which users can view a sample performance of an application process. Typically, you don't need this user right to use the performance reporting tools included in the operating system. However, you do need this user right if the system’s monitor components are configured to collect data through Windows Management Instrumentation (WMI). - -Constant: SeProfileSingleProcessPrivilege - -### Possible values - -- User-defined list of accounts -- Administrators -- Not Defined - -### Best practices - -- This right shouldn't be granted to individual users. It should be granted only for trusted applications that monitor other programs. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings| Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Profile single process** user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They could also identify other users who are signed in to a computer. - -### Countermeasure - -Ensure that only the local Administrators group is assigned the **Profile single process** user right. - -### Potential impact - -If you remove the **Profile single process** user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks aren't negatively affected. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md b/windows/security/threat-protection/security-policy-settings/profile-system-performance.md deleted file mode 100644 index f0af56ab38..0000000000 --- a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Profile system performance -description: Best practices, location, values, policy management, and security considerations for the security policy setting, Profile system performance. -ms.assetid: ffabc3c5-9206-4105-94ea-84f597a54b2e -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Profile system performance - -**Applies to** -- Windows 11 -- Windows 10 - -This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the **Profile system performance** security policy setting. - -## Reference - -This security setting determines which users can use Windows performance monitoring tools to monitor the performance of system processes. - -Constant: SeSystemProfilePrivilege - -### Possible values - -- User-defined list of accounts -- Administrators -- Not defined - -### Best practices - -- Ensure that only the local Administrators group is assigned the **Profile system performance** user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this setting is Administrators and NT SERVICE\WdiServiceHost on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Depending on your version of Windows and your environment, you might need to add this user right to the Local System account or the Local Service account if you encounter access errors when you use the Administrators account. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Profile system performance** user right poses a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers might also be able to determine what processes are active on the computer so that they could identify countermeasures to avoid, such as anti-virus software or an intrusion detection system. - -### Countermeasure - -Ensure that only the local Administrators group is assigned the **Profile system performance** user right. - -### Potential impact - -None. Restricting the **Profile system performance** user right to the local Administrators group is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md deleted file mode 100644 index 55d2e7660d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: Recovery console Allow automatic administrative logon -description: Best practices, location, values, policy management, and security considerations for the policy setting, Recovery console Allow automatic administrative logon. -ms.assetid: be2498fc-48f4-43f3-ad09-74664e45e596 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Recovery console: Allow automatic administrative logon - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. - -## Reference - -This policy setting determines whether the built-in Administrator account password must be provided before access to the device is granted. If you enable this setting, the built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required. - -The Recovery Console can be useful when troubleshooting and repairing systems that can't be restarted. However, enabling this policy setting so a user can automatically sign in to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select **Recovery Console** from the **Restart** menu, and then assume full control of the server. - -### Possible values - -- Enabled - - The built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required - -- Disabled - - Automatic administrative logon isn't allowed. - -- Not defined - - Automatic administrative logon isn't allowed. - -### Best practices - -- Set **Recovery Console: Allow automatic administrative logon** to **Disabled**. This setting requires a user to enter a user name and password to access the Recovery Console account. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy| Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device - -### Policy conflicts - -None. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The Recovery Console can be useful when you must troubleshoot and repair devices that don't start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server. - -### Countermeasure - -Disable the **Recovery console: Allow automatic administrative logon** setting. - -### Potential impact - -Users must enter a user name and password to access the Recovery Console. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md deleted file mode 100644 index 10304c2de7..0000000000 --- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Recovery console Allow floppy copy and access to all drives and folders -description: Best practices, security considerations, and more for the policy setting, Recovery console Allow floppy copy and access to all drives and folders. -ms.assetid: a5b4ac0c-f33d-42b5-a866-72afa7cbd0bd -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Recovery console: Allow floppy copy and access to all drives and folders - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. - -## Reference - -This policy setting enables or disables the Recovery Console SET command, which allows you to set the following Recovery Console environment variables. - -- **AllowWildCards**. Enables wildcard support for some commands, such as the DEL command. -- **AllowAllPaths**. Allows access to all files and folders on the device. -- **AllowRemovableMedia**. Allows files to be copied to removable media, such as a floppy disk. -- **NoCopyPrompt**. Suppresses the prompt that typically displays before an existing file is overwritten. - -You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the removable media before the hard disk drive, the server will start from the removable disk. This boot causes the server's network services to be unavailable. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set **Recovery Console: Allow floppy copy and access to drives and folders** to **Disabled**. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account won't be able to copy files and folders to a floppy disk. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. - -### Policy conflicts - -None. - -### Command-line tools - -Enabling this security option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables: - -- AllowWildCards: Enable wildcard support for some commands (such as the DEL command). -- AllowAllPaths: Allow access to all files and folders on the device. -- AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk. -- NoCopyPrompt: Don't prompt when overwriting an existing file. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker who can cause the system to restart into the Recovery Console could steal sensitive data and leave no audit or access trail. - -### Countermeasure - -Disable the **Recovery console: Allow floppy copy and access to drives and folders** setting. - -### Potential impact - -Users who have started a server through the Recovery Console and logged in with the built-in Administrator account can't copy files and folders to a floppy disk. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md b/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md deleted file mode 100644 index d7f19e7b40..0000000000 --- a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Remove computer from docking station - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Remove computer from docking station security policy setting. -ms.assetid: 229a385a-a862-4973-899a-413b1b5b6c30 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Remove computer from docking station - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Remove computer from docking station** security policy setting. - -## Reference - -This security setting determines whether a user can undock a portable device from its docking station without logging on. This policy setting only affects scenarios that involve a portable computer and its docking station. - -If this user right is assigned to the user’s account (or if the user is a member of the assigned group), the user must sign in before removing the portable device from its docking station. Otherwise, as a security measure, the user won't be able to sign in after the device is removed from the docking station. If this policy isn't assigned, the user may remove the portable device from its docking station without signing in, and then have the ability to start and sign in to the device afterwards in its undocked state. - -Constant: SeUndockPrivilege - -### Possible values - -- User-defined list of accounts -- Not Defined - -### Best practices - -- Assign this user right to only those accounts that are permitted to use the portable device. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -Although this portable device scenario doesn't normally apply to servers, by default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Anyone who has the **Remove computer from docking station** user right can sign in and then remove a portable device from its docking station. If this setting isn't defined, it has the same effect as if everyone was granted this right. However, the value of implementing this countermeasure is reduced by the following factors: - -- If attackers can restart the device, they could remove it from the docking station after the BIOS starts but before the operating system starts. -- This setting doesn't affect servers because they typically aren't installed in docking stations. -- An attacker could steal the device and the docking station together. -- Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality. - -### Countermeasure - -Ensure that only the local Administrators group and the user account to which the device is allocated are assigned the **Remove computer from docking station** user right. - -### Potential impact - -By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted this user right as necessary. If your organization's users aren't members of the local Administrators groups on their portable devices, they can't remove their portable devices from their docking stations if they don't first shut down the device. Therefore, you may want to assign the **Remove computer from docking station** privilege to the local Users group for portable devices. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md b/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md deleted file mode 100644 index 139239d715..0000000000 --- a/windows/security/threat-protection/security-policy-settings/replace-a-process-level-token.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Replace a process level token -description: Describes the best practices, location, values, policy management, and security considerations for the Replace a process level token security policy setting. -ms.assetid: 5add02db-6339-489e-ba21-ccc3ccbe8745 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Replace a process level token - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Replace a process level token** security policy setting. - -## Reference - -This policy setting determines which parent processes can replace the access token that is associated with a child process. - -Specifically, the **Replace a process level token** setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler, where the user right is extended to any processes that can be managed by Task Scheduler. - -An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account that is associated with the process or thread. With this user right, every child process that runs on behalf of this user account would have its access token replaced with the process level token. - -Constant: SeAssignPrimaryTokenPrivilege - -### Possible values - -- User-defined list of accounts -- Defaults -- Not defined - -### Best practices - -- For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Network Service and Local Service on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Network Service
Local Service | -| Stand-Alone Server Default Settings | Network Service
Local Service| -| Domain Controller Effective Default Settings | Network Service
Local Service| -| Member Server Effective Default Settings | Network Service
Local Service| -| Client Computer Effective Default Settings | Network Service
Local Service| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users with the **Replace a process level token** user right can start processes as another user if they know the user’s credentials. - -### Countermeasure - -For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right. - -### Potential impact - -On most computers, restricting the **Replace a process level token** user right to the Local Service and the Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Replace a process level token** user right to additional accounts. For example, IIS requires that the Service, Network Service, and IWAM\_*<ComputerName>* accounts be explicitly granted this user right. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md deleted file mode 100644 index 83a1004c87..0000000000 --- a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Reset account lockout counter after -description: Describes the best practices, location, values, and security considerations for the Reset account lockout counter after security policy setting. -ms.assetid: d5ccf6dd-5ba7-44a9-8e0b-c478d8b1442c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 11/02/2018 ---- - -# Reset account lockout counter after - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting. - -## Reference - -The **Reset account lockout counter after** policy setting determines the number of minutes that must elapse from the time a user fails to sign in before the failed sign-in attempt counter is reset to 0. If [Account lockout threshold](account-lockout-threshold.md) is set to a number greater than zero, this reset time must be less than or equal to the value of [Account lockout duration](account-lockout-duration.md). - -The disadvantage of a high setting is that users lock themselves out for an inconveniently long period if they exceed the account lockout threshold through sign-in errors. Users may make excessive Help Desk calls. - -### Possible values - -- A user-defined number of minutes from 1 through 99,999 -- Not defined - -### Best practices - -Determine the threat level for your organization and balance that against the cost of your Help Desk support for password resets. Each organization will have specific requirements. - -[Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) recommend configuring the **Reset account lockout counter after** policy setting to 15, but as with other account lockout settings, this value is more of a guideline than a rule or best practice because there's no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout). - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout Policy** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Not defined| -| Default domain controller policy | Not defined| -| Stand-alone server default settings | Not applicable| -| Domain controller effective default settings | Not defined| -| Member server effective default settings | Not defined| -| Client computer effective default settings | Not applicable| - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users can accidentally lock themselves out of their accounts if they mistype their password multiple times. - -### Countermeasure - -[Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md) recommend configuring the **Reset account lockout counter after** policy setting to 15. - -### Potential impact - -If you don't configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to sign in to each user's account numerous times and lock out their accounts, a denial-of-service (DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to sign in after a failed sign in within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk. - -## Related topics - -- [Account Lockout Policy](account-lockout-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md b/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md deleted file mode 100644 index 85b208bd22..0000000000 --- a/windows/security/threat-protection/security-policy-settings/restore-files-and-directories.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Restore files and directories - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Restore files and directories security policy setting. -ms.assetid: c673c0fa-6f49-4edd-8c1f-c5e8513f701d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Restore files and directories - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Restore files and directories** security policy setting. - -## Reference - -This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories, and it determines which users can set valid security principals as the owner of an object. - -Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system: - -- **Traverse folder / execute file** -- **Write** - -Constant: SeRestorePrivilege - -### Possible values - -- User-defined list of accounts -- Defaults -- Not Defined - -### Best practices - -- Users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, so only assign this user right to trusted users. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default, this right is granted to the Administrators, Backup Operators, and Server Operators groups on domain controllers, and to the Administrators and Backup Operators groups on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -|Default Domain Policy | | -| Default Domain Controller Policy| Administrators
Backup Operators
Server Operators| -| Stand-Alone Server Default Settings | Administrators
Backup Operators| -| Domain Controller Effective Default Settings | Administrators
Backup Operators
Server Operators| -| Member Server Effective Default Settings | Administrators
Backup Operators| -| Client Computer Effective Default Settings | Administrators
Backup Operators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer is not required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object, which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -An attacker with the **Restore files and directories** user right could restore sensitive data to a computer and overwrite data that is more recent, which could lead to loss of important data, data corruption, or a denial-of-service condition. Attackers could overwrite executable files that are used by legitimate administrators or system services with versions that include malicious software to grant themselves elevated privileges, compromise data, or install programs that provide continued access to the device - ->**Note:**  Even if the following countermeasure is configured, an attacker could restore data to a computer in a domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media that are used to back up data. - -### Countermeasure - -Ensure that only the local Administrators group is assigned the **Restore files and directories** user right unless your organization has clearly defined roles for backup and for restore personnel. - -### Potential impact - -If you remove the **Restore files and directories** user right from the Backup Operators group and other accounts, users who aren't members of the local Administrators group can't load data backups. If restoring backups is delegated to a subset of IT staff in your organization, you should verify that this change does not negatively affect the ability of your organization's personnel to do their jobs. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/secpol-advanced-security-audit-policy-settings.md b/windows/security/threat-protection/security-policy-settings/secpol-advanced-security-audit-policy-settings.md deleted file mode 100644 index ebfd260fab..0000000000 --- a/windows/security/threat-protection/security-policy-settings/secpol-advanced-security-audit-policy-settings.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Advanced security audit policy settings in brief -description: Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate. -ms.assetid: 6BF9A642-DBC3-4101-94A3-B2316C553CE3 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Advanced security audit policy settings for Windows 10 - -**Applies to** -- Windows 11 -- Windows 10 - -Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate. - -The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as: - -- A group administrator has modified settings or data on servers that contain finance information. -- An employee within a defined group has accessed an important file. -- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access. - -You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local device or by using Group Policy. - -These Advanced Audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity. - -For more info, see [Advanced security audit policies](../auditing/advanced-security-auditing.md). diff --git a/windows/security/threat-protection/security-policy-settings/security-options.md b/windows/security/threat-protection/security-policy-settings/security-options.md deleted file mode 100644 index 2872bdad4b..0000000000 --- a/windows/security/threat-protection/security-policy-settings/security-options.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Security options -description: Introduction to the Security Options settings of the local security policies plus links to more information. -ms.reviewer: -manager: aaroncz -ms.author: vinpa -ms.localizationpriority: medium -author: vinaypamnani-msft -ms.date: 01/13/2023 -ms.topic: reference ---- - -# Security Options - -**Applies to** - -- Windows 11 -- Windows 10 - -Provides an introduction to the **Security Options** settings for local security policies and links to more information. - -The **Security Options** contain the following groupings of security policy settings that allow you to configure the behavior of the local computer. Some of these policies can be included in a Group Policy Object and distributed over your organization. - -When you edit policy settings locally on a device, you only affect the settings on only that device. If you configure the settings in a Group Policy Object (GPO), the settings apply to all devices that are subject to that GPO. - -For info about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md). - -## In this section - -| Article | Description | -| - | - | -| [Accounts: Administrator account status](accounts-administrator-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.| -| [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md) | Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.| -| [Accounts: Guest account status](accounts-guest-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.| -| [Accounts: Limit local account use of blank passwords to console logon only](accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting. | -| [Accounts: Rename administrator account](accounts-rename-administrator-account.md)| This security policy article for the IT professional describes the best practices, location, values, and security considerations for this policy setting.| -| [Accounts: Rename guest account](accounts-rename-guest-account.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.| -| [Audit: Audit the access of global system objects](audit-audit-the-access-of-global-system-objects.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting.| -| [Audit: Audit the use of Backup and Restore privilege](audit-audit-the-use-of-backup-and-restore-privilege.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting.| -| [Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings](audit-force-audit-policy-subcategory-settings-to-override.md) | Describes the best practices, location, values, and security considerations for the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** security policy setting. | -| [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md)| Describes the best practices, location, values, management practices, and security considerations for the **Audit: Shut down system immediately if unable to log security audits** security policy setting. | -| [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. | -| [DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting. | -| [Devices: Allow undock without having to log on](devices-allow-undock-without-having-to-log-on.md)| Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting.| -| [Devices: Allowed to format and eject removable media](devices-allowed-to-format-and-eject-removable-media.md) | Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting.| -| [Devices: Prevent users from installing printer drivers](devices-prevent-users-from-installing-printer-drivers.md) | Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting.| -| [Devices: Restrict CD-ROM access to locally logged-on user only](devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md) | Describes the best practices, location, values, and security considerations for the **Devices: Restrict CD-ROM access to locally logged-on user only** security policy setting. | -| [Devices: Restrict floppy access to locally logged-on user only](devices-restrict-floppy-access-to-locally-logged-on-user-only.md)| Describes the best practices, location, values, and security considerations for the **Devices: Restrict floppy access to locally logged-on user only** security policy setting. | -| [Domain controller: Allow server operators to schedule tasks](domain-controller-allow-server-operators-to-schedule-tasks.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting. | -| [Domain controller: LDAP server signing requirements](domain-controller-ldap-server-signing-requirements.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting. | -| [Domain controller: Refuse machine account password changes](domain-controller-refuse-machine-account-password-changes.md) | Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting.| -| [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) | Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt or sign secure channel data (always)** security policy setting. | -| [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt secure channel data (when possible)** security policy setting. | -| [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting.| -| [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting.| -| [Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md) |Describes the best practices, location, values, and security considerations for the **Domain member: Maximum machine account password age** security policy setting.| -|[Domain member: Require strong (Windows 2000 or later) session key](domain-member-require-strong-windows-2000-or-later-session-key.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Require strong (Windows 2000 or later) session key** security policy setting. | -| [Interactive logon: Display user information when the session is locked](interactive-logon-display-user-information-when-the-session-is-locked.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting. | -| [Interactive logon: Don't display last signed-in](interactive-logon-do-not-display-last-user-name.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Don't display last signed-in** security policy setting.| -| [Interactive logon: Don't display username at sign-in](interactive-logon-dont-display-username-at-sign-in.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display username at sign-in** security policy setting.| -| [Interactive logon: Do not require CTRL+ALT+DEL](interactive-logon-do-not-require-ctrl-alt-del.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting.| -| [Interactive logon: Machine account lockout threshold](interactive-logon-machine-account-lockout-threshold.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting.| -| [Interactive logon: Machine inactivity limit](interactive-logon-machine-inactivity-limit.md)| Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting.| -| [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Message text for users attempting to log on** security policy setting. | -| [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Message title for users attempting to log on** security policy setting. | -| [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting. | -| [Interactive logon: Prompt user to change password before expiration](interactive-logon-prompt-user-to-change-password-before-expiration.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Prompt user to change password before expiration** security policy setting. | -| [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Domain Controller authentication to unlock workstation** security policy setting. | -| [Interactive logon: Require Windows Hello for Business or smart card](interactive-logon-require-smart-card.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Windows Hello for Business or smart card** security policy setting.| -| [Interactive logon: Smart card removal behavior](interactive-logon-smart-card-removal-behavior.md) | Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.| -| [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md) | Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2. | -| [Microsoft network client: Send unencrypted password to third-party SMB servers](microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting. | -| [Microsoft network server: Amount of idle time required before suspending session](microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting. | -| [Microsoft network server: Attempt S4U2Self to obtain claim information](microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md)| Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting. | -| [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)| Describes the best practices, location, values, policy management, and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting for SMBv3 and SMBv2.| -| [Microsoft network server: Disconnect clients when logon hours expire](microsoft-network-server-disconnect-clients-when-logon-hours-expire.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting. | -| [Microsoft network server: Server SPN target name validation level](microsoft-network-server-server-spn-target-name-validation-level.md)| Describes the best practices, location, and values, policy management, and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting. | -| [Network access: Allow anonymous SID/Name translation](network-access-allow-anonymous-sidname-translation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting.| -| [Network access: Do not allow anonymous enumeration of SAM accounts](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting. | -| [Network access: Do not allow anonymous enumeration of SAM accounts and shares](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** security policy setting. | -| [Network access: Do not allow storage of passwords and credentials for network authentication](network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting. | -| [Network access: Let Everyone permissions apply to anonymous users](network-access-let-everyone-permissions-apply-to-anonymous-users.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting. | -| [Network access: Named Pipes that can be accessed anonymously](network-access-named-pipes-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting. | -| [Network access: Remotely accessible registry paths](network-access-remotely-accessible-registry-paths.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Remotely accessible registry paths** security policy setting.| -| [Network access: Remotely accessible registry paths and subpaths](network-access-remotely-accessible-registry-paths-and-subpaths.md)| Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting. | -| [Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Restrict anonymous access to Named Pipes and Shares** security policy setting. | -| [Network access: Restrict clients allowed to make remote calls to SAM](network-access-restrict-clients-allowed-to-make-remote-sam-calls.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting. | -| [Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting. | -| [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting. | -| [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md)| Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting. | -| [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md)| Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting.| -| [Network security: Allow PKU2U authentication requests to this computer to use online identities](network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md)| Describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting. | -| [Network security: Configure encryption types allowed for Kerberos Win7 only](network-security-configure-encryption-types-allowed-for-kerberos.md)| Describes the best practices, location, values, and security considerations for the **Network security: Configure encryption types allowed for Kerberos Win7 only** security policy setting. | -| [Network security: Do not store LAN Manager hash value on next password change](network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting. | -| [Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting. | -| [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: LAN Manager authentication level** security policy setting.| -| [Network security: LDAP client signing requirements](network-security-ldap-client-signing-requirements.md) | This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system. | -| [Network security: Minimum session security for NTLM SSP based (including secure RPC) clients](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting. | -| [Network security: Minimum session security for NTLM SSP based (including secure RPC) servers](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md)| Describes the best practices, location, values, policy management, and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting. | -| [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** security policy setting. | -| [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add server exceptions in this domain** security policy setting. | -| [Network security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit incoming NTLM traffic** security policy setting. | -| [Network security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** security policy setting. | -| [Network security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Incoming NTLM traffic** security policy setting. | -| [Network security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: NTLM authentication in this domain** security policy setting. | -| [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting. | -| [Recovery console: Allow automatic administrative logon](recovery-console-allow-automatic-administrative-logon.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. | -| [Recovery console: Allow floppy copy and access to all drives and folders](recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md)| Describes the best practices, location, values, policy management, and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. | -| [Shutdown: Allow system to be shut down without having to log on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. | -| [Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)| Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.| -| [System cryptography: Force strong key protection for user keys stored on the computer](system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md)| Describes the best practices, location, values, policy management, and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. | -| [System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md)| This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting. | -| [System objects: Require case insensitivity for non-Windows subsystems](system-objects-require-case-insensitivity-for-non-windows-subsystems.md)| Describes the best practices, location, values, policy management, and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting. | -| [System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)](system-objects-strengthen-default-permissions-of-internal-system-objects.md)| Describes the best practices, location, values, policy management, and security considerations for the **System objects: Strengthen default permissions of internal system objects (for example, Symbolic Links)** security policy setting. | -| [System settings: Optional subsystems](system-settings-optional-subsystems.md) | Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting.| -| [System settings: Use certificate rules on Windows executables for Software Restriction Policies](system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md)| Describes the best practices, location, values, policy management, and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting. | -| [User Account Control: Admin Approval Mode for the Built-in Administrator account](user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. | -| [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md)| Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. | -| [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting. | -| [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting. | -| [User Account Control: Detect application installations and prompt for elevation](user-account-control-detect-application-installations-and-prompt-for-elevation.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting. | -| [User Account Control: Only elevate executables that are signed and validated](user-account-control-only-elevate-executables-that-are-signed-and-validated.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting. | -| [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting. | -| [User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. | -| [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. | -| [User Account Control: Virtualize file and registry write failures to per-user locations](user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md)| Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. | - -## Related articles - -- [Security policy settings reference](security-policy-settings-reference.md) -- [Security policy settings](security-policy-settings.md) diff --git a/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md b/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md deleted file mode 100644 index a6167efac3..0000000000 --- a/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Security policy settings reference -description: This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations. -ms.assetid: ef5a4579-15a8-4507-9a43-b7ccddcb0ed1 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Security policy settings reference - -**Applies to** -- Windows 11 -- Windows 10 - -This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations. - -This reference focuses on those settings that are considered security settings. This reference examines only the settings and features in the Windows operating systems that can help organizations secure their enterprises against malicious software threats. Management features and those security features that you can't configure aren't described in this reference. - -Each policy setting described contains referential content such as a detailed explanation of the settings, best practices, default settings, differences between operating system versions, policy management considerations, and security considerations that include a discussion of vulnerability, countermeasures, and potential impact of those countermeasures. - -## In this section - -| Topic | Description | -| - | - | -| [Account Policies](account-policies.md) | An overview of account policies in Windows and provides links to policy descriptions.| -| [Audit Policy](audit-policy.md) | Provides information about basic audit policies that are available in Windows and links to information about each setting.| -| [Security Options](security-options.md) | Provides an introduction to the settings under **Security Options** of the local security policies and links to information about each setting.| -| [Advanced security audit policy settings](secpol-advanced-security-audit-policy-settings.md) | Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.| -| [User Rights Assignment](user-rights-assignment.md) | Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows.  | - - diff --git a/windows/security/threat-protection/security-policy-settings/security-policy-settings.md b/windows/security/threat-protection/security-policy-settings/security-policy-settings.md deleted file mode 100644 index 7c394d7e01..0000000000 --- a/windows/security/threat-protection/security-policy-settings/security-policy-settings.md +++ /dev/null @@ -1,410 +0,0 @@ ---- -title: Security policy settings -description: This reference topic describes the common scenarios, architecture, and processes for security settings. -ms.assetid: e7ac5204-7f6c-4708-a9f6-6af712ca43b9 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Security policy settings - -**Applies to** - -- Windows 10 -- Windows 11 - -This reference topic describes the common scenarios, architecture, and processes for security settings. - -Security policy settings are rules that administrators configure on a computer or multiple devices for protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security settings for multiple devices from any device joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients, and other resources in your organization. - -Security settings can control: - -- User authentication to a network or device. -- The resources that users are permitted to access. -- Whether to record a user's or group's actions in the event log. -- Membership in a group. - -To manage security configurations for multiple devices, you can use one of the following options: - -- Edit specific security settings in a GPO. -- Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template into a Group Policy Object. A security template is a file that represents a security configuration, and it can be imported to a GPO, applied to a local device, or used to analyze security. - -For more info about managing security configurations, see [Administer security policy settings](administer-security-policy-settings.md). - -The Security Settings extension of the Local Group Policy Editor includes the following types of security policies: - -- **Account Policies.** These policies are defined on devices; they affect how user accounts can interact with the computer or domain. Account policies include the following types of policies: - - - **Password Policy.** These policies determine settings for passwords, such as enforcement and lifetimes. Password policies are used for domain accounts. - - **Account Lockout Policy.** These policies determine the conditions and length of time that an account will be locked out of the system. Account lockout policies are used for domain or local user accounts. - - **Kerberos Policy.** These policies are used for domain user accounts; they determine Kerberos-related settings, such as ticket lifetimes and enforcement. - -- **Local Policies.** These policies apply to a computer and include the following types of policy settings: - - - **Audit Policy.** Specify security settings that control the logging of security events into the Security log on the computer, and specifies what types of security events to log (success, failure, or both). - - > [!NOTE] - > For devices running Windows 7 and later, we recommend to use the settings under Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies. - - - **User Rights Assignment.** Specify the users or groups that have sign-in rights or privileges on a device - - **Security Options.** Specify security settings for the computer, such as Administrator and Guest Account names; access to floppy disk drives and CD-ROM drives; installation of drivers; sign-in prompts; and so on. - -- **Windows Firewall with Advanced Security.** Specify settings to protect the device on your network by using a stateful firewall that allows you to determine which network traffic is permitted to pass between your device and the network. -- **Network List Manager Policies.** Specify settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices. -- **Public Key Policies.** Specify settings to control Encrypting File System, Data Protection, and BitLocker Drive Encryption in addition to certain certificate paths and services settings. -- **Software Restriction Policies.** Specify settings to identify software and to control its ability to run on your local device, organizational unit, domain, or site. -- **Application Control Policies.** Specify settings to control which users or groups can run particular applications in your organization based on unique identities of files. -- **IP Security Policies on Local Computer.** Specify settings to ensure private, secure communications over IP networks by using cryptographic security services. IPsec establishes trust and security from a source IP address to a destination IP address. -- **Advanced Audit Policy Configuration.** Specify settings that control the logging of security events into the security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over which activities to monitor as opposed to the Audit Policy settings under Local Policies. - -[!INCLUDE [windows-security-policy-settings-and-auditing](../../../../includes/licensing/windows-security-policy-settings-and-auditing.md)] - -## Policy-based security settings management - -The Security Settings extension to Group Policy provides an integrated policy-based management infrastructure to help you manage and enforce your security policies. - -You can define and apply security settings policies to users, groups, and network servers and clients through Group Policy and Active Directory Domain Services (AD DS). A group of servers with the same functionality can be created (for example, a Microsoft Web (IIS) server), and then Group Policy Objects can be used to apply common security settings to the group. If more servers are added to this group later, many of the common security settings are automatically applied, reducing deployment and administrative labor. - -### Common scenarios for using security settings policies - -Security settings policies are used to manage the following aspects of security: accounts policy, local policy, user rights assignment, registry values, file and registry Access Control Lists (ACLs), service startup modes, and more. - -As part of your security strategy, you can create GPOs with security settings policies configured specifically for the various roles in your organization, such as domain controllers, file servers, member servers, clients, and so on. - -You can create an organizational unit (OU) structure that groups devices according to their roles. Using OUs is the best method for separating specific security requirements for the different roles in your network. This approach also allows you to apply customized security templates to each class of server or computer. After creating the security templates, you create a new GPO for each of the OUs, and then import the security template (.inf file) into the new GPO. - -Importing a security template to a GPO ensures that any accounts to which the GPO is applied automatically receive the template's security settings when the Group Policy settings are refreshed. On a workstation or server, the security settings are refreshed at regular intervals (with a random offset of at most 30 minutes), and, on a domain controller, this process occurs every few minutes if changes have occurred in any of the GPO settings that apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred. - -> [!NOTE] -> These refresh settings vary between versions of the operating system and can be configured. - -By using Group Policy−based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update many servers with any other changes required in the future. - -### Dependencies on other operating system technologies - -For devices that are members of a Windows Server 2008 or later domain, security settings policies depend on the following technologies: - -- **Active Directory Domain Services (AD DS)** - - The Windows-based directory service, AD DS, stores information about objects on a network and makes this information available to administrators and users. By using AD DS, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single sign in. - -- **Group Policy** - - The infrastructure within AD DS that enables directory-based configuration management of user and computer settings on devices running Windows Server. By using Group Policy, you can define configurations for groups of users and computers, including policy settings, registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance, and security. - -- **Domain Name System (DNS)** - - A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This service allows users, computers, and applications to query DNS to specify remote systems by fully qualified domain names rather than by IP addresses. - -- **Winlogon** - - A part of the Windows operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a credential provider, and any number of network providers. - -- **Setup** - - Security configuration interacts with the operating system setup process during a clean installation or upgrade from earlier versions of Windows Server. - -- **Security Accounts Manager (SAM)** - - A Windows service used during the sign-in process. SAM maintains user account information, including groups to which a user belongs. - -- **Local Security Authority (LSA)** - - A protected subsystem that authenticates and signs in users to the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system. - -- **Windows Management Instrumentation (WMI)** - - A feature of the Microsoft Windows operating system, WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI provides access to information about objects in a managed environment. Through WMI and the WMI application programming interface (API), applications can query for and make changes to static information in the Common Information Model (CIM) repository and dynamic information maintained by the various types of providers. - -- **Resultant Set of Policy (RSoP)** - - An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. These public methods allow administrators to easily determine the combination of policy settings that apply to, or will apply to, a user or device. - -- **Service Control Manager (SCM)** - - Used for configuration of service startup modes and security. - -- **Registry** - - Used for configuration of registry values and security. - -- **File system** - - Used for configuration of security. - -- **File system conversions** - - Security is set when an administrator converts a file system from FAT to NTFS. - -- **Microsoft Management Console (MMC)** - - The user interface for the Security Settings tool is an extension of the Local Group Policy Editor MMC snap-in. - -### Security settings policies and Group Policy - -The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tool set. The following components are associated with Security Settings: a configuration engine; an analysis engine; a template and database interface layer; setup integration logic; and the secedit.exe command-line tool. The security configuration engine is responsible for handling security configuration editor-related security requests for the system on which it runs. The analysis engine analyzes system security for a given configuration and saves the result. The template and database interface layer handles reading and writing requests from and to the template or database (for internal storage). The Security Settings extension of the Local Group Policy Editor handles Group Policy from a domain-based or local device. The security configuration logic integrates with setup and manages system security for a clean installation or upgrade to a more recent Windows operating system. Security information is stored in templates (.inf files) or in the Secedit.sdb database. - -The following diagram shows Security Settings and related features. - -#### Security Settings Policies and Related Features - -![components related to security policies.](images/secpol-components.gif) - -- **Scesrv.dll** - - Provides the core security engine functionality. - -- **Scecli.dll** - - Provides the client-side interfaces to the security configuration engine and provides data to Resultant Set of Policy (RSoP). - -- **Wsecedit.dll** - - The Security Settings extension of Local Group Policy Editor. scecli.dll is loaded into wsecedit.dll to support the Security Settings user interface. - -- **Gpedit.dll** - - The Local Group Policy Editor MMC snap-in. - -## Security Settings extension architecture - -The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tools, as shown in the following diagram. - -**Security Settings Architecture** - -![architecture of security policy settings.](images/secpol-architecture.gif) - -The security settings configuration and analysis tools include a security configuration engine, which provides local computer (non-domain member) and Group Policy−based configuration and analysis of security settings policies. The security configuration engine also supports the creation of security policy files. The primary features of the security configuration engine are scecli.dll and scesrv.dll. - -The following list describes these primary features of the security configuration engine and other Security Settings−related features. - -- **scesrv.dll** - - This .dll file is hosted in services.exe and runs under local system context. scesrv.dll provides core Security Configuration Manager functionality, such as import, configure, analyze, and policy propagation. - - Scesrv.dll performs configuration and analysis of various security-related system parameters by calling corresponding system APIs, including LSA, SAM, and the registry. - - Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over LRPC (Windows XP) and fails the call if it isn't. - - Communication between parts of the Security Settings extension occurs by using the following methods: - - - Component Object Model (COM) calls - - Local Remote Procedure Call (LRPC) - - Lightweight Directory Access Protocol (LDAP) - - Active Directory Service Interfaces (ADSI) - - Server Message Block (SMB) - - Win32 APIs - - Windows Management Instrumentation (WMI) calls - - On domain controllers, scesrv.dll receives notifications of changes made to SAM and the LSA that need to be synchronized across domain controllers. Scesrv.dll incorporates those changes into the Default Domain Controller Policy GPO by using in-process scecli.dll template modification APIs. - Scesrv.dll also performs configuration and analysis operations. - -- **Scecli.dll** - - This Scecli.dll is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC snap-ins. It's used by Setup to configure default system security and security of files, registry keys, and services installed by the Setup API .inf files. - - The command-line version of the security configuration and analysis user interfaces, secedit.exe, uses scecli.dll. - - Scecli.dll implements the client-side extension for Group Policy. - - Scesrv.dll uses scecli.dll to download applicable Group Policy files from SYSVOL in order to apply Group Policy security settings to the local device. - - Scecli.dll logs application of security policy into WMI (RSoP). - - Scesrv.dll policy filter uses scecli.dll to update Default Domain Controller Policy GPO when changes are made to SAM and LSA. - -- **Wsecedit.dll** - - The Security Settings extension of the Group Policy Object Editor snap-in. You use this tool to configure security settings in a Group Policy Object for a site, domain, or organizational unit. You can also use Security Settings to import security templates to a GPO. - -- **Secedit.sdb** - - This Secedit.sdb is a permanent system database used for policy propagation including a table of persistent settings for rollback purposes. - -- **User databases** - - A user database is any database other than the system database created by administrators for the purposes of configuration or analysis of security. - -- **.Inf Templates** - - These templates are text files that contain declarative security settings. They're loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they're downloaded (by using file copy) and merged into the system database during policy propagation. - -## Security settings policy processes and interactions - -For a domain-joined device, where Group Policy is administered, security settings are processed in conjunction with Group Policy. Not all settings are configurable. - -### Group Policy processing - -When a computer starts and a user signs in, computer policy and user policy are applied according to the following sequence: - -1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start. -1. An ordered list of Group Policy Objects is obtained for the device. The list might depend on these factors: - - - Whether the device is part of a domain and, therefore, subject to Group Policy through Active Directory. - - The location of the device in Active Directory. - - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects hasn't changed, no processing is done. - -1. Computer policy is applied. These settings are the ones under Computer Configuration from the gathered list. This process is a synchronous one by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed. -1. Startup scripts run. These scripts are hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior. -1. The user presses CTRL+ALT+DEL to sign in. -1. After the user is validated, the user profile loads; it's governed by the policy settings that are in effect. -1. An ordered list of Group Policy Objects is obtained for the user. The list might depend on these factors: - - - Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory. - - Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting. - - The location of the user in Active Directory. - - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects hasn't changed, no processing is done. - -1. User policy is applied. These settings are the ones under User Configuration from the gathered list. These settings are synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed. -1. Logon scripts run. Group Policy−based logon scripts are hidden and asynchronous by default. The user object script runs last. -1. The operating system user interface that is prescribed by Group Policy appears. - -### Group Policy Objects storage - -A Group Policy Object (GPO) is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at the domain level. The policy setting information of a GPO is stored in the following two locations: - -- **Group Policy containers in Active Directory.** - - The Group Policy container is an Active Directory container that contains GPO properties, such as version information, GPO status, plus a list of other component settings. - -- **Group Policy templates in a domain's system volume folder (SYSVOL).** - - The Group Policy template is a file system folder that includes policy data specified by .admx files, security settings, script files, and information about applications that are available for installation. The Group Policy template is located in the SYSVOL folder in the \\\Policies subfolder. - -The **GROUP\_POLICY\_OBJECT** structure provides information about a GPO in a GPO list, including the version number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a string that specifies the path to the file system portion of the GPO. - -### Group Policy processing order - -Group Policy settings are processed in the following order: - -1. **Local Group Policy Object.** - - Each device running a Windows operating system beginning with Windows XP has exactly one Group Policy Object that is stored locally. - -1. **Site.** - - Any Group Policy Objects that have been linked to the site are processed next. Processing is synchronous and in an order that you specify. - -1. **Domain.** - - Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you specify. - -1. **Organizational units.** - - Group Policy Objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy Objects that are linked to its child organizational unit, and so on. Finally, the Group Policy Objects that are linked to the organizational unit that contains the user or device are processed. - -At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy Objects can be linked. If several Group Policy Objects are linked to an organizational unit, their processing is synchronous and in an order that you specify. - -This order means that the local Group Policy Object is processed first, and Group Policy Objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy Objects. - -This order is the default processing order and administrators can specify exceptions to this order. A Group Policy Object that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to **Enforced** with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as **Block Inheritance**. Group Policy Object links that are set to **Enforced** are always applied, however, and they can't be blocked. For more information, see [Group Policy Basics – Part 2: Understanding Which GPOs to Apply](/archive/blogs/musings_of_a_technical_tam/group-policy-basics-part-2-understanding-which-gpos-to-apply). - -### Security settings policy processing - -In the context of Group Policy processing, security settings policy is processed in the following order. - -1. During Group Policy processing, the Group Policy engine determines which security settings policies to apply. -1. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension. -1. The Security Settings extension downloads the policy from the appropriate location such as a specific domain controller. -1. The Security Settings extension merges all security settings policies according to precedence rules. The processing is according to the Group Policy processing order of local, site, domain, and organizational unit (OU), as described earlier in the "Group Policy processing order" section. If multiple GPOs are in effect for a given device and there are no conflicting policies, then the policies are cumulative and are merged. - - This example uses the Active Directory structure shown in the following figure. A given computer is a member of OU2, to which the **GroupMembershipPolGPO** GPO is linked. This computer is also subject to the **UserRightsPolGPO** GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting policies exist so the device receives all of the policies contained in both the **UserRightsPolGPO** and the **GroupMembershipPolGPO** GPOs. - - **Multiple GPOs and Merging of Security Policy** - - ![multiple gpos and merging of security policy.](images/secpol-multigpomerge.gif) - -1. The resultant security policies are stored in secedit.sdb, the security settings database. The security engine gets the security template files and imports them to secedit.sdb. -1. The security settings policies are applied to devices. -The following figure illustrates the security settings policy processing. - -**Security Settings Policy Processing** - -![process and interactions of security policy settings.](images/secpol-processes.gif) - -### Merging of security policies on domain controllers - -Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This merging is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged: - -- Network Security: Force sign out when sign-in hours expire -- Accounts: Administrator account status -- Accounts: Guest account status -- Accounts: Rename administrator account -- Accounts: Rename guest account - -Another mechanism exists that allows security policy changes made by administrators by using net accounts to be merged into the Default Domain Policy GPO. User rights changes that are made by using Local Security Authority (LSA) APIs are filtered into the Default Domain Controllers Policy GPO. - -### Special considerations for domain controllers - -If an application is installed on a primary domain controller (PDC) with operations master role (also known as flexible single master operations or FSMO) and the application makes changes to user rights or password policy, these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll receives a notification of any changes made to the security account manager (SAM) and LSA that need to be synchronized across domain controllers and then incorporates the changes into the Default Domain Controller Policy GPO by using scecli.dll template modification APIs. - -### When security settings are applied - -After you've edited the security settings policies, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object in the following instances: - -- When a device is restarted. -- Every 90 minutes on a workstation or server and every 5 minutes on a domain controller. This refresh interval is configurable. -- By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO hasn't changed. - -### Persistence of security settings policy - -Security settings can persist even if a setting is no longer defined in the policy that originally applied it. - -Security settings might persist in the following cases: - -- The setting hasn't been previously defined for the device. -- The setting is for a registry security object. -- The settings are for a file system security object. - -All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value doesn't exist in the database, then the setting doesn't revert to anything and remains defined as is. -This behavior is sometimes referred to as "tattooing". - -Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values. - -### Permissions required for policy to apply - -Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy Object apply to users or groups, and computers. - -### Filtering security policy - -By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or won't have a Group Policy Object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU. - -> [!NOTE] -> Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it. - -### Migration of GPOs containing security settings - -In some situations, you might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings. - -Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs isn't as simple as taking a folder and copying it from one device to another. - -The following security policies can contain security principals and might require some more work to successfully move them from one domain to another. - -- User rights assignment -- Restricted groups -- Services -- File system -- Registry -- The GPO DACL, if you choose to preserve it during a copy operation - -To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When there's a migration of a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs. - -## In this section - -| Topic | Description | -| - | - | -| [Administer security policy settings](administer-security-policy-settings.md) | This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization.| -| [Configure security policy settings](how-to-configure-security-policy-settings.md) | Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.| -| [Security policy settings reference](security-policy-settings-reference.md) | This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.| diff --git a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md b/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md deleted file mode 100644 index 24628a2de8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Shut down the system - security policy setting -description: Describes the best practices, location, values, policy management, and security considerations for the Shut down the system security policy setting. -ms.assetid: c8e8f890-153a-401e-a957-ba6a130304bf -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Shut down the system - security policy setting - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Shut down the system** security policy setting. - -## Reference - -This security setting determines if a user who is logged on locally to a device can shut down Windows. - -Shutting down domain controllers makes them unable to do things like process sign-in requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles, which are also known as flexible single master operations or FSMO roles, can disable key domain functionality. For example, processing sign-in requests for new passwords, which are done by the primary domain controller (PDC) emulator master. - -The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancel a shutdown. - -Constant: SeShutdownPrivilege - -### Possible values - -- A user-defined list of accounts -- Defaults -- Not defined - -### Best practices - -1. Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers. And that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks won't be negatively affected. -2. The ability to shut down domain controllers should be limited to a few trusted administrators. Even though a system shutdown requires the ability to sign in to the server, you should be careful about the accounts and groups that you allow to shut down a domain controller. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators, Backup Operators, Server Operators, and Print Operators on domain controllers, and Administrators and Backup Operators on stand-alone servers. - -The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Administrators
Backup Operators
Server Operators
Print Operators| -| Stand-Alone Server Default Settings | Administrators
Backup Operators| -| Domain Controller Effective Default Settings | Administrators
Backup Operators
Server Operators
Print Operators| -| Member Server Effective Default Settings | Administrators
Backup Operators| -| Client Computer Effective Default Settings | Administrators
Backup Operators
Users| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the computer isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -This user right doesn't have the same effect as **Force shutdown from a remote system**. For more information, see [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md). - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The ability to shut down domain controllers should be limited to a few trusted administrators. Although the **Shut down the system** user right requires the ability to sign in to the server, you should be careful about which accounts and groups you allow to shut down a domain controller. - -When a domain controller is shut down, it can't process sign-in requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that have operations master roles, you can disable key domain functionality, such as processing sign-in requests for new passwords, which are performed by the PDC master. - -For other server roles, especially roles where non-administrators have rights to sign in to the server, such as RD Session Host servers, it's critical that this user right be removed from users who don't have a legitimate reason to restart the servers. - -### Countermeasure - -Make sure that only the Administrators and Backup Operators groups are assigned the **Shut down the system** user right on member servers. And make sure that only the Administrators group is assigned the user right on domain controllers. - -### Potential impact - -The impact of removing these default groups from the **Shut down the system** user right could limit the delegated abilities of assigned roles in your environment. Confirm that delegated activities aren't adversely affected. - -## Related articles - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md b/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md deleted file mode 100644 index 86b9b4dfd8..0000000000 --- a/windows/security/threat-protection/security-policy-settings/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Shutdown Allow system to be shut down without having to log on -description: Best practices, security considerations, and more for the security policy setting Shutdown Allow system to be shut down without having to log on. -ms.assetid: f3964767-5377-4416-8eb3-e14d553a7315 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Shutdown: Allow system to be shut down without having to log on - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. - -## Reference - -This policy setting determines whether you can shut down a device without having to sign in to Windows. When you enable it, the **Shut Down** option is available on the sign-in screen in Windows. If you disable this setting, the **Shut Down** option is removed from the screen. To use the option, the user must sign in on the device successfully and have the **Shut down the system** user right. - -Users who access the console locally can shut down the system. Attackers or misguided users can connect to the server by using Remote Desktop Services, and then shut it down or restart it without having to identify themselves. A malicious user might also cause a temporary denial-of-service -condition from a local console by restarting or shutting down the server. - -### Possible values - -- Enabled - - The shutdown command is available on the sign-in screen. - -- Disabled - - The shut down option is removed from the sign-in screen. Users must have the **Shut down the system** user right to do a shutdown. - -- Not defined - -### Best practices - -1. On servers, set this policy to **Disabled**. You must sign in to servers to shut down or restart them. -2. On client devices, set this policy to **Enabled**. Define the list of users who have the right to shut them down or restart them with the User Rights Assignment policy **Shut down the system**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. - -### Group Policy - -For info about the User Rights Assignment policy, **Shut down the system**, see [Shut down the system](shut-down-the-system.md). - -## Security considerations - -This section describes: -- How an attacker might exploit a feature or its configuration. -- How to implement the countermeasure. -- Possible negative consequences of countermeasure implementation. - -### Vulnerability - -Users who can access the console locally could shut down the device - -Attackers who have access to the local console could restart the server, which would cause a temporary DoS condition. Attackers could also shut down the server and leave all of its applications and services unavailable. - -### Countermeasure - -Disable the **Shutdown: Allow system to be shut down without having to log on** setting. - -### Potential impact - -You must sign in on servers to shut them down or restart them. - -## Related articles - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md b/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md deleted file mode 100644 index da640b385d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Shutdown Clear virtual memory pagefile -description: Describes the best practices, location, values, policy management and security considerations for the Shutdown Clear virtual memory pagefile security policy setting. -ms.assetid: 31400078-6c56-4891-a6df-6dfb403c4bc9 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 08/01/2017 ---- - -# Shutdown: Clear virtual memory pagefile - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting. - -## Reference - -This policy setting determines whether the virtual memory paging file is cleared when the device is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they aren't used. On a running device, this paging file is opened exclusively by the operating system, and it's well protected. However, devices that are configured to allow other operating systems to start should verify that the system paging file is cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file isn't available to an unauthorized user who manages to directly access the paging file after shutdown. - -Important information that is kept in real memory might be written periodically to the paging file. This periodical write-operation helps devices handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This process is a time-consuming one, but it can expose data that is cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by unplugging the server from its power source. - -### Possible values - -- Enabled - - The system paging file is cleared when the system shuts down normally. Also, this policy setting forces the computer to clear the hibernation file (hiberfil.sys) when hibernation is disabled on a portable device. - -- Disabled -- Not defined - -### Best practices - -- Set this policy to **Enabled**. This policy setting causes Windows to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Important information that is kept in real memory may be written periodically to the paging file to help Windows handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the paging file. The attacker could move the system volume into a different device and then analyze the contents of the paging file. Although this process is time consuming, it could expose data that is cached from random access memory (RAM) to the paging file. - ->**Caution:**  An attacker who has physical access to the device could bypass this countermeasure by unplugging the computer from its power source. - -### Countermeasure - -Enable the **Shutdown: Clear virtual memory page file** setting. This configuration causes the operating system to clear the paging file when the device is shut down. The amount of time that is required to complete this process depends on the size of the page file. Because the process overwrites the storage area that is used by the page file several times, it could be several minutes before the device completely shuts down. - -### Potential impact - -It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more than 30 minutes. For some organizations, this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md b/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md deleted file mode 100644 index 30ba31a152..0000000000 --- a/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Store passwords using reversible encryption -description: Describes the best practices, location, values, and security considerations for the Store passwords using reversible encryption security policy setting. -ms.assetid: 57f958c2-f1e9-48bf-871b-0a9b3299e238 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Store passwords using reversible encryption - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **Store passwords using reversible encryption** security policy setting. - -## Reference - -The **Store password using reversible encryption** policy setting provides support for applications that use protocols that require the user's password for authentication. Storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then sign in to network resources by using the compromised account. For this reason, never enable **Store password using reversible encryption** for all users in the domain unless application requirements outweigh the need to protect password information. - -If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used by remote access and network connections. Digest Authentication in Internet -Information Services (IIS) also requires that you enable this policy setting. - -### Possible values -- Enabled -- Disabled -- Not defined - -### Best practices - -Set the value for **Store password using reversible encryption** to Disabled. If you use CHAP through remote access or IAS, or Digest Authentication in IIS, you must set this value to **Enabled**. This setting presents a security risk when you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate user account object in Active Directory Users and Computers. - ->**Note:**  Do not enable this policy setting unless business requirements outweigh the need to protect password information. - -### Location - -**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\** - -### Default values - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or Group Policy Object (GPO) | Default value | -| - | - | -| Default domain policy| Disabled| -| Default domain controller policy| Disabled| -| Stand-alone server default settings | Disabled| -| Domain controller effective default settings | Disabled| -| Member server effective default settings | Disabled| -| Effective GPO default settings on client computers | Disabled| - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Enabling this policy setting allows the operating system to store passwords in a format that can weaken your overall security. - -### Countermeasure - -Disable the **Store password using reversible encryption** policy setting. - ->[!Note] -> When policy settings are disabled, only new passwords will be stored using one-way encryption by default. Existing passwords will be stored using reversible encryption until they are changed. - -### Potential impact - -If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure this policy setting to Enabled. This setting presents a security risk when you apply the setting through Group Policy on a user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users and Computers. - -## Related topics - -- [Password Policy](password-policy.md) diff --git a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md b/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md deleted file mode 100644 index b5cbe5f54e..0000000000 --- a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Synchronize directory service data -description: Describes the best practices, location, values, policy management, and security considerations for the Synchronize directory service data security policy setting. -ms.assetid: 97b0aaa4-674f-40f4-8974-b4bfb12c232c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Synchronize directory service data - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Synchronize directory service data** security policy setting. - -## Reference - -This policy setting determines which users and groups have authority to synchronize all directory service data, regardless of the protection for objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services. Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. - -Constant: SeSyncAgentPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- Ensure that no accounts are assigned the **Synchronize directory service data** user right. Only domain controllers need this privilege, which they inherently have. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting isn't defined on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| Domain Controller Effective Default Settings | Enabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The **Synchronize directory service data** user right affects domain controllers (only domain controllers should be able to synchronize directory service data). Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. Attackers who have this user right can view all information that is stored within the directory. They could then use some of that information to facilitate more attacks or expose sensitive data, such as direct telephone numbers or physical addresses. - -### Countermeasure - -Ensure that no accounts are assigned the **Synchronize directory service data** user right. - -### Potential impact - -None. Not defined is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md deleted file mode 100644 index b72384f5df..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: System cryptography Force strong key protection for user keys stored on the computer -description: Best practices, security considerations, and more for the policy setting, System cryptography Force strong key protection for user keys stored on the computer. -ms.assetid: 8cbff267-881e-4bf6-920d-b583a5ff7de0 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# System cryptography: Force strong key protection for user keys stored on the computer - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. - -## Reference - -This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password. - -Configuring this policy setting so that users must provide a password every time they use a key (in addition to their domain password) makes it more difficult for a malicious user to access locally stored user keys, even if the attacker takes control of the user's device and determines their sign-in password. - -### Possible values - -- **User input is not required when new keys are stored and used** -- **User is prompted when the key is first used** -- **User must enter a password each time they use a key** -- Not defined - -### Best practices - -- Set this policy to **User must enter a password each time they use a key**. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they'll be forced to enter the password for that certificate every time they send a signed email message. For some organizations, the overhead that is caused by using this value might be too high, but they should set the value at a minimum to **User is prompted when the key is first used**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Not defined| -| DC Effective Default Settings | Not defined| -| Member Server Effective Default Settings | Not defined| -| Client Computer Effective Default Settings| Not defined| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -If a user's account is compromised or the user's device is inadvertently left unsecured, the malicious user can use the keys that are stored for the user to access protected resources. - -### Countermeasure - -Configure the **System cryptography: Force strong key protection for user keys stored on the computer** setting to **User must enter a password each time they use a key** so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the sign-in password. - -### Potential impact - -Users must type their password every time they access a key that is stored on their device. For example, if users use an S/MIME certificate to digitally sign their email, they're forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this setting should be set to **User is prompted when the key is first used**. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md deleted file mode 100644 index 2c4c5679ce..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: System cryptography Use FIPS compliant algorithms for encryption, hashing, and signing -description: Best practices, security considerations, and more for the policy setting System cryptography Use FIPS compliant algorithms for encryption, hashing, and signing -ms.assetid: 83988865-dc0f-45eb-90d1-ee33495eb045 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 11/16/2018 ---- - -# System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing - -**Applies to** -- Windows 11 -- Windows 10 - -This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. - -## Reference - -The Federal Information Processing Standard (FIPS) 140 is a security implementation that is designed for certifying cryptographic software. Windows implements these certified algorithms to meet the requirements and standards for cryptographic modules for use by departments and agencies of the -United States federal government. - -**TLS/SSL** - -This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the -Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements. - -**Encrypting File System (EFS)** - -For the EFS service, this policy setting supports the 3DES and Advanced Encryption Standard (AES) encryption algorithms for encrypting file data supported by the NTFS file system. To encrypt file data, by default EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003, Windows Vista, and later, and it uses a DESX algorithm in Windows XP. - -**Remote Desktop Services (RDS)** - -If you're using Remote Desktop Services, this policy setting should only be enabled if the 3DES encryption algorithm is supported. - -**BitLocker** - -For BitLocker, this policy setting needs to be enabled before any encryption key is generated. -Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the creation or use of recovery passwords on these systems, so recovery keys should be used instead. -Additionally, if a data drive is password-protected, it can be accessed by a FIPS-compliant computer after the password is supplied, but the drive will be read-only. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -We recommend that customers hoping to comply with FIPS 140-2 research the configuration settings of applications and protocols they may be using to ensure their solutions can be configured to utilize the FIPS 140-2 validated cryptography provided by Windows when it's operating in FIPS 140-2 approved mode. - -For a complete list of Microsoft-recommended configuration settings, see [Windows security baselines](../../operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.md). For more information about Windows and FIPS 140-2, see [FIPS 140 Validation](../fips-140-validation.md). - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -### Operating system version differences - -When this setting is enabled, the Encrypting File System (EFS) service supports only the Triple DES encryption algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX. - -When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to the following versions: - -| Operating systems | Applicability | -| - | - | -| Windows 10, Windows 8.1, and Windows Server 2012 R2| When created on these operating systems, the recovery password can't be used on other systems listed in this table.| -| Windows Server 2012 and Windows 8 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.| -| Windows Server 2008 R2 and Windows 7 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.| -| Windows Server 2008 and Windows Vista | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -You can enable this policy setting to ensure that the device uses the most powerful algorithms that are available for digital encryption, hashing, and signing. Use of these algorithms minimize the risk of compromise of digitally encrypted or signed data by an unauthorized user. - -### Countermeasure - -Enable the **System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing** setting. - -### Potential impact - -Client devices that have this policy setting enabled can't communicate through digitally encrypted or signed protocols with servers that don't support these algorithms. Network clients that don't support these algorithms can't use servers that require them for network communications. For example, many Apache-based Web servers aren't configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool -uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices aren't configured to use the same encryption algorithms. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md deleted file mode 100644 index 1f8e7eadab..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: System objects Require case insensitivity for non-Windows subsystems -description: Best practices, security considerations and more for the security policy setting, System objects Require case insensitivity for non-Windows subsystems. -ms.assetid: 340d6769-8f33-4067-8470-1458978d1522 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# System objects: Require case insensitivity for non-Windows subsystems - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting. - -## Reference - -This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem isn't case sensitive; however, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting doesn't allow the Win32 subsystem to become case sensitive. - -Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting isn't enforced, it's possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That convention might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available. - -### Possible values - -- Enabled - - Case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. - -- Disabled - - Won't allow the Win32 subsystem to become case sensitive. - -- Not defined - -### Best practices - -- Set this policy to **Enabled**. All subsystems will be forced to observe case insensitivity. However, this insensitivity might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive operating system. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Because Windows is case insensitive but the POSIX subsystem supports case sensitivity, failure to enable this policy setting makes it possible for a user of that subsystem to create a file with the same name as another file but with a different mix of uppercase and lowercase letters. Such a situation could potentially confuse users when they try to access such files from normal Win32 tools because only one of the files is available. - -### Countermeasure - -Enable the **System objects: Require case insensitivity for non-Windows subsystems** setting. - -### Potential impact - -All subsystems are forced to observe case insensitivity. This configuration may confuse users who are familiar with any UNIX-based operating systems that are case sensitive. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md b/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md deleted file mode 100644 index 2045194c25..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: System objects Strengthen default permissions of internal system objects (for example, Symbolic Links) -description: Best practices and more for the security policy setting, System objects Strengthen default permissions of internal system objects (for example, Symbolic Links). -ms.assetid: 3a592097-9cf5-4fd0-a504-7cbfab050bb6 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# System objects: Strengthen default permissions of internal system objects (for example, Symbolic Links) - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)** security policy setting. - -## Reference - -This policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. The processes use this list to locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who aren't administrators to read, but not to modify, shared objects that they didn't create. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- It's advisable to set this policy to **Enabled**. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\ Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled | -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this setting is disabled, it's possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten. Enabling **System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)** prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they didn't create. - -### Countermeasure - -Enable the **System objects: Strengthen default permissions of global system objects (for example, Symbolic Links)** setting. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md deleted file mode 100644 index b33abc4d19..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: System settings Optional subsystems -description: Describes the best practices, location, values, policy management, and security considerations for the System settings Optional subsystems security policy setting. -ms.assetid: 5cb6519a-4f84-4b45-8072-e2aa8a72fb78 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# System settings: Optional subsystems - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting. - -## Reference - -This policy setting determines which subsystems support your applications. You can use this security setting to specify as many subsystems as your environment demands. - -The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a user starts a process and then signs out, the next user who signs in to the system might access the process that the previous user started. This pattern is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything that the second user does using that process is performed with the user rights of the first user. This privileges rollover makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics. - -### Possible values - -- User-defined list of subsystems -- Not defined - -### Best practices - -- Set this policy setting to a null value. The default value is **POSIX**, so applications that rely on the POSIX subsystem will no longer run. For example, Microsoft Services for UNIX 3.0 installs an updated version of the POSIX subsystem. Reset this policy setting in Group Policy for any servers that use Services for UNIX 3.0. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | POSIX| -| DC Effective Default Settings | POSIX| -| Member Server Effective Default Settings| POSIX| -| Client Computer Effective Default Settings | POSIX| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem. - -The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across sign-ins. If a user starts a process and then signs out, there's a potential that the next user who signs in to the computer could access the previous user's process. This accessibility would allow the second user to take actions on the process by using the privileges of the first user. - -### Countermeasure - -Configure the **System settings: Optional subsystems setting** to a null value. The default value is POSIX. - -### Potential impact - -Applications that rely on the POSIX subsystem no longer operate. For example, Microsoft Services for UNIX (SFU) installs an updated version of the POSIX subsystem that is required, so you must reconfigure this setting in Group Policy for any servers that use SFU. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md b/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md deleted file mode 100644 index 61df619542..0000000000 --- a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: System settings Use certificate rules on Windows executables for Software Restriction Policies -description: Best practices and more for the security policy setting, System settings Use certificate rules on Windows executables for Software Restriction Policies. -ms.assetid: 2380d93b-b553-4e56-a0c0-d1ef740d089c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# System settings: Use certificate rules on Windows executables for Software Restriction Policies - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting. - -## Reference - -This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .exe file name extension. This security setting enables or disables certificate rules (which are a type of software restriction policy). With a software restriction policy, you can create a certificate rule that allows or disallows Microsoft Authenticode®-signed software to run, based on the digital certificate that is associated with the software. For certificate rules to work in software restriction policies, you must enable this security setting. - -### Possible values - -- Enabled -- Disabled -- Not defined - -### Best practices - -- Set this policy to **Enabled**. Enabling certificate rules results in software restriction policies checking a certificate revocation list (CRL) to make sure that the software's certificate and signature are valid. When you start signed programs, this setting can decrease system performance. -You can disable CRLs by editing the software restriction policies in the desired GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled | -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Without the use of software restriction policies, users and device might be exposed to unauthorized software that could include malware. - -### Countermeasure - -Enable the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** setting. - -### Potential impact - -If you enable certificate rules, software restriction policies check a certificate revocation list (CRL) to verify that the software's certificate and signature are valid. This checking process may negatively affect performance when signed programs start. To disable this feature, you can edit the software restriction policies in the appropriate GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes. - -## Related topics - -- [Security Options](security-options.md) diff --git a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md b/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md deleted file mode 100644 index 1563e3d995..0000000000 --- a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Take ownership of files or other objects -description: Describes the best practices, location, values, policy management, and security considerations for the Take ownership of files or other objects security policy setting. -ms.assetid: cb8595d1-74cc-4176-bb15-d97663eebb2d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# Take ownership of files or other objects - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **Take ownership of files or other objects** security policy setting. - -## Reference - -This policy setting determines which users can take ownership of any securable object in the device, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads. - -Every object has an owner, whether the object resides in an NTFS volume or Active Directory database. The owner controls how permissions are set on the object and to whom permissions are granted. - -By default, the owner is the person who or the process that created the object. Owners can always change permissions to objects, even when they're denied all access to the object. - -Constant: SeTakeOwnershipPrivilege - -### Possible values - -- User-defined list of accounts -- Not defined - -### Best practices - -- Assigning this user right can be a security risk. Because owners of objects have full control of them, only assign this user right to trusted users. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment - -### Default values - -By default this setting is Administrators on domain controllers and on stand-alone servers. - -The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Administrators| -| Stand-Alone Server Default Settings | Administrators| -| Domain Controller Effective Default Settings | Administrators| -| Member Server Effective Default Settings | Administrators| -| Client Computer Effective Default Settings | Administrators| - -## Policy management - -This section describes features, tools, and guidance to help you manage this policy. - -A restart of the device isn't required for this policy setting to be effective. - -Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. - -Ownership can be taken by: - -- An administrator. By default, the Administrators group is given the **Take ownership of files or other objects** user right. -- Anyone or any group who has the **Take ownership** user right on the object. -- A user who has the **Restore files and directories** user right. - -Ownership can be transferred in the following ways: - -- The current owner can grant the **Take ownership** user right to another user if that user is a member of a group defined in the current owner's access token. The user must take ownership to complete the transfer. -- An administrator can take ownership. -- A user who has the **Restore files and directories** user right can double-click **Other users and groups** and choose any user or group to assign ownership to. - -### Group Policy - -Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: - -1. Local policy settings -2. Site policy settings -3. Domain policy settings -4. OU policy settings - -When a local setting is greyed out, it indicates that a GPO currently controls that setting. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Any users with the **Take ownership of files or other objects user right** can take control of any object, regardless of the permissions on that object, and then make any changes that they want to make to that object. Such changes could result in exposure of data, corruption of data, or a -denial-of-service condition. - -### Countermeasure - -Ensure that only the local Administrators group has the **Take ownership of files or other objects** user right. - -### Potential impact - -None. Restricting the **Take ownership of files or other objects** user right to the local Administrators group is the default configuration. - -## Related topics - -- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md deleted file mode 100644 index 1dbf68c41d..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: User Account Control Admin Approval Mode for the Built-in Administrator account -description: Best practices, security considerations, and more for the policy setting, User Account Control Admin Approval Mode for the Built-in Administrator account. -ms.assetid: d465fc27-1cd2-498b-9cf6-7ad2276e5998 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 09/08/2017 ---- - -# User Account Control: Admin Approval Mode for the Built-in Administrator account -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. - -## Reference - -This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account. -When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode isn't enabled, the built-in Administrator account runs all applications by default with full administrative privileges. By default, Admin Approval Mode is set to **Disabled**. - -> [!NOTE] -> If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled. - -### Possible values - -- Enabled - - The built-in administrator account logs on in Admin Approval Mode so that any operation that requires elevation of privilege displays a prompt that provides the administrator the option to permit or deny the elevation of privilege. - -- Disabled - - If Admin Approval Mode isn't enabled, the built-in Administrator account runs all applications by default with full administrative privileges - -### Best practices - -- It's recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. See [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account) - - To enable Admin Approval Mode, you must also configure the local security policy setting: [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) to **Prompt for consent on the secure desktop** and then click OK. - -> [!NOTE] -> After enabling Admin Approval Mode, to activate the setting, you must first log in and out. Alternatively, You may perform **gpupdate /force** from an elevated command prompt. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the Administrator account because that user account was created for all installations of Windows. To address this risk, the built-in Administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the Administrator account is enabled, and the password must be changed the first time the administrator logs on. In a default installation of a computer running at least Windows Vista, if the computer isn't joined to a domain, the first user account you create has the equivalent permissions of a local administrator. - -### Countermeasure - -Enable the **User Account Control: Admin Approval Mode for the Built-in Administrator account** setting if you have the built-in Administrator account enabled. - -### Potential impact - -Users who sign in by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege. -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md b/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md deleted file mode 100644 index 4452ee2e72..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop -description: Best practices and more for the policy setting, User Account Control Allow UIAccess applications to prompt for elevation without using the secure desktop. -ms.assetid: fce20472-3c93-449d-b520-13c4c74a9892 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. - -## Reference - -This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user. - ->**Note:**  This setting does not change the behavior of the UAC elevation prompt for administrators. - -**Background** - -User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI doesn't interfere with or change the behavior of messages between applications at the same privilege (or integrity) level. - -Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that support an accessible user experience control the behavior of other Windows applications for the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions don't interfere with the Microsoft UI automation model. - -However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation can't drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess. - -If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy -checks before starting an application with UIAccess privilege. - -1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local computer. -2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are: - - 1. %ProgramFiles% and its subdirectories. - 2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access. - -**Resulting behavior** - -When this setting is enabled, UIAccess programs (including Windows Remote Assistance) can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. The prompts also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation. - -If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled. - -### Possible values - -- Enabled - - UIA programs can automatically disable the secure desktop for elevation prompts, and unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of on the secure desktop. Prompts will also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation. - -- Disabled - - The secure desktop can be disabled only by the user of the interactive desktop or by disabling the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting. - -### Best practices - -- Best practices are dependent on your security policies and your remote operational requirements. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -Server type or GPO| Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -### Policy interactions - -If you plan to enable this setting, you should also review the effect of the [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md) setting. If it's configured as **Automatically deny elevation requests**, elevation requests aren't presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation requests to appear on the regular interactive desktop instead of on the secure desktop. This requests-appearance increases the risk that a malicious program could intercept data that is being transferred between the UI and the application. Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths: - -- ..\\Program Files\\ (and subfolders) -- ..\\Program Files (x86)\\ (and subfolders, in 64-bit versions of Windows only) -- ..\\Windows\\System32\\ - -The requirement to be in a protected path can be disabled by the [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md) setting. Although this setting applies to any UIA program, it's used primarily in certain Windows Remote Assistance scenarios. - -### Countermeasure - -Disable the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** setting. - -### Potential impact - -If a user requests remote assistance from an administrator and the remote assistance session is established, elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user can select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. But selecting this check box requires the interactive user to respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user doesn't have the required credentials to allow elevation. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md deleted file mode 100644 index ba2ac6f92a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode -description: Best practices and more for the security policy setting, User Account Control Behavior of the elevation prompt for administrators in Admin Approval Mode. -ms.assetid: 46a3c3a2-1d2e-4a6f-b5e6-29f9592f535d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 09/08/2017 ---- - -# User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting. - -## Reference - -This policy setting determines the behavior of the elevation prompt for accounts that have administrative credentials. - -### Possible values - -- **Elevate without prompting** - - Assumes that the administrator will permit an operation that requires elevation, and more consent or credentials aren't required. - - **Note**  Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We don't recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. - -- **Prompt for credentials on the secure desktop** - - When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege. - -- **Prompt for consent on the secure desktop** - - When an operation requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.* - -- **Prompt for credential**s - - An operation that requires elevation of privilege prompts the administrator to type the user name and password. If the administrator enters valid credentials, the operation continues with the applicable privilege. - -- **Prompt for consent** - - An operation that requires elevation of privilege prompts the administrator to select **Permit** or **Deny**. If the administrator selects **Permit**, the operation continues with the administrator's highest available privilege. - -- **Prompt for consent for non-Windows binaries** - - This prompt for consent is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege. - -\*If you've enabled the built-in Administrator account and have configured Admin Approval Mode, you must also configure the option **Prompt for consent on the secure desktop**. You can also configure this option from User Account Control, by typing **UAC** in the search box. From the User Account Control Settings dialog box, set the slider control to **Notify me only when apps try to make changes to my computer (default)**. - -> [!NOTE] -> After enabling Admin Approval Mode, to activate the setting, you must first log in and out. Alternatively, You may perform **gpupdate /force** from an elevated command prompt. - -### Best practices - -- Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We don't recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure. - -- It's recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. For more information, see [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account) - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined | -| Stand-Alone Server Default Settings | Prompt for consent for non-Windows binaries| -| DC Effective Default Settings | Prompt for consent for non-Windows binaries| -| Member Server Effective Default Settings | Prompt for consent for non-Windows binaries| -| Client Computer Effective Default Settings | Prompt for consent for non-Windows binaries| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. This setting raises awareness to the administrator of elevated privilege operations, and it permits the administrator to prevent a malicious program from elevating its privilege when the program attempts to do so. - -### Countermeasure - -Configure the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** setting to **Prompt for consent**. - -### Potential impact - -Administrators should be made aware that they'll be prompted for consent when all binaries attempt to run. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md deleted file mode 100644 index f4ef816fc7..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Behavior of the elevation prompt for standard users -description: Learn about best practices, security considerations, and more for the policy setting, User Account Control Behavior of the elevation prompt for standard users. -ms.author: vinpa -author: vinaypamnani-msft -manager: aaroncz -ms.topic: reference -ms.date: 01/18/2023 ---- - -# User Account Control: Behavior of the elevation prompt for standard users - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting. - -This policy setting determines the behavior of the elevation prompt for standard users. - -## Possible values - -- **Automatically deny elevation requests** - - This option returns an *Access denied* error message to standard users when they try to perform an operation that requires elevation of privilege. Most organizations that run desktops as standard users configure this policy to reduce help desk calls. - -- **Prompt for credentials on the secure desktop** - - When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege. - -- **Prompt for credentials** - - An operation that requires elevation of privilege prompts the user to type an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege. This is the default value. - -## Best practices - -1. Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to sign in with an administrative account to run programs that require elevation of privilege. -2. As a security best practice, standard users shouldn't have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, set **Prompt for credentials on the secure desktop** so that the users don't choose to always sign in with their administrator accounts, and they shift their behavior to use the standard user account. - -## Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -## Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy | Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Prompt for credentials on the secure desktop| -| DC Effective Default Settings | Prompt for credentials on the secure desktop| -| Member Server Effective Default Settings | Prompt for credentials on the secure desktop| -| Client Computer Effective Default Settings | Prompt for credentials on the secure desktop| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -One of the risks that the UAC feature tries to mitigate is that of malicious programs running under elevated credentials without the user or administrator being aware of their activity. This setting raises awareness to the user that a program requires the use of elevated privilege operations, and it requires that the user supply administrative credentials for the program to run. - -### Countermeasure - -Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to sign in with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users shouldn't have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting **Prompt for credentials on the secure desktop** so that the users don't choose to always sign in with their administrator accounts, and they shift their behavior to use the standard user account. - -### Potential impact - -Users must provide administrative passwords to run programs with elevated privileges. This impact could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md deleted file mode 100644 index 4456c3de17..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: User Account Control Detect application installations and prompt for elevation -description: Learn about best practices and more for the security policy setting, User Account Control Detect application installations and prompt for elevation. -ms.assetid: 3f8cb170-ba77-4c9f-abb3-c3ed1ef264fc -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Detect application installations and prompt for elevation - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting. - -## Reference - -This policy setting determines the behavior of application installation detection for the entire system. -Some software might attempt to install itself after being given permission to run. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This security policy provides another way to identify and stop these attempted software installations before they can do damage. - -### Possible values - -- **Enabled** - - Application installation packages that require an elevation of privilege to install are detected and the user is prompted for administrative credentials. - -- **Disabled** - - Application installation packages that require an elevation of privilege to install aren't detected and the user isn't prompted for administrative credentials. - -### Best practices - -1. Installer detection is unnecessary when enterprises run standard user desktops that capitalize on delegated installation technologies like Group Policy Software Install (GPSI) or Configuration Manager. Therefore you can set this security policy to **Disabled**. -2. Enable the **User Account Control: Detect application installations and prompt for elevation** setting so standard users must provide administrative credentials before software is installed. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Some malicious software might attempt to install itself after being given permission to run, for example, malicious software with a trusted application shell. The user may give permission for the program to run because the program is trusted. Then the user is prompted to install an unknown component. This policy provides another way to trap the software before it can do damage. - -### Countermeasure - -Enable the **User Account Control: Detect application installations and prompt for elevation** setting. - -### Potential impact - -Users must provide administrative passwords to install programs. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md deleted file mode 100644 index ace44a281a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: User Account Control Only elevate executables that are signed and validated -description: Best practices, security considerations, and more for the security policy setting, User Account Control Only elevate executables that are signed and validated. -ms.assetid: 64950a95-6985-4db6-9905-1db18557352d -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Only elevate executables that are signed and validated - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting. - -## Reference - -This policy setting enforces public key infrastructure (PKI) signature checks on any interactive application that requests elevation of privilege. You can control the apps that are allowed to run through the population of certificates in the local computer's Trusted Publishers store. - -A trusted publisher is a certificate issuer that the computer’s user has chosen to trust and that has certificate details that have been added to the store of trusted publishers. - -Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated with the computer object or they're owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores. A certificate store will often contain numerous certificates, possibly issued from many different certification authorities (CAs). -When certificate path discovery is initiated, Windows attempts to locate the issuing CA for the certificates, and it builds a certificate path to the trusted root certificate. Intermediate certificates are included as part of the application protocol or are picked up from Group Policy or through URLs that are specified in the Authority Information Access (AIA) extension. When the path is built, each certificate in the path is verified for validity with respect to various parameters, such as name, time, signature, revocation status, and other constraints. - -### Possible values - -- **Enabled** - - Enforces the PKI certificate chain validation of a given executable file before it's permitted to run. - -- **Disabled** - - Doesn't enforce PKI certificate chain validation before a given executable file is permitted to run. - -### Best practices - -- Best practices are dependent on your security and performance goals. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Disabled| -| DC Effective Default Settings | Disabled| -| Member Server Effective Default Settings | Disabled| -| Client Computer Effective Default Settings | Disabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Intellectual property, personal information, and other confidential data are normally manipulated by applications on the computer, and elevated credentials are required to access the information. Users and administrators inherently trust applications that are used with these information sources, and they provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data could be compromised and the user's administrative credentials would also be compromised. - -### Countermeasure - -Enable the **User Account Control: Only elevate executables that are signed and validated**. - -### Potential impact - -Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications aren't signed, and they can't be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting. -Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is provided by this setting isn't an assurance that all rogue applications will be found. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md deleted file mode 100644 index 68167d5fe5..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: Only elevate UIAccess app installed in secure location -description: Learn about best practices and more for the policy setting, User Account Control Only elevate UIAccess applications that are installed in secure locations. -ms.assetid: 4333409e-a5be-4f2f-8808-618f53abd22c -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Only elevate UIAccess applications that are installed in secure locations - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting. - -## Reference - -This policy setting enforces the requirement that apps that request running with a UIAccess integrity level by marking *UIAccess=true* in their app manifest must reside in a secure location on the file system. Relatively secure locations are limited to the following directories: - -- \\Program Files\\ including subdirectories -- \\Windows\\system32\\ -- \\Program Files (x86)\\ including subdirectories for 64-bit versions of Windows - ->**Note:**  Windows enforces a PKI signature check on any interactive application that requests running with a UIAccess integrity level, regardless of the state of this security setting. - -**Background** - -User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI doesn't interfere with or change the behavior of messages between applications at the same privilege (or integrity) level. - -Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications for the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions don't interfere with the Microsoft UI automation model. - -However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation can't drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess. - -If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege. - -1. The application must have a digital signature that can be verified by using a digital certificate that is associated with the Trusted Root Certification Authorities store on the local device -2. The application must be installed in a local folder that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are: - - 1. %ProgramFiles% and its subdirectories. - 2. %WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access. - -### Possible values - -- **Enabled** - - An application can start with UIAccess integrity only if it resides in a secure location in the file system. - -- **Disabled** - - An application can start with UIAccess integrity even if it doesn't reside in a secure location in the file system. - -### Best practices - -- Set this policy to **Enabled** to permit applications that are located in one of the designated secure directories to run with UIAccess integrity. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes: -- How an attacker might exploit a feature or its configuration. -- How to implement the countermeasure. -- The possible negative consequences of countermeasure implementation. - -### Vulnerability - -UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as sign-in prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that transmit user interfaces to alternative forms. But it's not required by most applications. A process that's started with UIAccess rights has the following abilities: - -- Set the foreground window. -- Drive any application window by using the SendInput function. -- Use read input for all integrity levels by using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput. -- Set journal hooks. -- Use AttachThreadInput to attach a thread to a higher integrity input queue. - -### Countermeasure - -Enable the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** setting. - -### Potential impact - -If the application that requests UIAccess meets the UIAccess setting requirements, computers that run at least the Windows Vista operating system start the application with the ability to bypass most UIPI restrictions. If the application doesn't meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level. - -## Related articles - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md deleted file mode 100644 index f8aa1b8eec..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: UAC Run all administrators in Admin Approval Mode -description: Learn about best practices, security considerations and more for the security policy setting, User Account Control Run all administrators in Admin Approval Mode. -ms.assetid: b838c561-7bfc-41ef-a7a5-55857259c7bf -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Run all administrators in Admin Approval Mode - -**Applies to** -- Windows 11 -- Windows 10 - -This article describes the best practices, location, values, policy management and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. - -## Reference - -This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This setting is the one that turns on or off the UAC. - -### Possible values - -- **Enabled** - - Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires restarting the system. - -- **Disabled** - - Admin Approval Mode and all related UAC policies are disabled. - - > [!NOTE] - > If this security setting is configured to **Disabled**, **Windows Security** notifies the user that the overall security of the operating system has been reduced. - -### Best practices - -- Turn on this policy to allow all other UAC features and policies to function. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy's property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -The computer must be restarted before this policy is effective when changes to this policy are saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console or Local Security Policy snap-in for a domain, site, or organizational unit. - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -This setting turns on or turns off UAC. If this setting isn't turned on, UAC isn't used, and any security benefits and risk mitigations that are dependent on UAC aren't present on the computer. - -### Countermeasure - -Turn on the **User Account Control: Run all users, including administrators, as standard users** setting. - -### Potential impact - -Users and administrators must learn to work with UAC prompts and adjust their work habits to use least privilege operations. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md deleted file mode 100644 index 97f904064a..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: User Account Control Switch to the secure desktop when prompting for elevation -description: Best practices, security considerations, and more for the policy setting, User Account Control Switch to the secure desktop when prompting for elevation. -ms.assetid: 77a067db-c70d-4b02-9861-027503311b8b -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Switch to the secure desktop when prompting for elevation - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. - -## Reference - -This policy setting determines whether the elevation request prompts on the interactive user desktop or on the secure desktop. - -The secure desktop presents the sign-in UI and restricts functionality and access to the system until the sign-in requirements are satisfied. - -The secure desktop’s primary difference from the user desktop is that only trusted processes running as SYSTEM are allowed to run here (that is, nothing is running at the user’s privilege level). The path to get to the secure desktop from the user desktop must also be trusted through the entire chain. - -### Possible values - -- **Enabled** - - All elevation requests by default go to the secure desktop. - -- **Disabled** - - All elevation requests go to the interactive user desktop. - -### Best practices - -- Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system -processes. - -### Location - -Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value | -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to malicious software. Mouse cursors can be spoofed by hiding the real cursor and replacing it with an offset so the cursor is actually pointing to the **Allow** button. - -### Countermeasure - -Enable the **User Account Control: Switch to the secure desktop when prompting for elevation setting**. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md deleted file mode 100644 index eb289356c6..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: User Account Control Virtualize file and registry write failures to per-user locations -description: Best practices, security considerations and more for the policy setting, User Account Control Virtualize file and registry write failures to per-user locations. -ms.assetid: a7b47420-cc41-4b1c-b03e-f67a05221261 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.topic: reference -ms.date: 04/19/2017 ---- - -# User Account Control: Virtualize file and registry write failures to per-user locations - -**Applies to** -- Windows 11 -- Windows 10 - -Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. - -## Reference - -This policy setting enables or disables the redirection of the write failures of earlier applications to defined locations in the registry and the file system. This feature mitigates applications that historically ran as administrator and wrote runtime application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKEY\_LOCAL\_MACHINE\\Software\\. - -This feature can be disabled for applications on devices running at least Windows Vista because it's unnecessary. - -### Possible values - -- **Enabled** - - Setting this value facilitates the runtime redirection of application write failures to defined user locations for the file system and the registry. - -- **Disabled** - - Applications that write data to protected locations fail. - -### Best practices - -1. If you run applications that aren't Windows Vista-compliant, enable this security policy to prevent the possibility that these older applications could write data to unsecure locations. -2. If you only run at least Windows Vista–compliant applications, this feature is unnecessary so you can disable this policy. - -### Location - -\\Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options - -### Default values - -The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page. - -| Server type or GPO | Default value| -| - | - | -| Default Domain Policy| Not defined| -| Default Domain Controller Policy | Not defined| -| Stand-Alone Server Default Settings | Enabled| -| DC Effective Default Settings | Enabled| -| Member Server Effective Default Settings| Enabled| -| Client Computer Effective Default Settings | Enabled| - -## Policy management - -This section describes features and tools that are available to help you manage this policy. - -### Restart requirement - -None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy. - -### Group Policy - -All auditing capabilities are integrated in Group Policy. You can configure, deploy, and manage these settings in the Group Policy Management Console (GPMC) or Local Security Policy snap-in for a domain, site, or organizational unit (OU). - -## Security considerations - -This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. - -### Vulnerability - -Earlier applications might not write data to secure locations. - -### Countermeasure - -Enable the **User Account Control: Virtualize file and registry write failures to per-user locations** setting. - -### Potential impact - -None. This non-impact state is the default configuration. - -## Related topics - -- [Security Options](/windows/device-security/security-policy-settings/security-options) diff --git a/windows/security/threat-protection/security-policy-settings/user-rights-assignment.md b/windows/security/threat-protection/security-policy-settings/user-rights-assignment.md deleted file mode 100644 index 0ce9074142..0000000000 --- a/windows/security/threat-protection/security-policy-settings/user-rights-assignment.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: User Rights Assignment -description: Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows. -ms.assetid: 99340252-60be-4c79-b0a5-56fbe1a9b0c5 -ms.reviewer: -ms.author: vinpa -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: security -ms.localizationpriority: medium -author: vinaypamnani-msft -manager: aaroncz -audience: ITPro -ms.collection: - - highpri - - tier3 -ms.topic: reference -ms.date: 12/16/2021 ---- - -# User Rights Assignment - -**Applies to** -- Windows 10 -- Windows 11 - -Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows. -User rights govern the methods by which a user can log on to a system. User rights are applied at the local device level, and they allow users to perform tasks on a device or in a domain. User rights include logon rights and permissions. Logon rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the **User Rights Assignment** item. - -Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC) under -**Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment**, or on the local device by using the Local Group Policy Editor (gpedit.msc). - -For information about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md). - -The following table links to each security policy setting and provides the constant name for each. Setting descriptions contain reference information, best practices for configuring the policy setting, default values, differences between operating system versions, and considerations for policy management and security. - -| Group Policy Setting | Constant Name | -| - | - | -| [Access Credential Manager as a trusted caller](access-credential-manager-as-a-trusted-caller.md) | SeTrustedCredManAccessPrivilege| -| [Access this computer from the network](access-this-computer-from-the-network.md) | SeNetworkLogonRight| -| [Act as part of the operating system](act-as-part-of-the-operating-system.md) | SeTcbPrivilege| -| [Add workstations to domain](add-workstations-to-domain.md) | SeMachineAccountPrivilege| -| [Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md) | SeIncreaseQuotaPrivilege| -| [Allow log on locally](allow-log-on-locally.md) | SeInteractiveLogonRight| -| [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md)| SeRemoteInteractiveLogonRight| -| [Back up files and directories](back-up-files-and-directories.md) | SeBackupPrivilege| -| [Bypass traverse checking](bypass-traverse-checking.md) | SeChangeNotifyPrivilege| -| [Change the system time](change-the-system-time.md) | SeSystemtimePrivilege| -| [Change the time zone](change-the-time-zone.md) | SeTimeZonePrivilege| -| [Create a pagefile](create-a-pagefile.md) | SeCreatePagefilePrivilege| -| [Create a token object](create-a-token-object.md) | SeCreateTokenPrivilege| -| [Create global objects](create-global-objects.md) | SeCreateGlobalPrivilege| -| [Create permanent shared objects](create-permanent-shared-objects.md) | SeCreatePermanentPrivilege| -| [Create symbolic links](create-symbolic-links.md) | SeCreateSymbolicLinkPrivilege| -| [Debug programs](debug-programs.md) | SeDebugPrivilege| -| [Deny access to this computer from the network](deny-access-to-this-computer-from-the-network.md)| SeDenyNetworkLogonRight | -| [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) | SeDenyBatchLogonRight| -| [Deny log on as a service](deny-log-on-as-a-service.md) | SeDenyServiceLogonRight | -| [Deny log on locally](deny-log-on-locally.md) | SeDenyInteractiveLogonRight| -| [Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md)| SeDenyRemoteInteractiveLogonRight| -| [Enable computer and user accounts to be trusted for delegation](enable-computer-and-user-accounts-to-be-trusted-for-delegation.md)| SeEnableDelegationPrivilege| -| [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md) | SeRemoteShutdownPrivilege| -| [Generate security audits](generate-security-audits.md) | SeAuditPrivilege| -| [Impersonate a client after authentication](impersonate-a-client-after-authentication.md)| SeImpersonatePrivilege| -| [Increase a process working set](increase-a-process-working-set.md) | SeIncreaseWorkingSetPrivilege| -| [Increase scheduling priority](increase-scheduling-priority.md) | SeIncreaseBasePriorityPrivilege| -| [Load and unload device drivers](load-and-unload-device-drivers.md) | SeLoadDriverPrivilege| -| [Lock pages in memory](lock-pages-in-memory.md) | SeLockMemoryPrivilege| -| [Log on as a batch job](log-on-as-a-batch-job.md) | SeBatchLogonRight| -| [Log on as a service](log-on-as-a-service.md) | SeServiceLogonRight| -| [Manage auditing and security log](manage-auditing-and-security-log.md)| SeSecurityPrivilege| -| [Modify an object label](modify-an-object-label.md) | SeRelabelPrivilege| -| [Modify firmware environment values](modify-firmware-environment-values.md)| SeSystemEnvironmentPrivilege| -| [Obtain an impersonation token for another user in the same session](impersonate-a-client-after-authentication.md) | SeDelegateSessionUserImpersonatePrivilege| -| [Perform volume maintenance tasks](perform-volume-maintenance-tasks.md) | SeManageVolumePrivilege| -| [Profile single process](profile-single-process.md) | SeProfileSingleProcessPrivilege| -| [Profile system performance](profile-system-performance.md) | SeSystemProfilePrivilege| -| [Remove computer from docking station](remove-computer-from-docking-station.md) | SeUndockPrivilege| -| [Replace a process level token](replace-a-process-level-token.md) | SeAssignPrimaryTokenPrivilege| -| [Restore files and directories](restore-files-and-directories.md) | SeRestorePrivilege | -| [Shut down the system](shut-down-the-system.md) | SeShutdownPrivilege| -| [Synchronize directory service data](synchronize-directory-service-data.md)| SeSyncAgentPrivilege| -| [Take ownership of files or other objects](take-ownership-of-files-or-other-objects.md) | SeTakeOwnershipPrivilege| - - -## Related topics - -- [Security policy settings reference](security-policy-settings-reference.md)