mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-24 14:53:44 +00:00
Merge branch 'master' into FIDO-staging
This commit is contained in:
Aabha Thipsay
@ -5,7 +5,7 @@ ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.date: 07/30/2018
|
||||
ms.date: 12/10/2018
|
||||
---
|
||||
|
||||
# Local Accounts
|
||||
@ -16,15 +16,8 @@ ms.date: 07/30/2018
|
||||
|
||||
This reference topic for the IT professional describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server. This topic does not describe the default local user accounts for an Active Directory domain controller.
|
||||
|
||||
**Did you mean…**
|
||||
|
||||
- [Active Directory Accounts](active-directory-accounts.md)
|
||||
|
||||
- [Microsoft Accounts](microsoft-accounts.md)
|
||||
|
||||
## <a href="" id="about-local-user-accounts-"></a>About local user accounts
|
||||
|
||||
|
||||
Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
|
||||
|
||||
This topic describes the following:
|
||||
@ -475,14 +468,9 @@ Passwords can be randomized by:
|
||||
|
||||
- Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools.
|
||||
|
||||
- Configuring, customizing and implementing a free tool to accomplish this task. A sample tool with source code is available at [Solution for management of built-in Administrator account’s password via GPO](https://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789).
|
||||
- Configuring [Local Administrator Password Solution (LAPS)](https://www.microsoft.com/download/details.aspx?id=46899) to accomplish this task.
|
||||
|
||||
**Note**
|
||||
This tool is not supported by Microsoft. There are some important considerations to make before deploying this tool because this tool requires client-side extensions and schema extensions to support password generation and storage.
|
||||
|
||||
|
||||
|
||||
- Create and implement a custom script or solution to randomize local account passwords.
|
||||
- Creating and implementing a custom script or solution to randomize local account passwords.
|
||||
|
||||
## <a href="" id="dhcp-references"></a>See also
|
||||
|
||||
|
||||
@ -51,7 +51,7 @@ For information about Windows Defender Remote Credential Guard hardware and soft
|
||||
|
||||
## Application requirements
|
||||
|
||||
When Windows Defender Credential Guard is enabled, specific authentication capabilities are blocked, so applications that require such capabilities will break. Applications should be tested prior to deployment to ensure compatiblity with the reduced functionality.
|
||||
When Windows Defender Credential Guard is enabled, specific authentication capabilities are blocked, so applications that require such capabilities will break. Applications should be tested prior to deployment to ensure compatibility with the reduced functionality.
|
||||
|
||||
>[!WARNING]
|
||||
> Enabling Windows Defender Credential Guard on domain controllers is not supported. <br>
|
||||
|
||||
@ -202,9 +202,9 @@ Active Directory Domain Services uses AdminSDHolder to secure privileged users a
|
||||
Sign-in to a domain controller or management workstation with access equivalent to _domain administrator_.
|
||||
|
||||
1. Type the following command to add the **allow** read and write property permissions for msDS-KeyCredentialLink attribute for the **Key Admins** (or **KeyCredential Admins**) group on the AdminSDHolder object.</br>
|
||||
```dsacls "CN=AdminSDHolder,CN=System,**DC=domain,DC=com**" /g "**[domainName\keyAdminGroup]**":RPWP,msDS-KeyCredentialLink```</br>
|
||||
```dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /g "[domainName\keyAdminGroup]":RPWP;msDS-KeyCredentialLink```</br>
|
||||
where **DC=domain,DC=com** is the LDAP path of your Active Directory domain and **domainName\keyAdminGroup]** is the NetBIOS name of your domain and the name of the group you use to give access to keys based on your deployment. For example:</br>
|
||||
```dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net /g "mstepdemo\Key Admins":RPWP,msDS-KeyCredentialLink```
|
||||
```dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=mstepdemo,DC=net" /g "mstepdemo\Key Admins":RPWP;msDS-KeyCredentialLink```
|
||||
2. To trigger security descriptor propagation, open **ldp.exe**.
|
||||
3. Click **Connection** and select **Connect...** Next to **Server**, type the name of the domain controller that holds the PDC role for the domain. Next to **Port**, type **389** and click **OK**.
|
||||
4. Click **Connection** and select **Bind...** Click **OK** to bind as the currently signed-in user.
|
||||
@ -266,4 +266,4 @@ Users appreciate convenience of biometrics and administrators value the security
|
||||
- [Windows Hello and password changes](hello-and-password-changes.md)
|
||||
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
|
||||
- [Event ID 300 - Windows Hello successfully created](hello-event-300.md)
|
||||
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
|
||||
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
|
||||
|
||||
@ -19,7 +19,7 @@ Windows Hello for Business authentication is passwordless, two-factor authentica
|
||||
Azure Active Directory joined devices authenticate to Azure during sign-in and can optional 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.<br>
|
||||
|
||||
[Azure AD join authentication to Azure Active Directory](#Azure-AD-join-authentication-to-Azure-Active-Directory)<br>
|
||||
[Azure AD join authentication to Active Direcotry using a Key](#Azure-AD-join-authentication-to-Active-Direcotry-using-a-Key)<br>
|
||||
[Azure AD join authentication to Active Directory using a Key](#Azure-AD-join-authentication-to-Active-Directory-using-a-Key)<br>
|
||||
[Azure AD join authentication to Active Directory using a Certificate](#Azure-AD-join-authentication-to-Active-Directory-using-a-Certificate)<br>
|
||||
[Hybrid Azure AD join authentication using a Key](#Hybrid-Azure-AD-join-authentication-using-a-Key)<br>
|
||||
[Hybrid Azure AD join authentication using a Certificate](#Hybrid-Azure-AD-join-authentication-using-a-Certificate)<br>
|
||||
@ -38,7 +38,7 @@ Azure Active Directory joined devices authenticate to Azure during sign-in and c
|
||||
|
||||
[Return to top](#Windows-Hello-for-Business-and-Authentication)
|
||||
## Azure AD join authentication to Active Directory using a Key
|
||||
|
||||
|
||||
|
||||
|
||||
| Phase | Description |
|
||||
|
||||
@ -77,11 +77,11 @@ Device Registration is a prerequisite to Windows Hello for Business provisioning
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
| A | The user signs in to a domain joined Windows 10 computers using domain credentials. This can be user name and password or smart card authentication. The user sign-in triggers the Automatic Device Join task.|
|
||||
|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines directs device registration to Azure Device Registration Service (ADRS).|
|
||||
|C | For the federated environments, the computer authenticates ADFS/STS using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task.
|
||||
|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.|
|
||||
|C | For the federated environments, the computer authenticates the enterprise device registration endpoint using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task.
|
||||
|D | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv). The application create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv. Next, the application derives second key pair from the TPM's storage root key. This is the transport key (tkpub/tkpriv).|
|
||||
|E | To provide SSO for on-premises federated application, the task requests an enterprise PRT from the on-premises STS. Windows Server 2016 running the Active Directory Federation Services role validate the request and return it the running task.|
|
||||
|F | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data. Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client. Device registration completes by receiving the device ID and the device certificate from Azure DRS. The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certificate is installed in the Personal store of the computer. With device registration complete, the task exits.|
|
||||
|G |If device write-back is enabled, on it's next synchronization cycle, Azure AD Connect requests updates from Azure Active Directory. Azure Active Directory correlates the device object with a matching synchronized computer object. Azure AD Connect receives the device object that includes the object GUID and computer SID and writes the device object to Active Directory.|
|
||||
|F | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data. Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client. Device registration completes by receiving the device ID and the device certificate from Azure DRS. The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certificate is installed in the Personal store of the computer. With device registration complete, the task exits.|
|
||||
|G | If Azure AD Connect device write-back is enabled, Azure AD Connect requests updates from Azure Active Directory at its next synchronization cycle (device write-back is required for hybrid deployment using certificate trust). Azure Active Directory correlates the device object with a matching synchronized computer object. Azure AD Connect receives the device object that includes the object GUID and computer SID and writes the device object to Active Directory.|
|
||||
|
||||
[Return to top](#Windows-Hello-for-Business-and-Device-Registration)
|
||||
[Return to top](#Windows-Hello-for-Business-and-Device-Registration)
|
||||
|
||||
@ -22,11 +22,12 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|
||||
[Azure AD joined provisioning in a Managed environment](#Azure-AD-joined-provisioning-in-a-Managed-environment)<br>
|
||||
[Azure AD joined provisioning in a Federated environment](#Azure-AD-joined-provisioning-in-a-Federated-environment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a Key Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Key-Trust-deployment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-Certificate-Trust-deployment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment)<br>
|
||||
[Domain joined provisioning in an On-premises Key Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Key-Trust-deployment)<br>
|
||||
[Domain joined provisioning in an On-premises Certificate Trust deployment](#Domain-joined-provisioning-in-an-Onpremises-Certificate-Trust-deployment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a Key Trust deployment in a Managed envrionment](#Hybrid-Azure-AD-joined-provisioning-in-a-Key-Trust-deployment-in-a-Managed-envrionment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a Certificate Trust deployment in a Managed environment](#Hybrid-Azure-AD-joined-provisioning-in-a-Certificate-Trust-deployment-in-a-Managed-environment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment-in-a-Managed-environment)<br>
|
||||
[Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Federated environment](#Hybrid-Azure-AD-joined-provisioning-in-a-synchronous-Certificate-Trust-deployment-in-a-Federated-environment)<br>
|
||||
[Domain joined provisioning in an On-premises Key Trust deployment](#Domain-joined-provisioning-in-an-On-premises-Key-Trust-deployment)<br>
|
||||
[Domain joined provisioning in an On-premises Certificate Trust deployment](#Domain-joined-provisioning-in-an-On-premises-Certificate-Trust-deployment)<br>
|
||||
|
||||
|
||||
|
||||
@ -85,7 +86,7 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|
||||
|
||||
[Return to top](#Windows-Hello-for-Business-Provisioning)
|
||||
## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environmnet
|
||||
## Hybrid Azure AD joined provisioning in a synchronous Certificate Trust deployment in a Managed environment
|
||||
|
||||
|
||||
| Phase | Description |
|
||||
@ -140,6 +141,6 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong,
|
||||
|D | The certificate request portion of provisioning begins after the application receives a successful response from key registration. The application creates a PKCS#10 certificate request. The key used in the certificate request is the same key that was securely provisioned.<br> The application sends the certificate request, which includes the public key, to the certificate registration authority hosted on the Active Directory Federation Services (AD FS) farm.<br> After receiving the certificate request, the certificate registration authority queries Active Directory for the msDS-KeyCredentailsLink for a list of registered public keys.|
|
||||
|E | The registration authority validates the public key in the certificate request matches a registered key for the user.<br> After validating the public key, the registration authority signs the certificate request using its enrollment agent certificate.|
|
||||
|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.|
|
||||
|G | The application receives the newly issued certificate and installs it into the Personal store of the user. This signals the end of provisioning.|
|
||||
|
||||
[Return to top](#Windows-Hello-for-Business-Provisioning)
|
||||
[Return to top](#Windows-Hello-for-Business-Provisioning)
|
||||
|
||||
@ -100,7 +100,7 @@ Sign-in to a domain controller or management workstation with access equivalent
|
||||
4. Type **NDES Servers** in **Enter the object names to select**. Click **OK**. Click **OK** on the **Active Directory Domain Services** success dialog.
|
||||
|
||||
> [!NOTE]
|
||||
> For high-availabilty, you should have more than one NDES server to service Windows Hello for Business certificate requests. You should add additional Windows Hello for Business NDES servers to this group to ensure they receive the proper configuration.
|
||||
> For high-availability, you should have more than one NDES server to service Windows Hello for Business certificate requests. You should add additional Windows Hello for Business NDES servers to this group to ensure they receive the proper configuration.
|
||||
|
||||
### Create the NDES Service Account
|
||||
The Network Device Enrollment Services (NDES) role runs under a service account. Typically, it is preferential to run services using a Group Managed Service Account (GMSA). While the NDES role can be configured to run using a GMSA, the Intune Certificate Connector was not designed nor tested using a GMSA and is considered an unsupported configuration. The deployment uses a normal services account.
|
||||
@ -517,8 +517,8 @@ Sign-in the NDES server with access equivalent to _local administrator_.
|
||||
#### Configure Parameters for HTTP.SYS
|
||||
1. Open an elevated command prompt.
|
||||
2. Run the following commands <br>
|
||||
```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 65534``` <br>
|
||||
```reg add HKLM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 65534```<br>
|
||||
```reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxFieldLength /t REG_DWORD /d 65534``` <br>
|
||||
```reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters /v MaxRequestBytes /t REG_DWORD /d 65534```<br>
|
||||
3. Restart the NDES server.
|
||||
|
||||
## Download, Install and Configure the Intune Certificate Connector
|
||||
@ -686,4 +686,4 @@ You have successfully completed the configuration. Add users that need to enrol
|
||||
> * Install and Configure the NDES Role
|
||||
> * Configure Network Device Enrollment Services to work with Microsoft Intune
|
||||
> * Download, Install, and Configure the Intune Certificate Connector
|
||||
> * Create and Assign a Simple Certificate Enrollment Protocol (SCEP Certificate Profile)
|
||||
> * Create and Assign a Simple Certificate Enrollment Protocol (SCEP Certificate Profile)
|
||||
|
||||
@ -29,7 +29,7 @@ When using a key, the on-premises environment needs an adequate distribution of
|
||||
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 key 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, 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 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).
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 o
|
||||
|
||||
3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.
|
||||
```PowerShell
|
||||
Install-AdcsCertificateAuthority
|
||||
Install-AdcsCertificationAuthority
|
||||
```
|
||||
|
||||
## Configure a Production Public Key Infrastructure
|
||||
@ -75,7 +75,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 certifcate store.
|
||||
> * 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.
|
||||
|
||||
### Section Review ###
|
||||
@ -84,7 +84,7 @@ If you do not have an existing public key infrastructure, please review [Certifi
|
||||
> * Minimum Windows Server 2012 Certificate Authority.
|
||||
> * Enterprise Certificate Authority.
|
||||
> * Functioning public key infrastructure.
|
||||
> * Root certifcate authority certificate (Azure AD Joined devices).
|
||||
> * Root certificate authority certificate (Azure AD Joined devices).
|
||||
> * Highly available certificate revocation list (Azure AD Joined devices).
|
||||
|
||||
## Azure Active Directory ##
|
||||
@ -131,7 +131,7 @@ Alternatively, you can configure Windows Server 2016 Active Directory Federation
|
||||
> * Review the overview and uses of Azure Multifactor Authentication.
|
||||
> * Review your Azure Active Directory subscription for Azure Multifactor Authentication.
|
||||
> * Create an Azure Multifactor Authentication Provider, if necessary.
|
||||
> * Configure Azure Multufactor Authentiation features and settings.
|
||||
> * Configure Azure Multifactor Authentiation features and settings.
|
||||
> * Understand the different User States and their effect on Azure Multifactor Authentication.
|
||||
> * Consider using Azure Multifactor Authentication or a third-party multifactor authentication provider with Windows Server Active Directory Federation Services, if necessary.
|
||||
|
||||
|
||||
@ -23,7 +23,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 Infrastructure](#public-key-infrastructure)
|
||||
* [Public Key Infrastucture](#public-key-infastructure)
|
||||
* [Directory Synchronization](#directory-synchronization)
|
||||
* [Federation](#federation)
|
||||
* [MultiFactor Authentication](#multifactor-authentication)
|
||||
@ -114,9 +114,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 Baseline**.
|
||||
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.
|
||||
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Synchronization**.
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Syncrhonization**.
|
||||
|
||||
For federated and non-federated environments, start with **Configure Windows Hello for Business settings**.
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ ms.date: 08/19/2018
|
||||
- Key trust
|
||||
|
||||
|
||||
## Directory Syncrhonization
|
||||
## Directory Synchronization
|
||||
|
||||
In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure. Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory.
|
||||
|
||||
|
||||
@ -46,7 +46,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
|
||||
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
|
||||
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.
|
||||
**Note**If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
|
||||
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
|
||||
6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
|
||||
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**.
|
||||
8. Close the console.
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ Domain controllers automatically request a certificate from the *Domain Controll
|
||||
|
||||
To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
|
||||
|
||||
#### Create a Domain Controller Automatic Certifiacte Enrollment Group Policy object
|
||||
#### Create a Domain Controller Automatic Certificate Enrollment Group Policy object
|
||||
|
||||
Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
|
||||
|
||||
@ -169,4 +169,4 @@ Users must receive the Windows Hello for Business group policy settings and have
|
||||
4. [Configure Directory Synchronization](hello-hybrid-key-trust-dirsync.md)
|
||||
5. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
|
||||
6. Configure Windows Hello for Business policy settings (*You are here*)
|
||||
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
|
||||
7. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
|
||||
|
||||
@ -39,7 +39,7 @@ Windows Hello addresses the following problems with passwords:
|
||||
* Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
|
||||
|
||||
### Hybrid Deployments
|
||||
The table shows the minimum requirements for each deployment.
|
||||
The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process.
|
||||
|
||||
| Key trust</br>Group Policy managed | Certificate trust</br>Mixed managed | Key trust</br>Modern managed | Certificate trust</br>Modern managed |
|
||||
| --- | --- | --- | --- |
|
||||
|
||||
@ -197,8 +197,7 @@ Sign-in a domain controller or management workstation with _Domain Admin_ equiva
|
||||
4. Click the **Members** tab and click **Add…**
|
||||
5. In the **Enter the object names to select** text box, type **adfssvc**. Click **OK**.
|
||||
6. Click **OK** to return to **Active Directory Users and Computers**.
|
||||
7. Click **OK** to return to **Active Directory Users and Computers**.
|
||||
8. Change to server hosting the AD FS role and restart it.
|
||||
7. Change to server hosting the AD FS role and restart it.
|
||||
|
||||
|
||||
## Configure the Device Registration Service
|
||||
|
||||
@ -38,7 +38,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-key-trust-deploy-mfa.md).
|
||||
|
||||
@ -47,4 +47,4 @@ Once you have validated all the requirements, please proceed to [Configure or De
|
||||
2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
|
||||
3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
|
||||
4. Validate and Deploy Multifactor Authentication Services (MFA) (*You are here*)
|
||||
5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
|
||||
5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
|
||||
|
||||
@ -64,7 +64,7 @@ Sign-in to a certificate authority or management workstations with _Domain Admin
|
||||
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
|
||||
5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name. Adjust the validity and renewal period to meet your enterprise’s needs.
|
||||
**Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
|
||||
6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
|
||||
6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **None** from the **Subject name format** list. Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
|
||||
7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list. Select **RSA** from the **Algorithm name** list. Type **2048** in the **Minimum key size** text box. Select **SHA256** from the **Request hash** list. Click **OK**.
|
||||
8. Close the console.
|
||||
|
||||
|
||||
@ -9,12 +9,11 @@ ms.pagetype: security, mobile
|
||||
author: mikestephens-MS
|
||||
ms.author: mstephen
|
||||
ms.localizationpriority: high
|
||||
ms.date: 05/05/2018
|
||||
---
|
||||
# Windows Hello for Business Overview
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows 10
|
||||
|
||||
In Windows 10, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN.
|
||||
|
||||
|
||||
@ -22,10 +22,10 @@ Over the past few years, Microsoft has continued their commitment to enabling a
|
||||
### 1. Develop a password replacement offering
|
||||
Before you move away from passwords, you need something to replace them. With Windows 10, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single-sign on to Azure Active Directory and Active Directory.
|
||||
|
||||
Deploying Windows Hello for Business is the first step towards password-less. With Windows Hello for Business deployed, it coexists with password nicely. Users are likely to useWindows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
|
||||
Deploying Windows Hello for Business is the first step towards password-less. With Windows Hello for Business deployed, it coexists with password nicely. Users are likely to use Windows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it.
|
||||
|
||||
### 2. Reduce user-visible password surface area
|
||||
With Windows Hello for Business and passwords coexisting in your environment, the next step towards password-less is to reduce the password surface. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the user knows they have a password, but they never user it. This state helps decondition users from providing a password any time a password prompt shows on their computer. This is a how passwords are phished. Users who rarely, it at all, use their password are unlikely to provide it. Password prompts are no longer the norm.
|
||||
With Windows Hello for Business and passwords coexisting in your environment, the next step towards password-less is to reduce the password surface. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the user knows they have a password, but they never use it. This state helps decondition users from providing a password any time a password prompt shows on their computer. This is how passwords are phished. Users who rarely, if at all, use their password are unlikely to provide it. Password prompts are no longer the norm.
|
||||
|
||||
### 3. Transition into a password-less deployment
|
||||
Once the user-visible password surface has been eliminated, your organization can begin to transition those users into a password-less world. A world where:
|
||||
|
||||
@ -7,7 +7,7 @@ ms.mktglfcycl: operate
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
ms.date: 09/19/2018
|
||||
ms.date: 11/16/2018
|
||||
---
|
||||
|
||||
# How User Account Control works
|
||||
@ -182,7 +182,7 @@ To better understand each component, review the table below:
|
||||
</ul>
|
||||
<p>Not recommended. Choose this only if it takes a long time to dim the desktop on your computer.</p><br>
|
||||
</li>
|
||||
<li><p><b>Never notify (Disable UAC)</b> will:</p>
|
||||
<li><p><b>Never notify (Disable UAC prompts)</b> will:</p>
|
||||
<ul>
|
||||
<li>Not notify you when programs try to install software or make changes to your computer.</li>
|
||||
<li>Not notify you when you make changes to Windows settings.</li>
|
||||
|
||||
@ -10,7 +10,7 @@ ms.author: pashort
|
||||
manager: elizapo
|
||||
ms.reviewer:
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 04/20/2018
|
||||
ms.date: 01/26/2019
|
||||
---
|
||||
|
||||
# VPN and conditional access
|
||||
@ -30,9 +30,9 @@ Conditional Access Platform components used for Device Compliance include the fo
|
||||
|
||||
- [Windows Health Attestation Service](https://technet.microsoft.com/itpro/windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices#device-health-attestation) (optional)
|
||||
|
||||
- Azure AD Certificate Authority - It is a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA cannot be configured as part of an on-premises Enterprise CA.
|
||||
- Azure AD Certificate Authority - It is a requirement that the client certificate used for the cloud-based device compliance solution be issued by an Azure Active Directory-based Certificate Authority (CA). An Azure AD CA is essentially a mini-CA cloud tenant in Azure. The Azure AD CA cannot be configured as part of an on-premises Enterprise CA.
|
||||
|
||||
- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used.
|
||||
- Azure AD-issued short-lived certificates - When a VPN connection attempt is made, the Azure AD Token Broker on the local device communicates with Azure Active Directory, which then checks for health based on compliance rules. If compliant, Azure AD sends back a short-lived certificate that is used to authenticate the VPN. Note that certificate authentication methods such as EAP-TLS can be used.
|
||||
|
||||
Additional details regarding the Azure AD issued short-lived certificate:
|
||||
- The default lifetime is 60 minutes and is configurable
|
||||
@ -52,15 +52,13 @@ The following client-side components are also required:
|
||||
- Trusted Platform Module (TPM)
|
||||
|
||||
## VPN device compliance
|
||||
According to the VPNv2 CSP, these settings options are **Optional**. If you want your users to access on-premises resources, such as files on a network share, based on the credential of a certificate that was issued by an on-premises CA, and not the Cloud CA certificate, you add these settings to the VPNv2 profile. Alternatively, if you add the cloud root certificates to the NTAuth store in on-prem AD, your user's cloud certificate will chain and KDC will issue TGT and TGS tickets to them.
|
||||
At this time, the Azure AD certificates issued to users do not contain a CRL Distribution Point (CDP) and are not suitable for Key Distribution Centers (KDCs) to issue Kerberos tokens. For users to gain access to on-premises resources such as files on a network share, client authentication certificates must be deployed to the Windows profiles of the users, and their VPNv2 profiles must contain the <SSO> section.
|
||||
|
||||
Server-side infrastructure requirements to support VPN device compliance include:
|
||||
|
||||
- The VPN server should be configured for certificate authentication.
|
||||
- The VPN server should be configured for certificate authentication
|
||||
- The VPN server should trust the tenant-specific Azure AD CA
|
||||
- Either of the below should be true for Kerberos/NTLM SSO:
|
||||
- Domain servers trust Azure AD CA
|
||||
- A domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO)
|
||||
- For client access using Kerberos/NTLM, a domain-trusted certificate is deployed to the client device and is configured to be used for single sign-on (SSO)
|
||||
|
||||
After the server side is set up, VPN admins can add the policy settings for conditional access to the VPN profile using the VPNv2 DeviceCompliance node.
|
||||
|
||||
@ -68,7 +66,7 @@ Two client-side configuration service providers are leveraged for VPN device com
|
||||
|
||||
- VPNv2 CSP DeviceCompliance settings
|
||||
- **Enabled**: enables the Device Compliance flow from the client. If marked as **true**, the VPN client attempts to communicate with Azure AD to get a certificate to use for authentication. The VPN should be set up to use certificate authentication and the VPN server must trust the server returned by Azure AD.
|
||||
- **Sso**: nodes under SSO can be used to choose a certificate different from the VPN authentication certificate for Kerberos authentication in the case of device compliance.
|
||||
- **Sso**: entries under SSO should be used to direct the VPN client to use a certificate other than the VPN authentication certificate when accessing resources that require Kerberos authentication.
|
||||
- **Sso/Enabled**: if this field is set to **true**, the VPN client looks for a separate certificate for Kerberos authentication.
|
||||
- **Sso/IssuerHash**: hashes for the VPN client to look for the correct certificate for Kerberos authentication.
|
||||
- **Sso/Eku**: comma-separated list of Enhanced Key Usage (EKU) extensions for the VPN client to look for the correct certificate for Kerberos authentication.
|
||||
@ -79,8 +77,7 @@ Two client-side configuration service providers are leveraged for VPN device com
|
||||
- Upon request, forwards the Health Attestation Certificate (received from HAS) and related runtime information to the MDM server for verification
|
||||
|
||||
>[!NOTE]
|
||||
>Enabling SSO is not necessarily required unless you want VPN users to be issued Kerberos tickets to access on-premises resources using a certificate issued by the on-premises CA; not the cloud certificate issued by AAD.
|
||||
|
||||
>Currently, it is required that certificates be issued from an on-premises CA, and that SSO be enabled in the user’s VPN profile. This will enable the user to obtain Kerberos tickets in order to access resources on-premises. Kerberos currently does not support the use of Azure AD certificates.
|
||||
|
||||
## Client connection flow
|
||||
The VPN client side connection flow works as follows:
|
||||
@ -89,7 +86,7 @@ The VPN client side connection flow works as follows:
|
||||
|
||||
When a VPNv2 Profile is configured with \<DeviceCompliance> \<Enabled>true<\/Enabled> the VPN client uses this connection flow:
|
||||
|
||||
1. The VPN client calls into Windows 10’s AAD Token Broker, identifying itself as a VPN client.
|
||||
1. The VPN client calls into Windows 10’s Azure AD Token Broker, identifying itself as a VPN client.
|
||||
2. The Azure AD Token Broker authenticates to Azure AD and provides it with information about the device trying to connect. The Azure AD Server checks if the device is in compliance with the policies.
|
||||
3. If compliant, Azure AD requests a short-lived certificate
|
||||
4. Azure AD pushes down a short-lived certificate to the Certificate Store via the Token Broker. The Token Broker then returns control back over to the VPN client for further connection processing.
|
||||
|
||||
Reference in New Issue
Block a user