Active Directory + Google Authenticator - AD FS, ou comment?

(Modifié pour correspondre à la compréhension des répondeurs - Nouvelle question fraîche et propre publiée ici: Active Directory + Google Authenticator - Prise en charge native dans Windows Server? )

Recherches effectuées jusqu'à présent

Il existe un article technique sur la façon d'utiliser l'authentificateur Google avec les services fédérés Active Directory (AD FS): https://blogs.technet.microsoft.com/cloudpfe/2014/10/26/using-time-based-one-time -passwords-for-multi-factor-authentication-in-ad-fs-3-0 /

Curieusement, il semble être un projet de développement, nécessitant du code et sa propre base de données SQL.

Nous ne parlons pas ici spécifiquement d'AD FS. Nous recherchons, lorsque vous y arrivez, pour 2FA, préférant prendre en charge les RFC Google Authenticator, intégrés à AD.

Nous devons regarder ce qui se passe ici.

AD FS concerne SAML . Il se connectera à Active Directory pour l'utiliser en tant que fournisseur d'identité SAML. Google a déjà la capacité d'agir en tant que fournisseur de services SAML . Associez les deux afin que Google fasse confiance au jeton SAML de votre serveur et que vous vous connectiez à un compte Google via les informations d'identification Active Directory. ¹

Google Authenticator, d'autre part, agit comme l'un des facteurs d'un fournisseur d'identité ... généralement pour le propre service de Google. Peut-être pouvez-vous voir maintenant comment cela ne s'intègre pas vraiment avec AD FS. Lorsque vous utilisez AD FS avec Google, vous n'utilisez plus vraiment le fournisseur d'identité de Google, et au moment où AD FS termine le transfert à Google, le côté identité est déjà terminé. Si vous avez fait quoi que ce soit, il s'agirait de configurer Google pour exiger Authenticator comme confirmation d'identité supplémentaire par-dessus (mais distincte) d'AD FS ou d'autres fournisseurs d'identité SAML. (Remarque: je ne pense pas que Google supporte cela, mais ils devraient).

Maintenant, cela ne signifie pas que ce que vous voulez faire est impossible ... juste que ce n'est peut-être pas le meilleur choix. Bien qu'il soit principalement utilisé avec Active Directory, AD FS est également conçu pour fonctionner comme un service SAML plus générique; vous pouvez le connecter à d'autres fournisseurs d'identité qu'Active Directory et il prend en charge de nombreuses options et extensions différentes. L'un d'eux est la possibilité de créer vos propres fournisseurs d'authentification multifacteur. En outre, Google Authenticator prend en charge la norme TOTP pour l' authentification multifacteur .

Mettez les deux ensemble, et il devrait être possible (mais certainement pas trivial) d'utiliser Google Authenticator en tant que fournisseur MuliFactor avec AD FS. L'article auquel vous avez lié est une preuve de concept d'une telle tentative. Cependant, ce n'est pas quelque chose qu'AD FS fait hors de la boîte; il appartient à chaque service multifacteur de créer ce plug-in.

Peut-être que MS pourrait fournir une assistance de première main pour quelques-uns des grands fournisseurs multi-facteurs (s'il y a une telle chose), mais Google Authenticator est assez nouveau et AD FS 3.0 est assez vieux pour qu'il n'aurait pas été possible de le faire ceci au moment de la sortie. En outre, il serait difficile pour les États membres de les maintenir, lorsqu'ils n'ont aucune influence sur le moment ou les mises à jour que ces autres fournisseurs pourraient proposer.

Peut-être que lorsque Windows Server 2016 sera sorti, l'AD FS mis à jour facilitera les choses. Ils semblent avoir fait du travail pour un meilleur support multi-facteurs , mais je ne vois aucune note sur l'inclusion de l'authentificateur d'un concurrent dans la boîte. Au lieu de cela, il semble qu'ils voudront que vous configuriez Azure pour ce faire et que vous fournissiez éventuellement une application iOS / Android / Windows pour leur propre concurrent à Authenticator.

Ce que j'aimerais finalement voir MS livrer est un fournisseur TOTP générique , où je configure quelques choses pour lui dire que je parle à Google Authenticator, et il fait le reste. Peut-être un jour. Peut-être qu'un examen plus détaillé du système, une fois que nous pourrons réellement l'obtenir, montrera qu'il est là.

^{1 Pour mémoire, je l' ai déjà fait. Sachez que lorsque vous effectuez le saut, ces informations ne s'appliquent pas à imap ou à d'autres applications qui utilisent le compte. En d'autres termes, vous cassez une grande partie du compte Google. Pour éviter cela, vous devrez également installer et configurer l'outil de synchronisation des mots de passe de Google . Avec l'outil, chaque fois que quelqu'un change son mot de passe dans Active Directory, votre contrôleur de domaine enverra un hachage du mot de passe à Google pour l'utiliser avec ces autres authentifications.}

^{De plus, c'est tout ou rien pour vos utilisateurs. Vous pouvez restreindre par adresse IP de noeud final, mais pas en fonction des utilisateurs. Donc, si vous avez des utilisateurs hérités (par exemple: des anciens élèves d'un collège) qui ne connaissent pas d'informations d'identification Active Directory, les déplacer tous pourrait être un défi. Pour cette raison, je n'utilise pas actuellement AD FS avec Google, bien que j'espère toujours faire le saut. Nous avons maintenant fait ce saut.}

Je pense que votre question fait l'hypothèse non valide qu'il appartient à Microsoft d'ajouter la prise en charge de la solution 2FA / MFA d'un fournisseur particulier. Mais il existe de nombreux produits 2FA / MFA qui prennent déjà en charge Windows et AD car les fournisseurs ont choisi d'ajouter cette prise en charge. Si Google ne pense pas que ce soit suffisamment important pour ajouter un support, ce n'est pas vraiment la faute de Microsoft. Les API liées à l'authentification et à l'autorisation sont bien documentées et gratuites à utiliser.

L'article de blog que vous avez lié à un exemple de code que n'importe qui pourrait écrire pour ajouter la prise en charge RFC6238 TOTP à son propre environnement AD FS. Le fait qu'il fonctionne avec Google Authenticator n'est qu'un effet secondaire de l'authentificateur prenant en charge cette RFC. Je voudrais également noter la litanie de clauses de non-responsabilité au bas sur le code étant «preuve de concept», «pas de traitement d'erreur approprié» et «non créé avec la sécurité à l'esprit».

En tout cas, non. Je ne pense pas que la prise en charge de Google Authenticator sera explicitement prise en charge dans Windows Server 2016. Mais je ne pense pas que quoi que ce soit empêche Google d'ajouter lui-même la prise en charge sur Server 2016 ou une version antérieure.

La réponse, en octobre 2017:

Utilisez Duo to MFA enable systems that do LDAP back to AD

Nous avons tout recherché ou tout essayé.

• Azure / Microsoft MFA (complexe et long à configurer, fragile en fonctionnement)
• Serveurs RADIUS

Bien que nous n'aimions pas le coût de fonctionnement de DUO, pour un maximum de 50 utilisateurs, le coût, pour nous, vaut la simplicité de configuration et d'utilisation.

Nous l'avons utilisé jusqu'ici:

• Périphériques Cisco ASA pour l'accès VPN

• Sonicwall Remote Access Appliance pour l'accès VPN (avec l'appareil faisant LDAP également à AD)

Nous ne connaissons aucune autre approche pouvant être configurée en 2 à 4 heures et MFA active les services LDAP qui bloquent AD.

Nous continuons de croire que AD lui-même devrait prendre en charge l'authentificateur Google derrière TOTP / HOTP RFC et nous sommes profondément déçus que MS n'ait pas résolu cela correctement dans Windows Server 2016.

Il existe déjà un plug-in gratuit pour l'authentification par mot de passe unique avec ADFS. Cela fonctionne bien avec les applications d'authentification Google ou Microsoft. Voir www.securemfa.com pour plus d'informations. Je l'utilise sans aucun problème de production.