Merge branch 'main' into v-mathavale-6063796

This commit is contained in:
Meghana Athavale
2022-08-11 16:23:09 +05:30
1177 changed files with 8416 additions and 11692 deletions

View File

@ -219,25 +219,25 @@
- name: Create a WIP policy using Microsoft Intune
href: information-protection/windows-information-protection/overview-create-wip-policy.md
items:
- name: Create a WIP policy with MDM using the Azure portal for Microsoft Intune
- name: Create a WIP policy in Microsoft Intune
href: information-protection/windows-information-protection/create-wip-policy-using-intune-azure.md
items:
- name: Deploy your WIP policy using the Azure portal for Microsoft Intune
- name: Deploy your WIP policy in Microsoft Intune
href: information-protection/windows-information-protection/deploy-wip-policy-using-intune-azure.md
- name: Associate and deploy a VPN policy for WIP using the Azure portal for Microsoft Intune
- name: Associate and deploy a VPN policy for WIP in Microsoft Intune
href: information-protection/windows-information-protection/create-vpn-and-wip-policy-using-intune-azure.md
- name: Create and verify an EFS Data Recovery Agent (DRA) certificate
href: information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
- name: Determine the Enterprise Context of an app running in WIP
- name: Determine the enterprise context of an app running in WIP
href: information-protection/windows-information-protection/wip-app-enterprise-context.md
- name: Create a WIP policy using Microsoft Endpoint Configuration Manager
href: information-protection/windows-information-protection/overview-create-wip-policy-configmgr.md
items:
- name: Create and deploy a WIP policy using Microsoft Endpoint Configuration Manager
- name: Create and deploy a WIP policy in Configuration Manager
href: information-protection/windows-information-protection/create-wip-policy-using-configmgr.md
- name: Create and verify an EFS Data Recovery Agent (DRA) certificate
href: information-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate.md
- name: Determine the Enterprise Context of an app running in WIP
- name: Determine the enterprise context of an app running in WIP
href: information-protection/windows-information-protection/wip-app-enterprise-context.md
- name: Mandatory tasks and settings required to turn on WIP
href: information-protection/windows-information-protection/mandatory-settings-for-wip.md
@ -260,6 +260,8 @@
href: information-protection/windows-information-protection/using-owa-with-wip.md
- name: Fine-tune WIP Learning
href: information-protection/windows-information-protection/wip-learning.md
- name: Disable WIP
href: information-protection/windows-information-protection/how-to-disable-wip.md
- name: Application security
items:
- name: Overview
@ -317,29 +319,15 @@
href: identity-protection/credential-guard/credential-guard-known-issues.md
- name: Protect Remote Desktop credentials with Remote Credential Guard
href: identity-protection/remote-credential-guard.md
- name: Configuring LSA Protection
href: /windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection?toc=/windows/security/toc.json&bc=/windows/security/breadcrumb/toc.json
- name: Technical support policy for lost or forgotten passwords
href: identity-protection/password-support-policy.md
- name: Access Control Overview
href: identity-protection/access-control/access-control.md
items:
- name: Dynamic Access Control Overview
href: identity-protection/access-control/dynamic-access-control.md
- name: Security identifiers
href: identity-protection/access-control/security-identifiers.md
- name: Security Principals
href: identity-protection/access-control/security-principals.md
- name: Local Accounts
href: identity-protection/access-control/local-accounts.md
- name: Active Directory Accounts
href: identity-protection/access-control/active-directory-accounts.md
- name: Microsoft Accounts
href: identity-protection/access-control/microsoft-accounts.md
- name: Service Accounts
href: identity-protection/access-control/service-accounts.md
- name: Active Directory Security Groups
href: identity-protection/access-control/active-directory-security-groups.md
- name: Special Identities
href: identity-protection/access-control/special-identities.md
- name: User Account Control
href: identity-protection/user-account-control/user-account-control-overview.md
items:

View File

@ -0,0 +1,12 @@
items:
- name: Docs
tocHref: /
topicHref: /
items:
- name: Windows
tocHref: /windows/
topicHref: /windows/resources/
items:
- name: Security
tocHref: /windows-server/security/credentials-protection-and-management/
topicHref: /windows/security/

View File

@ -41,7 +41,7 @@
"audience": "ITPro",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.security",

View File

@ -1,621 +0,0 @@
---
title: Active Directory Accounts (Windows 10)
description: Active Directory Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 08/23/2019
---
# Active Directory Accounts
**Applies to**
- Windows Server 2016
Windows Server operating systems are installed with default local accounts. In addition, you can create user accounts to meet the requirements of your organization. This reference topic for the IT professional describes the Windows Server default local accounts that are stored locally on the domain controller and are used in Active Directory.
This reference topic does not describe default local user accounts for a member or standalone server or for a Windows client. For more information, see [Local Accounts](local-accounts.md).
## About this topic
This topic describes the following:
- [Default local accounts in Active Directory](#sec-ad-default-accounts)
- [Administrator account](#sec-administrator)
- [Guest account](#sec-guest)
- [HelpAssistant account (installed with a Remote Assistance session)](#sec-helpassistant)
- [KRBTGT account](#sec-krbtgt)
- [Settings for default local accounts in Active Directory](#sec-account-settings)
- [Manage default local accounts in Active Directory](#sec-manage-local-accounts)
- [Restrict and protect sensitive domain accounts](#sec-restrict-protect-accounts)
- [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
- [Create dedicated workstation hosts without Internet and email access](#task2-admin-workstations)
- [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
- [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
- [Secure and manage domain controllers](#sec-secure-manage-dcs)
## <a href="" id="sec-ad-default-accounts"></a>Default local accounts in Active Directory
Default local accounts are built-in accounts that are created automatically when a Windows Server domain controller is installed and the domain is created. These default local accounts have counterparts in Active Directory. These accounts also have domain-wide access and are completely separate from the default local user accounts for a member or standalone server.
You can assign rights and permissions to default local accounts on a particular domain controller, and only on that domain controller. These accounts are local to the domain. After the default local accounts are installed, they are stored in the Users container in Active Directory Users and Computers. It is a best practice to keep the default local accounts in the User container and not attempt to move these accounts, for example, to a different organizational unit (OU).
The default local accounts in the Users container include: Administrator, Guest, and KRBTGT. The HelpAssistant account is installed when a Remote Assistance session is established. The following sections describe the default local accounts and their use in Active Directory.
Primarily, default local accounts do the following:
- Let the domain represent, identify, and authenticate the identity of the user that is assigned to the account by using unique credentials (user name and password). It is a best practice to assign each user to a single account to ensure maximum security. Multiple users are not allowed to share one account. A user account lets a user sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
- Authorize (grant or deny) access to resources. After a users credentials have been authenticated, the user is authorized to access the network and domain resources based on the users explicitly assigned rights on the resource.
- Audit the actions that are carried out on a user account.
In Active Directory, default local accounts are used by administrators to manage domain and member servers directly and from dedicated administrative workstations. Active Directory accounts provide access to network resources. Active Directory User accounts and Computer accounts can represent a physical entity, such as a computer or person, or act as dedicated service accounts for some applications.
Each default local account is automatically assigned to a security group that is preconfigured with the appropriate rights and permissions to perform specific tasks. Active Directory security groups collect user accounts, computer accounts, and other groups into manageable units. For more information, see [Active Directory Security Groups](active-directory-security-groups.md).
On an Active Directory domain controller, each default local account is referred to as a security principal. A security principal is a directory object that is used to secure and manage Active Directory services that provide access to domain controller resources. A security principal includes objects such as user accounts, computer accounts, security groups, or the threads or processes that run in the security context of a user or computer account. For more information, see [Security Principals](security-principals.md).
A security principal is represented by a unique security identifier (SID).The SIDs that are related to each of the default local accounts in Active Directory are described in the sections below.
Some of the default local accounts are protected by a background process that periodically checks and applies a specific security descriptor. A security descriptor is a data structure that contains security information that is associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the default local accounts or groups is overwritten with the protected settings.
This security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object to ensure that it is applied consistently. Be careful when making these modifications, because you are also changing the default settings that are applied to all of your protected accounts.
## <a href="" id="sec-administrator"></a>Administrator account
The Administrator account is a default account that is used in all versions of the Windows operating system on every computer and device. The Administrator account is used by the system administrator for tasks that require administrative credentials. This account cannot be deleted or locked out, but the account can be renamed or disabled.
The Administrator account gives the user complete access (Full Control permissions) of the files, directories, services, and other resources that are on that local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. Administrator can also be used to take control of local resources at any time simply by changing the user rights and permissions. Although files and directories can be protected from the Administrator account temporarily, the Administrator account can take control of these resources at any time by changing the access permissions.
**Account group membership**
The Administrator account has membership in the default security groups as described in the Administrator account attributes table later in this topic.
The security groups ensure that you can control administrator rights without having to change each Administrator account. In most instances, you do not have to change the basic settings for this account. However, you might have to change its advanced settings, such as membership in particular groups.
**Security considerations**
After installation of the server operating system, your first task is to set up the Administrator account properties securely. This includes setting up an especially long, strong password, and securing the Remote control and Remote Desktop Services profile settings.
The Administrator account can also be disabled when it is not required. Renaming or disabling the Administrator account makes it more difficult for malicious users to try to gain access to the account. However, even when the Administrator account is disabled, it can still be used to gain access to a domain controller by using safe mode.
On a domain controller, the Administrator account becomes the Domain Admin account. The Domain Admin account is used to sign in to the domain controller and this account requires a strong password. The Domain Admin account gives you access to domain resources.
> [!NOTE]
> When the domain controller is initially installed, you can sign in and use Server Manager to set up a local Administrator account, with the rights and permissions you want to assign. For example, you can use a local Administrator account to manage the operating system when you first install it. By using this approach, you can set up the operating system without getting locked out. Generally, you do not need to use the account after installation. You can only create local user accounts on the domain controller, before Active Directory Domain Services is installed, and not afterwards.
When Active Directory is installed on the first domain controller in the domain, the Administrator account is created for Active Directory. The Administrator account is the most powerful account in the domain. It is given domain-wide access and administrative rights to administer the computer and the domain, and it has the most extensive rights and permissions over the domain. The person who installs Active Directory Domain Services on the computer creates the password for this account during the installation.
**Administrator account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-500|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|N/A|
|Default member of|Administrators, Domain Admins, Enterprise Administrators, Domain Users. Note that the Primary Group ID of all user accounts is Domain Users. <br/><br/>Group Policy Creator Owners, and Schema Admins in Active Directory<br/><br/>Domain Users group|
|Protected by ADMINSDHOLDER?|Yes|
|Safe to move out of default container?|Yes|
|Safe to delegate management of this group to non-service administrators?|No|
## <a href="" id="sec-guest"></a>Guest account
The Guest account is a default local account that has limited access to the computer and is disabled by default. By default, the Guest account password is left blank. A blank password allows the Guest account to be accessed without requiring the user to enter a password.
The Guest account enables occasional or one-time users, who do not have an individual account on the computer, to sign in to the local server or domain with restricted rights and permissions. The Guest account can be enabled, and the password can be set up if needed, but only by a member of the Administrator group on the domain.
**Account group membership**
The Guest account has membership in the default security groups that are described in the following Guest account attributes table. By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server, and the Domain Guests global group, which lets a user sign in to a domain.
A member of the Administrators group or Domain Admins group can set up a user with a Guest account on one or more computers.
**Security considerations**
Because the Guest account can provide anonymous access, it is a security risk. It also has a well-known SID. For this reason, it is a best practice to leave the Guest account disabled, unless its use is required and then only with restricted rights and permissions for a very limited period of time.
When the Guest account is required, an Administrator on the domain controller is required to enable the Guest account. The Guest account can be enabled without requiring a password, or it can be enabled with a strong password. The Administrator also grants restricted rights and permissions for the Guest account. To help prevent unauthorized access:
- Do not grant the Guest account the [Shut down the system](/windows/device-security/security-policy-settings/shut-down-the-system) user right. When a computer is shutting down or starting up, it is possible that a Guest user or anyone with local access, such as a malicious user, could gain unauthorized access to the computer.
- Do not provide the Guest account with the ability to view the event logs. After the Guest account is enabled, it is a best practice to monitor this account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
- Do not use the Guest account when the server has external network access or access to other computers.
If you decide to enable the Guest account, be sure to restrict its use and to change the password regularly. As with the Administrator account, you might want to rename the account as an added security precaution.
In addition, an administrator is responsible for managing the Guest account. The administrator monitors the Guest account, disables the Guest account when it is no longer in use, and changes or removes the password as needed.
For details about the Guest account attributes, see the following table.
**Guest account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-501|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Guests, Domain Guests|
|Protected by ADMINSDHOLDER?|No|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the users invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
**Security considerations**
The SIDs that pertain to the default HelpAssistant account include:
- SID: S-1-5-`<domain>`-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
- SID: S-1-5-`<domain>`-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
For details about the HelpAssistant account attributes, see the following table.
**HelpAssistant account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-13 (Terminal Server User), S-1-5-`<domain>`-14 (Remote Interactive Logon)|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Domain Guests<p>Guests|
|Protected by ADMINSDHOLDER?|No|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-krbtgt"></a>KRBTGT account
The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.
KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.
Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.
### KRBTGT account maintenance considerations
A strong password is assigned to the KRBTGT and trust accounts automatically. Like any privileged service accounts, organizations should change these passwords on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.
Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. In addition, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.
After you reset the KRBTGT password, ensure that event ID 9 in the (Kerberos) Key-Distribution-Center event source is written to the System event log.
### Security considerations
It is also a best practice to reset the KRBTGT account password to ensure that a newly restored domain controller does not replicate with a compromised domain controller. In this case, in a large forest recovery that is spread across multiple locations, you cannot guarantee that all domain controllers are shut down, and if they are shut down, they cannot be rebooted again before all of the appropriate recovery steps have been undertaken. After you reset the KRBTGT account, another domain controller cannot replicate this account password by using an old password.
An organization suspecting domain compromise of the KRBTGT account should consider the use of professional incident response services. The impact to restore the ownership of the account is domain-wide and labor intensive an should be undertaken as part of a larger recovery effort.
The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT password is similar to renewing the root CA certificate with a new key and immediately not trusting the old key, resulting in almost all subsequent Kerberos operations will be affected.
For all account types (users, computers, and services)
- All the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These tickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the tickets become invalid.
- All currently authenticated sessions that logged on users have established (based on their service tickets) to a resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is required to re-authenticate.
- NTLM authenticated connections are not affected
Because it is impossible to predict the specific errors that will occur for any given user in a production operating environment, you must assume all computers and users will be affected.
> [!IMPORTANT]
> Rebooting a computer is the only reliable way to recover functionality as this will cause both the computer account and user accounts to log back in again. Logging in again will request new TGTs that are valid with the new KRBTGT, correcting any KRBTGT related operational issues on that computer.
For information about how to help mitigate the risks associated with a potentially compromised KRBTGT account, see [KRBTGT Account Password Reset Scripts now available for customers](https://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/).
### Read-only domain controllers and the KRBTGT account
Windows Server 2008 introduced the read-only domain controller (RODC). The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different KRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is successfully authenticated, the RODC determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC by using the Password Replication Policy.
After the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the credentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.
### KRBTGT account attributes
For details about the KRBTGT account attributes, see the following table.
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-502|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Domain Users group. Note that the Primary Group ID of all user accounts is Domain Users.|
|Protected by ADMINSDHOLDER?|Yes|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-account-settings"></a>Settings for default local accounts in Active Directory
Each default local account in Active Directory has a number of account settings that you can use to configure password settings and security-specific information, as described in the following table.
**Settings for default local accounts in Active Directory**
|Account settings|Description|
|--- |--- |
|User must change password at next logon|Forces a password change the next time that the user logs signs in to the network. Use this option when you want to ensure that the user is the only person to know his or her password.|
|User cannot change password|Prevents the user from changing the password. Use this option when you want to maintain control over a user account, such as for a Guest or temporary account.|
|Password never expires|Prevents a user password from expiring. It is a best practice to enable this option with service accounts and to use strong passwords.|
|Store passwords using reversible encryption|Provides support for applications that use protocols requiring knowledge of the plaintext form of the users password for authentication purposes.<br/><br/>This option is required when using Challenge Handshake Authentication Protocol (CHAP) in Internet Authentication Services (IAS), and when using digest authentication in Internet Information Services (IIS).|
|Account is disabled|Prevents the user from signing in with the selected account. As an administrator, you can use disabled accounts as templates for common user accounts.|
|Smart card is required for interactive logon|Requires that a user has a smart card to sign on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card.<br/><br/>When this attribute is applied on the account, the effect is as follows:<li>The attribute only restricts initial authentication for interactive logon and Remote Desktop logon. When interactive or Remote Desktop logon requires a subsequent network logon, such as with a domain credential, an NT Hash provided by the domain controller is used to complete the smartcard authentication process<li>Each time the attribute is enabled on an account, the accounts current password hash value is replaced with a 128-bit random number. This invalidates the use of any previously configured passwords for the account. The value does not change after that unless a new password is set or the attribute is disabled and re-enabled.<li>Accounts with this attribute cannot be used to start services or run scheduled tasks.|
|Account is trusted for delegation|Lets a service running under this account perform operations on behalf of other user accounts on the network. A service running under a user account (also known as a service account) that is trusted for delegation can impersonate a client to gain access to resources, either on the computer where the service is running or on other computers. For example, in a forest that is set to the Windows Server 2003 functional level, this setting is found on the Delegation tab. It is available only for accounts that have been assigned service principal names (SPNs), which are set by using the setspn command from Windows Support Tools. This setting is security-sensitive and should be assigned cautiously.|
|Account is sensitive and cannot be delegated|Gives control over a user account, such as for a Guest account or a temporary account. This option can be used if this account cannot be assigned for delegation by another account.|
|Use DES encryption types for this account|Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard (40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong (128-bit), Internet Protocol security (IPSec) DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES).<div class="alert"> **Note:** DES is not enabled by default in Windows Server operating systems starting with Windows Server 2008 R2, nor in Windows client operating systems starting with Windows 7. For these operating systems, computers will not use DES-CBC-MD5 or DES-CBC-CRC cipher suites by default. If your environment requires DES, then this setting might affect compatibility with client computers or services and applications in your environment. For more information, see [Hunting down DES in order to securely deploy Kerberos](/archive/blogs/askds/hunting-down-des-in-order-to-securely-deploy-kerberos)</div>|
|Do not require Kerberos preauthentication|Provides support for alternate implementations of the Kerberos protocol. Because preauthentication provides additional security, use caution when enabling this option. Note that domain controllers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time.|
## <a href="" id="sec-manage-local-accounts"></a>Manage default local accounts in Active Directory
After the default local accounts are installed, these accounts reside in the Users container in Active Directory Users and Computers. Default local accounts can be created, disabled, reset, and deleted by using the Active Directory Users and Computers Microsoft Management Console (MMC) and by using command-line tools.
You can use Active Directory Users and Computers to assign rights and permissions on a given local domain controller, and that domain controller only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting down a computer. In contrast, an access permission is a rule that is associated with an object, usually a file, folder, or printer, that regulates which users can have access to the object and in what manner.
For more information about creating and managing local user accounts in Active Directory, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
You can also use Active Directory Users and Computers on a domain controller to target remote computers that are not domain controllers on the network.
You can obtain recommendations from Microsoft for domain controller configurations that you can distribute by using the Security Compliance Manager (SCM) tool. For more information, see [Microsoft Security Compliance Manager](/previous-versions/tn-archive/cc677002(v=technet.10)).
Some of the default local user accounts are protected by a background process that periodically checks and applies a specific security descriptor, which is a data structure that contains security information that is associated with a protected object. This security descriptor is present on the AdminSDHolder object.
This means, when you want to modify the permissions on a service administrator group or on any of its member accounts, you are also required to modify the security descriptor on the AdminSDHolder object. This approach ensures that the permissions are applied consistently. Be careful when you make these modifications, because this action can also affect the default settings that are applied to all of your protected administrative accounts.
## <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect sensitive domain accounts
Restricting and protecting domain accounts in your domain environment requires you to adopt and implement the following best practices approach:
- Strictly limit membership to the Administrators, Domain Admins, and Enterprise Admins groups.
- Stringently control where and how domain accounts are used.
Member accounts in the Administrators, Domain Admins, and Enterprise Admins groups in a domain or forest are high-value targets for malicious users. It is a best practice to strictly limit membership to these administrator groups to the smallest number of accounts in order to limit any exposure. Restricting membership in these groups reduces the possibility that an administrator might unintentionally misuse these credentials and create a vulnerability that malicious users can exploit.
Moreover, it is a best practice to stringently control where and how sensitive domain accounts are used. Restrict the use of Domain Admins accounts and other administrator accounts to prevent them from being used to sign in to management systems and workstations that are secured at the same level as the managed systems. When administrator accounts are not restricted in this manner, each workstation from which a domain administrator signs in provides another location that malicious users can exploit.
Implementing these best practices is separated into the following tasks:
- [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
- [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
- [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
- [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
Note that, to provide for instances where integration challenges with the domain environment are expected, each task is described according to the requirements for a minimum, better, and ideal implementation. As with all significant changes to a production environment, ensure that you test these changes thoroughly before you implement and deploy them. Then stage the deployment in a manner that allows for a rollback of the change in case technical issues occur.
### <a href="" id="task1-separate-admin-accounts"></a>Separate administrator accounts from user accounts
Restrict Domain Admins accounts and other sensitive accounts to prevent them from being used to sign in to lower trust servers and workstations. Restrict and protect administrator accounts by segregating administrator accounts from standard user accounts, by separating administrative duties from other tasks, and by limiting the use of these accounts. Create dedicated accounts for administrative personnel who require administrator credentials to perform specific administrative tasks, and then create separate accounts for other standard user tasks, according to the following guidelines:
- **Privileged account**. Allocate administrator accounts to perform the following administrative duties only:
- **Minimum**. Create separate accounts for domain administrators, enterprise administrators, or the equivalent with appropriate administrator rights in the domain or forest. Use accounts that have been granted sensitive administrator rights only to administer domain data and domain controllers.
- **Better**. Create separate accounts for administrators that have reduced administrative rights, such as accounts for workstation administrators, and accounts with user rights over designated Active Directory organizational units (OUs).
- **Ideal**. Create multiple, separate accounts for an administrator who has a variety of job responsibilities that require different trust levels. Set up each administrator account with significantly different user rights, such as for workstation administration, server administration and domain administration, to let the administrator sign in to given workstations, servers and domain controllers based strictly on his or her job responsibilities.
- **Standard user account**. Grant standard user rights for standard user tasks, such as email, web browsing, and using line-of-business (LOB) applications. These accounts should not be granted administrator rights.
> [!IMPORTANT]
> Ensure that sensitive administrator accounts cannot access email or browse the Internet as described in the following section.
### <a href="" id="task2-admin-workstations"></a>Create dedicated workstation hosts without Internet and email access
Administrators need to manage job responsibilities that require sensitive administrator rights from a dedicated workstation because they do not have easy physical access to the servers. A workstation that is connected to the Internet and has email and web browsing access is regularly exposed to compromise through phishing, downloading, and other types of Internet attacks. Because of these threats, it is a best practice to set these administrators up by using workstations that are dedicated to administrative duties only, and not provide access to the Internet, including email and web browsing. For more information, see [Separate administrator accounts from user accounts](#task1-separate-admin-accounts).
> [!NOTE]
> If the administrators in your environment can sign in locally to managed servers and perform all tasks without elevated rights or domain rights from their workstation, you can skip this task.
- **Minimum**. Build dedicated administrative workstations and block Internet access on those workstations including web browsing and email. Use the following ways to block Internet access:
- Configure authenticating boundary proxy services, if they are deployed, to disallow administrator accounts from accessing the Internet.
- Configure boundary firewall or proxy services to disallow Internet access for the IP addresses that are assigned to dedicated administrative workstations.
- Block outbound access to the boundary proxy servers in the Windows Firewall.
The instructions for meeting this minimum requirement are described in the following procedure.
- **Better**. Do not grant administrators membership in the local Administrator group on the computer in order to restrict the administrator from bypassing these protections.
- **Ideal**. Restrict workstations from having any network connectivity, except for the domain controllers and servers that the administrator accounts are used to manage. Alternately, use AppLocker application control policies to restrict all applications from running, except for the operating system and approved administrative tools and applications. For more information about AppLocker, see [AppLocker](/windows/device-security/applocker/applocker-overview).
The following procedure describes how to block Internet access by creating a Group Policy Object (GPO) that configures an invalid proxy address on administrative workstations. These instructions apply only to computers running Internet Explorer and other Windows components that use these proxy settings.
> [!NOTE]
> In this procedure, the workstations are dedicated to domain administrators. By simply modifying the administrator accounts to grant permission to administrators to sign in locally, you can create additional OUs to manage administrators that have fewer administrative rights to use the instructions described in the following procedure.
**To install administrative workstations in a domain and block Internet and email access (minimum)**
1. As a domain administrator on a domain controller, open Active Directory Users and Computers, and create a new OU for administrative workstations.
2. Create computer accounts for the new workstations.
> [!NOTE]
> You might have to delegate permissions to join computers to the domain if the account that joins the workstations to the domain does not already have them. For more information, see [Delegation of Administration in Active Directory](https://social.technet.microsoft.com/wiki/contents/articles/20292.delegation-of-administration-in-active-directory.aspx).
![Active Directory local accounts](images/adlocalaccounts-proc1-sample1.gif)
3. Close Active Directory Users and Computers.
4. Start the **Group Policy Management** Console (GPMC).
5. Right-click the new OU, and &gt; **Create a GPO in this domain, and Link it here**.
![Active Directory's local accounts](images/adlocalaccounts-proc1-sample2.png)
6. Name the GPO, and &gt; **OK**.
7. Expand the GPO, right-click the new GPO, and &gt; **Edit**.
![Active Directory (AD) local accounts](images/adlocalaccounts-proc1-sample3.png)
8. Configure which members of accounts can log on locally to these administrative workstations as follows:
1. Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**.
2. Double-click **Allow log on locally**, and then select the **Define these policy settings** check box.
3. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
4. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
> [!IMPORTANT]
> These instructions assume that the workstation is to be dedicated to domain administrators.
5. Click **Add User or Group**, type **Administrators**, and &gt; **OK**.
![AD local accounts](images/adlocalaccounts-proc1-sample4.png)
9. Configure the proxy configuration:
1. Navigate to User Configuration\\Policies\\Windows Settings\\Internet Explorer, and &gt; **Connection**.
2. Double-click **Proxy Settings**, select the **Enable proxy settings** check box, type **127.0.0.1** (the network Loopback IP address) as the proxy address, and &gt; **OK**.
![AD's local accounts](images/adlocalaccounts-proc1-sample5.png)
10. Configure the loopback processing mode to enable the user Group Policy proxy setting to apply to all users on the computer as follows:
1. Navigate to Computer Configuration\\Policies\\Administrative Templates\\System, and &gt; **Group Policy**.
2. Double-click **User Group Policy loopback policy processing mode**, and &gt; **Enabled**.
3. Select **Merge Mode**, and &gt; **OK**.
11. Configure software updates as follows:
1. Navigate to Computer Configuration\\Policies\\Administrative Templates\\Windows Components, and then click **Windows Update**.
2. Configure Windows Update settings as described in the following table.
|Windows Update Setting|Configuration|
|--- |--- |
|Allow Automatic Updates immediate installation|Enabled|
|Configure Automatic Updates|Enabled4 - Auto download and schedule the installation0 - Every day 03:00|
|Enable Windows Update Power Management to automatically wake up the system to install scheduled updates|Enabled|
|Specify intranet Microsoft Update service location|Enabled `http://<WSUSServername> http://<WSUSServername>` Where `<WSUSServername>` is the DNS name or IP address of the Windows Server Update Services (WSUS) in the environment.|
|Automatic Updates detection frequency|6 hours|
|Re-prompt for restart with scheduled installations|1 minute|
|Delay restart for scheduled installations|5 minutes|
> [!NOTE]
> This step assumes that Windows Server Update Services (WSUS) is installed and configured in the environment. You can skip this step if you use another tool to deploy software updates. Also, if the public Microsoft Windows Update service only is used on the Internet, then these administrative workstations no longer receive updates.
12. Configure the inbound firewall to block all connections as follows:
1. Right-click **Windows Firewall with Advanced Security LDAP://path**, and &gt; **Properties**.
![Local accounts for Active Directory](images/adlocalaccounts-proc1-sample6.png)
2. On each profile, ensure that the firewall is enabled and that inbound connections are set to **Block all connections**.
![Local accounts for an AD](images/adlocalaccounts-proc1-sample7.png)
3. Click **OK** to complete the configuration.
13. Close the Group Policy Management Console.
14. Install the Windows operating system on the workstations, give each workstation the same names as the computer accounts assigned to them, and then join them to the domain.
### <a href="" id="task3-restrict-admin-logon"></a>Restrict administrator logon access to servers and workstations
It is a best practice to restrict administrators from using sensitive administrator accounts to sign in to lower-trust servers and workstations. This restriction prevents administrators from inadvertently increasing the risk of credential theft by signing in to a lower-trust computer.
> [!IMPORTANT]
> Ensure that you either have local access to the domain controller or that you have built at least one dedicated administrative workstation.
Restrict logon access to lower-trust servers and workstations by using the following guidelines:
- **Minimum**. Restrict domain administrators from having logon access to servers and workstations. Before starting this procedure, identify all OUs in the domain that contain workstations and servers. Any computers in OUs that are not identified will not restrict administrators with sensitive accounts from signing-in to them.
- **Better**. Restrict domain administrators from non-domain controller servers and workstations.
- **Ideal**. Restrict server administrators from signing in to workstations, in addition to domain administrators.
> [!NOTE]
> For this procedure, do not link accounts to the OU that contain workstations for administrators that perform administration duties only, and do not provide Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
**To restrict domain administrators from workstations (minimum)**
1. As a domain administrator, open the Group Policy Management Console (GPMC).
2. Open **Group Policy Management**, and expand *&lt;forest&gt;*\\Domains\\`<domain>`, and then expand to **Group Policy Objects**.
3. Right-click **Group Policy Objects**, and &gt; **New**.
![Local account's representation - Active Directory](images/adlocalaccounts-proc2-sample1.png)
4. In the **New GPO** dialog box, name the GPO that restricts administrators from signing in to workstations, and &gt; **OK**.
![Local account's representation - AD](images/adlocalaccounts-proc2-sample2.png)
5. Right-click **New GPO**, and &gt; **Edit**.
6. Configure user rights to deny logon locally for domain administrators.
7. Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**, and perform the following:
1. Double-click **Deny logon locally**, and &gt; **Define these policy settings**.
2. Click **Add User or Group**, click **Browse**, type **Enterprise Admins**, and &gt; **OK**.
3. Click **Add User or Group**, click **Browse**, type **Domain Admins**, and &gt; **OK**.
![An Active Directory's local accounts](images/adlocalaccounts-proc2-sample3.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
4. Click **OK** to complete the configuration.
8. Configure the user rights to deny batch and service logon rights for domain administrators as follows:
> [!NOTE]
> Completing this step might cause issues with administrator tasks that run as scheduled tasks or services with accounts in the Domain Admins group. The practice of using domain administrator accounts to run services and tasks on workstations creates a significant risk of credential theft attacks and therefore should be replaced with alternative means to run scheduled tasks or services.
1. Double-click **Deny logon as a batch job**, and &gt; **Define these policy settings**.
2. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
3. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
![An AD's local accounts](images/adlocalaccounts-proc2-sample4.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
4. Double-click **Deny logon as a service**, and &gt; **Define these policy settings**.
5. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
6. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
![Local accounts for AD](images/adlocalaccounts-proc2-sample5.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
9. Link the GPO to the first Workstations OU.
Navigate to the *&lt;forest&gt;*\\Domains\\`<domain>`\\OU Path, and then:
1. Right-click the workstation OU, and then &gt; **Link an Existing GPO**.
![Local accounts representation for an Active Directory](images/adlocalaccounts-proc2-sample6.png)
2. Select the GPO that you just created, and &gt; **OK**.
![Active Directory's local accounts' presentation](images/adlocalaccounts-proc2-sample7.png)
=======
![Active Directory local accounts 13](images/adlocalaccounts-proc2-sample6.png)
2. Select the GPO that you just created, and &gt; **OK**.
![Active Directory local accounts 14](images/adlocalaccounts-proc2-sample7.png)
10. Test the functionality of enterprise applications on workstations in the first OU and resolve any issues caused by the new policy.
11. Link all other OUs that contain workstations.
However, do not create a link to the Administrative Workstation OU if it is created for administrative workstations that are dedicated to administration duties only, and that are without Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations).
> [!IMPORTANT]
> If you later extend this solution, do not deny logon rights for the **Domain Users** group. The **Domain Users** group includes all user accounts in the domain, including Users, Domain Administrators, and Enterprise Administrators.
### <a href="" id="task4-disable-account-delegation"></a>Disable the account delegation right for sensitive administrator accounts
Although user accounts are not marked for delegation by default, accounts in an Active Directory domain can be trusted for delegation. This means that a service or a computer that is trusted for delegation can impersonate an account that authenticates to them to access other resources across the network.
For sensitive accounts, such as those belonging to members of the Administrators, Domain Admins, or Enterprise Admins groups in Active Directory, delegation can present a substantial risk of rights escalation. For example, if an account in the Domain Admins group is used to sign in to a compromised member server that is trusted for delegation, that server can request access to resources in the context of the Domain Admins account, and escalate the compromise of that member server to a domain compromise.
It is a best practice to configure the user objects for all sensitive accounts in Active Directory by selecting the **Account is sensitive and cannot be delegated** check box under **Account options** to prevent these accounts from being delegated. For more information, see [Setting for default local accounts in Active Directory](#sec-account-settings).
As with any configuration change, test this enabled setting fully to ensure that it performs correctly before you implement it.
![An Active Directory local accounts' presentation](images/adlocalaccounts-proc3-sample1.png)
## <a href="" id="sec-secure-manage-dcs"></a>Secure and manage domain controllers
It is a best practice to strictly enforce restrictions on the domain controllers in your environment. This ensures that the domain controllers:
1. Run only required software
2. Required software is regularly updated
3. Are configured with the appropriate security settings
One aspect of securing and managing domain controllers is to ensure that the default local user accounts are fully protected. It is of primary importance to restrict and secure all sensitive domain accounts, as described in the preceding sections.
Because domain controllers store credential password hashes of all accounts in the domain, they are high-value targets for malicious users. When domain controllers are not well managed and secured by using restrictions that are strictly enforced, they can be compromised by malicious users. For example, a malicious user could steal sensitive domain administrator credentials from one domain controller, and then use these credentials to attack the domain and forest.
In addition, installed applications and management agents on domain controllers might provide a path for escalating rights that malicious users can use to compromise the management service or administrators of that service. The management tools and services, which your organization uses to manage domain controllers and their administrators, are equally important to the security of the domain controllers and the domain administrator accounts. Ensure that these services and administrators are fully secured with equal effort.
## See also
- [Security Principals](security-principals.md)
- [Access Control Overview](access-control.md)

View File

@ -1,140 +0,0 @@
---
title: Dynamic Access Control Overview (Windows 10)
description: Learn about Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
ms.reviewer:
---
# Dynamic Access Control Overview
**Applies to**
- Windows Server 2016
This overview topic for the IT professional describes Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
Domain-based Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources.
For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a users permissions change dynamically without additional administrator intervention if the users job or role changes (resulting in changes to the users account attributes in AD DS). For more detailed examples of Dynamic Access Control in use, see the scenarios described in [Dynamic Access Control: Scenario Overview](/windows-server/identity/solution-guides/dynamic-access-control--scenario-overview).
Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.
Features and concepts associated with Dynamic Access Control include:
- [Central access rules](#bkmk-rules)
- [Central access policies](#bkmk-policies)
- [Claims](#bkmk-claims)
- [Expressions](#bkmk-expressions2)
- [Proposed permissions](#bkmk-permissions2)
### <a href="" id="bkmk-rules"></a>Central access rules
A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy.
If one or more central access rules have been defined for a domain, file share administrators can match specific rules to specific resources and business requirements.
### <a href="" id="bkmk-policies"></a>Central access policies
Central access policies are authorization policies that include conditional expressions. For example, lets say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:
- Identify and mark the files that contain the PII.
- Identify the group of HR members who are allowed to view the PII information.
- Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.
Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.
### <a href="" id="bkmk-claims"></a>Claims
A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The users title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources. The following types of claims are available in the supported versions of Windows:
- **User claims**   Active Directory attributes that are associated with a specific user.
- **Device claims**   Active Directory attributes that are associated with a specific computer object.
- **Resource attributes**  Global resource properties that are marked for use in authorization decisions and published in Active Directory.
Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.
### <a href="" id="bkmk-expressions2"></a>Expressions
Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions are managed through the Advanced Security Settings dialog box of the ACL Editor or the Central Access Rule Editor in the Active Directory Administrative Center (ADAC).
Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.
### <a href="" id="bkmk-permissions2"></a>Proposed permissions
Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them.
Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.
## Additional changes
Additional enhancements in the supported versions of Windows that support Dynamic Access Control include:
### Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.
By default, devices running any of the supported versions of Windows are able to process Dynamic Access Control-related Kerberos tickets, which include data needed for compound authentication. Domain controllers are able to issue and respond to Kerberos tickets with compound authentication-related information. When a domain is configured to recognize Dynamic Access Control, devices receive claims from domain controllers during initial authentication, and they receive compound authentication tickets when submitting service ticket requests. Compound authentication results in an access token that includes the identity of the user and the device on the resources that recognize Dynamic Access Control.
### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
### Support in Active Directory to store user and device claims, resource properties, and central access policy objects.
### Support for using Group Policy to deploy central access policy objects.
The following Group Policy setting enables you to deploy central access policy objects to file servers in your organization: **Computer Configuration\\Policies\\ Windows Settings\\Security Settings\\File System\\Central Access Policy**.
### Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing
You must enable staged central access policy auditing to audit the effective access of central access policy by using proposed permissions. You configure this setting for the computer under **Advanced Audit Policy Configuration** in the **Security Settings** of a Group Policy Object (GPO). After you configure the security setting in the GPO, you can deploy the GPO to computers in your network.
### Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts
You can filter or transform incoming and outgoing claims that traverse a forest trust. There are three basic scenarios for filtering and transforming claims:
- **Value-based filtering**  Filters can be based on the value of a claim. This allows the trusted forest to prevent claims with certain values from being sent to the trusting forest. Domain controllers in trusting forests can use value-based filtering to guard against an elevation-of-privilege attack by filtering the incoming claims with specific values from the trusted forest.
- **Claim type-based filtering**  Filters are based on the type of claim, rather than the value of the claim. You identify the claim type by the name of the claim. You use claim type-based filtering in the trusted forest, and it prevents Windows from sending claims that disclose information to the trusting forest.
- **Claim type-based transformation**  Manipulates a claim before sending it to the intended target. You use claim type-based transformation in the trusted forest to generalize a known claim that contains specific information. You can use transformations to generalize the claim-type, the claim value, or both.
## <a href="" id="software-requirements-"></a>Software requirements
Because claims and compound authentication for Dynamic Access Control require Kerberos authentication extensions, any domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows to support authentication from Dynamic Access Control-aware Kerberos clients. By default, devices must use domain controllers in other sites. If no such domain controllers are available, authentication will fail. Therefore, you must support one of the following conditions:
- Every domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows Server to support authentication from all devices running the supported versions of Windows or Windows Server.
- Devices running the supported versions of Windows or that do not protect resources by using claims or compound identity, should disable Kerberos protocol support for Dynamic Access Control.
For domains that support user claims, every domain controller running the supported versions of Windows server must be configured with the appropriate setting to support claims and compound authentication, and to provide Kerberos armoring. Configure settings in the KDC Administrative Template policy as follows:
- **Always provide claims**   Use this setting if all domain controllers are running the supported versions of Windows Server. In addition, set the domain functional level to Windows Server 2012 or higher.
- **Supported**   When you use this setting, monitor domain controllers to ensure that the number of domain controllers running the supported versions of Windows Server is sufficient for the number of client computers that need to access resources protected by Dynamic Access Control.
If the user domain and file server domain are in different forests, all domain controllers in the file servers forest root must be set at the Windows Server 2012 or higher functional level.
If clients do not recognize Dynamic Access Control, there must be a two-way trust relationship between the two forests.
If claims are transformed when they leave a forest, all domain controllers in the users forest root must be set at the Windows Server 2012 or higher functional level.
A file server running a server operating system that supports Dyamic Access Control must have a Group Policy setting that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is set by default to **Automatic**, which results in this Group Policy setting to be turned **On** if there is a central policy that contains user or device claims for that file server. If the file server contains discretionary ACLs that include user claims, you need to set this Group Policy to **On** so that the server knows to request claims on behalf of users that do not provide claims when they access the server.
## See also
- [Access control overview](access-control.md)

View File

@ -10,7 +10,7 @@ ms.collection:
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 02/28/2019
ms.date: 06/17/2022
---
# Local Accounts
@ -21,13 +21,13 @@ ms.date: 02/28/2019
- Windows Server 2019
- Windows Server 2016
This reference topic for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
This reference article for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
## <a href="" id="about-local-user-accounts-"></a>About local user accounts
Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
This topic describes the following:
This article describes the following:
- [Default local user accounts](#sec-default-accounts)
@ -57,9 +57,9 @@ For information about security principals, see [Security Principals](security-pr
The default local user accounts are built-in accounts that are created automatically when you install Windows.
After Windows is installed, the default local user accounts cannot be removed or deleted. In addition, default local user accounts do not provide access to network resources.
After Windows is installed, the default local user accounts can't be removed or deleted. In addition, default local user accounts don't provide access to network resources.
Default local user accounts are used to manage access to the local servers resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this topic.
Default local user accounts are used to manage access to the local servers resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this article.
Default local user accounts are described in the following sections.
@ -69,23 +69,23 @@ The default local Administrator account is a user account for the system adminis
The Administrator account has full control of the files, directories, services, and other resources on the local computer. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can take control of local resources at any time simply by changing the user rights and permissions.
The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled.
The default Administrator account can't be deleted or locked out, but it can be renamed or disabled.
From Windows 10, Windows 11 and Windows Server 2016, Windows setup disables the built-in Administrator account and creates another local account that is a member of the Administrators group. Members of the Administrators groups can run apps with elevated permissions without using the **Run as Administrator** option. Fast User Switching is more secure than using Runas or different-user elevation.
**Account group membership**
By default, the Administrator account is installed as a member of the Administrators group on the server. It is a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
By default, the Administrator account is installed as a member of the Administrators group on the server. It's a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed.
The Administrator account can't be deleted or removed from the Administrators group, but it can be renamed.
**Security considerations**
Because the Administrator account is known to exist on many versions of the Windows operating system, it is a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.
Because the Administrator account is known to exist on many versions of the Windows operating system, it's a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.
You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see [Disable or activate a local user account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732112(v=ws.11)) and [Rename a local user account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725595(v=ws.11)).
As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Do not use the Administrator account to sign in to your computer unless it is entirely necessary. For more information, see [Run a program with administrative credentials](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732200(v=ws.11)).
As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Don't use the Administrator account to sign in to your computer unless it's entirely necessary. For more information, see [Run a program with administrative credentials](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732200(v=ws.11)).
In comparison, on the Windows client operating system, a user with a local user account that has Administrator rights is considered the system administrator of the client computer. The first local user account that is created during installation is placed in the local Administrators group. However, when multiple users run as local administrators, the IT staff has no control over these users or their client computers.
@ -99,7 +99,7 @@ In this case, Group Policy can be used to enable secure settings that can contro
### <a href="" id="sec-guest"></a>Guest account
The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who do not have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it is a security risk. For this reason, it is a best practice to leave the Guest account disabled, unless its use is entirely necessary.
The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who don't have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it's a security risk. For this reason, it's a best practice to leave the Guest account disabled, unless its use is entirely necessary.
**Account group membership**
@ -107,26 +107,26 @@ By default, the Guest account is the only member of the default Guests group (SI
**Security considerations**
When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account shouldn't be used over the network and made accessible to other computers.
In addition, the guest user in the Guest account should not be able to view the event logs. After the Guest account is enabled, it is a best practice to monitor the Guest account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
In addition, the guest user in the Guest account shouldn't be able to view the event logs. After the Guest account is enabled, it's a best practice to monitor the Guest account frequently to ensure that other users can't use services and other resources. This includes resources that were unintentionally left available by a previous user.
## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the users invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it's initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the users invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
**Security considerations**
The SIDs that pertain to the default HelpAssistant account include:
- SID: S-1-5-&lt;domain&gt;-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
- SID: S-1-5-&lt;domain&gt;-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note: In Windows Server 2008, Remote Desktop Services are called Terminal Services.
- SID: S-1-5-&lt;domain&gt;-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
For the Windows Server operating system, Remote Assistance is an optional component that isn't installed by default. You must install Remote Assistance before it can be used.
For details about the HelpAssistant account attributes, see the following table.
@ -140,14 +140,14 @@ For details about the HelpAssistant account attributes, see the following table.
|Default members|None|
|Default member of|Domain Guests<br/><br/>Guests|
|Protected by ADMINSDHOLDER?|No|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to move out of default container?|Can be moved out, but we don't recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
### DefaultAccount
The DefaultAccount, also known as the Default System Managed Account (DSMA), is a built-in account introduced in Windows 10 version 1607 and Windows Server 2016.
The DSMA is a well-known user account type.
It is a user neutral account that can be used to run processes that are either multi-user aware or user-agnostic.
It's a user neutral account that can be used to run processes that are either multi-user aware or user-agnostic.
The DSMA is disabled by default on the desktop SKUs (full windows SKUs) and WS 2016 with the Desktop.
The DSMA has a well-known RID of 503. The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-\<ComputerIdentifier>-503
@ -167,24 +167,24 @@ Today, Xbox automatically signs in as Guest account and all apps run in this con
All the apps are multi-user-aware and respond to events fired by user manager.
The apps run as the Guest account.
Similarly, Phone auto logs in as a “DefApps” account which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
Similarly, Phone auto logs in as a “DefApps” account, which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
In the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context different from that of the users.
For this purpose, the system creates DSMA.
#### How the DefaultAccount gets created on domain controllers
If the domain was created with domain controllers that run Windows Server 2016, the DefaultAccount will exist on all domain controllers in the domain.
If the domain was created with domain controllers that run an earlier version of Windows Server, the DefaultAccount will be created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount will then be replicated to all other domain controllers in the domain.
If the domain was created with domain controllers running Windows Server 2016, the DefaultAccount will exist on all domain controllers in the domain.
If the domain was created with domain controllers running an earlier version of Windows Server, the DefaultAccount will be created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount will then be replicated to all other domain controllers in the domain.
#### Recommendations for managing the Default Account (DSMA)
Microsoft does not recommend changing the default configuration, where the account is disabled. There is no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
Microsoft doesn't recommend changing the default configuration, where the account is disabled. There's no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
## <a href="" id="sec-localsystem"></a>Default local system accounts
### SYSTEM
The SYSTEM account is used by the operating system and by services that run under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM accounts user rights. It is an internal account that does not show up in User Manager, and it cannot be added to any groups.
The SYSTEM account is used by the operating system and by services running under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM accounts user rights. It's an internal account that doesn't show up in User Manager, and it can't be added to any groups.
On the other hand, the SYSTEM account does appear on an NTFS file system volume in File Manager in the **Permissions** portion of the **Security** menu. By default, the SYSTEM account is granted Full Control permissions to all files on an NTFS volume. Here the SYSTEM account has the same functional rights and permissions as the Administrator account.
@ -200,22 +200,22 @@ The LOCAL SERVICE account is a predefined local account used by the service cont
## <a href="" id="sec-manage-accounts"></a>How to manage local user accounts
The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
The default local user accounts, and the local user accounts you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
You can use Local Users and Groups to assign rights and permissions on the local server, and that server only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
You can use Local Users and Groups to assign rights and permissions on only the local server to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
You cannot use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that are not domain controllers on the network.
You can't use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that aren't domain controllers on the network.
> [!NOTE]
> You use Active Directory Users and Computers to manage users and groups in Active Directory.
You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using a variety of PowerShell cmdlets and other scripting technologies.
You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using various PowerShell cmdlets and other scripting technologies.
### <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect local accounts with administrative rights
An administrator can use a number of approaches to prevent malicious users from using stolen credentials, such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights; this is also called "lateral movement".
An administrator can use many approaches to prevent malicious users from using stolen credentials such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights. This is also called "lateral movement".
The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks, for example, to browse the Internet, send email, or use a word processor. When you want to perform an administrative task, for example, to install a new program or to change a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks. For example, use a standard account to browse the Internet, send email, or use a word processor. When you want to perform administrative tasks such as installing a new program or changing a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
The other approaches that can be used to restrict and protect user accounts with administrative rights include:
@ -240,16 +240,18 @@ UAC makes it possible for an account with administrative rights to be treated as
In addition, UAC can require administrators to specifically approve applications that make system-wide changes before those applications are granted permission to run, even in the administrator's user session.
For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it is issued a standard user token with no administrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon cannot access administrative shares such as C$, or ADMIN$, or perform any remote administration.
For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it's issued a standard user token with no administrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon can't access administrative shares such as C$, or ADMIN$, or perform any remote administration.
For more information about UAC, see [User Account Control](/windows/access-protection/user-account-control/user-account-control-overview).
The following table shows the Group Policy and registry settings that are used to enforce local account restrictions for remote access.
<!-- MicrosoftDocs/windows-itpro-docs/issues/7146 start line 254-->
|No.|Setting|Detailed Description|
|--- |--- |--- |
||Policy location|Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options|
|1|Policy name|[User Account Control: Run all administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode)|
|1|Policy name|[User Account Control: Admin Approval Mode for the Built-in Administrator account](/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)|
||Policy setting|Enabled|
|2|Policy location|Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options|
||Policy name|[User Account Control: Run all administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode)|
@ -262,7 +264,6 @@ The following table shows the Group Policy and registry settings that are used t
> [!NOTE]
> You can also enforce the default for LocalAccountTokenFilterPolicy by using the custom ADMX in Security Templates.
#### To enforce local account restrictions for remote access
1. Start the **Group Policy Management** Console (GPMC).
@ -281,7 +282,7 @@ The following table shows the Group Policy and registry settings that are used t
![local accounts 3.](images/localaccounts-proc1-sample3.png)
6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by doing the following:
6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by following these steps:
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\, and &gt; **Security Options**.
@ -289,7 +290,7 @@ The following table shows the Group Policy and registry settings that are used t
3. Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** &gt; **Enabled** &gt; **OK**.
7. Ensure that the local account restrictions are applied to network interfaces by doing the following:
7. Ensure that the local account restrictions are applied to network interfaces by following these steps:
1. Navigate to Computer Configuration\\Preferences and Windows Settings, and &gt; **Registry**.
@ -301,7 +302,7 @@ The following table shows the Group Policy and registry settings that are used t
4. Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
5. Click (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
5. Select (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
6. In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
@ -321,7 +322,7 @@ The following table shows the Group Policy and registry settings that are used t
![local accounts 6.](images/localaccounts-proc1-sample6.png)
3. Select the GPO that you just created, and &gt; **OK**.
3. Select the GPO that you created, and &gt; **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
@ -331,7 +332,7 @@ The following table shows the Group Policy and registry settings that are used t
### <a href="" id="sec-deny-network-logon"></a>Deny network logon to all local Administrator accounts
Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that the credentials for local accounts that are stolen from a compromised operating system cannot be used to compromise additional computers that use the same credentials.
Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that stolen credentials for local accounts from a compromised operating system can't be used to compromise other computers that use the same credentials.
> [!NOTE]
> To perform this procedure, you must first identify the name of the local, default Administrator account, which might not be the default user name "Administrator", and any other accounts that are members of the local Administrators group.
@ -357,7 +358,7 @@ The following table shows the Group Policy settings that are used to deny networ
3. In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
4. In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it is being used to restrict the local administrative accounts from interactively signing in to the computer.
4. In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it's being used to restrict the local administrative accounts from interactively signing in to the computer.
![local accounts 7.](images/localaccounts-proc2-sample1.png)
@ -371,15 +372,15 @@ The following table shows the Group Policy settings that are used to deny networ
2. Double-click **Deny access to this computer from the network**.
3. Click **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
3. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
7. Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then click **User Rights Assignment**.
1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then select **User Rights Assignment**.
2. Double-click **Deny log on through Remote Desktop Services**.
3. Click **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
3. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
8. Link the GPO to the first **Workstations** OU as follows:
@ -387,7 +388,7 @@ The following table shows the Group Policy settings that are used to deny networ
2. Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
3. Select the GPO that you just created, and &gt; **OK**.
3. Select the GPO that you created, and &gt; **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
@ -401,9 +402,9 @@ The following table shows the Group Policy settings that are used to deny networ
### <a href="" id="sec-create-unique-passwords"></a>Create unique passwords for local accounts with administrative rights
Passwords should be unique per individual account. While this is generally true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
Passwords should be unique per individual account. While it's true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hampers the ability of malicious users to use password hashes of those accounts to compromise other computers.
Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hamper the ability of malicious users to use password hashes of those accounts to compromise other computers.
Passwords can be randomized by:

View File

@ -1,186 +0,0 @@
---
title: Microsoft Accounts (Windows 10)
description: Microsoft Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 10/13/2017
ms.reviewer:
---
# Microsoft Accounts
**Applies to**
- Windows 10
This topic for the IT professional explains how a Microsoft account works to enhance security and privacy for users, and how you can manage this consumer account type in your organization.
Microsoft sites, services, and properties, as well as computers running Windows 10, can use a Microsoft account as a means of identifying a user. Microsoft account was previously called Windows Live ID. It has user-defined secrets, and consists of a unique email address and a password.
When a user signs in with a Microsoft account, the device is connected to cloud services. Many of the user's settings, preferences, and apps can be shared across devices.
## <a href="" id="bkmk-benefits"></a>How a Microsoft account works
The Microsoft account allows users to sign in to websites that support this service by using a single set of credentials. Users' credentials are validated by a Microsoft account authentication server that is associated with a website. The Microsoft Store is an example of this association. When new users sign in to websites that are enabled to use Microsoft accounts, they are redirected to the nearest authentication server, which asks for a user name and password. Windows uses the Schannel Security Support Provider to open a Transport Level Security/Secure Sockets Layer (TLS/SSL) connection for this function. Users then have the option to use Credential Manager to store their credentials.
When users sign in to websites that are enabled to use a Microsoft account, a time-limited cookie is installed on their computers, which includes a triple DES encrypted ID tag. This encrypted ID tag has been agreed upon between the authentication server and the website. This ID tag is sent to the website, and the website plants another time-limited encrypted HTTP cookie on the users computer. When these cookies are valid, users are not required to supply a user name and password. If a user actively signs out of their Microsoft account, these cookies are removed.
**Important**  
Local Windows account functionality has not been removed, and it is still an option to use in managed environments.
### How Microsoft accounts are created
To prevent fraud, the Microsoft system verifies the IP address when a user creates an account. A user who tries to create multiple Microsoft accounts with the same IP address is stopped.
Microsoft accounts are not designed to be created in batches, such as for a group of domain users within your enterprise.
There are two methods for creating a Microsoft account:
- **Use an existing email address**.
Users are able to use their valid email addresses to sign up for Microsoft accounts. The service turns the requesting user's email address into a Microsoft account. Users can also choose their personal passwords.
- **Sign up for a Microsoft email address**.
Users can sign up for an email account with Microsoft's webmail services. This account can be used to sign in to websites that are enabled to use Microsoft accounts.
### How the Microsoft account information is safeguarded
Credential information is encrypted twice. The first encryption is based on the accounts password. Credentials are encrypted again when they are sent across the Internet. The data that is stored is not available to other Microsoft or non-Microsoft services.
- **Strong password is required**.
Blank passwords are not allowed.
For more information, see [How to help keep your Microsoft account safe and secure](https://support.microsoft.com/account-billing/how-to-help-keep-your-microsoft-account-safe-and-secure-628538c2-7006-33bb-5ef4-c917657362b9).
- **Secondary proof of identity is required**.
Before user profile information and settings can be accessed on a second supported Windows computer for the first time, trust must established for that device by providing secondary proof of identity. This can be accomplished by providing Windows with a code that is sent to a mobile phone number or by following the instructions that are sent to an alternate email address that a user specifies in the account settings.
- **All user profile data is encrypted on the client before it is transmitted to the cloud**.
User data does not roam over a wireless wide area network (WWAN) by default, thereby protecting profile data. All data and settings that leave a device are transmitted through the TLS/SSL protocol.
**Microsoft account security information is added**.
Users can add security information to their Microsoft accounts through the **Accounts** interface on computers running the supported versions of Windows. This feature allows the user to update the security information that they provided when they created their accounts. This security information includes an alternate email address or phone number so if their password is compromised or forgotten, a verification code can be sent to verify their identity. Users can potentially use their Microsoft accounts to store corporate data on a personal OneDrive or email app, so it is safe practice for the account owner to keep this security information up-to-date.
## <a href="" id="bkmk-msaccountintheenterprise"></a>The Microsoft account in the enterprise
Although the Microsoft account was designed to serve consumers, you might find situations where your domain users can benefit by using their personal Microsoft account in your enterprise. The following list describes some advantages.
- **Download Microsoft Store apps**:
If your enterprise chooses to distribute software through the Microsoft Store, your users can use their Microsoft accounts to download and use them on up to five devices running any version of Windows 10, Windows 8.1, Windows 8, or Windows RT.
- **Single sign-on**:
Your users can use Microsoft account credentials to sign in to devices running Windows 10, Windows 8.1, Windows 8 or Windows RT. When they do this, Windows works with your Microsoft Store app to provide authenticated experiences for them. Users can associate a Microsoft account with their sign-in credentials for Microsoft Store apps or websites, so that these credentials roam across any devices running these supported versions.
- **Personalized settings synchronization**:
Users can associate their most commonly used operating-system settings with a Microsoft account. These settings are available whenever a user signs in with that account on any device that is running a supported version of Windows and is connected to the cloud. After a user signs in, the device automatically attempts to get the user's settings from the cloud and apply them to the device.
- **App synchronization**:
Microsoft Store apps can store user-specific settings so that these settings are available to any device. As with operating system settings, these user-specific app settings are available whenever the user signs in with the same Microsoft account on any device that is running a supported version of Windows and is connected to the cloud. After the user signs in, that device automatically downloads the settings from the cloud and applies them when the app is installed.
- **Integrated social media services**:
Contact information and status for your users friends and associates automatically stay up-to-date from sites such as Hotmail, Outlook, Facebook, Twitter, and LinkedIn. Users can also access and share photos, documents, and other files from sites such as OneDrive, Facebook, and Flickr.
### Managing the Microsoft account in the domain
Depending on your IT and business models, introducing Microsoft accounts into your enterprise might add complexity or it might provide solutions. You should address the following considerations before you allow the use of these account types in your enterprise:
- [Restrict the use of the Microsoft account](#bkmk-restrictuse)
- [Configure connected accounts](#bkmk-cfgconnectedaccounts)
- [Provision Microsoft accounts in the enterprise](#bkmk-provisionaccounts)
- [Audit account activity](#bkmk-audit)
- [Perform password resets](#bkmk-passwordresets)
- [Restrict app installation and usage](#bkmk-restrictappinstallationandusage)
### <a href="" id="bkmk-restrictuse"></a>Restrict the use of the Microsoft account
The following Group Policy settings help control the use of Microsoft accounts in the enterprise:
- [Block all consumer Microsoft account user authentication](#block-all-consumer-microsoft-account-user-authentication)
- [Accounts: Block Microsoft accounts](#accounts-block-microsoft-accounts)
#### Block all consumer Microsoft account user authentication
This setting controls whether users can provide Microsoft accounts for authentication for applications or services.
If this setting is enabled, all applications and services on the device are prevented from using Microsoft accounts for authentication.
This applies both to existing users of a device and new users who may be added.
However, any application or service that has already authenticated a user will not be affected by enabling this setting until the authentication cache expires.
It is recommended to enable this setting before any user signs in to a device to prevent cached tokens from being present.
If this setting is disabled or not configured, applications and services can use Microsoft accounts for authentication.
By default, this setting is **Disabled**.
This setting does not affect whether users can sign in to devices by using Microsoft accounts, or the ability for users to provide Microsoft accounts via the browser for authentication with web-based applications.
The path to this setting is:
Computer Configuration\Administrative Templates\Windows Components\Microsoft account
#### Accounts: Block Microsoft accounts
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.
There are two options if this setting is enabled:
- **Users cant add Microsoft accounts** means that existing connected accounts can still sign in to the device (and appear on the Sign in screen). However, users cannot use the **Settings** app to add new connected accounts (or connect local accounts to Microsoft accounts).
- **Users cant add or log on with Microsoft accounts** means that users cannot add new connected accounts (or connect local accounts to Microsoft accounts) or use existing connected accounts through **Settings**.
This setting does not affect adding a Microsoft account for application authentication. For example, if this setting is enabled, a user can still provide a Microsoft account for authentication with an application such as **Mail**, but the user cannot use the Microsoft account for single sign-on authentication for other applications or services (in other words, the user will be prompted to authenticate for other applications or services).
By default, this setting is **Not defined**.
The path to this setting is:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
### <a href="" id="bkmk-cfgconnectedaccounts"></a>Configure connected accounts
Users can connect a Microsoft account to their domain account and synchronize the settings and preferences between them. This enables users to see the same desktop background, app settings, browser history and favorites, and other Microsoft account settings on their other devices.
Users can disconnect a Microsoft account from their domain account at any time as follows: In **PC settings**, tap or click **Users**, tap or click **Disconnect**, and then tap or click **Finish**.
**Note**  
Connecting Microsoft accounts with domain accounts can limit access to some high-privileged tasks in Windows. For example, Task Scheduler will evaluate the connected Microsoft account for access and fail. In these situations, the account owner should disconnect the account.
### <a href="" id="bkmk-provisionaccounts"></a>Provision Microsoft accounts in the enterprise
Microsoft accounts are private user accounts. There are no methods provided by Microsoft to provision Microsoft accounts for an enterprise. Enterprises should use domain accounts.
### <a href="" id="bkmk-audit"></a>Audit account activity
Because Microsoft accounts are Internet-based, Windows does not have a mechanism to audit their use until the account is associated with a domain account. But this association does not restrict the user from disconnecting the account or disjoining from the domain. It is not possible to audit the activity of accounts that are not associated with your domain.
### <a href="" id="bkmk-passwordresets"></a>Perform password resets
Only the owner of the Microsoft account can change the password. Passwords can be changed in the [Microsoft account sign-in portal](https://login.live.com).
### <a href="" id="bkmk-restrictappinstallationandusage"></a>Restrict app installation and usage
Within your organization, you can set application control policies to regulate app installation and usage for Microsoft accounts. For more information, see [AppLocker](/windows/device-security/applocker/applocker-overview) and [Packaged Apps and Packaged App Installer Rules in AppLocker](/windows/device-security/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker).
## See also
- [Managing Privacy: Using a Microsoft Account to Logon and Resulting Internet Communication](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj884082(v=ws.11))
- [Access Control Overview](access-control.md)

View File

@ -1,331 +0,0 @@
---
title: Security identifiers (Windows 10)
description: Security identifiers
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
---
# Security identifiers
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
This topic for the IT professional describes security identifiers and how they work in regards to accounts and groups in the Windows operating system.
## What are security identifiers?
A security identifier (SID) is used to uniquely identify a security principal or security group. Security principals can represent any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.
Each account or group, or process running in the security context of the account, has a unique SID that is issued by an authority, such as a Windows domain controller. It is stored in a security database. The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known SIDs have values that remain constant across all operating systems.
SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
The content in this topic applies to computers that are running the supported versions of the Windows operating system as designated in the **Applies To** list at the beginning of this topic.
## How security identifiers work
Users refer to accounts by using the account name, but the operating system internally refers to accounts and processes that run in the security context of the account by using their security identifiers (SIDs). For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they are never reused.
The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for a local account or group is generated by the Local Security Authority (LSA) on the computer, and it is stored with other account information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it is stored as an attribute of the User or Group object in Active Directory Domain Services.
For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for an account or group that is created in one domain will never match the SID for an account or group created in any other domain in the enterprise.
SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For example, if a user with a user account in a Windows domain leaves her job, an administrator deletes her Active Directory account, including the SID that identifies the account. If she later returns to a different job at the same company, an administrator creates a new account, and the Windows Server operating system generates a new SID. The new SID does not match the old one; so none of the user's access from her old account is transferred to the new account. Her two accounts represent two completely different security principals.
## Security identifier architecture
A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify the SID-issuing authority (for example, “NT Authority”), the SID-issuing domain, and a particular security principal or group. The following image illustrates the structure of a SID.
![Security identifier architecture.](images/security-identifider-architecture.jpg)
The individual values of a SID are described in the following table.
| Comment | Description |
| - | - |
| Revision | Indicates the version of the SID structure that is used in a particular SID. |
| Identifier authority | Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server account or group is 5 (NT Authority). |
| Subauthorities | >Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier. The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain. |
The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:
```
S-R-X-Y1-Y2-Yn-1-Yn
```
In this notation, the components of a SID are represented as shown in the following table.
| Comment | Description |
| - | - |
| S | Indicates that the string is a SID |
| R | Indicates the revision level |
| X | Indicates the identifier authority value |
| Y | Represents a series of subauthority values, where *n* is the number of values |
The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Y*n*-1) is the domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an enterprise share the same domain identifier.
The last item in the series of subauthority values (-Y*n*) is the relative identifier. It distinguishes one account or group from all other accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:
```
S-1-5-32-544
```
This SID has four components:
- A revision level (1)
- An identifier authority value (5, NT Authority)
- A domain identifier (32, Builtin)
- A relative identifier (544, Administrators)
SIDs for built-in accounts and groups always have the same domain identifier value: 32. This value identifies the domain **Builtin**, which exists on every computer that is running a version of the Windows Server operating system. It is never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups because they are local in scope. They are local to a single computer, or in the case of domain controllers for a network domain, they are local to several computers that are acting as one.
Built-in accounts and groups need to be distinguished from one another within the scope of the **Builtin** domain. Therefore, the SID for each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No other account or group in the **Builtin** domain has a SID with a final value of 544.
In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group, and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd. domain (Contoso\\Domain Admins):
```
S-1-5-21-1004336348-1177238915-682003330-512
```
The SID for Contoso\\Domain Admins has:
- A revision level (1)
- An identifier authority (5, NT Authority)
- A domain identifier (21-1004336348-1177238915-682003330, Contoso)
- A relative identifier (512, Domain Admins)
The SID for Contoso\\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for Contoso\\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
## Relative identifier allocation
When accounts and groups are stored in an account database that is managed by a local Security Accounts Manager (SAM), it is fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a stand-alone computer. The SAM on a stand-alone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network domain, there are as many copies of the account database as there are domain controllers. In addition to this, every copy of the account database is a master copy. New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account database to all other master copies is called a multimaster operation.
The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of relative identifier (RID) master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group is created in one domain controller's replica of Active Directory, it is assigned a SID. The relative identifier for the new SID is taken from the domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller requests another block from the RID master.
Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier values only once. This process assures that every account and group created in the domain has a unique relative identifier.
## Security identifiers and globally unique identifiers
When a new domain user or group account is created, Active Directory stores the account's SID in the **ObjectSID** property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not only User and Group objects. Each object's GUID is stored in its **ObjectGUID** property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by **ObjectGUID** might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the **ObjectGUID** property never changes. When an object is assigned a GUID, it keeps that value for life.
If a user moves from one domain to another, the user gets a new SID. The SID for a group object does not change because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for example, Contoso\\NoAm to Contoso\\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that is issued in NoAm is unique to NoAm; so the SID for the user's account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain; so if the domain changes, the relative identifier also changes.
When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the **ObjectSID** property. Before the new value is written to the property, the previous value is copied to another property of a User object, **SIDHistory**. This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the **ObjectSID** property, and another value is added to the list of old SIDs in **SIDHistory**. When a user signs in and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and they are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token (including one of the SIDs in **SIDHistory**), can allow or deny the user access.
If you allow or deny users' access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others.
However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The **SIDHistory** property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in the user's access token. It is listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.
## Well-known SIDs
The values of certain SIDs are constant across all systems. They are created when the operating system or domain is installed. They are called well-known SIDs because they identify generic users or generic groups.
There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.
The following table lists the universal well-known SIDs.
| Value | Universal Well-Known SID | Identifies |
| - | - | - |
| S-1-0-0 | Null SID | A group with no members. This is often used when a SID value is not known.|
| S-1-1-0 | World | A group that includes all users. |
| S-1-2-0 | Local | Users who log on to terminals that are locally (physically) connected to the system. |
| S-1-2-1 | Console Logon | A group that includes users who are logged on to the physical console. |
| S-1-3-0 | Creator Owner ID | A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable ACEs. |
| S-1-3-1 | Creator Group ID | A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable ACEs. |
| S-1-3-2 | Creator Owner Server | |
| S-1-3-3 | Creator Group Server | |
| S-1-3-4 | Owner Rights | A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner. |
| S-1-4 | Non-unique Authority | A SID that represents an identifier authority. |
| S-1-5 | NT Authority | A SID that represents an identifier authority. |
| S-1-5-80-0 | All Services | A group that includes all service processes configured on the system. Membership is controlled by the operating system.|
The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the rest of the values are used with well-known SIDs in Windows operating systems designated in the **Applies To** list.
| Identifier Authority | Value | SID String Prefix |
| - | - | - |
| SECURITY_NULL_SID_AUTHORITY | 0 | S-1-0 |
| SECURITY_WORLD_SID_AUTHORITY | 1 | S-1-1 |
| SECURITY_LOCAL_SID_AUTHORITY | 2 | S-1-2 |
| SECURITY_CREATOR_SID_AUTHORITY | 3 | S-1-3 |
| SECURITY_NT_AUTHORITY | 5 | S-1-5 |
| SECURITY_AUTHENTICATION_AUTHORITY | 18 | S-1-18 |
The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier authority with which you can combine the RID to create a universal well-known SID.
| Relative Identifier Authority | Value | Identifier Authority |
| - | - | - |
| SECURITY_NULL_RID | 0 | S-1-0 |
| SECURITY_WORLD_RID | 0 | S-1-1 |
| SECURITY_LOCAL_RID | 0 | S-1-2 |
| SECURITY_CREATOR_OWNER_RID | 0 | S-1-3 |
| SECURITY_CREATOR_GROUP_RID | 1 | S-1-3 |
The SECURITY\_NT\_AUTHORITY (S-1-5) predefined identifier authority produces SIDs that are not universal and are meaningful only in installations of the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic. The following table lists the well-known SIDs.
| SID | Display Name | Description |
| - | - | - |
| S-1-5-1 | Dialup | A group that includes all users who are logged on to the system by means of a dial-up connection.|
| S-1-5-113 | Local account| You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named.|
| S-1-5-114| Local account and member of Administrators group | You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. |
| S-1-5-2 | Network | A group that includes all users who are logged on by means of a network connection. Access tokens for interactive users do not contain the Network SID.|
| S-1-5-3 | Batch | A group that includes all users who have logged on by means of a batch queue facility, such as task scheduler jobs.|
| S-1-5-4 | Interactive| A group that includes all users who log on interactively. A user can start an interactive logon session by logging on directly at the keyboard, by opening a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services connection, the user's access token also contains the Remote Interactive Logon SID.|
| S-1-5-5- *X*-*Y* | Logon Session| The *X* and *Y* values for these SIDs uniquely identify a particular logon session.|
| S-1-5-6 | Service| A group that includes all security principals that have signed in as a service.|
| S-1-5-7 | Anonymous Logon| A user who has connected to the computer without supplying a user name and password.<br/>The Anonymous Logon identity is different from the identity that is used by Internet Information Services (IIS) for anonymous web access. IIS uses an actual account—by default, IUSR_ *ComputerName*, for anonymous access to resources on a website. Strictly speaking, such access is not anonymous because the security principal is known even though unidentified people are using the account. IUSR_ *ComputerName* (or whatever you name the account) has a password, and IIS logs on the account when the service starts. As a result, the IIS "anonymous" user is a member of Authenticated Users but Anonymous Logon is not.|
| S-1-5-8| Proxy| Does not currently apply: this SID is not used.|
| S-1-5-9 | Enterprise Domain Controllers| A group that includes all domain controllers in a forest of domains.|
| S-1-5-10 | Self| A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal that is represented by the object.|
| S-1-5-11 | Authenticated Users| A group that includes all users and computers with identities that have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.<br/>This group includes authenticated security principals from any trusted domain, not only the current domain.|
| S-1-5-12 | Restricted Code| An identity that is used by a process that is running in a restricted security context. In Windows and Windows Server operating systems, a software restriction policy can assign one of three security levels to code: unrestricted, restricted, or disallowed. When code runs at the restricted security level, the Restricted SID is added to the user's access token.|
| S-1-5-13 | Terminal Server User| A group that includes all users who sign in to a server with Remote Desktop Services enabled.|
| S-1-5-14 | Remote Interactive Logon| A group that includes all users who log on to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.|
| S-1-5-15| This Organization| A group that includes all users from the same organization. Only included with Active Directory accounts and only added by a domain controller.|
| S-1-5-17 | IUSR| An account that is used by the default Internet Information Services (IIS) user.|
| S-1-5-18 | System (or LocalSystem)| An identity that is used locally by the operating system and by services that are configured to sign in as LocalSystem.<br/>System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in Administrators group in its access token.<br/>When a process that is running locally as System accesses network resources, it does so by using the computer's domain identity. Its access token on the remote computer includes the SID for the local computer's domain account plus SIDs for security groups that the computer is a member of, such as Domain Computers and Authenticated Users.|
| S-1-5-19 | NT Authority (LocalService)| An identity that is used by services that are local to the computer, have no need for extensive local access, and do not need authenticated network access. Services that run as LocalService access local resources as ordinary users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has significantly less authority than a service that runs as LocalSystem locally and on the network.|
| S-1-5-20 | Network Service| An identity that is used by services that have no need for extensive local access but do need authenticated network access. Services running as NetworkService access local resources as ordinary users and access network resources by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as a service that runs as LocalSystem, but it has significantly reduced local access.|
| S-1-5-*domain*-500 | Administrator| A user account for the system administrator. Every computer has a local Administrator account and every domain has a domain Administrator account.<br/>The Administrator account is the first account created during operating system installation. The account cannot be deleted, disabled, or locked out, but it can be renamed.<br/>By default, the Administrator account is a member of the Administrators group, and it cannot be removed from that group.|
| S-1-5-*domain*-501 | Guest| A user account for people who do not have individual accounts. Every computer has a local Guest account, and every domain has a domain Guest account.<br/>By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a member of the Domain Guests and Domain Users groups.<br/>Unlike Anonymous Logon, Guest is a real account, and it can be used to log on interactively. The Guest account does not require a password, but it can have one.|
| S-1-5-*domain*-502| krbtgt| A user account that is used by the Key Distribution Center (KDC) service. The account exists only on domain controllers.|
| S-1-5-*domain*-512| Domain Admins| A global group with members that are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined the domain, including domain controllers.<br/>Domain Admins is the default owner of any object that is created in the domain's Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.|
| S-1-5-*domain*-513| Domain Users| A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.|
| S-1-5-*domain*-514| Domain Guests| A global group, which by default, has only one member: the domain's built-in Guest account.|
| S-1-5-*domain*-515 | Domain Computers| A global group that includes all computers that have joined the domain, excluding domain controllers.|
| S-1-5-*domain*-516| Domain Controllers| A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically.|
| S-1-5-*domain*-517 | Cert Publishers| A global group that includes all computers that host an enterprise certification authority.<br/>Cert Publishers are authorized to publish certificates for User objects in Active Directory.|
| S-1-5-*root domain*-518| Schema Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.|
| S-1-5-*root domain*-519| Enterprise Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode.<br/>The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities.<br/>By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The group is a default member of every Domain Admins group in the forest. |
| S-1-5-*domain*-520| Group Policy Creator Owners| A global group that is authorized to create new Group Policy Objects in Active Directory. By default, the only member of the group is Administrator.<br/>Objects that are created by members of Group Policy Creator Owners are owned by the individual user who creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as Administrators and Domain Admins). Objects that are created by members of these groups are owned by the group rather than by the individual.|
| S-1-5-*domain*-553| RAS and IAS Servers| A local domain group. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically.<br/>Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.|
| S-1-5-32-544 | Administrators| A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.|
| S-1-5-32-545 | Users| A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group.|
| S-1-5-32-546 | Guests| A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.|
| S-1-5-32-547 | Power Users| A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares. |
| S-1-5-32-548| Account Operators| A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.|
| S-1-5-32-549| Server Operators| Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.|
| S-1-5-32-550 | Print Operators| A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.|
| S-1-5-32-551 | Backup Operators| A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down.|
| S-1-5-32-552 | Replicators | A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.|
|S-1-5-32-554|Builtin\Pre-Windows 2000 Compatible Access|An alias added by Windows 2000. A backward compatibility group that allows read access on all users and groups in the domain.|
|S-1-5-32-555|Builtin\Remote Desktop Users|An alias. Members in this group are granted the right to log on remotely.|
|S-1-5-32-556|Builtin\Network Configuration Operators|An alias. Members in this group can have some administrative privileges to manage configuration of networking features.|
|S-1-5-32-557|Builtin\Incoming Forest Trust Builders|An alias. Members of this group can create incoming, one-way trusts to this forest.|
|S-1-5-32-558|Builtin\Performance Monitor Users|An alias. Members of this group have remote access to monitor this computer.|
|S-1-5-32-559|Builtin\Performance Log Users|An alias. Members of this group have remote access to schedule logging of performance counters on this computer.|
|S-1-5-32-560|Builtin\Windows Authorization Access Group|An alias. Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects.|
|S-1-5-32-561|Builtin\Terminal Server License Servers|An alias. A group for Terminal Server License Servers. When Windows Server 2003 Service Pack 1 is installed, a new local group is created.|
|S-1-5-32-562|Builtin\Distributed COM Users|An alias. A group for COM to provide computer-wide access controls that govern access to all call, activation, or launch requests on the computer.|
|S-1-5-32-568|Builtin\IIS_IUSRS|An alias. A built-in group account for IIS users.|
|S-1-5-32-569|Builtin\Cryptographic Operators|A built-in local group. Members are authorized to perform cryptographic operations.|
|S-1-5-32-573|Builtin\Event Log Readers|A built-in local group. Members of this group can read event logs from local computer.|
|S-1-5-32-574|Builtin\Certificate Service DCOM Access|A built-in local group. Members of this group are allowed to connect to Certification Authorities in the enterprise.|
|S-1-5-32-575|Builtin\RDS Remote Access Servers|A built-in local group. Servers in this group enable users of RemoteApp programs and personal virtual desktops access to these resources. In Internet-facing deployments, these servers are typically deployed in an edge network. This group needs to be populated on servers running RD Connection Broker. RD Gateway servers and RD Web Access servers used in the deployment need to be in this group.|
|S-1-5-32-576|Builtin\RDS Endpoint Servers|A built-in local group. Servers in this group run virtual machines and host sessions where users RemoteApp programs and personal virtual desktops run. This group needs to be populated on servers running RD Connection Broker. RD Session Host servers and RD Virtualization Host servers used in the deployment need to be in this group.|
|S-1-5-32-577|Builtin\RDS Management Servers|A builtin local group. Servers in this group can perform routine administrative actions on servers running Remote Desktop Services. This group needs to be populated on all servers in a Remote Desktop Services deployment. The servers running the RDS Central Management service must be included in this group.|
|S-1-5-32-578|Builtin\Hyper-V Administrators|A built-in local group. Members of this group have complete and unrestricted access to all features of Hyper-V.|
|S-1-5-32-579|Builtin\Access Control Assistance Operators|A built-in local group. Members of this group can remotely query authorization attributes and permissions for resources on this computer.|
|S-1-5-32-580|Builtin\Remote Management Users|A built-in local group. Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.|
| S-1-5-64-10| NTLM Authentication| A SID that is used when the NTLM authentication package authenticated the client|
| S-1-5-64-14 | SChannel Authentication| A SID that is used when the SChannel authentication package authenticated the client.|
| S-1-5-64-21 | Digest Authentication| A SID that is used when the Digest authentication package authenticated the client.|
| S-1-5-80 | NT Service | A SID that is used as an NT Service account prefix.|
| S-1-5-80-0 | All Services| A group that includes all service processes that are configured on the system. Membership is controlled by the operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server 2008 R2.|
| S-1-5-83-0| NT VIRTUAL MACHINE\Virtual Machines| A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained by the Hyper-V Management Service (VMMS). This group requires the **Create Symbolic Links** right (SeCreateSymbolicLinkPrivilege), and also the **Log on as a Service** right (SeServiceLogonRight). |
The following RIDs are relative to each domain.
| RID |Decimal value| Identifies |
| - | - | - |
| DOMAIN_USER_RID_ADMIN | 500 | The administrative user account in a domain. |
| DOMAIN_USER_RID_GUEST| 501 | The guest-user account in a domain. Users who do not have an account can automatically sign in to this account.|
| DOMAIN_GROUP_RID_USERS | 513 | A group that contains all user accounts in a domain. All users are automatically added to this group.|
| DOMAIN_GROUP_RID_GUESTS | 514 | The group Guest account in a domain.|
| DOMAIN_GROUP_RID_COMPUTERS | 515 | The Domain Computer group. All computers in the domain are members of this group.|
| DOMAIN_GROUP_RID_CONTROLLERS | 516 | The Domain Controller group. All domain controllers in the domain are members of this group.|
| DOMAIN_GROUP_RID_CERT_ADMINS | 517 | The certificate publishers' group. Computers running Active Directory Certificate Services are members of this group.|
| DOMAIN_GROUP_RID_SCHEMA_ADMINS | 518 | The schema administrators' group. Members of this group can modify the Active Directory schema.|
| DOMAIN_GROUP_RID_ENTERPRISE_ADMINS | 519 | The enterprise administrators' group. Members of this group have full access to all domains in the Active Directory forest. Enterprise administrators are responsible for forest-level operations such as adding or removing new domains.|
| DOMAIN_GROUP_RID_POLICY_ADMINS| 520 | The policy administrators' group.|
The following table provides examples of domain-relative RIDs that are used to form well-known SIDs for local groups.
| RID | Decimal value | Identifies |
| - | - | - |
| DOMAIN_ALIAS_RID_ADMINS | 544 | Administrators of the domain.|
| DOMAIN_ALIAS_RID_USERS | 545 | All users in the domain.|
| DOMAIN_ALIAS_RID_GUESTS | 546 | Guests of the domain.|
| DOMAIN_ALIAS_RID_POWER_USERS | 547 | A user or a set of users who expect to treat a system as if it were their personal computer rather than as a workstation for multiple users.|
| DOMAIN_ALIAS_RID_BACKUP_OPS | 551 | A local group that is used to control the assignment of file backup-and-restore user rights.|
| DOMAIN_ALIAS_RID_REPLICATOR | 552 | A local group that is responsible for copying security databases from the primary domain controller to the backup domain controllers. These accounts are used only by the system.|
| DOMAIN_ALIAS_RID_RAS_SERVERS | 553 | A local group that represents remote access and servers running Internet Authentication Service (IAS). This group permits access to various attributes of User objects.|
## Changes in security identifier's functionality
The following table describes changes in SID implementation in the Windows operating systems that are designated in the list.
| Change | Operating system version | Description and resources |
| - | - | - |
| Most of the operating system files are owned by the TrustedInstaller security identifier (SID)| Windows Server 2008, Windows Vista| The purpose of this change is to prevent a process that is running as an administrator or under the LocalSystem account from automatically replacing the operating system files. |
| Restricted SID checks are implemented| Windows Server 2008, Windows Vista| When restricting SIDs are present, Windows performs two access checks. The first is the normal access check, and the second is the same access check against the restricting SIDs in the token. Both access checks must pass to allow the process to access the object. |
## Capability SIDs
Capability Security Identifiers (SIDs) are used to uniquely and immutably identify capabilities. Capabilities represent an unforgeable token of authority that grants access to resources (Examples: documents, camera, locations etc...) to Universal Windows Applications. An App that “has” a capability is granted access to the resource the capability is associated with, and one that “does not have” a capability is denied access to the resource.
All Capability SIDs that the operating system is aware of are stored in the Windows Registry in the path `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities'. Any Capability SID added to Windows by first or third-party applications will be added to this location.
## Examples of registry keys taken from Windows 10, version 1909, 64-bit Enterprise edition
You may see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_Internal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All Capability SIDs are prefixed by S-1-15-3
## Examples of registry keys taken from Windows 11, version 21H2, 64-bit Enterprise edition
You may see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_Internal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All Capability SIDs are prefixed by S-1-15-3
## See also
- [Access Control Overview](access-control.md)

View File

@ -1,148 +0,0 @@
---
title: Security Principals (Windows 10)
description: Security Principals
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
ms.reviewer:
---
# Security Principals
**Applies to**
- Windows 10
- Windows Server 2016
This reference topic for the IT professional describes security principals in regards to Windows accounts and security groups, in addition to security technologies that are related to security principals.
## <a href="" id="w2k3tr-princ-what"></a>What are security principals?
Security principals are any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, or the security groups for these accounts. Security principals have long been a foundation for controlling access to securable resources on Windows computers. Each security principal is represented in the operating system by a unique security identifier (SID).
The following content applies to the versions of Windows that are designated in the **Applies To** list at the beginning of this topic.
## How security principals work
Security principals that are created in an Active Directory domain are Active Directory objects, which can be used to manage access to domain resources. Each security principal is assigned a unique identifier, which it retains for its entire lifetime. Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are managed by the Security Accounts Manager (SAM) on the local computer.
### <a href="" id="bkmk-authzandac"></a>Authorization and access control components
The following diagram illustrates the Windows authorization and access control process. In this diagram, the subject (a process that is initiated by a user) attempts to access an object, such as a shared folder. The information in the users access token is compared to the access control entries (ACEs) in the objects security descriptor, and the access decision is made. The SIDs of security principals are used in the users access token and in the ACEs in the objects security descriptor.
**Authorization and access control process**
![authorization and access control process.](images/authorizationandaccesscontrolprocess.gif)
Security principals are closely related to the following components and technologies:
- [Security identifiers](#bkmk-sids)
- [Access tokens](#bkmk-accesstokens)
- [Security descriptors and access control lists](#bkmk-sdandacls)
- [Permissions](#bkmk-permissions)
### <a href="" id="bkmk-sids"></a>Security identifiers
Security identifiers (SIDs) provide a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
A SID is a value of variable length that is used to uniquely identify a security principal that represents any entity that can be authenticated by the system. These entities include a user account, a computer account, or a thread or process that runs in the security context of a user or computer account. Each security principal is automatically assigned a SID when it is created. The SID is stored in a security database. When a SID is used as the unique identifier for a user or group, it can never be used to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the users SID, user rights, and the SIDs for groups that the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and the World SIDs identify groups that includes all users. Well-known SIDs have values that remain constant across all operating systems.
### <a href="" id="bkmk-accesstokens"></a>Access tokens
An access token is a protected object that contains information about the identity and user rights that are associated with a user account.
When a user signs in interactively or tries to make a network connection to a computer running Windows, the sign-in process authenticates the users credentials. If authentication is successful, the process returns a SID for the user and a list of SIDs for the users security groups. The Local Security Authority (LSA) on the computer uses this information to create an access token (in this case, the primary access token). This includes the SIDs that are returned by the sign-in process and a list of user rights that are assigned by the local security policy to the user and to the users security groups.
After the LSA creates the primary access token, a copy of the access token is attached to every thread and process that executes on the users behalf. Whenever a thread or process interacts with a securable object or tries to perform a system task that requires user rights, the operating system checks the access token that is associated with the thread to determine the level of authorization.
There are two kinds of access tokens, primary and impersonation. Every process has a primary token that describes the security context of the user account that is associated with the process. A primary access token is typically assigned to a process to represent the default security information for that process. Impersonation tokens, on the other hand, are usually used for client and server scenarios. Impersonation tokens enable a thread to run in a security context that differs from the security context of the process that owns the thread.
### <a href="" id="bkmk-sdandacls"></a>Security descriptors and access control lists
A security descriptor is a data structure that is associated with each securable object. All objects in Active Directory and all securable objects on a local computer or on the network have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An objects security descriptor can contain two types of ACLs:
- A discretionary access control list (DACL), which identifies the users and groups who are allowed or denied access
- A system access control list (SACL), which controls how access is audited
You can use this access control model to individually secure objects and attributes such as files and folders, Active Directory objects, registry keys, printers, devices, ports, services, processes, and threads. Because of this individual control, you can adjust the security of objects to meet the needs of your organization, delegate authority over objects or attributes, and create custom objects or attributes that require unique security protections to be defined.
### <a href="" id="bkmk-permissions"></a>Permissions
Permissions enable the owner of each securable object, such as a file, Active Directory object, or registry key, to control who can perform an operation or a set of operations on the object or object property. Permissions are expressed in the security architecture as access control entries (ACEs). Because access to an object is at the discretion of the objects owner, the type of access control that is used in Windows is called discretionary access control.
Permissions are different from user rights in that permissions are attached to objects, and user rights apply to user accounts. Administrators can assign user rights to groups or users. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
On computers, user rights enable administrators to control who has the authority to perform operations that affect an entire computer, rather than a particular object. Administrators assign user rights to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. Users can (and usually do) have different user rights on different computers.
For information about which user rights are available and how they can be implemented, see [User Rights Assignment](/windows/device-security/security-policy-settings/user-rights-assignment).
### <a href="" id="bkmk-authn"></a> Security context in authentication
A user account enables a user to sign in to computers, networks, and domains with an identity that can be authenticated by the computer, network, or domain.
In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based. For example, domain-joined Windows client computers can participate in a network domain by communicating with a domain controller, even when no user is signed in.
To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the Local Security Authority on the domain controller authenticates the computers identity and then defines the computers security context just as it would for a users security principal.
This security context defines the identity and capabilities of a user or service on a particular computer, or of a user, service, group or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, service, or computer on that resource.
The security context of a user or computer can vary from one computer to another, such as when a user authenticates to a server or a workstation other than the users primary workstation. It can also vary from one session to another, such as when an administrator modifies the users rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain.
## <a href="" id="w2k3tr-princ-what-vblj"></a>Accounts and security groups
Accounts and security groups that are created in an Active Directory domain are stored in the Active Directory database and managed by using Active Directory tools. These security principals are directory objects, and they can be used to manage access to domain resources.
Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are stored in and managed by the Security Accounts Manager (SAM) on the local computer.
### User accounts
A user account uniquely identifies a person who is using a computer system. The account signals the system to enforce the appropriate authorization to allow or deny that user access to resources. User accounts can be created in Active Directory and on local computers, and administrators use them to:
- Represent, identify, and authenticate the identity of a user. A user account enables a user to sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
- Authorize (grant or deny) access to resources. After a user has been authenticated, the user is authorized access to resources based on the permissions that are assigned to that user for the resource.
- Audit the actions that are carried out on a user account.
Windows and the Windows Server operating systems have built-in user accounts, or you can create user accounts to meet the requirements of your organization.
### Security groups
A security group is a collection of user accounts, computer accounts, and other groups of accounts that can be managed as a single unit from a security perspective. In Windows operating systems, there are several built-in security groups that are preconfigured with the appropriate rights and permissions for performing specific tasks. Additionally, you can (and, typically, will) create a security group for each unique combination of security requirements that applies to multiple users in your organization.
Groups can be Active Directory-based or local to a particular computer:
- Active Directory security groups are used to manage rights and permissions to domain resources.
- Local groups exist in the SAM database on local computers (on all Windows-based computers) except domain controllers. You use local groups to manage rights and permissions only to resources on the local computer.
By using security groups to manage access control, you can:
- Simplify administration. You can assign a common set of rights, a common set of permissions, or both to many accounts at one time, rather than assigning them to each account individually. Also, when users transfer jobs or leave the organization, permissions are not tied to their user accounts, making permission reassignment or removal easier.
- Implement a role-based access-control model. You can use this model to grant permissions by using groups with different scopes for appropriate purposes. Scopes that are available in Windows include local, global, domain local, and universal.
- Minimize the size of access control lists (ACLs) and speed security checking. A security group has its own SID; therefore, the group SID can be used to specify permissions for a resource. In an environment with more than a few thousand users, if the SIDs of individual user accounts are used to specify access to a resource, the ACL of that resource can become unmanageably large, and the time that is needed for the system to check permissions to the resource can become unacceptable.
For descriptions and settings information about the domain security groups that are defined in Active Directory, see [Active Directory Security Groups](active-directory-security-groups.md).
For descriptions and settings information about the Special Identities group, see [Special Identities](special-identities.md).
## See also
- [Access Control Overview](access-control.md)

View File

@ -1,112 +0,0 @@
---
title: Service Accounts (Windows 10)
description: Service Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 11/19/2021
---
# Service Accounts
**Applies to**
- Windows 10
- Windows Server 2016
This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.
## Overview
A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service's ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.
This topic contains information about the following types of service accounts:
- [Standalone managed service accounts](#bkmk-standalonemanagedserviceaccounts)
- [Group-managed service accounts](#bkmk-groupmanagedserviceaccounts)
- [Virtual accounts](#bkmk-virtualserviceaccounts)
### <a href="" id="bkmk-standalonemanagedserviceaccounts"></a>Standalone managed service accounts
A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.
To use managed service accounts, the server on which the application or service is installed must be running at least Windows Server 2008 R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group-managed service account. For more information, see [Group-Managed Service Accounts Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)).
In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:
- You can create a class of domain accounts that can be used to manage and maintain services on local computers.
- Unlike domain accounts in which administrators must manually reset passwords, the network passwords for these accounts are automatically reset.
- You do not have to complete complex SPN management tasks to use managed service accounts.
- You don't have to complete complex SPN management tasks to use managed service accounts.
- Administrative tasks for managed service accounts can be delegated to non-administrators.
### Software requirements
Managed service accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
### <a href="" id="bkmk-groupmanagedserviceaccounts"></a>Group-managed service accounts
Group-managed service accounts are an extension of the standalone-managed service accounts, which were introduced in Windows Server 2008 R2. These accounts are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.
The group-managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group-managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.
The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group-managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group-managed service account.
### <a href="" id="bkmk-app"></a>Practical applications
Group-managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group-managed service account solution, services can be configured for the group-managed service account principal, and the password management is handled by the operating system.
By using a group-managed service account, service administrators do not need to manage password synchronization between service instances. The group-managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This provision means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
Failover clusters do not support group-managed service accounts. However, services that run on top of the Cluster service can use a group-managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group-managed service account or standalone managed service accounts.
### <a href="" id="bkmk-soft"></a>Software requirements
Group-managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.
A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group-managed service accounts.
A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the accounts **msDS-SupportedEncryptionTypes** attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) must always be configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.
**Note**  
Introduced in Windows Server 2008 R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see [Changes in Kerberos Authentication](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd560670(v=ws.10)).
Group-managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.
### <a href="" id="bkmk-virtualserviceaccounts"></a>Virtual accounts
Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7, and are managed local accounts that provide the following features to simplify service administration:
- The virtual account is automatically managed.
- The virtual account can access the network in a domain environment.
- No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows Server 2008 R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\\&lt;SERVICENAME&gt;.
Services that run as virtual accounts access network resources by using the credentials of the computer account in the format &lt;domain\_name&gt;\\&lt;computer\_name&gt;$.
For information about how to configure and use virtual service accounts, see [Service Accounts Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd548356(v=ws.10)).
### Software requirements
Virtual accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
## <a href="" id="bkmk-links"></a>See also
The following table provides links to other resources that are related to standalone managed service accounts, group-managed service accounts, and virtual accounts.
| Content type | References |
|---------------|-------------|
| **Product evaluation** | [What's New for Managed Service Accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831451(v=ws.11))<br>[Getting Started with Group Managed Service Accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)) |
| **Deployment** | [Windows Server 2012: Group Managed Service Accounts - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs](https://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx) |
| **Related technologies** | [Security Principals](security-principals.md)<br>[What's new in Active Directory Domain Services](/windows-server/identity/whats-new-active-directory-domain-services) |

View File

@ -1,495 +0,0 @@
---
title: Special Identities (Windows 10)
description: Special Identities
ms.prod: m365-security
ms.technology: windows-sec
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 12/21/2021
ms.reviewer:
---
# Special Identities
**Applies to**
- Windows Server 2016 or later
This reference topic for the IT professional describes the special identity groups (which are sometimes referred to as security groups) that are used in Windows access control.
Special identity groups are similar to Active Directory security groups as listed in the users and built-in containers. Special identity groups can provide an efficient way to assign access to resources in your network. By using special identity groups, you can:
- Assign user rights to security groups in Active Directory.
- Assign permissions to security groups for the purpose of accessing resources.
Servers that are running the supported Windows Server operating systems designated in the **Applies To** list at the beginning of this topic include several special identity groups. These special identity groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances.
Although the special identity groups can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. Group scopes do not apply to special identity groups. Users are automatically assigned to these special identity groups whenever they sign in or access a particular resource.
For information about security groups and group scope, see [Active Directory Security Groups](active-directory-security-groups.md).
The special identity groups are described in the following tables:
- [Anonymous Logon](#anonymous-logon)
- [Authenticated Users](#authenticated-users)
- [Batch](#batch)
- [Creator Group](#creator-group)
- [Creator Owner](#creator-owner)
- [Dialup](#dialup)
- [Digest Authentication](#digest-authentication)
- [Enterprise Domain Controllers](#enterprise-domain-controllers)
- [Everyone](#everyone)
- [Interactive](#interactive)
- [Local Service](#local-service)
- [LocalSystem](#localsystem)
- [Network](#network)
- [Network Service](#network-service)
- [NTLM Authentication](#ntlm-authentication)
- [Other Organization](#other-organization)
- [Principal Self](#principal-self)
- [Remote Interactive Logon](#remote-interactive-logon)
- [Restricted](#restricted)
- [SChannel Authentication](#schannel-authentication)
- [Service](#service)
- [Terminal Server User](#terminal-server-user)
- [This Organization](#this-organization)
- [Window Manager\\Window Manager Group](#window-managerwindow-manager-group)
## Anonymous Logon
Any user who accesses the system through an anonymous logon has the Anonymous Logon identity. This identity allows anonymous access to resources, such as a web page that is published on corporate servers. The Anonymous Logon group is not a member of the Everyone group by default.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-7 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Attested Key Property
A SID that means the key trust object had the attestation property.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-6 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Authenticated Users
Any user who accesses the system through a sign-in process has the Authenticated Users identity. This identity allows access to shared resources within the domain, such as files in a shared folder that should be accessible to all the workers in the organization. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-11 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight<br> [Add workstations to domain](/windows/device-security/security-policy-settings/add-workstations-to-domain): SeMachineAccountPrivilege<br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege|
## Authentication Authority Asserted Identity
A SID that means the client's identity is asserted by an authentication authority based on proof of possession of client credentials.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Batch
Any user or process that accesses the system as a batch job (or through the batch queue) has the Batch identity. This identity allows batch jobs to run scheduled tasks, such as a nightly cleanup job that deletes temporary files. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-3 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Console Logon
A group that includes users who are logged on to the physical console. This SID can be used to implement security policies that grant different rights based on whether a user has been granted physical access to the console.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-2-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Creator Group
The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory.
A placeholder security identifier (SID) is created in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the primary group of the objects current owner. The primary group is used only by the Portable Operating System Interface for UNIX (POSIX) subsystem.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Creator Owner
The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory. A placeholder SID is created in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the objects current owner.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-0 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Dialup
Any user who accesses the system through a dial-up connection has the Dial-Up identity. This identity distinguishes dial-up users from other types of authenticated users.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Digest Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-21 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Enterprise Domain Controllers
This group includes all domain controllers in an Active Directory forest. Domain controllers with enterprise-wide roles and responsibilities have the Enterprise Domain Controllers identity. This identity allows them to perform certain tasks in the enterprise by using transitive trusts. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-9 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight<br> [Allow log on locally](/windows/device-security/security-policy-settings/allow-log-on-locally): SeInteractiveLogonRight|
## Everyone
All interactive, network, dial-up, and authenticated users are members of the Everyone group. This special identity group gives wide access to system resources. Whenever a user logs on to the network, the user is automatically added to the Everyone group.
On computers running Windows 2000 and earlier, the Everyone group included the Anonymous Logon group as a default member, but as of Windows Server 2003, the Everyone group contains only Authenticated Users and Guest; and it no longer includes Anonymous Logon by default (although this can be changed, using Registry Editor, by going to the **Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa** key and setting the value of **everyoneincludesanonymous** DWORD to 1).
Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-1-0 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight</br> [Act as part of the operating system](/windows/device-security/security-policy-settings/act-as-part-of-the-operating-system): SeTcbPrivilege</br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege|
## Fresh Public Key Identity
A SID that means the client's identity is asserted by an authentication authority based on proof of current possession of client public key credentials.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-3 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Interactive
Any user who is logged on to the local system has the Interactive identity. This identity allows only local users to access a resource. Whenever a user accesses a given resource on the computer to which they are currently logged on, the user is automatically added to the Interactive group. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None|
## IUSR
Internet Information Services (IIS) uses this account by default whenever anonymous authentication is enabled.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-17 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Key Trust
A SID that means the client's identity is based on proof of possession of public key credentials using the key trust object.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Local Service
The Local Service account is similar to an Authenticated User account. The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with anonymous credentials. The name of the account is NT AUTHORITY\\LocalService. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-19 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Adjust memory quotas for a process](/windows/device-security/security-policy-settings/adjust-memory-quotas-for-a-process): SeIncreaseQuotaPrivilege <br>[Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Change the system time](/windows/device-security/security-policy-settings/change-the-system-time): SeSystemtimePrivilege<br> [Change the time zone](/windows/device-security/security-policy-settings/change-the-time-zone): SeTimeZonePrivilege<br> [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Generate security audits](/windows/device-security/security-policy-settings/generate-security-audits): SeAuditPrivilege<br>[Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br> [Replace a process level token](/windows/device-security/security-policy-settings/replace-a-process-level-token): SeAssignPrimaryTokenPrivilege<br>|
## LocalSystem
This is a service account that is used by the operating system. The LocalSystem account is a powerful account that has full access to the system and acts as the computer on the network. If a service logs on to the LocalSystem account on a domain controller, that service has access to the entire domain. Some services are configured by default to log on to the LocalSystem account. Do not change the default service setting. The name of the account is LocalSystem. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-18 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## MFA Key Property
A SID that means the key trust object had the multifactor authentication (MFA) property.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-5 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Network
This group implicitly includes all users who are logged on through a network connection. Any user who accesses the system through a network has the Network identity. This identity allows only remote users to access a resource. Whenever a user accesses a given resource over the network, the user is automatically added to the Network group. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-2 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Network Service
The Network Service account is similar to an Authenticated User account. The Network Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Network Service account access network resources by using the credentials of the computer account. The name of the account is NT AUTHORITY\\NetworkService. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-20 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Adjust memory quotas for a process](/windows/device-security/security-policy-settings/adjust-memory-quotas-for-a-process): SeIncreaseQuotaPrivilege<br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Generate security audits](/windows/device-security/security-policy-settings/generate-security-audits): SeAuditPrivilege<br> [Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br> [Replace a process level token](/windows/device-security/security-policy-settings/replace-a-process-level-token): SeAssignPrimaryTokenPrivilege<br>|
## NTLM Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-10 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None|
## Other Organization
This group implicitly includes all users who are logged on to the system through a dial-up connection. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-1000 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Owner Rights
A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Principal Self
This identity is a placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal that is represented by the object.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-10 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Proxy
Identifies a SECURITY_NT_AUTHORITY Proxy.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-8 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Remote Interactive Logon
This identity represents all users who are currently logged on to a computer by using a Remote Desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-14|
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Restricted
Users and computers with restricted capabilities have the Restricted identity. This identity group is used by a process that is running in a restricted security context, such as running an application with the RunAs service. When code runs at the Restricted security level, the Restricted SID is added to the users access token.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-12 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## SChannel Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-14 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Service
Any service that accesses the system has the Service identity. This identity group includes all security principals that are signed in as a service. This identity grants access to processes that are being run by Windows Server services. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-6 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br>|
## Service Asserted Identity
A SID that means the client's identity is asserted by a service.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-2 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Terminal Server User
Any user accessing the system through Terminal Services has the Terminal Server User identity. This identity allows users to access Terminal Server applications and to perform other necessary tasks with Terminal Server services. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-13 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## This Organization
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-15 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Window Manager\\Window Manager Group
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-90 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Increase a process working set](/windows/device-security/security-policy-settings/increase-a-process-working-set): SeIncreaseWorkingSetPrivilege<br>|
## See also
- [Active Directory Security Groups](active-directory-security-groups.md)
- [Security Principals](security-principals.md)
- [Access Control Overview](access-control.md)

View File

@ -12,46 +12,56 @@ ms.date: 01/26/2022
ms.reviewer:
---
# Windows Defender Credential Guard: Known issues
# Windows Defender Credential Guard: Known issues
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
Windows Defender Credential Guard has certain application requirements. Windows Defender Credential Guard blocks specific authentication capabilities. So applications that require such capabilities won't function when it's enabled. For more information, see [Application requirements](/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
The following known issue has been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/help/4051033):
Windows Defender Credential Guard has certain application requirements. Windows Defender Credential Guard blocks specific authentication capabilities. So applications that require such capabilities won't function when it's enabled. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message: <br>
"Task Scheduler failed to log on \Test. <br>
Failure occurred in LogonUserExEx. <br>
User Action: Ensure the credentials for the task are correctly specified. <br>
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect)."
- When enabling NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
> Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: \<Secure Channel Name>
User name:
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
The following known issues have been fixed in the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4):
- Scheduled tasks with domain user-stored credentials fail to run when Credential Guard is enabled. The task fails and reports Event ID 104 with the following message:
```console
Task Scheduler failed to log on '\Test'.
Failure occurred in 'LogonUserExEx'.
User Action: Ensure the credentials for the task are correctly specified.
Additional Data: Error Value: 2147943726. 2147943726: ERROR\_LOGON\_FAILURE (The user name or password is incorrect).
```
- When you enable NTLM audit on the domain controller, an Event ID 8004 with an indecipherable username format is logged. You also get a similar user name in a user logon failure event 4625 with error 0xC0000064 on the machine itself. For example:
```console
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: <Secure Channel Name>
User name:
@@CyBAAAAUBQYAMHArBwUAMGAoBQZAQGA1BAbAUGAyBgOAQFAhBwcAsGA6AweAgDA2AQQAMEAwAANAgDA1AQLAIEADBQRAADAtAANAYEA1AwQA0CA5AAOAMEAyAQLAYDAxAwQAEDAEBwMAMEAwAgMAMDACBgRA0HA
Domain name: NULL
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
- The username appears in an unusual format because local accounts arent protected by Credential Guard. The task also fails to execute.
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
```
- This event stems from a scheduled task running under local user context with the [Cumulative Security Update for November 2017](https://support.microsoft.com/topic/november-27-2017-kb4051033-os-build-14393-1914-447b6b88-e75d-0a24-9ab9-5dcda687aaf4) or later and happens when Credential Guard is enabled.
- The username appears in an unusual format because local accounts aren't protected by Credential Guard. The task also fails to execute.
- As a workaround, run the scheduled task under a domain user or the computer's SYSTEM account.
The following known issues have been fixed by servicing releases made available in the Cumulative Security Updates for April 2017:
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/help/4015217/windows-10-update-kb4015217)
- [KB4015217 Windows Defender Credential Guard generates double bad password count on Active Directory domain-joined Windows machines](https://support.microsoft.com/topic/april-11-2017-kb4015217-os-build-14393-1066-and-14393-1083-b5f79067-98bd-b4ec-8b81-5d858d7dc722)
This issue can potentially lead to unexpected account lockouts. See also Microsoft® Knowledge Base articles [KB4015219](https://support.microsoft.com/help/4015219/windows-10-update-kb4015219) and [KB4015221](https://support.microsoft.com/help/4015221/windows-10-update-kb4015221)
This issue can potentially lead to unexpected account lockouts. For more information, see the following support articles:
- [KB4015219](https://support.microsoft.com/topic/april-11-2017-kb4015219-os-build-10586-873-68b8e379-aafa-ea6c-6b29-56d19785e657)
- [KB4015221](https://support.microsoft.com/topic/april-11-2017-kb4015221-os-build-10240-17354-743f52bc-a484-d23f-71f5-b9957cbae0e6)
## Known issues involving third-party applications
@ -59,61 +69,47 @@ The following issue affects MSCHAPv2:
- [Credential guard doesn't work with MSCHAPv2 configurations, of which Cisco ISE is a very popular enterprise implementation](https://quickview.cloudapps.cisco.com/quickview/bug/CSCul55352).
The following issue affects the Java GSS API. See the following Oracle bug database article:
The following issue affects the Java GSS API. See the following Oracle bug database article:
- [JDK-8161921: Windows Defender Credential Guard doesn't allow sharing of TGT with Java](http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8161921)
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API won't authenticate. This is expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and won't provide the TGT session key to applications regardless of registry key settings. For more information, see [Application requirements](/windows/access-protection/credential-guard/credential-guard-requirements#application-requirements).
When Windows Defender Credential Guard is enabled on Windows, the Java GSS API won't authenticate. This is expected behavior because Windows Defender Credential Guard blocks specific application authentication capabilities and won't provide the TGT session key to applications regardless of registry key settings. For more information, see [Application requirements](credential-guard-requirements.md#application-requirements).
The following issue affects Cisco AnyConnect Secure Mobility Client:
- [Blue screen on Windows computers running Hypervisor-Protected Code Integrity and Windows Defender Credential Guard with Cisco Anyconnect 4.3.04027](https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc66692) \*
*Registration required to access this article.
- [Blue screen on Windows computers running Hypervisor-Protected Code Integrity and Windows Defender Credential Guard with Cisco Anyconnect 4.3.04027](https://quickview.cloudapps.cisco.com/quickview/bug/CSCvc66692)
The following issue affects McAfee Application and Change Control (MACC):
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kc.mcafee.com/corporate/index?page=content&id=KB88869) <sup>[1]</sup>
The following issue affects AppSense Environment Manager.
For more information, see the following Knowledge Base article:
- [Installing AppSense Environment Manager on Windows machines causes LSAISO.exe to exhibit high CPU usage when Windows Defender Credential Guard is enabled](http://www.appsense.com/kb/160525073917945) <sup>[1]</sup> \**
- [KB88869 Windows machines exhibit high CPU usage with McAfee Application and Change Control (MACC) installed when Windows Defender Credential Guard is enabled](https://kcm.trellix.com/corporate/index?page=content&id=KB88869) <sup>[Note 1](#bkmk_note1)</sup>
The following issue affects Citrix applications:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[1]</sup>
<sup>[1]</sup> Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled Windows 10, Windows 11, Windows Server 2016, or Windows Server 2019 machines to exhibit high CPU usage. For technical and troubleshooting information, see the following Microsoft Knowledge Base article:
- Windows machines exhibit high CPU usage with Citrix applications installed when Windows Defender Credential Guard is enabled. <sup>[Note 1](#bkmk_note1)</sup>
- [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage)
For further technical information on LSAISO.exe, see the MSDN article: [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes)
\** Registration is required to access this article.
<a name="bkmk_note1"></a>
> [!NOTE]
> **Note 1**: Products that connect to Virtualization Based Security (VBS) protected processes can cause Windows Defender Credential Guard-enabled Windows 10, Windows 11, Windows Server 2016, or Windows Server 2019 machines to exhibit high CPU usage. For technical and troubleshooting information, see [KB4032786 High CPU usage in the LSAISO process on Windows](/troubleshoot/windows-client/performance/lsaiso-process-high-cpu-usage).
>
> For more technical information on LSAISO.exe, see [Isolated User Mode (IUM) Processes](/windows/win32/procthread/isolated-user-mode--ium--processes).
## Vendor support
See the following article on Citrix support for Secure Boot:
- [Citrix Support for Secure Boot](https://www.citrix.com/blogs/2016/12/08/windows-server-2016-hyper-v-secure-boot-support-now-available-in-xenapp-7-12/)
For more information on Citrix support for Secure Boot, see [Citrix Support for Secure Boot](https://www.citrix.com/blogs/2016/12/08/windows-server-2016-hyper-v-secure-boot-support-now-available-in-xenapp-7-12/)
Windows Defender Credential Guard isn't supported by either these products, products versions, computer systems, or Windows 10 versions:
Windows Defender Credential Guard isn't supported by the following products, products versions, computer systems, or Windows 10 versions:
- For Windows Defender Credential Guard on Windows with McAfee Encryption products, see:
[Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kc.mcafee.com/corporate/index?page=content&id=KB86009)
- [Support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard on Windows with McAfee encryption products](https://kcm.trellix.com/corporate/index?page=content&id=KB86009KB86009)
- For Windows Defender Credential Guard on Windows with Check Point Endpoint Security Client, see:
[Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- [Check Point Endpoint Security Client support for Microsoft Windows Defender Credential Guard and Hypervisor-Protected Code Integrity features](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113912)
- For Windows Defender Credential Guard on Windows with VMWare Workstation
[Windows host fails when running VMWare Workstation when Windows Defender Credential Guard is enabled](https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2146361)
- ["VMware Workstation and Device/Credential Guard are not compatible" error in VMware Workstation on Windows 10 host (2146361)](https://kb.vmware.com/s/article/2146361)
- For Windows Defender Credential Guard on Windows with specific versions of the Lenovo ThinkPad
[ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows ThinkPad](https://support.lenovo.com/in/en/solutions/ht503039)
- [ThinkPad support for Hypervisor-Protected Code Integrity and Windows Defender Credential Guard in Microsoft Windows](https://support.lenovo.com/in/en/solutions/ht503039)
- For Windows Defender Credential Guard on Windows with Symantec Endpoint Protection
[Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
- [Windows devices with Windows Defender Credential Guard and Symantec Endpoint Protection 12.1](https://www.symantec.com/connect/forums/windows-10-device-guard-credentials-guard-and-sep-121)
This isn't a comprehensive list. Check whether your product vendor, product version, or computer system, supports Windows Defender Credential Guard on systems that run Windows or specific versions of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.
This list isn't comprehensive. Check whether your product vendor, product version, or computer system supports Windows Defender Credential Guard on systems that run Windows or specific versions of Windows. Specific computer system models may be incompatible with Windows Defender Credential Guard.
Microsoft encourages third-party vendors to contribute to this page by providing relevant product support information and by adding links to their own product support statements.
Microsoft encourages third-party vendors to contribute to this page by providing relevant product support information and by adding links to their own product support statements.

View File

@ -70,6 +70,8 @@ If the error occurs again, check the error code against the following table to s
| 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Azure AD and rejoin. |
| | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. |
| 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. |
| 0xC00000BB | Your PIN or this option is temporarily unavailable.| The destination domain controller doesn't support the login method. Most often the KDC service doesn't have the proper certificate to support the login. Use a different login method.|
## Errors with unknown mitigation

View File

@ -31,6 +31,7 @@ sections:
answer: |
Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust).
- question: What about virtual smart cards?
answer: |
Windows Hello for Business is the modern, two-factor credential for Windows 10. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using Windows 10 and virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows 10 deployments use Windows Hello for Business. Virtual smart cards remain supported for Windows 7 and Windows 8.
@ -42,6 +43,7 @@ sections:
- question: Can I use Windows Hello for Business key trust and RDP?
answer: |
Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates.
- question: Can I deploy Windows Hello for Business by using Microsoft Endpoint Configuration Manager?
answer: |
@ -57,13 +59,12 @@ sections:
- question: How can a PIN be more secure than a password?
answer: |
The Windows Hello for Business PIN isn't a symmetric key, whereas a password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement "PIN is stronger than Password" isn't directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multi-factor Unlock](feature-multifactor-unlock.md) feature.
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
- question: How does Windows Hello for Business work with Azure AD registered devices?
answer: |
A user will be prompted to set-up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using their exiting gestures.
A user will be prompted to set up a Windows Hello for Business key on an Azure AD registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using their exiting gestures.
If a user has signed into their Azure AD registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Azure AD resources. The Windows Hello for Business key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources.
@ -79,7 +80,7 @@ sections:
answer: |
It's currently possible to set a convenience PIN on Azure Active Directory Joined or Hybrid Active Directory Joined devices. Convenience PIN isn't supported for Azure Active Directory user accounts (synchronized identities included). It's only supported for on-premises Domain Joined users and local account users.
- question: Can I use an external Windows Hello compatible camera when my computer has a built in Windows Hello compatible camera?
- question: Can I use an external Windows Hello compatible camera when my computer has a built-in Windows Hello compatible camera?
answer: |
Yes. Starting with Windows 10, version 21H1 an external Windows Hello compatible camera can be used if a device already supports an internal Windows Hello camera. When both cameras are present, the external camera is used for face authentication. For more information, see [IT tools to support Windows 10, version 21H1](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/it-tools-to-support-windows-10-version-21h1/ba-p/2365103). However, using external Hello cameras and accessories is restricted if ESS is enabled, please see [Windows Hello Enhanced Sign-in Security](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#pluggableperipheral-biometric-sensors).
@ -101,14 +102,10 @@ sections:
answer: |
The user experience for Windows Hello for Business occurs after the user signs in, after you deploy Windows Hello for Business policy settings to your environment.
[Windows Hello for Business user enrollment experience](hello-videos.md#windows-hello-for-business-user-enrollment-experience)
- question: What happens when a user forgets their PIN?
answer: |
If the user can sign in with a password, they can reset their PIN by selecting the "I forgot my PIN" link in Settings. Beginning with Windows 10 1709, users can reset their PIN above the lock screen by selecting the "I forgot my PIN" link on the PIN credential provider.
[Windows Hello for Business forgotten PIN user experience](hello-videos.md#windows-hello-for-business-forgotten-pin-user-experience)
For on-premises deployments, devices must be well-connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid customers can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset).
- question: What URLs do I need to allow for a hybrid deployment?
@ -127,9 +124,9 @@ sections:
- question: What's the difference between non-destructive and destructive PIN reset?
answer: |
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 Enterprise and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md).
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 Enterprise can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid deployments, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services.
- question: |
Which is better or more secure, key trust or certificate trust?
@ -153,7 +150,31 @@ sections:
- question: Is Windows Hello for Business multi-factor authentication?
answer: |
Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor".
- question: Where is Windows Hello biometrics data stored?
answer: |
When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesnt roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details see [Windows Hello biometrics in the enterprise](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored).
- question: What is the format used to store Windows Hello biometrics data on the device?
answer: |
Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (e.g., face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before its stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash.
- question: Who has access on Windows Hello biometrics data?
answer: |
Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it.
- question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication?
answer: |
Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method (e.g. pin). Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just click on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users.
- question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication?
answer: |
To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy).
- question: What about any diagnostic data coming out when WHFB is enabled?
answer: |
To help us keep things working properly, to help detect and prevent fraud, and to continue improving Windows Hello, we collect diagnostic data about how people use Windows Hello. For example, data about whether people sign in with their face, iris, fingerprint, or PIN; the number of times they use it; and whether it works or not is all valuable information that helps us build a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319).
- question: What are the biometric requirements for Windows Hello for Business?
answer: |
Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information.
@ -210,7 +231,7 @@ sections:
answer: |
Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business don't require a TPM. Administrators can choose to allow key operations in software.
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to re-authenticate to the IDP before the IDP allows them to re-register).
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against various known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to reauthenticate to the IDP before the IDP allows them to re-register).
- question: Can Windows Hello for Business work in air-gapped environments?
answer: |
@ -227,9 +248,9 @@ sections:
| Protocol | Description |
| :---: | :--- |
| [[MS-KPP]: Key Provisioning Protocol](/openspecs/windows_protocols/ms-kpp/25ff7bd8-50e3-4769-af23-bcfd0b4d4567) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. |
| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and login hints. |
| [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. |
| [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define additional claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define additional provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
| [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. |
- question: Does Windows Hello for Business work with Mac and Linux clients?
answer: |
@ -239,3 +260,4 @@ sections:
- question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients?
answer: |
No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD.

View File

@ -1,6 +1,6 @@
---
title: Pin Reset
description: Learn how Microsoft PIN reset services enables you to help users recover who have forgotten their PIN.
description: Learn how Microsoft PIN reset services enable you to help users recover who have forgotten their PIN.
ms.prod: m365-security
author: GitPrakhar13
ms.author: prsriva
@ -10,52 +10,58 @@ ms.collection:
- highpri
ms.topic: article
localizationpriority: medium
ms.date: 5/3/2021
ms.date: 07/29/2022
appliesto:
-<b>Windows 10</b>
-<b>Windows 11</b>
---
# PIN reset
**Applies to:**
Windows Hello for Business provides the capability for users to reset forgotten PINs using the *I forgot my PIN* link from the Sign-in options page in *Settings* or from the Windows lock screen. Users are required to authenticate and complete multi-factor authentication to reset their PIN.
- Windows 10, version 1709 or later
- Windows 11
There are two forms of PIN reset:
Windows Hello for Business provides the capability for users to reset forgotten PINs using the "I forgot my PIN link" from the Sign-in options page in Settings or from above the lock screen. User's are required to authenticate and complete multifactor authentication to reset their PIN.
- **Destructive PIN reset**: with this option, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new login key and PIN are provisioned. Destructive PIN reset is the default option, and doesn't require configuration.
- **Non-destructive PIN reset**: with this option, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. For non-destructive PIN reset, you must deploy the **Microsoft PIN Reset Service** and configure your clients' policy to enable the **PIN Recovery** feature.
## Using PIN reset
There are two forms of PIN reset called destructive and non-destructive. Destructive PIN reset is the default and does not require configuration. During a destructive PIN reset, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned. For non-destructive PIN reset, you must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.
## Using PIN Reset
There are two forms of PIN reset called destructive and non-destructive. Destructive PIN reset is the default and doesn't require configuration. During a destructive PIN reset, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned. For non-destructive PIN reset, you must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.
**Requirements**
- Reset from settings - Windows 10, version 1703
- Reset above Lock - Windows 10, version 1709
- Reset from settings - Windows 10, version 1703 or later, Windows 11
- Reset above Lock - Windows 10, version 1709 or later, Windows 11
Destructive and non-destructive PIN reset use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users do not have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider.
Destructive and non-destructive PIN reset use the same entry points for initiating a PIN reset. If a user has forgotten their PIN, but has an alternate logon method, they can navigate to Sign-in options in Settings and initiate a PIN reset from the PIN options. If they do not have an alternate way to sign into their device, PIN reset can also be initiated from above the lock screen in the PIN credential provider.
>[!IMPORTANT]
>For hybrid Azure AD-joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN.
### Reset PIN from Settings
1. Sign-in to Windows 10, version 1703 or later using an alternate credential.
2. Open **Settings**, click **Accounts**, click **Sign-in options**.
3. Under **PIN**, click **I forgot my PIN** and follow the instructions.
1. Sign-in to Windows 10 using an alternate credential.
1. Open **Settings**, select **Accounts** > **Sign-in options**.
1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions.
### Reset PIN above the Lock Screen
For Azure AD-joined devices:
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
1. Click **I forgot my PIN** from the PIN credential provider.
1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (i.e., Password, PIN, Security key).
1. Select **I forgot my PIN** from the PIN credential provider.
1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key).
1. Follow the instructions provided by the provisioning process.
1. When finished, unlock your desktop using your newly created PIN.
For Hybrid Azure AD-joined devices:
1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon.
1. Click **I forgot my PIN** from the PIN credential provider.
1. Select **I forgot my PIN** from the PIN credential provider.
1. Enter your password and press enter.
1. Follow the instructions provided by the provisioning process.
1. When finished, unlock your desktop using your newly created PIN.
@ -63,86 +69,129 @@ For Hybrid Azure AD-joined devices:
> [!NOTE]
> Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work.
You may find that PIN reset from settings only works post login, and that the "lock screen" PIN reset function will not work if you have any matching limitation of SSPR password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
Visit the [Windows Hello for Business Videos](./hello-videos.md) page and watch [Windows Hello for Business forgotten PIN user experience](./hello-videos.md#windows-hello-for-business-forgotten-pin-user-experience).
You may find that PIN reset from settings only works post login, and that the "lock screen" PIN reset function will not work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations).
## Non-Destructive PIN reset
**Requirements:**
- Azure Active Directory
- Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903.
- Hybrid Windows Hello for Business deployment
- Azure AD registered, Azure AD joined, and Hybrid Azure AD joined
- Windows 10, version 1709 to 1809, **Enterprise Edition**. There is no licensing requirement for this feature since version 1903.
When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally and added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication to Azure, and completes multifactor authentication, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it is then cleared from memory.
Using Group Policy, Microsoft Intune or a compatible MDM, you can configure Windows devices to securely use the Microsoft PIN reset service that enables users to reset their forgotten PIN through settings or above the lock screen without requiring re-enrollment.
When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally and added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Azure AD, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it is then cleared from memory.
Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the **Microsoft PIN Reset Service** which enables users to reset their forgotten PIN without requiring re-enrollment.
>[!IMPORTANT]
> The Microsoft PIN Reset service only works with **Enterprise Edition** for Windows 10, version 1709 to 1809. The feature works with **Enterprise Edition** and **Pro** edition with Windows 10, version 1903 and newer.
> The Microsoft PIN Reset service only works with **Enterprise Edition** for Windows 10, version 1709 to 1809 and later, and Windows 11. The feature works with **Enterprise Edition** and **Pro** edition with Windows 10, version 1903 and later, Windows 11.
> The Microsoft PIN Reset service is not currently available in Azure Government.
### Summary
|Category|Destructive PIN Reset|Non-Destructive PIN Reset|
|--- |--- |--- |
|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.|
|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.|
|**Azure Active Directory Joined**|Cert Trust, Key Trust, and Cloud Trust|Cert Trust, Key Trust, and Cloud Trust|
|**Hybrid Azure Active Directory Joined**|Cert Trust and Cloud Trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and Cloud Trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.|
|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.|
|**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
### Onboarding the Microsoft PIN reset service to your Intune tenant
Before you can remotely reset PINs, you must on-board the Microsoft PIN reset service to your Azure Active Directory tenant, and configure devices you manage.
> The **Microsoft PIN Reset Service** is not currently available in Azure Government.
### Connect Azure Active Directory with the PIN reset service
1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using the Global administrator account you use to manage your Azure Active Directory tenant.
### Enable the Microsoft PIN Reset Service in your Azure AD tenant
1. After you have logged in, choose **Accept** to give consent for the PIN reset service to access your account.
Before you can remotely reset PINs, you must register two applications in your Azure Active Directory tenant:
- PIN Reset Service
- PIN Reset Client
#### Connect Azure Active Directory with the PIN Reset Service
1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant.
1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization.
![PIN reset service application in Azure.](images/pinreset/pin-reset-service-prompt.png)
1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using the Global administrator account you use to manage your Azure Active Directory tenant.
1. After you have logged in, choose **Accept** to give consent for the PIN reset client to access your account.
#### Connect Azure Active Directory with the PIN Reset Client
1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant.
1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization.
![PIN reset client application in Azure.](images/pinreset/pin-reset-client-prompt.png)
> [!NOTE]
> After you have accepted the PIN reset service and client requests, you will land on a page that states "You do not have permission to view this directory or page." This behavior is expected. Be sure to confirm that the two PIN reset applications are listed for your tenant.
#### Confirm that the two PIN Reset service principals are registered in your tenant
1. In the [Azure portal](https://portal.azure.com), verify that the Microsoft PIN Reset Service and Microsoft PIN Reset Client are integrated from the **Enterprise applications** blade. Filter to application status "Enabled" and both Microsoft Pin Reset Service Production and Microsoft Pin Reset Client Production will show up in your tenant.
1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com).
1. Select **Azure Active Directory** > **Applications** > **Enterprise applications**.
1. Search by application name "Microsoft PIN" and both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** will show up in the list.
:::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png":::
:::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications.png":::
### Enable PIN Recovery on your devices
### Configure Windows devices to use PIN reset using Group Policy
Before you can remotely reset PINs, your devices must be configured to enable PIN Recovery. Follow the instructions below to configure your devices using either Microsoft Intune, Group Policy Objects (GPO), or Configuration Service Providers (CSP).
You can configure Windows to use the Microsoft PIN Reset service using the computer configuration portion of a Group Policy object.
#### [✅ **Intune**](#tab/intune)
You can configure Windows devices to use the **Microsoft PIN Reset Service** using Microsoft Intune.
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com).
1. Select **Devices** > **Configuration profiles** > **Create profile**.
1. Enter the following properties:
- **Platform**: Select **Windows 10 and later**.
- **Profile type**: Select **Settings catalog**.
1. Select **Create**.
1. In **Basics**, enter the following properties:
- **Name**: Enter a descriptive name for the profile.
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
1. Select **Next**.
1. In **Configuration settings**, select **Add settings**.
1. In the settings picker, select **Windows Hello For Business** > **Enable Pin Recovery**.
1. Configure **Enable Pin Recovery** to **true**.
1. Select **Next**.
1. In **Scope tags**, assign any applicable tags (optional).
1. Select **Next**.
1. In **Assignments**, select the security groups that will receive the policy.
1. Select **Next**.
1. In **Review + create**, review your settings and select **Create**.
>[!NOTE]
> You can also configure PIN recovery from the **Endpoint security** blade:
> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com).
> 1. Select **Endpoint security** > **Account protection** > **Create Policy**.
#### [✅ **GPO**](#tab/gpo)
You can configure Windows devices to use the **Microsoft PIN Reset Service** using a Group Policy Object (GPO).
1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory.
1. Edit the Group Policy object from Step 1.
1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**.
1. Close the Group Policy Management Editor to save the Group Policy object. Close the GPMC.
1. Close the Group Policy Management Editor to save the Group Policy object.
#### Create a PIN Reset Device configuration profile using Microsoft Intune
#### [✅ **CSP**](#tab/csp)
1. Sign-in to [Endpoint Manager admin center](https://endpoint.microsoft.com/) using a Global administrator account.
1. Click **Endpoint Security** > **Account Protection** > **Properties**.
1. Set **Enable PIN recovery** to **Yes**.
You can configure Windows devices to use the **Microsoft PIN Reset Service** using the [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp).
> [!NOTE]
> You can also set up PIN recovery using configuration profiles.
>
> 1. Sign in to Endpoint Manager.
> 1. Click **Devices** > **Configuration Profiles** > Create a new profile or edit an existing profile using the Identity Protection profile type.
> 1. Set **Enable PIN recovery** to **Yes**.
- OMA-URI: `./Vendor/MSFT/Policy/PassportForWork/`*TenantId*`/Policies/EnablePinRecovery`
- Data type: **Boolean**
- Value: **True**
#### Assign the PIN Reset Device configuration profile using Microsoft Intune
>[!NOTE]
> You must replace `TenantId` with the identifier of your Azure Active Directory tenant.
1. Sign in to the [Azure portal](https://portal.azure.com) using a Global administrator account.
1. Navigate to the Microsoft Intune blade. Choose **Device configuration** > **Profiles**. From the list of device configuration profiles, choose the profile that contains the PIN reset configuration.
1. In the device configuration profile, select **Assignments**.
1. Use the **Include** and/or **Exclude** tabs to target the device configuration profile to select groups.
---
### Confirm that PIN recovery policy is enforced on the client
#### Confirm that PIN Recovery policy is enforced on the devices
The PIN reset configuration for a user can be viewed by running [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) from the command line. This state can be found under the output in the user state section as the **CanReset** line item. If **CanReset** reports as DestructiveOnly, then only destructive PIN reset is enabled. If **CanReset** reports DestructiveAndNonDestructive, then non-destructive PIN reset is enabled.
The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) from the command line. This state can be found under the output in the user state section as the **CanReset** line item. If **CanReset** reports as DestructiveOnly, then only destructive PIN reset is enabled. If **CanReset** reports DestructiveAndNonDestructive, then non-destructive PIN reset is enabled.
#### Sample User state Output for Destructive PIN Reset
**Sample User state Output for Destructive PIN Reset**
```console
+----------------------------------------------------------------------+
@ -161,7 +210,7 @@ The PIN reset configuration for a user can be viewed by running [**dsregcmd /sta
+----------------------------------------------------------------------+
```
#### Sample User state Output for Non-Destructive PIN Reset
**Sample User state Output for Non-Destructive PIN Reset**
```console
+----------------------------------------------------------------------+
@ -200,7 +249,7 @@ The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-au
1. In the **Name** field type **Web Sign In Allowed URLs** and optionally provide a description for the configuration. Click Next.
1. On the Configuration settings page, click **Add** to add a custom OMA-URI setting. Provide the following information for the custom settings
1. On the Configuration settings page, click **Add** to add a custom OMA-URI setting. Provide the following information for the custom settings:
- **Name:** Web Sign In Allowed URLs
- **Description:** (Optional) List of domains that are allowed during PIN reset flows.
@ -210,14 +259,45 @@ The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-au
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist.png":::
1. Click the Save button to save the custom configuration.
1. Click the **Save** button to save the custom configuration.
1. On the Assignments page, use the Included groups and Excluded groups sections to define the groups of users or devices that should receive this policy. Once you have completed configuring groups click the Next button.
1. On the Applicability rules page, click Next.
1. On the Applicability rules page, click **Next**.
1. Review the configuration that is shown on the Review + create page to make sure that it is accurate. Click create to save the profile and apply it to the configured groups.
### Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that can be reached during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset.
#### Configure Web Sign-in Allowed URLs using Microsoft Intune
1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** > **Configuration profiles** > **Create profile**.
1. Enter the following properties:
- **Platform**: Select **Windows 10 and later**.
- **Profile type**: Select **Templates**.
- In the list of templates that is loaded, select **Custom** > **Create**.
1. In **Basics**, enter the following properties:
- **Name**: Enter a descriptive name for the profile.
- **Description**: Enter a description for the profile. This setting is optional, but recommended.
1. Select **Next**.
1. In **Configuration settings**, select **Add** and enter the following settings:
- Name: **Web Sign In Allowed URLs**
- Description: **(Optional) List of domains that are allowed during PIN reset flows**
- OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls`
- Data type: **String**
- Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks).
:::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist-expanded.png":::
1. Select **Save** > **Next**.
1. In **Assignments**, select the security groups that will receive the policy.
1. Select **Next**.
1. In **Applicability Rules**, select **Next**.
1. In **Review + create**, review your settings and select **Create**.
> [!NOTE]
> For Azure Government, there is a known issue with PIN reset on Azure AD Joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, "We can't open that page right now." The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy.

View File

@ -1,5 +1,5 @@
---
title: How Windows Hello for Business works - Technology and Terms
title: How Windows Hello for Business works - technology and terms
description: Explore technology and terms associated with Windows Hello for Business. Learn how Windows Hello for Business works.
ms.prod: m365-security
author: GitPrakhar13
@ -11,275 +11,340 @@ localizationpriority: medium
ms.date: 10/08/2018
ms.reviewer:
---
# Technology and Terms
# Technology and terms
**Applies to:**
- Windows 10
- Windows 11
- [Attestation Identity Keys](#attestation-identity-keys)
- [Azure AD Joined](#azure-ad-joined)
- [Azure AD Registered](#azure-ad-registered)
- [Certificate Trust](#certificate-trust)
- [Cloud Deployment](#cloud-deployment)
- [Cloud Experience Host](#cloud-experience-host)
- [Deployment Type](#deployment-type)
- [Endorsement Key](#endorsement-key)
- [Federated Environment](#federated-environment)
- [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
- [Hybrid Deployment](#hybrid-deployment)
- [Join Type](#join-type)
- [Key Trust](#key-trust)
- [Managed Environment](#managed-environment)
- [On-premises Deployment](#on-premises-deployment)
- [Pass-through Authentication](#pass-through-authentication)
- [Password Hash Synchronization](#password-hash-sync)
- [Primary Refresh Token](#primary-refresh-token)
- [Storage Root Key](#storage-root-key)
- [Trust Type](#trust-type)
- [Trusted Platform Module](#trusted-platform-module)
<hr>
## Attestation identity keys
## Attestation Identity Keys
Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
Because the endorsement certificate is unique for each device and doesn't change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
> [!NOTE]
> The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
> The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
Windows creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows device.
Windows creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it's communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 or Windows 11 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 or Windows 11 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates aren't issued by Microsoft Cloud CA. This behavior isn't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an endorsement certificate.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be used by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that's not backed by an endorsement certificate.
### Related topics
[Endorsement Key](#endorsement-key), [Storage Root Key](#storage-root-key), [Trusted Platform Module](#trusted-platform-module)
### Related to attestation identity keys
### More information
- [Windows Client Certificate Enrollment Protocol: Glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
### More information about attestation identity keys
[Return to Top](hello-how-it-works-technology.md)
## Azure AD Joined
Azure AD Join is intended for organizations that desire to be cloud-first or cloud-only. There is no restriction on the size or type of organizations that can deploy Azure AD Join. Azure AD Join works well even in an hybrid environment and can enable access to on-premise applications and resources.
### Related topics
[Join Type](#join-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
- [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction).
## Azure Active Directory join
[Return to Top](hello-how-it-works-technology.md)
## Azure AD Registered
The goal of Azure AD registered devices is to provide you with support for the Bring Your Own Device (BYOD) scenario. In this scenario, a user can access your organization's Azure Active Directory controlled resources using a personal device.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Join Type](#join-type)
Azure Active Directory (Azure AD) join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Azure AD join. Azure AD join also works in a hybrid environment and can enable access to on-premises applications and resources.
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
### Related to Azure AD join
- [Join type](#join-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
[Return to Top](hello-how-it-works-technology.md)
## Certificate Trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
### More information about Azure AD join
### Related topics
[Deployment Type](#deployment-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Hybrid Deployment](#hybrid-deployment), [Key Trust](#key-trust), [On-premises Deployment](#on-premises-deployment), [Trust Type](#trust-type)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
## Azure AD registration
[Return to Top](hello-how-it-works-technology.md)
## Cloud Deployment
The Windows Hello for Business Cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD joined or Azure AD registered device join types.
The goal of Azure AD-registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Azure AD-controlled resources using a personal device.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Deployment Type](#deployment-type), [Join Type](#join-type)
### Related to Azure AD registration
[Return to Top](hello-how-it-works-technology.md)
## Cloud Experience Host
In Windows 10 and Windows 11, Cloud Experience Host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
- [Azure AD join](#azure-active-directory-join)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Join type](#join-type)
### Related topics
[Windows Hello for Business](./hello-identity-verification.md), [Managed Windows Hello in Organization](./hello-manage-in-organization.md)
### More information about Azure AD registration
### More information
- [Windows Hello for Business and Device Registration](./hello-how-it-works-device-registration.md)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview).
[Return to Top](hello-how-it-works-technology.md)
## Certificate trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
### Related to certificate trust
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### More information about certificate trust
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Cloud deployment
The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Azure AD-joined or Azure AD-registered devices.
### Related to cloud deployment
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Deployment type](#deployment-type)
- [Join type](#join-type)
## Cloud experience host
In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Azure AD for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Azure AD, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
### Related to cloud experience host
- [Windows Hello for Business](./hello-identity-verification.md)
- [Managed Windows Hello in organization](./hello-manage-in-organization.md)
### More information on cloud experience host
[Windows Hello for Business and device registration](./hello-how-it-works-device-registration.md)
## Deployment type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
## Deployment Type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
- Cloud
- Hybrid
- On-Premises
- On-premises
### Related topics
[Cloud Deployment](#cloud-deployment), [Hybrid Deployment](#hybrid-deployment), [On-premises Deployment](#on-premises-deployment)
### Related to deployment type
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
- [Cloud deployment](#cloud-deployment)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
[Return to Top](hello-how-it-works-technology.md)
## Endorsement Key
### More information about deployment type
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Endorsement key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key public key is used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM.
The endorsement key is often accompanied by one or two digital certificates:
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10 and Windows 11.
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Storage Root Key](#storage-root-key), [Trusted Platform Module](#trusted-platform-module)
### Related to endorsement key
### More information
- [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11)).
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
- [Attestation identity keys](#attestation-identity-keys)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
[Return to Top](hello-how-it-works-technology.md)
## Federated Environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure Active Directory and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they do not have to sign in again to use Office 365 or other Azure-based applications. This federated authentication model can provide additional authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD.
### More information about endorsement key
### Related topics
[Hybrid Deployment](#hybrid-deployment), [Managed Environment](#managed-environment), [Pass-through authentication](#pass-through-authentication), [Password Hash Sync](#password-hash-sync)
- [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11))
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Federated environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Azure AD and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Office 365 or other Azure-based applications. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Azure AD.
### Related to federated environment
- [Hybrid deployment](#hybrid-deployment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash sync](#password-hash-sync)
### More information about federated environment
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Hybrid Azure AD join
[Return to Top](hello-how-it-works-technology.md)
## Hybrid Azure AD Joined
For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable:
- IT departments to manage work-owned devices from a central location.
- Users to sign in to their devices with their Active Directory work or school accounts.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy (GP) to manage them.
- Users to sign in to their devices with their Active Directory work or school accounts.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD-joined devices. These are devices that are both, joined to your on-premises Active Directory and your Azure Active Directory.
Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Deployment](#hybrid-deployment)
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure AD, you can implement hybrid Azure AD-joined devices. These devices are joined to both your on-premises Active Directory and your Azure AD.
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
### Related to hybrid Azure AD join
[Return to Top](hello-how-it-works-technology.md)
## Hybrid Deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that is synchronized with Azure Active Directory. Hybrid deployments support devices that are Azure AD registered, Azure AD joined, and hybrid Azure AD joined. The Hybrid deployment model supports two trust types for on-premises authentication, key trust and certificate trust.
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid deployment](#hybrid-deployment)
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined),
### More information about hybrid Azure AD join
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
## Hybrid deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Azure AD. Hybrid deployments support devices that are Azure AD-registered, Azure AD-joined, and hybrid Azure AD-joined. The Hybrid deployment model supports two trust types for on-premises authentication, key trust and certificate trust.
### Related to hybrid deployment
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
### More information about hybrid deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
[Return to Top](hello-how-it-works-technology.md)
## Join type
Join type is how devices are associated with Azure Active Directory. For a device to authenticate to Azure Active Directory it must be registered or joined.
Join type is how devices are associated with Azure AD. For a device to authenticate to Azure AD it must be registered or joined.
Registering a device to Azure AD enables you to manage a device's identity. When a device is registered, Azure AD device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Azure AD. You can use the identity to enable or disable a device.
When combined with a mobile device management(MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune .
When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Azure AD are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune.
Joining a device is an extension to registering a device. This means, it provides you with all the benefits of registering a device and in addition to this, it also changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined)
### Related to join type
### More information
- [Introduction to device management in Azure Active Directory](/azure/active-directory/device-management-introduction)
- [Azure AD join](#azure-active-directory-join)
- [Azure AD registration](#azure-ad-registration)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
[Return to Top](hello-how-it-works-technology.md)
## Key Trust
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows Server 2016 domain controllers.
### More information about join type
### Related topics
[Certificate Trust](#certificate-trust), [Deployment Type](#deployment-type), [Hybrid Azure AD Joined](#hybrid-azure-ad-joined), [Hybrid Deployment](#hybrid-deployment), [On-premises Deployment](#on-premises-deployment), [Trust Type](#trust-type)
[Introduction to device identity in Azure AD](/azure/active-directory/devices/overview)
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
## Key trust
[Return to Top](hello-how-it-works-technology.md)
## Managed Environment
Managed environments are for non-federated environments where Azure Active Directory manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services.
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows Server 2016 domain controllers.
### Related topics
[Federated Environment](#federated-environment), [Pass-through authentication](#pass-through-authentication), [Password Hash Synchronization](#password-hash-sync)
### Related to key trust
[Return to Top](#technology-and-terms)
## On-premises Deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises resources that are accessed using Active Directory identities. On-premises deployments support domain joined devices. The on-premises deployment model supports two authentication trust types, key trust and certificate trust.
- [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type)
- [Hybrid Azure AD join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### Related topics
[Cloud Deployment](#cloud-deployment), [Deployment Type](#deployment-type), [Hybrid Deployment](#hybrid-deployment)
### More information about key trust
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Managed environment
Managed environments are for non-federated environments where Azure AD manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
### Related to managed environment
- [Federated environment](#federated-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash synchronization](#password-hash-sync)
## On-premises deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises resources that are accessed using Active Directory identities. On-premises deployments support domain joined devices. The on-premises deployment model supports two authentication trust types, key trust and certificate trust.
### Related to on-premises deployment
- [Cloud deployment](#cloud-deployment)
- [Deployment type](#deployment-type)
- [Hybrid deployment](#hybrid-deployment)
### More information about on-premises deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
[Return to Top](hello-how-it-works-technology.md)
## Pass-through authentication
Provides a simple password validation for Azure AD authentication services using a software agent running on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Allows your users to sign in to both on-premises and Office 365 resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Office 365. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and logon hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### Related topics
[Federated Environment](#federated-environment), [Managed Environment](#managed-environment), [Password Hash Synchronization](#password-hash-sync)
Pass-through authentication provides a simple password validation for Azure AD authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Allows your users to sign in to both on-premises and Office 365 resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Office 365. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### Related to pass-through authentication
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/security/azure-ad-choose-authn)
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Password hash synchronization](#password-hash-sync)
[Return to Top](hello-how-it-works-technology.md)
## Password Hash Sync
The simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
### More information about pass-through authentication
### Related topics
[Federated Environment](#federated-environment), [Managed Environment](#managed-environment), [Pass-through authentication](#pass-through-authentication)
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
### More information
- [Choosing the right authentication method for your Azure Active Directory hybrid identity solution](/azure/security/azure-ad-choose-authn)
## Password hash sync
[Return to Top](hello-how-it-works-technology.md)
## Primary Refresh Token
SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a Primary Refresh Token (PRT). This is a [JSON Web Token](http://openid.net/specs/draft-jones-json-web-token-07.html) containing claims about both the user and the device.
Password hash sync is the simplest way to enable authentication for on-premises directory objects in Azure AD. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Office 365 and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Azure AD so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Azure AD or stored in Azure AD in clear text. Some premium features of Azure AD, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Azure AD when they are on their corporate devices and connected to your corporate network.
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and hybrid Azure AD-joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.).
### Related to password hash sync
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. Please also note that the PRT contains information about the device. This means that if you have any [device-based conditional access](/azure/active-directory/active-directory-conditional-access-policy-connected-applications) policy set on an application, without the PRT, access will be denied.
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
[Return to Top](#technology-and-terms)
## Storage Root Key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### More information about password hash sync
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Endorsement Key](#endorsement-key), [Trusted Platform Module](#trusted-platform-module)
[Choose the right authentication method for your Azure AD hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
### More information
[TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
## Primary refresh token
Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Azure AD joined and hybrid Azure AD-joined devices. For personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com.
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied.
## Storage root key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048-bits length). The SRK has a major role and is used to protect TPM keys, so that these keys can't be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### Related to storage root key
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Trusted platform module](#trusted-platform-module)
### More information about storage root key
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
[Return to Top](hello-how-it-works-technology.md)
## Trust type
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type does not affect authentication to Azure Active Directory. Windows Hello for Business authentication to Azure Active Directory always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### Related topics
[Certificate Trust](#certificate-trust), [Hybrid Deployment](#hybrid-deployment), [Key Trust](#key-trust), [On-premises Deployment](#on-premises-deployment)
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Azure AD. Windows Hello for Business authentication to Azure AD always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### More information
- [Windows Hello for Business Planning Guide](hello-planning-guide.md)
### Related to trust type
[Return to Top](hello-how-it-works-technology.md)
## Trusted Platform Module
- [Certificate trust](#certificate-trust)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
A Trusted Platform Module (TPM) is a hardware component that provides unique security features.<br>
### More information about trust type
Windows leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Trusted platform module
A trusted platform module (TPM) is a hardware component that provides unique security features.
Windows uses security characteristics of a TPM for the following functions:
- Measuring boot integrity sequence. Based on that sequence, it automatically unlocks BitLocker-protected drives
- Protecting credentials
- Health attestation
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). There are currently two versions of the TPM specification produced by TCG that aren't compatible with each other:
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
@ -290,27 +355,29 @@ Windows recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG.
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
- Update cryptography strength to meet modern security needs
- Support for SHA-256 for PCRs
- Support for HMAC command
- Support for SHA-256 for PCRs
- Support for HMAC command
- Cryptographic algorithms flexibility to support government needs
- TPM 1.2 is severely restricted in terms of what algorithms it can support
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
- TPM 1.2 is severely restricted in terms of what algorithms it can support
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
- Consistency across implementations
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single component:
- A RSA 2048-bit key generator
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single component:
- An RSA 2048-bit key generator
- A random number generator
- Nonvolatile memory for storing EK, SRK, and AIK keys
- A cryptographic engine to encrypt, decrypt, and sign
- Volatile memory for storing the PCRs and RSA keys
### Related to trusted platform module
### Related topics
[Attestation Identity Keys](#attestation-identity-keys), [Endorsement Key](#endorsement-key), [Storage Root Key](#storage-root-key)
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
### More information
- [TPM Library Specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
### More information about trusted platform module
[Return to Top](hello-how-it-works-technology.md)
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)

View File

@ -288,11 +288,13 @@ Sign-in to the issuing certificate authority or management workstations with _Do
7. On the **Security** tab, click **Add**.
8. Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
8. Select **Object Types**, then, in the window that appears, choose **Computers** and click **OK**.
9. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
9. Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
10. Click on the **Apply** to save changes and close the console.
10. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
11. Click on the **Apply** to save changes and close the console.
### Create an Azure AD joined Windows Hello for Business authentication certificate template
@ -334,7 +336,7 @@ The certificate authority may only issue certificates for certificate templates
> [!Important]
> Ensure you publish the **AADJ WHFB Authentication** certificate templates to the certificate authority that Microsoft Intune uses by way of the NDES servers. The NDES configuration asks you to choose a certificate authority from which it requests certificates. You need to publish that certificate templates to that issuing certificate authority. The **NDES-Intune Authentication** certificate is directly enrolled and can be published to any certificate authority.
Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
Sign in to the certificate authority or management workstations with an _enterprise admin_ -equivalent credential.
1. Open the **Certificate Authority** management console.
@ -849,7 +851,7 @@ Sign-in a workstation with access equivalent to a _domain user_.
![Azure AD new group creation.](images/aadjcert/azureadcreatewhfbcertgroup.png)
8. Click **Members**. Use the **Select members** pane to add members to this group. When finished click **Select**.
8. Click **Members**. Use the **Select members** pane to add members to this group. When finished, click **Select**.
9. Click **Create**.

View File

@ -21,7 +21,7 @@ ms.reviewer:
- Hybrid Deployment
- Key trust
Windows Hello for Business deployments rely on certificates. Hybrid deployments uses publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
Windows Hello for Business deployments rely on certificates. Hybrid deployments use publicly issued server authentication certificates to validate the name of the server to which they are connecting and to encrypt the data that flows them and the client computer.
All deployments use enterprise issued certificates for domain controllers as a root of trust.
@ -79,11 +79,11 @@ The certificate template is configured to supersede all the certificate template
> [!NOTE]
> The domain controller's certificate must chain to a root in the NTAuth store. By default, the Active Directory Certificate Authority's root certificate is added to the NTAuth store. If you are using a third-party CA, this may not be done by default. If the domain controller certificate does not chain to a root in the NTAuth store, user authentication will fail.
>you can view
>To see all certificates in the NTAuth store, use the following command:
>
>'''powershell
>Certutil -view
>Publish Certificate Templates to a Certificate Authority
> `Certutil -viewstore -enterprise NTAuth`
### Publish Certificate Templates to a Certificate Authority
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
@ -95,7 +95,7 @@ Sign-in to the certificate authority or management workstations with an _enterpr
4. Right-click the **Certificate Templates** node. Click **New**, and click **Certificate Template** to issue.
5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)** template you created in the previous steps. Click **OK** to publish the selected certificate templates to the certificate authority.
6. If you published the **Domain Controller Authentication (Kerberos)** certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
* To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
- To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
7. Close the console.
### Unpublish Superseded Certificate Templates

View File

@ -75,7 +75,7 @@ The following table lists the MDM policy settings that you can configure for Win
|UsePassportForWork|Device or user|True|<p>True: Windows Hello for Business will be provisioned for all users on the device.<p>False: Users will not be able to provision Windows Hello for Business. <div class="alert"> **Note:** If Windows Hello for Business is enabled, and then the policy is changed to False, users who previously set up Windows Hello for Business can continue to use it, but will not be able to set up Windows Hello for Business on other devices</div>|
|RequireSecurityDevice|Device or user|False|<p>True: Windows Hello for Business will only be provisioned using TPM.<p>False: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM is not available.|
|ExcludeSecurityDevice<p>TPM12|Device|False|Added in Windows 10, version 1703<p>True: TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business.<p>False: TPM revision 1.2 modules will be allowed to be used with Windows Hello for Business.|
|EnablePinRecovery|Device or use|False|<p>Added in Windows 10, version 1703<p>True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset.<p>False: Windows Hello for Business does not create or store a PIN recovery secret. PIN reset does not use the Azure-based PIN recovery service.For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
|EnablePinRecovery|Device or use|False|<p>Added in Windows 10, version 1703<p>True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset.<p>False: Windows Hello for Business does not create or store a PIN recovery secret. PIN reset does not use the Azure-based PIN recovery service. For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
### Biometrics
@ -93,7 +93,7 @@ The following table lists the MDM policy settings that you can configure for Win
|Special characters|Device or user|2|<p>0: Special characters are allowed. <p>1: At least one special character is required. <p>2: Special characters are not allowed.|
|Uppercase letters|Device or user|2|<p>0: Uppercase letters are allowed. <p>1: At least one uppercase letter is required.<p>2: Uppercase letters are not allowed.|
|Maximum PIN length |Device or user|127 |<p>Maximum length that can be set is 127. Maximum length cannot be less than minimum setting.|
|Minimum PIN length|Device or user|4|<p>Minimum length that can be set is 4. Minimum length cannot be greater than maximum setting.|
|Minimum PIN length|Device or user|6|<p>Minimum length that can be set is 6. Minimum length cannot be greater than maximum setting.|
|Expiration |Device or user|0|<p>Integer value specifies the period of time (in days) that a PIN can be used before the system requires the user to change it. The largest number you can configure for this policy setting is 730. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then the user's PIN will never expire.|
|History|Device or user|0|<p>Integer value that specifies the number of past PINs that can be associated to a user account that can't be reused. The largest number you can configure for this policy setting is 50. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then storage of previous PINs is not required.|
@ -114,7 +114,7 @@ Policies for Windows Hello for Business are enforced using the following hierarc
Feature enablement policy and certificate trust policy are grouped together and enforced from the same source (either GP or MDM), based on the rule above. The Use Passport for Work policy is used to determine the winning policy source.
All PIN complexity policies, are grouped separately from feature enablement and are enforced from a single policy source. Use a hardware security device and RequireSecurityDevice enforcement are also grouped together with PIN complexity policy. Conflict resolution for other Windows Hello for Business policies are enforced on a per policy basis.
All PIN complexity policies are grouped separately from feature enablement and are enforced from a single policy source. Use a hardware security device and RequireSecurityDevice enforcement are also grouped together with PIN complexity policy. Conflict resolution for other Windows Hello for Business policies are enforced on a per policy basis.
>[!NOTE]
> Windows Hello for Business policy conflict resolution logic does not respect the ControlPolicyConflict/MDMWinsOverGP policy in the Policy CSP.

View File

@ -37,37 +37,37 @@ Windows Hello lets users authenticate to:
- A Microsoft account.
- An Active Directory account.
- A Microsoft Azure Active Directory (Azure AD) account.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://go.microsoft.com/fwlink/p/?LinkId=533889) authentication.
- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.
After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.
As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization.
As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization.
## Biometric sign-in
Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials.
- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well.
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is significantly more reliable and less error-prone. Most existing fingerprint readers (whether external or integrated into laptops or USB keyboards) work with Windows 10 and Windows 11.
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is more reliable and less error-prone. Most existing fingerprint readers work with Windows 10 and Windows 11, whether they're external or integrated into laptops or USB keyboards.
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data. For more information about biometric authentication with Windows Hello for Business, see [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md).
## The difference between Windows Hello and Windows Hello for Business
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it is set up, but can use a simple password hash depending on an individual's account type. This configuration is referred to as Windows Hello convenience PIN and it is not backed by asymmetric (public/private key) or certificate-based authentication.
- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on an individual's account type. This configuration is referred to as Windows Hello convenience PIN and it's not backed by asymmetric (public/private key) or certificate-based authentication.
- **Windows Hello for Business**, which is configured by Group Policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This makes it much more secure than **Windows Hello convenience PIN**.
- **Windows Hello for Business**, which is configured by group policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This behavior makes it more secure than **Windows Hello convenience PIN**.
## Benefits of Windows Hello
Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed.
You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they are entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials.
You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they're entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials.
In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows from the combination of Hello keys and gesture that this is a verified identity and provides an authentication token that allows Windows to access resources and services.
In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services.
>[!NOTE]
>Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password.
> [!NOTE]
> Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password.
:::image type="content" alt-text="How authentication works in Windows Hello." source="images/authflow.png" lightbox="images/authflow.png":::
@ -79,15 +79,15 @@ Windows Hello helps protect user identities and user credentials. Because the us
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
- Identity provider (such as Active Directory, Azure AD, or a Microsoft account) validates user identity and maps the Windows Hello public key to a user account during the registration step.
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Azure AD, or a Microsoft account.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture does not roam between devices and is not shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture doesn't roam between devices and isn't shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- Personal (Microsoft account) and corporate (Active Directory or Azure AD) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
@ -97,25 +97,21 @@ For details, see [How Windows Hello for Business works](hello-how-it-works.md).
## Comparing key-based and certificate-based authentication
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that do not use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 21H2, there is a feature called cloud trust for hybrid deployments which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but does not require certificates on the domain controller.
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud trust for hybrid deployments, which uses Azure AD as the root of trust. Cloud trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
Windows Hello for Business with a key, including cloud trust, does not support supplied credentials for RDP. RDP does not support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
Windows Hello for Business with a key, including cloud trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Windows Defender Remote Credential Guard](../remote-credential-guard.md).
## Learn more
[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/en-us/itshowcase/implementing-strong-user-authentication-with-windows-hello-for-business)
[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/insidetrack/implementing-strong-user-authentication-with-windows-hello-for-business)
[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/en-us/itshowcase/implementing-windows-hello-for-business-at-microsoft)
[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/insidetrack/implementing-windows-hello-for-business-at-microsoft)
[Introduction to Windows Hello](/learn/?l=eH7yoY2BC_9106218949), video presentation on Microsoft Virtual Academy
[Windows Hello for Business: Authentication](https://youtu.be/WPmzoP_vMek): In this video, learn about Windows Hello for Business and how it's used to sign-in and access resources.
[Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication)
[Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security!](https://go.microsoft.com/fwlink/p/?LinkId=533890)
[Windows 10: The End Game for Passwords and Credential Theft?](https://go.microsoft.com/fwlink/p/?LinkId=533891)
## Related topics
## Related articles
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)

View File

@ -8,8 +8,8 @@ manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
localizationpriority: medium
ms.date: 08/19/2018
ms.reviewer:
ms.date: 07/26/2022
ms.reviewer: paoloma
---
# Windows Hello for Business Videos
@ -46,22 +46,4 @@ Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business pr
Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business authentication works.
> [!VIDEO https://www.youtube.com/embed/WPmzoP_vMek]
## Windows Hello for Business user enrollment experience
The user experience for Windows Hello for Business occurs after user sign-in, after you deploy Windows Hello for Business policy settings to your environment.
> [!VIDEO https://www.youtube.com/embed/FJqHPTZTpNM]
</br>
> [!VIDEO https://www.youtube.com/embed/etXJsZb8Fso]
## Windows Hello for Business forgotten PIN user experience
If the user can sign-in with a password, they can reset their PIN by clicking the "I forgot my PIN" link in settings. Beginning with the Fall Creators Update, users can reset their PIN above the lock screen by clicking the "I forgot my PIN" link on the PIN credential provider.
> [!VIDEO https://www.youtube.com/embed/KcVTq8lTlkI]
For on-premises deployments, devices must be well connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid customers can on-board their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs without access to their corporate network.
> [!VIDEO https://www.youtube.com/embed/WPmzoP_vMek]

Binary file not shown.

After

Width:  |  Height:  |  Size: 85 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 33 KiB

After

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 159 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 133 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 225 KiB

After

Width:  |  Height:  |  Size: 225 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 215 KiB

After

Width:  |  Height:  |  Size: 210 KiB

View File

@ -1,10 +1,10 @@
---
title: VPN security features (Windows 10 and Windows 11)
title: VPN security features
description: Learn about security features for VPN, including LockDown VPN, Windows Information Protection integration with VPN, and traffic filters.
ms.prod: m365-security
author: dansimp
ms.localizationpriority: medium
ms.date: 09/03/2021
ms.date: 07/21/2022
ms.reviewer:
manager: dansimp
ms.author: dansimp
@ -17,6 +17,12 @@ ms.author: dansimp
- Windows 11
## Hyper-V based containers and VPN
Windows supports different kinds of Hyper-V based containers. This support includes, but isn't limited to, Microsoft Defender Application Guard and Windows Sandbox. When you use 3rd party VPN solutions, these Hyper-V based containers may not be able to seamlessly connect to the internet. Additional configurational changes might be needed to resolve connectivity issues.
For example, for more information on a workaround for Cisco AnyConnect VPN, see [Cisco AnyConnect Secure Mobility Client Administrator Guide: Connectivity issues with VM-based subsystems](https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect410/administration/guide/b-anyconnect-admin-guide-4-10/troubleshoot-anyconnect.html#Cisco_Task_in_List_GUI.dita_3a9a8101-f034-4e9b-b24a-486ee47b5e9f).
## Windows Information Protection (WIP) integration with VPN
Windows Information Protection provides capabilities allowing the separation and protection of enterprise data against disclosure across both company and personally owned devices, without requiring additional changes to the environments or the apps themselves. Additionally, when used with Rights Management Services (RMS), WIP can help to protect enterprise data locally.
@ -85,4 +91,4 @@ Deploy this feature with caution, as the resultant connection will not be able t
- [VPN and conditional access](vpn-conditional-access.md)
- [VPN name resolution](vpn-name-resolution.md)
- [VPN auto-triggered profile options](vpn-auto-trigger-profile.md)
- [VPN profile options](vpn-profile-options.md)
- [VPN profile options](vpn-profile-options.md)

View File

@ -16,7 +16,7 @@ metadata:
ms.author: dansimp #Required; microsoft alias of author; optional team alias.
ms.date: 09/20/2021
localization_priority: Priority
# linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | video | whats-new
landingContent:
@ -156,7 +156,7 @@ landingContent:
- text: Microsoft Security Development Lifecycle
url: threat-protection/msft-security-dev-lifecycle.md
- text: Microsoft Bug Bounty
url: /microsoft-365/security/intelligence/microsoft-bug-bounty-program.md
url: /microsoft-365/security/intelligence/microsoft-bug-bounty-program
- text: Common Criteria Certifications
url: threat-protection/windows-platform-common-criteria.md
- text: Federal Information Processing Standard (FIPS) 140 Validation

View File

@ -85,7 +85,23 @@ These requirements help protect you from rootkits while allowing you to run any
To prevent malware from abusing these options, the user must manually configure the UEFI firmware to trust a non-certified bootloader or to turn off Secure Boot. Software can't change the Secure Boot settings.
Like most mobile devices, ARM-based Certified For Windows RT devices, such as the Microsoft Surface RT device, are designed to run only Windows 8.1. Therefore, Secure Boot can't be turned off, and you can't load a different OS. Fortunately, there's a large market of ARM processor devices designed to run other operating systems.
The default state of Secure Boot has a wide circle of trust which can result in customers trusting boot components they may not need. Since the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for all Linux distributions, trusting the Microsoft 3rd Party UEFI CA signature in the UEFI database increase s the attack surface of systems. A customer who intended to only trust and boot a single Linux distribution will trust all distributions much more than their desired configuration. A vulnerability in any of the bootloaders exposes the system and places the customer at risk of exploit for a bootloader they never intended to use, as seen in recent vulnerabilities, for example [with the GRUB bootloader](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) or [firmware-level rootkit]( https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit) affecting boot components. [Secured-core PCs](/windows-hardware/design/device-experiences/OEM-highly-secure-11) require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible.
To trust and boot operating systems, like Linux, and components signed by the UEFI signature, Secured-core PCs can be configured in the BIOS menu to add the signature in the UEFI database by following these steps:
1. Open the firmware menu, either:
- Boot the PC, and press the manufacturers key to open the menus. Common keys used: Esc, Delete, F1, F2, F10, F11, or F12. On tablets, common buttons are Volume up or Volume down. During startup, theres often a screen that mentions the key. If theres not one, or if the screen goes by too fast to see it, check your manufacturers site.
- Or, if Windows is already installed, from either the Sign on screen or the Start menu, select Power ( ) > hold Shift while selecting Restart. Select Troubleshoot > Advanced options > UEFI Firmware settings.
2. From the firmware menu navigate to Security > Secure Boot and select the option to trust the “3rd Party CA”.
3. Save changes and exit.
Microsoft continues to collaborate with Linux and IHV ecosystem partners to design least privileged features to help you stay secure and opt-in trust for only the publishers and components you trust.
Like most mobile devices, Arm-based devices, such as the Microsoft Surface RT device, are designed to run only Windows 8.1. Therefore, Secure Boot can't be turned off, and you can't load a different OS. Fortunately, there's a large market of ARM processor devices designed to run other operating systems.
## Trusted Boot

View File

@ -1,22 +1,26 @@
---
title: Make & verify an EFS Data Recovery Agent certificate (Windows 10)
description: Follow these steps to create, verify, and perform a quick recovery by using a Encrypting File System (EFS) Data Recovery Agent (DRA) certificate.
title: Create an EFS Data Recovery Agent certificate
description: Follow these steps to create, verify, and perform a quick recovery by using an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate.
ms.prod: m365-security
ms.localizationpriority: medium
author: dansimp
ms.author: dansimp
manager: dansimp
author: aczechowski
ms.author: aaroncz
manager: dougeby
ms.reviewer: rafals
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 03/05/2019
ms.reviewer:
ms.topic: how-to
ms.date: 07/15/2022
---
# Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate
**Applies to:**
[!INCLUDE [Deprecate Windows Information Protection](includes/wip-deprecation.md)]
<!-- 6010051 -->
- Windows 10, version 1607 and later
_Applies to:_
- Windows 10
- Windows 11
If you don't already have an EFS DRA certificate, you'll need to create and extract one from your system before you can use Windows Information Protection (WIP), formerly known as enterprise data protection (EDP), in your organization. For the purposes of this section, we'll use the file name EFSDRA; however, this name can be replaced with anything that makes sense to you.
@ -123,7 +127,7 @@ Starting with Windows 10, version 1709, WIP includes a data recovery feature tha
To help make sure employees can always access files, WIP creates an auto-recovery key that's backed up to their Azure Active Directory (Azure AD) identity.
The employee experience is based on sign in with an Azure AD work account. The employee can either:
The employee experience is based on signing in with an Azure AD work account. The employee can either:
- Add a work account through the **Windows Settings > Accounts > Access work or school > Connect** menu.
@ -159,7 +163,3 @@ After signing in, the necessary WIP key info is automatically downloaded and emp
- [Create a Windows Information Protection (WIP) policy using Microsoft Endpoint Configuration Manager](create-wip-policy-using-configmgr.md)
- [Creating a Domain-Based Recovery Agent](/previous-versions/tn-archive/cc875821(v=technet.10)#EJAA)
>[!Note]
>Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this topic, see [Contributing to this article](https://github.com/Microsoft/windows-itpro-docs/blob/master/CONTRIBUTING.md).

View File

@ -1,24 +1,28 @@
---
title: Create and deploy a Windows Information Protection (WIP) policy using Microsoft Endpoint Manager (Windows 10)
description: Use Configuration Manager to make & deploy a Windows Information Protection (WIP) policy. Choose protected apps, WIP-protection level, and find enterprise data.
ms.reviewer:
title: Create and deploy a WIP policy in Configuration Manager
description: Use Microsoft Endpoint Configuration Manager to create and deploy a Windows Information Protection (WIP) policy. Choose protected apps, WIP-protection level, and find enterprise data.
ms.prod: m365-security
ms.localizationpriority: medium
author: dansimp
ms.author: dansimp
manager: dansimp
author: aczechowski
ms.author: aaroncz
manager: dougeby
ms.reviewer: rafals
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 01/09/2020
ms.topic: how-to
ms.date: 07/15/2022
---
# Create and deploy a Windows Information Protection (WIP) policy using Microsoft Endpoint Configuration Manager
**Applies to:**
# Create and deploy a Windows Information Protection policy in Configuration Manager
- Windows 10, version 1607 and later
- Microsoft Endpoint Configuration Manager
[!INCLUDE [Deprecate Windows Information Protection](includes/wip-deprecation.md)]
<!-- 6010051 -->
Configuration Manager helps you create and deploy your Windows Information Protection (WIP) policy, including letting you choose your protected apps, your WIP-protection mode, and how to find enterprise data on the network.
_Applies to:_
- Windows 10
- Windows 11
Microsoft Endpoint Configuration Manager helps you create and deploy your Windows Information Protection (WIP) policy. You can choose your protected apps, your WIP-protection mode, and how to find enterprise data on the network.
## Add a WIP policy
After you've installed and set up Configuration Manager for your organization, you must create a configuration item for WIP, which in turn becomes your WIP policy.
@ -28,18 +32,18 @@ After you've installed and set up Configuration Manager for your organization, y
**To create a configuration item for WIP**
1. Open the Configuration Manager console, click the **Assets and Compliance** node, expand the **Overview** node, expand the **Compliance Settings** node, and then expand the **Configuration Items** node.
1. Open the Configuration Manager console, select the **Assets and Compliance** node, expand the **Overview** node, expand the **Compliance Settings** node, and then expand the **Configuration Items** node.
![Configuration Manager, Configuration Items screen.](images/wip-configmgr-addpolicy.png)
2. Click the **Create Configuration Item** button.<p>
2. Select the **Create Configuration Item** button.<p>
The **Create Configuration Item Wizard** starts.
![Create Configuration Item wizard, define the configuration item and choose the configuration type.](images/wip-configmgr-generalscreen.png)
3. On the **General Information screen**, type a name (required) and an optional description for your policy into the **Name** and **Description** boxes.
4. In the **Specify the type of configuration item you want to create** area, pick the option that represents whether you use Configuration Manager for device management, and then click **Next**.
4. In the **Specify the type of configuration item you want to create** area, pick the option that represents whether you use Configuration Manager for device management, and then select **Next**.
- **Settings for devices managed with the Configuration Manager client:** Windows 10
@ -47,11 +51,11 @@ The **Create Configuration Item Wizard** starts.
- **Settings for devices managed without the Configuration Manager client:** Windows 8.1 and Windows 10
5. On the **Supported Platforms** screen, click the **Windows 10** box, and then click **Next**.
5. On the **Supported Platforms** screen, select the **Windows 10** box, and then select **Next**.
![Create Configuration Item wizard, choose the supported platforms for the policy.](images/wip-configmgr-supportedplat.png)
6. On the **Device Settings** screen, click **Windows Information Protection**, and then click **Next**.
6. On the **Device Settings** screen, select **Windows Information Protection**, and then select **Next**.
![Create Configuration Item wizard, choose the Windows Information Protection settings.](images/wip-configmgr-devicesettings.png)
@ -71,7 +75,7 @@ For this example, we're going to add Microsoft OneNote, a store app, to the **Ap
**To add a store app**
1. From the **App rules** area, click **Add**.
1. From the **App rules** area, select **Add**.
The **Add app rule** box appears.
@ -79,7 +83,7 @@ For this example, we're going to add Microsoft OneNote, a store app, to the **Ap
2. Add a friendly name for your app into the **Title** box. In this example, it's *Microsoft OneNote*.
3. Click **Allow** from the **Windows Information Protection mode** drop-down list.
3. Select **Allow** from the **Windows Information Protection mode** drop-down list.
Allow turns on WIP, helping to protect that app's corporate data through the enforcement of WIP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from WIP restrictions](#exempt-apps-from-wip-restrictions) section.
@ -87,7 +91,7 @@ For this example, we're going to add Microsoft OneNote, a store app, to the **Ap
The box changes to show the store app rule options.
5. Type the name of the app and the name of its publisher, and then click **OK**. For this UWP app example, the **Publisher** is `CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US` and the **Product name** is `Microsoft.Office.OneNote`.
5. Type the name of the app and the name of its publisher, and then select **OK**. For this UWP app example, the **Publisher** is `CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US` and the **Product name** is `Microsoft.Office.OneNote`.
If you don't know the publisher or product name, you can find them for both desktop devices by following these steps.
@ -131,7 +135,7 @@ For this example, we're going to add Internet Explorer, a desktop app, to the **
**To add a desktop app to your policy**
1. From the **App rules** area, click **Add**.
1. From the **App rules** area, select **Add**.
The **Add app rule** box appears.
@ -139,7 +143,7 @@ For this example, we're going to add Internet Explorer, a desktop app, to the **
2. Add a friendly name for your app into the **Title** box. In this example, it's *Internet Explorer*.
3. Click **Allow** from the **Windows Information Protection mode** drop-down list.
3. Select **Allow** from the **Windows Information Protection mode** drop-down list.
Allow turns on WIP, helping to protect that app's corporate data through the enforcement of WIP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from WIP restrictions](#exempt-apps-from-wip-restrictions) section.
@ -147,15 +151,15 @@ For this example, we're going to add Internet Explorer, a desktop app, to the **
The box changes to show the desktop app rule options.
5. Pick the options you want to include for the app rule (see table), and then click **OK**.
5. Pick the options you want to include for the app rule (see table), and then select **OK**.
|Option|Manages|
|--- |--- |
|All fields left as "*"|All files signed by any publisher. (Not recommended.)|
|**Publisher** selected|All files signed by the named publisher.This might be useful if your company is the publisher and signer of internal line-of-business apps.|
|**Publisher** selected|All files signed by the named publisher. This might be useful if your company is the publisher and signer of internal line-of-business apps.|
|**Publisher** and **Product Name** selected|All files for the specified product, signed by the named publisher.|
|**Publisher**, **Product Name**, and **Binary name** selected|Any version of the named file or package for the specified product, signed by the named publisher.|
|**Publisher**, **Product Name**, **Binary name**, and **File Version, and above**, selected|Specified version or newer releases of the named file or package for the specified product, signed by the named publisher.This option is recommended for enlightened apps that weren't previously enlightened.|
|**Publisher**, **Product Name**, **Binary name**, and **File Version, and above**, selected|Specified version or newer releases of the named file or package for the specified product, signed by the named publisher. This option is recommended for enlightened apps that weren't previously enlightened.|
|**Publisher**, **Product Name**, **Binary name**, and **File Version, And below** selected|Specified version or older releases of the named file or package for the specified product, signed by the named publisher.|
|**Publisher**, **Product Name**, **Binary name**, and **File Version, Exactly** selected|Specified version of the named file or package for the specified product, signed by the named publisher.|
@ -185,31 +189,31 @@ For this example, we're going to add an AppLocker XML file to the **App Rules**
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then click **Packaged App Rules**.
2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then select **Packaged App Rules**.
![Local security snap-in, showing the Packaged app Rules.](images/intune-local-security-snapin.png)
3. Right-click in the right-hand pane, and then click **Create New Rule**.
3. Right-click in the right-hand pane, and then select **Create New Rule**.
The **Create Packaged app Rules** wizard appears.
4. On the **Before You Begin** page, click **Next**.
4. On the **Before You Begin** page, select **Next**.
![Create a Packaged app Rules wizard and showing the Before You Begin page.](images/intune-applocker-before-begin.png)
5. On the **Permissions** page, make sure the **Action** is set to **Allow** and the **User or group** is set to **Everyone**, and then click **Next**.
5. On the **Permissions** page, make sure the **Action** is set to **Allow** and the **User or group** is set to **Everyone**, and then select **Next**.
![Create Packaged app Rules wizard, set action to Allow.](images/intune-applocker-permissions.png)
6. On the **Publisher** page, click **Select** from the **Use an installed packaged app as a reference** area.
6. On the **Publisher** page, select **Select** from the **Use an installed packaged app as a reference** area.
![Create Packaged app Rules wizard, select use an installed packaged app.](images/intune-applocker-publisher.png)
7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then click **OK**. For this example, we're using Microsoft Photos.
7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then select **OK**. For this example, we're using Microsoft Photos.
![Create Packaged app Rules wizard, select application and click ok.](images/intune-applocker-select-apps.png)
8. On the updated **Publisher** page, click **Create**.
8. On the updated **Publisher** page, select **Create**.
![Create Packaged app Rules wizard, showing the Microsoft Photos on the Publisher page.](images/intune-applocker-publisher-with-app.png)
@ -217,15 +221,15 @@ For this example, we're going to add an AppLocker XML file to the **App Rules**
![Local security snap-in, showing the new rule.](images/intune-local-security-snapin-updated.png)
10. In the left pane, right-click on **AppLocker**, and then click **Export policy**.
10. In the left pane, right-click on **AppLocker**, and then select **Export policy**.
The **Export policy** box opens, letting you export and save your new policy as XML.
![Local security snap-in, showing the Export Policy option.](images/intune-local-security-export.png)
11. In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then click **Save**.
11. In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then select **Save**.
The policy is saved and you'll see a message that says 1 rule was exported from the policy.
The policy is saved and you'll see a message that says one rule was exported from the policy.
**Example XML file**<br>
This is the XML file that AppLocker creates for Microsoft Photos.
@ -251,7 +255,7 @@ For this example, we're going to add an AppLocker XML file to the **App Rules**
**To import your Applocker policy file app rule using Configuration Manager**
1. From the **App rules** area, click **Add**.
1. From the **App rules** area, select **Add**.
The **Add app rule** box appears.
@ -259,7 +263,7 @@ For this example, we're going to add an AppLocker XML file to the **App Rules**
2. Add a friendly name for your app into the **Title** box. In this example, it's *Allowed app list*.
3. Click **Allow** from the **Windows Information Protection mode** drop-down list.
3. Select **Allow** from the **Windows Information Protection mode** drop-down list.
Allow turns on WIP, helping to protect that app's corporate data through the enforcement of WIP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from WIP restrictions](#exempt-apps-from-wip-restrictions) section.
@ -267,7 +271,7 @@ For this example, we're going to add an AppLocker XML file to the **App Rules**
The box changes to let you import your AppLocker XML policy file.
5. Click the ellipsis (...) to browse for your AppLocker XML file, click **Open**, and then click **OK** to close the **Add app rule** box.
5. Select the ellipsis (...) to browse for your AppLocker XML file, select **Open**, and then select **OK** to close the **Add app rule** box.
The file is imported and the apps are added to your **App Rules** list.
@ -276,25 +280,25 @@ If you're running into compatibility issues where your app is incompatible with
**To exempt a store app, a desktop app, or an AppLocker policy file app rule**
1. From the **App rules** area, click **Add**.
1. From the **App rules** area, select **Add**.
The **Add app rule** box appears.
2. Add a friendly name for your app into the **Title** box. In this example, it's *Exempt apps list*.
3. Click **Exempt** from the **Windows Information Protection mode** drop-down list.
3. Select **Exempt** from the **Windows Information Protection mode** drop-down list.
Be aware that when you exempt apps, they're allowed to bypass the WIP restrictions and access your corporate data. To allow apps, see [Add app rules to your policy](#add-app-rules-to-your-policy) in this article.
When you exempt apps, they're allowed to bypass the WIP restrictions and access your corporate data. To allow apps, see [Add app rules to your policy](#add-app-rules-to-your-policy) in this article.
4. Fill out the rest of the app rule info, based on the type of rule you're adding:
- **Store app.** Follow the **Publisher** and **Product name** instructions in the [Add a store app rule to your policy](#add-a-store-app-rule-to-your-policy) section of this topic.
- **Store app.** Follow the **Publisher** and **Product name** instructions in the [Add a store app rule to your policy](#add-a-store-app-rule-to-your-policy) section of this article.
- **Desktop app.** Follow the **Publisher**, **Product name**, **Binary name**, and **Version** instructions in the [Add a desktop app rule to your policy](#add-a-desktop-app-rule-to-your-policy) section of this topic.
- **Desktop app.** Follow the **Publisher**, **Product name**, **Binary name**, and **Version** instructions in the [Add a desktop app rule to your policy](#add-a-desktop-app-rule-to-your-policy) section of this article.
- **AppLocker policy file.** Follow the **Import** instructions in the [Add an AppLocker policy file](#add-an-applocker-policy-file) section of this topic, using a list of exempted apps.
- **AppLocker policy file.** Follow the **Import** instructions in the [Add an AppLocker policy file](#add-an-applocker-policy-file) section of this article, using a list of exempted apps.
5. Click **OK**.
5. Select **OK**.
## Manage the WIP-protection level for your enterprise data
After you've added the apps you want to protect with WIP, you'll need to apply a management and protection mode.
@ -308,15 +312,15 @@ We recommend that you start with **Silent** or **Override** while verifying with
|-----|------------|
|Block |WIP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.|
|Override |WIP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log. |
|Silent |WIP runs silently, logging inappropriate data sharing, without blocking anything that would've been prompted for employee interaction while in Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or WIP-protected data, are still blocked.|
|Off (not recommended) |WIP is turned off and doesn't help to protect or audit your data.<p>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Be aware that your previous decryption and policy info isn't automatically reapplied if you turn WIP protection back on.|
|Silent |WIP runs silently, logging inappropriate data sharing, without blocking anything that would have been prompted for employee interaction while in Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or WIP-protected data, are still blocked.|
|Off |WIP is turned off and doesn't help to protect or audit your data.<p>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Your previous decryption and policy info isn't automatically reapplied if you turn WIP protection back on. For more information, see [How to disable Windows Information Protection](how-to-disable-wip.md).|
:::image type="content" alt-text="Create Configuration Item wizard, choose your WIP-protection level" source="images/wip-configmgr-appmgmt.png":::
## Define your enterprise-managed identity domains
Corporate identity, usually expressed as your primary internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you've marked as protected by WIP. For example, emails using contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
You can specify multiple domains owned by your enterprise by separating them with the "|" character. For example, (contoso.com|newcontoso.com). With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list.
You can specify multiple domains owned by your enterprise by separating them with the `|` character. For example, `contoso.com|newcontoso.com`. With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list.
**To add your corporate identity**
@ -333,7 +337,7 @@ There are no default locations included with WIP, you must add each of your netw
>Every WIP policy should include policy that defines your enterprise network locations.<br>
>Classless Inter-Domain Routing (CIDR) notation isn't supported for WIP configurations.
**To define where your protected apps can find and send enterprise data on you network**
**To define where your protected apps can find and send enterprise data on your network**
1. Add additional network locations your apps can access by clicking **Add**.
@ -345,7 +349,7 @@ There are no default locations included with WIP, you must add each of your netw
- **Enterprise Cloud Resources**: Specify the cloud resources to be treated as corporate and protected by WIP.
For each cloud resource, you may also optionally specify a proxy server from your Internal proxy servers list to route traffic for this cloud resource. Be aware that all traffic routed through your Internal proxy servers is considered enterprise.
For each cloud resource, you may also optionally specify a proxy server from your internal proxy servers list to route traffic for this cloud resource. All traffic routed through your internal proxy servers is considered enterprise.
If you have multiple resources, you must separate them using the `|` delimiter. If you don't use proxy servers, you must also include the `,` delimiter just before the `|`. For example: URL `<,proxy>|URL <,proxy>`.
@ -358,7 +362,7 @@ There are no default locations included with WIP, you must add each of your netw
>[!Important]
> In some cases, such as when an app connects directly to a cloud resource through an IP address, Windows can't tell whether it's attempting to connect to an enterprise cloud resource or to a personal site. In this case, Windows blocks the connection by default. To stop Windows from automatically blocking these connections, you can add the /*AppCompat*/ string to the setting. For example: URL <,proxy>|URL <,proxy>|/*AppCompat*/.
- **Enterprise Network Domain Names (Required)**: Specify the DNS suffixes used in your environment. All traffic to the fully-qualified domains appearing in this list will be protected.
- **Enterprise Network Domain Names (Required)**: Specify the DNS suffixes used in your environment. All traffic to the fully qualified domains appearing in this list will be protected.
This setting works with the IP ranges settings to detect whether a network endpoint is enterprise or personal on private networks.
@ -408,7 +412,7 @@ There are no default locations included with WIP, you must add each of your netw
**Format examples**: `sts.contoso.com,sts.contoso2.com`
3. Add as many locations as you need, and then click **OK**.
3. Add as many locations as you need, and then select **OK**.
The **Add or edit corporate network definition** box closes.
@ -416,13 +420,13 @@ There are no default locations included with WIP, you must add each of your netw
:::image type="content" alt-text="Create Configuration Item wizard, Add whether to search for additional network settings" source="images/wip-configmgr-optsettings.png":::
- **Enterprise Proxy Servers list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the proxy servers you specified in the network boundary definition as the complete list of proxy servers available on your network. If you clear this box, Windows will search for additional proxy servers in your immediate network. Not configured is the default option.
- **Enterprise Proxy Servers list is authoritative (do not auto-detect).** Select this box if you want Windows to treat the proxy servers you specified in the network boundary definition as the complete list of proxy servers available on your network. If you clear this box, Windows will search for additional proxy servers in your immediate network. Not configured is the default option.
- **Enterprise IP Ranges list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network. Not configured is the default option.
- **Enterprise IP Ranges list is authoritative (do not auto-detect).** Select this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network. Not configured is the default option.
- **Show the Windows Information Protection icon overlay on your allowed apps that are WIP-unaware on corporate files in the File Explorer.** Click this box if you want the Windows Information Protection icon overlay to appear on corporate files in the Save As and File Explorer views. Additionally, for unenlightened but allowed apps, the icon overlay also appears on the app tile and with *Managed* text on the app name in the **Start** menu. Not configured is the default option.
- **Show the Windows Information Protection icon overlay on your allowed apps that are WIP-unaware on corporate files in the File Explorer.** Select this box if you want the Windows Information Protection icon overlay to appear on corporate files in the Save As and File Explorer views. Additionally, for unenlightened but allowed apps, the icon overlay also appears on the app tile and with *Managed* text on the app name in the **Start** menu. Not configured is the default option.
5. In the required **Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data** box, click **Browse** to add a data recovery certificate for your policy.
5. In the required **Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data** box, select **Browse** to add a data recovery certificate for your policy.
![Create Configuration Item wizard, Add a data recovery agent (DRA) certificate.](images/wip-configmgr-dra.png)
@ -452,27 +456,26 @@ After you've decided where your protected apps can access enterprise data on you
- **Allow Azure RMS.** Enables secure sharing of files by using removable media such as USB drives. For more information about how RMS works with WIP, see [Create a WIP policy using Intune](create-wip-policy-using-intune-azure.md). To confirm what templates your tenant has, run [Get-AadrmTemplate](/powershell/module/aadrm/get-aadrmtemplate) from the [AADRM PowerShell module](/azure/information-protection/administer-powershell). If you don't specify a template, WIP uses a key from a default RMS template that everyone in the tenant will have access to.
2. After you pick all of the settings you want to include, click **Summary**.
2. After you pick all of the settings you want to include, select **Summary**.
## Review your configuration choices in the Summary screen
After you've finished configuring your policy, you can review all of your info on the **Summary** screen.
**To view the Summary screen**
- Click the **Summary** button to review your policy choices, and then click **Next** to finish and to save your policy.
- Select the **Summary** button to review your policy choices, and then select **Next** to finish and to save your policy.
![Create Configuration Item wizard, Summary screen for all of your policy choices.](images/wip-configmgr-summaryscreen.png)
A progress bar appears, showing you progress for your policy. After it's done, click **Close** to return to the **Configuration Items** page.
A progress bar appears, showing you progress for your policy. After it's done, select **Close** to return to the **Configuration Items** page.
## Deploy the WIP policy
After you've created your WIP policy, you'll need to deploy it to your organization's devices. For info about your deployment options, see these topics:
- [Operations and Maintenance for Compliance Settings in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/gg699357(v=technet.10))
After you've created your WIP policy, you'll need to deploy it to your organization's devices. For more information about your deployment options, see the following articles:
- [How to Create Configuration Baselines for Compliance Settings in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/gg712268(v=technet.10))
- [Create configuration baselines in Configuration Manager](/mem/configmgr/compliance/deploy-use/create-configuration-baselines)
- [How to Deploy Configuration Baselines in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/hh219289(v=technet.10))
- [How to deploy configuration baselines in Configuration Manager](/mem/configmgr/compliance/deploy-use/deploy-configuration-baselines)
## Related topics
## Related articles
- [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md)

View File

@ -1,21 +1,25 @@
---
title: Create a Windows Information Protection (WIP) policy with MDM using the Azure portal for Microsoft Intune (Windows 10)
description: Learn how to use the Azure portal for Microsoft Intune to create and deploy your Windows Information Protection (WIP) policy to protect data on your network.
title: Create a WIP policy in Intune
description: Learn how to use the Microsoft Endpoint Manager admin center to create and deploy your Windows Information Protection (WIP) policy to protect data on your network.
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
author: aczechowski
ms.author: aaroncz
manager: dougeby
ms.reviewer: rafals
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 05/13/2019
ms.reviewer:
ms.topic: how-to
ms.date: 07/15/2022
---
# Create a Windows Information Protection (WIP) policy using the Azure portal for Microsoft Intune
# Create a Windows Information Protection policy in Microsoft Intune
**Applies to:**
[!INCLUDE [Deprecate Windows Information Protection](includes/wip-deprecation.md)]
<!-- 6010051 -->
- Windows 10, version 1607 and later
_Applies to:_
- Windows 10
- Windows 11
Microsoft Intune has an easy way to create and deploy a Windows Information Protection (WIP) policy. You can choose which apps to protect, the level of protection, and how to find enterprise data on the network. The devices can be fully managed by Mobile Device Management (MDM), or managed by Mobile Application Management (MAM), where Intune manages only the apps on a user's personal device.
@ -118,7 +122,7 @@ If you don't know the Store app publisher or product name, you can find them by
4. Copy the `publisherCertificateName` value into the **Publisher** box and copy the `packageIdentityName` value into the **Name** box of Intune.
>[!Important]
>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app thats using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.
>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that's using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.
>
> For example:
>
@ -147,7 +151,7 @@ If you don't know the Store app publisher or product name, you can find them by
8. Copy the `publisherCertificateName` value and paste it into the **Publisher Name** box and the `packageIdentityName` value into the **Product Name** box of Intune.
>[!Important]
>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app thats using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.
>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that's using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.
>
> For example:
>
@ -164,19 +168,19 @@ To add **Desktop apps**, complete the following fields, based on what results yo
|Field|Manages|
|--- |--- |
|All fields marked as “*”|All files signed by any publisher. (Not recommended and may not work)|
|Publisher only|If you only fill out this field, youll get all files signed by the named publisher. This might be useful if your company is the publisher and signer of internal line-of-business apps.|
|Publisher and Name only|If you only fill out these fields, youll get all files for the specified product, signed by the named publisher.|
|Publisher, Name, and File only|If you only fill out these fields, youll get any version of the named file or package for the specified product, signed by the named publisher.|
|Publisher, Name, File, and Min version only|If you only fill out these fields, youll get the specified version or newer releases of the named file or package for the specified product, signed by the named publisher. This option is recommended for enlightened apps that weren't previously enlightened.|
|Publisher, Name, File, and Max version only|If you only fill out these fields, youll get the specified version or older releases of the named file or package for the specified product, signed by the named publisher.|
|All fields completed|If you fill out all fields, youll get the specified version of the named file or package for the specified product, signed by the named publisher.|
|All fields marked as `*`|All files signed by any publisher. (Not recommended and may not work)|
|Publisher only|If you only fill out this field, you'll get all files signed by the named publisher. This might be useful if your company is the publisher and signer of internal line-of-business apps.|
|Publisher and Name only|If you only fill out these fields, you'll get all files for the specified product, signed by the named publisher.|
|Publisher, Name, and File only|If you only fill out these fields, you'll get any version of the named file or package for the specified product, signed by the named publisher.|
|Publisher, Name, File, and Min version only|If you only fill out these fields, you'll get the specified version or newer releases of the named file or package for the specified product, signed by the named publisher. This option is recommended for enlightened apps that weren't previously enlightened.|
|Publisher, Name, File, and Max version only|If you only fill out these fields, you'll get the specified version or older releases of the named file or package for the specified product, signed by the named publisher.|
|All fields completed|If you fill out all fields, you'll get the specified version of the named file or package for the specified product, signed by the named publisher.|
To add another Desktop app, select the ellipsis **…**. After youve entered the info into the fields, select **OK**.
To add another Desktop app, select the ellipsis ``. After you've entered the info into the fields, select **OK**.
![Microsoft Intune management console: Adding Desktop app info.](images/wip-azure-add-desktop-apps.png)
If youre unsure about what to include for the publisher, you can run this PowerShell command:
If you're unsure about what to include for the publisher, you can run this PowerShell command:
```powershell
Get-AppLockerFileInformation -Path "<path_of_the_exe>"
@ -202,7 +206,7 @@ Regarding to how to get the Product Name for the Apps you wish to Add, contact t
### Import a list of apps
This section covers two examples of using an AppLocker XML file to the **Protected apps** list. Youll use this option if you want to add multiple apps at the same time.
This section covers two examples of using an AppLocker XML file to the **Protected apps** list. You'll use this option if you want to add multiple apps at the same time.
- [Create a Packaged App rule for Store apps](#create-a-packaged-app-rule-for-store-apps)
- [Create an Executable rule for unsigned apps](#create-an-executable-rule-for-unsigned-apps)
@ -233,7 +237,7 @@ For more info about AppLocker, see the [AppLocker](../../threat-protection/windo
![Screenshot of the "Use an installed package app as a reference" radio button selected and the Select button highlighted](images/wip-applocker-secpol-wizard-3.png)
7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then select **OK**. For this example, were using Microsoft Dynamics 365.
7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then select **OK**. For this example, we're using Microsoft Dynamics 365.
![Screenshot of the Select applications list.](images/wip-applocker-secpol-wizard-4.png)
@ -257,7 +261,7 @@ For more info about AppLocker, see the [AppLocker](../../threat-protection/windo
11. In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then select **Save**.
The policy is saved and youll see a message that says one rule was exported from the policy.
The policy is saved and you'll see a message that says one rule was exported from the policy.
**Example XML file**<br>
This is the XML file that AppLocker creates for Microsoft Dynamics 365.
@ -281,7 +285,7 @@ For more info about AppLocker, see the [AppLocker](../../threat-protection/windo
</AppLockerPolicy>
```
12. After youve created your XML file, you need to import it by using Microsoft Intune.
12. After you've created your XML file, you need to import it by using Microsoft Intune.
## Create an Executable rule for unsigned apps
@ -303,7 +307,7 @@ The executable rule helps to create an AppLocker rule to sign any unsigned apps.
![Screenshot with Path conditions selected in the Create Executable Rules wizard.](images/path-condition.png)
7. Select **Browse Folders...** and select the path for the unsigned apps. For this example, were using "C:\Program Files".
7. Select **Browse Folders...** and select the path for the unsigned apps. For this example, we're using "C:\Program Files".
![Screenshot of the Path field of the Create Executable Rules wizard.](images/select-path.png)
@ -315,9 +319,9 @@ The executable rule helps to create an AppLocker rule to sign any unsigned apps.
11. In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then select **Save**.
The policy is saved and youll see a message that says one rule was exported from the policy.
The policy is saved and you'll see a message that says one rule was exported from the policy.
12. After youve created your XML file, you need to import it by using Microsoft Intune.
12. After you've created your XML file, you need to import it by using Microsoft Intune.
**To import a list of protected apps using Microsoft Intune**
@ -343,9 +347,9 @@ If your app is incompatible with WIP, but still needs to be used with enterprise
2. In **Exempt apps**, select **Add apps**.
When you exempt apps, theyre allowed to bypass the WIP restrictions and access your corporate data.
When you exempt apps, they're allowed to bypass the WIP restrictions and access your corporate data.
3. Fill out the rest of the app info, based on the type of app youre adding:
3. Fill out the rest of the app info, based on the type of app you're adding:
- [Add Recommended apps](#add-recommended-apps)
@ -371,12 +375,12 @@ We recommend that you start with **Silent** or **Allow Overrides** while verifyi
|Block |WIP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.|
|Allow Overrides |WIP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log. For info about how to collect your audit log files, see [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md).|
|Silent |WIP runs silently, logging inappropriate data sharing, without blocking anything that would have been prompted for employee interaction while in Allow Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or WIP-protected data, are still stopped.|
|Off (not recommended) |WIP is turned off and doesn't help to protect or audit your data.<br><br>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Your previous decryption and policy info isnt automatically reapplied if you turn WIP protection back on.|
|Off |WIP is turned off and doesn't help to protect or audit your data.<br><br>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Your previous decryption and policy info isn't automatically reapplied if you turn WIP protection back on. For more information, see [How to disable Windows Information Protection](how-to-disable-wip.md).|
2. Select **Save**.
## Define your enterprise-managed corporate identity
Corporate identity, typically expressed as your primary Internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps youve marked as protected by WIP. For example, emails using contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
Corporate identity, typically expressed as your primary Internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you've marked as protected by WIP. For example, emails using contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
Starting with Windows 10, version 1703, Intune automatically determines your corporate identity and adds it to the **Corporate identity** field.
@ -384,7 +388,7 @@ Starting with Windows 10, version 1703, Intune automatically determines your cor
1. From **App policy**, select the name of your policy, and then select **Required settings**.
2. If the auto-defined identity isnt correct, you can change the info in the **Corporate identity** field.
2. If the auto-defined identity isn't correct, you can change the info in the **Corporate identity** field.
![Microsoft Intune, Set your corporate identity for your organization.](images/wip-azure-required-settings-corp-identity.png)
@ -395,7 +399,7 @@ Starting with Windows 10, version 1703, Intune automatically determines your cor
## Choose where apps can access enterprise data
After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network. Every WIP policy should include your enterprise network locations.
There are no default locations included with WIP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprises range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT).
There are no default locations included with WIP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise's range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT).
To define the network boundaries, select **App policy** > the name of your policy > **Advanced settings** > **Add network boundary**.
@ -420,7 +424,7 @@ Personal applications can access a cloud resource that has a blank space or an i
To add a subdomain for a cloud resource, use a period (.) instead of an asterisk (*). For example, to add all subdomains within Office.com, use ".office.com" (without the quotation marks).
In some cases, such as when an app connects directly to a cloud resource through an IP address, Windows cant tell whether its attempting to connect to an enterprise cloud resource or to a personal site.
In some cases, such as when an app connects directly to a cloud resource through an IP address, Windows can't tell whether it's attempting to connect to an enterprise cloud resource or to a personal site.
In this case, Windows blocks the connection by default.
To stop Windows from automatically blocking these connections, you can add the `/*AppCompat*/` string to the setting.
For example:
@ -466,9 +470,9 @@ corp.contoso.com,region.contoso.com
### Proxy servers
Specify the proxy servers your devices will go through to reach your cloud resources.
Using this server type indicates that the cloud resources youre connecting to are enterprise resources.
Using this server type indicates that the cloud resources you're connecting to are enterprise resources.
This list shouldnt include any servers listed in your Internal proxy servers list.
This list shouldn't include any servers listed in your Internal proxy servers list.
Proxy servers must be used only for non-WIP-protected (non-enterprise) traffic.
Separate multiple resources with the ";" delimiter.
@ -478,9 +482,9 @@ proxy.contoso.com:80;proxy2.contoso.com:443
### Internal proxy servers
Specify the internal proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources youre connecting to are enterprise resources.
Specify the internal proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you're connecting to are enterprise resources.
This list shouldnt include any servers listed in your Proxy servers list.
This list shouldn't include any servers listed in your Proxy servers list.
Internal proxy servers must be used only for WIP-protected (enterprise) traffic.
Separate multiple resources with the ";" delimiter.
@ -492,7 +496,7 @@ contoso.internalproxy1.com;contoso.internalproxy2.com
Specify the addresses for a valid IPv4 value range within your intranet.
These addresses, used with your Network domain names, define your corporate network boundaries.
Classless Inter-Domain Routing (CIDR) notation isnt supported.
Classless Inter-Domain Routing (CIDR) notation isn't supported.
Separate multiple ranges with the "," delimiter.
@ -507,13 +511,13 @@ Starting with Windows 10, version 1703, this field is optional.
Specify the addresses for a valid IPv6 value range within your intranet.
These addresses, used with your network domain names, define your corporate network boundaries.
Classless Inter-Domain Routing (CIDR) notation isnt supported.
Classless Inter-Domain Routing (CIDR) notation isn't supported.
Separate multiple ranges with the "," delimiter.
**Starting IPv6 Address:** 2a01:110::<br/>
**Ending IPv6 Address:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff<br/>
**Custom URI:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,<br>fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
**Starting IPv6 Address:** `2a01:110::`</br>
**Ending IPv6 Address:** `2a01:110:7fff:ffff:ffff:ffff:ffff:ffff`<br>
**Custom URI:** `2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,'<br>'fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`
### Neutral resources
@ -534,10 +538,10 @@ Decide if you want Windows to look for more network settings:
![Microsoft Intune, Choose if you want Windows to search for more proxy servers or IP ranges in your enterprise.](images/wip-azure-advanced-settings-network-autodetect.png)
## Upload your Data Recovery Agent (DRA) certificate
After you create and deploy your WIP policy to your employees, Windows begins to encrypt your corporate data on the employees local device drive. If somehow the employees local encryption keys get lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the Data Recovery Agent (DRA) certificate lets Windows use an included public key to encrypt the local data while you maintain the private key that can unencrypt the data.
After you create and deploy your WIP policy to your employees, Windows begins to encrypt your corporate data on the employees' local device drive. If somehow the employees' local encryption keys get lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the Data Recovery Agent (DRA) certificate lets Windows use an included public key to encrypt the local data while you maintain the private key that can unencrypt the data.
>[!Important]
>Using a DRA certificate isnt mandatory. However, we strongly recommend it. For more info about how to find and export your data recovery certificate, see [Data Recovery and Encrypting File System (EFS)](/previous-versions/tn-archive/cc512680(v=technet.10)). For more info about creating and verifying your EFS DRA certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
>Using a DRA certificate isn't mandatory. However, we strongly recommend it. For more info about how to find and export your data recovery certificate, see [Data Recovery and Encrypting File System (EFS)](/previous-versions/tn-archive/cc512680(v=technet.10)). For more info about creating and verifying your EFS DRA certificate, see [Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate](/windows/threat-protection/windows-information-protection/create-and-verify-an-efs-dra-certificate).
**To upload your DRA certificate**
1. From **App policy**, select the name of your policy, and then select **Advanced settings** from the menu that appears.
@ -553,11 +557,11 @@ After you've decided where your protected apps can access enterprise data on you
![Advanced optional settings.](images/wip-azure-advanced-settings-optional.png)
**Revoke encryption keys on unenroll.** Determines whether to revoke a users local encryption keys from a device when its unenrolled from Windows Information Protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate data. The options are:
**Revoke encryption keys on unenroll.** Determines whether to revoke a user's local encryption keys from a device when it's unenrolled from Windows Information Protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate data. The options are:
- **On, or not configured (recommended).** Revokes local encryption keys from a device during unenrollment.
- **Off.** Stop local encryption keys from being revoked from a device during unenrollment. For example, if youre migrating between Mobile Device Management (MDM) solutions.
- **Off.** Stop local encryption keys from being revoked from a device during unenrollment. For example, if you're migrating between Mobile Device Management (MDM) solutions.
**Show the enterprise data protection icon.** Determines whether the Windows Information Protection icon overlay appears on corporate files in the Save As and File Explorer views. The options are:
@ -565,11 +569,11 @@ After you've decided where your protected apps can access enterprise data on you
- **Off, or not configured (recommended).** Stops the Windows Information Protection icon overlay from appearing on corporate files or unenlightened, but protected apps. Not configured is the default option.
**Use Azure RMS for WIP.** Determines whether WIP uses [Microsoft Azure Rights Management](/azure/information-protection/what-is-azure-rms) to apply EFS encryption to files that are copied from Windows 10 to USB or other removable drives so they can be securely shared with employees. In other words, WIP uses Azure Rights Management "machinery" to apply EFS encryption to files when they're copied to removable drives. You must already have Azure Rights Management set up. The EFS file encryption key is protected by the RMS templates license. Only users with permission to that template can read it from the removable drive. WIP can also integrate with Azure RMS by using the **AllowAzureRMSForEDP** and the **RMSTemplateIDForEDP** MDM settings in the [EnterpriseDataProtection CSP](/windows/client-management/mdm/enterprisedataprotection-csp).
**Use Azure RMS for WIP.** Determines whether WIP uses [Microsoft Azure Rights Management](/azure/information-protection/what-is-azure-rms) to apply EFS encryption to files that are copied from Windows 10 to USB or other removable drives so they can be securely shared with employees. In other words, WIP uses Azure Rights Management "machinery" to apply EFS encryption to files when they're copied to removable drives. You must already have Azure Rights Management set up. The EFS file encryption key is protected by the RMS template's license. Only users with permission to that template can read it from the removable drive. WIP can also integrate with Azure RMS by using the **AllowAzureRMSForEDP** and the **RMSTemplateIDForEDP** MDM settings in the [EnterpriseDataProtection CSP](/windows/client-management/mdm/enterprisedataprotection-csp).
- **On.** Protects files that are copied to a removable drive. You can enter a TemplateID GUID to specify who can access the Azure Rights Management protected files, and for how long. The RMS template is only applied to the files on removable media, and is only used for access control—it doesnt actually apply Azure Information Protection to the files.
- **On.** Protects files that are copied to a removable drive. You can enter a TemplateID GUID to specify who can access the Azure Rights Management protected files, and for how long. The RMS template is only applied to the files on removable media, and is only used for access control—it doesn't actually apply Azure Information Protection to the files.
If you dont specify an [RMS template](/information-protection/deploy-use/configure-custom-templates), its a regular EFS file using a default RMS template that all users can access.
If you don't specify an [RMS template](/information-protection/deploy-use/configure-custom-templates), it's a regular EFS file using a default RMS template that all users can access.
- **Off, or not configured.** Stops WIP from encrypting Azure Rights Management files that are copied to a removable drive.
@ -601,6 +605,3 @@ You can restrict which files are protected by WIP when they're downloaded from a
- [Intune MAM Without Enrollment](/archive/blogs/configmgrdogs/intune-mam-without-enrollment)
- [Azure RMS Documentation Update for May 2016](https://blogs.technet.microsoft.com/enterprisemobility/2016/05/31/azure-rms-documentation-update-for-may-2016/)
> [!NOTE]
> Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this topic, see [Editing Windows IT professional documentation](https://github.com/Microsoft/windows-itpro-docs/blob/master/CONTRIBUTING.md).

View File

@ -0,0 +1,126 @@
---
title: How to disable Windows Information Protection (WIP)
description: How to disable Windows Information Protection (WIP) in Microsoft Intune or Microsoft Endpoint Configuration Manager.
ms.date: 07/21/2022
ms.prod: m365-security
ms.topic: how-to
ms.localizationpriority: medium
author: lizgt2000
ms.author: lizlong
ms.reviewer: aaroncz
manager: dougeby
---
# How to disable Windows Information Protection (WIP)
[!INCLUDE [wip-deprecation](includes/wip-deprecation.md)]
<!-- 6010051 -->
_Applies to:_
- Windows 10
- Windows 11
## Use Intune to disable WIP
To disable Windows Information Protection (WIP) using Intune, you have the following options:
### Option 1 - Unassign the WIP policy (preferred)
When you unassign an existing policy, it removes the intent to deploy WIP from those devices. When that intent is removed, the device removes protection for files and the configuration for WIP. For more information, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).
### Option 2 - Change current WIP policy to off
If you're currently deploying a WIP policy for enrolled or unenrolled devices, you switch the WIP policy to Off. When devices check in after this change, the devices will proceed to unprotect files previously protected by WIP.
1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com).
1. Open Microsoft Intune and select **Apps** > **App protection policies**.
1. Select the existing policy to turn off, and then select the **Properties**.
1. Edit **Required settings**.
:::image type="content" alt-text="Intune App Protection policy properties, required settings, with WIP mode Off." source="images/intune-edit-app-protection-policy-mode-off.png":::
1. Set **Windows Information Protection mode** to off.
1. After making this change, select **Review and Save**.
1. Select **Save**.
> [!NOTE]
> **Another option is to create a disable policy that sets WIP to Off.**
>
> You can create a separate disable policy for WIP (both enrolled and unenrolled) and deploy that to a new group. You then can stage the transition to this disabled state. Move devices from the existing group to the new group. This process slowly migrates devices instead of all at once.
### Revoke local encryption keys during the unenrollment process
Determine whether to revoke a user's local encryption keys from a device when it's unenrolled from Windows Information Protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate data. The options are:
- Yes, or not configured. Revokes local encryption keys from a device during unenrollment.
- No (recommended). Stop local encryption keys from being revoked from a device during unenrollment.
## Use Configuration Manager to disable WIP
To disable Windows Information Protection (WIP) using Configuration Manager, create a new configuration item that turns off WIP. Configure that new object for your environment to match the existing policy, except for disabling WIP. Then deploy the new policy, and move devices into the new collection.
> [!WARNING]
> Don't just delete your existing WIP policy. If you delete the old policy, Configuration Manager stops sending further WIP policy updates, but also leaves WIP enforced on the devices. To remove WIP from your managed devices, follow the steps in this section to create a new policy to turn off WIP.
### Create a WIP policy
To disable WIP for your organization, first create a configuration item.
1. Open the Configuration Manager console, select the **Assets and Compliance** node, expand the **Overview** node, expand the **Compliance Settings** node, and then expand the **Configuration Items** node.
2. Select the **Create Configuration Item** button.
The **Create Configuration Item Wizard** starts.
![Create Configuration Item wizard, define the configuration item and choose the configuration type.](images/wip-configmgr-generalscreen-off.png)
3. On the **General Information screen**, type a name (required) and an optional description for your policy into the **Name** and **Description** boxes.
4. In the **Specify the type of configuration item you want to create** area, select **Windows 10 or later** for devices managed with the Configuration Manager client, and then select **Next**.
5. On the **Supported Platforms** screen, select the **Windows 10** box, and then select **Next**.
6. On the **Device Settings** screen, select **Windows Information Protection**, and then select **Next**.
The **Configure Windows Information Protection settings** page appears, where you'll configure your policy for your organization. The following sections provide details on the required settings on this page.
> [!TIP]
> For more information on filling out the required fields, see [Create and deploy a Windows Information Protection (WIP) policy using Microsoft Endpoint Configuration Manager](/windows/security/information-protection/windows-information-protection/create-wip-policy-using-configmgr).
#### Turn off WIP
Of the four options to specify the restriction mode, select **Off** to turn off Windows Information Protection.
:::image type="content" alt-text="Create Configuration Item wizard, choose your WIP-protection level." source="images/wip-configmgr-disable-wip.png":::
#### Specify the corporate identity
Paste the value of your corporate identity into the **Corporate identity** field. For example, `contoso.com` or `contoso.com|newcontoso.com`.
![Create Configuration Item wizard, Add the primary Internet domain for your enterprise identity.](images/wip-configmgr-corp-identity.png)
> [!IMPORTANT]
> This corporate identity value must match the string in the original policy. Copy and paste the string from your original policy that enables WIP.
#### Specify the corporate network definition
For the **Corporate network definition**, select **Add** to specify the necessary network locations. The **Add or edit corporate network definition** box appears. Add the required fields.
> [!IMPORTANT]
> These corporate network definitions must match the original policy. Copy and paste the strings from your original policy that enables WIP.
#### Specify the data recovery agent certificate
In the required **Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data** box, select **Browse** to add a data recovery certificate for your policy. This certificate should be the same as the original policy that enables WIP.
![Create Configuration Item wizard, Add a data recovery agent (DRA) certificate.](images/wip-configmgr-dra.png)
### Deploy the WIP policy
After you've created the new policy to turn off WIP, deploy it to your organization's devices. For more information about deployment options, see the following articles:
- [Create a configuration baseline that includes the new configuration item](/mem/configmgr/compliance/deploy-use/create-configuration-baselines).
- [Create a new collection](/mem/configmgr/core/clients/manage/collections/create-collections).
- [Deploy the baseline to the collection](/mem/configmgr/compliance/deploy-use/deploy-configuration-baselines).
- Move devices from the old collection to new collection.

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

View File

@ -0,0 +1,12 @@
---
author: aczechowski
ms.author: aaroncz
ms.prod: windows
ms.topic: include
ms.date: 07/20/2022
---
> [!NOTE]
> Starting in July 2022, Microsoft is deprecating Windows Information Protection (WIP). Microsoft will continue to support WIP on supported versions of Windows. New versions of Windows won't include new capabilities for WIP, and it won't be supported in future versions of Windows. For more information, see [Announcing sunset of Windows Information Protection](https://go.microsoft.com/fwlink/?linkid=2202124).<!-- 6010051 -->
>
> For your data protection needs, Microsoft recommends that you use [Microsoft Purview Information Protection](/microsoft-365/compliance/information-protection) and [Microsoft Purview Data Loss Prevention](/microsoft-365/compliance/dlp-learn-about-dlp). Purview simplifies the configuration set-up and provides an advanced set of capabilities.

View File

@ -1,54 +1,59 @@
---
title: Limitations while using Windows Information Protection (WIP) (Windows 10)
title: Limitations while using Windows Information Protection (WIP)
description: This section includes info about the common problems you might encounter while using Windows Information Protection (WIP).
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
author: aczechowski
ms.author: aaroncz
manager: dougeby
ms.reviewer: rafals
ms.collection: M365-security-compliance
ms.topic: conceptual
ms.date: 04/05/2019
ms.reviewer:
ms.localizationpriority: medium
---
# Limitations while using Windows Information Protection (WIP)
**Applies to:**
- Windows 10, version 1607 and later
_Applies to:_
- Windows 10
- Windows 11
This following list provides info about the most common problems you might encounter while running Windows Information Protection in your organization.
- **Limitation**: Your enterprise data on USB drives might be tied to the device it was protected on, based on your Azure RMS configuration.
- **How it appears**:
- If youre using Azure RMS: Authenticated users can open enterprise data on USB drives, on computers running Windows 10, version 1703.
- If youre not using Azure RMS: Data in the new location remains encrypted, but becomes inaccessible on other devices and for other users. For example, the file won't open or the file opens, but doesn't contain readable text.
- If you're using Azure RMS: Authenticated users can open enterprise data on USB drives, on computers running Windows 10, version 1703.
- If you're not using Azure RMS: Data in the new location remains encrypted, but becomes inaccessible on other devices and for other users. For example, the file won't open or the file opens, but doesn't contain readable text.
- **Workaround**: Share files with fellow employees through enterprise file servers or enterprise cloud locations. If data must be shared via USB, employees can decrypt protected files, but it will be audited.
We strongly recommend educating employees about how to limit or eliminate the need for this decryption.
- **Limitation**: Direct Access is incompatible with Windows Information Protection.
- **How it appears**: Direct Access might experience problems with how Windows Information Protection enforces app behavior and data movement because of how WIP determines what is and isnt a corporate network resource.
- **How it appears**: Direct Access might experience problems with how Windows Information Protection enforces app behavior and data movement because of how WIP determines what is and isn't a corporate network resource.
- **Workaround**: We recommend that you use VPN for client access to your intranet resources.
> [!NOTE]
> VPN is optional and isnt required by Windows Information Protection.
> VPN is optional and isn't required by Windows Information Protection.
- **Limitation**: **NetworkIsolation** Group Policy setting takes precedence over MDM Policy settings.
- **How it appears**: The **NetworkIsolation** Group Policy setting can configure network settings that can also be configured by using MDM. WIP relies on these policies being correctly configured.
- **Workaround**: If you use both Group Policy and MDM to configure your **NetworkIsolation** settings, you must make sure that those same settings are deployed to your organization using both Group Policy and MDM.
- **Limitation**: Cortana can potentially allow data leakage if its on the allowed apps list.
- **Limitation**: Cortana can potentially allow data leakage if it's on the allowed apps list.
- **How it appears**: If Cortana is on the allowed list, some files might become unexpectedly encrypted after an employee performs a search using Cortana. Your employees will still be able to use Cortana to search and provide results on enterprise documents and locations, but results might be sent to Microsoft.
- **Workaround**: We dont recommend adding Cortana to your allowed apps list. However, if you wish to use Cortana and don't mind whether the results potentially go to Microsoft, you can make Cortana an Exempt app.
- **Workaround**: We don't recommend adding Cortana to your allowed apps list. However, if you wish to use Cortana and don't mind whether the results potentially go to Microsoft, you can make Cortana an Exempt app.
<a name="single-user"></a>
- **Limitation**: Windows Information Protection is designed for use by a single user per device.
- **How it appears**: A secondary user on a device might experience app compatibility issues when unenlightened apps start to automatically encrypt for all users. Additionally, only the initial, enrolled users content can be revoked during the unenrollment process.
- **Workaround**: We recommend only having one user per managed device.
- **How it appears**: A secondary user on a device might experience app compatibility issues when unenlightened apps start to automatically encrypt for all users. Additionally, only the initial, enrolled user's content can be revoked during the unenrollment process.
- **Workaround**: Have only one user per managed device.
- If this scenario occurs, it may be possible to mitigate. Once protection is disabled, a second user can remove protection by changing the file ownership. Although the protection is in place, the file remains accessible to the user.
- **Limitation**: Installers copied from an enterprise network file share might not work properly.
- **How it appears**: An app might fail to properly install because it cant read a necessary configuration or data file, such as a .cab or .xml file needed for installation, which was protected by the copy action.
- **How it appears**: An app might fail to properly install because it can't read a necessary configuration or data file, such as a .cab or .xml file needed for installation, which was protected by the copy action.
- **Workaround**: To fix this, you can:
- Start the installer directly from the file share.
@ -58,9 +63,9 @@ This following list provides info about the most common problems you might encou
OR
- Mark the file share with the installation media as personal. To do this, youll need to set the Enterprise IP ranges as **Authoritative** and then exclude the IP address of the file server, or youll need to put the file server on the Enterprise Proxy Server list.
- Mark the file share with the installation media as "personal". To do this, you'll need to set the Enterprise IP ranges as **Authoritative** and then exclude the IP address of the file server, or you'll need to put the file server on the Enterprise Proxy Server list.
- **Limitation**: Changing your primary Corporate Identity isnt supported.
- **Limitation**: Changing your primary Corporate Identity isn't supported.
- **How it appears**: You might experience various instabilities, including but not limited to network and file access failures, and potentially granting incorrect access.
- **Workaround**: Turn off Windows Information Protection for all devices before changing the primary Corporate Identity (first entry in the list), restarting, and finally redeploying.
@ -85,7 +90,7 @@ This following list provides info about the most common problems you might encou
- **Workaround**: Open File Explorer and change the file ownership to **Personal** before you upload.
- **Limitation**: ActiveX controls should be used with caution.
- **How it appears**: Webpages that use ActiveX controls can potentially communicate with other outside processes that arent protected by using Windows Information Protection.
- **How it appears**: Webpages that use ActiveX controls can potentially communicate with other outside processes that aren't protected by using Windows Information Protection.
- **Workaround**: We recommend that you switch to using Microsoft Edge, the more secure and safer browser that prevents the use of ActiveX controls. We also recommend that you limit the usage of Internet Explorer 11 to only those line-of-business apps that require legacy technology.
For more info, see [Out-of-date ActiveX control blocking](/internet-explorer/ie11-deploy-guide/out-of-date-activex-control-blocking).
@ -94,7 +99,7 @@ This following list provides info about the most common problems you might encou
- **How it appears**:Trying to save or transfer Windows Information Protection files to ReFS will fail.
- **Workaround**: Format drive for NTFS, or use a different drive.
- **Limitation**: Windows Information Protection isnt turned on if any of the following folders have the **MakeFolderAvailableOfflineDisabled** option set to **False**:
- **Limitation**: Windows Information Protection isn't turned on if any of the following folders have the **MakeFolderAvailableOfflineDisabled** option set to **False**:
- AppDataRoaming
- Desktop
- StartMenu
@ -111,8 +116,8 @@ This following list provides info about the most common problems you might encou
<br/>
- **How it appears**: Windows Information Protection isnt turned on for employees in your organization. Error code 0x807c0008 will result if Windows Information Protection is deployed by using Microsoft Endpoint Configuration Manager.
- **Workaround**: Dont set the **MakeFolderAvailableOfflineDisabled** option to **False** for any of the specified folders. You can configure this parameter, as described [Disable Offline Files on individual redirected folders](/windows-server/storage/folder-redirection/disable-offline-files-on-folders).
- **How it appears**: Windows Information Protection isn't turned on for employees in your organization. Error code 0x807c0008 will result if Windows Information Protection is deployed by using Microsoft Endpoint Configuration Manager.
- **Workaround**: Don't set the **MakeFolderAvailableOfflineDisabled** option to **False** for any of the specified folders. You can configure this parameter, as described [Disable Offline Files on individual redirected folders](/windows-server/storage/folder-redirection/disable-offline-files-on-folders).
If you currently use redirected folders, we recommend that you migrate to a file synchronization solution that supports Windows Information Protection, such as Work Folders or OneDrive for Business. Additionally, if you apply redirected folders after Windows Information Protection is already in place, you might be unable to open your files offline.
@ -137,7 +142,7 @@ This following list provides info about the most common problems you might encou
2. Move the notebook folder via File Explorer out of the OneDrive for Business folder to another location, such as the Desktop.
3. Copy the notebook folder and Paste it back into the OneDrive for Business folder.
Wait a few minutes to allow OneDrive to finish syncing & upgrading the notebook, and the folder should automatically convert to an Internet Shortcut. Opening the shortcut will open the notebook in the browser, which can then be opened in the OneNote client by using the Open in app button.
Wait a few minutes to allow OneDrive to finish syncing & upgrading the notebook, and the folder should automatically convert to an Internet Shortcut. Opening the shortcut will open the notebook in the browser, which can then be opened in the OneNote client by using the "Open in app" button.
- **Limitation**: Microsoft Office Outlook offline data files (PST and OST files) are not marked as **Work** files, and are therefore not protected.
- **How it appears**: If Microsoft Office Outlook is set to work in cached mode (default setting), or if some emails are stored in a local PST file, the data is unprotected.

View File

@ -1,26 +1,29 @@
---
title: Protect your enterprise data using Windows Information Protection (WIP) (Windows 10)
title: Protect your enterprise data using Windows Information Protection
description: Learn how to prevent accidental enterprise data leaks through apps and services, such as email, social media, and the public cloud.
ms.prod: m365-security
ms.localizationpriority: medium
author: dansimp
ms.author: dansimp
manager: dansimp
author: aczechowski
ms.author: aaroncz
manager: dougeby
ms.reviewer: rafals
ms.collection:
- M365-security-compliance
- highpri
ms.topic: conceptual
ms.date: 03/05/2019
ms.topic: overview
ms.date: 07/15/2022
---
# Protect your enterprise data using Windows Information Protection (WIP)
**Applies to:**
- Windows 10, version 1607 and later
[!INCLUDE [Deprecate Windows Information Protection](includes/wip-deprecation.md)]
<!-- 6010051 -->
>Learn more about what features and functionality are supported in each Windows edition at [Compare Windows 10 Editions](https://www.microsoft.com/WindowsForBusiness/Compare).
_Applies to:_
With the increase of employee-owned devices in the enterprise, theres also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprises control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.
- Windows 10
- Windows 11
With the increase of employee-owned devices in the enterprise, there's also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise's control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.
Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps. Finally, another data protection technology, Azure Rights Management also works alongside WIP to extend data protection for data that leaves the device, such as when email attachments are sent from an enterprise aware version of a rights management mail client.
@ -32,18 +35,18 @@ Windows Information Protection (WIP), previously known as enterprise data protec
> [!Video https://www.microsoft.com/videoplayer/embed/RE2IGhh]
## Prerequisites
Youll need this software to run Windows Information Protection in your enterprise:
You'll need this software to run Windows Information Protection in your enterprise:
|Operating system | Management solution |
|-----------------|---------------------|
|Windows 10, version 1607 or later | Microsoft Intune<br><br>-OR-<br><br>Microsoft Endpoint Configuration Manager<br><br>-OR-<br><br>Your current company-wide 3rd party mobile device management (MDM) solution. For info about 3rd party MDM solutions, see the documentation that came with your product. If your 3rd party MDM does not have UI support for the policies, refer to the [EnterpriseDataProtection CSP](/windows/client-management/mdm/enterprisedataprotection-csp) documentation.|
|Windows 10, version 1607 or later | Microsoft Intune<br><br>-OR-<br><br>Microsoft Endpoint Configuration Manager<br><br>-OR-<br><br>Your current company-wide 3rd party mobile device management (MDM) solution. For info about 3rd party MDM solutions, see the documentation that came with your product. If your 3rd party MDM does not have UI support for the policies, refer to the [EnterpriseDataProtection CSP](/windows/client-management/mdm/enterprisedataprotection-csp) documentation.|
## What is enterprise data control?
Effective collaboration means that you need to share data with others in your enterprise. This sharing can be from one extreme where everyone has access to everything without any security, all the way to the other extreme where people cant share anything and its all highly secured. Most enterprises fall somewhere in between the two extremes, where success is balanced between providing the necessary access with the potential for improper data disclosure.
Effective collaboration means that you need to share data with others in your enterprise. This sharing can be from one extreme where everyone has access to everything without any security, all the way to the other extreme where people can't share anything and it's all highly secured. Most enterprises fall somewhere in between the two extremes, where success is balanced between providing the necessary access with the potential for improper data disclosure.
As an admin, you can address the question of who gets access to your data by using access controls, such as employee credentials. However, just because someone has the right to access your data doesnt guarantee that the data will remain within the secured locations of the enterprise. This means that while access controls are a great start, theyre not enough.
As an admin, you can address the question of who gets access to your data by using access controls, such as employee credentials. However, just because someone has the right to access your data doesn't guarantee that the data will remain within the secured locations of the enterprise. This means that while access controls are a great start, they're not enough.
In the end, all of these security measures have one thing in common: employees will tolerate only so much inconvenience before looking for ways around the security restrictions. For example, if you dont allow employees to share files through a protected system, employees will turn to an outside app that more than likely lacks security controls.
In the end, all of these security measures have one thing in common: employees will tolerate only so much inconvenience before looking for ways around the security restrictions. For example, if you don't allow employees to share files through a protected system, employees will turn to an outside app that more than likely lacks security controls.
### Using data loss prevention systems
To help address this security insufficiency, companies developed data loss prevention (also known as DLP) systems. Data loss prevention systems require:
@ -53,15 +56,15 @@ To help address this security insufficiency, companies developed data loss preve
- **The ability to specify what happens when data matches a rule, including whether employees can bypass enforcement.** For example, in Microsoft SharePoint and SharePoint Online, the Microsoft Purview data loss prevention system lets you warn your employees that shared data includes sensitive info, and to share it anyway (with an optional audit log entry).
Unfortunately, data loss prevention systems have their own problems. For example, the less detailed the rule set, the more false positives are created, leading employees to believe that the rules slow down their work and need to be bypassed in order to remain productive, potentially leading to data being incorrectly blocked or improperly released. Another major problem is that data loss prevention systems must be widely implemented to be effective. For example, if your company uses a data loss prevention system for email, but not for file shares or document storage, you might find that your data leaks through the unprotected channels. But perhaps the biggest problem with data loss prevention systems is that it provides a jarring experience that interrupts the employees natural workflow by stopping some operations (such as sending a message with an attachment that the system tags as sensitive) while allowing others, often according to subtle rules that the employee doesnt see and cant understand.
Unfortunately, data loss prevention systems have their own problems. For example, the less detailed the rule set, the more false positives are created, leading employees to believe that the rules slow down their work and need to be bypassed in order to remain productive, potentially leading to data being incorrectly blocked or improperly released. Another major problem is that data loss prevention systems must be widely implemented to be effective. For example, if your company uses a data loss prevention system for email, but not for file shares or document storage, you might find that your data leaks through the unprotected channels. But perhaps the biggest problem with data loss prevention systems is that it provides a jarring experience that interrupts the employees' natural workflow by stopping some operations (such as sending a message with an attachment that the system tags as sensitive) while allowing others, often according to subtle rules that the employee doesn't see and can't understand.
### Using information rights management systems
To help address the potential data loss prevention system problems, companies developed information rights management (also known as IRM) systems. Information rights management systems embed protection directly into documents, so that when an employee creates a document, he or she determines what kind of protection to apply. For example, an employee can choose to stop the document from being forwarded, printed, shared outside of the organization, and so on.
After the type of protection is set, the creating app encrypts the document so that only authorized people can open it, and even then, only in compatible apps. After an employee opens the document, the app becomes responsible for enforcing the specified protections. Because protection travels with the document, if an authorized person sends it to an unauthorized person, the unauthorized person wont be able to read or change it. However, for this to work effectively information rights management systems require you to deploy and set up both a server and client environment. And, because only compatible clients can work with protected documents, an employees work might be unexpectedly interrupted if he or she attempts to use a non-compatible app.
After the type of protection is set, the creating app encrypts the document so that only authorized people can open it, and even then, only in compatible apps. After an employee opens the document, the app becomes responsible for enforcing the specified protections. Because protection travels with the document, if an authorized person sends it to an unauthorized person, the unauthorized person won't be able to read or change it. However, for this to work effectively information rights management systems require you to deploy and set up both a server and client environment. And, because only compatible clients can work with protected documents, an employees' work might be unexpectedly interrupted if he or she attempts to use a non-compatible app.
### And what about when an employee leaves the company or unenrolls a device?
Finally, theres the risk of data leaking from your company when an employee leaves or unenrolls a device. Previously, you would simply erase all of the corporate data from the device, along with any other personal data on the device.
Finally, there's the risk of data leaking from your company when an employee leaves or unenrolls a device. Previously, you would simply erase all of the corporate data from the device, along with any other personal data on the device.
## Benefits of WIP
Windows Information Protection provides:
@ -78,17 +81,17 @@ Windows Information Protection provides:
## Why use WIP?
Windows Information Protection is the mobile application management (MAM) mechanism on Windows 10. WIP gives you a new way to manage data policy enforcement for apps and documents on Windows 10 desktop operating systems, along with the ability to remove access to enterprise data from both enterprise and personal devices (after enrollment in an enterprise management solution, like Intune).
- **Change the way you think about data policy enforcement.** As an enterprise admin, you need to maintain compliance in your data policy and data access. Windows Information Protection helps protect enterprise on both corporate and employee-owned devices, even when the employee isnt using the device. When employees create content on an enterprise-protected device, they can choose to save it as a work document. If it's a work document, it becomes locally-maintained as enterprise data.
- **Change the way you think about data policy enforcement.** As an enterprise admin, you need to maintain compliance in your data policy and data access. Windows Information Protection helps protect enterprise on both corporate and employee-owned devices, even when the employee isn't using the device. When employees create content on an enterprise-protected device, they can choose to save it as a work document. If it's a work document, it becomes locally maintained as enterprise data.
- **Manage your enterprise documents, apps, and encryption modes.**
- **Copying or downloading enterprise data.** When an employee or an app downloads content from a location like SharePoint, a network share, or an enterprise web location, while using a WIP-protected device, WIP encrypts the data on the device.
- **Using protected apps.** Managed apps (apps that you've included on the **Protected apps** list in your WIP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if WIP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but makes a mistake and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldnt paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
- **Using protected apps.** Managed apps (apps that you've included on the **Protected apps** list in your WIP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if WIP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but makes a mistake and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldn't paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
- **Managed apps and restrictions.** With WIP you can control which apps can access and use your enterprise data. After adding an app to your protected apps list, the app is trusted with enterprise data. All apps not on this list are stopped from accessing your enterprise data, depending on your WIP management-mode.
You dont have to modify line-of-business apps that never touch personal data to list them as protected apps; just include them in the protected apps list.
You don't have to modify line-of-business apps that never touch personal data to list them as protected apps; just include them in the protected apps list.
- **Deciding your level of data access.** WIP lets you block, allow overrides, or audit employees' data sharing actions. Hiding overrides stops the action immediately. Allowing overrides lets the employee know there's a risk, but lets him or her continue to share the data while recording and auditing the action. Silent just logs the action without stopping anything that the employee could've overridden while using that setting; collecting info that can help you to see patterns of inappropriate sharing so you can take educative action or find apps that should be added to your protected apps list. For info about how to collect your audit log files, see [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md).
@ -97,9 +100,9 @@ Windows Information Protection is the mobile application management (MAM) mechan
Apps such as Microsoft Word work with WIP to help continue your data protection across local files and removable media. These apps are being referred to as, enterprise aware. For example, if an employee opens WIP-encrypted content from Word, edits the content, and then tries to save the edited version with a different name, Word automatically applies Windows Information Protection to the new document.
- **Helping prevent accidental data disclosure to public spaces.** Windows Information Protection helps protect your enterprise data from being accidentally shared to public spaces, such as public cloud storage. For example, if Dropbox™ isnt on your protected apps list, employees wont be able to sync encrypted files to their personal cloud storage. Instead, if the employee stores the content to an app on your protected apps list, like Microsoft OneDrive for Business, the encrypted files can sync freely to the business cloud, while maintaining the encryption locally.
- **Helping prevent accidental data disclosure to public spaces.** Windows Information Protection helps protect your enterprise data from being accidentally shared to public spaces, such as public cloud storage. For example, if Dropbox™ isn't on your protected apps list, employees won't be able to sync encrypted files to their personal cloud storage. Instead, if the employee stores the content to an app on your protected apps list, like Microsoft OneDrive for Business, the encrypted files can sync freely to the business cloud, while maintaining the encryption locally.
- **Helping prevent accidental data disclosure to removable media.** Windows Information Protection helps prevent enterprise data from leaking when it's copied or transferred to removable media. For example, if an employee puts enterprise data on a Universal Serial Bus (USB) drive that also has personal data, the enterprise data remains encrypted while the personal data doesnt.
- **Helping prevent accidental data disclosure to removable media.** Windows Information Protection helps prevent enterprise data from leaking when it's copied or transferred to removable media. For example, if an employee puts enterprise data on a Universal Serial Bus (USB) drive that also has personal data, the enterprise data remains encrypted while the personal data doesn't.
- **Remove access to enterprise data from enterprise-protected devices.** Windows Information Protection gives admins the ability to revoke enterprise data from one or many MDM-enrolled devices, while leaving personal data alone. This is a benefit when an employee leaves your company, or in the case of a stolen device. After determining that the data access needs to be removed, you can use Microsoft Intune to unenroll the device so when it connects to the network, the user's encryption key for the device is revoked and the enterprise data becomes unreadable.
@ -115,7 +118,7 @@ Windows Information Protection helps address your everyday challenges in the ent
- Helping to maintain the ownership and control of your enterprise data.
- Helping control the network and data access and data sharing for apps that arent enterprise aware
- Helping control the network and data access and data sharing for apps that aren't enterprise aware
### Enterprise scenarios
Windows Information Protection currently addresses these enterprise scenarios:
@ -125,12 +128,12 @@ Windows Information Protection currently addresses these enterprise scenarios:
- You can protect specific apps that can access enterprise data that are clearly recognizable to employees. You can also stop non-protected apps from accessing enterprise data.
- Your employees won't have their work otherwise interrupted while switching between personal and enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple times isnt required.
- Your employees won't have their work otherwise interrupted while switching between personal and enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple times isn't required.
### <a href="" id="bkmk-modes"></a>WIP-protection modes
Enterprise data is automatically encrypted after its loaded on a device from an enterprise source or if an employee marks the data as corporate. Then, when the enterprise data is written to disk, Windows Information Protection uses the Windows-provided Encrypting File System (EFS) to protect it and associate it with your enterprise identity.
Enterprise data is automatically encrypted after it's loaded on a device from an enterprise source or if an employee marks the data as corporate. Then, when the enterprise data is written to disk, Windows Information Protection uses the Windows-provided Encrypting File System (EFS) to protect it and associate it with your enterprise identity.
Your Windows Information Protection policy includes a list of trusted apps that are protected to access and process corporate data. This list of apps is implemented through the [AppLocker](/windows/device-security/applocker/applocker-overview) functionality, controlling what apps are allowed to run and letting the Windows operating system know that the apps can edit corporate data. Apps included on this list dont have to be modified to open corporate data because their presence on the list allows Windows to determine whether to grant them access. However, new for Windows 10, app developers can use a new set of application programming interfaces (APIs) to create *enlightened* apps that can use and edit both enterprise and personal data. A huge benefit to working with enlightened apps is that dual-use apps, like Microsoft Word, can be used with less concern about encrypting personal data by mistake because the APIs allow the app to determine whether data is owned by the enterprise or if its personally owned.
Your Windows Information Protection policy includes a list of trusted apps that are protected to access and process corporate data. This list of apps is implemented through the [AppLocker](/windows/device-security/applocker/applocker-overview) functionality, controlling what apps are allowed to run and letting the Windows operating system know that the apps can edit corporate data. Apps included on this list don't have to be modified to open corporate data because their presence on the list allows Windows to determine whether to grant them access. However, new for Windows 10, app developers can use a new set of application programming interfaces (APIs) to create *enlightened* apps that can use and edit both enterprise and personal data. A huge benefit to working with enlightened apps is that dual-use apps, like Microsoft Word, can be used with less concern about encrypting personal data by mistake because the APIs allow the app to determine whether data is owned by the enterprise or if it's personally owned.
>[!NOTE]
>For info about how to collect your audit log files, see [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md).
@ -139,19 +142,14 @@ You can set your Windows Information Protection policy to use 1 of 4 protection
|Mode|Description|
|----|-----------|
|Block |Windows Information Protection looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing enterprise data to non-enterprise-protected apps in addition to sharing enterprise data between apps or attempting to share outside of your organizations network.|
|Block |Windows Information Protection looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing enterprise data to non-enterprise-protected apps in addition to sharing enterprise data between apps or attempting to share outside of your organization's network.|
|Allow overrides |Windows Information Protection looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log.|
|Silent |Windows Information Protection runs silently, logging inappropriate data sharing, without stopping anything that wouldve been prompted for employee interaction while in Allow overrides mode. Unallowed actions, like apps inappropriately trying to access a network resource or WIP-protected data, are still stopped.|
|Off |Windows Information Protection is turned off and doesn't help to protect or audit your data.<p>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Be aware that your previous decryption and policy info isnt automatically reapplied if you turn Windows Information Protection back on. |
|Silent |Windows Information Protection runs silently, logging inappropriate data sharing, without stopping anything that would've been prompted for employee interaction while in Allow overrides mode. Unallowed actions, like apps inappropriately trying to access a network resource or WIP-protected data, are still stopped.|
|Off |Windows Information Protection is turned off and doesn't help to protect or audit your data.<p>After you turn off WIP, an attempt is made to decrypt any WIP-tagged files on the locally attached drives. Be aware that your previous decryption and policy info isn't automatically reapplied if you turn Windows Information Protection back on. |
## Turn off WIP
You can turn off all Windows Information Protection and restrictions, decrypting all devices managed by WIP and reverting to where you were pre-WIP, with no data loss. However, this isnt recommended. If you choose to turn WIP off, you can always turn it back on, but your decryption and policy info wont be automatically reapplied.
You can turn off all Windows Information Protection and restrictions, decrypting all devices managed by WIP and reverting to where you were pre-WIP, with no data loss. However, this isn't recommended. If you choose to turn WIP off, you can always turn it back on, but your decryption and policy info won't be automatically reapplied.
## Next steps
After deciding to use WIP in your enterprise, you need to:
- [Create a Windows Information Protection (WIP) policy](overview-create-wip-policy.md)
>[!NOTE]
>Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this topic, see [Editing Windows IT professional documentation](https://github.com/Microsoft/windows-itpro-docs/blob/master/CONTRIBUTING.md).
After you decide to use WIP in your environment, [create a Windows Information Protection (WIP) policy](overview-create-wip-policy.md).

View File

@ -77,13 +77,13 @@ This event always generates, regardless of the objects [SACL](/windows/win32/
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policy on the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policy on the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the Central Access Policy on the object.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -137,7 +137,7 @@ This event always generates, regardless of the objects [SACL](/windows/win32/
- **Original Security Descriptor** \[Type = UnicodeString\]**:** the Security Descriptor Definition Language (SDDL) value for the old Central Policy ID (for the policy that was formerly applied to the object).
SDDL contains Central Access Policy SID, here is an example: S:ARAI(SP;ID;;;;S-1-17-1442530252-1178042555-1247349694-2318402534), Central Access Policy SID here is “**S-1-17-1442530252-1178042555-1247349694-2318402534**”. To resolve this SID to the real Central Access Policy name you need to do the following:
SDDL contains Central Access Policy SID, here's an example: S:ARAI(SP;ID;;;;S-1-17-1442530252-1178042555-1247349694-2318402534), Central Access Policy SID here is “**S-1-17-1442530252-1178042555-1247349694-2318402534**”. To resolve this SID to the real Central Access Policy name, you need to do the following steps:
1. Find Central Access Policy Active Directory object in: “CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=XXX,DC=XX” Active Directory container.
@ -166,11 +166,11 @@ This event always generates, regardless of the objects [SACL](/windows/win32/
|-------|--------------------------------------|-------|---------------------------------|
| "AO" | Account operators | "PA" | Group Policy administrators |
| "RU" | Alias to allow previous Windows 2000 | "IU" | Interactively logged-on user |
| "AN" | Anonymous logon | "LA" | Local administrator |
| "AN" | Anonymous sign in | "LA" | Local administrator |
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
| "BO" | Backup operators | "NU" | Network logon user |
| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@ -182,7 +182,7 @@ This event always generates, regardless of the objects [SACL](/windows/win32/
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
| "WD" | Everyone | "SU" | Service logon user |
| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@ -202,7 +202,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@ -228,7 +228,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@ -239,7 +239,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@ -261,7 +261,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: <https://msdn.microsoft.com/library/cc230374.aspx>, <https://msdn.microsoft.com/library/windows/hardware/aa374892(v=vs.85).aspx>.
@ -277,7 +277,7 @@ For 4913(S): Central Access Policy on the object was changed.
- If you have a pre-defined “**Process Name**” for the process reported in this event, monitor all events with “**Process Name**” not equal to your defined value.
- You can monitor to see if “**Process Name**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Process Name**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
<!-- -->

View File

@ -97,12 +97,12 @@ Failure event generates if an error occurs (**Status Code** != 0).
<img src="images/ad-sites-and-services.png" alt="Directory Replication Service options in AD Sites and Services" width="890" height="529" />
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## Security Monitoring Recommendations
For 4928(S, F): An Active Directory replica source naming context was established.
- Monitor for **Source Address** field, because the source of new replication (new DRA) must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
- Monitor for **Source Address** field, because the source of new replication (new DRA) must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.

View File

@ -89,18 +89,18 @@ Failure event generates if an error occurs (**Status Code** != 0).
- **Source Address** \[Type = UnicodeString\]: DNS record of the server from which the “remove” request was received.
- **Naming Context** \[Type = UnicodeString\]**:** naming context which was removed.
- **Naming Context** \[Type = UnicodeString\]**:** naming context that was removed.
> **Note**&nbsp;&nbsp;The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## Security Monitoring Recommendations
For 4929(S, F): An Active Directory replica source naming context was removed.
- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.

View File

@ -27,7 +27,7 @@ This event generates every time Active Directory replica source naming context w
Failure event generates if an error occurs (**Status Code** != 0).
It is not possible to understand what exactly was modified from this event.
It isn't possible to understand what exactly was modified from this event.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -91,18 +91,18 @@ It is not possible to understand what exactly was modified from this event.
- **Source Address** \[Type = UnicodeString\]: DNS record of computer from which the modification request was received.
- **Naming Context** \[Type = UnicodeString\]**:** naming context which was modified.
- **Naming Context** \[Type = UnicodeString\]**:** naming context that was modified.
> **Note**&nbsp;&nbsp;The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## Security Monitoring Recommendations
For 4930(S, F): An Active Directory replica source naming context was modified.
- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.

View File

@ -27,7 +27,7 @@ This event generates every time Active Directory replica destination naming cont
Failure event generates if an error occurs (**Status Code** != 0).
It is not possible to understand what exactly was modified from this event.
It isn't possible to understand what exactly was modified from this event.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -91,13 +91,13 @@ It is not possible to understand what exactly was modified from this event.
- **Destination Address** \[Type = UnicodeString\]: DNS record of computer to which the modification request was sent.
- **Naming Context** \[Type = UnicodeString\]**:** naming context which was modified.
- **Naming Context** \[Type = UnicodeString\]**:** naming context that was modified.
> **Note**&nbsp;&nbsp;The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## Security Monitoring Recommendations

View File

@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time Windows Firewall service starts.
This event shows the inbound and/or outbound rule which was listed when the Windows Firewall started and applied for “Public” profile.
This event shows the inbound and/or outbound rule that was listed when the Windows Firewall started and applied for “Public” profile.
This event generates per rule.
@ -75,11 +75,11 @@ This event generates per rule.
- **Rule ID** \[Type = UnicodeString\]: the unique firewall rule identifier.
To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was listed when the Windows Firewall started. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was listed when the Windows Firewall started. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -89,5 +89,5 @@ For 4945(S): A rule was listed when the Windows Firewall started.
- Typically this event has an informational purpose.
- Unfortunately this event shows rules only for **Public** profile, but you still can compare this list with your organization's Windows Firewall baseline for Public profile rules on different computers, and trigger an alert if the configuration is not the same.
- Unfortunately this event shows rules only for **Public** profile, but you still can compare this list with your organization's Windows Firewall baseline for Public profile rules on different computers, and trigger an alert if the configuration isn't the same.

View File

@ -71,11 +71,11 @@ This event doesn't generate when new rule was added via Group Policy.
- All
- Domain,Public
- Domain, Public
- Domain,Private
- Domain, Private
- Private,Public
- Private, Public
- Public
@ -87,11 +87,11 @@ This event doesn't generate when new rule was added via Group Policy.
- **Rule ID** \[Type = UnicodeString\]: the unique new firewall rule identifier.
To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was added. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was added. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -99,5 +99,5 @@ This event doesn't generate when new rule was added via Group Policy.
For 4946(S): A change has been made to Windows Firewall exception list. A rule was added.
- This event can be helpful in case you want to monitor all creations of new Firewall rules which were done locally.
- This event can be helpful in case you want to monitor all creations of new Firewall rules that were done locally.

View File

@ -71,11 +71,11 @@ This event doesn't generate when the rule was deleted via Group Policy.
- All
- Domain,Public
- Domain, Public
- Domain,Private
- Domain, Private
- Private,Public
- Private, Public
- Public
@ -87,11 +87,11 @@ This event doesn't generate when the rule was deleted via Group Policy.
- **Rule ID** \[Type = UnicodeString\]: the unique identifier for deleted firewall rule.
To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was deleted. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was deleted. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -99,5 +99,5 @@ This event doesn't generate when the rule was deleted via Group Policy.
For 4948(S): A change has been made to Windows Firewall exception list. A rule was deleted.
- This event can be helpful in case you want to monitor all deletions of Firewall rules which were done locally.
- This event can be helpful in case you want to monitor all deletions of Firewall rules that were done locally.

View File

@ -77,7 +77,7 @@ This event doesn't generate when Windows Firewall setting was changed via Group
**New Setting:**
- **Type** \[Type = UnicodeString\]: the name of the setting which was modified. You can use “**netsh advfirewall**” command to see or set Windows Firewall settings, for example, to see settings for current\\active Windows Firewall profile you need to execute “**netsh advfirewall show currentprofile**” command:
- **Type** \[Type = UnicodeString\]: the name of the setting that was modified. You can use “**netsh advfirewall**” command to see or set Windows Firewall settings, for example, to see settings for current\\active Windows Firewall profile you need to execute “**netsh advfirewall show currentprofile**” command:
<img src="images/netsh-advfirewall-command.png" alt="Netsh advfirewall command illustration" width="951" height="422" />
@ -89,5 +89,5 @@ For 4950(S): A Windows Firewall setting has changed.
- If you have a standard or baseline for Windows Firewall settings defined, monitor this event and check whether the settings reported by the event are still the same as were defined in your standard or baseline.
- This event can be helpful in case you want to monitor all changes in Windows Firewall settings which were done locally.
- This event can be helpful in case you want to monitor all changes in Windows Firewall settings that were done locally.

View File

@ -1,6 +1,6 @@
---
title: 4951(F) A rule has been ignored because its major version number was not recognized by Windows Firewall. (Windows 10)
description: Describes security event 4951(F) A rule has been ignored because its major version number was not recognized by Windows Firewall.
title: 4951(F) A rule has been ignored because its major version number wasn't recognized by Windows Firewall. (Windows 10)
description: Describes security event 4951(F) A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -14,7 +14,7 @@ ms.author: dansimp
ms.technology: windows-sec
---
# 4951(F): A rule has been ignored because its major version number was not recognized by Windows Firewall.
# 4951(F): A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
<img src="images/event-4951.png" alt="Event 4951 illustration" width="449" height="364" hspace="10" align="left" />
@ -25,7 +25,7 @@ ms.technology: windows-sec
When you create or edit a Windows Firewall rule, the settings that you can include depend upon the version of Windows you use when creating the rule. As new settings are added to later versions of Windows or to service packs for existing versions of Windows, the version number of the rules processing engine is updated, and that version number is stamped into rules that are created by using that version of Windows. For example, Windows Vista produces firewall rules that are stamped with version "v2.0". Future versions of Windows might use "v2.1", or "v3.0" to indicate, respectively, minor or major changes and additions.
If you create a firewall rule on a newer version of Windows that references firewall settings that are not available on earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows, the firewall engine produces this error to indicate that it cannot process the rule.
If you create a firewall rule on a newer version of Windows that references firewall settings that aren't available on earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows, the firewall engine produces this error to indicate that it can't process the rule.
The only solution is to remove the incompatible rule, and then deploy a compatible rule.
@ -73,11 +73,11 @@ The only solution is to remove the incompatible rule, and then deploy a compatib
- All
- Domain,Public
- Domain, Public
- Domain,Private
- Domain, Private
- Private,Public
- Private, Public
- Public
@ -89,17 +89,17 @@ The only solution is to remove the incompatible rule, and then deploy a compatib
- **ID** \[Type = UnicodeString\]: the unique identifier for ignored firewall rule.
To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **Name** \[Type = UnicodeString\]: the name of the rule which was ignored. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
- **Name** \[Type = UnicodeString\]: the name of the rule that was ignored. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
## Security Monitoring Recommendations
For 4951(F): A rule has been ignored because its major version number was not recognized by Windows Firewall.
For 4951(F): A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
- This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition. Typically this event indicates configuration issues, not security issues.

View File

@ -1,6 +1,6 @@
---
title: 4953(F) Windows Firewall ignored a rule because it could not be parsed. (Windows 10)
description: Describes security event 4953(F) Windows Firewall ignored a rule because it could not be parsed.
title: 4953(F) Windows Firewall ignored a rule because it couldn't be parsed. (Windows 10)
description: Describes security event 4953(F) Windows Firewall ignored a rule because it couldn't be parsed.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -14,7 +14,7 @@ ms.author: dansimp
ms.technology: windows-sec
---
# 4953(F): Windows Firewall ignored a rule because it could not be parsed.
# 4953(F): Windows Firewall ignored a rule because it couldn't be parsed.
<img src="images/event-4953.png" alt="Event 4953 illustration" width="449" height="375" hspace="10" align="left" />
@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
This event generates if Windows Firewall was not able to parse Windows Firewall rule for some reason.
This event generates if Windows Firewall wasn't able to parse Windows Firewall rule for some reason.
It can happen if Windows Firewall rule registry entry was corrupted.
@ -72,11 +72,11 @@ It can happen if Windows Firewall rule registry entry was corrupted.
- All
- Domain,Public
- Domain, Public
- Domain,Private
- Domain, Private
- Private,Public
- Private, Public
- Public
@ -90,7 +90,7 @@ It can happen if Windows Firewall rule registry entry was corrupted.
- **ID** \[Type = UnicodeString\]: the unique identifier for ignored firewall rule.
To see the unique ID of the rule, navigate to the “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, navigate to the “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
@ -100,7 +100,7 @@ It can happen if Windows Firewall rule registry entry was corrupted.
## Security Monitoring Recommendations
For 4953(F): Windows Firewall ignored a rule because it could not be parsed.
For 4953(F): Windows Firewall ignored a rule because it couldn't be parsed.
- This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition. Typically this event indicates configuration issues, not security issues.

View File

@ -1,6 +1,6 @@
---
title: 4957(F) Windows Firewall did not apply the following rule. (Windows 10)
description: Describes security event 4957(F) Windows Firewall did not apply the following rule.
description: Describes security event 4957(F) Windows Firewall didn't apply the following rule.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
This event generates when Windows Firewall starts or apply new rule, and the rule cannot be applied for some reason.
This event generates when Windows Firewall starts or apply new rule, and the rule can't be applied for some reason.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -69,17 +69,17 @@ This event generates when Windows Firewall starts or apply new rule, and the rul
- **ID** \[Type = UnicodeString\]: the unique identifier for not applied firewall rule.
To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **Name** \[Type = UnicodeString\]: the name of the rule which was not applied. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
- **Name** \[Type = UnicodeString\]: the name of the rule that wasn't applied. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
**Error Information:**
- **Reason** \[Type = UnicodeString\]: the reason why the rule was not applied.
- **Reason** \[Type = UnicodeString\]: the reason why the rule wasn't applied.
## Security Monitoring Recommendations

View File

@ -1,6 +1,6 @@
---
title: 4958(F) Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer. (Windows 10)
description: Describes security event 4958(F) Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer.
description: Describes security event 4958(F) Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -17,15 +17,15 @@ ms.technology: windows-sec
# 4958(F): Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer.
Windows Firewall with Advanced Security processed a rule that contains parameters that cannot be resolved on the local computer. The rule is therefore not enforceable on the computer and so is excluded from the runtime state of the firewall. This is not necessarily an error. Examine the rule for applicability on the computers to which it was applied.
Windows Firewall with Advanced Security processed a rule that contains parameters that can't be resolved on the local computer. The rule is therefore not enforceable on the computer and so is excluded from the runtime state of the firewall. This exclusion isn't necessarily an error. Examine the rule for applicability on the computers to which it was applied.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md)
***Event Schema:***
*Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer:
*Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer:
Rule Information:
%tID:%t%1
%tName:%t%2

View File

@ -19,9 +19,9 @@ ms.technology: windows-sec
Windows logs this event if the Windows Firewall service fails to start, or if it unexpectedly terminates. The error message indicates the cause of the service failure by including an error code in the text of the message.
This event doesn't generate during Windows Firewall service failures if Windows Firewall policy is incorrect\\corrupted or one of the service dependencies was not started.
This event doesn't generate during Windows Firewall service failures if Windows Firewall policy is incorrect\\corrupted or one of the service dependencies wasn't started.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other System Events](audit-other-system-events.md)

View File

@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates when an application was blocked from accepting incoming connections on the network by [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page).
If you dont have any firewall rules (Allow or Deny) in Windows Firewall for specific applications, you will get this event from [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page) layer, because by default this layer is denying any incoming connections.
If you dont have any firewall rules (Allow or Deny) in Windows Firewall for specific applications, you'll get this event from [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page) layer, because by default this layer is denying any incoming connections.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -82,8 +82,8 @@ For 5031(F): The Windows Firewall Service blocked an application from accepting
- You can use this event to detect applications for which no Windows Firewall rules were created.
- If you have a pre-defined application which should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- If you have a pre-defined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”

View File

@ -1,6 +1,6 @@
---
title: 5038(F) Code integrity determined that the image hash of a file is not valid. (Windows 10)
description: Describes security event 5038(F) Code integrity determined that the image hash of a file is not valid.
description: Describes security event 5038(F) Code integrity determined that the image hash of a file isn't valid.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -19,11 +19,11 @@ ms.technology: windows-sec
The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
This event generates by [Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) feature, if signature of a file is not valid.
This event generates by [Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) feature, if signature of a file isn't valid.
Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it's loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

View File

@ -19,9 +19,9 @@ ms.technology: windows-sec
This event should be generated when registry key was virtualized using [LUAFV](https://blogs.msdn.com/b/alexcarp/archive/2009/06/25/the-deal-with-luafv-sys.aspx).
This event occurs very rarely during standard LUAFV registry key virtualization.
This event occurs rarely during standard LUAFV registry key virtualization.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Registry](audit-registry.md)
@ -59,7 +59,7 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -19,9 +19,9 @@ ms.technology: windows-sec
This event should be generated when file was virtualized using [LUAFV](https://blogs.msdn.com/b/alexcarp/archive/2009/06/25/the-deal-with-luafv-sys.aspx).
This event occurs very rarely during standard LUAFV file virtualization.
This event occurs rarely during standard LUAFV file virtualization.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit File System](audit-file-system.md)
@ -59,5 +59,5 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for CNG troubleshooting.
This event is used for CNG troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5057(F): A cryptographic primitive operation failed.
This event generates in case of CNG primitive operation failure.
This event generates if there's a CNG primitive operation failure.
For more information about Cryptographic Next Generation (CNG) visit these pages:
@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

View File

@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
This event generates when an operation (read, write, delete, and so on) was performed on a file that contains a KSP key by using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs were used:
This event generates when an operation (read, write, delete, and so on) was performed on a file that contains a KSP key by using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs was used:
- Microsoft Software Key Storage Provider
@ -81,13 +81,13 @@ You can see these events, for example, during certificate renewal or export oper
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested key file operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested key file operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested key file operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -109,7 +109,7 @@ You can see these events, for example, during certificate renewal or export oper
- Microsoft Smart Card Key Storage Provider
- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this typically has “**UNKNOWN**” value. Can also have one of the following values:
- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this algorithm has “**UNKNOWN**” value. Can also have one of the following values:
- RSA algorithm created by Ron Rivest, Adi Shamir, and Leonard Adleman.
@ -129,7 +129,7 @@ You can see these events, for example, during certificate renewal or export oper
- ECDSA\_P521 Elliptic Curve Digital Signature Algorithm with 521-bit key length.
- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here is an output example:
- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here's an output example:
<img src="images/certutil-command.png" alt="Certutil command illustration" width="588" height="665" />

View File

@ -27,9 +27,9 @@ For more information about CNG, visit these pages:
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for CNG troubleshooting.
This event is used for CNG troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

View File

@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
This event generates when a cryptographic operation (open key, create key, create key, and so on) was performed using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs were used:
This event generates when a cryptographic operation (open key, create key, create key, and so on) was performed using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs was used:
- Microsoft Software Key Storage Provider
@ -78,13 +78,13 @@ This event generates when a cryptographic operation (open key, create key, creat
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested specific cryptographic operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested specific cryptographic operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested specific cryptographic operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -106,7 +106,7 @@ This event generates when a cryptographic operation (open key, create key, creat
- Microsoft Smart Card Key Storage Provider
- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this typically has “**UNKNOWN**” value. Can also have one of the following values:
- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this algorithm has “**UNKNOWN**” value. Can also have one of the following values:
- RSA algorithm created by Ron Rivest, Adi Shamir, and Leonard Adleman.
@ -126,7 +126,7 @@ This event generates when a cryptographic operation (open key, create key, creat
- ECDSA\_P521 Elliptic Curve Digital Signature Algorithm with 521-bit key length.
- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here is an output example:
- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here's an output example:
<img src="images/certutil-command.png" alt="Certutil command illustration" width="588" height="665" />

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5063(S, F): A cryptographic provider operation was attempted.
This event generates in BCryptUnregisterProvider() and BCryptRegisterProvider() functions. These are Cryptographic Next Generation (CNG) functions.
This event generates in BCryptUnregisterProvider() and BCryptRegisterProvider() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic provider was registered or unregistered.
@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5064(S, F): A cryptographic context operation was attempted.
This event generates in [BCryptCreateContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptcreatecontext)() and [BCryptDeleteContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptdeletecontext)() functions. These are Cryptographic Next Generation (CNG) functions.
This event generates in [BCryptCreateContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptcreatecontext)() and [BCryptDeleteContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptdeletecontext)() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic context was created or deleted.
@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -16,8 +16,7 @@ ms.technology: windows-sec
# 5065(S, F): A cryptographic context modification was attempted.
This event generates in [BCryptConfigureContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontext)() function. This is a Cryptographic Next Generation (CNG) function.
This event generates in [BCryptConfigureContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontext)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when configuration information was changed for existing CNG context.
@ -27,9 +26,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5066(S, F): A cryptographic function operation was attempted.
This event generates in [BCryptAddContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptaddcontextfunction)() and [BCryptRemoveContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptremovecontextfunction)() functions. These are Cryptographic Next Generation (CNG) functions.
This event generates in [BCryptAddContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptaddcontextfunction)() and [BCryptRemoveContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptremovecontextfunction)() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic function was added or removed from the list of functions that are supported by an existing CNG context.
@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,19 +17,19 @@ ms.technology: windows-sec
# 5067(S, F): A cryptographic function modification was attempted.
This event generates in [BCryptConfigureContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontextfunction)() function. This is a Cryptographic Next Generation (CNG) function.
This event generates in [BCryptConfigureContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontextfunction)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when configuration information for the cryptographic function of an existing CNG context was changed.
For more information about Cryptographic Next Generation (CNG) visit these pages:
For more information about Cryptographic Next Generation (CNG), visit these pages:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,17 +17,17 @@ ms.technology: windows-sec
# 5068(S, F): A cryptographic function provider operation was attempted.
This event generates in BCryptAddContextFunctionProvider() and BCryptRemoveContextFunctionProvider() functions. These are Cryptographic Next Generation (CNG) functions.
This event generates in BCryptAddContextFunctionProvider() and BCryptRemoveContextFunctionProvider() functions. These functions are Cryptographic Next Generation (CNG) functions.
For more information about Cryptographic Next Generation (CNG) visit these pages:
For more information about Cryptographic Next Generation (CNG), visit these pages:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,19 +17,19 @@ ms.technology: windows-sec
# 5069(S, F): A cryptographic function property operation was attempted.
This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This is a Cryptographic Next Generation (CNG) function.
This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was added or removed.
For more information about Cryptographic Next Generation (CNG) visit these pages:
For more information about Cryptographic Next Generation (CNG), visit these pages:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5070(S, F): A cryptographic function property modification was attempted.
This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This is a Cryptographic Next Generation (CNG) function.
This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was updated.
@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
This event is used for Cryptographic Next Generation (CNG) troubleshooting.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

View File

@ -27,7 +27,7 @@ This event generates every time an Active Directory object is modified.
To generate this event, the modified object must have an appropriate entry in [SACL](/windows/win32/secauthz/access-control-lists): the “**Write”** action auditing for specific attributes.
For a change operation you will typically see two 5136 events for one action, with different **Operation\\Type** fields: “Value Deleted” and then “Value Added”. “Value Deleted” event typically contains previous value and “Value Added” event contains new value.
For a change operation, you'll typically see two 5136 events for one action, with different **Operation\\Type** fields: “Value Deleted” and then “Value Added”. “Value Deleted” event typically contains previous value and “Value Added” event contains new value.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -82,13 +82,13 @@ For a change operation you will typically see two 5136 events for one action, wi
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify object” operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -142,13 +142,13 @@ For a change operation you will typically see two 5136 events for one action, wi
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- Take first 3 sections a6b34ab5-551b-4626.
- Take first three sections a6b34ab5-551b-4626.
- For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Delete - : b54ab3a61b552646b8ee2b36b3ee6672
- Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@ -180,7 +180,7 @@ For a change operation you will typically see two 5136 events for one action, wi
> **Note**&nbsp;&nbsp;[LDAP Display Name](/windows/win32/adschema/a-ldapdisplayname) is the name used by LDAP clients, such as the ADSI LDAP provider, to read and write the attribute by using the LDAP protocol.
- **Syntax (OID)** \[Type = UnicodeString\]**:** The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. Whether the attribute value must be a string, a number, or a unit of time is also defined. Every attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined.
- **Syntax (OID)** \[Type = UnicodeString\]**:** The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. Whether the attribute value must be a string, a number, or a unit of time is also defined. Every attribute of every object is associated with exactly one syntax. The syntaxes aren't represented as objects in the schema, but they're programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined.
| OID | Syntax Name | Description |
|----------|--------------------------------------------|----------------------------------------------------------|
@ -189,7 +189,7 @@ For a change operation you will typically see two 5136 events for one action, wi
| 2.5.5.2 | String(Object-Identifier) | The object identifier. |
| 2.5.5.3 | Case-Sensitive String | General String. |
| 2.5.5.4 | CaseIgnoreString(Teletex) | Differentiates uppercase and lowercase. |
| 2.5.5.5 | String(Printable), String(IA5) | Teletex. Does not differentiate uppercase and lowercase. |
| 2.5.5.5 | String(Printable), String(IA5) | Teletex. Doesn't differentiate uppercase and lowercase. |
| 2.5.5.6 | String(Numeric) | Printable string or IA5-String. |
| 2.5.5.7 | Object(DN-Binary) | Both character sets are case-sensitive. |
| 2.5.5.8 | Boolean | A sequence of digits. |
@ -205,7 +205,7 @@ For a change operation you will typically see two 5136 events for one action, wi
> Table 10. LDAP Attribute Syntax OIDs.
- **Value** \[Type = UnicodeString\]: the value which was added or deleted, depending on the **Operation\\Type** field.
- **Value** \[Type = UnicodeString\]: the value that was added or deleted, depending on the **Operation\\Type** field.
**Operation:**
@ -235,4 +235,4 @@ For 5136(S): A directory service object was modified.
- If you need to monitor modifications to specific Active Directory attributes, monitor for **LDAP Display Name** field with specific attribute name.
- It is better to monitor **Operation\\Type = Value Added** events, because you will see the new value of attribute. At the same time you can correlate to previous **Operation\\Type = Value Deleted** event with the same **Correlation ID** to see the previous value.
- It's better to monitor **Operation\\Type = Value Added** events, because you'll see the new value of attribute. At the same time, you can correlate to previous **Operation\\Type = Value Deleted** event with the same **Correlation ID** to see the previous value.

View File

@ -76,13 +76,13 @@ This event only generates if the parent object has a particular entry in its [SA
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested the “create object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested the “create object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create object” operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -136,13 +136,13 @@ This event only generates if the parent object has a particular entry in its [SA
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- Take first 3 sections a6b34ab5-551b-4626.
- Take first three sections a6b34ab5-551b-4626.
- For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Delete - : b54ab3a61b552646b8ee2b36b3ee6672
- Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@ -182,4 +182,4 @@ For 5137(S): A directory service object was created.
- If you need to monitor creation of Active Directory objects with specific classes, monitor for **Class** field with specific class name. For example, we recommend that you monitor all new group policy objects creations: **groupPolicyContainer** class.
- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5137](event-5137.md). There is no reason to audit all creation events for all types of Active Directory objects; find the most important locations (organizational units, folders, etc.) and monitor for creation of specific classes only (user, computer, group, etc.).
- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5137](event-5137.md). There's no reason to audit all creation events for all types of Active Directory objects; find the most important locations (organizational units, folders, etc.) and monitor for creation of specific classes only (user, computer, group, etc.).

View File

@ -77,13 +77,13 @@ This event only generates if the container to which the Active Directory object
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested that the object be undeleted or restored. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested that the object be undeleted or restored. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** name of account that requested that the object be undeleted or restored.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -105,7 +105,7 @@ This event only generates if the container to which the Active Directory object
**Object:**
- **Old DN** \[Type = UnicodeString\]: Old distinguished name of undeleted object. It will points to [Active Directory Recycle Bin](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392261(v=ws.10)) folder, in case if it was restored from it.
- **Old DN** \[Type = UnicodeString\]: Old distinguished name of undeleted object. It will point to [Active Directory Recycle Bin](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392261(v=ws.10)) folder, in case if it was restored from it.
> **Note**&nbsp;&nbsp;The LDAP API references an LDAP object by its **distinguished name (DN)**. A DN is a sequence of relative distinguished names (RDN) connected by commas.
>
@ -139,13 +139,13 @@ This event only generates if the container to which the Active Directory object
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- Take first 3 sections a6b34ab5-551b-4626.
- Take first three sections a6b34ab5-551b-4626.
- For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Delete - : b54ab3a61b552646b8ee2b36b3ee6672
- Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@ -185,4 +185,4 @@ For 5138(S): A directory service object was undeleted.
- If you need to monitor undelete operations (restoration) of Active Directory objects with specific classes, monitor for **Class** field with specific class name.
- It may be a good idea to monitor all undelete events, because the operation is not performed very often. Confirm that there is a reason for the object to be undeleted.
- It may be a good idea to monitor all undelete events, because the operation isn't performed often. Confirm that there's a reason for the object to be undeleted.

View File

@ -77,13 +77,13 @@ This event only generates if the destination object has a particular entry in it
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested the “move object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested the “move object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “move object” operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -139,13 +139,13 @@ This event only generates if the destination object has a particular entry in it
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- Take first 3 sections a6b34ab5-551b-4626.
- Take first three sections a6b34ab5-551b-4626.
- For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Delete - : b54ab3a61b552646b8ee2b36b3ee6672
- Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@ -185,4 +185,4 @@ For 5139(S): A directory service object was moved.
- If you need to monitor movement of Active Directory objects with specific classes, monitor for **Class** field with specific class name.
- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5139](event-5139.md). There is no reason to audit all movement events for all types of Active Directory objects, you need to find the most important locations (organizational units, folders, etc.) and monitor for movement of specific classes only to these locations (user, computer, group, etc.).
- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5139](event-5139.md). There's no reason to audit all movement events for all types of Active Directory objects, you need to find the most important locations (organizational units, folders, etc.) and monitor for movement of specific classes only to these locations (user, computer, group, etc.).

View File

@ -78,13 +78,13 @@ This event generates once per session, when first access attempt was made.
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -120,7 +120,7 @@ This event generates once per session, when first access attempt was made.
- ::1 or 127.0.0.1 means localhost.
- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port which was used from remote or local machine to request the access.
- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port that was used from remote or local machine to request the access.
- 0 for local access attempts.
@ -134,7 +134,7 @@ This event generates once per session, when first access attempt was made.
- **Access Mask** \[Type = HexInt32\]: the sum of hexadecimal values of requested access rights. See “Table 13. File access codes.” for different hexadecimal values for access rights. Has always “**0x1**” value for this event.
- **Accesses** \[Type = UnicodeString\]: the list of access rights which were requested by **Subject\\Security ID**. These access rights depend on **Object Type**. Has always “**ReadData (or ListDirectory)**” value for this event.
- **Accesses** \[Type = UnicodeString\]: the list of access rights that were requested by **Subject\\Security ID**. These access rights depend on **Object Type**. Has always “**ReadData (or ListDirectory)**” value for this event.
## Security Monitoring Recommendations
@ -144,9 +144,9 @@ For 5140(S, F): A network share object was accessed.
- If you have high-value computers for which you need to monitor all access to all shares or specific shares (“**Share Name**”), monitor this event<b>.</b> For example, you could monitor share **C$** on domain controllers.
- Monitor this event if the **Network Information\\Source Address** is not from your internal IP range.
- Monitor this event if the **Network Information\\Source Address** isn't from your internal IP range.
- Monitor this event if the **Network Information\\Source Address** should not be able to connect with the specific computer (**Computer:**).
- Monitor this event if the **Network Information\\Source Address** shouldn't be able to connect with the specific computer (**Computer:**).
- If you need to monitor access attempts to local shares from a specific IP address (“**Network Information\\Source Address”)**, use this event.

View File

@ -77,13 +77,13 @@ This event only generates if the deleted object has a particular entry in its [S
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete object” operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -137,13 +137,13 @@ This event only generates if the deleted object has a particular entry in its [S
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- Take first 3 sections a6b34ab5-551b-4626.
- Take first three sections a6b34ab5-551b-4626.
- For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- Delete - : b54ab3a61b552646b8ee2b36b3ee6672
- Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@ -193,4 +193,4 @@ For 5141(S): A directory service object was deleted.
- If you need to monitor deletion of Active Directory objects with specific classes, monitor for **Class** field with specific class name. For example, we recommend that you monitor for group policy objects deletions: **groupPolicyContainer** class.
- If you need to monitor deletion of specific Active Directory objects, monitor for **DN** field with specific object name. For example, if you have critical Active Directory objects which should not be deleted, monitor for their deletion.
- If you need to monitor deletion of specific Active Directory objects, monitor for **DN** field with specific object name. For example, if you have critical Active Directory objects that shouldn't be deleted, monitor for their deletion.

View File

@ -78,13 +78,13 @@ This event generates every time network share object was modified.
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify network share object” operation.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -120,9 +120,9 @@ This event generates every time network share object was modified.
<img src="images/advanced-sharing.png" alt="Advanced Sharing illustration" width="300" height="319" />
- **Old Remark** \[Type = UnicodeString\]: the old value of network share “**Comments:**” field. Has “**N/A**” value if it is not set.
- **Old Remark** \[Type = UnicodeString\]: the old value of network share “**Comments:**” field. Has “**N/A**” value if it isn't set.
- **New Remark** \[Type = UnicodeString\]: the new value of network share “**Comments:**” field. Has “**N/A**” value if it is not set.
- **New Remark** \[Type = UnicodeString\]: the new value of network share “**Comments:**” field. Has “**N/A**” value if it isn't set.
- **Old MaxUsers** \[Type = HexInt32\]: old hexadecimal value of “**Limit the number of simultaneous user to:**” field. Has “**0xFFFFFFFF**” value if the number of connections is unlimited.
@ -155,7 +155,7 @@ This event generates every time network share object was modified.
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
| "BO" | Backup operators | "NU" | Network logon user |
| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@ -167,7 +167,7 @@ This event generates every time network share object was modified.
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
| "WD" | Everyone | "SU" | Service logon user |
| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@ -187,7 +187,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@ -213,7 +213,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@ -224,7 +224,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@ -246,7 +246,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: <https://msdn.microsoft.com/library/cc230374.aspx>, <https://msdn.microsoft.com/library/windows/hardware/aa374892(v=vs.85).aspx>.

View File

@ -78,13 +78,13 @@ This event generates every time network share object (file or folder) was access
**Subject:**
- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -120,7 +120,7 @@ This event generates every time network share object (file or folder) was access
- ::1 or 127.0.0.1 means localhost.
- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port which was used from remote or local machine to request the access.
- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port that was used from remote or local machine to request the access.
- 0 for local access attempts.
@ -136,7 +136,7 @@ This event generates every time network share object (file or folder) was access
- **Access Mask** \[Type = HexInt32\]: the sum of hexadecimal values of requested access rights. See “Table 13. File access codes.” for different hexadecimal values for access rights.
- **Accesses** \[Type = UnicodeString\]: the list of access rights which were requested by **Subject\\Security ID**. These access rights depend on **Object Type**.
- **Accesses** \[Type = UnicodeString\]: the list of access rights that were requested by **Subject\\Security ID**. These access rights depend on **Object Type**.
## Table of file access codes
@ -144,10 +144,10 @@ This event generates every time network share object (file or folder) was access
|-----------------------------------------------------------|----------------------------|---------------|
| ReadData (or ListDirectory) | 0x1,<br>%%4416 | **ReadData -** For a file object, the right to read the corresponding file data. For a directory object, the right to read the corresponding directory data.<br>**ListDirectory -** For a directory, the right to list the contents of the directory. |
| WriteData (or AddFile) | 0x2,<br>%%4417 | **WriteData -** For a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (**FILE\_ADD\_FILE**).<br>**AddFile -** For a directory, the right to create a file in the directory. |
| AppendData (or AddSubdirectory or CreatePipeInstance) | 0x4,<br>%%4418 | **AppendData -** For a file object, the right to append data to the file. (For local files, write operations will not overwrite existing data if this flag is specified without **FILE\_WRITE\_DATA**.) For a directory object, the right to create a subdirectory (**FILE\_ADD\_SUBDIRECTORY**). <br>**AddSubdirectory -** For a directory, the right to create a subdirectory.<br>**CreatePipeInstance -** For a named pipe, the right to create a pipe. |
| AppendData (or AddSubdirectory or CreatePipeInstance) | 0x4,<br>%%4418 | **AppendData -** For a file object, the right to append data to the file. (For local files, write operations won't overwrite existing data if this flag is specified without **FILE\_WRITE\_DATA**.) For a directory object, the right to create a subdirectory (**FILE\_ADD\_SUBDIRECTORY**). <br>**AddSubdirectory -** For a directory, the right to create a subdirectory.<br>**CreatePipeInstance -** For a named pipe, the right to create a pipe. |
| ReadEA | 0x8,<br>%%4419 | The right to read extended file attributes. |
| WriteEA | 0x10,<br>%%4420 | The right to write extended file attributes. |
| Execute/Traverse | 0x20,<br>%%4421 | **Execute** - For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.<br>**Traverse -** For a directory, the right to traverse the directory. By default, users are assigned the **BYPASS\_TRAVERSE\_CHECKING**&thinsp; [privilege](/windows/win32/secauthz/privileges), which ignores the **FILE\_TRAVERSE**&thinsp; [access right](/windows/win32/secauthz/access-rights-and-access-masks). See the remarks in [File Security and Access Rights](/windows/win32/fileio/file-security-and-access-rights) for more information. |
| Execute/Traverse | 0x20,<br>%%4421 | **Execute** - For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.<br>**Traverse -** For a directory, the right to traverse the directory. By default, users are assigned the **BYPASS\_TRAVERSE\_CHECKING**&thinsp; [privilege](/windows/win32/secauthz/privileges), which ignores the **FILE\_TRAVERSE**&thinsp; [access right](/windows/win32/secauthz/access-rights-and-access-masks). For more information, see the remarks in [File Security and Access Rights](/windows/win32/fileio/file-security-and-access-rights). |
| DeleteChild | 0x40,<br>%%4422 | For a directory, the right to delete a directory and all the files it contains, including read-only files. |
| ReadAttributes | 0x80,<br>%%4423 | The right to read file attributes. |
| WriteAttributes | 0x100,<br>%%4424 | The right to write file attributes. |
@ -155,7 +155,7 @@ This event generates every time network share object (file or folder) was access
| READ\_CONTROL | 0x20000,<br>%%1538 | The right to read the information in the object's security descriptor, not including the information in the system access control list (SACL). |
| WRITE\_DAC | 0x40000,<br>%%1539 | The right to modify the discretionary access control list (DACL) in the object's security descriptor. |
| WRITE\_OWNER | 0x80000,<br>%%1540 | The right to change the owner in the object's security descriptor |
| SYNCHRONIZE | 0x100000,<br>%%1541 | The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right. |
| SYNCHRONIZE | 0x100000,<br>%%1541 | The right to use the object for synchronization. This right enables a thread to wait until the object is in the signaled state. Some object types don't support this access right. |
| ACCESS\_SYS\_SEC | 0x1000000,<br>%%1542 | The ACCESS\_SYS\_SEC access right controls the ability to get or set the SACL in an object's security descriptor. |
> <span id="_Ref433878809" class="anchor"></span>Table 13. File access codes.
@ -193,7 +193,7 @@ REQUESTED\_ACCESS: RESULT ACE\_WHICH\_ ALLOWED\_OR\_DENIED\_ACCESS.
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
| "BO" | Backup operators | "NU" | Network logon user |
| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@ -205,7 +205,7 @@ REQUESTED\_ACCESS: RESULT ACE\_WHICH\_ ALLOWED\_OR\_DENIED\_ACCESS.
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
| "WD" | Everyone | "SU" | Service logon user |
| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@ -225,7 +225,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@ -251,7 +251,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@ -262,7 +262,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@ -284,7 +284,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: <https://msdn.microsoft.com/library/cc230374.aspx>, <https://msdn.microsoft.com/library/windows/hardware/aa374892(v=vs.85).aspx>.
@ -294,9 +294,9 @@ For 5145(S, F): A network share object was checked to see whether client can be
> **Important**&nbsp;&nbsp;For this event, also see [Appendix A: Security monitoring recommendations for many audit events](appendix-a-security-monitoring-recommendations-for-many-audit-events.md).
- Monitor this event if the **Network Information\\Source Address** is not from your internal IP range.
- Monitor this event if the **Network Information\\Source Address** isn't from your internal IP range.
- Monitor this event if the **Network Information\\Source Address** should not be able to connect with the specific computer (**Computer:**).
- Monitor this event if the **Network Information\\Source Address** shouldn't be able to connect with the specific computer (**Computer:**).
- If you have critical files or folders on specific network shares, for which you need to monitor access attempts (Success and Failure), monitor for specific **Share Information\\Share Name** and **Share Information\\Relative Target Name**.

View File

@ -17,9 +17,9 @@ ms.technology: windows-sec
# 5148(F): The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded.
In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack starts or was detected.
In most circumstances, this event occurs rarely. It's designed to be generated when an ICMP DoS attack starts or was detected.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Object Access Events](audit-other-object-access-events.md)

View File

@ -17,9 +17,9 @@ ms.technology: windows-sec
# 5149(F): The DoS attack has subsided and normal processing is being resumed.
In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack ended.
In most circumstances, this event occurs rarely. It's designed to be generated when an ICMP DoS attack ends.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other Object Access Events](audit-other-object-access-events.md)

View File

@ -109,7 +109,7 @@ This event is generated for every received network packet.
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number on which application received the packet.
@ -123,7 +123,7 @@ This event is generated for every received network packet.
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number that was used from remote machine to send the packet.
@ -167,20 +167,20 @@ For 5152(F): The Windows Filtering Platform blocked a packet.
- If you have a pre-defined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that **Source Address** is one of the addresses assigned to the computer.
- If the computer or device should not have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5152](event-5152.md) events where **Destination Address** is an IP address from the Internet (not from private IP ranges).
- If the computer or device shouldn't have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5152](event-5152.md) events where **Destination Address** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in **Destination Address**.
- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in **“Destination Address”** that are not in the allow list.
- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in **“Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5152](event-5152.md) events with that “**Source Port**.**”**
- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computers communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”

View File

@ -95,10 +95,10 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
- IPv6 Address
- :: - all IP addresses in IPv6 format
s
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]: source TCP\\UDP port number that was requested for listening by application.
@ -112,7 +112,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Filter Information:**
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows application to listen on the specific port. By default Windows firewall won't prevent a port from being listened by an application and if this application doesnt match any filters you will get value **0** in this field.
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows application to listen on the specific port. By default Windows firewall won't prevent a port from being listened by an application and if this application doesnt match any filters you'll get value **0** in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find specific substring with required filter ID (**&lt;filterId&gt;**)**,** for example:
@ -128,7 +128,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
For 5154(S): The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections.
- If you have an “allow list” of applications that are associated with certain operating systems or server roles, and that are expected to listen on specific ports, monitor this event for **“Application Name”** and other relevant information.
- If you've an “allowlist” of applications that are associated with certain operating systems or server roles, and that are expected to listen on specific ports, monitor this event for **“Application Name”** and other relevant information.
- If a certain application is allowed to listen only on specific port numbers, monitor this event for **“Application Name”** and **“Network Information\\Source Port**.**”**
@ -138,7 +138,7 @@ For 5154(S): The Windows Filtering Platform has permitted an application or serv
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”

View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5155(F): The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections.
By default Windows firewall won't prevent a port from being listened by an application. In the other word, Windows system will not generate Event 5155 by itself.
By default Windows firewall won't prevent a port from being listened by an application. In the other word, Windows system won't generate Event 5155 by itself.
You can add your own filters using the WFP APIs to block listen to reproduce this event: <https://msdn.microsoft.com/library/aa364046(v=vs.85).aspx>.
@ -72,7 +72,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
**Application Information**:
- **Process ID** \[Type = Pointer\]: Hexadecimal Process ID (PID) of the process which was permitted to bind to the local port. The PID is a number used by the operating system to uniquely identify an active process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
- **Process ID** \[Type = Pointer\]: Hexadecimal Process ID (PID) of the process that was permitted to bind to the local port. The PID is a number used by the operating system to uniquely identify an active process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
<img src="images/task-manager.png" alt="Task manager illustration" width="585" height="375" />
@ -100,7 +100,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** The port number used by the application.
@ -126,7 +126,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
**Filter Information:**
- **Filter Run-Time ID** \[Type = UInt64\]: A unique filter ID which blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding to an application, and if this application doesnt match any filters, you will get a 0 value in this field.
- **Filter Run-Time ID** \[Type = UInt64\]: A unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding to an application, and if this application doesnt match any filters, you'll get a 0 value in this field.
To find a specific Windows Filtering Platform filter by ID, you need to execute the following command: **netsh wfp show filters**. As a result of this command, a **filters.xml** file will be generated. You need to open this file and find the specific substring with the required filter ID (**&lt;filterId&gt;**), for example:
@ -134,7 +134,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
- **Layer Name** \[Type = UnicodeString\]: [Application Layer Enforcement](/windows/win32/fwp/application-layer-enforcement--ale-) layer name.
- **Layer Run-Time ID** \[Type = UInt64\]: Windows Filtering Platform layer identifier. To find a specific Windows Filtering Platform layer ID, you need to execute the following command: **netsh wfp show state**. As result of this command, a **wfpstate.xml** file will be generated. You need to open this file and find the specific substring with the required layer ID (**&lt;layerId&gt;**), for example:
- **Layer Run-Time ID** \[Type = UInt64\]: Windows Filtering Platform layer identifier. To find a specific Windows Filtering Platform layer ID, you need to execute the following command: **netsh wfp show state**. As a result of this command, a **wfpstate.xml** file will be generated. You need to open this file and find the specific substring with the required layer ID (**&lt;layerId&gt;**), for example:
<img src="images/wfpstate-xml.png" alt="Wfpstate xml illustration" width="1563" height="780" />

View File

@ -109,7 +109,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number from which the connection was initiated.
@ -123,7 +123,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number where the connection was received.
@ -167,20 +167,20 @@ For 5156(S): The Windows Filtering Platform has permitted a connection.
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that “**Source Address”** is one of the addresses assigned to the computer.
- If the computer or device should not have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5156](event-5156.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If the computer or device shouldn't have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5156](event-5156.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in “**Destination Address**.**”**
- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that are not in the allow list.
- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5156](event-5156.md) events with that “**Source Port**.**”**
- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computers communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”

View File

@ -109,7 +109,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number on which application received the connection.
@ -123,7 +123,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number that was used from remote machine to initiate connection.
@ -167,20 +167,20 @@ For 5157(F): The Windows Filtering Platform has blocked a connection.
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that “**Source Address”** is one of the addresses assigned to the computer.
- If the\` computer or device should not have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5157](event-5157.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If the\` computer or device shouldn't have access to the Internet, or contains only applications that dont connect to the Internet, monitor for [5157](event-5157.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in “**Destination Address**.**”**
- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that are not in the allow list.
- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5157](event-5157.md) events with that “**Source Port**.**”**
- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computers communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”

View File

@ -90,7 +90,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Network Information:**
- **Source Address** \[Type = UnicodeString\]**:** local IP address on which application was bind the port.
- **Source Address** \[Type = UnicodeString\]**:** local IP address on which application was bound the port.
- IPv4 Address
@ -100,7 +100,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number which application was bind.
@ -126,7 +126,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Filter Information:**
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows the application to bind the port. By default, Windows firewall won't prevent a port from being bound by an application. If this application doesnt match any filters, you will get value 0 in this field.
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows the application to bind the port. By default, Windows firewall won't prevent a port from being bound by an application. If this application doesnt match any filters, you'll get value 0 in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find specific substring with required filter ID (**&lt;filterId&gt;**)**,** for example:
@ -144,7 +144,7 @@ For 5158(S): The Windows Filtering Platform has permitted a bind to a local port
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
@ -152,6 +152,6 @@ For 5158(S): The Windows Filtering Platform has permitted a bind to a local port
- If you need to monitor all actions with a specific local port, monitor for [5158](event-5158.md) events with that “**Source Port.”**
- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 6 or 17.
- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 6 or 17.
- If the computers communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”

View File

@ -98,7 +98,7 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
- 0.0.0.0 - all IP addresses in IPv4 format
- 127.0.0.1 , ::1 - localhost
- 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** the port number used by the application.
@ -124,7 +124,7 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
**Filter Information:**
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding by an application, and if this application doesnt match any filters, you will get value 0 in this field.
- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding by an application, and if this application doesnt match any filters, you'll get value 0 in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find the specific substring with the required filter ID (**&lt;filterId&gt;**)**,** for example:
@ -138,4 +138,4 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -85,7 +85,7 @@ It typically generates when network adapter connects to new wireless network.
- **Account Name** \[Type = UnicodeString\]**:** the name of the account for which 802.1x authentication request was made.
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following:
- **Account Domain** \[Type = UnicodeString\]**:** subjects domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@ -125,16 +125,16 @@ You can see interfaces GUID using the following commands:
- **Reason Code** \[Type = UnicodeString\]**:** contains Reason Text (explanation of Reason Code) and Reason Code for wireless authentication results. See more information about reason codes for wireless authentication here: <https://msdn.microsoft.com/library/windows/desktop/dd877212(v=vs.85).aspx>, <https://technet.microsoft.com/library/cc727747(v=ws.10).aspx>.
- **Error Code** \[Type = HexInt32\]**:** there is no information about this field in this document.
- **Error Code** \[Type = HexInt32\]**:** there's no information about this field in this document.
- **EAP Reason Code** \[Type = HexInt32\]**:** there is no information about this field in this document. See additional information here: <https://technet.microsoft.com/library/dd197570(v=ws.10).aspx>.
- **EAP Reason Code** \[Type = HexInt32\]**:** there's no information about this field in this document. See additional information here: <https://technet.microsoft.com/library/dd197570(v=ws.10).aspx>.
- **EAP Root Cause String** \[Type = UnicodeString\]**:** there is no information about this field in this document.
- **EAP Root Cause String** \[Type = UnicodeString\]**:** there's no information about this field in this document.
- **EAP Error Code** \[Type = HexInt32\]**:** there is no information about this field in this document.
- **EAP Error Code** \[Type = HexInt32\]**:** there's no information about this field in this document.
## Security Monitoring Recommendations
For 5632(S, F): A request was made to authenticate to a wireless network.
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time settings from the “Security Settings” section in the group policy object are applied successfully to a computer, without any errors. This event generates on the target computer itself.
It is a routine event which shows you the list of Group Policy Objects that include “Security Settings” policies, and that were applied to the computer.
It's a routine event that shows you the list of Group Policy Objects that include “Security Settings” policies, and that were applied to the computer.
This event generates every time Group Policy is applied to the computer.
@ -82,7 +82,7 @@ You can find specific GROUP\_POLICY\_GUID using **Get-GPO** PowerShell cmdlet wi
For 6144(S): Security policy in the group policy objects has been applied successfully.
- If you have a pre-defined list of Group Policy Objects which contain Security Settings and must be applied to specific computers, then you can compare the list from this event with your list and in case of any difference trigger an alert.
- If you have a pre-defined list of Group Policy Objects that contain Security Settings and must be applied to specific computers, then you can compare the list from this event with your list and if there's any difference, you must trigger an alert.
- This event is mostly an informational event.

View File

@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time settings from the “Security Settings” section in the group policy object are applied to a computer with one or more errors. This event generates on the target computer itself.
This event generates, for example, if the [SID](/windows/win32/secauthz/security-identifiers) of a security principal which was included in one of the Group Policy settings cannot be resolved or translated to the real account name.
This event generates, for example, if the [SID](/windows/win32/secauthz/security-identifiers) of a security principal which was included in one of the Group Policy settings can't be resolved or translated to the real account name.
> **Note**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -66,7 +66,7 @@ This event generates, for example, if the [SID](/windows/win32/secauthz/security
***Field Descriptions:***
**Error Code** \[Type = UInt32\]: specific error code which shows the error which happened during Group Policy processing. You can find the meaning of specific error code here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>. For example, error code 1332 means that “no mapping between account names and security IDs was done”.
**Error Code** \[Type = UInt32\]: specific error code that shows the error that happened during Group Policy processing. You can find the meaning of specific error code here: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>. For example, error code 1332 means that “no mapping between account names and security IDs was done”.
**GPO List** \[Type = UnicodeString\]: the list of Group Policy Objects that include “Security Settings” policies, and that were applied with errors to the computer. The format of the list item is: “GROUP\_POLICY\_GUID GROUP\_POLICY\_NAME”.
@ -80,7 +80,7 @@ You can find specific GROUP\_POLICY\_GUID using **Get-GPO** PowerShell cmdlet wi
For 6145(F): One or more errors occurred while processing security policy in the group policy objects.
- This event indicates that Group Policy Objects which were applied to the computer or device had some errors during processing. If you see this event, we recommend checking settings in the GPOs from **GPO List** and resolving the cause of the errors.
- This event indicates that Group Policy Objects that were applied to the computer or device had some errors during processing. If you see this event, we recommend checking settings in the GPOs from **GPO List** and resolving the cause of the errors.
- If you have a pre-defined list of Group Policy Objects that contain Security Settings and that must be applied to specific computers, check this event to see if errors occurred when the Security Settings were applied. If so, you can review the error codes and investigate the cause of the failure.

View File

@ -1,6 +1,6 @@
---
title: 6281(F) Code Integrity determined that the page hashes of an image file are not valid. (Windows 10)
description: Describes security event 6281(F) Code Integrity determined that the page hashes of an image file are not valid.
title: 6281(F) Code Integrity determined that the page hashes of an image file aren't valid. (Windows 10)
description: Describes security event 6281(F) Code Integrity determined that the page hashes of an image file aren't valid.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -14,16 +14,16 @@ ms.author: dansimp
ms.technology: windows-sec
---
# 6281(F): Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
# 6281(F): Code Integrity determined that the page hashes of an image file aren't valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it's loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
This event generates when [code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. This event also generates when signing certificate was revoked. The invalid hashes could indicate a potential disk device error.
This event generates when [code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) determined that the page hashes of an image file aren't valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. This event also generates when signing certificate was revoked. The invalid hashes could indicate a potential disk device error.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

View File

@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other System Events](audit-other-system-events.md)
@ -35,4 +35,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other System Events](audit-other-system-events.md)
@ -37,4 +37,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

View File

@ -1,6 +1,6 @@
---
title: 6407(-) 1%. (Windows 10)
description: Describes security event 6407(-) 1%. This is a BranchCache event, which is outside the scope of this document.
description: Describes security event 6407(-) 1%. This event is a BranchCache event, which is outside the scope of this document.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
There is no example of this event in this document.
There's no example of this event in this document.
***Subcategory:***&nbsp;[Audit Other System Events](audit-other-system-events.md)
@ -35,4 +35,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
- There is no recommendation for this event in this document.
- There's no recommendation for this event in this document.

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