mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 20:03:40 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Configure federation between Google Workspace and Azure AD
|
||||
description: Configuration of a federated trust between Google Workspace and Azure AD, with Google Workspace acting as an identity provider (IdP) for Azure AD.
|
||||
ms.date: 01/17/2023
|
||||
ms.date: 02/10/2023
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
@ -42,7 +42,7 @@ To test federation, the following prerequisites must be met:
|
||||
1. On the *Service provider details* page
|
||||
- Select the option **Signed response**
|
||||
- Verify that the Name ID format is set to **PERSISTENT**
|
||||
- Depending on how the Azure AD users have been provisioned in Azure AD, you may need to adjust the **Name ID** mapping. For more information, see (article to write).\
|
||||
- Depending on how the Azure AD users have been provisioned in Azure AD, you may need to adjust the **Name ID** mapping.\
|
||||
If using Google auto-provisioning, select **Basic Information > Primary email**
|
||||
- Select **Continue**
|
||||
1. On the *Attribute mapping* page, map the Google attributes to the Azure AD attributes
|
||||
|
||||
@ -27,13 +27,12 @@ Windows Hello for Business cloud Kerberos trust uses *Azure AD Kerberos*, which
|
||||
|
||||
## Azure AD Kerberos and cloud Kerberos 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 a PKI for DC certificates, and requires end-user certificates for certificate trust.\
|
||||
*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 a PKI for DC certificates, and requires end-user certificates for certificate trust.
|
||||
|
||||
*Cloud Kerberos trust* uses *Azure AD Kerberos*, which doesn't require a PKI to request TGTs.
|
||||
Cloud Kerberos trust uses Azure AD Kerberos, which doesn't require a PKI to request TGTs.\
|
||||
With Azure AD Kerberos, Azure AD can issue TGTs for one or more 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 the on-premises Domain Controllers.
|
||||
|
||||
With *Azure AD Kerberos*, Azure AD can issue TGTs for one or more 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 the on-premises Domain Controllers.
|
||||
|
||||
When *Azure AD Kerberos* is enabled in an Active Directory domain, an *Azure AD Kerberos server object* is created in the domain. This object:
|
||||
When Azure AD Kerberos is enabled in an Active Directory domain, an *Azure AD Kerberos server object* is created in the domain. This object:
|
||||
|
||||
- Appears as a Read Only Domain Controller (RODC) object, but isn't associated with any physical servers
|
||||
- Is only used by Azure AD to generate TGTs for the Active Directory domain. The same rules and restrictions used for RODCs apply to the Azure AD Kerberos Server object
|
||||
@ -44,7 +43,7 @@ For more information about how Azure AD Kerberos enables access to on-premises r
|
||||
For more information about how Azure AD Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-azure-ad-kerberos-cloud-kerberos-trust).
|
||||
|
||||
> [!IMPORTANT]
|
||||
> When implementing the *hybrid cloud Kerberos trust* deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1].
|
||||
> When implementing the cloud Kerberos trust deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1].
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -72,9 +71,9 @@ The following scenarios aren't supported using Windows Hello for Business cloud
|
||||
|
||||
## Deployment steps
|
||||
|
||||
Deploying *Windows Hello for Business cloud Kerberos trust* consists of two steps:
|
||||
Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
|
||||
|
||||
1. Set up *Azure AD Kerberos*
|
||||
1. Set up Azure AD Kerberos
|
||||
1. Configure a Windows Hello for Business policy and deploy it to the devices
|
||||
|
||||
### Deploy Azure AD Kerberos
|
||||
@ -85,7 +84,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 Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
After setting up the Azure AD Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO).
|
||||
|
||||
#### [:::image type="icon" source="../../images/icons/intune.svg"::: **Intune**](#tab/intune)
|
||||
|
||||
@ -115,7 +114,7 @@ Windows Hello for Business settings are also available in the settings catalog.
|
||||
|
||||
### Configure cloud Kerberos trust policy
|
||||
|
||||
To configure the *cloud Kerberos trust* policy, follow the steps below:
|
||||
To configure the cloud Kerberos trust policy, follow the steps below:
|
||||
|
||||
1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
|
||||
1. Select **Devices** > **Windows** > **Configuration Profiles** > **Create profile**.
|
||||
@ -155,7 +154,7 @@ You can also create a Group Policy Central Store and copy them their respective
|
||||
|
||||
#### Create the Windows Hello for Business group policy object
|
||||
|
||||
You can configure Windows devices to enable *Windows Hello for Business cloud Kerberos trust* using a Group Policy Object (GPO).
|
||||
You can configure Windows Hello for Business cloud Kerberos trust using a Group Policy Object (GPO).
|
||||
|
||||
1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer objects in Active Directory
|
||||
1. Edit the Group Policy object from Step 1
|
||||
@ -167,7 +166,7 @@ You can configure Windows devices to enable *Windows Hello for Business cloud Ke
|
||||
---
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If the *Use certificate for on-premises authentication* policy is enabled, *certificate trust* will take precedence over *cloud Kerberos trust*. Ensure that the machines that you want to enable *cloud Kerberos trust* have this policy *not configured* or *disabled*.
|
||||
> If the *Use certificate for on-premises authentication* policy is enabled, certificate trust will take precedence over cloud Kerberos trust. Ensure that the machines that you want to enable cloud Kerberos trust have this policy *not configured* or *disabled*.
|
||||
|
||||
## Provision Windows Hello for Business
|
||||
|
||||
@ -195,11 +194,11 @@ This is the process that occurs after a user signs in, to enroll in Windows Hell
|
||||
|
||||
### Sign-in
|
||||
|
||||
Once a user has set up a PIN with *cloud Kerberos trust*, it can be used **immediately** for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
|
||||
Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Hybrid Azure AD joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity.
|
||||
|
||||
## Migrate from key trust deployment model to cloud Kerberos trust
|
||||
|
||||
If you deployed Windows Hello for Business using the *key trust model*, and want to migrate to the *cloud Kerberos trust model*, follow these steps:
|
||||
If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps:
|
||||
|
||||
1. [Set up Azure AD Kerberos in your hybrid environment](#deploy-azure-ad-kerberos)
|
||||
1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy)
|
||||
@ -208,14 +207,14 @@ If you deployed Windows Hello for Business using the *key trust model*, and want
|
||||
> [!NOTE]
|
||||
> For hybrid Azure AD joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.
|
||||
>
|
||||
> Without line of sight to a DC, even when the client is configured to use *cloud Kerberos trust*, the system will fall back to *key trust* if *cloud Kerberos trust* login fails.
|
||||
> Without line of sight to a DC, even when the client is configured to use cloud Kerberos trust, the system will fall back to key trust if cloud Kerberos trust login fails.
|
||||
|
||||
## Migrate from certificate trust deployment model to cloud Kerberos trust
|
||||
|
||||
> [!IMPORTANT]
|
||||
> There is no *direct* migration path from *certificate trust* deployment to *cloud Kerberos trust* deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust.
|
||||
> There is no *direct* migration path from a certificate trust deployment to a cloud Kerberos trust deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust.
|
||||
|
||||
If you deployed Windows Hello for Business using the *certificate trust model*, and want to use the *cloud Kerberos trust model*, you must redeploy Windows Hello for Business by following these steps:
|
||||
If you deployed Windows Hello for Business using the certificate trust model, and want to use the cloud Kerberos trust model, you must redeploy Windows Hello for Business by following these steps:
|
||||
|
||||
1. Disable the certificate trust policy
|
||||
1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy)
|
||||
|
||||
Reference in New Issue
Block a user