Office 365 – Les limites de l’identifiant de connexion alternatif
Intune
Je n’ai pas beaucoup de contexte sur celui-ci, sauf qu’il est là depuis la sortie de la fonctionnalité originale. Les notes ont toujours dit : « Si vous êtes un client Intune utilisant le connecteur SCCM, il peut y avoir une configuration supplémentaire requise ». Cela me dit qu’il y a une sorte de problème, mais peut-être que quelqu’un de plus impliqué dans Intune peut aider à remplir les détails.
Exchange Hybrid Autodiscover : Domain Joined
Le principal problème ici est le décalage entre les informations d’identification valides sur site et les informations d’identification valides dans le cloud. Dans un environnement Exchange Hybrid, les enregistrements Autodiscover pointent toujours vers l’Exchange sur site où un utilisateur s’authentifie et effectue ensuite une recherche Autodiscover. Si l’utilisateur possède une boîte aux lettres dans le nuage, il est alors redirigé vers Office 365 où une autre recherche Autodiscover est effectuée, avec authentification, puis la réponse Autodiscover est renvoyée. Le problème qui se produit est que des informations d’identification différentes sont nécessaires pour les machines sur site (qui ne savent rien de l’ID de connexion alternatif) et le cloud (qui s’attend à l’ID de connexion alternatif).
Pour les machines jointes au domaine, les informations d’identification connectées sont suffisantes pour s’authentifier à l’Exchange sur site, puis l’utilisateur reçoit l’invite unique habituelle pour s’authentifier à Exchange Online. La seule différence que vous remarquerez ici est que l’invite pour Office 365 a les mauvaises informations d’identification peuplées dans la boîte de connexion et vous devez entrer votre identifiant de connexion alternatif.
Exchange Hybrid Autodiscover : Non-Domain Joined
Pour les machines non jointes à un domaine, l’utilisateur se voit présenter des invites à la fois sur site et dans le cloud sans savoir à quelle plateforme l’invite correspond. Le résultat est que, bien qu’il soit techniquement possible de naviguer dans les invites de connexion, il est peu probable que vos utilisateurs sachent quelles informations d’identification fournir lors de quelle invite.
Là où cela devient vraiment difficile de savoir quel compte utiliser, c’est lorsque vous avez des dossiers publics sur site que vous avez rendus accessibles par des utilisateurs de boîtes aux lettres dans le cloud. La boîte aux lettres proxy pour les dossiers publics sur site est renvoyée dans le cadre de la réponse Autodiscover du cloud et à un moment donné, lors de l’ouverture d’Outlook, vous êtes censé entrer les informations d’identification sur site. Je dirais que cette configuration est presque inutilisable.
Exchange Hybrid Autodiscover : Mac
Lorsque vous utilisez le nouveau « Outlook pour Mac », la non-concordance des informations d’identification de l’identifiant de connexion alternatif fera échouer Outlook lors de la configuration automatique du compte. L’utilisateur devra configurer manuellement Outlook pour utiliser la cible de « https://outlook.office365.com/EWS/Exchange.asmx ».
Office ProPlus
Le comportement ici est quelque peu étrange. Lorsqu’un utilisateur utilise un identifiant de connexion alternatif, Office ProPlus s’installe et s’affiche activé sous le compte de cet utilisateur dans le cloud, cependant dans les applications locales, il vous montrera connecté sous votre UPN sur site.
Le résultat est que vous ne verrez pas les liens vers votre OneDrive for Business dans les applications Office et le client de synchronisation OneDrive for Business ne sera pas configuré. Bien que vous soyez en mesure de vous déconnecter de l’UPN sur site et de vous connecter avec votre identifiant de connexion alternatif, je me demande si Office ProPlus ne passerait pas en » mode de fonctionnalité réduite » après un certain temps si vous restez connecté avec le compte sur site.
Remote Connectivity Analyzer
Non pas que ce soit un problème critique, mais le test Autodiscover de Remote Connectivity Analyzer ne sait pas comment gérer Alternate Login ID avec Exchange Hybrid en raison de l’invite de double authentification.
Azure Application Proxy
Comme l’a noté le commentateur ci-dessous, le nouveau Azure Application Proxy comporte une note de bas de page indiquant : » Les UPN dans Azure Active Directory doivent être identiques à ceux de votre Active Directory sur site pour que la préauthentification fonctionne. Assurez-vous que votre Azure Active Directory est synchronisé avec votre Active Directory sur site. » Cela signifie que Alternate Login ID n’est pas compatible dans cette situation.
Fournisseurs d’identité tiers (IDP)
Microsoft a un programme pour les IDP tiers testés appelé « Works with Office 365 – Identity ». Une partie de ce programme est une liste de fournisseurs testés ainsi que toutes les exceptions qui pourraient être connues avec ces produits. Dans les notes de ce programme, il est indiqué que « l’utilisation de l’ouverture de session par un autre identifiant que l’UPN n’est pas non plus testée dans ce programme ». Donc, fondamentalement, votre kilométrage peut varier lors de l’utilisation de l’ID de connexion alternatif avec l’un de ces IDP tiers.