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

Improper acronyms review update-05

Browse Source 
The updates here are made for acronym :AAD, Azure AD-joined, AAD-joined as per the task 6027362. Thanks!
This commit is contained in:
Alekhya Jupudi 2022-06-09 13:45:16 +05:30
parent 8f33332a8c
commit 829d8da98c
82 changed files with 186 additions and 186 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
education/windows/change-to-pro-education.md
View File

@ -28,7 +28,7 @@ To take advantage of this offering, make sure you meet the [requirements for cha
## Requirements for changing
Before you change to Windows 10 Pro Education, make sure you meet these requirements:
- Devices must be running Windows 10 Pro, version 1607 or higher.
- Devices must be Azure Active Directory joined, or domain joined with Azure AD Connect. Customers who are federated with Azure AD are also eligible. For more information, see [Review requirements on devices](#review-requirements-on-devices).
- Devices must be Azure Active Directory-joined, or domain joined with Azure AD Connect. Customers who are federated with Azure AD are also eligible. For more information, see [Review requirements on devices](#review-requirements-on-devices).
If you haven't domain joined your devices already, [prepare for deployment of Windows 10 Pro Education licenses](#preparing-for-deployment-of-windows-10-pro-education-licenses).
@ -47,7 +47,7 @@ For schools that want to standardize all their Windows 10 Pro devices to Windows
In this scenario:
- The IT admin of the tenant chooses to turn on the change for all Azure AD joined devices.
- The IT admin of the tenant chooses to turn on the change for all Azure AD-joined devices.
- Any device that joins the Azure AD will change automatically to Windows 10 Pro Education.
- The IT admin has the option to automatically roll back to Windows 10 Pro, if desired. See [Roll back Windows 10 Pro Education to Windows 10 Pro](#roll-back-windows-10-pro-education-to-windows-10-pro).
@ -92,7 +92,7 @@ You can use Windows Configuration Designer to create a provisioning package that
3. In the **Enter a product key** window, enter the MAK key for Windows 10 Pro Education and click **Next**.
## Education customers with Azure AD joined devices
## Education customers with Azure AD-joined devices
Academic institutions can easily move from Windows 10 Pro to Windows 10 Pro Education without using activation keys or reboots. When one of your users enters their Azure AD credentials associated with a Windows 10 Pro Education license, the operating system changes to Windows 10 Pro Education and all the appropriate Windows 10 Pro Education features are unlocked. Previously, only schools or organizations purchasing devices as part of the Shape the Future K-12 program or with a Microsoft Volume Licensing Agreement could deploy Windows 10 Pro Education to their users. Now, if you have an Azure AD for your organization, you can take advantage of the Windows 10 Pro Education features.
@ -145,7 +145,7 @@ Enabling the automatic change also triggers an email message notifying all globa
So what will users experience? How will they change their devices?
### For existing Azure AD joined devices
### For existing Azure AD-joined devices
Existing Azure AD domain joined devices will be changed to Windows 10 Pro Education the next time the user logs in. That's it! No other steps are needed.
### For new devices that are not Azure AD joined
@ -251,7 +251,7 @@ Devices must be running Windows 10 Pro, version 1607 or higher, or domain joined
dsregcmd /status
```
2. Review the output under Device State. If the **AzureAdJoined** status is YES, the device is Azure Active Directory joined.
2. Review the output under Device State. If the **AzureAdJoined** status is YES, the device is Azure Active Directory-joined.
**To determine the version of Windows 10**

2
education/windows/set-up-school-pcs-azure-ad-join.md
View File

@ -59,7 +59,7 @@ The following table describes each setting within **Device Settings**.
| Setting | Description |
|------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Users may join devices to Azure AD | Choose the scope of people in your organization that are allowed to join devices to Azure AD. **All** allows all users and groups within your tenant to join devices. **Selected** prompts you to choose specific users or groups to allow. **None** allows no one in your tenant to join devices to Azure AD. |
| More local administrators on Azure AD joined devices | Only applicable to Azure AD Premium tenants. Grant extra local administrator rights on devices, to selected users. Global administrators and the device owner are granted local administrator rights by default. |
| More local administrators on Azure AD-joined devices | Only applicable to Azure AD Premium tenants. Grant extra local administrator rights on devices, to selected users. Global administrators and the device owner are granted local administrator rights by default. |
| Users may register their devices with Azure AD | Allow all or none of your users to register their devices with Azure AD (Workplace Join). If you're enrolled in Microsoft Intune or Mobile Device Management for Office 365, your devices are required to be registered. In this case, **All** is automatically selected for you. |
| Require Multi-Factor Authentication to join devices | Recommended when adding devices to Azure AD. When set to **Yes**, users that are setting up devices must enter a second method of authentication. |
| Maximum number of devices per user | Set the maximum number of devices a user is allowed to have in Azure AD. If the maximum is exceeded, the user must remove one or more existing devices before more devices are added. |

4
education/windows/set-up-school-pcs-whats-new.md
View File

@ -34,7 +34,7 @@ You can now give devices running Windows 10, version 2004 and later a name that'
### Resumed support for Windows 10, version 1903 and later
The previously mentioned provisioning problem was resolved, so the Set up School PCs app once again supports Windows 10, version 1903 and later. The Windows 10 settings that were removed are now back in the app.
### Device rename made optional for Azure AD joined devices
### Device rename made optional for Azure AD-joined devices
When you set up your Azure AD join devices in the app, you no longer need to rename your devices. You can keep existing device names.
## Week of May 23, 2019
@ -42,7 +42,7 @@ When you set up your Azure AD join devices in the app, you no longer need to ren
### Suspended support for Windows 10, version 1903 and later
Due to a provisioning problem, Set up School PCs has temporarily stopped support for Windows 10, version 1903 and later. All settings in the app that were for Windows 10, version 1903 and later have been removed. When the problem is resolved, support will resume again.
### Mandatory device rename for Azure AD joined devices
### Mandatory device rename for Azure AD-joined devices
If you configure Azure AD Join, you're now required to rename your devices during setup. You can't keep existing device names.
## Week of April 15, 2019

2
windows/client-management/connect-to-remote-aadj-pc.md
View File

@ -66,7 +66,7 @@ Ensure [Remote Credential Guard](/windows/access-protection/remote-credential-gu
- Adding users using policy
Starting in Windows 10, version 2004, you can add users to the Remote Desktop Users using MDM policies as described in [How to manage the local administrators group on Azure AD joined devices](/azure/active-directory/devices/assign-local-admin#manage-administrator-privileges-using-azure-ad-groups-preview).
Starting in Windows 10, version 2004, you can add users to the Remote Desktop Users using MDM policies as described in [How to manage the local administrators group on Azure AD-joined devices](/azure/active-directory/devices/assign-local-admin#manage-administrator-privileges-using-azure-ad-groups-preview).
> [!TIP]
> When you connect to the remote PC, enter your account name in this format: AzureAD\yourloginid@domain.com.

2
windows/client-management/mdm/azure-active-directory-integration-with-mdm.md
View File

@ -359,7 +359,7 @@ With Azure integrated MDM enrollment, there's no discovery phase and the discove
There are two different MDM enrollment types that integrate with Azure AD, and use Azure AD user and device identities. Depending on the enrollment type, the MDM service may need to manage a single user or multiple users.
<a href="" id="multiple-user-management-for-azure-ad-joined-devices"></a>**Multiple user management for Azure AD joined devices**
<a href="" id="multiple-user-management-for-azure-ad-joined-devices"></a>**Multiple user management for Azure AD-joined devices**
In this scenario the MDM enrollment applies to every Azure AD user who signs in to the Azure AD joined device - call this enrollment type a device enrollment or a multi-user enrollment. The management server can determine the user identity, determine what policies are targeted for this user, and send corresponding policies to the device. To allow management server to identify current user that is logged on to the device, the OMA DM client uses the Azure AD user tokens. Each management session contains an extra HTTP header that contains an Azure AD user token. This information is provided in the DM package sent to the management server. However, in some circumstances Azure AD user token isn't sent over to the management server. One such scenario happens immediately after MDM enrollments completes during Azure AD join process. Until Azure AD join process is finished and Azure AD user signs on to the machine, Azure AD user token isn't available to OMA-DM process. Typically, MDM enrollment completes before Azure AD user sign in to machine and the initial management session doesn't contain an Azure AD user token. The management server should check if the token is missing and only send device policies in such case. Another possible reason for a missing Azure AD token in the OMA-DM payload is when a guest user is logged on to the device.
<a href="" id="adding-a-work-account-and-mdm-enrollment-to-a-device"></a>**Adding a work account and MDM enrollment to a device**

4
windows/client-management/mdm/bitlocker-csp.md
View File

@ -1178,7 +1178,7 @@ If you don't configure this policy setting, users can use BitLocker on removable
Allows the admin to disable the warning prompt for other disk encryption on the user machines that are targeted when the RequireDeviceEncryption policy is set to 1.
<!--/Description-->
> [!IMPORTANT]
> Starting in Windows 10, version 1803, the value 0 can only be set for Azure Active Directory joined devices. When RequireDeviceEncryption is set to 1 and AllowWarningForOtherDiskEncryption is set to 0, Windows will attempt to silently enable [BitLocker](/windows/device-security/bitlocker/bitlocker-overview).
> Starting in Windows 10, version 1803, the value 0 can only be set for Azure Active Directory-joined devices. When RequireDeviceEncryption is set to 1 and AllowWarningForOtherDiskEncryption is set to 0, Windows will attempt to silently enable [BitLocker](/windows/device-security/bitlocker/bitlocker-overview).
> [!Warning]
> When you enable BitLocker on a device with third-party encryption, it may render the device unusable and require you to reinstall Windows.
@ -1197,7 +1197,7 @@ Allows the admin to disable the warning prompt for other disk encryption on the
<!--SupportedValues-->
The following list shows the supported values:
- 0 – Disables the warning prompt. Starting in Windows 10, version 1803, the value 0 can only be set for Azure Active Directory joined devices. Windows will attempt to silently enable BitLocker for value 0.
- 0 – Disables the warning prompt. Starting in Windows 10, version 1803, the value 0 can only be set for Azure Active Directory-joined devices. Windows will attempt to silently enable BitLocker for value 0.
- 1 (default) – Warning prompt allowed.
<!--/SupportedValues-->
```xml

12
windows/client-management/mdm/bitlocker-ddf-file.md
View File

@ -646,7 +646,7 @@ The XML below is the current version for this CSP.
1 = This is the default, when the policy is not set. Warning prompt and encryption notification is allowed.
0 = Disables the warning prompt and encryption notification. Starting in Windows 10, next major update,
the value 0 only takes affect on Azure Active Directory joined devices.
the value 0 only takes affect on Azure Active Directory-joined devices.
Windows will attempt to silently enable BitLocker for value 0.
If you want to disable this policy use the following SyncML:
@ -744,15 +744,15 @@ The XML below is the current version for this CSP.
<Get />
<Replace />
</AccessType>
<Description> Allows Admin to configure Numeric Recovery Password Rotation upon use for OS and fixed drives on AAD and Hybrid domain joined devices.
When not configured, Rotation is turned on by default for AAD only and off on Hybrid. The Policy will be effective only when
<Description> Allows Admin to configure Numeric Recovery Password Rotation upon use for OS and fixed drives on Azure Active Directory and Hybrid domain joined devices.
When not configured, Rotation is turned on by default for Azure AD only and off on Hybrid. The Policy will be effective only when
Active Directory back up for recovery password is configured to required.
For OS drive: Turn on "Do not enable Bitlocker until recovery information is stored to AD DS for operating system drives"
For Fixed drives: Turn on "Do not enable Bitlocker until recovery information is stored to AD DS for fixed data drives"
Supported Values: 0 - Numeric Recovery Passwords rotation OFF.
1 - Numeric Recovery Passwords Rotation upon use ON for AAD joined devices. Default value
2 - Numeric Recovery Passwords Rotation upon use ON for both AAD and Hybrid devices
1 - Numeric Recovery Passwords Rotation upon use ON for Azure Active Directory-joined devices. Default value
2 - Numeric Recovery Passwords Rotation upon use ON for both Azure AD and Hybrid devices
If you want to disable this policy use the following SyncML:
@ -783,7 +783,7 @@ The XML below is the current version for this CSP.
</DFType>
<MSFT:SupportedValues low="0" high="2">
<MSFT:SupportedValue value="0" description="Numeric Recovery Passwords Key rotation OFF"/>
<MSFT:SupportedValue value="1" description="Default Value. Numeric Recovery Passwords Key Rotation ON for AAD joined devices."/>
<MSFT:SupportedValue value="1" description="Default Value. Numeric Recovery Passwords Key Rotation ON for AAD-joined devices."/>
<MSFT:SupportedValue value="2" description="Numeric Recovery Passwords Key Rotation ON for both AAD and Hybrid devices"/>
</MSFT:SupportedValues>
</DFProperties>

2
windows/client-management/mdm/clientcertificateinstall-csp.md
View File

@ -377,7 +377,7 @@ The date type format is Null, meaning this node doesn’t contain a value.
The only supported operation is Execute.
<a href="" id="clientcertificateinstall-scep-uniqueid-install-aadkeyidentifierlist"></a>**ClientCertificateInstall/SCEP/*UniqueID*/Install/AADKeyIdentifierList**
Optional. Specify the Azure AD Key Identifier List as a list of semicolon separated values. On Enroll, the values in this list are validated against the Azure AD Key present on the device. If no match is found, enrollment will fail.
Optional. Specify the Azure Active Directory Key Identifier List as a list of semicolon separated values. On Enroll, the values in this list are validated against the Azure AD Key present on the device. If no match is found, enrollment will fail.
Data type is string.

2
windows/client-management/mdm/clientcertificateinstall-ddf-file.md
View File

@ -931,7 +931,7 @@ Supported operation is Exec.</Description>
<Delete />
<Replace />
</AccessType>
<Description>Optional. Specify the AAD Key Identifier List as a semicolon separated values. On Enroll, the values in this list are validated against the AAD Key present on the device. If no match is found, enrollment will fail.</Description>
<Description>Optional. Specify the Azure Active Directory Key Identifier List as a semicolon separated values. On Enroll, the values in this list are validated against the Azure AD Key present on the device. If no match is found, enrollment will fail.</Description>
<DFFormat>
<chr />
</DFFormat>

2
windows/client-management/mdm/disconnecting-from-mdm-unenrollment.md
View File

@ -125,7 +125,7 @@ When the server initiates disconnection, all undergoing sessions for the enrollm
<a href="" id="work-access"></a>
## Unenrollment from Work Access settings page
If the user is enrolled into MDM using an Azure Active Directory (AAD Join or by adding a Microsoft work account), the MDM account will show up under the Work Access page. However, the **Disconnect** button is greyed out and not accessible. Users can remove that MDM account by removing the AAD association to the device.
If the user is enrolled into MDM using an Azure Active Directory (AAD Join or by adding a Microsoft work account), the MDM account will show up under the Work Access page. However, the **Disconnect** button is greyed out and not accessible. Users can remove that MDM account by removing the Azure AD association to the device.
You can only use the Work Access page to unenroll under the following conditions:

4
windows/client-management/mdm/dmclient-csp.md
View File

@ -346,7 +346,7 @@ Value type is bool.
<a href="" id="provider-providerid-forceaadtoken"></a>**Provider/*ProviderID*/ForceAadToken**
The value type is integer/enum.
The value is "1" and it means client should always send AAD device token during check-in/sync.
The value is "1" and it means client should always send Azure Active Directory device token during check-in/sync.
<a href="" id="provider-providerid-poll"></a>**Provider/*ProviderID*/Poll**
Optional. Polling schedules must use the DMClient CSP. The Registry paths previously associated with polling using the Registry CSP are now deprecated.
@ -517,7 +517,7 @@ This node tracks the status of a Recovery request from the InitiateRecovery node
1 - Recovery is in Process.
2 - Recovery has finished successfully.
3 - Recovery has failed to start because TPM is not available.
4 - Recovery has failed to start because AAD keys are not protected by the TPM.
4 - Recovery has failed to start because Azure Active Directory keys are not protected by the TPM.
5 - Recovery has failed to start because the MDM keys are already protected by the TPM.
6 - Recovery has failed to start because the TPM is not ready for attestation.
7 - Recovery has failed because the client cannot authenticate to the server.

2
windows/client-management/mdm/dmclient-ddf-file.md
View File

@ -981,7 +981,7 @@ The XML below is for Windows 10, version 1803.
<Get />
<Replace />
</AccessType>
<Description>Send the device AAD token, if the user one can't be returned</Description>
<Description>Send the device Azure Active Directory token, if the user one can't be returned</Description>
<DFFormat>
<bool />
</DFFormat>

4
windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md
View File

@ -127,7 +127,7 @@ Requirements:
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. The default behavior for older releases is to revert to **User Credential**.
> **Device Credential** is only supported for Microsoft Intune enrollment in scenarios with Co-management or Azure Virtual Desktop because the Intune subscription is user centric.
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called "Schedule created by enrollment client for automatically enrolling in MDM from AAD."
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called "Schedule created by enrollment client for automatically enrolling in MDM from Azure Active Directory."
To see the scheduled task, launch the [Task Scheduler app](#task-scheduler-app).
@ -270,7 +270,7 @@ To collect Event Viewer logs:
> This task isn't visible to standard users, run Scheduled Tasks with administrative credentials to find the task.
This task runs every 5 minutes for the duration of one day. To confirm if the task succeeded, check the task scheduler event logs:
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**. Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from AAD is triggered by event ID 107.
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**. Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from Azure Active Directory is triggered by event ID 107.
:::image type="content" alt-text="Event ID 107." source="images/auto-enrollment-event-id-107.png" lightbox="images/auto-enrollment-event-id-107.png":::

4
windows/client-management/mdm/healthattestation-csp.md
View File

@ -139,7 +139,7 @@ Data fields:
- rpID (Relying Party Identifier): This field contains an identifier that can be used to help determine the caller.
- serviceEndpoint : This field contains the complete URL of the Microsoft Azure Attestation provider instance to be used for evaluation.
- nonce: This field contains an arbitrary number that can be used only once in a cryptographic communication. It's often a random or pseudo-random number issued in an authentication protocol to ensure that old communications can't be reused in replay attacks.
- aadToken: The AAD token to be used for authentication against the Microsoft Azure Attestation service.
- aadToken: The Azure Active Directory token to be used for authentication against the Microsoft Azure Attestation service.
- cv: This field contains an identifier(Correlation Vector) that will be passed in to the service call, and that can be used for diagnostics purposes.
Sample Data:
@ -408,7 +408,7 @@ calls between client and MAA and for each call the GUID is separated by semicolo
};
```
3. Call TriggerAttestation with your rpid, AAD token and the attestURI: Use the Attestation URL generated in step 1, and append the appropriate api version you want to hit. For more information about the api version, see [Attestation - Attest Tpm - REST API](/rest/api/attestation/attestation/attest-tpm).
3. Call TriggerAttestation with your rpid, Azure Active Directory token and the attestURI: Use the Attestation URL generated in step 1, and append the appropriate api version you want to hit. For more information about the api version, see [Attestation - Attest Tpm - REST API](/rest/api/attestation/attestation/attest-tpm).
4. Call GetAttestReport and decode and parse the report to ensure the attested report contains the required properties: GetAttestReport return the signed attestation token as a JWT. The JWT can be decoded to parse the information per the attestation policy.

4
windows/client-management/mdm/new-in-windows-mdm-enrollment-management.md
View File

@ -250,7 +250,7 @@ Alternatively you can use the following procedure to create an EAP Configuration
After the MDM client automatically renews the WNS channel URI, the MDM client will immediately check-in with the MDM server. Henceforth, for every MDM client check-in, the MDM server should send a GET request for "ProviderID/Push/ChannelURI" to retrieve the latest channel URI and compare it with the existing channel URI; then update the channel URI if necessary.
### User provisioning failure in Azure Active Directory joined Windows 10 and Windows 11 devices
### User provisioning failure in Azure Active Directory-joined Windows 10 and Windows 11 devices
In Azure AD joined Windows 10 and Windows 11, provisioning /.User resources fails when the user isn't logged in as an Azure AD user. If you attempt to join Azure AD from **Settings** &gt; **System** &gt; **About** user interface, ensure to sign out and sign in with Azure AD credentials to get your organizational configuration from your MDM server. This behavior is by design.
@ -270,7 +270,7 @@ The DM agent for [push-button reset](/windows-hardware/manufacture/desktop/push-
No. Only one MDM is allowed.
### How do I set the maximum number of Azure Active Directory joined devices per user?
### How do I set the maximum number of Azure Active Directory-joined devices per user?
1. Sign in to the portal as tenant admin: https://portal.azure.com.
2. Select Active Directory on the left pane.

4
windows/client-management/mdm/policy-csp-admx-terminalserver.md
View File

@ -2305,10 +2305,10 @@ ADMX Info:
<!--Description-->
This policy setting allows you to specify the type of Remote Desktop Services client access license (RDS CAL) that is required to connect to this RD Session Host server.
You can use this policy setting to select one of three licensing modes: Per User, Per Device, and AAD Per User.
You can use this policy setting to select one of three licensing modes: Per User, Per Device, and Azure Active Directory Per User.
- Per User licensing mode requires that each user account connecting to this RD Session Host server have an RDS Per User CAL issued from an RD Licensing server.
- Per Device licensing mode requires that each device connecting to this RD Session Host server have an RDS Per Device CAL issued from an RD Licensing server.
- AAD Per User licensing mode requires that each user account connecting to this RD Session Host server have a service plan that supports RDS licenses assigned in AAD.
- Azure AD Per User licensing mode requires that each user account connecting to this RD Session Host server have a service plan that supports RDS licenses assigned in Azure AD.
If you enable this policy setting, the Remote Desktop licensing mode that you specify is honored by the Remote Desktop license server and RD Session Host.

2
windows/client-management/mdm/policy-csp-authentication.md
View File

@ -312,7 +312,7 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
Specifies the list of domains that are allowed to be navigated to in AAD PIN reset and Web Sign-in Windows device scenarios where authentication is handled by AD FS or a third-party federated identity provider. Note this policy is required in federated environments as a mitigation to the vulnerability described in [CVE-2021-27092](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27092).
Specifies the list of domains that are allowed to be navigated to in Azure Active Directory PIN reset and Web Sign-in Windows device scenarios where authentication is handled by AD FS or a third-party federated identity provider. Note this policy is required in federated environments as a mitigation to the vulnerability described in [CVE-2021-27092](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27092).
**Example**: If your organization's PIN reset or Web Sign-in authentication flow is expected to navigate to two domains, accounts.contoso.com and signin.contoso.com, the policy value should be "accounts.contoso.com;signin.contoso.com".

6
windows/client-management/mdm/policy-csp-deliveryoptimization.md
View File

@ -702,7 +702,7 @@ ADMX Info:
<!--/Scope-->
<!--Description-->
Set this policy to restrict peer selection to a specific source. Available options are: 1 = AD Site, 2 = Authenticated domain SID, 3 = DHCP Option ID, 4 = DNS Suffix, 5 = AAD.
Set this policy to restrict peer selection to a specific source. Available options are: 1 = Active Directory Site, 2 = Authenticated domain SID, 3 = DHCP Option ID, 4 = DNS Suffix, 5 = Azure Active Directory.
When set, the Group ID will be assigned automatically from the selected source.
@ -727,11 +727,11 @@ ADMX Info:
<!--SupportedValues-->
The following list shows the supported values:
- 1 - AD site
- 1 - Active Directory site
- 2 - Authenticated domain SID
- 3 - DHCP user option
- 4 - DNS suffix
- 5 - AAD
- 5 - Azure Active Directory
<!--/SupportedValues-->
<!--/Policy-->

2
windows/client-management/mdm/policy-csp-experience.md
View File

@ -340,7 +340,7 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
Specifies whether to allow the user to delete the workplace account using the workplace control panel. If the device is Azure Active Directory joined and MDM enrolled (for example, auto-enrolled), then disabling the MDM unenrollment has no effect.
Specifies whether to allow the user to delete the workplace account using the workplace control panel. If the device is Azure Active Directory-joined and MDM enrolled (for example, auto-enrolled), then disabling the MDM unenrollment has no effect.
> [!NOTE]
> The MDM server can always remotely delete the account.

2
windows/client-management/mdm/policy-csp-kerberos.md
View File

@ -436,7 +436,7 @@ ADMX Info:
<!--/Scope-->
<!--Description-->
Adds a list of domains that an Azure Active Directory joined device can attempt to contact when it can't resolve a UPN to a principal.
Adds a list of domains that an Azure Active Directory-joined device can attempt to contact when it can't resolve a UPN to a principal.
Devices joined to Azure Active Directory in a hybrid environment need to interact with Active Directory Domain Controllers, but they lack the built-in ability to find a Domain Controller that a domain-joined device has. This limitation can cause failures when such a device needs to resolve an Azure Active Directory UPN into an Active Directory Principal. You can use this policy to avoid those failures.

12
windows/client-management/mdm/policy-csp-localusersandgroups.md
View File

@ -59,7 +59,7 @@ manager: dansimp
This policy setting allows IT admins to add, remove, or replace members of local groups on a managed device.
> [!NOTE]
> The [RestrictedGroups/ConfigureGroupMembership](./policy-csp-restrictedgroups.md#restrictedgroups-configuregroupmembership) policy setting also allows you to configure members (users or AAD groups) to a Windows 10 local group. However, it allows only for a full replace of the existing groups with the new members and does not allow selective add or remove.
> The [RestrictedGroups/ConfigureGroupMembership](./policy-csp-restrictedgroups.md#restrictedgroups-configuregroupmembership) policy setting also allows you to configure members (users or Azure Active Directory groups) to a Windows 10 local group. However, it allows only for a full replace of the existing groups with the new members and does not allow selective add or remove.
>
> Starting from Windows 10, version 20H2, it is recommended to use the LocalUsersandGroups policy instead of the RestrictedGroups policy. Applying both the policies to the same device is unsupported and may yield unpredictable results.
@ -104,9 +104,9 @@ See [Use custom settings for Windows 10 devices in Intune](/mem/intune/configura
**Examples**
Example 1: AAD focused.
Example 1: Azure Active Directory focused.
The following example updates the built-in administrators group with AAD account "bob@contoso.com" and an Azure AD group with the SID **S-1-12-1-111111111-22222222222-3333333333-4444444444** on an AAD-joined machine.
The following example updates the built-in administrators group with Azure AD account "bob@contoso.com" and an Azure AD group with the SID **S-1-12-1-111111111-22222222222-3333333333-4444444444** on an AAD-joined machine.
```xml
<GroupConfiguration>
@ -118,7 +118,7 @@ The following example updates the built-in administrators group with AAD account
</GroupConfiguration>
```
Example 2: Replace / Restrict the built-in administrators group with an AAD user account.
Example 2: Replace / Restrict the built-in administrators group with an Azure AD user account.
> [!NOTE]
> When using ‘R’ replace option to configure the built-in ‘Administrators’ group, it is required to always specify the administrator as a member + any other custom members. This is because the built-in administrator must always be a member of the administrators group.
@ -135,7 +135,7 @@ Example:
```
Example 3: Update action for adding and removing group members on a hybrid joined machine.
The following example shows how you can update a local group (**Administrators**)—add an AD domain group as a member using its name (**Contoso\ITAdmins**), add a AAD group by its SID (**S-1-12-1-111111111-22222222222-3333333333-4444444444**), and remove a local account (**Guest**) if it exists.
The following example shows how you can update a local group (**Administrators**)—add an AD domain group as a member using its name (**Contoso\ITAdmins**), add a Azure Active Directory group by its SID (**S-1-12-1-111111111-22222222222-3333333333-4444444444**), and remove a local account (**Guest**) if it exists.
```xml
<GroupConfiguration>
@ -158,7 +158,7 @@ The following example shows how you can update a local group (**Administrators**
> [!NOTE]
>
> When AAD group SID’s are added to local groups, during AAD account logon privileges are evaluated only for the following well-known groups on a Windows 10 device:
> When Azure Active Directory group SID’s are added to local groups, during Azure AD account logon privileges are evaluated only for the following well-known groups on a Windows 10 device:
>
> - Administrators
> - Users

2
windows/client-management/mdm/policy-csp-mixedreality.md
View File

@ -106,7 +106,7 @@ On a device where this policy is configured, the user specified in the policy wi
> [!NOTE]
>
> - Some events such as major OS updates may require the specified user to logon to the device again to resume auto-logon behavior.
> - Auto-logon is only supported for Microsoft account and AAD users.
> - Auto-logon is only supported for Microsoft account and Azure Active Directory users.
<!--/SupportedSKUs-->
<hr/>

2
windows/client-management/mdm/policy-csp-restrictedgroups.md
View File

@ -15,7 +15,7 @@ manager: dansimp
# Policy CSP - RestrictedGroups
> [!IMPORTANT]
> Starting from Windows 10, version 20H2, it is recommended to use the [LocalUsersandGroups](policy-csp-localusersandgroups.md) policy instead of the RestrictedGroups policy to configure members (users or AAD groups) to a Windows 10 local group. Applying both the policies to the same device is unsupported and may yield unpredictable results.
> Starting from Windows 10, version 20H2, it is recommended to use the [LocalUsersandGroups](policy-csp-localusersandgroups.md) policy instead of the RestrictedGroups policy to configure members (users or Azure Active Directory groups) to a Windows 10 local group. Applying both the policies to the same device is unsupported and may yield unpredictable results.
<hr/>

2
windows/client-management/mdm/policy-csp-search.md
View File

@ -162,7 +162,7 @@ ADMX Info:
<!--/ADMXMapped-->
<!--SupportedValues-->
This value is a simple boolean value, default false, that can be set by MDM policy to allow the Cortana Page in OOBE when logged in with an AAD account.
This value is a simple boolean value, default false, that can be set by MDM policy to allow the Cortana Page in OOBE when logged in with an Azure Active Directory account.
<!--/SupportedValues-->

6
windows/client-management/mdm/policy-csp-system.md
View File

@ -194,7 +194,7 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
This policy setting configures an Azure Active Directory joined device so that Microsoft is the processor of the Windows diagnostic data collected from the device, subject to the [Product Terms](https://www.microsoft.com/licensing/terms/productoffering).
This policy setting configures an Azure Active Directory-joined device so that Microsoft is the processor of the Windows diagnostic data collected from the device, subject to the [Product Terms](https://www.microsoft.com/licensing/terms/productoffering).
To enable this behavior, you must complete two steps:
@ -534,7 +534,7 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
This policy setting configures an Azure Active Directory joined device so that Microsoft is the processor of the Windows diagnostic data.
This policy setting configures an Azure Active Directory-joined device so that Microsoft is the processor of the Windows diagnostic data.
For customers who enroll into the Microsoft Managed Desktop service, this policy will be enabled by default to allow Microsoft to process data for operational and analytic needs. For more information, see [Privacy and personal data](/microsoft-365/managed-desktop/service-description/privacy-personal-data).
@ -772,7 +772,7 @@ The following list shows the supported values:
<!--/Scope-->
<!--Description-->
This policy setting configures an Azure Active Directory joined device so that Microsoft is the processor of the Windows diagnostic data collected from the device, subject to the [Product Terms](https://www.microsoft.com/licensing/terms/productoffering).
This policy setting configures an Azure Active Directory-joined device so that Microsoft is the processor of the Windows diagnostic data collected from the device, subject to the [Product Terms](https://www.microsoft.com/licensing/terms/productoffering).
To enable this behavior, you must complete three steps:

2
windows/client-management/mdm/secureassessment-csp.md
View File

@ -48,7 +48,7 @@ The supported operations are Add, Delete, Get, and Replace.
The user name of the test taking account.
- To specify a domain account, use domain\\user.
- To specify an AAD account, use username@tenant.com.
- To specify an Azure Active Directory account, use username@tenant.com.
- To specify a local account, use the username.
The supported operations are Add, Delete, Get, and Replace.

2
windows/client-management/mdm/secureassessment-ddf-file.md
View File

@ -84,7 +84,7 @@ The XML below is the current version for this CSP.
<Delete />
<Replace />
</AccessType>
<Description>The user name of the test taking account. To specify a domain account, use domain\user. To specify an AAD account, use username@tenant.com. To specify a local account, use the username.</Description>
<Description>The user name of the test taking account. To specify a domain account, use domain\user. To specify an Azure Active Directory account, use username@tenant.com. To specify a local account, use the username.</Description>
<DFFormat>
<chr />
</DFFormat>

4
windows/client-management/mdm/vpnv2-csp.md
View File

@ -659,10 +659,10 @@ Reserved for future use.
Reserved for future use.
<a href="" id="vpnv2-profilename-devicecompliance"></a>**VPNv2/**<em>ProfileName</em>**/DeviceCompliance**
Added in Windows 10, version 1607. Nodes under DeviceCompliance can be used to enable AAD-based Conditional Access for VPN.
Added in Windows 10, version 1607. Nodes under DeviceCompliance can be used to enable Azure Active Directory-based Conditional Access for VPN.
<a href="" id="vpnv2-profilename-devicecompliance-enabled"></a>**VPNv2/**<em>ProfileName</em>**/DeviceCompliance/Enabled**
Added in Windows 10, version 1607. Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with AAD to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory.
Added in Windows 10, version 1607. Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with Azure Active Directory to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory.
Value type is bool. Supported operations include Get, Add, Replace, and Delete.

8
windows/client-management/mdm/vpnv2-ddf-file.md
View File

@ -1403,7 +1403,7 @@ The XML below is for Windows 10, version 2004.
<Add />
<Get />
</AccessType>
<Description>Nodes under DeviceCompliance can be used to enable AAD based Conditional Access for VPN</Description>
<Description>Nodes under DeviceCompliance can be used to enable Azure Active Directory based Conditional Access for VPN</Description>
<DFFormat>
<node />
</DFFormat>
@ -1426,7 +1426,7 @@ The XML below is for Windows 10, version 2004.
<Get />
<Replace />
</AccessType>
<Description>Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with AAD to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory</Description>
<Description>Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with Azure Active Directory to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory</Description>
<DFFormat>
<bool />
</DFFormat>
@ -3593,7 +3593,7 @@ The XML below is for Windows 10, version 2004.
<Add />
<Get />
</AccessType>
<Description>Nodes under DeviceCompliance can be used to enable AAD based Conditional Access for VPN</Description>
<Description>Nodes under DeviceCompliance can be used to enable Azure Active Directory based Conditional Access for VPN</Description>
<DFFormat>
<node />
</DFFormat>
@ -3616,7 +3616,7 @@ The XML below is for Windows 10, version 2004.
<Get />
<Replace />
</AccessType>
<Description>Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with AAD to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory</Description>
<Description>Enables the Device Compliance flow from the client. If marked as True, the VPN Client will attempt to communicate with Azure Active Directory to get a certificate to use for authentication. The VPN should be set up to use Certificate Auth and the VPN Server must trust the Server returned by Azure Active Directory</Description>
<DFFormat>
<bool />
</DFFormat>

4
windows/client-management/new-policies-for-windows-10.md
View File

@ -270,7 +270,7 @@ The following Group Policy settings were added in Windows 10, version 1803:
- Windows Components\IME\Turn on Live Sticker
- Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection\Do not allow video capture redirection
- Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Use hardware graphics adapters for all Remote Desktop Services sessions
- Windows Components\Search\Allow Cortana Page in OOBE on an AAD account
- Windows Components\Search\Allow Cortana Page in OOBE on an Azure Active Directory account
- Windows Components\Store\Disable all apps from Microsoft Store
- Windows Components\Text Input\Allow Uninstallation of Language Features
- Windows Components\Text Input\Improve inking and typing recognition
@ -311,7 +311,7 @@ The following Group Policy settings were added in Windows 10, version 1709:
- Windows Components\Data Collection and Preview Builds\Limit Enhanced diagnostic data to the minimum required by Windows Analytics
- Windows Components\Handwriting\Handwriting Panel Default Mode Docked
- Windows Components\Internet Explorer\Internet Settings\Advanced settings\Browsing\Hide the button (next to the New Tab button) that opens Microsoft Edge
- Windows Components\MDM\Auto MDM Enrollment with AAD Token
- Windows Components\MDM\Auto MDM Enrollment with Azure Active Directory Token
- Windows Components\Messaging\Allow Message Service Cloud Sync
- Windows Components\Microsoft Edge\Always show the Books Library in Microsoft Edge
- Windows Components\Microsoft Edge\Provision Favorites

2
windows/configuration/cortana-at-work/set-up-and-test-cortana-in-windows-10.md
View File

@ -44,4 +44,4 @@ When a user enters a search query (by speech or text), Cortana evaluates if the
Bing Answers is enabled by default for all users. However, admins can configure and change this for specific users and user groups in their organization.
## How the Bing Answer policy configuration is applied
Before a query is sent to Bing for a search of public results from Bing.com, the Bing Answers service checks with the Office Cloud Policy Service to see if there are any policy configurations that pertain to the user for allowing Bing Answers to respond to questions users ask Cortana. If the user is a member of an AAD group that is assigned that policy configuration, then the appropriate policy settings are applied and a check is made again in 10 minutes.
Before a query is sent to Bing for a search of public results from Bing.com, the Bing Answers service checks with the Office Cloud Policy Service to see if there are any policy configurations that pertain to the user for allowing Bing Answers to respond to questions users ask Cortana. If the user is a member of an Azure Active Directory group that is assigned that policy configuration, then the appropriate policy settings are applied and a check is made again in 10 minutes.

8
windows/deployment/deploy-enterprise-licenses.md
View File

@ -89,7 +89,7 @@ For more information about integrating on-premises AD DS domains with Azure AD,
## Preparing for deployment: reviewing requirements
Devices must be running Windows 10 Pro, version 1703, or later and be Azure Active Directory joined, or hybrid domain joined with Azure AD Connect. Customers who are federated with Azure Active Directory are also eligible. For more information, see [Review requirements on devices](#review-requirements-on-devices), later in this topic.
Devices must be running Windows 10 Pro, version 1703, or later and be Azure Active Directory-joined, or hybrid domain joined with Azure AD Connect. Customers who are federated with Azure Active Directory are also eligible. For more information, see [Review requirements on devices](#review-requirements-on-devices), later in this topic.
## Assigning licenses to users
@ -241,12 +241,12 @@ Use the following figures to help you troubleshoot when users experience these c
### Review requirements on devices
Devices must be running Windows 10 Pro, version 1703 (or later), and be Azure Active Directory joined, or hybrid domain joined with Azure AD Connect. Customers who are federated with Azure Active Directory are also eligible. You can use the following procedures to review whether a particular device meets requirements.
Devices must be running Windows 10 Pro, version 1703 (or later), and be Azure Active Directory-joined, or hybrid domain joined with Azure AD Connect. Customers who are federated with Azure Active Directory are also eligible. You can use the following procedures to review whether a particular device meets requirements.
**To determine if a device is Azure Active Directory joined:**
**To determine if a device is Azure Active Directory-joined:**
1. Open a command prompt and type **dsregcmd /status**.
2. Review the output under Device State. If the **AzureAdJoined** status is YES, the device is Azure Active Directory joined.
2. Review the output under Device State. If the **AzureAdJoined** status is YES, the device is Azure Active Directory-joined.
**To determine the version of Windows 10:**

2
windows/deployment/do/waas-delivery-optimization-reference.md
View File

@ -124,7 +124,7 @@ Download mode dictates which download sources clients are allowed to use when do
> Starting in Windows 11, the Bypass option of Download Mode is no longer used.
>
> [!NOTE]
> When you use AAD tenant, AD Site, or AD Domain as the source of group IDs, the association of devices participating in the group should not be relied on for an authentication of identity of those devices.
> When you use Azure Active Directory tenant, AD Site, or AD Domain as the source of group IDs, the association of devices participating in the group should not be relied on for an authentication of identity of those devices.
### Group ID

2
windows/deployment/update/WIP4Biz-intro.md
View File

@ -48,7 +48,7 @@ Windows 10 Insider Preview builds offer organizations a valuable and exciting op
|Release channel |**Fast Ring:** Insider Preview builds in the Fast Ring are released approximately once a week and contain the very latest features. This makes them ideal for feature exploration.|
|Users | Because Fast Ring builds are released so early in the development cycle, we recommend limiting feature exploration in your organization to IT administrators and developers running Insider Preview builds on secondary devices. |
|Tasks | - Install and manage Insider Preview builds on devices (per device or centrally across multiple devices)<br> - Explore new features in Windows designed for organizations, including new features related to current and planned line of business applications<br> - Before running an Insider Preview build, check our [Windows Insider blog](https://blogs.windows.com/windowsexperience/tag/windows-insider-program/#k3WWwxKCTWHCO82H.97) for a summary of current features. |
|Feedback | - This helps us make adjustments to features as quickly as possible.<br> - Encourage users to sign into the Feedback Hub using their AAD work accounts. This enables both you and Microsoft to track feedback submitted by users within your specific organization. (Note: This tracking is only visible to Microsoft and registered Insiders within your organization’s domain.)<br> - [Learn how to provide effective feedback in the Feedback Hub](https://insider.windows.com/how-to-feedback/) |
|Feedback | - This helps us make adjustments to features as quickly as possible.<br> - Encourage users to sign into the Feedback Hub using their Azure Active Directory work accounts. This enables both you and Microsoft to track feedback submitted by users within your specific organization. (Note: This tracking is only visible to Microsoft and registered Insiders within your organization’s domain.)<br> - [Learn how to provide effective feedback in the Feedback Hub](https://insider.windows.com/how-to-feedback/) |
## Validate Insider Preview builds
Along with exploring new features, you also have the option to validate your apps and infrastructure on Insider Preview builds. Early validation has several benefits:

4
windows/deployment/update/olympia/olympia-enrollment-guidelines.md
View File

@ -47,7 +47,7 @@ As part of Windows Insider Lab for Enterprise, you can upgrade to Windows client
Choose one of the following two enrollment options:
- To set up an AAD-registered device, [follow these steps](#enrollment-keep-current-edition). In this case, you log onto the device by using an existing (non-Olympia) account.
- To set up an Azure Active Directory-registered device, [follow these steps](#enrollment-keep-current-edition). In this case, you log onto the device by using an existing (non-Olympia) account.
- If you are running Windows client Pro, we recommend that you upgrade to Windows client Enterprise by following these steps to [set up an Azure Active Directory-joined device](#enrollment-upgrade-to-enterprise). In this case, you will be able to log on to the device with your Olympia account.
@ -91,7 +91,7 @@ This is the Bring Your Own Device (BYOD) method--your device will receive Olympi
### Set up Azure Active Directory-JOINED Windows client device
- This method will upgrade your Windows client Pro license to Enterprise and create a new account. See [Set up Azure Active Directory joined devices](/azure/active-directory/device-management-azuread-joined-devices-setup) for more information.
- This method will upgrade your Windows client Pro license to Enterprise and create a new account. See [Set up Azure Active Directory-joined devices](/azure/active-directory/device-management-azuread-joined-devices-setup) for more information.
> [!NOTE]
> Make sure that you save your Pro license key before upgrading to the Enterprise edition. If the device gets disconnected from Olympia, you can use the Pro key to reactivate the license manually in the unlikely event that the license fails to downgrade back to Pro automatically. To reactivate manually, see [Upgrade by manually entering a product key](../../upgrade/windows-10-edition-upgrades.md#upgrade-by-manually-entering-a-product-key).

4
windows/deployment/update/update-compliance-v2-overview.md
View File

@ -21,7 +21,7 @@ ms.date: 06/06/2022
> [!Important]
> This information relates to a preview feature that's available for early testing and use in a production environment. This feature is fully supported but it's still in active development and may receive substantial changes until it becomes generally available.
Update Compliance is a cloud-based solution that provides information about the compliance of your Azure Active Directory joined devices with Windows updates. Update Compliance is offered through the [Azure portal](https://portal.azure.com), and it's included as part of the Windows 10 or Windows 11 prerequisite licenses. Update Compliance helps you:
Update Compliance is a cloud-based solution that provides information about the compliance of your Azure Active Directory-joined devices with Windows updates. Update Compliance is offered through the [Azure portal](https://portal.azure.com), and it's included as part of the Windows 10 or Windows 11 prerequisite licenses. Update Compliance helps you:
- Monitor security, quality, and feature updates for Windows 11 and Windows 10 devices
- Report on devices with update compliance issues
@ -53,7 +53,7 @@ Currently, the technical preview contains the following features:
## How Update Compliance works
You'll set up Update Compliance by enrolling into the solution from the Azure portal. Then you'll configure your Azure AD joined devices to send Windows client diagnostic data to the solution. Update Compliance uses [Log Analytics in Azure Monitor](/azure/azure-monitor/logs/log-analytics-overview) to store the diagnostic data the clients send. You can use this data for reporting on updates for your devices. Update Compliance collects system data such as:
You'll set up Update Compliance by enrolling into the solution from the Azure portal. Then you'll configure your Azure AD-joined devices to send Windows client diagnostic data to the solution. Update Compliance uses [Log Analytics in Azure Monitor](/azure/azure-monitor/logs/log-analytics-overview) to store the diagnostic data the clients send. You can use this data for reporting on updates for your devices. Update Compliance collects system data such as:
- Update deployment progress
- Delivery Optimization usage data

4
windows/deployment/update/update-compliance-v2-prerequisites.md
View File

@ -30,8 +30,8 @@ Before you begin the process of adding Update Compliance to your Azure subscript
- An Azure subscription with [Azure Active Directory](/azure/active-directory/)
- You must have either an Owner or Contributor [Azure role](/azure/role-based-access-control/rbac-and-directory-admin-roles#azure-roles) as a minimum in order to add the Update Compliance solution.
- Devices must be Azure Active Directory joined and meet the below OS, diagnostic, and endpoint access requirements
- Devices that are Workplace joined only (Azure AD registered) aren't supported with Update Compliance
- Devices must be Azure Active Directory-joined and meet the below OS, diagnostic, and endpoint access requirements.
- Devices that are Workplace joined only (Azure AD registered) aren't supported with Update Compliance.
### Operating systems and editions

4
windows/deployment/vda-subscription-activation.md
View File

@ -45,7 +45,7 @@ Deployment instructions are provided for the following scenarios:
- The VM is running Windows 10, version 1803 or later (ex: Windows 11).
- The VM is hosted in Azure or another Qualified Multitenant Hoster (QMTH).
When a user with VDA rights signs in to the VM using their AAD credentials, the VM is automatically stepped-up to Enterprise and activated. There is no need to perform Windows 10/11 Pro activation. This eliminates the need to maintain KMS or MAK in the qualifying cloud infrastructure.
When a user with VDA rights signs in to the VM using their Azure Active Directory credentials, the VM is automatically stepped-up to Enterprise and activated. There is no need to perform Windows 10/11 Pro activation. This eliminates the need to maintain KMS or MAK in the qualifying cloud infrastructure.
### Scenario 2
@ -101,7 +101,7 @@ For examples of activation issues, see [Troubleshoot the user experience](./depl
>Azure Active Directory (Azure AD) provisioning packages have a 180 day limit on bulk token usage. You will need to update the provisioning package and re-inject it into the image after 180 days. Existing virtual machines that are Azure AD-joined and deployed will not need to be recreated.
For Azure AD-joined VMs, follow the same instructions (above) as for [Active Directory-joined VMs](#active-directory-joined-vms) with the following exceptions:
- In step 9, during setup with Windows Configuration Designer, under **Name**, type a name for the project that indicates it is not for Active Directory joined VMs, such as **Desktop Bulk Enrollment Token Pro GVLK**.
- In step 9, during setup with Windows Configuration Designer, under **Name**, type a name for the project that indicates it is not for Active Directory-joined VMs, such as **Desktop Bulk Enrollment Token Pro GVLK**.
- In step 11, during setup with Windows Configuration Designer, on the Account Management page, instead of enrolling in Active Directory, choose **Enroll in Azure AD**, click **Get Bulk Token**, sign in and add the bulk token using your organization's credentials.
- In step 15, sub-step 2, when entering the PackagePath, use the project name you entered in step 9 (ex: **Desktop Bulk Enrollment Token Pro GVLK.ppkg**)
- When attempting to access the VM using remote desktop, you will need to create a custom RDP settings file as described below in [Create custom RDP settings for Azure](#create-custom-rdp-settings-for-azure).

2
windows/deployment/windows-10-deployment-scenarios.md
View File

@ -49,7 +49,7 @@ The following tables summarize various Windows 10 deployment scenarios. The scen
|Scenario|Description|More information|
|--- |--- |--- |
|[Subscription Activation](#windows-10-subscription-activation)|Switch from Windows 10 Pro to Enterprise when a subscribed user signs in.|[Windows 10 Subscription Activation](/windows/deployment/windows-10-enterprise-subscription-activation)|
|[AAD / MDM](#dynamic-provisioning)|The device is automatically joined to AAD and configured by MDM.|[Azure Active Directory integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm)|
|[AAD / MDM](#dynamic-provisioning)|The device is automatically joined to Azure Active Directory and configured by MDM.|[Azure Active Directory integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm)|
|[Provisioning packages](#dynamic-provisioning)|Using the Windows Imaging and Configuration Designer tool, create provisioning packages that can be applied to devices.|[Configure devices without MDM](/windows/configuration/configure-devices-without-mdm)|
### Traditional

4
windows/deployment/windows-10-subscription-activation.md
View File

@ -109,7 +109,7 @@ If devices are running Windows 7 or Windows 8.1, see [New Windows 10 upgrade ben
#### Multifactor authentication
An issue has been identified with Hybrid Azure AD joined devices that have enabled [multifactor authentication](/azure/active-directory/authentication/howto-mfa-getstarted) (MFA). If a user signs into a device using their Active Directory account and MFA is enabled, the device will not successfully upgrade to their Windows Enterprise subscription.
An issue has been identified with Hybrid Azure AD-joined devices that have enabled [multifactor authentication](/azure/active-directory/authentication/howto-mfa-getstarted) (MFA). If a user signs into a device using their Active Directory account and MFA is enabled, the device will not successfully upgrade to their Windows Enterprise subscription.
To resolve this issue:
@ -162,7 +162,7 @@ You can benefit by moving to Windows as an online service in the following ways:
> [!NOTE]
> The following Windows 10 examples and scenarios also apply to Windows 11.
The device is AAD joined from **Settings > Accounts > Access work or school**.
The device is Azure Active Directory-joined from **Settings > Accounts > Access work or school**.
The IT administrator assigns Windows 10 Enterprise to a user. See the following figure.

2
windows/privacy/basic-level-windows-diagnostic-events-and-fields-1709.md
View File

@ -3732,7 +3732,7 @@ Activity for deletion of a user account for devices set up for Shared PC mode as
The following fields are available:
- **accountType** The type of account that was deleted. Example: AD, AAD, or Local
- **accountType** The type of account that was deleted. Example: AD, Azure Active Directory (AAD), or Local
- **deleteState** Whether the attempted deletion of the user account was successful.
- **userSid** The security identifier of the account.
- **wilActivity** Windows Error Reporting data collected when there is a failure in deleting a user account with the Transient Account Manager. See [wilActivity](#wilactivity).

2
windows/privacy/basic-level-windows-diagnostic-events-and-fields-1803.md
View File

@ -4989,7 +4989,7 @@ Activity for deletion of a user account for devices set up for Shared PC mode as
The following fields are available:
- **accountType** The type of account that was deleted. Example: AD, AAD, or Local
- **accountType** The type of account that was deleted. Example: AD, Azure Active Directory (AAD), or Local.
- **deleteState** Whether the attempted deletion of the user account was successful.
- **userSid** The security identifier of the account.
- **wilActivity** Windows Error Reporting data collected when there is a failure in deleting a user account with the Transient Account Manager. See [wilActivity](#wilactivity).

4
windows/privacy/basic-level-windows-diagnostic-events-and-fields-1809.md
View File

@ -9567,7 +9567,7 @@ The following fields are available:
- **CV** The correlation vector.
- **GlobalEventCounter** Counts the events at the global level for telemetry.
- **PackageVersion** The package version for currency tools.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is AAD joined.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is Azure Active Directoryjoined.
- **UnifiedInstallerDeviceInDssPolicy** Boolean indicating whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceInDssPolicyHresult** The result code for checking whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceIsAADJoined** Boolean indicating whether a device is AADJ.
@ -9652,7 +9652,7 @@ The following fields are available:
### Microsoft.Windows.UpdateHealthTools.UpdateHealthToolsServiceBlockedByNoDSSJoin
This event is sent when the device is not joined to AAD. The data collected with this event is used to help keep Windows up to date and secure.
This event is sent when the device is not joined to Azure Active Directory. The data collected with this event is used to help keep Windows up to date and secure.
The following fields are available:

6
windows/privacy/basic-level-windows-diagnostic-events-and-fields-1903.md
View File

@ -6239,7 +6239,7 @@ The following fields are available:
- **CV** The correlation vector.
- **GlobalEventCounter** Counts the events at the global level for telemetry.
- **PackageVersion** The package version for currency tools.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is AAD joined.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is Azure Active Directory-joined.
- **UnifiedInstallerDeviceInDssPolicy** Boolean indicating whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceInDssPolicyHresult** The result code for checking whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceIsAADJoined** Boolean indicating whether a device is AADJ.
@ -6358,7 +6358,7 @@ The following fields are available:
- **PackageVersion** The package version of the label.
- **UpdateHealthToolsDevicePolicyFileName** The default name of the policy blob file.
- **UpdateHealthToolsDssDeviceApiSegment** The URI segment for reading the DSS device pointer.
- **UpdateHealthToolsDssDeviceId** The AAD ID of the device used to create the device ID hash.
- **UpdateHealthToolsDssDeviceId** The Azure Active Directory ID of the device used to create the device ID hash.
- **UpdateHealthToolsDssDevicePolicyApiSegment** The segment of the device policy API pointer.
- **UpdateHealthToolsDssTenantId** The tenant id of the device used to create the tenant id hash.
- **UpdateHealthToolsHashedDeviceId** The SHA256 hash of the device id.
@ -6367,7 +6367,7 @@ The following fields are available:
### Microsoft.Windows.UpdateHealthTools.UpdateHealthToolsServiceBlockedByNoDSSJoin
The event is sent when the device is not joined to AAD. The data collected with this event is used to help keep Windows up to date and secure.
The event is sent when the device is not joined to Azure Active Directory. The data collected with this event is used to help keep Windows up to date and secure.
The following fields are available:

2
windows/privacy/changes-to-windows-diagnostic-data-collection.md
View File

@ -81,7 +81,7 @@ The following provides information on the current configurations:
## New Windows diagnostic data processor configuration
Enterprise customers have an option for controlling their Windows diagnostic data for their Azure Active Directory joined devices. This configuration option is supported on the following versions of Windows:
Enterprise customers have an option for controlling their Windows diagnostic data for their Azure Active Directory-joined devices. This configuration option is supported on the following versions of Windows:
- Windows 11 Enterprise, Professional, and Education
- Windows 10, Enterprise, Professional, and Education, version 1809 with at least the July 2021 update.

6
windows/privacy/required-windows-diagnostic-data-events-and-fields-2004.md
View File

@ -5771,7 +5771,7 @@ The following fields are available:
- **CV** The correlation vector.
- **GlobalEventCounter** Counts the events at the global level for telemetry.
- **PackageVersion** The package version for currency tools.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is AAD joined.
- **UnifiedInstallerDeviceAADJoinedHresult** The result code after checking if device is Azure Active Directory-joined.
- **UnifiedInstallerDeviceInDssPolicy** Boolean indicating whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceInDssPolicyHresult** The result code for checking whether the device is found to be in a DSS policy.
- **UnifiedInstallerDeviceIsAADJoined** Boolean indicating whether a device is AADJ.
@ -5901,7 +5901,7 @@ The following fields are available:
- **PackageVersion** The package version of the label.
- **UpdateHealthToolsDevicePolicyFileName** The default name of the policy blob file.
- **UpdateHealthToolsDssDeviceApiSegment** The URI segment for reading the DSS device pointer.
- **UpdateHealthToolsDssDeviceId** The AAD ID of the device used to create the device ID hash.
- **UpdateHealthToolsDssDeviceId** The Azure Active Directory ID of the device used to create the device ID hash.
- **UpdateHealthToolsDssDevicePolicyApiSegment** The segment of the device policy API pointer.
- **UpdateHealthToolsDssTenantId** The tenant id of the device used to create the tenant id hash.
- **UpdateHealthToolsHashedDeviceId** The SHA256 hash of the device id.
@ -5910,7 +5910,7 @@ The following fields are available:
### Microsoft.Windows.UpdateHealthTools.UpdateHealthToolsServiceBlockedByNoDSSJoin
This event is sent when the device is not joined to AAD. The data collected with this event is used to help keep Windows up to date and secure.
This event is sent when the device is not joined to Azure Active Directory. The data collected with this event is used to help keep Windows up to date and secure.
The following fields are available:

4
windows/privacy/windows-10-and-privacy-compliance.md
View File

@ -156,9 +156,9 @@ An administrator can disable a user’s ability to delete their device’s diagn
- Windows 11 Enterprise, Professional, and Education editions
- Windows 10 Enterprise, Professional, and Education, version 1809 with July 2021 update and newer
The Windows diagnostic data processor configuration enables IT administrators to be the controller, as defined by the European Union General Data Protection Regulation (GDPR), for the Windows diagnostic data collected from Windows devices that are Azure Active Directory (AAD) joined and meet the configuration requirements. For more information, see [Enable Windows diagnostic data processor configuration](configure-windows-diagnostic-data-in-your-organization.md#enable-windows-diagnostic-data-processor-configuration) in [Configure Windows diagnostic data in your organization](configure-windows-diagnostic-data-in-your-organization.md). Windows diagnostic data does not include data processed by Microsoft in connection with providing service-based capabilities.
The Windows diagnostic data processor configuration enables IT administrators to be the controller, as defined by the European Union General Data Protection Regulation (GDPR), for the Windows diagnostic data collected from Windows devices that are Azure Active Directory (AAD)-joined and meet the configuration requirements. For more information, see [Enable Windows diagnostic data processor configuration](configure-windows-diagnostic-data-in-your-organization.md#enable-windows-diagnostic-data-processor-configuration) in [Configure Windows diagnostic data in your organization](configure-windows-diagnostic-data-in-your-organization.md). Windows diagnostic data does not include data processed by Microsoft in connection with providing service-based capabilities.
The Windows diagnostic data collected from devices enabled with the Windows diagnostic data processor configuration may be associated with a specific AAD User ID or device ID. The Windows diagnostic data processor configuration provides you with controls that help respond to data subject requests (DSRs) to delete diagnostic data, at user account closure, for a specific AAD User ID. Additionally, you’re able to execute an export DSR for diagnostic data related to a specific AAD User ID. For more information, see [The process for exercising data subject rights](#3-the-process-for-exercising-data-subject-rights). Microsoft also will accommodate a tenant account closure, either because you decide to close your Azure or Azure AD tenant account, or because you decide you no longer wish to be the data controller for Windows diagnostic data, but still wish to remain an Azure customer.
The Windows diagnostic data collected from devices enabled with the Windows diagnostic data processor configuration may be associated with a specific Azure Active Directory User ID or device ID. The Windows diagnostic data processor configuration provides you with controls that help respond to data subject requests (DSRs) to delete diagnostic data, at user account closure, for a specific Azure AD User ID. Additionally, you’re able to execute an export DSR for diagnostic data related to a specific Azure AD User ID. For more information, see [The process for exercising data subject rights](#3-the-process-for-exercising-data-subject-rights). Microsoft also will accommodate a tenant account closure, either because you decide to close your Azure or Azure AD tenant account, or because you decide you no longer wish to be the data controller for Windows diagnostic data, but still wish to remain an Azure customer.
We recommend that IT administrators who have enabled the Windows diagnostic data processor configuration consider the following:

4
windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
View File

@ -91,9 +91,9 @@ If there's a conflicting Device policy and User policy, the User policy would ta
## Related reference documents for Azure AD join scenarios
- [Azure AD joined devices](/azure/active-directory/devices/concept-azure-ad-join)
- [Azure AD-joined devices](/azure/active-directory/devices/concept-azure-ad-join)
- [Plan your Azure Active Directory device deployment](/azure/active-directory/devices/plan-device-deployment)
- [How to: Plan your Azure AD join implementation](/azure/active-directory/devices/azureadjoin-plan)
- [How to manage the local administrators group on Azure AD joined devices](/azure/active-directory/devices/assign-local-admin)
- [How to manage the local administrators group on Azure AD-joined devices](/azure/active-directory/devices/assign-local-admin)
- [Manage device identities using the Azure portal](/azure/active-directory/devices/device-management-azure-portal)
- [Azure AD Join Single Sign-on Deployment](hello-hybrid-aadj-sso.md)

8
windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
View File

@ -29,7 +29,7 @@ Applies to:
- Windows 10, version 1803 and later
- Windows 11
PIN reset on Azure AD joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will show a page with the error message "We can't open that page right now".
PIN reset on Azure AD-joined devices uses a flow called web sign-in to authenticate the user above lock. Web sign in only allows navigation to specific domains. If it attempts to navigate to a domain that is not allowed it will show a page with the error message "We can't open that page right now".
### Identifying Azure AD joined PIN Reset Allowed Domains Issue
@ -124,7 +124,7 @@ Domain controllers running early versions of Windows Server 2019 have an issue t
On the client, authentication with Windows Hello for Business will fail with the error message, *"That option is temporarily unavailable. For now, please use a different method to sign in."*
This error is usually presented on hybrid Azure AD joined devices in key trust deployments after Windows Hello for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been populated for NGC, then it is possible that this error case is occurring.
This error is usually presented on hybrid Azure AD-joined devices in key trust deployments after Windows Hello for Business has been provisioned but before a user's key has synced from Azure AD to AD. If a user's key has been synced from Azure AD and the msDS-keycredentiallink attribute on the user object in AD has been populated for NGC, then it is possible that this error case is occurring.
The other indicator of this failure case can be identified using network traces. If network traces are captured for a key trust sign-in event, the traces will show kerberos failing with the error KDC_ERR_CLIENT_NAME_MISMATCH.
@ -158,8 +158,8 @@ User: <User SID>
Computer: <Computer name>
Description:
Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes
User has logged on with Azure Active Directory credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes

6
windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
View File

@ -34,7 +34,7 @@ Three approaches are documented here:
1. Deploying a certificate to hybrid joined devices using an on-premises Active Directory certificate enrollment policy.
1. Deploying a certificate to hybrid or Azure AD joined devices using Simple Certificate Enrollment Protocol (SCEP) and Intune.
1. Deploying a certificate to hybrid or Azure AD-joined devices using Simple Certificate Enrollment Protocol (SCEP) and Intune.
1. Working with non-Microsoft enterprise certificate authorities.
@ -191,7 +191,7 @@ Once the configuration profile has been created, targeted clients will receive t
1. In the right-hand pane of the MMC, check for the new certificate
> [!NOTE]
> This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid AAD-Joined devices using Intune Policies.
> This infrastructure may also deploy the same certificates to co-managed or modern-managed Hybrid Azure Active Directory-Joined devices using Intune Policies.
## Using non-Microsoft Enterprise Certificate Authorities
@ -205,6 +205,6 @@ The Generate-CertificateRequest commandlet will generate an .inf file for a pre-
After adding the certificate using an approach from any of the previous sections, you should be able to RDP to any Windows device or server in the same Forest as the user’s on-premises Active Directory account, provided the PKI certificate chain for the issuing certificate authority is deployed to that target server.
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid AAD-Joined client where the authentication certificate has been deployed.
1. Open the Remote Desktop Client (%windir%\system32\mstsc.exe) on the Hybrid Azure Active Directory-Joined client where the authentication certificate has been deployed.
1. Attempt an RDP session to a target server.
1. Use the certificate credential protected by your Windows Hello for Business gesture.

4
windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md
View File

@ -72,7 +72,7 @@ If the error occurs again, check the error code against the following table to s
| 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed. <br><br> -or- <br><br> Token was not found in the Authorization header. <br><br> -or- <br><br> Failed to read one or more objects. <br><br> -or- <br><br> The request sent to the server was invalid. <br><br> -or- <br><br> User does not have permissions to join to Azure AD. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin. <br> Allow user(s) to join to Azure AD under Azure AD Device settings.
| 0x801C03EE | Attestation failed. | Sign out and then sign in again. |
| 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. |
| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in AAD and the Primary SMTP address are the same in the proxy address.
| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Azure Active Directory and the Primary SMTP address are the same in the proxy address.
| 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. |
@ -104,7 +104,7 @@ For errors listed in this table, contact Microsoft Support for assistance.
| 0x801C03F0 | ​There is no key registered for the user. |
| 0x801C03F1 | ​There is no UPN in the token. |
| ​0x801C044C | There is no core window for the current thread. |
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request AAD token for provisioning. Unable to enroll a device to use a PIN for login. |
| 0x801c004D | DSREG_NO_DEFAULT_ACCOUNT: NGC provisioning is unable to find the default WAM account to use to request Azure Active Directory token for provisioning. Unable to enroll a device to use a PIN for login. |
## Related topics

2
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -29,7 +29,7 @@ sections:
- question: What is Windows Hello for Business cloud trust?
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).
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: |

10
windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
View File

@ -39,7 +39,7 @@ There are two forms of PIN reset called destructive and non-destructive. Destruc
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.
>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
@ -49,7 +49,7 @@ Destructive and non-destructive PIN reset use the same entry points for initiati
### Reset PIN above the Lock Screen
For Azure AD joined devices:
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.
@ -57,7 +57,7 @@ For Azure AD joined devices:
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:
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.
@ -66,7 +66,7 @@ For Hybrid Azure AD joined devices:
1. When finished, unlock your desktop using your newly created PIN.
> [!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.
> 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).
@ -193,7 +193,7 @@ The PIN reset configuration for a user can be viewed by running [**dsregcmd /sta
- Windows 11
- Azure AD joined
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to 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.
The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to 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.
### Configuring Policy Using Intune

4
windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
View File

@ -24,7 +24,7 @@ ms.reviewer:
Windows Hello for Business authentication is passwordless, two-factor authentication. Authenticating with Windows Hello for Business provides a convenient sign-in experience that authenticates the user to both Azure Active Directory and Active Directory resources.
Azure Active Directory joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
Azure Active Directory-joined devices authenticate to Azure during sign-in and can optionally authenticate to Active Directory. Hybrid Azure Active Directory-joined devices authenticate to Active Directory during sign-in, and authenticate to Azure Active Directory in the background.
- [Azure AD join authentication to Azure Active Directory](#azure-ad-join-authentication-to-azure-active-directory)
- [Azure AD join authentication to Active Directory using Azure AD Kerberos (cloud trust preview)](#azure-ad-join-authentication-to-active-directory-using-azure-ad-kerberos-cloud-trust-preview)
@ -39,7 +39,7 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
![Azure AD join authentication to Azure Active Directory.](images/howitworks/auth-aadj-cloud.png)
> [!NOTE]
> All Azure AD joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
> All Azure AD-joined devices authenticate with Windows Hello for Business to Azure AD the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD.
| Phase | Description |
| :----: | :----------- |

4
windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md
View File

@ -80,7 +80,7 @@ List of provisioning flows:
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
> [!NOTE]
> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to AAD and AD after provisioning their credential.
> Windows Hello for Business Cloud Trust does not require users' keys to be synced from Azure AD to AD. Users can immediately authenticate to Azure Active Directory and AD after provisioning their credential.
[Return to top](#windows-hello-for-business-provisioning)
@ -94,7 +94,7 @@ List of provisioning flows:
| A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Azure Active Directory Web Account Manager plug-in.<br>Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Azure MFA service provides the second factor of authentication. If the user has performed Azure MFA within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they are not prompted for MFA because the current MFA remains valid.<br>Azure Active Directory validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. |
| B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pre-generation pool, which includes attestation data. This is the user key (ukpub/ukpriv). |
| C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Azure Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Azure Active Directory returns a key ID to the application which signals the end of user provisioning and the application exits. |
| D | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. AAD Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
| D | Azure AD Connect requests updates on its next synchronization cycle. Azure Active Directory sends the user's public key that was securely registered through provisioning. Azure Active Directory Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. |
> [!IMPORTANT]
> The newly provisioned user will not be able to sign in using Windows Hello for Business until Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory.

4
windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
View File

@ -166,7 +166,7 @@ For more than a decade, many organizations have used the domain join to their on
- 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.
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.
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.
### Related topics
[Azure AD Joined](#azure-ad-joined), [Azure AD Registered](#azure-ad-registered), [Hybrid Deployment](#hybrid-deployment)
@ -252,7 +252,7 @@ The simplest way to enable authentication for on-premises directory objects in A
## 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.
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.).
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.).
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.

2
windows/security/identity-protection/hello-for-business/hello-how-it-works.md
View File

@ -22,7 +22,7 @@ ms.reviewer:
- Windows 10
- Windows 11
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory joined, Hybrid Azure Active Directory joined, or Azure Active Directory registered devices. Windows Hello for Business also works for domain joined devices.
Windows Hello for Business is a modern, two-factor credential that is the more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Azure Active Directory-joined, Hybrid Azure Active Directory-joined, or Azure AD registered devices. Windows Hello for Business also works for domain joined devices.
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]

22
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
View File

@ -1,5 +1,5 @@
---
title: Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
title: Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
description: Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support them.
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
ms.prod: m365-security
@ -17,19 +17,19 @@ ms.topic: article
localizationpriority: medium
ms.date: 01/14/2021
---
# Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business
# Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business
**Applies to**
- Windows 10
- Windows 11
- Azure Active Directory joined
- Azure Active Directory-joined
- Hybrid Deployment
- Key trust model
## Prerequisites
Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD joined devices. Unlike hybrid Azure AD joined devices, Azure AD joined devices do not have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD joined devices.
Before adding Azure Active Directory (Azure AD) joined devices to your existing hybrid deployment, you need to verify the existing deployment can support Azure AD-joined devices. Unlike hybrid Azure AD-joined devices, Azure AD-joined devices do not have a relationship with your Active Directory domain. This factor changes the way in which users authenticate to Active Directory. Validate the following configurations to ensure they support Azure AD-joined devices.
- Azure Active Directory Connect synchronization
- Device Registration
@ -56,9 +56,9 @@ Certificates issued by a certificate authority can be revoked. When a certifica
![Domain Controller Certificate with LDAP CDP.](images/aadj/Certificate-CDP.png)
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory joined devices and users on Azure Active Directory joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
The preceding domain controller certificate shows a CRL distribution path (CDP) using Active Directory. You can determine this because the value in the URL begins with **ldap**. Using Active Directory for domain joined devices provides a highly available CRL distribution point. However, Azure Active Directory-joined devices and users on Azure Active Directory-joined devices cannot read data from Active Directory, and certificate validation does not provide an opportunity to authenticate prior to reading the certificate revocation list. This becomes a circular problem as the user is attempting to authenticate, but must read Active Directory to complete the authentication, but the user cannot read Active Directory because they have not authenticated.
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
To resolve this issue, the CRL distribution point must be a location that is accessible by Azure Active Directory-joined devices that does not require authentication. The easiest solution is to publish the CRL distribution point on a web server that uses HTTP (not HTTPS).
If your CRL distribution point does not list an HTTP distribution point, then you need to reconfigure the issuing certificate authority to include an HTTP CRL distribution point, preferably first in the list of distribution points.
@ -73,7 +73,7 @@ If you are interested in configuring your environment to use the Windows Hello f
### Domain Controller Certificates
Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD joined devices authenticating to Active Directory
Certificate authorities write CRL distribution points in certificates as they are issued. If the distribution point changes, then previously issued certificates must be reissued for the certificate authority to include the new CRL distribution point. The domain controller certificate is one the critical components of Azure AD-joined devices authenticating to Active Directory
#### Why does Windows need to validate the domain controller certificate?
@ -87,7 +87,7 @@ Windows Hello for Business enforces the strict KDC validation security feature w
- The domain controller's certificate's signature hash algorithm is **sha256**.
- The domain controller's certificate's public key is **RSA (2048 Bits)**.
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are adding Azure AD joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
Authenticating from a Hybrid Azure AD joined device to a domain using Windows Hello for Business does not enforce that the domain controller certificate includes the **KDC Authentication** EKU. If you are adding Azure AD-joined devices to an existing domain environment, make sure to verify that your domain controller certificate has been updated to include the **KDC Authentication** EKU. If you need to update your domain controller certificate to include the **KDC Authentication** EKU, follow the instructions in [Configure Hybrid Windows Hello for Business: Public Key Infrastructure](hello-hybrid-key-whfb-settings-pki.md)
> [!Tip]
> If you are using Windows Server 2008, **Kerberos Authentication** is not the default template, so make sure to use the correct template when issuing or re-issuing the certificate.
@ -107,7 +107,7 @@ Steps you will perform include:
### Configure Internet Information Services to host CRL distribution point
You need to host your new certificate revocation list of a web server so Azure AD joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps is just one and may be useful for those unfamiliar with adding a new CRL distribution point.
You need to host your new certificate revocation list of a web server so Azure AD-joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps is just one and may be useful for those unfamiliar with adding a new CRL distribution point.
> [!IMPORTANT]
> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http.
@ -265,7 +265,7 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
## Configure and Assign a Trusted Certificate Device Configuration Profile
Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD joined devices. Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD joined devices do not trust domain controller certificates and authentication fails.
Your domain controllers have new certificate that include the new CRL distribution point. Next, you need your enterprise root certificate so you can deploy it to Azure AD-joined devices. Deploying the enterprise root certificates to the device, ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Azure AD-joined devices do not trust domain controller certificates and authentication fails.
Steps you will perform include:
- [Export Enterprise Root certificate](#export-enterprise-root-certificate)
@ -288,7 +288,7 @@ Steps you will perform include:
### Create and Assign a Trust Certificate Device Configuration Profile
A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD joined devices.
A **Trusted Certificate** device configuration profile is how you deploy trusted certificates to Azure AD-joined devices.
1. Sign-in to the [Microsoft Azure Portal](https://portal.azure.com) and select **Microsoft Intune**.
2. Click **Device configuration**. In the **Device Configuration** blade, click **Create profile**.

24
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
View File

@ -1,6 +1,6 @@
---
title: Using Certificates for AADJ On-premises Single-sign On single sign-on
description: If you want to use certificates for on-premises single-sign on for Azure Active Directory joined devices, then follow these additional steps.
description: If you want to use certificates for on-premises single-sign on for Azure Active Directory-joined devices, then follow these additional steps.
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -23,14 +23,14 @@ ms.reviewer:
- Windows 10
- Windows 11
- Azure Active Directory joined
- Azure Active Directory-joined
- Hybrid Deployment
- Certificate trust
If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD joined devices.
If you plan to use certificates for on-premises single-sign on, then follow these **additional** steps to configure the environment to enroll Windows Hello for Business certificates for Azure AD-joined devices.
> [!IMPORTANT]
> Ensure you have performed the configurations in [Azure AD joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue.
> Ensure you have performed the configurations in [Azure AD-joined devices for On-premises Single-Sign On](hello-hybrid-aadj-sso-base.md) before you continue.
Steps you will perform include:
@ -44,7 +44,7 @@ Steps you will perform include:
## Requirements
You need to install and configure additional infrastructure to provide Azure AD joined devices with on-premises single-sign on.
You need to install and configure additional infrastructure to provide Azure AD-joined devices with on-premises single-sign on.
- An existing Windows Server 2012 R2 or later Enterprise Certificate Authority
- A Windows Server 2012 R2 domain joined server that hosts the Network Device Enrollment Services role
@ -75,7 +75,7 @@ Most environments change the user principal name suffix to match the organizatio
To include the on-premises distinguished name in the certificate's subject, Azure AD Connect must replicate the Active Directory **distinguishedName** attribute to the Azure Active Directory **onPremisesDistinguishedName** attribute. Azure AD Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
### Verify AAD Connect version
### Verify Azure Active Directory Connect version
Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_.
@ -471,13 +471,13 @@ Sign-in a domain controller with a minimum access equivalent to _Domain Admins_.
5. Click **Add**.
6. Click **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Available services** list, select **HOST**. Click **OK**.
6. Click **Users or Computers...** Type the name of the _NDES Server_ you use to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **HOST**. Click **OK**.
![NDES Service delegation to NDES host.](images/aadjcert/ndessvcdelegation-host-ndes-spn.png)
7. Repeat steps 5 and 6 for each NDES server using this service account. Click **Add**.
8. Click **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Click **OK**.
8. Click **Users or computers...** Type the name of the issuing certificate authority this NDES service account uses to issue Windows Hello for Business authentication certificates to Azure AD-joined devices. From the **Available services** list, select **dcom**. Hold the **CTRL** key and select **HOST**. Click **OK**.
9. Repeat steps 8 and 9 for each issuing certificate authority from which one or more NDES servers request certificates.
@ -550,7 +550,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
1. Open an elevated command prompt.
2. Using the table above, decide which registry value name you will use to request Windows Hello for Business authentication certificates for Azure AD joined devices.
2. Using the table above, decide which registry value name you will use to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
3. Type the following command:
@ -558,7 +558,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v [registryValueName] /t REG_SZ /d [certificateTemplateName]
```
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD joined devices. Example:
where **registryValueName** is one of the three value names from the above table and where **certificateTemplateName** is the name of the certificate template you created for Windows Hello for Business Azure AD-joined devices. Example:
```console
reg add HKLM\Software\Microsoft\Cryptography\MSCEP /v SignatureTemplate /t REG_SZ /d AADJWHFBAuthentication
@ -573,7 +573,7 @@ Sign-in to the NDES Server with _local administrator_ equivalent credentials.
### Create a Web Application Proxy for the internal NDES URL.
Certificate enrollment for Azure AD joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
Certificate enrollment for Azure AD-joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.
Ideally, you configure your Microsoft Intune SCEP certificate profile to use multiple external NDES URLs. This enables Microsoft Intune to round-robin load balance the certificate requests to identically configured NDES Servers (each NDES server can accommodate approximately 300 concurrent requests). Microsoft Intune sends these requests to Azure AD Application Proxies.
@ -697,7 +697,7 @@ Sign-in the NDES server with access equivalent to _local administrators_.
10. Click **Enroll**
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD joined devices.
11. Repeat these steps for all NDES Servers used to request Windows Hello for Business authentication certificates for Azure AD-joined devices.
### Configure the Web Server Role

12
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
View File

@ -1,6 +1,6 @@
---
title: Azure AD Join Single Sign-on Deployment
description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory joined devices, using Windows Hello for Business.
description: Learn how to provide single sign-on to your on-premises resources for Azure Active Directory-joined devices, using Windows Hello for Business.
keywords: identity, PIN, biometric, Hello, passport, AADJ, SSO,
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -22,10 +22,10 @@ ms.reviewer:
- Windows 10
- Windows 11
- Azure Active Directory joined
- Azure Active Directory-joined
- Hybrid deployment
Windows Hello for Business combined with Azure Active Directory joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory joined devices using Windows Hello for Business, using a key or a certificate.
Windows Hello for Business combined with Azure Active Directory-joined devices makes it easy for users to securely access cloud-based resources using a strong, two-factor credential. Some resources may remain on-premises as enterprises transition resources to the cloud and Azure AD-joined devices may need to access these resources. With additional configurations to your current hybrid deployment, you can provide single sign-on to your on-premises resources for Azure Active Directory-joined devices using Windows Hello for Business, using a key or a certificate.
## Key vs. Certificate
@ -33,10 +33,10 @@ Enterprises can use either a key or a certificate to provide single-sign on for
When using a key, the on-premises environment needs an adequate distribution of Windows Server 2016 domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement. However, single-sign on using a certificate requires additional infrastructure to issue a certificate when the user enrolls for Windows Hello for Business. Azure AD joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM). Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.
When using a certificate, the on-premises environment can use Windows Server 2008 R2 and later domain controllers, which removes the Windows Server 2016 domain controller requirement. However, single-sign on using a certificate requires additional infrastructure to issue a certificate when the user enrolls for Windows Hello for Business. Azure AD-joined devices enroll certificates using Microsoft Intune or a compatible Mobile Device Management (MDM). Microsoft Intune and Windows Hello for Business use the Network Device Enrollment Services (NDES) role and support Microsoft Intune connector.
To deploy single sign-on for Azure AD joined devices using keys, read and follow [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md).
To deploy single sign-on for Azure AD joined devices using certificates, read and follow [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md) and then [Using Certificates for AADJ On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md).
To deploy single sign-on for Azure AD-joined devices using keys, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md).
To deploy single sign-on for Azure AD-joined devices using certificates, read and follow [Configure Azure AD-joined devices for On-premises Single-Sign On using Windows Hello for Business](hello-hybrid-aadj-sso-base.md) and then [Using Certificates for Azure Active Directory-joined On-premises Single-sign On](hello-hybrid-aadj-sso-cert.md).
## Related topics

10
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md
View File

@ -43,8 +43,8 @@ Use this three-phased approach for configuring device registration.
> Before proceeding, you should familiarize yourself with device registration concepts such as:
>
> - Azure AD registered devices
> - Azure AD joined devices
> - Hybrid Azure AD joined devices
> - Azure AD-joined devices
> - Hybrid Azure AD-joined devices
>
> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](/azure/active-directory/device-management-introduction)
@ -55,7 +55,7 @@ Use this three-phased approach for configuring device registration.
To support hybrid Windows Hello for Business, configure hybrid Azure AD join.
Follow the guidance on [How to configure hybrid Azure Active Directory joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment.
Follow the guidance on [How to configure hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment.
If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps:
@ -69,11 +69,11 @@ You can learn more about this scenario by reading [Review on-premises UPN suppor
## Configure Active Directory to support Azure device synchronization
Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD joined devices. Begin with upgrading the Active Directory Schema
Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD-joined devices. Begin with upgrading the Active Directory Schema
### Upgrading Active Directory to the Windows Server 2016 or later Schema
To use Windows Hello for Business with Hybrid Azure AD joined devices, you must first upgrade your Active Directory schema to Windows Server 2016 or later.
To use Windows Hello for Business with Hybrid Azure AD-joined devices, you must first upgrade your Active Directory schema to Windows Server 2016 or later.
> [!IMPORTANT]
> If you already have a Windows Server 2016 or later domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 or later Schema** (this section).

4
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md
View File

@ -31,7 +31,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
![Event358 from User Device Registration log showing Windows Hello for Business prerequisite check result.](images/Event358.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.
@ -52,7 +52,7 @@ The provisioning flow has all the information it needs to complete the Windows H
- A fresh, successful multi-factor authentication
- A validated PIN that meets the PIN complexity requirements
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. AAD Connect synchronizes the user's key to the on-premises Active Directory.
The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key. Azure Active Directory Connect synchronizes the user's key to the on-premises Active Directory.
> [!IMPORTANT]
> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).

2
windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
View File

@ -38,7 +38,7 @@ This section has you configure certificate templates on your Windows Server 2012
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD joined devices. The steps below to *Create a Domain Controller Authentication (Kerberos) Certificate Template* and *Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template* to include the **KDC Authentication** OID in the domain controller certificate may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD joined devices to your environment in the future.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. The steps below to *Create a Domain Controller Authentication (Kerberos) Certificate Template* and *Configure Certificate Superseding for the Domain Controller Authentication (Kerberos) Certificate Template* to include the **KDC Authentication** OID in the domain controller certificate may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD-joined devices to your environment in the future.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template as a baseline to create an updated domain controller certificate template.

10
windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust.md
View File

@ -40,7 +40,7 @@ Windows Hello for Business cloud trust uses Azure Active Directory (AD) Kerberos
## Azure Active Directory Kerberos and Cloud Trust Authentication
Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
Key trust and certificate trust use certificate authentication based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires PKI for DC certificates, and requires end-user certificates for certificate trust. Single sign-on (SSO) to on-premises resources from Azure AD-joined devices requires more PKI configuration to publish a certificate revocation list (CRL) to a public endpoint. Cloud trust uses Azure AD Kerberos that doesn't require any of the above PKI to get the user a TGT.
With Azure AD Kerberos, Azure AD can issue TGTs for one or more of your AD domains. Windows can request a TGT from Azure AD when authenticating with Windows Hello for Business and use the returned TGT for logon or to access traditional AD-based resources. Kerberos service tickets and authorization continue to be controlled by your on-premises AD DCs.
@ -53,7 +53,7 @@ More details on how Azure AD Kerberos enables access to on-premises resources ar
| Requirement | Notes |
| --- | --- |
| Multi-factor Authentication | This requirement can be met using [Azure AD multi-factor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multi-factor authentication provided through AD FS, or a comparable solution. |
| Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD joined devices. |
| Patched Windows 10 version 21H2 or patched Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Azure AD joined and Hybrid Azure AD-joined devices. |
| Fully patched Windows Server 2016 or later Domain Controllers | Domain controllers should be fully patched to support updates needed for Azure AD Kerberos. If you're using Windows Server 2016, [KB3534307](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e) must be installed. If you're using Server 2019, [KB4534321](https://support.microsoft.com/en-us/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f) must be installed. |
| Azure AD Kerberos PowerShell module | This module is used for enabling and managing Azure AD Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).|
| Device management | Windows Hello for Business cloud trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. |
@ -83,7 +83,7 @@ If you haven't deployed Azure AD Kerberos, follow the instructions in the [Enabl
### Configure Windows Hello for Business Policy
After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD joined devices.
After setting up the Azure AD Kerberos Object, Windows Hello for business cloud trust must be enabled using policy. By default, cloud trust won't be used by Hybrid Azure AD joined or Azure AD-joined devices.
#### Configure Using Group Policy
@ -202,7 +202,7 @@ To configure the cloud trust policy, follow the steps below:
## Provisioning
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD joined devices when cloud trust is enabled by policy.
The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business cloud trust adds a prerequisite check for Hybrid Azure AD-joined devices when cloud trust is enabled by policy.
You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs\Microsoft\Windows**. This information is also available using the [**dsregcmd /status**](/azure/active-directory/devices/troubleshoot-device-dsregcmd) command from a console.
@ -210,7 +210,7 @@ You can determine the status of the prerequisite check by viewing the **User Dev
The cloud trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Azure AD Kerberos is set up for the user's domain and tenant. If Azure AD Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud trust is not being enforced by policy or if the device is Azure AD joined.
This prerequisite check isn't done for provisioning on Azure AD joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
This prerequisite check isn't done for provisioning on Azure AD-joined devices. If Azure AD Kerberos isn't provisioned, a user on an Azure AD joined device will still be able to sign in.
### PIN Setup

2
windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install.md
View File

@ -85,7 +85,7 @@ If you do not have an existing public key infrastructure, please review [Certifi
> [!IMPORTANT]
> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
> * Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based URL.
> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based URL.
### Section Review

6
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
View File

@ -31,8 +31,8 @@ You're ready to configure device registration for your hybrid environment. Hybri
> [!NOTE]
> Before proceeding, you should familiarize yourself with device registration concepts such as:
> * Azure AD registered devices
> * Azure AD joined devices
> * Hybrid Azure AD joined devices
> * Azure AD-joined devices
> * Hybrid Azure AD-joined devices
>
> You can learn about this and more by reading [What is a device identity](/azure/active-directory/devices/overview)
@ -40,7 +40,7 @@ You're ready to configure device registration for your hybrid environment. Hybri
Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD.
Follow the guidance on the [How to configure hybrid Azure Active Directory joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment.
Follow the guidance on the [How to configure hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/hybrid-azuread-join-plan) page. In the **Select your scenario based on your identity infrastructure** section, identify your configuration (either **Managed environment** or **Federated environment**) and perform only the steps applicable to your environment.
If the user principal name (UPN) in your on-premises Active Directory is different from the UPN in Azure AD, you also need to complete the following steps:

2
windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
View File

@ -83,7 +83,7 @@ The minimum required Enterprise certificate authority that can be used with Wind
> [!IMPORTANT]
> For Azure AD joined device to authenticate to and use on-premises resources, ensure you:
> * Install the root certificate authority certificate for your organization in the user's trusted root certificate store.
> * Publish your certificate revocation list to a location that is available to Azure AD joined devices, such as a web-based url.
> * Publish your certificate revocation list to a location that is available to Azure AD-joined devices, such as a web-based url.
### Section Review
> [!div class="checklist"]

2
windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
View File

@ -31,7 +31,7 @@ The Windows Hello for Business provisioning begins immediately after the user ha
![Event358.](images/Event358-2.png)
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is Azure Active Directory-joined (AADJ or DJ++): Yes** appears. Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **AzureADJoined** reads **Yes**.
Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name. The user clicks **Setup a PIN**.

2
windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
View File

@ -38,7 +38,7 @@ This section has you configure certificate templates on your Windows Server 2012
Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate. Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. This provides clients a root of trust external to the domain - namely the enterprise certificate authority.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD joined devices. The steps below to update the domain controller certificate to include the **KDC Authentication** OID may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD joined devices to your environment in the future.
Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory. However, certificates based on the *Domain Controller* and *Domain Controller Authentication* certificate templates do not include the **KDC Authentication** object identifier (OID), which was later added to the Kerberos RFC. Inclusion of the **KDC Authentication** OID in domain controller certificate is not required for key trust authentication from Hybrid Azure AD-joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Azure AD-joined devices. The steps below to update the domain controller certificate to include the **KDC Authentication** OID may be skipped if you only have Hybrid Azure AD Joined devices in your environment, but we recommend completing these steps if you are considering adding Azure AD-joined devices to your environment in the future.
By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template. However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the **Kerberos Authentication** certificate template a baseline to create an updated domain controller certificate template.

2
windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
View File

@ -34,7 +34,7 @@ Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 C
Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) automatically request and renew the correct domain controller certificate.
Hybrid Azure AD joined devices needs one Group Policy setting:
Hybrid Azure AD-joined devices needs one Group Policy setting:
* Enable Windows Hello for Business
### Configure Domain Controllers for Automatic Certificate Enrollment

12
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -99,7 +99,7 @@ It's fundamentally important to understand which deployment model to use for a s
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
> [!NOTE]
> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business 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). More information will be available on Windows Hello for Business cloud trust once it is generally available.
> Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business 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). More information will be available on Windows Hello for Business cloud trust once it is generally available.
The key trust type does not require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
@ -191,7 +191,7 @@ If your organization does not have cloud resources, write **On-Premises** in box
### Trust type
Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
@ -259,10 +259,10 @@ If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage non-domain joined devices. If you choose to manage Azure Active Directory-joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
> [!NOTE]
> Azure Active Directory joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
@ -278,7 +278,7 @@ Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage non-domain joined devices.
> [!NOTE]
> Azure Active Directory joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
> Azure Active Directory-joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **2a** on your planning worksheet read **modern management**.
@ -306,7 +306,7 @@ If box **1a** on your planning worksheet reads **cloud only**, ignore the public
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD joined devices and Azure AD joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
The registration authority only relates to certificate trust deployments and the management used for domain and non-domain joined devices. Hybrid Azure AD-joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Hybrid Azure AD-joined devices and Azure AD-joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:

2
windows/security/identity-protection/vpn/how-to-use-single-sign-on-sso-over-vpn-and-wi-fi-connections.md
View File

@ -80,7 +80,7 @@ If the credentials are certificate-based, then the elements in the following tab
| SubjectName | The user’s distinguished name (DN) where the domain components of the distinguished name reflect the internal DNS namespace when the SubjectAlternativeName does not have the fully qualified UPN required to find the domain controller. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located. |
| SubjectAlternativeName | The user’s fully qualified UPN where a domain name component of the user’s UPN matches the organizations internal domain’s DNS namespace. </br>This requirement is relevant in multi-forest environments as it ensures a domain controller can be located when the SubjectName does not have the DN required to find the domain controller. |
| Key Storage Provider (KSP) | If the device is joined to Azure AD, a discrete SSO certificate is used. |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br>- Client Authentication (for the VPN) </br>- EAP Filtering OID (for Windows Hello for Business)</br>- SmartCardLogon (for Azure AD joined devices) </br>If the domain controllers require smart card EKU either:</br>- SmartCardLogon</br>- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) <br>Otherwise:</br>- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2) |
| EnhancedKeyUsage | One or more of the following EKUs is required: </br>- Client Authentication (for the VPN) </br>- EAP Filtering OID (for Windows Hello for Business)</br>- SmartCardLogon (for Azure AD-joined devices) </br>If the domain controllers require smart card EKU either:</br>- SmartCardLogon</br>- id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4) <br>Otherwise:</br>- TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2) |
## NDES server configuration

2
windows/security/information-protection/bitlocker/bitlocker-deployment-comparison.md
View File

@ -33,7 +33,7 @@ This article depicts the BitLocker deployment comparison chart.
|Minimum client operating system version |Windows 11 and Windows 10 | Windows 11, Windows 10, and Windows 8.1 | Windows 7, Windows 8, Windows 8.1, Windows 10, Windows 10 IoT, and Windows 11 |
|Supported Windows SKUs | Enterprise, Pro, Education | Enterprise, Pro, Education | Enterprise |
|Minimum Windows version |1909 | None | None |
|Supported domain-joined status | Microsoft Azure Active Directory (Azure AD) joined, hybrid Azure AD joined | Active Directory joined, hybrid Azure AD joined | Active Directory joined |
|Supported domain-joined status | Microsoft Azure Active Directory (Azure AD) joined, hybrid Azure AD joined | Active Directory-joined, hybrid Azure AD joined | Active Directory-joined |
|Permissions required to manage policies | Endpoint security manager or custom | Full administrator or custom | Domain Admin or Delegated GPO access |
|Cloud or on premises | Cloud | On premises | On premises |
|Server components required? | | :::image type="content" source="images/yes-icon.png" alt-text="supported."::: | :::image type="content" source="images/yes-icon.png" alt-text="supported."::: |

2
windows/security/information-protection/bitlocker/ts-bitlocker-tpm-issues.md
View File

@ -110,5 +110,5 @@ This issue may occur when the Windows operating system is not the owner of the T
For more information about TPM issues, see the following articles:
- [TPM fundamentals: Anti-hammering](../tpm/tpm-fundamentals.md#anti-hammering)
- [Troubleshooting hybrid Azure Active Directory joined devices](/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current)
- [Troubleshooting hybrid Azure Active Directory-joined devices](/azure/active-directory/devices/troubleshoot-hybrid-join-windows-current)
- [Troubleshoot the TPM](../tpm/initialize-and-configure-ownership-of-the-tpm.md)

2
windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
View File

@ -75,7 +75,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or an Azure AD account. That account can then log on to a peer device (if the peer device is likewise configured) without the use of a Windows logon account (domain or local). This setup is not only beneficial, but required for Azure AD joined devices, where they are signed in with an online identity and are issued certificates by Azure AD. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it does not pose any threats in a hybrid environment where Azure AD is used as it relies on the user's online identity and Azure AD to authenticate.
Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or an Azure AD account. That account can then log on to a peer device (if the peer device is likewise configured) without the use of a Windows logon account (domain or local). This setup is not only beneficial, but required for Azure AD-joined devices, where they are signed in with an online identity and are issued certificates by Azure AD. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it does not pose any threats in a hybrid environment where Azure AD is used as it relies on the user's online identity and Azure AD to authenticate.
### Countermeasure

2
windows/security/zero-trust-windows-device-health.md
View File

@ -50,7 +50,7 @@ A summary of the steps involved in attestation and Zero Trust on the device side
3. The TPM is verified by using the keys/cryptographic material available on the chipset with an [Azure Certificate Service](/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation).
4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger (MEM) integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with AAD conditional access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device.
4. This information is then sent to the attestation service in the cloud to verify that the device is safe. Microsoft Endpoint Manger (MEM) integrates with Microsoft Azure Attestation to review device health comprehensively and connect this information with Azure Active Directory conditional access. This integration is key for Zero Trust solutions that help bind trust to an untrusted device.
5. The attestation service does the following:

4
windows/whats-new/ltsc/whats-new-windows-10-2019.md
View File

@ -213,7 +213,7 @@ For more information, see: [Windows Hello and FIDO2 Security Keys enable secure
Windows Defender Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It's designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
Windows Defender Credential Guard has always been an optional feature, but Windows 10 in S mode turns on this functionality by default when the machine has been Azure Active Directory joined. This feature provides an added level of security when connecting to domain resources not normally present on devices running Windows 10 in S mode.
Windows Defender Credential Guard has always been an optional feature, but Windows 10 in S mode turns on this functionality by default when the machine has been Azure Active Directory-joined. This feature provides an added level of security when connecting to domain resources not normally present on devices running Windows 10 in S mode.
> [!NOTE]
> Windows Defender Credential Guard is available only to S mode devices or Enterprise and Education Editions.
@ -471,7 +471,7 @@ Some of the other new CSPs are:
For more information, see [What's new in mobile device enrollment and management](/windows/client-management/mdm/new-in-windows-mdm-enrollment-management).
MDM has been expanded to include domain joined devices with Azure Active Directory registration. Group policy can be used with Active Directory joined devices to trigger auto-enrollment to MDM. For more information, see [Enroll a Windows 10 device automatically using Group Policy](/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy).
MDM has been expanded to include domain joined devices with Azure Active Directory registration. Group policy can be used with Active Directory-joined devices to trigger auto-enrollment to MDM. For more information, see [Enroll a Windows 10 device automatically using Group Policy](/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy).
Multiple new configuration items are also added. For more information, see [What's new in MDM enrollment and management](/windows/client-management/mdm/new-in-windows-mdm-enrollment-management).

2
windows/whats-new/ltsc/whats-new-windows-10-2021.md
View File

@ -187,7 +187,7 @@ Windows Management Instrumentation (WMI) Group Policy Service (GPSVC) has a perf
#### Key-rolling and Key-rotation
This release also includes two new features called Key-rolling and Key-rotation enables secure rolling of Recovery passwords on MDM-managed AAD devices on demand from Microsoft Intune/MDM tools or when a recovery password is used to unlock the BitLocker protected drive. This feature will help prevent accidental recovery password disclosure as part of manual BitLocker drive unlock by users.
This release also includes two new features called Key-rolling and Key-rotation enables secure rolling of Recovery passwords on MDM-managed Azure Active Directory devices on demand from Microsoft Intune/MDM tools or when a recovery password is used to unlock the BitLocker protected drive. This feature will help prevent accidental recovery password disclosure as part of manual BitLocker drive unlock by users.
## Deployment

2
windows/whats-new/whats-new-windows-10-version-1703.md
View File

@ -181,7 +181,7 @@ Windows Update for Business managed devices are now able to defer feature update
### Windows Insider for Business
We recently added the option to download Windows 10 Insider Preview builds using your corporate credentials in Azure Active Directory (AAD). By enrolling devices in AAD, you increase the visibility of feedback submitted by users in your organization – especially on features that support your specific business needs. For details, see [Windows Insider Program for Business](/windows-insider/business/register).
We recently added the option to download Windows 10 Insider Preview builds using your corporate credentials in Azure Active Directory (AAD). By enrolling devices in Azure AD, you increase the visibility of feedback submitted by users in your organization – especially on features that support your specific business needs. For details, see [Windows Insider Program for Business](/windows-insider/business/register).
### Optimize update delivery

2
windows/whats-new/whats-new-windows-10-version-1709.md
View File

@ -57,7 +57,7 @@ You can now register your Azure AD domains to the Windows Insider Program. For m
### Mobile Device Management (MDM)
MDM has been expanded to include domain joined devices with Azure Active Directory registration. Group Policy can be used with Active Directory joined devices to trigger auto-enrollment to MDM. For more information, see [Enroll a Windows 10 device automatically using Group Policy](/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy).
MDM has been expanded to include domain joined devices with Azure Active Directory registration. Group Policy can be used with Active Directory-joined devices to trigger auto-enrollment to MDM. For more information, see [Enroll a Windows 10 device automatically using Group Policy](/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy).
Multiple new configuration items are also added. For more information, see [What's new in MDM enrollment and management](/windows/client-management/mdm/new-in-windows-mdm-enrollment-management#whatsnew1709).

8
windows/whats-new/whats-new-windows-10-version-1809.md
View File

@ -31,7 +31,7 @@ Windows Autopilot self-deploying mode enables a zero touch device provisioning e
This self-deploying capability removes the current need to have an end user interact by pressing the “Next” button during the deployment process.
You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your organization’s MDM provider, and provision policies and applications, all with no user authentication or user interaction required.
You can utilize Windows Autopilot self-deploying mode to register the device to an Azure Active Directory tenant, enroll in your organization’s MDM provider, and provision policies and applications, all with no user authentication or user interaction required.
To learn more about Autopilot self-deploying mode and to see step-by-step instructions to perform such a deployment, [Windows Autopilot self-deploying mode](/windows/deployment/windows-autopilot/self-deploying).
@ -60,7 +60,7 @@ This also means you’ll see more links to other security apps within **Windows
#### Silent enforcement on fixed drives
Through a Modern Device Management (MDM) policy, BitLocker can be enabled silently for standard Azure Active Directory (AAD) joined users. In Windows 10, version 1803 automatic BitLocker encryption was enabled for standard AAD users, but this still required modern hardware that passed the Hardware Security Test Interface (HSTI). This new functionality enables BitLocker via policy even on devices that don’t pass the HSTI.
Through a Modern Device Management (MDM) policy, BitLocker can be enabled silently for standard Azure Active Directory (AAD)-joined users. In Windows 10, version 1803 automatic BitLocker encryption was enabled for standard Azure AD users, but this still required modern hardware that passed the Hardware Security Test Interface (HSTI). This new functionality enables BitLocker via policy even on devices that don’t pass the HSTI.
This is an update to the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp), which was introduced in Windows 10, version 1703, and leveraged by Intune and others.
@ -138,11 +138,11 @@ You can add specific rules for a WSL process in Windows Defender Firewall, just
We introduced new group policies and Modern Device Management settings to manage Microsoft Edge. The new policies include enabling and disabling full-screen mode, printing, favorites bar, and saving history; preventing certificate error overrides; configuring the Home button and startup options; setting the New Tab page and Home button URL, and managing extensions. Learn more about the [new Microsoft Edge policies](/microsoft-edge/deploy/change-history-for-microsoft-edge).
### Windows Defender Credential Guard is supported by default on 10S devices that are AAD Joined
### Windows Defender Credential Guard is supported by default on 10S devices that are Azure Active Directory-joined
Windows Defender Credential Guard is a security service in Windows 10 built to protect Active Directory (AD) domain credentials so that they can't be stolen or misused by malware on a user's machine. It is designed to protect against well-known threats such as Pass-the-Hash and credential harvesting.
Windows Defender Credential Guard has always been an optional feature, but Windows 10-S turns this functionality on by default when the machine has been Azure Active Directory joined. This provides an added level of security when connecting to domain resources not normally present on 10-S devices. Please note that Windows Defender Credential Guard is available only to S-Mode devices or Enterprise and Education Editions.
Windows Defender Credential Guard has always been an optional feature, but Windows 10-S turns this functionality on by default when the machine has been Azure Active Directory-joined. This provides an added level of security when connecting to domain resources not normally present on 10-S devices. Please note that Windows Defender Credential Guard is available only to S-Mode devices or Enterprise and Education Editions.
### Windows 10 Pro S Mode requires a network connection

2
windows/whats-new/whats-new-windows-10-version-1909.md
View File

@ -49,7 +49,7 @@ BitLocker and Mobile Device Management (MDM) with Azure Active Directory work to
### Key-rolling and Key-rotation
Windows 10, version 1909 also includes two new features called **Key-rolling** and **Key-rotation** enables secure rolling of Recovery passwords on MDM managed AAD devices on demand from Microsoft Intune/MDM tools or when a recovery password is used to unlock the BitLocker protected drive. This feature will help prevent accidental recovery password disclosure as part of manual BitLocker drive unlock by users.
Windows 10, version 1909 also includes two new features called **Key-rolling** and **Key-rotation** enables secure rolling of Recovery passwords on MDM managed Azure Active Directory devices on demand from Microsoft Intune/MDM tools or when a recovery password is used to unlock the BitLocker protected drive. This feature will help prevent accidental recovery password disclosure as part of manual BitLocker drive unlock by users.
### Transport Layer Security (TLS)