mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-26 15:53:40 +00:00
Merge pull request #5436 from MicrosoftDocs/repo_sync_working_branch
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
@ -10,7 +10,7 @@ ms.prod: w10
|
||||
ms.technology: windows
|
||||
author: dansimp
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 06/23/2021
|
||||
ms.date: 07/23/2021
|
||||
---
|
||||
|
||||
# Defender CSP
|
||||
@ -61,7 +61,7 @@ Defender
|
||||
--------SupportLogLocation (Added in the next major release of Windows 10)
|
||||
--------PlatformUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
|
||||
--------EngineUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
|
||||
--------SignaturesUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
|
||||
--------DefinitionUpdatesChannel (Added with the 4.18.2106.5 Defender platform release)
|
||||
--------DisableGradualRelease (Added with the 4.18.2106.5 Defender platform release)
|
||||
----Scan
|
||||
----UpdateSignature
|
||||
|
@ -37,7 +37,7 @@ Take the following steps to create a configuration profile that will set require
|
||||
5. You are now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
|
||||
6. On the **Configuration settings** page, you will be adding multiple OMA-URI Settings that correspond to the policies described in [Manually configuring devices for Update Compliance](update-compliance-configuration-manual.md).
|
||||
1. If you don't already have it, get your Commercial ID. For steps, see [Get your CommmercialID](update-compliance-get-started.md#get-your-commercialid).
|
||||
2. Add a setting for **Commercial ID** ) with the following values:
|
||||
2. Add a setting for **Commercial ID** with the following values:
|
||||
- **Name**: Commercial ID
|
||||
- **Description**: Sets the Commercial ID that corresponds to the Update Compliance Log Analytics workspace.
|
||||
- **OMA-URI**: `./Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID`
|
||||
|
@ -5,7 +5,7 @@ keywords: updates, servicing, current, deployment, semi-annual channel, feature,
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: manage
|
||||
author: jaimeo
|
||||
ms.localizationpriority: medium
|
||||
ms.localizationpriority: high
|
||||
ms.author: jaimeo
|
||||
ms.reviewer:
|
||||
manager: laurawi
|
||||
|
@ -105,7 +105,7 @@ Three approaches are documented here:
|
||||
|
||||
1. Update the certificate template by executing the following command:
|
||||
|
||||
certutil - dsaddtemplate \<TemplateName\>.txt
|
||||
certutil -dsaddtemplate \<TemplateName\>.txt
|
||||
|
||||
1. In the Certificate Authority console, right-click **Certificate Templates**, select **New**, and select **Certificate Template to Issue**
|
||||
|
||||
|
@ -282,6 +282,7 @@ The most common values:
|
||||
| 2 | PA-ENC-TIMESTAMP | This is a normal type for standard password authentication. |
|
||||
| 11 | PA-ETYPE-INFO | The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.<br>Never saw this Pre-Authentication Type in Microsoft Active Directory environment. |
|
||||
| 15 | PA-PK-AS-REP\_OLD | Used for Smart Card logon authentication. |
|
||||
| 16 | PA-PK-AS-REQ | Request sent to KDC in Smart Card authentication scenarios. |
|
||||
| 17 | PA-PK-AS-REP | This type should also be used for Smart Card authentication, but in certain Active Directory environments, it is never seen. |
|
||||
| 19 | PA-ETYPE-INFO2 | The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.<br>Never saw this Pre-Authentication Type in Microsoft Active Directory environment. |
|
||||
| 20 | PA-SVR-REFERRAL-INFO | Used in KDC Referrals tickets. |
|
||||
|
@ -119,7 +119,7 @@ In either of the scenarios above, once these rules are added they must be delete
|
||||
|
||||
When designing a set of firewall policies for your network, it is a best practice to configure allow rules for any networked applications deployed on the host. Having these rules in place before the user first launches the application will help ensure a seamless experience.
|
||||
|
||||
The absence of these staged rules does not necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime requires user interaction.
|
||||
The absence of these staged rules does not necessarily mean that in the end an application will be unable to communicate on the network. However, the behaviors involved in the automatic creation of application rules at runtime require user interaction and administrative privilege. If the device is expected to be used by non-administrative users, you should follow best practices and provide these rules before the application's first launch to avoid unexpected networking issues.
|
||||
|
||||
To determine why some applications are blocked from communicating in the network, check for the following:
|
||||
|
||||
@ -129,6 +129,8 @@ To determine why some applications are blocked from communicating in the network
|
||||
|
||||
3. Local Policy Merge is disabled, preventing the application or network service from creating local rules.
|
||||
|
||||
Creation of application rules at runtime can also be prohibited by administrators using the Settings app or Group Policy.
|
||||
|
||||

|
||||
|
||||
*Figure 4: Dialog box to allow access*
|
||||
@ -207,4 +209,4 @@ For tasks related to creating outbound rules, see [Checklist: Creating Outbound
|
||||
|
||||
## Document your changes
|
||||
|
||||
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
|
||||
When creating an inbound or outbound rule, you should specify details about the app itself, the port range used, and important notes like creation date. Rules must be well-documented for ease of review both by you and other admins. We highly encourage taking the time to make the work of reviewing your firewall rules at a later date easier. And *never* create unnecessary holes in your firewall.
|
||||
|
Reference in New Issue
Block a user