Dobbiamo guardare cosa sta succedendo qui.
AD FS riguarda SAML . Si connetterà ad Active Directory per usarlo come provider di identità SAML. Google ha già la possibilità di agire come fornitore di servizi SAML . Metti insieme i due elementi, in modo che Google si fidi del token SAML del tuo server e accedi a un account Google tramite le credenziali di Active Directory. 1
Google Authenticator, d'altra parte, funge da fattore di un provider di identità ... di solito per il servizio di Google. Forse ora puoi vedere come non si adatta davvero con AD FS. Quando si utilizza ADFS con Google, non si utilizza più realmente il provider di identità di Google e quando AD FS completa la restituzione a Google, il lato identità è già terminato. Se hai fatto qualcosa, sarebbe configurare Google per richiedere Authenticator come conferma d'identità supplementare oltre (ma separato da) AD FS o altri provider di identità SAML. (Nota: non credo che Google supporti questo, ma dovrebbero).
Ora, ciò non significa che ciò che vuoi fare sia impossibile ... solo che forse non è la soluzione migliore. Sebbene sia utilizzato principalmente con Active Directory, ADFS è anche progettato per funzionare come un servizio SAML più generico; puoi collegarlo ad altri provider di identità diversi da Active Directory e supporta molte opzioni ed estensioni diverse. Uno di questi è la possibilità di creare i propri provider di autenticazione a più fattori. Inoltre, Google Authenticator supporta lo standard TOTP per l'autenticazione a più fattori.
Metti insieme i due e dovrebbe essere possibile (anche se certamente non banale) utilizzare Google Authenticator come provider MuliFactor con AD FS. L'articolo a cui ti sei collegato è una prova del concetto di uno di questi tentativi. Tuttavia, questo non è qualcosa che ADFS fa fuori dalla scatola; spetta a ciascun servizio Multi-Factor creare quel plug-in.
Forse MS potrebbe fornire supporto di prima parte ad alcuni dei grandi fornitori di fattori multipli (se esiste una cosa del genere), ma Google Authenticator è abbastanza nuovo e ADFS 3.0 è abbastanza vecchio che non sarebbe stato possibile farlo questo al momento del rilascio. Inoltre, sarebbe difficile per gli Stati membri mantenerli, quando non hanno alcuna influenza su quando o su quali aggiornamenti potrebbero spingere questi altri fornitori.
Forse quando Windows Server 2016 verrà rilasciato, ADFS aggiornato renderà tutto più semplice. Sembrano aver fatto un po 'di lavoro per un migliore supporto multi-fattore , ma non vedo alcuna nota sull'inclusione dell'autenticatore di un concorrente nella confezione. Al contrario, sembra che vorranno configurare Azure per farlo, e possibilmente fornire un'app iOS / Android / Windows per il proprio concorrente a Authenticator.
Quello che alla fine mi piacerebbe vedere MS consegnare è un generico provider TOTP, dove configuro alcune cose per dire che sto parlando con Google Authenticator, e fa il resto. Forse un giorno. Forse uno sguardo più dettagliato al sistema, una volta che possiamo effettivamente ottenerlo, mostrerà che è lì.
1 Per la cronaca, l'ho fatto. Tieni presente che quando esegui il salto, queste informazioni non si applicano all'imap o ad altre app che utilizzano l'account. In altre parole, stai rompendo gran parte dell'account Google. Per evitare ciò, dovrai anche installare e configurare lo Strumento di sincronizzazione password di Google . Con lo strumento, ogni volta che qualcuno modifica la propria password in Active Directory, il controller di dominio invierà a Google un hash della password da utilizzare con queste altre autenticazioni.
Inoltre, questo è tutto o niente per i tuoi utenti. È possibile limitare in base all'indirizzo IP dell'endpoint, ma non in base agli utenti. Quindi, se hai utenti legacy (ad esempio: utenti ex studenti in un college) che non conoscono le credenziali di Active Directory, farli spostare tutti potrebbe essere una sfida. Per questo motivo, attualmente non sto usando AD FS con Google, anche se spero ancora di fare il salto di qualità. Ora abbiamo fatto quel salto.