
Nous le savons tous les mots de passe sont trops nombreux et occasionnent des appels au support lorqu’ils expirent ou lorsqu’ils sont oubliés.
Dans notre cas nous allons tenter de mettre en place via les régles d’accés conditionnels cette fonctionnalité en prenant en compte deux aspects
- L’aspect lié à la configuration de l’environnement Azure
- L’expérience utilisateur
l’objectif est que nos utilisateur n’aient plus de mot de passe et qu’ils utilisent systématiquement le passwordless.
Pour cela rendez vous naturellement sur le site de documentation de Microsoft pour savoir comment il faut procéder.
Tout d’abord avant de mettre en place le passwordless, il faut que l’utilisateur dispose d’un smartphone, d’un plan d’appel lui permettant de valider la connexion à son compte 0365 .
IOS ou Android ?
La deja premier probléme , si on regarde attentivement la documentation Microsoft mieux vaut utiliser un téléphone IOS plutot que Android. Car sous IOS, il est possible de gérer plusieurs compte d’authentification (toujours d’aprés la documentation Microsoft). Comme rien n’est précisé concernant Android, cela laisse supposer que cela n’est pas possible sur Android. Par conséquent si un utilisateur 0365 Android , posséde déja Microsoft Authenticator sur le téléphone avec un compte en password less comme hotmail.com la documentation plus loin confirme que la gestion multiple sous Android n’est pas encore possible.
les prérequis
Pour utiliser la connexion téléphonique sans mot de passe avec Microsoft Authenticator, les conditions préalables suivantes doivent être remplies :
- Recommandé : Azure AD Multi-Factor Authentication, avec les notifications push autorisées comme méthode de vérification. Les notifications push envoyées à votre smartphone ou à votre tablette permettent à l’application Authenticator d’empêcher l’accès non autorisé aux comptes et de stopper les transactions frauduleuses. L’application Authenticator génère automatiquement des codes lorsqu’elle est configurée pour envoyer des notifications push. L’utilisateur dispose d’une méthode de connexion de secours même si son appareil n’est pas connecté.
- La dernière version de Microsoft Authenticator est installée sur les appareils fonctionnant sous iOS ou Android.
- Pour Android, l’appareil qui exécute Microsoft Authenticator doit être enregistré auprès d’un utilisateur individuel. Nous travaillons activement à l’activation de comptes multiples sur Android.
- Pour iOS, l’appareil doit être enregistré auprès de chaque locataire où il est utilisé pour se connecter. Par exemple, l’appareil suivant doit être enregistré auprès de Contoso et de Wingtiptoys pour permettre à tous les comptes de se connecter :
- balas@contoso.com
- balas@wingtiptoys.com et bsandhu@wingtiptoys
- Pour utiliser l’authentification sans mot de passe dans Azure AD, activez d’abord l’expérience d’enregistrement combiné, puis activez les utilisateurs pour la méthode sans mot de passe.
Etape 1 : Activer les méthodes d’authentification par téléphone sans mot de passe
Bon si on suit la documentation vous n’allez pas trouver Sécurité>Méthodes d’authentification>Stratégies. Cela est du au fait que Microsoft change les interfaces et que la documentation n’est pas mise à jour .
Pour trouver l’option il faut (je pense) aller dans Azure AD portail puis Protection, puis Security Center puis authentication methods
Pour nos propres besoins nous l’avons activé pour un groupe de sécurité uniquement comme le montre les deux figures suivantes :


Tout d’abord nous avons mis en place pour des raisons de sécurité une régle d’accès conditionnels qui a pour but d’obliger les utilisateurs à se connecter en Passwordlesss pour pouvoir accéder à leur environnement Microsoft Teams
Cette règle d’accés conditionnels est détaillée ici

Seulement, cette régle ne peut pas être mise en place avant que les utilisateurs s’inscrivent en tant qu’utilisateur passwordLess. Car sinon la regle d’accés conditionnels refusera la connexion. Nous avons donc positionné cette regle d’accés conditionnel en report only Comme ca, nous serons me mesure de voir qui passe la règle et qui ne la passe pas.
Passons coté utilisateur si vous le voulez bien
Pour les besoins du test nous avons monté un machine Windows 10 dans Azure qui fera office de poste client. Nous allons utiliser un utilisateur « test-UnifiedUser » pour voir comment il peut s’enregistrer en tant que passwordless user.
Ce dernier posséde un licence E5 avec toutes les fonctionnalités activées.
Que nous dis la documentation Microsoft ?
Etape 2 : Enregistrement des utilisateurs

Ok!, nous prenons notre téléphone android et commencons la procédure d’enregistrement précisée plus haut.
Nous lancons Microsoft Authenticator
- sélectionnons ajouter un compte / Compte professionnel ou Scolaire puis
- l’option Se connecter
- Nous rentrons le compte test-UnifiedUser puis le mot de passe
- puis l’application nous demande de Terminer la configuration sur un navigateur Web
- Nous ouvrons le navigateur en cliquant sur le bouton Ouvrir le navigateur
- Le navigateur nous demande ensuite de nous connecter une nouvelle fois …..
- Nous rentrons une nouvelle fois le compte test-UnifiedUser puis le mot de passe
- La l’application étrangement nous demande de changer le mot de passe ce que nous faisons
- L’application nous demande ensuite si nous voulons rester connecté nous répond oui.
- l’explorateur nous affiche ensuite ce message d’erreur
- There was a problém processing your request

bon pour une premiére expérience ce n’est pas génial. mais on a peut être raté quelque chose. Pour cela on va examiner les journaux de connexion de cet utilisateur . Peut être que la connexion lui a été refusée par une règle d’accès conditionnel. Pour regarder les journaux de connexion il faut s’armer de patience car ils ne sont pas rafraichis tout de suite.

si l’on regarde les journaux on trouve une erreur à 12:05:48
et si l’on regarde dans le détail on voit que c’est la régle en report only qui refuse la connexion

Pourquoi une regle en report only refuse la connexion qu’elle est censée laisser passer ?.
Tout simplement parce qu’elle ne s’est pas encore mise à jour après 15 minutes. Comment savoir quand elle est mise à jour par Azure. Personnellement je ne sais pas. Il faut attendre. Nous l’avons modifier à 11h50 et nous avons été « jeté » par la méme règle à 12:05 soit 15 minutes après sa mise à jour.
Nous retentons notre chance sur le téléphone à 12h22 soit 32 minutes aprés le changement de la régle .
nous lancons L’application authenticator (12h25)
- sélectionnons ajouter un compte / Compte professionnel ou Scolaire puis
- l’option Se connecter
- Nous rentrons le compte test-UnifiedUser puis le mot de passe
- puis l’application nous demande de Terminer la configuration sur un navigateur Web
- l’application nous informe que More information Required
- your Organisation needs more informations to keep your account secure. (ca sent bon 😉
- nous cliquons sur Next
- l’application nous demande notre mot de passe…., nous le rentrons puis le browser semble allez sur MySignins.microsoft.com /
- ou nous attend un belle page blanche

Nous tentons de rafraichir la page…..
et la nous obtenons cette page (enfin 😉

Nous rentrons notre numéro de téléphone et recevons le SMS. Cette fois ci le téléphone est bien associé au compte comme le montre l’écran suivant :

ETAPE 3 : Test de la connexion utilisateur
Pour ce faire, nous allons utiliser le compte utilisateur en question et tenter de se connecter à Teams .microsoft.com. Si le téléphone est bien associé au compte utilisateur ce n’est pas pour cela que le passwordlesss est activé. Nous avons pu nous connecter à Teams.microsoft.com sans que nous soit demandé une quelconque vérification par téléphone.
Une autre configuration est donc a faire . Il s’agit d’activer la connexion par téléphone.
Etape 4 : Activation de la connexion par téléphone.
Pour ce faire voici ce que nous dit la documentation Microsoft

En ouvrant l’application authenticator nous avons un message d’erreur nous informant que l’inscription par téléphone a échouée. Nous constatons que le compte ajouté ne figure pas dans la liste des comptes authenticator. Nous décidons de l’ajouter une nouvelle fois……
nous lancons L’application authenticator (14h09)
- sélectionnons ajouter un compte / Compte professionnel ou Scolaire puis
- l’option Se connecter
- Nous rentrons le compte test-UnifiedUser puis le mot de passe
- puis l’application nous demande de Terminer la configuration par un code SMS
- l’application nous informe que More information Required
- Nous validons la connexion et la l’appareil nous demande d’activer la connexion par téléphone.
Quelques photos d’écran pas de très bonne qualité mais l’essentiel y est

Etape 5 : Test de la fonction passwordless
Nous allons tenter de nous connecter à Teams.microsoft.com via un explorateur Web Edge en utilisant une fenêtre en navigation privée
la à notre grand surprise le navigateur nous demande ….. le mot de passe

Nous le rentrons pour voir.. et la nous pouvons accéder à Teams.
Décidément le passwordless c’est loin d’être passwordlessEasy !!. retour à la documention Microsoft..
Bon en relisant la documentation et en faisant d’autres tests , l’utilisateur peut à la connexion choisir si il veut continuer à utiliser le mot de passe ou bien utiliser son application Microsoft authenticator. nous testons l’application Microsoft et cela fonctionne

On progresse nous avons désormais un utilisateur passwordless avec password. 😉
Maintenant cherchons comment nous allons forcer l’utilisateur à ne plus utiliser de mot de passe car l’objectif primaire est qu’il ne possède plus de mot de passe.!!
« password is dead » a dit un jour un certain B.Gates.
Retour à la documentation
