Vous êtes déjà client NinjaOne ? Connectez-vous pour consulter d'autres guides et les dernières nouvelles.

Contourner la MFA de NinjaOne : FAQ

  • Dernière mise à jour décembre 16, 2025


Activer le contournement conditionnel de l'authentification forte de NinjaOne permet de s'assurer que la MFA n'est demandée qu'une seule fois lors d'une connexion SSO, soit au niveau du fournisseur d'identité, soit au niveau de NinjaOne, mais pas au niveau des deux à la fois. Cela permet de garantir un niveau de sécurité élevé tout en offrant l'avantage supplémentaire de ne demander qu'une seule authentification forte.

MFA au niveau du fournisseur d'identité uniquement

Picture1.png

- OU -

MFA au niveau de NinjaOne uniquement

Picture2.png

 

Comment NinjaOne procède-t-il ?

Certains fournisseurs d'identité (IdP), dont Okta et Azure, ajoutent un attribut SAML à la réponse de connexion de l'utilisateur qui indique à l'IdP si l'authentification forte a été effectuée pendant la session de connexion. Nous recherchons cet attribut une fois la réponse SAML reçue afin de déterminer si la MFA de NinjaOne peut-être ignorée sur la base de cette condition. La réponse SAML est un document signé de manière chiffrée qui établit la confiance entre NinjaOne et le fournisseur d'identité. Elle ne peut pas être modifiée entre le fournisseur d'identité et NinjaOne sans que cela soit détecté. Si nous ne voyons pas cet attribut MFA spécifique dans la réponse SAML, nous ne contournerons pas l'authentification forte de NinjaOne pour la connexion de l'utilisateur.

Quels sont les fournisseurs d'identité compatibles ?

À l'heure actuelle, seuls Azure et Okta sont des fournisseurs d'identité compatibles avec cette fonctionnalité. D'autres IdP seront pris en charge une fois que nous aurons déterminé qu'ils sont compatibles avec un attribut MFA basé sur la session, comme décrit ci-dessus.

Quelles sont les attributs recherchées par NinjaOne ?

NinjaOne recherchera les attributs suivants dans la réponse SAML pour Okta et Azure. S'ils sont trouvés, NinaOne contourne la MFA pour cette demande. S'ils ne sont pas trouvés, NinjaOne demandera l'authentification forte lors la demande de connexion.

Attributs Okta :

<saml2:Attribute Name=“amr” NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified”>
<saml2:AttributeValue xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:type=“xs:string”>swk</saml2:AttributeValue>
<saml2:AttributeValue xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:type=“xs:string”>mfa</saml2:AttributeValue>
<saml2:AttributeValue xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:type=“xs:string”>pwd</saml2:AttributeValue>
</saml2:Attribute>

Attributs Azure :

<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
<AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</AttributeValue>
</Attribute>
Remarque importante : Pour Okta, l'attribut doit être configuré dans la liste des attributs de l'application Okta. Il est recommandé de nommer l'attribut "amr". C'est le nom de l'attribut que nous recherchons par défaut. Une valeur d'attribut "mfa" doit être présente dans la liste pour que le contournement conditionnel soit effectif. Voir la documentation Okta "Pass Dynamic Authentication Context" (en anglais).
MFAIDP3.png

Pourquoi l'option "Activer le contournement conditionnel de la MFA de NinjaOne" est-elle masquée après le test du fournisseur d'identité ?

Comme seuls Azure et Okta sont compatibles dans cette version, nous recherchons actuellement une URL de fournisseur d'identité contenant .okta.com (Okta) ou .microsoftonline.com (Azure). Si votre fournisseur d'identité a une URL personnalisée, il n'est pour le moment pas compatible, mais le sera probablement à l'avenir. Pour l'instant, tous les autres fournisseur d'identité auront cette option masquée après la connexion de test de l'IdP.

Pourquoi les utilisateurs reçoivent-ils toujours la demande MFA de NinjaOne lors de la connexion alors que cette fonctionnalité est activée ?

Cela peut se produire pour plusieurs raisons :

  • Assurez-vous que la fonctionnalité est activée dans la configuration du fournisseur d'identité NinjaOne.
  • Il est possible que l'attribut défini dans la réponse SAML par l'IdP ne soit pas présent ou ne corresponde pas au nom de l'attribut que nous recherchons. Assurez-vous que l'attribut est bien présent dans la réponse SAML reçue par NinjaOne.
  • Il se peut que l'utilisateur n'ait pas effectué d'authentification forte auprès du fournisseur d'identité. Assurez-vous que la politique IdP applique la MFA pour l'application NinjaOne.
  • Si le fournisseur d'identité est configuré avec un tiers pour la MFA (par exemple, en utilisant Duo avec Azure IdP), il est possible que l'IdP n'ajoute pas l'attribut MFA que nous recherchons.

Cela s'applique-t-il aussi à la MFA de NinjaOne pour les opérations sensibles en matière de sécurité dans NinjaOne après l'ouverture de session ?

Non, cela n'affecte pas les exigences de la MFA après l'ouverture de session. Même si l'authentification forte de NinjaOne est contournée lors de la connexion, tous les utilisateurs de NinjaOne (techniciens et utilisateurs finaux) devraient quand même avoir la MFA de NinjaOne configurée et devraient toujours avoir à effectuer l'authentification forte pour les opérations sensibles en matière de sécurité après la connexion.

 

FAQ

Pour aller plus loin