mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 11:53:37 +00:00
@ -252,7 +252,7 @@ Contains numeric value ranging from 0 to 100 to represent the wireless network's
|
||||
<sig_quality>80</sig_quality>
|
||||
```
|
||||
|
||||
### Sample Trusted Signal Congfigurations
|
||||
### Sample Trusted Signal Configurations
|
||||
|
||||
These examples are wrapped for readability. Once properly formatted, the entire XML contents must be a single line.
|
||||
|
||||
|
@ -66,7 +66,7 @@ Sign-in a domain controller or management workstation with domain administrator
|
||||
|
||||
The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group. This provides them the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
|
||||
|
||||
Sign-in a domain controller or management workstation with domain administrator equivalent credentials.
|
||||
Sign into a domain controller or management workstation with domain administrator equivalent credentials.
|
||||
|
||||
1. Open **Active Directory Users and Computers**.
|
||||
2. Click **View** and click **Advanced Features**.
|
||||
|
@ -42,7 +42,7 @@ A lab or proof-of-concept environment does not need high-availability or scalabi
|
||||
Please follow [Download the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#download-the-azure-multi-factor-authentication-server) to download Azure MFA server.
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Make sure to validate the requirements for Azure MFA server, as outlined in [Install and Configure the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#install-and-configure-the-azure-multi-factor-authentication-server) before proceeding. Do not use instllation instructions provided in the article.
|
||||
>Make sure to validate the requirements for Azure MFA server, as outlined in [Install and Configure the Azure Multi-Factor Authentication Server](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-server#install-and-configure-the-azure-multi-factor-authentication-server) before proceeding. Do not use installation instructions provided in the article.
|
||||
|
||||
Once you have validated all the requirements, please proceed to [Configure or Deploy Multifactor Authentication Services](hello-cert-trust-deploy-mfa.md).
|
||||
|
||||
|
@ -67,7 +67,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|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.|
|
||||
> [!IMPORTANT]
|
||||
> The newly provisionied 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.
|
||||
> 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.
|
||||
|
||||
|
||||
|
||||
@ -87,7 +87,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|H | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning.|
|
||||
|F | 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.|
|
||||
> [!IMPORTANT]
|
||||
> The newly provisionied 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.
|
||||
> 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.
|
||||
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
@ -104,12 +104,12 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
|
||||
|G | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning.|
|
||||
> [!IMPORTANT]
|
||||
> Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
|
||||
> Synchronous certificate enrollment does not depend on Azure AD Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
|
||||
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Federated environment
|
||||

|
||||

|
||||
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
@ -121,7 +121,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|F |The registration authority sends the certificate request to the enterprise issuing certificate authority. The certificate authority validates the certificate request is signed by a valid enrollment agent and, on success, issues a certificate and returns it to the registration authority that then returns the certificate to the application.|
|
||||
|G | The application receives the newly issued certificate and installs the it into the Personal store of the user. This signals the end of provisioning.|
|
||||
> [!IMPORTANT]
|
||||
> Synchronous certificate enrollment does not depend on Azure AD Connect to syncrhonize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not show in this flow.
|
||||
> Synchronous certificate enrollment does not depend on Azure AD Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Azure AD Connect continues to synchronize the public key to Active Directory, but is not shown in this flow.
|
||||
|
||||
[Return to top](#windows-hello-for-business-provisioning)
|
||||
## Domain joined provisioning in an On-premises Key Trust deployment
|
||||
|
@ -43,6 +43,6 @@ Provision can occur automatically through the out-of-box-experience (OOBE) on Az
|
||||
|
||||
## Authentication
|
||||
|
||||
Authentication using Windows Hello for Business is the goal, and the first step in getting to a passwordless environment. With the device registered, and provisioning complete. Users can sign-in to Windows 10 using biometrics or a PIN. PIN is the most common gesture and is avaiable on most computers and devices. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. The PIN nor the private portion of the credential are never sent to the identity provider, and the PIN is not stored on the device. It is user provided entropy when performing operations that use the private portion of the credential.
|
||||
Authentication using Windows Hello for Business is the goal, and the first step in getting to a passwordless environment. With the device registered, and provisioning complete. Users can sign-in to Windows 10 using biometrics or a PIN. PIN is the most common gesture and is available on most computers and devices. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. The PIN nor the private portion of the credential are never sent to the identity provider, and the PIN is not stored on the device. It is user provided entropy when performing operations that use the private portion of the credential.
|
||||
|
||||
[How Windows Hello for Business authentication works](hello-how-it-works-authentication.md)
|
||||
|
@ -69,8 +69,8 @@ To include the on-premises distinguished name in the certificate's subject, Azur
|
||||
### Verify AAD Connect version
|
||||
Sign-in to computer running Azure AD Connect with access equivalent to _local administrator_.
|
||||
|
||||
1. Open **Syncrhonization Services** from the **Azure AD Connect** folder.
|
||||
2. In the **Syncrhonization Service Manager**, click **Help** and then click **About**.
|
||||
1. Open **Synchronization Services** from the **Azure AD Connect** folder.
|
||||
2. In the **Synchronization Service Manager**, click **Help** and then click **About**.
|
||||
3. If the version number is not **1.1.819** or later, then upgrade Azure AD Connect to the latest version.
|
||||
|
||||
### Verify the onPremisesDistinguishedName attribute is synchronized
|
||||
@ -172,7 +172,7 @@ You must prepare the public key infrastructure and the issuing certificate autho
|
||||
When deploying certificates using Microsoft Intune, you have the option of providing the validity period in the SCEP certificate profile rather than relying on the validity period in the certificate template. If you need to issue the same certificate with different validity periods, it may be advantageous to use the SCEP profile, given the limited number of certificates a single NDES server can issue.
|
||||
|
||||
> [!NOTE]
|
||||
> Skip this step if you do not want to enable Microsoft Intune to specify the validity period of the certificate. Without this configuiration, the certificate request uses the validity period configured in the certificate template.
|
||||
> Skip this step if you do not want to enable Microsoft Intune to specify the validity period of the certificate. Without this configuration, the certificate request uses the validity period configured in the certificate template.
|
||||
|
||||
Sign-in to the issuing certificate authority with access equivalent to _local administrator_.
|
||||
|
||||
@ -222,7 +222,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin eq
|
||||
The certificate authority may only issue certificates for certificate templates that are published to that certificate authority. If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
|
||||
|
||||
> [!Important]
|
||||
> Ensure you publish the **AADJ WHFB Authentication** certificate templates to the certificate authority that Microsoft Intune uses by way of the NDES servers. The NDES configuration asks you to choose a certificate authority from which it requests certificates. You need to publish that cerificate templates to that issuing certificate authority. The **NDES-Intune Authentication** certificate is directly enrolled and can be published to any certificate authority.
|
||||
> Ensure you publish the **AADJ WHFB Authentication** certificate templates to the certificate authority that Microsoft Intune uses by way of the NDES servers. The NDES configuration asks you to choose a certificate authority from which it requests certificates. You need to publish that certificate templates to that issuing certificate authority. The **NDES-Intune Authentication** certificate is directly enrolled and can be published to any certificate authority.
|
||||
|
||||
Sign-in to the certificate authority or management workstations with an _Enterprise Admin_ equivalent credentials.
|
||||
|
||||
@ -373,7 +373,7 @@ where **registryValueName** is one of the three value names from the above table
|
||||
5. Close the command prompt.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Use the **name** of the certificate template; not the **display name**. The certificate template name does not include spaces. You can view the certificate names by looking at the **General** tab of the certificate template's properties in the **Certifcates Templates** management console (certtmpl.msc).
|
||||
> Use the **name** of the certificate template; not the **display name**. The certificate template name does not include spaces. You can view the certificate names by looking at the **General** tab of the certificate template's properties in the **Certificates Templates** management console (certtmpl.msc).
|
||||
|
||||
### 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.
|
||||
|
@ -74,7 +74,7 @@ Sign-in a domain controller or management workstation with *Domain Admin* equiva
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
|
||||
5. Configure Windows Hello for Business settings: Active Directory (*You are here*)
|
||||
|
@ -73,7 +73,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
|
||||
5. Configure Windows Hello for Business settings: AD FS (*You are here*)
|
||||
|
@ -79,7 +79,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
|
||||
5. Configure Windows Hello for Business settings: Directory Synchronization (*You are here*)
|
||||
|
@ -203,7 +203,7 @@ Sign-in to the certificate authority or management workstation with _Enterprise
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
|
||||
5. Configure Windows Hello for Business settings: PKI (*You are here*)
|
||||
|
@ -197,7 +197,7 @@ Users must receive the Windows Hello for Business group policy settings and have
|
||||
|
||||
## Follow the Windows Hello for Business hybrid certificate trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-cert-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
|
||||
4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
|
||||
5. Configure Windows Hello for Business policy settings (*You are here*)
|
||||
|
@ -27,7 +27,7 @@ Hybrid environments are distributed systems that enable organizations to use on-
|
||||
|
||||
The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include:
|
||||
* [Directories](#directories)
|
||||
* [Public Key Infrastucture](#public-key-infastructure)
|
||||
* [Public Key Infrastructure](#public-key-infastructure)
|
||||
* [Directory Synchronization](#directory-synchronization)
|
||||
* [Federation](#federation)
|
||||
* [MultiFactor Authentication](#multifactor-authentication)
|
||||
@ -118,9 +118,9 @@ Organizations wanting to deploy hybrid key trust need their domain joined device
|
||||
<br>
|
||||
|
||||
### Next Steps ###
|
||||
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.
|
||||
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**.
|
||||
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Syncrhonization**.
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Synchronization**.
|
||||
|
||||
For federated and non-federated environments, start with **Configure Windows Hello for Business settings**.
|
||||
|
||||
|
@ -58,7 +58,7 @@ Sign-in a domain controller or management workstation with *Domain Admin* equiva
|
||||
|
||||
## Follow the Windows Hello for Business hybrid key trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
|
||||
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
|
||||
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
|
||||
|
@ -55,7 +55,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
|
||||
|
||||
## Follow the Windows Hello for Business hybrid key trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
|
||||
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
|
||||
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
|
||||
|
@ -168,7 +168,7 @@ Users must receive the Windows Hello for Business group policy settings and have
|
||||
|
||||
## Follow the Windows Hello for Business hybrid key trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
|
||||
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
|
||||
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
|
||||
|
@ -45,7 +45,7 @@ For the most efficient deployment, configure these technologies in order beginni
|
||||
|
||||
## Follow the Windows Hello for Business hybrid key trust deployment guide
|
||||
1. [Overview](hello-hybrid-cert-trust.md)
|
||||
2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
|
||||
2. [Prerequisites](hello-hybrid-key-trust-prereqs.md)
|
||||
3. [New Installation Baseline](hello-hybrid-key-new-install.md)
|
||||
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
|
||||
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
|
||||
|
@ -23,7 +23,7 @@ Using configurable code integrity to restrict devices to only authorized apps ha
|
||||
|
||||
1. Configurable code integrity policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
|
||||
2. Configurable code integrity allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows.
|
||||
3. Customers can protect the configurable code integrity policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it extremely difficult for an attacker with administrative privledge, or malicious software that managed to gain administrative privilege, to alter the application control policy.
|
||||
3. Customers can protect the configurable code integrity policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it extremely difficult for an attacker with administrative privilege, or malicious software that managed to gain administrative privilege, to alter the application control policy.
|
||||
4. The entire configurable code integrity enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is significantly diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable code integrity or any other application control solution.
|
||||
|
||||
## (Re-)Introducing Windows Defender Application Control
|
||||
|
Reference in New Issue
Block a user