Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Azure AD – Déployer le passwordless avec Microsoft Authenticator

Une présentation du passwordless a été faite dans ce post : Azure AD – Présentation du passwordless

Microsoft Authenticator est un logiciel pratique qui permet à la fois de faire du l’authentification multifacteur, mais également de faire du passwordless. Cet article explique comment préparer son environnement pour pouvoir se connecter en passwordless avec Microsoft Authenticator.

Les configurations ci-après sont réalisées avec un compte Global Administrator (GA).

Désactiver le MFA historique

La méthode moderne de faire du MFA est via l’accès conditionnel Azure, il est nécessaire de désactiver le MFA historique pour éviter d’avoir des conflits.

Se connecter successivement à portal.azure.com > Cliquer sur l’icône des 3 traits horizontaux > Azure Active Directory > Users >  Per-user MFA

Pour chaque utilisateur qui doit pouvoir faire du passwordless, il faut désactiver le MFA

 

Combiner les informations de sécurité SSPR et MFA

Les étapes sont décrites dans l’article : Azure – Combiner les informations de sécurité SSPR et MFA

 

(Optionnel) Activer le MFA via accès conditionnel Azure

Active le MFA n’est pas obligatoire pour l’authentification via Microsoft Authenticator mais, est fortement recommandé.

Pour créer un nouvel accès conditionnel Azure ou conditional access (CA), se connecter successivement à portal.azure.com > Cliquer sur l’icône des 3 traits horizontaux > Azure Active Directory > Security > Policies > New policy

 

Dans Users choisir les utilisateurs qui doivent faire du passwordless, attention de toujours garder quelques comptes de bris de glace qui ne sont pas concernés par la politique

Dans Cloud apps or actions, cocher All cloud apps

Dans Conditions, uniquement, s’il faut exclure certains utilisateurs en se basant sur des critères prédéfinis

Dans Enable policy choisir On

 

Dans Grant, cocher Grant access et Require multifactor authenticator puis cliquer sur Select

Enfin cliquer sur Create

Dorénavant, les utilisateurs configurés dans la CA devront s’authentifier en MFA. Lors de la première connexion, il leur sera demandé d’enregistrer des facteurs d’authentifications, Microsoft Authenticator étant plus que recommandé sans quoi l’authentification passwordless ne pourra pas se faire.

 

Identifier les domaines fédérés et planifier la migration de l’authentification vers Azure

Dans le cas où l’environnement disposerait d’une ferme ADFS, les domaines fédérés ne peuvent pas être utilisés pour faire du passwordless.

En fonction de comment est gérer l’authentification des utilisateurs OnPremises versus Azure, les actions à réaliser peuvent être plus ou moins chronophages.

Se référer à la documentation Microsoft : Migrate from federation to cloud authentication

Il est donc nécessaire de réaliser cette transition de l’authentification vers le cloud Azure pour pouvoir faire du passwordless.

 

Configurer l’authentification passwordless via Microsoft Authenticator

Se connecter successivement à portal.azure.com > Cliquer sur l’icône des 3 traits horizontaux > Azure Active Directory > Security > Authentication Methods > Microsoft Authenticator

Dans Enable and Target, activer Enable

Dans Include, choisir Select groups puis choisir le groupe qui contient les utilisateurs qu’il faut déployer passwordless, ici le groupe s’appelle Passwordless-test
Dans Authentication mode choisir Any, any inclut la possibilité de faire du passwordless

Cliquer sur Save

 

Cela conclut la configuration de l’authentification passwordless via Microsoft Authenticator

 

Configuration par l’utilisateur final la possibilité de faire de l’authentification passwordless avec Microsoft Authenticator

Chaque utilisateur souhaitant s’authentifier en passwordless doit activer l’option dans son application Microsoft Authenticator

Une fois sur le compte d’entreprise, cliquer sur Enable phone sign-in

Azure AD – Présentation du passwordless

L’importance du passwordless

Posséder une bonne stratégie de mot de passe demeure essentiel, mais ne permet pas de s’affranchir du maillon le plus à risque de la chaîne d’authentification à savoir l’utilisateur. Cet utilisateur peut être invité de façon frauduleuse à fournir ses identifiants de connexions à un pirate informatique, c’est ce que l’on appelle le phising.

Le passwordless consiste à fournir à l’utilisateur des méthodes d’authentifications qui ne se reposent pas sur l’utilisation d’un mot de passe.

Augmenter la sécurité est souvent lié à plus de contraintes, c’est le cas par exemple pour le MFA ou multi-factor authentification qui nécessite une étape supplémentaire lors de la connexion.

Le passwordless, en outre de fournir un meilleur niveau de sécurité que le MFA traditionnel permet de réduire directement ou indirectement ces impératifs lourds de connexion lourd intrinséque au MFA

Un autre avantage du passwordless Azure est sa liberté d’implémentation, il est possible d’autoriser les utilisateurs à utiliser en conjonction leurs identifiants standards et le passwordless. Cela permet en termes de déploiement d’avoir une meilleure adhésion des utilisateurs au passwordless et d’identifier en amont les éventuels problèmes avant de restreindre l’utilisation des mots de passe.

 

Les solutions pour faire du passwodless via Azure

  • L’application Microsoft Authenticator, disponible sur Android et iOS, prisée pour l’authentification MFA, permet également de faire du passwordless. Concrètement, lorsqu’un utilisateur tente de se connecter à une application, son mot de passe ne lui sera pas demandé, mais une notification apparaîtra dans son application Microsoft Authenticator.

 

  • Windows Hello for Business, une solution implémentée dans les systèmes d’exploitation Windows 10 et postérieur, propose à l’utilisateur d’utiliser un code PIN ou des informations biométriques pour se connecter. Le code PIN à l’instar du mot de passe traditionnel ne peut pas être utilisé sur un autre équipement que le PC sur lequel il a été configuré et n’est pas transmis à un autre équipement ou application.

 

  • Une clé de sécurité FIDO2, aussi courament appelée token, est un équipement physique qui s’apparente à une clé USB, l’utilisateur lorsqu’il veut se connecter doit brancher sa clé FIDO2 à son PC et entrer le code PIN pour débloquer la clé.

 

Passwodless vs MFA

L’augmentation des attaques informatiques sur les dernières années à pousser les entreprises à améliorer la sécurité de leur système d’information. Nombreuses d’entre elles ont donc décidé d’implémenter du MFA ou multi-factor authentification.
Le MFA dans son implémentation la plus fréquente consiste à demander en plus du jeu identifiant et mot de passe pour l’authentification d’un utilisateur, un deuxième moyen à l’utilisateur de prouver son identité, par exemple un code d’authentification reçu par SMS.

L’obtention de certifications demande l’implémentation de solutions de MFA, on est donc en droit de se demander si le passwordless est de l’authentification MFA ?

Le MFA consiste à utiliser à minima 2 des 3 éléments suivants :

  • Ce que je sais, par exemple un mot de passe ou un code PIN
  • Ce que je possède, par exemple une clé FIDO2 ou un téléphone portable
  • Ce que je suis, ce qui est lié a de la biométrie, par exemple un iris, un visage ou une empreinte

 

L’application Microsoft Authenticator utilise donc les facteurs : ce que je sais et ce que je posséde

Windows Hello For Business, utilise donc une combinaison des 3 facteurs en fonction de l’authentification choisie. Dans le cas de l’utilisation du code PIN, un argument serait que seul le facteur ce que je sais entre en jeu, cependant le PC qui est utilisé pour l’authentification du passwordless doit être enregistrée dans le tenant Azure de l’organisation. Le PC peut donc être considéré de facto comme le facteur ce que je posséde.

La clé de sécurité FIDO2 utilise donc les 2 facteurs : ce que je sais et ce que je possède

 

Le périmètre d’application du passwordless

Le passordless Azure comme son nom l’indique est fondamentalment lié à Azure, il est donc nécessaire que l’application qui demande à l’utilisateur de s’authentifier soit compatible avec les méthodes d’authentification fortes d’Azure.

Pour la connexion aux portails Azure et Office 365, c’est nativement le cas.

Pour l’ouverture d’une session Windows, des pré-requis doivent être satisfaits et des configurations réalisées

Pour les applications tierces ou développées en interne, l’authentification doit supporter des méthodes d’authentification modernes Azure tel que le SSO

 

Pour aller plus loin

Définir sa stratégie de déploiement passwordless : Article officiel de Microsoft

[Exchange Hybride] Automapping Mappage automatique ne fonctionne pas comme prévu

Le Mappage automatique permet à Outlook d’ouvrir automatiquement toutes les boîtes aux lettres auxquelles un utilisateur a les droits d’accès complet (le mappage automatique fonctionne uniquement pour les utilisateurs individuels disposant des autorisations appropriées et ne fonctionne pour aucun type de groupe.)

La fonctionnalité d’auto-mappage automatique de boîte aux lettres est NON prise en charge dans les environnements hybrides. Au début, les migrations Exchange hybrides ne prenaient en charge aucune sorte d’autorisations de boîte aux lettres entre forêts. Après quelques années, Microsoft a rendu possible le fonctionnement des autorisations d’accès complet.

Lorsque les autorisations d’accès complet sont attribuées avant le déplacement –> Tout continue de fonctionner. Toutefois, la configuration des autorisations d’accès complet après la migration d’une boîte aux lettres ne configurera pas le mappage automatique. Il ne s’agit pas d’un problème  d’autorisations mais plutôt au niveau des attributs de mappage automatique.

Les deux attributs Active Directory qui doivent être mis à jour pour que le mappage automatique fonctionne sont : msExchDelegateListLink (La boîte aux lettres autorisée) et  msExchDelegateListBL (Utilisateur bénéficiant des autorisations)

1. Ajouter tout d’abord des autorisations permettant à un user Online d’accéder à la boîte aux lettres onpremise. Cela se fait avec l’applet de commande Add-MailboxPermission dans Exchange Online. 

PS C:\>Add-MailboxPermission -Identity sales@contoso.com -Utilisateur nathan@contoso.com -AccessRights FullAccess -InheritanceType All

2. Exécuter par la suite la commande Set-ADUser Onprem. 

PS C:\>Set-ADUser -Identity nathan@mcsmlab.com -Add@ {msExchDelegateListLink/BL=sales@contoso.com}

Une fois que ces actions ont été effectuées, AAD Connect synchronisera tous les attributs appropriés dans Azure AD et le mappage automatique fonctionnera comme prévu.