deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Delete all in /windows/security/threat-protection/security-policy-settings/

Browse Source
This commit is contained in:
Gary Moore 2024-02-28 22:01:28 -08:00
parent e44c798d46
commit b8a420f240
173 changed files with 0 additions and 17190 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

345
windows/security/threat-protection/security-policy-settings/TOC.yml
View File

@ -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/

94
windows/security/threat-protection/security-policy-settings/access-credential-manager-as-a-trusted-caller.md
View File

@ -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)

118
windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
View File

@ -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)

80
windows/security/threat-protection/security-policy-settings/account-lockout-duration.md
View File

@ -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)

47
windows/security/threat-protection/security-policy-settings/account-lockout-policy.md
View File

@ -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)

131
windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md
View File

@ -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.
### <a href="" id="bkmk-impleconsiderations"></a>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.
### <a href="" id="bkmk-countermeasure"></a>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)

42
windows/security/threat-protection/security-policy-settings/account-policies.md
View File

@ -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)

111
windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md
View File

@ -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)

96
windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md
View File

@ -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)

78
windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md
View File

@ -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)

97
windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
View File

@ -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)

95
windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
View File

@ -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)

94
windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md
View File

@ -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)

91
windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md
View File

@ -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)

96
windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md
View File

@ -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)
 
 

99
windows/security/threat-protection/security-policy-settings/adjust-memory-quotas-for-a-process.md
View File

@ -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<br>Local Service<br>Network Service |
| Default Domain Controller Policy | Administrators<br>Local Service<br>Network Service |
| Stand-Alone Server Default Settings | Administrators<br>Local Service<br>Network Service |
| Domain Controller Effective Default Settings | Administrators<br>Local Service<br>Network Service |
| Member Server Effective Default Settings | Administrators<br>Local Service<br>Network Service |
| Client Computer Effective Default Settings | Administrators<br>Local Service<br>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\_&lt;ComputerName&gt;, 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)

314
windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md
View File

@ -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.
## <a href="" id="what-s-changed-in-how-settings-are-administered-"></a>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 <br> MMC snap-in designed to manage only security policy settings.|
|[Security editor command line tool](#using-the-secedit-command-line-tool) |Secedit.exe <br> Configures and analyzes system security by comparing your current configuration to specified security templates.|
|[Security Compliance Manager](#using-the-security-compliance-manager)|Tool download <br> 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 <br> 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 <br> 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 <br> See [Administer Software Restriction Policies](/windows-server/identity/software-restriction-policies/administer-software-restriction-policies)|Gpedit.msc <br> 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 <br> See [Administer AppLocker](/windows/device-security/applocker/administer-applocker)|Gpedit.msc <br> 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.|
## <a href="" id="bkmk-secpol"></a>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.
## <a href="" id="bkmk-secedit"></a>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.
## <a href="" id="bkmk-scm"></a>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.
## <a href="" id="bkmk-scw"></a>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)).
## <a href="" id="bkmk-scmtool"></a>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.|
### <a href="" id="bkmk-seccfgana"></a>Security Configuration and Analysis
Security Configuration and Analysis is an MMC snap-in for analyzing and configuring local system security.
### <a href="" id="h2-359808543"></a>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.
### <a href="" id="h2-359810173"></a>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.
### <a href="" id="bkmk-sectmpl"></a>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.
### <a href="" id="bkmk-secextensions"></a>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.
### <a href="" id="bkmk-localsecpol"></a>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)
### <a href="" id="bkmk-applysecsettings"></a>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.
### <a href="" id="bkmk-impexpsectmpl"></a>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.
### <a href="" id="bkmk-anasecviewresults"></a>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. <br> 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.
### <a href="" id="bkmk-resolvesecdiffs"></a>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.
### <a href="" id="bkmk-autoseccfgtasks"></a>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.
## <a href="" id="bkmk-grouppolicy"></a>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.

115
windows/security/threat-protection/security-policy-settings/allow-log-on-locally.md
View File

@ -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<br>Administrators<br>Backup Operators<br>Enterprise Domain Controllers<br>Print Operators<br>Server Operators |
| Stand-Alone Server Default Settings| Administrators<br>Backup Operators<br>Users |
| Domain Controller Effective Default Settings | Account Operators<br>Administrators<br>Backup Operators<br>Enterprise Domain Controllers<br>Print Operators<br>Server Operators |
| Member Server Effective Default Settings | Administrators<br>Backup Operators<br>Users |
| Client Computer Effective Default Settings | Administrators<br>Backup Operators<br>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\_*&lt;ComputerName&gt;* 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)

108
windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md
View File

@ -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<br>Remote Desktop Users |
| Domain Controller Effective Default Settings | Administrators |
| Member Server Effective Default Settings | Administrators<br>Remote Desktop Users |
| Client Computer Effective Default Settings | Administrators<br>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)

124
windows/security/threat-protection/security-policy-settings/audit-audit-the-access-of-global-system-objects.md
View File

@ -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.<br>**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.<br>**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.<br>**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)

93
windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md
View File

@ -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)

102
windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md
View File

@ -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)

44
windows/security/threat-protection/security-policy-settings/audit-policy.md
View File

@ -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)
 
 

98
windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
View File

@ -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)

117
windows/security/threat-protection/security-policy-settings/back-up-files-and-directories.md
View File

@ -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<br>Backup Operators<br>Server Operators|
| Stand-Alone Server Default Settings | Administrators<br>Backup Operators|
| Domain Controller Effective Default Settings | Administrators<br>Backup Operators<br>Server Operators|
| Member Server Effective Default Settings | Administrators<br>Backup Operators|
| Client Computer Effective Default Settings | Administrators<br>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)

99
windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md
View File

@ -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<br/>Authenticated Users<br/>Everyone<br/>Local Service<br/>Network Service<br/>Pre-Windows 2000 Compatible Access|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators<br/>Users<br/>Everyone<br/>Local Service<br/>Network Service|
| Domain Controller Effective Default Settings | Administrators<br/>Authenticated Users<br/>Everyone<br/>Local Service<br/>Network Service<br/>Pre-Windows 2000 Compatible Access|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators<br/>Users<br/>Everyone<br/>Local Service<br/>Network Service|
| Client Computer Effective Default Settings | Administrators<br/>Backup Operators<br/>Users<br/>Everyone<br/>Local Service<br/>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\_*&lt;ComputerName&gt;*, and IWAM\_*&lt;ComputerName&gt;* 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)

113
windows/security/threat-protection/security-policy-settings/change-the-system-time.md
View File

@ -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 <br/>Server Operators <br/>Local Service|
| Stand-Alone Server Default Settings | Administrators <br/>Local Service|
| DC Effective Default Settings | Administrators <br/>Server Operators <br/>Local Service|
| Member Server Effective Default Settings | Administrators <br/>Local Service|
| Client Computer Effective Default Settings | Administrators <br/>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)

93
windows/security/threat-protection/security-policy-settings/change-the-time-zone.md
View File

@ -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<br/>Users|
| Stand-Alone Server Default Settings | Administrators<br/>Users|
| Domain Controller Effective Default Settings | Administrators<br/>Users|
| Member Server Effective Default Settings | Administrators<br/>Users|
| Client Computer Effective Default Settings | Administrators<br/>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)

97
windows/security/threat-protection/security-policy-settings/create-a-pagefile.md
View File

@ -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)

99
windows/security/threat-protection/security-policy-settings/create-a-token-object.md
View File

@ -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)

99
windows/security/threat-protection/security-policy-settings/create-global-objects.md
View File

@ -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<br/>Local Service<br/>Network Service<br/>Service|
| Stand-Alone Server Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Domain Controller Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Member Server Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Client Computer Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>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)

97
windows/security/threat-protection/security-policy-settings/create-permanent-shared-objects.md
View File

@ -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)

106
windows/security/threat-protection/security-policy-settings/create-symbolic-links.md
View File

@ -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)

98
windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
View File

@ -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)

97
windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
View File

@ -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)

99
windows/security/threat-protection/security-policy-settings/debug-programs.md
View File

@ -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)

110
windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md
View File

@ -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)

105
windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md
View File

@ -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)

100
windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md
View File

@ -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)

99
windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md
View File

@ -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)

87
windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md
View File

@ -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)

87
windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md
View File

@ -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)

91
windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md
View File

@ -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)

87
windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
View File

@ -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)

87
windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
View File

@ -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)

87
windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md
View File

@ -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)

88
windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-channel-binding-token-requirements.md
View File

@ -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)

85
windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md
View File

@ -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)

86
windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md
View File

@ -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)

121
windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
View File

@ -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)

115
windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
View File

@ -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)

113
windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md
View File

@ -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)

99
windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md
View File

@ -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:<AD DS domain name>
```
In this command, \<AD DS domain name\> 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)

88
windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md
View File

@ -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)

104
windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md
View File

@ -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)

110
windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
View File

@ -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)

93
windows/security/threat-protection/security-policy-settings/enforce-password-history.md
View File

@ -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)

95
windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md
View File

@ -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)

101
windows/security/threat-protection/security-policy-settings/force-shutdown-from-a-remote-system.md
View File

@ -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<br/>Server Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>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)

100
windows/security/threat-protection/security-policy-settings/generate-security-audits.md
View File

@ -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<br/>Network Service|
| Stand-Alone Server Default Settings | Local Service<br/>Network Service|
| Domain Controller Effective Default Settings | Local Service<br/>Network Service|
| Member Server Effective Default Settings | Local Service<br/>Network Service|
| Client Computer Effective Default Settings | Local Service<br/>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)

81
windows/security/threat-protection/security-policy-settings/how-to-configure-security-policy-settings.md
View File

@ -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:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>
---
# 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)

BIN
windows/security/threat-protection/security-policy-settings/images/privacy-setting-in-sign-in-options.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.9 KiB

BIN
windows/security/threat-protection/security-policy-settings/images/secpol-architecture.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 34 KiB

BIN
windows/security/threat-protection/security-policy-settings/images/secpol-components.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 8.4 KiB

BIN
windows/security/threat-protection/security-policy-settings/images/secpol-multigpomerge.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.0 KiB

BIN
windows/security/threat-protection/security-policy-settings/images/secpol-processes.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 14 KiB

111
windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication.md
View File

@ -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<br/>Local Service<br/>Network Service<br/>Service|
| Stand-Alone Server Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Domain Controller Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Member Server Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Client Computer Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>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\_*&lt;ComputerName&gt;*, IIS\_WPG, ASP.NET, or IWAM\_*&lt;ComputerName&gt;*.
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)

95
windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md
View File

@ -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)

91
windows/security/threat-protection/security-policy-settings/increase-scheduling-priority.md
View File

@ -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))

155
windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md
View File

@ -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)

95
windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md
View File

@ -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)

96
windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md
View File

@ -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)

93
windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md
View File

@ -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)

95
windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md
View File

@ -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)

105
windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md
View File

@ -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)

111
windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
View File

@ -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)

92
windows/security/threat-protection/security-policy-settings/interactive-logon-prompt-user-to-change-password-before-expiration.md
View File

@ -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)

97
windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
View File

@ -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)

93
windows/security/threat-protection/security-policy-settings/interactive-logon-require-smart-card.md
View File

@ -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)

113
windows/security/threat-protection/security-policy-settings/interactive-logon-smart-card-removal-behavior.md
View File

@ -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)

44
windows/security/threat-protection/security-policy-settings/kerberos-policy.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md
View File

@ -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<br/>Print Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>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)

102
windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md
View File

@ -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<br/>Backup Operators<br/>Performance Log Users|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Domain Controller Effective Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators<br/>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\_*&lt;ComputerName&gt;* and IWAM\_*&lt;ComputerName&gt;* 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\_*&lt;ComputerName&gt;*, ASPNET, and IWAM\_*&lt;ComputerName&gt;* 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)

99
windows/security/threat-protection/security-policy-settings/log-on-as-a-service.md
View File

@ -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)

104
windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md
View File

@ -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)

98
windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md
View File

@ -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)

96
windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md
View File

@ -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)

96
windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md
View File

@ -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)

89
windows/security/threat-protection/security-policy-settings/maximum-password-age.md
View File

@ -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)

97
windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md
View File

@ -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)

115
windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.md
View File

@ -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 <sup>1</sup> | Not signed<sup>2</sup> |
</br>
<sup>1</sup> Default for domain controller SMB traffic</br>
<sup>2</sup> 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)

90
windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
View File

@ -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)

88
windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
View File

@ -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)

103
windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
View File

@ -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)

115
windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md
View File

@ -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 <sup>1</sup> | Not Signed<sup>2</sup> |
</br>
<sup>1</sup> Default for domain controller SMB traffic</br>
<sup>2</sup> 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)

93
windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
View File

@ -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)

Some files were not shown because too many files have changed in this diff Show More