10

(Edited to match the understanding of the answer-writers -- New, fresh, clean question posted here: Active Directory + Google Authenticator - Native support in Windows Server?)

Research Done So Far

There is a technet article on how to use google authenticator with Active Directory Federated Services (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/

Oddly, it appears to be a dev project, requiring some code and its own SQL DB.

We are not speaking here of AD FS specifically. We are looking, when you get to it, for 2FA, pref supporting Google Authenticator RFCs, built in to AD.

  • Google Authenticator is a proprietary client. The equivalent would be the RSA token. What you want is an authentication server or service that supports the authenticator that would work with AD FS. I am not familiar with AD FS, but for AD in general, NPS can be used to integrate most 2FA servers because most support RADIUS. If AD FS can use radius for authentication, then you could go ADFS >> NPS/AD >> 2FA server. Just like you would for any VPN etc. – nowen Mar 22 '16 at 20:27
  • @nowen You are incorrect. Per https://en.wikipedia.org/wiki/Google_Authenticator Google authenticator is based on RFC 6238. There are other authenticator apps that implement this RFC also, and they are interchangeable with Google Authenticator. – Jonesome Reinstate Monica Mar 23 '16 at 00:05
  • Correct @samsmith. I meant 'closed source' to clarify that it is no-longer open. – nowen Mar 24 '16 at 13:10
  • @nowen No, you are still off the point. The RFC is public. Lots of companies, including Microsoft, have built authenticator apps that are compatible w google authenticator. Your whole point is off. We are looking for proper MFA in AD (as we require MFA in everything else we do). – Jonesome Reinstate Monica Jan 22 '18 at 18:49
  • I'm probably hair-splitting. ;-). All I mean is that the Google Authenticator product is property of Google Inc. Chrome and Opera are other examples of proprietary software that implement open RFCs and are proprietary. It used to be open-source, but Google converted to a proprietary license. – nowen Jan 23 '18 at 22:12

4 Answers4

10

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.1

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.

Joel Coel
  • 12,910
  • 13
  • 61
  • 99
7

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.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • Not only that, but MS pushes their own MFA in Windows Azure. – blaughw Mar 17 '16 at 18:21
  • Thank you for the detail. Very helpful! We all went a little sideways, so OP enhanced for clarity. – Jonesome Reinstate Monica Mar 18 '16 at 00:21
  • Ryan, you make the invalid assumption that Google Authenticator is a "particular vendor" Actually, it is just an implementation of RFC 6238 https://en.wikipedia.org/wiki/Google_Authenticator I am asking for an RFC-based 2FA solution for AD. I am NOT asking for Google Authenticator in particular (which is actually not possible, since there are other RFC 6238 based apps that are interchangeable with google authenticator) – Jonesome Reinstate Monica Mar 23 '16 at 00:07
  • Respectfully, the original unedited question that I answered specifically asked (with much snark) whether AD had native support for Google Authenticator and if not, whether it was expected in Server 2016. I stand by my original answer to those questions. – Ryan Bolger Mar 23 '16 at 04:22
1

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.

  • For future reference, here's another option, https://www.wikidsystems.com/learn-more/features-benefits/native-active-directory-two-factor-authentication/, but also not TOTP. – nowen Jan 23 '18 at 22:12
-2

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.

  • The issue here is that a free third party plugin, that stores data in SQL server: Smells really off. This needs to come from MS (in the OS), or a reputable security vendor. Thanks for the try! – Jonesome Reinstate Monica Jan 22 '18 at 18:51