diff --git a/windows/deployment/windows-autopilot/add-devices.md b/windows/deployment/windows-autopilot/add-devices.md index d0ace72c1e..72ca57267c 100644 --- a/windows/deployment/windows-autopilot/add-devices.md +++ b/windows/deployment/windows-autopilot/add-devices.md @@ -24,19 +24,31 @@ ms.topic: article Before deploying a device using Windows Autopilot, the device must be registered with the Windows Autopilot deployment service. Ideally, this would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually. +## OEM registration + +When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers" section of the [Windows Autopilot information page](https://www.microsoft.com/en-us/windowsforbusiness/windows-autopilot). + +Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/registration-auth#oem-authorization). + +## Reseller, distributor, or partner registration + +Customers may purchase devices from resellers, distributors, or other partners. As long as these resellers, distributors, and partners are part of the [Cloud Solution Partners (CSP) program](https://partner.microsoft.com/en-us/cloud-solution-provider), they too can register devices on behalf of the customer. + +As with OEMs, CSP parnters must be granted permission to register devices on behalf of an organization. This follows the process described on the [Customer consent page](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/registration-auth#csp-authorization). The CSP partner initiates a request to establish a relationship with the organization, with approval granted by a global administrator from the organization. Once approved, CSP partners add devices using [Partner Center](https://partner.microsoft.com/en-us/pcv/dashboard/overview), either directly through the web site or via available APIs that can automate the same tasks. + +Windows Autopilot does not require delegated administrator permissions when establishing the relationship between the CSP partner and the organization. As part of the approval process performed by the global administrator, the global administrator can choose to uncheck the "Include delegated administration permissions" checkbox. + +## Automatic registration of existing devices + +If an existing device is already running Windows 10 version 1703 or later and enrolled in an MDM service such an Intune, that MDM service can ask the device for the hardwareh ID (also known as a hardware hash). Once it has that, it can automatically register the device with Windows Autopilot. + +For instructions on how to do this with Microsoft Intune, see [Create an Autopilot deployment profile](https://docs.microsoft.com/en-us/intune/enrollment-autopilot#create-an-autopilot-deployment-profile) documentation describing the "Convert all targeted devices to Autopilot" setting. + +Also note that when using the [Windows Autopilot for existing devices](https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/existing-devices) scenario, it is not necessary to pre-register the devices with Windows Autopilot. Instead, a configuration file (AutopilotConfigurationFile.json) containing all the Windows Autopilot profile settings is used; the device can be registered with Windows Autopilot after the fact using the same "Convert all targeted devices to Autopilot" setting. + ## Manual registration -To perform manual registration of a device, you must caputure its hardware ID (also known as a hardware hash) and upload this to the Windows Autopilot deployment service. See the topics below for detailed information on how to collect and upload hardware IDs. - ->[!IMPORTANT] ->Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run **sysprep /generalize /oobe**.
->After Intune reports the profile ready to go, only then should the device be connected to the Internet. - -Also note that if OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of OOBE retries: - -**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE** - -To ensure OOBE has not been restarted too many times, you can change this value to 1. +To perform manual registration of a device, you must first caputure its hardware ID (also known as a hardware hash). Once this process has completed, the resulting hardware ID can be uploaded to the Windows Autopilot service. Because this process requires booting the device into Windows 10 in order to obtain the hardware ID, this is intended primarily for testing and evaluation scenarios. ## Device identification @@ -44,9 +56,13 @@ To define a device to the Windows Autopilot deployment service, a unique hardwar The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device. -Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot Deployment Service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as motherboard replacement, would not match, so the device would need to be re-uploaded. +Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot deployment service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as a motherboard replacement, would not match, so a new hash would need to be generated and uploaded. -## Collecting the hardware ID from existing devices using PowerShell +### Collecting the hardware ID from existing devices using System Center Configuration Manager + +Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [What’s new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details. The hash information can be extracted from Configuration Manager into a CSV file. + +### Collecting the hardware ID from existing devices using PowerShell The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running Windows 10 version 1703 or later. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo). @@ -62,25 +78,23 @@ Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the Get-WindowsAutoPilotInfo script’s help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script. +>[!IMPORTANT] +>Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run **sysprep /generalize /oobe**.
+>After Intune reports the profile ready to go, only then should the device be connected to the Internet. + >[!NOTE] ->If you will connect to the device remotely to collect the hardware ID, see the information at the top of this page about device connectivity to the Internet. - -## Collecting the hardware ID from existing devices using System Center Configuration Manager - -Starting with System Center Configuration Manager current branch version 1802, the hardware hashes for existing Windows 10 version 1703 and higher devices are automatically collected by Configuration Manager. See the [What’s new in version 1802](https://docs.microsoft.com/sccm/core/plan-design/changes/whats-new-in-version-1802#report-on-windows-autopilot-device-information) documentation for more details. +>If OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of OOBE retries:
+>**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE**
+>To ensure OOBE has not been restarted too many times, you can change this value to 1. ## Registering devices Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism: -For guidance on how to register devices, configure and apply deployment profiles, follow one of the available administration options: +- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot). This is the preferred mechanism for all customers. -- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot) +- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot). This is used by CSP partners to register devices on behalf of customers. -- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles) +- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa). This is typically used by small and medium businesses (SMBs) who manage their devices using Microsoft 365 Business. -- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa) - -- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot) - -For those using Microsoft Intune, devices should normally be uploaded via Intune; for those using Microsoft 365 Business, its administrative portal would be used. For [Cloud Solution Provider (CSP)](https://partnercenter.microsoft.com/en-us/partner/cloud-solution-provider) partners uploading devices on the behalf of a customer that they are authorized to manage, Partner Center can be used. For any other scenario, the Microsoft Store for Business is available. +- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles). diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md index 019946e637..5bbc66c72d 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md @@ -124,9 +124,10 @@ If your AD FS farm is not already configured for Device Authentication (you can ![Device Registration](images/hybridct/device2.png) 2. On your AD FS primary server, ensure you are logged in as AD DS user with enterprise administrator privileges and open an elevated Windows PowerShell prompt. Then, run the following commands: - + `Import-module activedirectory` `PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "" ` + 3. On the pop-up window click **Yes**. > [!NOTE] @@ -136,7 +137,6 @@ If your AD FS farm is not already configured for Device Authentication (you can The above PSH creates the following objects: - - RegisteredDevices container under the AD domain partition - Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration - Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration @@ -166,7 +166,7 @@ If you plan to use Windows 10 domain join (with automatic registration to Azure 3. Run the following PowerShell command - `PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred ` + `PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred ` Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory. @@ -177,7 +177,7 @@ To ensure AD DS objects and containers are in the correct state for write back o 1. Open Windows PowerShell and execute the following: - `PS C:>Initialize-ADSyncDeviceWriteBack -DomainName -AdConnectorAccount [AD connector account name] ` + `PS C:>Initialize-ADSyncDeviceWriteBack -DomainName -AdConnectorAccount [AD connector account name] ` Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format @@ -230,55 +230,55 @@ The definition helps you to verify whether the values are present or if you need **`http://schemas.microsoft.com/ws/2012/01/accounttype`** - This claim must contain a value of **DJ**, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this: - @RuleName = "Issue account type for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "DJ" - ); + @RuleName = "Issue account type for domain-joined computers" + c:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", + Value = "DJ" + ); #### Issue objectGUID of the computer account on-premises **`http://schemas.microsoft.com/identity/claims/onpremobjectguid`** - This claim must contain the **objectGUID** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this: - @RuleName = "Issue object GUID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), - query = ";objectguid;{0}", - param = c2.Value - ); + @RuleName = "Issue object GUID for domain-joined computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + store = "Active Directory", + types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), + query = ";objectguid;{0}", + param = c2.Value + ); #### Issue objectSID of the computer account on-premises **`http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`** - This claim must contain the **objectSid** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this: - @RuleName = "Issue objectSID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue(claim = c2); + @RuleName = "Issue objectSID for domain-joined computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue(claim = c2); #### Issue issuerID for computer when multiple verified domain names in Azure AD @@ -338,138 +338,147 @@ To get a list of your verified company domains, you can use the [Get-MsolDomain] **`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`** - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows: - @RuleName = "Issue ImmutableID for computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), - query = ";objectguid;{0}", - param = c2.Value - ); + @RuleName = "Issue ImmutableID for computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + store = "Active Directory", + types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), + query = ";objectguid;{0}", + param = c2.Value + ); #### Helper script to create the AD FS issuance transform rules The following script helps you with the creation of the issuance transform rules described above. - $multipleVerifiedDomainNames = $false - $immutableIDAlreadyIssuedforUsers = $false - $oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains - - $rule1 = '@RuleName = "Issue account type for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "DJ" - );' - $rule2 = '@RuleName = "Issue object GUID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), - query = ";objectguid;{0}", - param = c2.Value - );' - $rule3 = '@RuleName = "Issue objectSID for domain-joined computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue(claim = c2);' - $rule4 = '' - if ($multipleVerifiedDomainNames -eq $true) { - $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer" - NOT EXISTS( - [ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "DJ" - ] - ) - => add( - Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value = "User" - ); - - @RuleName = "Capture UPN when AccountType is User and issue the IssuerID" - c1:[ - Type == "http://schemas.xmlsoap.org/claims/UPN" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", - Value == "User" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = regexreplace( - c1.Value, - ".+@(?.+)", - "http://${domain}/adfs/services/trust/" - ) - ); - - @RuleName = "Issue issuerID for domain-joined computers" - c:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", - Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/" - );' - } - $rule5 = '' - if ($immutableIDAlreadyIssuedforUsers -eq $true) { - $rule5 = '@RuleName = "Issue ImmutableID for computers" - c1:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", - Value =~ "-515$", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - && - c2:[ - Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", - Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" - ] - => issue( - store = "Active Directory", - types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), - query = ";objectguid;{0}", - param = c2.Value - );' - } - $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules - $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5 - $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules - Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString + $multipleVerifiedDomainNames = $false + $immutableIDAlreadyIssuedforUsers = $false + $oneOfVerifiedDomainNames = 'example.com' # Replace example.com with one of your verified domains + + $rule1 = '@RuleName = "Issue account type for domain-joined computers" + c:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", + Value = "DJ" + );' + + $rule2 = '@RuleName = "Issue object GUID for domain-joined computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + store = "Active Directory", + types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), + query = ";objectguid;{0}", + param = c2.Value + );' + + $rule3 = '@RuleName = "Issue objectSID for domain-joined computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue(claim = c2);' + + $rule4 = '' + if ($multipleVerifiedDomainNames -eq $true) { + $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer" + NOT EXISTS( + [ + Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", + Value == "DJ" + ] + ) + => add( + Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", + Value = "User" + ); + + @RuleName = "Capture UPN when AccountType is User and issue the IssuerID" + c1:[ + Type == "http://schemas.xmlsoap.org/claims/UPN" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", + Value == "User" + ] + => issue( + Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", + Value = regexreplace( + c1.Value, + ".+@(?.+)", + "http://${domain}/adfs/services/trust/" + ) + ); + + @RuleName = "Issue issuerID for domain-joined computers" + c:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", + Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/" + );' + } + + $rule5 = '' + if ($immutableIDAlreadyIssuedforUsers -eq $true) { + $rule5 = '@RuleName = "Issue ImmutableID for computers" + c1:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", + Value =~ "-515$", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + && + c2:[ + Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", + Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$" + ] + => issue( + store = "Active Directory", + types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), + query = ";objectguid;{0}", + param = c2.Value + );' + } + + $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules + + $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5 + + $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules + + Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString + #### Remarks @@ -478,8 +487,8 @@ The following script helps you with the creation of the issuance transform rules - If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here is an example for this rule: - c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] - => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?.+)", "http://${domain}/adfs/services/trust/")); + c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] + => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?.+)", "http://${domain}/adfs/services/trust/")); - If you have already issued an **ImmutableID** claim for user accounts, set the value of **$immutableIDAlreadyIssuedforUsers** in the script to **$true**. @@ -507,8 +516,7 @@ For your reference, below is a comprehensive list of the AD DS devices, containe >[!div class="nextstepaction"] [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md) -

- +
## Follow the Windows Hello for Business hybrid certificate trust deployment guide diff --git a/windows/security/threat-protection/windows-defender-antivirus/configure-network-connections-windows-defender-antivirus.md b/windows/security/threat-protection/windows-defender-antivirus/configure-network-connections-windows-defender-antivirus.md index ea7fd2385e..72ecea3686 100644 --- a/windows/security/threat-protection/windows-defender-antivirus/configure-network-connections-windows-defender-antivirus.md +++ b/windows/security/threat-protection/windows-defender-antivirus/configure-network-connections-windows-defender-antivirus.md @@ -46,108 +46,18 @@ See [Enable cloud-delivered protection](enable-cloud-protection-windows-defender After you've enabled the service, you may need to configure your network or firewall to allow connections between it and your endpoints. -The following table lists the services and their associated URLs that your network must be able to connect to. You should ensure there are no firewall or network filtering rules that would deny access to these URLs, or you may need to create an **allow** rule specifically for them: +As a cloud service, it is required that computers have access to the internet and that the ATP machine learning services are reachable. The following table lists the services and their associated URLs. You should ensure there are no firewall or network filtering rules that would deny access to these URLs, or you may need to create an allow rule specifically for them: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ServiceDescriptionURL
- Windows Defender Antivirus cloud-delivered protection service, also referred to as Microsoft Active Protection Service (MAPS) - - Used by Windows Defender Antivirus to provide cloud-delivered protection - -*.wdcp.microsoft.com
-*.wdcpalt.microsoft.com
-*.wd.microsoft.com -
-Microsoft Update Service (MU) - -Security intelligence and product updates - -*.update.microsoft.com -
- Security intelligence updates alternate download location (ADL) - - Alternate location for Windows Defender Antivirus Security intelligence updates if the installed Security intelligence falls out of date (7 or more days behind) - -*.download.microsoft.com -
- Malware submission storage - - Upload location for files submitted to Microsoft via the Submission form or automatic sample submission - -ussus1eastprod.blob.core.windows.net
-ussus1westprod.blob.core.windows.net
-usseu1northprod.blob.core.windows.net
-usseu1westprod.blob.core.windows.net
-ussuk1southprod.blob.core.windows.net
-ussuk1westprod.blob.core.windows.net
-ussas1eastprod.blob.core.windows.net
-ussas1southeastprod.blob.core.windows.net
-ussau1eastprod.blob.core.windows.net
-ussau1southeastprod.blob.core.windows.net
-
-Certificate Revocation List (CRL) - -Used by Windows when creating the SSL connection to MAPS for updating the CRL - -http://www.microsoft.com/pkiops/crl/
-http://www.microsoft.com/pkiops/certs
-http://crl.microsoft.com/pki/crl/products
-http://www.microsoft.com/pki/certs - -
-Symbol Store - -Used by Windows Defender Antivirus to restore certain critical files during remediation flows - -https://msdl.microsoft.com/download/symbols -
-Universal Telemetry Client - -Used by Windows to send client diagnostic data; Windows Defender Antivirus uses this for product quality monitoring purposes - -This update uses SSL (TCP Port 443) to download manifests and upload diagnostic data to Microsoft that uses the following DNS endpoints:
  • vortex-win.data.microsoft.com
  • settings-win.data.microsoft.com
- +| **Service**| **Description** |**URL** | +| :--: | :-- | :-- | +| *Windows Defender Antivirus cloud-delivered protection service, also referred to as Microsoft Active Protection Service (MAPS)*|Used by Windows Defender Antivirus to provide cloud-delivered protection|*.wdcp.microsoft.com *.wdcpalt.microsoft.com *.wd.microsoft.com| +| *Microsoft Update Service (MU)*| Security intelligence and product updates |*.update.microsoft.com| +| *Security intelligence updates Alternate Download Location (ADL)*| Alternate location for Windows Defender Antivirus Security intelligence updates if the installed Security intelligence is out of date (7 or more days behind)| *.download.microsoft.com| +| *Malware submission storage *|Upload location for files submitted to Microsoft via the Submission form or automatic sample submission |*.blob.core.windows.net| +| *Certificate Revocation List (CRL)* |Used by Windows when creating the SSL connection to MAPS for updating the CRL | http://www.microsoft.com/pkiops/crl/ http://www.microsoft.com/pkiops/certs http://crl.microsoft.com/pki/crl/products http://www.microsoft.com/pki/certs | +| *Symbol Store *|Used by Windows Defender Antivirus to restore certain critical files during remediation flows | https://msdl.microsoft.com/download/symbols | +| *Universal Telemetry Client* | Used by Windows to send client diagnostic data; Windows Defender Antivirus uses this for product quality monitoring purposes | This update uses SSL (TCP Port 443) to download manifests and upload diagnostic data to Microsoft that uses the following DNS endpoints: * vortex-win.data.microsoft.com * settings-win.data.microsoft.com| ## Validate connections between your network and the cloud