Active Directory + Google Authenticator - AD FS, czyli jak?

(Edytowano, aby pasowało do zrozumienia autorów odpowiedzi - Nowe, świeże, czyste pytanie opublikowane tutaj: Active Directory + Google Authenticator - Natywna obsługa w systemie Windows Server? )

Badania zrobione do tej pory

Artykuł w technecie na temat korzystania z uwierzytelniacza Google w usługach federacyjnych 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 /

Co dziwne, wydaje się być projektem deweloperskim, wymagającym trochę kodu i własnej bazy danych SQL.

Nie mówimy tu konkretnie o AD FS. Szukamy, gdy dojdziesz do tego, 2FA, pref obsługujących RFC Google Authenticator, wbudowanych w AD.

Musimy spojrzeć na to, co się tutaj dzieje.

W usługach AD FS chodzi o SAML . Połączy się z Active Directory, aby użyć go jako dostawcy tożsamości SAML. Google ma już możliwość działania jako dostawca usług SAML . Połącz je razem, aby Google zaufał tokenowi SAML serwera i logujesz się na konto Google za pomocą poświadczeń Active Directory. ¹

Z drugiej strony Google Authenticator działa jako jeden z czynników dostarczających tożsamość ... zwykle dla własnej usługi Google. Może teraz zobaczysz, jak to naprawdę nie pasuje do AD FS. Korzystając z AD FS z Google, tak naprawdę nie używasz już dostawcy tożsamości Google, a zanim AD FS zakończy przekazywanie Google, strona tożsamości jest już ukończona. Jeśli cokolwiek zrobiłeś, Google konfigurowałoby, aby wymagało uwierzytelnienia jako dodatkowego potwierdzenia tożsamości na usługach AD FS lub innych dostawcach tożsamości SAML (ale niezależnie od nich). (Uwaga: nie sądzę, że Google to obsługuje, ale powinny).

To nie znaczy, że to, co chcesz zrobić, jest niemożliwe ... po prostu może nie jest to najlepsze dopasowanie. Chociaż jest głównie używany z usługą Active Directory, AD FS zaprojektowano również jako bardziej ogólną usługę SAML; możesz połączyć go z innymi dostawcami tożsamości niż Active Directory i obsługuje wiele różnych opcji i rozszerzeń. Jednym z nich jest możliwość tworzenia własnych dostawców uwierzytelniania wieloskładnikowego. Ponadto Google Authenticator obsługuje standard TOTP dla uwierzytelniania wieloskładnikowego.

Złóż je razem i powinno być możliwe (choć na pewno nie trywialne) użycie Google Authenticator jako dostawcy MuliFactor z AD FS. Artykuł, do którego linkujesz, jest dowodem koncepcji jednej takiej próby. Jednak nie jest to coś, co AD FS robi po wyjęciu z pudełka; stworzenie tej wtyczki zależy od każdej usługi Multi-Factor.

Może stwardnienie rozsiane może zapewnić pierwszorzędne wsparcie dla kilku dużych dostawców mutli-factor (jeśli jest coś takiego), ale Google Authenticator jest wystarczająco nowy, a AD FS 3.0 jest na tyle stary, że nie byłoby to możliwe to w momencie wydania. Ponadto MS będzie trudnym zadaniem, aby utrzymać je, gdy nie mają one wpływu na to, kiedy i jakie aktualizacje mogą przesuwać inni dostawcy.

Może po wydaniu systemu Windows Server 2016 zaktualizowany program AD FS ułatwi to. Wygląda na to, że wykonali pewną pracę dla lepszego wsparcia wieloskładnikowego , ale nie widzę żadnych notatek na temat włączenia uwierzytelniającego konkurenta do pudełka. Zamiast tego wygląda na to, że będą chcieli, abyś skonfigurował platformę Azure w tym celu i ewentualnie zapewnił aplikację iOS / Android / Windows dla swojego konkurenta w programie Authenticator.

To, co ostatecznie chciałbym zobaczyć, jak MS dostarcza, to ogólny dostawca TOTP, w którym konfiguruję kilka rzeczy, aby powiedzieć mu, że rozmawiam z Google Authenticator, a on zajmuje się resztą. Może kiedyś. Być może bardziej szczegółowe spojrzenie na system, gdy już go zdobędziemy, pokaże, że ono tam jest.

^{1 Dla przypomnienia, zrobiłem to. Pamiętaj, że kiedy wykonasz skok, te informacje nie będą miały zastosowania do imap ani innych aplikacji korzystających z konta. Innymi słowy, łamiesz ogromną część konta Google. Aby tego uniknąć, musisz również zainstalować i skonfigurować Google Password Sync Tool . Za pomocą tego narzędzia za każdym razem, gdy ktoś zmieni swoje hasło w usłudze Active Directory, kontroler domeny wyśle ​​skrót do hasła do Google w celu użycia z tymi innymi uwierzytelnieniami.}

^{Dodatkowo dla użytkowników to wszystko albo nic. Można ograniczyć według adresu IP punktu końcowego, ale nie w oparciu o użytkowników. Jeśli więc masz starszych użytkowników (na przykład absolwentów uczelni), którzy nie znają poświadczeń usługi Active Directory, przeniesienie ich wszystkich może być wyzwaniem. Z tego powodu nie korzystam obecnie z usług AD FS w Google, choć nadal mam nadzieję, że w końcu zrobię skok. Dokonaliśmy teraz tego skoku.}

Myślę, że twoje pytanie jest błędnym założeniem, że zadaniem Microsoftu jest dodanie obsługi rozwiązania 2FA / MFA konkretnego dostawcy. Ale istnieje wiele produktów 2FA / MFA, które już obsługują Windows i AD, ponieważ dostawcy zdecydowali się dodać tę obsługę. Jeśli Google nie uważa, że ​​dodanie wsparcia jest wystarczająco ważne, to nie jest tak naprawdę wina Microsoftu. Interfejsy API związane z uwierzytelnianiem i autoryzacją są dobrze udokumentowane i bezpłatne.

Wpis na blogu, który podałeś do przykładowego kodu, który każdy może napisać, aby dodać obsługę TFC RFC6238 do własnego środowiska AD FS. To, że zdarza się, że współpracuje z Google Authenticator, jest tylko efektem ubocznym uwierzytelnienia obsługującego ten RFC. Chciałbym również zauważyć litanię zrzeczeń na dole, że kod jest „dowodem koncepcji”, „brakiem prawidłowej obsługi błędów” i „nie stworzony z myślą o bezpieczeństwie”.

W każdym razie nie. Nie sądzę, aby obsługa Google Authenticator była wyraźnie obsługiwana w systemie Windows Server 2016. Ale nie sądzę, aby cokolwiek powstrzymywało Google przed dodaniem wsparcia na serwerze 2016 lub wcześniejszym.

Odpowiedź, od października 2017 r .:

Użyj Duo, aby włączyć MFA w systemach, które wykonują LDAP z powrotem do AD

Zbadaliśmy lub wypróbowaliśmy wszystko.

• Azure / Microsoft MFA (skomplikowany i czasochłonny w konfiguracji, delikatny w działaniu)
• Serwery RADIUS

Chociaż nie podoba nam się koszt operacyjny DUO, dla maksymalnie 50 użytkowników koszt jest dla nas prosty w konfiguracji i obsłudze.

Użyliśmy go do tej pory:

• Urządzenia Cisco ASA do dostępu VPN

• Sonicwall Remote Access Appliance dla dostępu VPN (z urządzeniem wykonującym LDAP również do AD)

Nie wiemy o żadnym innym podejściu, które można skonfigurować w ciągu 2-4 godzin, a usługa MFA włącza usługi LDAP, które zwalniają AD.

Nadal uważamy, że sama AD powinna obsługiwać TOTP / HOTP RFC za uwierzytelniaczem Google i jesteśmy głęboko rozczarowani, że MS nie rozwiązało tego poprawnie w Windows Server 2016.

Dostępne jest już bezpłatne podłączanie do jednorazowego uwierzytelnienia za pomocą hasła w ADFS. Działa dobrze z aplikacjami uwierzytelniającymi Google lub Microsoft. Więcej informacji na stronie www.securemfa.com. Używam go bez żadnych problemów w produkcji.