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

Merge pull request #6868 from MicrosoftDocs/main

Browse Source 
Publish 07/29/2022 3:30 PM PT
This commit is contained in:
Angela Fleischmann 2022-07-29 16:50:49 -06:00 committed by GitHub
commit 57bccaa541
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 66 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md
View File

@ -39,73 +39,18 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
:::image type="content" source="../media/windows-autopatch-device-registration-workflow-diagram.png" alt-text="Detailed device registration workflow diagram" lightbox="../media/windows-autopatch-device-registration-workflow-diagram.png":::
1. IT admin identifies devices to be managed by the Windows Autopatch service.
2. IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group.
3. The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.
1. Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:
1. AzureADDeviceID
2. OperatingSystem
3. DisplayName (Device name)
4. AccountEnabled
5. RegistrationDateTime
6. ApproximateLastSignInDateTime
2. In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.
4. The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:
1. **Serial number, model, and manufacturer.**
1. Checks if the serial number already exists in the Windows Autopatch’s managed device database.
2. **If the device is Intune-managed or not**.
1. Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.
1. If **yes**, it means this device is enrolled into Intune.
2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
2. **If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.
1. Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.
2. A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).
3. **If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.
3. **If the device is a Windows device or not**.
1. If it’s a Windows device, Windows Autopatch evaluates the following requirements:
1. Whether the **Windows OS version** is **greater or equal to 10**.
2. The **OS build** is **greater or equal to 1809**.
3. The **architecture** is **x64**.
4. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
1. **Enterprise**
2. **Pro**
3. **Pro Workstation**
5. If the device meets the operating system requirements, Windows Autopatch checks whether the device is either:
1. **Only managed by Intune**
1. If the device is only managed by Intune, the device is marked as **Passed all prerequisites**.
2. **Co-managed by both Configuration Manager and Intune**
1. If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state.
1. The required co-management workloads evaluated in this step are:
1. **Windows Updates Policies**
2. **Device Configuration**
3. **Office Click to Run**
2. If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.
5. Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:
1. If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.
2. If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.
6. Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:
1. **Modern Workplace Devices-Windows Autopatch-First**
1. The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.
2. **Modern Workplace Devices-Windows Autopatch-Fast**
3. **Modern Workplace Devices-Windows Autopatch-Broad**
7. Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:
1. **Modern Workplace Devices - All**
1. This group has all devices managed by Windows Autopatch.
2. When registering Windows 10 devices, use **Modern Workplace Devices Dynamic - Windows 10**
1. This group has all devices managed by Windows Autopatch and that have Windows 10 installed.
3. When registering Windows 11 devices, use **Modern Workplace Devices Dynamic - Windows 11**
1. This group has all devices managed by Windows Autopatch and that have Windows 11 installed.
4. When registering virtual devices, use **Modern Workplace Devices - Virtual Machine**
1. This group has all virtual devices managed by Windows Autopatch.
8. In post-device registration, three actions occur:
1. Windows Autopatch adds devices to its managed database.
2. Flags devices as **Active** in the **Ready** tab.
3. The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.
1. The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.
9. IT admins review the device registration status in both the **Ready** and **Not ready** tabs.
1. If the device was successfully registered, the device shows up in the **Ready** tab.
2. If not, the device shows up in the **Not ready** tab.
10. This is the end of the Windows Autopatch device registration workflow.
| Step | Description |
| ----- | ----- |
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.</li></ol> |
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.</li></ol></ol></ol>|
| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:<ol><li>If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 10 installed.</li></ol><li>When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 11 installed.</li></ol><li>When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all virtual devices managed by Windows Autopatch.</li></ol> |
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.</li><ol><li>The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not ready** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not ready** tab.</li></ol> |
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
## Detailed prerequisite check workflow diagram

12
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
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**.

32
windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
View File

@ -17,17 +17,17 @@ ms.technology: windows-sec
# Network access: Restrict clients allowed to make remote calls to SAM
**Applies to**
- Windows 10, version 1607 and later
- Windows 10, version 1511 with [KB 4103198](https://support.microsoft.com/help/4013198) installed
- Windows 10, version 1507 with [KB 4012606](https://support.microsoft.com/help/4012606) installed
- Windows 8.1 with [KB 4102219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed
- Windows 7 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2 with[KB 4012219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed
- Windows Server 2012 with [KB 4012220](https://support.microsoft.com/help/4012220/march-2017-preview-of-monthly-quality-rollup-for-windows-server-2012) installed
- Windows Server 2008 R2 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed
- Windows 10, version 1607 and later
- Windows 10, version 1511 with [KB 4103198](https://support.microsoft.com/help/4013198) installed
- Windows 10, version 1507 with [KB 4012606](https://support.microsoft.com/help/4012606) installed
- Windows 8.1 with [KB 4102219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed
- Windows 7 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2 with[KB 4012219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed
- Windows Server 2012 with [KB 4012220](https://support.microsoft.com/help/4012220/march-2017-preview-of-monthly-quality-rollup-for-windows-server-2012) installed
- Windows Server 2008 R2 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed
The **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting controls which users can enumerate users and groups in the local Security Accounts Manager (SAM) database and Active Directory.
The setting was first supported by Windows 10 version 1607 and Windows Server 2016 (RTM) and can be configured on earlier Windows client and server operating systems by installing updates from the KB articles listed in **Applies to** section of this topic.
@ -83,6 +83,7 @@ To avoid setting it manually in this case, you can configure the GPO itself on a
> For example, suppose a local administrator configures this setting as part of a local policy using the Local Security Policy snap-in (Secpol.msc), which edits that same registry path. If an enterprise administrator configures this setting as part of an enterprise GPO, that enterprise GPO will overwrite the same registry path.
## Default values
Beginning with Windows 10, version 1607 and Windows Server 2016, computers have hard-coded and more restrictive default values than earlier versions of Windows.
The different default values help strike a balance where recent Windows versions are more secure by default and older versions don’t undergo any disruptive behavior changes.
Administrators can test whether applying the same restriction earlier versions of Windows will cause compatibility problems for existing applications before implementing this security policy setting in a production environment.
@ -110,16 +111,17 @@ Audit-only mode configures the SAMRPC protocol to do the access check against th
|Setting|RestrictRemoteSamAuditOnlyMode|
|Data Type|REG_DWORD|
|Value|1|
|Notes|This setting can't be added or removed by using predefined Group Policy settings. <br> Administrators may create a custom policy to set the registry value if needed. <br> SAM responds dynamically to changes in this registry value without a reboot. <br> You can use the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script to parse the event logs, as explained in the next section.|
|Notes|This setting can't be added or removed by using predefined Group Policy settings. Administrators may create a custom policy to set the registry value if needed. SAM responds dynamically to changes in this registry value without a reboot. |
### Related events
There are corresponding events that indicate when remote calls to the SAM are restricted, what accounts attempted to read from the SAM database, and more. The following workflow is recommended to identify applications that may be affected by restricting remote calls to SAM:
1. Dump event logs to a common share.
2. Parse them with the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script.
3. Review Event IDs 16962 to 16969, as listed in the following table, in the System log with event source Directory-Service-SAM.
4. Identify which security contexts are enumerating users or groups in the SAM database.
5. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string.
1. Right click the System log, select **Filter Current Log**, and specify `16962-16969` in the Event IDs field.
1. Review Event IDs 16962 to 16969, as listed in the following table, with event source **Directory-Service-SAM**.
1. Identify which security contexts are enumerating users or groups in the SAM database.
1. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string.
|Event ID|Event Message Text|Explanation |
|---|---|---|