Light copyedit

windows/security/identity-protection/access-control/local-accounts.md
https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/a69576be-9a47-4363-8299-e82d8685dcad#CORRECTNESS
Line 120: users > user's
Line 126: are > is

windows/security/identity-protection/configure-s-mime.md
https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/4f3b39d4-9f2a-4c07-8f5b-d2f7571146fc#CORRECTNESS
Line 30: recipient(s) > recipients

windows/security/identity-protection/credential-guard/additional-mitigations.md
https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/ba28fde6-7ce6-4950-b001-6e3d14d57a05#CORRECTNESS
Line 21: sign on > sign on to
Lines 99 and 105: sign on > sign-on

windows/security/identity-protection/credential-guard/credential-guard-considerations.md
https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/129d9030-fcec-42a2-884f-182d9c3e8a98#CORRECTNESS
Line 83: signed-in > signed in
Line 84: signed-in > signed in

windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/b9c05e69-3ba6-4c2b-8770-1af996ae98dc#CORRECTNESS
Line 126 and 132: sign on > sign-on
This commit is contained in:
Angela Fleischmann 2022-08-11 18:03:02 -06:00
parent 7e4630059c
commit cdcf5eb2f3
5 changed files with 11 additions and 11 deletions

View File

@ -117,13 +117,13 @@ In addition, the guest user in the Guest account shouldn't be able to view the e
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'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.
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 user's 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: In Windows Server 2008, Remote Desktop Services are called Terminal Services.
- 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: In Windows Server 2008, Remote Desktop Services is 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.

View File

@ -27,7 +27,7 @@ S/MIME stands for Secure/Multipurpose Internet Mail Extensions, and provides an
Users can send encrypted message to people in their organization and people outside their organization if they have their encryption certificates. However, users using Windows Mail app can only read encrypted messages if the message is received on their Exchange account and they have corresponding decryption keys.
Encrypted messages can be read only by recipients who have a certificate. If you try to send an encrypted message to recipient(s) whose encryption certificate are not available, the app will prompt you to remove these recipients before sending the email.
Encrypted messages can be read only by recipients who have a certificate. If you try to send an encrypted message to recipients whose encryption certificate are not available, the app will prompt you to remove these recipients before sending the email.
## About digital signatures

View File

@ -18,7 +18,7 @@ Windows Defender Credential Guard can provide mitigation against attacks on deri
## Restricting domain users to specific domain-joined devices
Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on using devices that have Windows Defender Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Windows Defender Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used.
Credential theft attacks allow the attacker to steal secrets from one device and use them from another device. If a user can sign on to multiple devices then any device could be used to steal credentials. How do you ensure that users only sign on with devices that have Windows Defender Credential Guard enabled? By deploying authentication policies that restrict them to specific domain-joined devices that have been configured with Windows Defender Credential Guard. For the domain controller to know what device a user is signing on from, Kerberos armoring must be used.
### Kerberos armoring
@ -32,7 +32,7 @@ Kerberos armoring is part of RFC 6113. When a device supports Kerberos armoring,
### Protecting domain-joined device secrets
Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Windows Defender Credential Guard, the private key can be protected. Then authentication policies can require that users sign on devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
Since domain-joined devices also use shared secrets for authentication, attackers can steal those secrets as well. By deploying device certificates with Windows Defender Credential Guard, the private key can be protected. Then authentication policies can require that users sign on to devices that authenticate using those certificates. This prevents shared secrets stolen from the device to be used with stolen user credentials to sign on as the user.
Domain-joined device certificate authentication has the following requirements:
- Devices' accounts are in Windows Server 2012 domain functional level or higher.
@ -96,13 +96,13 @@ Beginning with the Windows Server 2008 R2 domain functional level, domain contro
.\set-IssuancePolicyToGroupLink.ps1 IssuancePolicyName:"<name of issuance policy>" groupOU:"<Name of OU to create>" groupName:”<name of Universal security group to create>"
```
### Restricting user sign on
### Restricting user sign-on
So we now have completed the following:
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
- Mapped that policy to a universal security group or claim
- Provided a way for domain controllers to get the device authorization data during user sign on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
Authentication policies have the following requirements:
- User accounts are in a Windows Server 2012 domain functional level or higher domain.

View File

@ -80,8 +80,8 @@ Domain user sign-in on a domain-joined device after clearing a TPM for as long a
|Credential Type | Windows version | Behavior
|---|---|---|
| Certificate (smart card or Windows Hello for Business) | All | All data protected with user DPAPI is unusable and user DPAPI doesn't work at all. |
| Password | Windows 10 v1709 or later | If the user signed-in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected.
| Password | Windows 10 v1703 | If the user signed-in with a password prior to clearing the TPM, then they can sign-in with that password and are unaffected.
| Password | Windows 10 v1709 or later | If the user signed in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected.
| Password | Windows 10 v1703 | If the user signed in with a password prior to clearing the TPM, then they can sign-in with that password and are unaffected.
| Password | Windows 10 v1607 or earlier | Existing user DPAPI protected data is unusable. User DPAPI is able to protect new data.
Once the device has connectivity to the domain controllers, DPAPI recovers the user's key and data protected prior to clearing the TPM can be decrypted.

View File

@ -123,13 +123,13 @@ Beginning with the Windows Server 2008 R2 domain functional level, domain contro
.\set-IssuancePolicyToGroupLink.ps1 IssuancePolicyName:"<name of issuance policy>" groupOU:"<Name of OU to create>" groupName:”<name of Universal security group to create>"
```
#### Restricting user sign on
#### Restricting user sign-on
So we now have completed the following:
- Created a special certificate issuance policy to identify devices that meet the deployment criteria required for the user to be able to sign on
- Mapped that policy to a universal security group or claim
- Provided a way for domain controllers to get the device authorization data during user sign on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
- Provided a way for domain controllers to get the device authorization data during user sign-on using Kerberos armoring. Now what is left to do is to configure the access check on the domain controllers. This is done using authentication policies.
Authentication policies have the following requirements:
- User accounts are in a Windows Server 2012 domain functional level or higher domain.