Users will not be able to sign-in to Azure AD with on-premises credentials…

Lorsque vous décidez de partir vers le cloud et que vous choisissez Office 365, l’un des premiers outils que vous allez probablement installer est Azure AD Connect. Ce dernier vous permet de synchroniser votre Active Directory local avec Azure Active Directory.

L’un des premiers pré-requis que vous devez mettre en place pour que tout se passe bien durant cette phase de transition est de disposer d’un domaine dit routable.

Il est en effet assez rare pour une entreprise de disposer d’un domaine Active Directory local qui porte le même nom que le domaine public de messagerie que vous utilisez pour vos emails.

Par exemple, vous pouvez disposez d’un domaine AD local dont le nom est entreprise.local tandis que votre domaine de messagerie sera par exemple entreprise.fr. Or, entreprise.local ne sera pas routable sur Internet cela signifie que ce n’est pas un domaine que vous pouvez avoir sur Internet (pour la simple et bonne raison que le TLD .local n’existe pas). Mais parfois, le problème est plus simple : votre domaine Active Directory (local) est peut-être juste différent de votre domaine de messagerie.

Si c’est votre cas et que vous exécutez Azure AD Connect dans ce scénario, alors vous aurez probablement le message d’alerte suivant :

Ajoutons à cela que nous ne voulons pas avoir à gérer pour nos utilisateurs un identifiant et mot de passe qui soit différent pour l’interne et pour le Cloud. Il faut donc trouver une solution…

En réalité, c’est un problème très simple – que beaucoup d’entreprises ont rencontré lors de leur transition vers Office 365.

Pour le résoudre, procédez simplement comme suit :

• Ajoutez et vérifiez votre domaine public au sein de votre tenant Office 365. Cela peut se faire depuis votre portail Office 365 ou bien depuis Azure Active Directory en allant dans le sous-section « Custom domain names« . Si ce n’est pas déjà fait, vous devrez créer une entrée DNS pour attester que vous êtes bien le propriétaire de ce nom de domaine.

• Ajoutez votre domaine public comme suffixe UPN additionnel au sein de votre Active Directory local. Pour ce faire, connectez-vous sur l’un de vos Domain Controller puis lancez l’outil Active Directory Domains and Trust. Effectuez un clic droit sur Active Directory Domains and trust et dans la boîte de dialogue qui s’ouvre vous allez pouvoir ajouter votre domaine public (que vous venez de vérifier sur Office 365).

Dans mon cas, mon domaine interne est akril.cloud tandis que mes utilisateurs doivent pouvois s’identifier avec akril.co.

• Il ne reste alors plus qu’à forcer le changement de domaine par défaut pour les utilisateurs que vous envisagez de synchroniser avec votre serveur AAD Connect. Vous pouvez le faire manuellement avec le menu déroulant sur chaque compte utilisateur… ou bien en PowerShell sur tous vos utilisateurs d’un seul coup. Pour la seconde option, je vous encourage à utiliser le script suivant.

Désormais, vos utilisateurs pourront s’authentifier avec le même domaine sur le portail Office 365 ou pour accéder à n’importe quels services SaaS interconnectés avec votre Azure AD. Et d’un point de vue de l’infrastructure locale, il n’y aura pas non plus de changement pour démarrer sa machine. Bref, aucun impact ! 😉