Active Directory + Google Authenticator - AD FS, ou comment?
(Modifié pour correspondre à la compréhension des rédacteurs de réponses - Nouvelle question fraîche et propre publiée ici: Active Directory + Google Authenticator - Prise en charge native de 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 -des-mots-de-passe-pour-l'authentification-multi-facteurs-dans-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 de AD FS spécifiquement. Nous recherchons, lorsque vous y arrivez, pour 2FA, préférant prendre en charge les RFC Google Authenticator, intégrés à AD.
La réponse, en octobre 2017:
Utilisez Duo pour activer les systèmes MFA qui effectuent LDAP vers 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.
Nous devons regarder ce qui se passe ici.
AD FS concerne tout SAML . Il se connectera à Active Directory pour l'utiliser comme fournisseur d'identité SAML. - Google a déjà la capacité d'agir en tant que fournisseur de services SAML . Mettez les deux ensemble, 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.1
Google Authenticator, d'autre part, agit comme un facteur 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 la transmission à Google, le côté identité est déjà terminé. Si vous avez fait quoi que ce soit, il faudrait configurer Google pour exiger Authenticator comme une confirmation d'identité supplémentaire en plus (mais distincte) de AD FS ou d'autres fournisseurs d'identité SAML. (Remarque: je ne pense pas que Google le supporte, mais ils le 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. L'une d'entre elles est la possibilité de créer vos propres fournisseurs d'authentification multifacteur. De plus, Google Authenticator prend en charge 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; c'est à chaque service multifacteur de créer ce plug-in.
Peut-être que MS pourrait fournir un support 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 que il n'aurait pas été possible de le faire au moment de la publication. De plus, il serait difficile pour MS de les maintenir, lorsqu'ils n'ont aucune influence sur le moment ou les mises à jour que ces autres fournisseurs pourraient pousser.
Peut-être que lorsque Windows Server 2016 sera sorti, l'AD mis à jour FS rendra cela plus facile. Ils semblent avoir fait du travail pour un meilleur support multi-facteurs , mais je ne ' Vous ne verrez aucune note sur l'inclusion de l'authentificateur d'un concurrent dans la boîte. Il semblerait plutôt que vous souhaitiez que vous configuriez Azure pour ce faire et que vous fournissiez éventuellement une application iOS/Android/Windows pour votre propre concurrent à Authenticator.
Ce que j'aimerais finalement voir MS livrer est un fournisseur générique TOTP, 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 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 énorme partie du compte Google. Afin d'éviter cela, vous 'll faudra également installer et configurer l'outil de synchronisation de mot de passe de Google . Avec l'outil, chaque fois que quelqu'un modifie 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 les 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.
Le billet de blog que vous avez lié à un exemple de code que n'importe qui pourrait écrire pour ajouter RFC6238 Prise en charge TOTP à leur propre environnement AD FS. Que cela fonctionne avec Google Authenticator est juste un effet secondaire de l'authentificateur soutenant cette RFC. Je voudrais également noter la litanie de renonciations 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.