Utilisation d'invitations Azure Active Directory B2B Collaboration

Cet article décrit les différentes façons dont les utilisateurs invités peuvent accéder à vos ressources, et le processus de consentement qu’ils vont rencontrer. Si vous envoyez un e-mail d’invitation à l’invité, l’invitation comprend un lien que l’invité peut utiliser pour obtenir l’accès à votre application ou portail. L’e-mail d’invitation n’est qu’une des possibilités permettant aux invités d’obtenir l’accès à vos ressources. Comme alternative, vous pouvez ajouter des invités à votre annuaire et leur donner un lien direct vers le portail ou l’application que vous souhaitez partager. Quelle que soit la méthode qu’ils utilisent, les invités sont guidés dans un processus de consentement initial. Ce processus garantit que vos invités sont d’accord avec les conditions de confidentialité, et qu’ils acceptent les conditions d’utilisation que vous avez définies.

Lorsque vous ajoutez un utilisateur invité à votre annuaire, le compte d’utilisateur invité présente un état de consentement (affichable dans PowerShell) qui est initialement défini sur PendingAcceptance. Ce paramètre est maintenu jusqu’à ce que l’invité accepte votre invitation et approuve votre politique de confidentialité ainsi que vos conditions d’utilisation. Après cela, l’état de consentement passe à Accepté, et les pages de consentement ne sont plus présentées à l’invité.

Important

  • À partir du 12 juillet 2021, si les clients B2B d’Azure AD configurent de nouvelles intégrations Google pour une utilisation avec l’inscription en libre-service pour leurs applications métier ou personnalisées, l’authentification avec les identités Google ne fonctionnera pas tant que les authentifications ne sont pas déplacées vers les vues web du système. Plus d’informations
  • À partir du 30 septembre 30, 2021, Google déprécie la prise en charge de la connexion aux vues web intégrée. Si vos applications authentifient les utilisateurs avec une vue Web incorporée et que vous utilisez Google Federation avec Azure AD B2C ou Azure AD B2B pour des invitations utilisateur externes ou une inscription en libre-service, les utilisateurs de Google Gmail ne peuvent pas s’authentifier. Plus d’informations
  • La fonctionnalité de code secret à usage unique par e-mail est désormais activée par défaut pour tous les nouveaux locataires et pour tous les locataires existants où vous ne l’avez pas explicitement désactivée. Quand cette fonctionnalité est désactivée, la méthode d’authentification de secours consiste à inviter les invités à créer un compte Microsoft.

Acceptation et connexion via un point de terminaison commun

Les utilisateurs invités peuvent désormais se connecter à vos applications multilocataires ou à vos applications principales Microsoft via un point de terminaison commun (URL), par exemple https://myapps.microsoft.com. Jusqu’ici, une URL commune redirigeait l’utilisateur invité vers son locataire d’origine au lieu de votre locataire de ressources pour l’authentification. Un lien spécifique au locataire était donc nécessaire (par exemple https://myapps.microsoft.com/?tenantid=<tenant id>). Désormais, l’utilisateur invité peut accéder à l’URL commune de l’application, choisir Options de connexion, puis sélectionner Sign in to an organization (Se connecter à une organisation). L’utilisateur tape ensuite le nom de domaine de votre organisation.

Capture d’écran montrant les points de terminaison courants utilisés pour la connexion.

L’utilisateur est ensuite redirigé vers votre point de terminaison de locataire, où il peut soit se connecter avec son adresse e-mail, soit sélectionner un fournisseur d’identité que vous avez configuré.

Au lieu de l’e-mail d’invitation ou de l’URL commune d’une application, vous pouvez fournir à un invité un lien direct vers votre application ou votre portail. Vous devez d’abord ajouter l’utilisateur invité à votre annuaire par le biais du portail Azure ou de PowerShell. Ensuite, vous pouvez utiliser un des moyens personnalisables de votre choix pour déployer des applications vers les utilisateurs, notamment les liens d’authentification directe. Lorsqu’un invité utilise un lien direct au lieu de l’e-mail d’invitation, il est toujours guidé dans l’expérience de consentement initial.

Notes

Un lien direct est spécifique au locataire. En d’autres termes, il inclut un ID de locataire ou un domaine vérifié pour permettre à l’invité d’être authentifié dans votre locataire, là où se trouve l’application partagée. Voici quelques exemples de liens directs avec contexte de locataire :

  • Panneau d’accès des applications : https://myapps.microsoft.com/?tenantid=<tenant id>
  • Panneau d’accès des applications pour un domaine vérifié : https://myapps.microsoft.com/<;verified domain>
  • Portail Azure : https://portal.azure.com/<tenant id>
  • Application individuelle : voir comment utiliser un lien d’authentification directe

Il existe certains cas où l’e-mail d’invitation est recommandé par rapport à un lien direct. Si ces cas particuliers sont importants pour votre organisation, nous vous conseillons d’inviter les utilisateurs par l’intermédiaire de méthodes qui envoient toujours l’e-mail d’invitation :

  • Parfois, l’objet utilisateur invité n’a pas d’adresse e-mail en raison d’un conflit avec un objet contact (par exemple, un objet contact Outlook). Dans ce cas, l’utilisateur doit cliquer sur l’URL d’acceptation de l’e-mail d’invitation.
  • L’utilisateur peut se connecter avec un alias de l’adresse e-mail via laquelle il a été invité (un alias est une adresse e-mail supplémentaire associée à un compte de courrier). Dans ce cas, l’utilisateur doit cliquer sur l’URL d’acceptation de l’e-mail d’invitation.

Acceptation via l’e-mail d’invitation

Lorsque vous ajoutez un utilisateur invité à votre annuaire en utilisant le portail Azure, un e-mail d’invitation est envoyé à l’invité dans le processus. Vous pouvez également choisir d’envoyer des e-mails d’invitation lorsque vous utilisez PowerShell pour ajouter des utilisateurs invités à votre annuaire. Voici une description de l’expérience de l’invité lorsqu’il accepte le lien dans l’e-mail.

  1. L’invité reçoit un e-mail d’invitation qui est envoyé depuis Invitations Microsoft.
  2. L’invité sélectionne Accepter l’invitation dans l’e-mail.
  3. L’invité utilise ses propres informations d’identification pour se connecter à votre répertoire. Si l’invité n’a pas de compte qui peut être fédéré à votre annuaire et que la fonctionnalité Code secret e-mail à usage unique (OTP) n’est pas activée, l’invité est invité à créer un MSA personnel. Pour plus d’informations, reportez-vous au flux d’acceptation d’invitation.
  4. L’invité est guidé tout au long de l’expérience de consentement décrite ci-dessous.

Limitation d’échange avec objet contact en conflit

Parfois, l’e-mail de l’utilisateur externe invité peut être en conflit avec un Objet de contact existant, ce qui entraîne la création de l’utilisateur invité sans proxyAddress. Cette limitation connue empêche les utilisateurs invités d’échanger une invitation via un lien direct à l’aide d’un fournisseur d’identité SAML/WS-FED, de MSA, de la fédération Google ou d’un compte à Code secret à usage unique d’e-mail.

Toutefois, les scénarios suivants devraient continuer à fonctionner :

Pour débloquer des utilisateurs qui ne peuvent pas échanger une invitation en raison d’un conflit avec un Objet de contact, procédez comme suit :

  1. Supprimez l’objet de contact conflictuel.
  2. Supprimez l’utilisateur invité dans le portail Azure (la propriété « Invitation acceptée » de l’utilisateur doit être dans un état d’attente).
  3. Réinvitez l’utilisateur.
  4. Attendez que l’utilisateur accepte l’invitation.
  5. Rajoutez l’e-mail de contact de l’utilisateur dans Exchange et toutes les listes de distribution dont il doit faire partie.

Flux d’acceptation d’invitation

Quand un utilisateur clique sur le lien Accepter l’invitation dans un e-mail d’invitation, Azure AD accepte automatiquement l’invitation en fonction du flux d’acceptation, comme illustré ci-dessous :

Capture d’écran montrant le diagramme du flux d’acceptation.


  1. Azure AD effectue une découverte basée sur l’utilisateur pour déterminer si l’utilisateur existe déjà dans un locataire Azure AD managé. (Les comptes Azure AD non managés ne peuvent plus être utilisés pour l’acceptation.) Si le nom d’utilisateur principal (UPN) de l’utilisateur correspond à un compte Azure AD existant et à un MSA personnel, l’utilisateur est invité à choisir le compte avec lequel il souhaite procéder à l’acceptation.

  2. Si un administrateur a activé la fédération SAML/WS-Fed IdP, Azure AD vérifie si le suffixe de domaine de l’utilisateur correspond au domaine d’un fournisseur d’identité SAML/WS-Fed configuré et redirige l’utilisateur vers le fournisseur d’identité préconfiguré.

  3. Si un administrateur a activé la fédération Google, Azure AD vérifie si le suffixe de domaine de l’utilisateur est gmail.com ou googlemail.com et redirige l’utilisateur vers Google.

  4. Le processus d’acceptation vérifie si l’utilisateur dispose d’un MSA personnel. Si l’utilisateur a déjà un MSA existant, il se connecte avec son MSA existant.

  5. Une fois que le répertoire de base de l’utilisateur est identifié, l’utilisateur est envoyé au fournisseur d’identité correspondant pour se connecter.

  6. Si aucun annuaire de base n’est trouvé et que la fonctionnalité de code secret à usage unique par e-mail est activée pour les invités, un code secret est envoyé à l’utilisateur via l’e-mail invité. L’utilisateur récupère et entre ce code secret dans la page de connexion Azure AD.

  7. Si aucun annuaire de base n’est trouvé et que la fonctionnalité de code secret à usage unique par e-mail pour les invités est désactivée, l’utilisateur est invité à créer un MSA consommateur avec l’e-mail invité. Nous prenons en charge la création d’un MSA avec des e-mails professionnels dans des domaines qui ne sont pas vérifiés dans Azure AD.

  8. Après s’être authentifié auprès du fournisseur d’identité approprié, l’utilisateur est redirigé vers Azure AD pour terminer l’expérience de consentement.

Lorsqu’un invité se connecte pour la première fois à une ressource d’une organisation partenaire, l’expérience de consentement suivante lui est présentée. Ces pages de consentement sont affichées à l’invité uniquement après la connexion, et elles ne sont pas affichées du tout si l’utilisateur les a déjà acceptées.

  1. L’invité passe en revue la page Révision des autorisations décrivant la déclaration de confidentialité de l’organisation qui invite. Pour continuer, l’utilisateur doit Accepter l’utilisation de ses informations conformément à la politique de confidentialité de l’organisation invitante.

    Capture d’écran montrant la page Passer en revue les autorisations.

    Notes

    Pour plus d’informations sur la manière dont vous pouvez, en tant qu’administrateur de locataire, créer un lien vers la déclaration de confidentialité de votre organisation, consultez le Guide pratique pour ajouter les informations de confidentialité de votre organisation dans Azure Active Directory.

  2. Si les conditions d’utilisation sont configurées, l’invité ouvre et passe en revue les conditions d’utilisation, puis il sélectionne Accepter.

    Capture d’écran montrant les nouvelles conditions d’utilisation.

    Vous pouvez configurer les conditions d’utilisation dans Identités externes>conditions d’utilisation.

  3. Sauf indication contraire, l’invité est redirigé vers le panneau d’accès des applications qui liste les applications auxquelles l’invité peut accéder.

    Capture d’écran montrant le panneau d’accès des applications.

Dans votre annuaire, la valeur de Invitation acceptée de l’invité passe à Oui. Si un MSA a été créé, la Source de l’invité affiche Compte Microsoft. Pour plus d’informations sur les propriétés du compte d’utilisateur invité, consultez Propriétés d’un utilisateur B2B Collaboration Azure AD. Si vous voyez une erreur qui requiert le consentement administrateur lors de l’accès à une application, consultez comment accorder le consentement administrateur aux applications.

Étapes suivantes