Share via

Régir des applications basées sur Active Directory locales (Kerberos) en tirant parti de Gouvernance des ID Microsoft Entra

  • Article

Important

La préversion publique de l'écriture différée de groupe V2 dans Microsoft Entra Connect Sync ne sera plus disponible après le 30 juin 2024. Cette fonctionnalité ne sera plus disponible à cette date et vous ne serez plus pris en charge dans Connect Sync pour approvisionner des groupes de sécurité cloud sur Active Directory.

Nous proposons une fonctionnalité similaire dans Microsoft Entra Cloud Sync appelée Approvisionnement de groupe vers Active Directory que vous pouvez utiliser au lieu d'Écriture différée de groupe v2 pour approvisionner des groupes de sécurité cloud sur Active Directory. Nous travaillons à améliorer cette fonctionnalité dans Cloud Sync, ainsi que d'autres nouvelles fonctionnalités que nous développons dans Cloud Sync.

Les clients qui utilisent cette fonctionnalité d'évaluation dans Connect Sync doivent basculer leur configuration de Connect Sync vers Cloud Sync. Vous pouvez choisir de procéder à la migration de toute votre synchronisation hybride vers Cloud Sync (si elle prend en charge vos besoins). Vous pouvez également exécuter Cloud Sync côte à côte et déplacer uniquement l'approvisionnement de groupes de sécurité du cloud vers Active Directory vers Cloud Sync.

Pour les clients qui approvisionnent des groupes Microsoft 365 dans Active Directory, vous pouvez continuer à utiliser l'Écriture différée de groupe v1 pour cette capacité.

Vous pouvez évaluer le déplacement exclusivement vers Cloud Sync à l’aide de l’assistant de synchronisation des utilisateurs.

Scénario : gérer des applications locales avec des groupes Active Directory configurés et gérés dans le cloud. La synchronisation cloud Microsoft Entra vous permet de régir entièrement les attributions d’applications dans AD tout en tirant parti des fonctionnalités de la Gouvernance des ID Microsoft Entra pour contrôler et corriger les demandes liées à l’accès.

Avec la publication de l’agent d’approvisionnement 1.1.1370.0, la synchronisation cloud permet désormais d’approvisionner des groupes directement dans votre environnement Active Directory local. Vous pouvez utiliser des fonctionnalités de gouvernance des identités pour régir l’accès aux applications AD, par exemple en incluant un groupe dans un package d’accès de gestion des droits d’utilisation.

Schéma conceptuel de la fourniture de groupe de Microsoft Entra Cloud Sync à AD.

Regarder la vidéo d’écriture différée du groupe

Pour obtenir une vue d’ensemble de l’approvisionnement de groupes de synchronisation cloud sur Active Directory et de ce qu’il peut faire pour vous, consultez la vidéo ci-dessous.

Prérequis

Les conditions préalables suivantes sont requises pour mettre en œuvre ce scénario.

  • Un compte Microsoft Entra avec au moins un rôle Administrateur hybride.
  • Un environnement Active Directory Domain Services local avec le système d’exploitation Windows Server 2016 ou version ultérieure.
    • Obligatoire pour l’attribut de schéma AD – msDS-ExternalDirectoryObjectId.
  • Un agent d’approvisionnement avec la version de build 1.1.1367.0 ou ultérieure.

Remarque

Les autorisations pour le compte de service sont attribuées uniquement lors de l’installation propre. Si vous effectuez une mise à niveau à partir de la version précédente, les autorisations doivent être affectées manuellement à l’aide de l’applet de commande PowerShell :

$credential = Get-Credential 

 Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -TargetDomainCredential $credential

Si les autorisations sont définies manuellement, vous devez vous assurer de disposer des propriétés Lire, Écrire, Créer et Supprimer toutes les propriétés pour tous les objets de groupes et d’utilisateurs descendants.

Ces autorisations ne sont pas appliquées aux objets AdminSDHolder par défaut

Applets de commande gMSA PowerShell de l’agent d’approvisionnement Microsoft Entra

  • L’agent d’approvisionnement doit être capable de communiquer avec un ou plusieurs contrôleurs de domaine sur les ports TCP/389 (LDAP) et TCP/3268 (Global Catalog).
    • Obligatoire pour la recherche dans le catalogue global afin de filtrer les références d’appartenance non valides.
  • Microsoft Entra Connect avec la version de build 2.2.8.0 ou ultérieure.
    • Obligatoire pour prendre en charge la synchronisation de l’appartenance des utilisateurs locaux à l’aide de Microsoft Entra Connect.
    • Obligatoire pour synchroniser AD:user:objectGUID avec Microsoft Entra ID:user:onPremisesObjectIdentifier.

Groupes pris en charge

Pour ce scénario, seuls les groupes suivants sont pris en charge :

  • seuls les groupes de sécurité créés sur le cloud sont pris en charge
  • ces groupes peuvent disposer d’une appartenance attribuée ou dynamique
  • ces groupes peuvent contenir uniquement des utilisateurs synchronisés locaux et/ou des groupes de sécurité créés par le cloud
  • les comptes d’utilisateur locaux synchronisés et membres de ce groupe de sécurité créé dans le cloud peuvent provenir du même domaine ou inter-domaine, mais ils doivent tous provenir de la même forêt
  • ces groupes sont réécrits avec la portée des groupes AD universel. Votre environnement local doit prendre en charge l’étendue du groupe universel
  • les groupes d’une taille supérieure à 50 000 membres ne sont pas pris en charge
  • chaque groupe imbriqué enfant direct compte comme un membre dans le groupe de référencement

Scénarios pris en charge

Les sections suivantes décrivent les scénarios pris en charge avec la configuration de groupes de synchronisation cloud.

Configuration des scénarios pris en charge

Vous pouvez contrôler si un utilisateur est en mesure de se connecter à une application Active Directory qui utilise l’authentification Windows à l’aide du proxy d’application et d’un groupe de sécurité Microsoft Entra ID. Si une application vérifie elle-même l’appartenance aux groupes AD d’un utilisateur, via Kerberos ou LDAP, vous pouvez utiliser le provisionnement de groupes de synchronisation cloud pour vous assurer qu’un utilisateur AD possède ces appartenances de groupe avant son accès aux applications.

Les sections suivantes décrivent deux scénarios possibles pris en charge avec la configuration de groupes de synchronisation cloud. Les scénarios possibles sont destinées à garantir que les utilisateurs affectés à l’application appartiennent à un groupe lorsqu’ils s’authentifient auprès de l’application.

  • Créer un groupe et mettre à jour l’application, si elle existe déjà, pour vérifier le nouveau groupe, ou
  • Créer un groupe et mettre à jour les groupes existants, que l’application vérifiait, pour inclure le nouveau groupe en tant que membre

Avant de commencer, vérifiez que vous êtes administrateur de domaine dans le domaine où l’application est installée. Vérifiez que vous pouvez vous connecter à un contrôleur de domaine ou que vous disposez des outils d’administration de serveur distant pour les services de domaine Active Directory (AD DS) sur votre PC Windows.

Configuration de la nouvelle option de groupes

Dans cette option de scénario, vous allez mettre à jour l’application pour rechercher l’identificateur de sécurité, le nom ou le nom unique des nouveaux groupes créés par la configuration de groupes de synchronisation cloud. Ce scénario peut s’appliquer dans ces cas de figure :

  • déploiements pour les nouvelles applications connectées à AD DS pour la première fois.
  • nouvelles cohortes d’utilisateurs accédant à l’application.
  • pour la modernisation des applications, afin de réduire la dépendance vis-à-vis des groupes AD DS existants. Les applications qui vérifient actuellement l’appartenance au groupe Domain Admins devront être mises à jour pour vérifier également un groupe AD nouvellement créé.

Utilisez les étapes suivantes pour que les applications utilisent de nouveaux groupes.

Créer une application et un groupe

  1. À l’aide du centre d’administration Microsoft Entra, créez une application dans Microsoft Entra ID représentant l’application AD, et configurez l’application pour qu’elle exige l’affectation d’un utilisateur.
  2. Si vous utilisez le proxy d’application pour permettre aux utilisateurs de se connecter à l’application, configurez-le.
  3. Créer un nouveau groupe de sécurité dans Microsoft Entra ID.
  4. Utilisez l’approvisionnement de groupes sur AD pour approvisionner ce groupe sur AD.
  5. Lancez les utilisateurs et ordinateurs Active Directory, puis attendez que le nouveau groupe AD obtenu soit créé dans le domaine AD. Lorsqu’il est présent, enregistrez le nom unique, le domaine, le nom de compte et le SID du nouveau groupe AD.

Configurer une application pour qu’elle utilise un nouveau groupe

  1. Si l’application utilise AD via LDAP, configurez l’application avec le nom unique du nouveau groupe AD. Si l’application utilise AD via Kerberos, configurez l’application avec le SID, ou le nom du domaine et du compte, du nouveau groupe AD.
  2. Créez un package d’accès. Ajoutez l’application de la première étape et le groupe de sécurité de la troisième étape en tant que ressources dans le package d’accès. Configurez une stratégie d’affectation directe dans le package d’accès.
  3. Dans Gestion des droits d’utilisation, affectez les utilisateurs synchronisés qui ont besoin d’accéder à l’application basée sur AD au package d’accès.
  4. Attendez que le nouveau groupe AD soit mis à jour avec les nouveaux membres. À l’aide des utilisateurs et ordinateurs Active Directory, vérifiez que les utilisateurs appropriés sont présents en tant que membres du groupe.
  5. Dans votre analyse de domaine AD, autorisez uniquement le compte gMSA qui exécute l’agent d’approvisionnement, autorisation de modifier l’appartenance dans le nouveau groupe AD.

Vous pouvez maintenant régir l’accès à l’application AD via ce nouveau package d’accès.

Configuration de l’option de groupes existante

Dans cette option de scénario, vous ajoutez un nouveau groupe de sécurité AD en tant que membre de groupe imbriqué d’un groupe existant. Ce scénario s’applique aux déploiements pour les applications qui ont une dépendance codée en dur sur un nom de compte de groupe particulier, un SID ou un nom unique.

L’imbrication de ce groupe dans les applications existantes du groupe AD autorise :

  • Les utilisateurs Microsoft Entra qui sont affectés par une fonctionnalité de gouvernance, puis accèdent à l’application, auront un ticket Kerberos approprié. Ce ticket contient le SID de groupes existants. Cet imbrication est autorisée par les règles d’imbrication de groupe AD.

Si l’application utilise LDAP et suit l’appartenance aux groupes imbriqués, elle verra les utilisateurs Microsoft Entra comme ayant le groupe existant parmi leurs appartenances.

Déterminer l’éligibilité du groupe existant

  1. Lancez les utilisateurs et ordinateurs Active Directory, puis enregistrez le nom unique, le type et l’étendue du groupe AD existant utilisé par l’application.
  2. Si le groupe existant est Domain Admins, Domain Guests, Domain Users, Enterprise Admins, Enterprise Key Admins, Group Policy Creation Owners, Key Admins, Protected Users ou Schema Admins, vous devrez modifier l’application pour utiliser un nouveau groupe, comme décrit ci-dessus, car ces groupes ne peuvent pas être utilisés par la synchronisation cloud.
  3. Si le groupe a une étendue globale, modifiez-le pour que son étendue soit universelle. Un groupe global ne peut pas avoir de groupes universels en tant que membres.

Créer une application et un groupe

  1. Dans le centre d’administration Microsoft Entra, créez une application dans Microsoft Entra ID représentant l’application AD, et configurez l’application pour qu’elle exige l’affectation d’un utilisateur.
  2. Si le proxy d’application est utilisé pour permettre aux utilisateurs de se connecter à l’application, configurez le proxy d’application.
  3. Créer un nouveau groupe de sécurité dans Microsoft Entra ID.
  4. Utilisez l’approvisionnement de groupes sur AD pour approvisionner ce groupe sur AD.
  5. Lancez les utilisateurs et ordinateurs Active Directory, puis attendez que le nouveau groupe AD résultant soit créé dans le domaine AD. Lorsqu’il est présent, enregistrez le nom unique, le domaine, le nom de compte et le SID du nouveau groupe AD.

Configurer une application pour qu’elle utilise un nouveau groupe

  1. À l’aide des utilisateurs et ordinateurs Active Directory, ajoutez le nouveau groupe AD en tant que membre du groupe AD existant.
  2. Créez un package d’accès. Ajoutez l’application de la première étape et le groupe de sécurité de la troisième étape en tant que ressources dans le package d’accès. Configurez une stratégie d’affectation directe dans le package d’accès.
  3. Dans Gestion des droits d’utilisation, affectez les utilisateurs synchronisés qui ont besoin d’accéder à l’application basée sur AD au package d’accès. Cela inclut tous les membres utilisateurs du groupe AD existant qui continueront à avoir besoin d’un accès.
  4. Attendez que le nouveau groupe AD soit mis à jour avec les nouveaux membres. À l’aide des utilisateurs et ordinateurs Active Directory, vérifiez que les utilisateurs appropriés sont présents en tant que membres du groupe.
  5. À l’aide des utilisateurs et ordinateurs Active Directory, supprimez les membres existants, en dehors du nouveau groupe AD, du groupe AD existant.
  6. Dans votre analyse de domaine AD, autorisez uniquement le compte gMSA qui exécute l’agent d’approvisionnement, autorisation de modifier l’appartenance dans le nouveau groupe AD.

Vous pourrez ensuite régir l’accès à l’application AD via ce nouveau package d’accès.

Résolution des problèmes

Un utilisateur membre du nouveau groupe AD et qui se trouve sur un PC Windows déjà connecté à un domaine AD peut avoir un ticket existant émis par un contrôleur de domaine AD qui n’inclut pas la nouvelle appartenance au groupe AD. Cela est dû au fait que le ticket a peut-être été émis avant l’approvisionnement du groupe de synchronisation cloud qui les ajoute au nouveau groupe AD. L’utilisateur ne pourra pas présenter le ticket pour l’accès à l’application, et devra donc attendre que le ticket expire et qu’un nouveau ticket soit émis, ou vider ses tickets, se déconnecter et se reconnecter au domaine. Pour plus d’informations, consultez la commande klist.

Clients existants de l’écriture différée du groupe Microsoft Entra Connect v2

Si vous utilisez l’écriture différée du groupe Microsoft Entra Connect v2, vous devrez passer à l’approvisionnement de synchronisation cloud vers AD avant de pouvoir tirer parti de l’approvisionnement de groupes de synchronisation cloud. Consultez Migrer l’écriture différée de groupe de synchronisation Microsoft Entra Connect V2 vers Synchronisation cloud Microsoft Entra

Étapes suivantes