Active Directory + Google Authenticator - AD FS, or how?

We need to look at what's going on here.

AD FS is all about SAML. It will connect to Active Directory to use it as a SAML Identity Provider. Google already has the ability to act as a SAML Service Provider. Put the two together, so Google will trust your server's SAML token, and you're logging into a Google Account via Active Directory credentials.¹

Google Authenticator, on the other hand, acts as one factor of an Identity Provider... usually for Google's own service. Maybe you can see now how it doesn't really fit in with AD FS. When using AD FS with Google, you're not really using Google's Identity Provider anymore, and by the time AD FS completes the hand off back to Google, the identity side is already finished. If you did anything, it would be configuring Google to require Authenticator as a supplemental identity confirmation on top of (but separate from) AD FS or other SAML identity providers. (Note: I don't think Google supports this, but they should).

Now, that doesn't mean what you want to do is impossible... just that it's maybe not the best fit. While it's primarily used with Active Directory, AD FS is also designed to function as a more generic SAML service; you can connect it to other identity providers than Active Directory, and it supports many different options and extensions. One of these is the ability to create your own Multi-Factor Authentication providers. Additionally, Google Authenticator supports the TOTP standard for multi-factor authentication.

Put the two together, and it should be possible (though certainly not trivial) to use Google Authenticator as a MuliFactor provider with AD FS. The article you linked to is a proof of concept of one such attempt. However, this isn't something AD FS does out of the box; it is up to each Multi-Factor service to create that plug-in.

Maybe MS could provide first-party support for a few of the big mutli-factor providers (if there is such a thing), but Google Authenticator is new enough and AD FS 3.0 is old enough that it wouldn't have been feasible to do this at the release time. Additionally, it would be challenging for MS to maintain these, when they have no influence on when or what updates these other providers might push.

Maybe when Windows Server 2016 is out the updated AD FS will make this easier. They seem to have done some work for better multi-factor support, but I don't see any notes about including a competitor's authenticator in the box. Instead, it looks like they'll want you to set up Azure to do this, and possibly provide an iOS/Android/Windows app for their own competitor to Authenticator.

What I would ultimately like to see MS deliver is a generic TOTP provider, where I configure a few things to tell it that I'm talking to Google Authenticator, and it does the rest. Maybe someday. Maybe a more detailed look at the system, once we can actually get it, will show it's in there.

^{1 For the record, I've done this. Be aware that when you make the jump, this information will not apply to imap or other apps that use the account. In other words, you're breaking a huge part of the Google account. In order to avoid this, you'll also need to install and configure Google's Password Sync Tool. With the tool, every time someone changes their password in Active Directory, your domain controller will send a hash of the password to Google for use with these other authentications.}

^{Additionally, this is all or nothing for your users. You can restrict by endpoint IP address, but not based on users. So if you have legacy users (for example: alumni users at a college) who don't know any Active Directory credentials, getting them all moved over could be a challenge. For this reason, I am not currently using AD FS with Google, though I'm still hoping to eventually make the leap. We have now made that leap.}

I think your question makes the invalid assumption that it is Microsoft's job to add support for a particular vendor's 2FA/MFA solution. But there are plenty of 2FA/MFA products that already support Windows and AD because the vendors have chosen to add that support. If Google doesn't think it's important enough to add support, that's not really Microsoft's fault. The Authentication and Authorization related APIs are well documented and free to use.

The blog post you linked to sample code that anyone could write to add RFC6238 TOTP support to their own AD FS environment. That it happens to work with Google Authenticator is just a side effect of the authenticator supporting that RFC. I would also note the litany of disclaimers at the bottom about the code being "proof of concept", "no proper error handling", and "not created with safety in mind".

In any case, no. I don't believe Google Authenticator support will explicitly be be supported in Windows Server 2016. But I don't think anything is preventing Google from adding support themselves on Server 2016 or earlier.

The Answer, as of October 2017:

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

We have researched or tried everything.

• Azure/Microsoft MFA (complex and time consuming to set up, fragile in operation)
• RADIUS servers

While we do not like the operational cost of DUO, for up to 50 users, the cost, to us, is worth the simplicity to set up and use.

We have used it so far behind:

• Cisco ASA devices for VPN access

• Sonicwall Remote Access Appliance for VPN access (with the device doing LDAP also to AD)

We are not aware of any other approach that can be set up in 2-4 hours and MFA enable LDAP services that hang off AD.

We continue to believe that AD itself should support the TOTP/HOTP RFC's behind google authenticator, and are deeply disappointed that MS has not solved this properly in Windows Server 2016.

There is allready a free pluging for One time password authentication with ADFS . It works fine with google or microsoft authenticator apps. See www.securemfa.com for more information. I'm using it without any issues in production.