Mettre en place une authentification multifacteur¶
L'authentification multifacteur (MFA) demande à l'utilisateur une seconde preuve en plus de son identifiant et de son mot de passe. CyberElements Bastion propose plusieurs moyens d'en obtenir une. Cette page en couvre quatre, dans l'ordre où on les envisage habituellement, puis détaille celui qui n'a pas de page d'intégration propre : le mot de passe à usage unique envoyé par e-mail.
Quatre facteurs, et non le tableau complet
Ces quatre-là sont ceux que cette page parcourt — ce ne sont pas les seuls seconds facteurs que la plateforme peut demander. Également disponibles, et hors du périmètre de cette page :
- un OTP envoyé par SMS, par l'un des nombreux opérateurs proposés par le module Générateurs de jeton OTP ;
- un connecteur Radius vers une solution MFA tierce, par le type OTP - Radius de ce même module ;
- l'authentification par certificat x509, qui n'est pas un jeton mais une méthode d'authentification du domaine lui-même — Certificat utilisateur, ou Certificat utilisateur et formulaire pour conserver également le mot de passe ;
- une MFA imposée en amont par un fournisseur SAML, ou par toute autre authentification déléguée. Le second facteur est alors demandé avant que la plateforme n'intervienne, laquelle ne le configure ni ne le voit.
La MFA se règle sur le domaine d'authentification, jamais sur un utilisateur
Quel que soit le facteur retenu, il s'active sur un domaine d'authentification et s'applique à tous les utilisateurs qui s'y connectent. Il n'existe aucun réglage par utilisateur : pour ne soumettre qu'une partie de votre population à la MFA, placez ces utilisateurs derrière un domaine d'authentification dédié.
Choisir un facteur¶
| Facteur | Ce que fait l'utilisateur | Ce qu'il exige | Procédure |
|---|---|---|---|
| Neomia Pulse | Rien. L'utilisateur est reconnu à sa façon de frapper au clavier. | L'option Neomia Pulse, les paramètres de connexion à votre service Pulse, un domaine d'authentification de type local ou LDAP, et un second facteur de ce tableau sur le même domaine. |
Intégration Neomia Pulse |
| FIDO2 | Présente son authentificateur — branchement d'une clé de sécurité, ou approbation sur l'appareil ou le coffre qui détient la clé d'accès — puis saisit un code PIN si l'authentificateur en demande un. | Un authentificateur FIDO2 par utilisateur, une partie de confiance déclarée dans la console, et un compte nominatif — un domaine d'authentification anonyme est exclu. | Intégration Yubico |
| TOTP | Lit un code à six chiffres dans une application d'authentification. | Une application sur le téléphone ou le poste de l'utilisateur (Google Authenticator, FreeOTP, Microsoft Authenticator, etc.) et un enrôlement par utilisateur. | Intégration Google Authenticator |
| OTP par e-mail | Recopie un code reçu par e-mail. | Un serveur SMTP joignable par la plateforme et une adresse e-mail portée par un attribut utilisateur. | Mettre en place un OTP par e-mail |
Neomia Pulse se configure par-dessus un autre facteur
Activer Neomia Pulse suppose qu'une autre MFA soit activée sur le même domaine. Ses réglages décident ensuite de ce à quoi sert cet autre facteur : il peut être ignoré quand Pulse valide l'utilisateur, et exigé quand Pulse ne le valide pas. Neomia Pulse est donc un moyen d'épargner le second facteur plutôt que de le remplacer.
Où chaque facteur se déclare, et où il s'active¶
La configuration comporte deux étapes possibles — déclarer le facteur dans son propre module, puis l'activer sur le domaine d'authentification — mais deux des quatre en sautent une :
| Facteur | Déclaré dans | Activé sur le domaine d'authentification |
|---|---|---|
| Neomia Pulse | rien à déclarer | ✅ l'option Activer l'authentification neomia Pulse, ainsi que les paramètres de connexion au service Pulse — voir l'encart ci-dessous |
| FIDO2 | Parties de confiance | ❌ rien à activer — voir l'encart ci-dessous |
| TOTP | Générateurs de jeton OTP | ✅ comme jeton d'authentification |
| OTP par e-mail | un serveur SMTP, puis Générateurs de jeton OTP | ✅ comme jeton d'authentification |
FIDO2 n'a pas d'interrupteur sur le domaine d'authentification
Les clés de sécurité ne s'activent pas domaine par domaine : la plateforme propose le facteur dès qu'au moins une partie de confiance est déclarée, sur tout domaine d'authentification qui n'est pas anonyme — une clé doit être rattachée à un compte nominatif. Et c'est l'utilisateur qui enrôle son authentificateur depuis le portail, non l'administrateur qui le lui attribue.
Neomia Pulse n'a rien à déclarer au préalable
Pulse n'est pas un jeton à créer dans un module : l'option s'active directement sur le domaine d'authentification, où se règle aussi son comportement.
Pulse a besoin de ses paramètres de connexion
Cocher Activer l'authentification neomia Pulse fait apparaître trois champs obligatoires qui dirigent la plateforme vers votre service Pulse :
| Champ | À renseigner |
|---|---|
| URL de l'API | URL de l'API Pulse. |
| URL de l'API d'authentification | URL de l'API d'authentification Pulse. |
| Clé d'API | Clé authentifiant la plateforme auprès de ce service. |
Le domaine d'authentification ne s'enregistre pas tant que les trois ne sont pas renseignés.
Le reste de cette page couvre l'OTP par e-mail de bout en bout. Les trois autres facteurs sont traités par leur page d'intégration, liée dans le tableau ci-dessus.
Mettre en place un OTP par e-mail¶
Un OTP par e-mail envoie à l'utilisateur un code à usage unique par e-mail une fois son identifiant et son mot de passe acceptés. L'utilisateur saisit ce code sur le portail pour terminer sa connexion.
Avant de commencer : ce que protège réellement un OTP par e-mail¶
Un OTP par e-mail n'ajoute pas toujours un facteur
À lire avant de préférer ce facteur aux trois autres.
Si l'utilisateur se connecte avec son compte Active Directory et relève le code dans une boîte aux lettres rattachée à ce même compte, le second facteur n'apporte presque rien : un attaquant qui a obtenu les identifiants ouvre la boîte avec ces mêmes identifiants et y lit le code.
Un OTP par e-mail vaut d'être déployé quand la boîte aux lettres n'est pas joignable avec les identifiants contrôlés, c'est-à-dire quand :
- l'utilisateur se connecte avec un compte local, ou avec un compte distinct de sa boîte aux lettres ;
- le code est envoyé à une adresse autre que celle du compte de connexion.
Étape 1 — Disposer d'un serveur SMTP¶
Le code est envoyé par la plateforme au travers d'un serveur SMTP déclaré dans le module Serveurs SMTP. Si aucun n'est encore disponible, déclarez-en un avant d'aller plus loin :
Mettre en place l'envoi d'e-mails
Utilisez ensuite le bloc Test de la configuration SMTP de ce module pour confirmer l'acheminement : une défaillance diagnostiquée à ce stade est une défaillance que vous ne chercherez pas plus tard dans le parcours de connexion.
Le message de test n'emploie pas l'expéditeur que vous allez configurer
Le test part de noreply@cleanroom.com, une adresse fixée par le produit : elle ne se paramètre nulle part et sert également d'adresse de réponse. Votre propre expéditeur est l'Expéditeur SMTP du jeton, réglé à l'étape 2 — c'est lui que portent les messages OTP réels.
La conséquence mérite d'être connue avant de conclure : un serveur SMTP qui restreint les adresses d'envoi peut rejeter le test tout en laissant passer les messages réels, et inversement.
La connexion est ouverte par la plateforme
Le flux vers le serveur SMTP part de la plateforme, non du poste de l'utilisateur. Si votre serveur SMTP se trouve sur votre LAN, ce flux doit être autorisé.
Étape 2 — Créer le jeton OTP¶
Ouvrez le module Générateurs de jeton OTP et cliquez sur +. Dans la fenêtre Ajout d'un jeton OTP, sélectionnez le type OTP - email, puis renseignez les champs.
| Champ | À renseigner |
|---|---|
| Type d'OTP | OTP - email. Ce choix n'est plus modifiable ensuite — un autre canal veut dire un autre jeton. |
| Nom | Le nom du jeton. Il est présenté à l'utilisateur sur le portail : il doit se lire comme un nom de facteur plutôt que comme une référence interne. |
| Description | Texte libre, visible des seuls administrateurs. |
| Caractères utilisables dans l'OTP | L'alphabet dans lequel le code est tiré. |
| Longueur de l'OTP | Le nombre de caractères du code. |
| Durée de validité d'un jeton (en secondes) | Le temps dont dispose l'utilisateur pour saisir le code avant qu'il ne soit refusé. |
| Message avant l'OTP | La phrase qui précède le code dans le corps du message. |
| Sujet de mail | L'objet du message. |
| Expéditeur SMTP | L'adresse expéditrice du message. |
| Serveur SMTP | Le serveur déclaré à l'étape 1. |
La liste complète des champs, avec leurs valeurs par défaut et leurs contraintes, figure dans la page de référence : Bloc générique et Expédition par courriel.
Cliquez sur Valider pour enregistrer le jeton.
Étape 3 — Activer le jeton sur un domaine d'authentification¶
Ouvrez le module Domaine d'authentification et modifiez le domaine qui doit demander l'OTP.
| Champ | À renseigner |
|---|---|
| Jeton d'authentification | Le jeton créé à l'étape 2. Plusieurs jetons peuvent être sélectionnés. |
| Attribut utilisateur utilisé pour envoyer l'OTP | Le nom de l'attribut utilisateur portant l'adresse à laquelle le code est envoyé. |
| Durée d'expiration du jeton | Le temps pendant lequel un OTP validé reste accepté avant d'être redemandé. 0 désactive l'expiration, ce qui revient à demander l'OTP à chaque connexion. |
| Unité de temps | Heures ou Jours, appliquée au champ précédent. |
| L'expiration commence | Si le décompte part de la dernière validation d'OTP ou de la dernière connexion réussie. |
Quel attribut porte l'adresse
L'attribut est celui de l'annuaire que vise le domaine d'authentification, et non un nom de notre choix : employez l'attribut dans lequel vos utilisateurs portent effectivement une adresse. Pour un annuaire local, c'est l'adresse saisie dans les propriétés de l'utilisateur qu'il faut viser ; pour un annuaire LDAP, c'est l'attribut de messagerie de l'annuaire lui-même.
Cliquez sur Valider. Les utilisateurs de ce domaine d'authentification se voient demander un code à leur prochaine connexion.
Étape 4 — Vérifier d'abord sur un domaine d'authentification de test¶
Activer la MFA sur un domaine d'authentification l'applique à tous les utilisateurs qui en dépendent, vous compris si vous vous connectez par lui. Avant d'activer le jeton sur votre domaine de production, créez un domaine d'authentification de test portant un seul compte et déroulez une connexion complète par son intermédiaire : identifiant, mot de passe, réception du message, saisie du code.
Un utilisateur sans adresse ne reçoit jamais de code
Un utilisateur dont l'attribut est vide ne peut rien recevoir, et sa connexion ne peut pas aboutir. Vérifiez que l'attribut est renseigné pour chaque compte dépendant du domaine d'authentification avant d'y activer le jeton.