Implementing Google Authenticator (TOTP) for Active Directory Logins: Native Support in Windows Server 2016+?


46 views

Many enterprises running Windows Server environments want to implement Time-based One-Time Password (TOTP) authentication (RFC 6238) for Active Directory domain logins, similar to how they secure cloud services like AWS. The expectation was that Windows Server 2016 would natively support this through AD, but current implementations require workarounds.

Windows Server does offer some MFA options out of the box:

  • Smart card authentication
  • Windows Hello for Business
  • Certificate-based authentication

However, none of these provide the TOTP functionality that tools like Google Authenticator offer.

While not natively supported in AD, here are practical ways to implement TOTP for AD logins:

1. Using RADIUS with Network Policy Server

This is the most common enterprise approach:

# Example PowerShell for NPS configuration
Import-Module Nps
$radius = New-NpsRadiusClient -Name "MFA Server" -Address "192.168.1.100" -SharedSecret "YourSecureKey"
Set-NpsRadiusClient -Name "MFA Server" -VendorName "RFC 6238" -AuthAttributeRequired $true

Pair this with a TOTP-compatible RADIUS server like FreeRADIUS with the privacyIDEA plugin.

2. Custom Credential Provider

You can develop a custom Windows Credential Provider that adds TOTP verification:

// C# example for credential provider structure
public class TOTPCredentialProvider : ICredentialProvider
{
    public void SetUsageScenario(UsageScenario cpus, uint dwFlags)
    {
        // Implementation for TOTP field injection
    }
    
    public int GetSerialization(...)
    {
        // Add TOTP verification logic here
        if (!VerifyTOTP(userInput, secretKey))
            return ERROR_INVALID_PASSWORD;
    }
}

3. Duo Security or Similar Commercial Solutions

Third-party tools like Duo offer:

  • Pre-built integrations with AD
  • Support for multiple 2FA methods including TOTP
  • Detailed logging and reporting

Several technical and business factors likely contribute:

  • Enterprise focus on FIDO2/WebAuthn standards
  • Existing investment in Windows Hello and smart cards
  • Security concerns about TOTP seed management
  • Preference for push notification MFA in their ecosystem

Here's a basic workflow for implementing TOTP with AD using FreeRADIUS:

  1. Set up FreeRADIUS server with privacyIDEA
  2. Configure NPS on Windows Server as RADIUS proxy
  3. Deploy TOTP seed generation during user provisioning:
# Python example for TOTP seed generation
import pyotp
import active_directory

def provision_user(username):
    user = active_directory.find_user(username)
    secret = pyotp.random_base32()
    user.setTOTPSecret(secret)  # Store in custom AD attribute
    qr_url = pyotp.totp.TOTP(secret).provisioning_uri(username)
    return qr_url

While Windows Server 2022 still doesn't natively support TOTP in AD, Microsoft is focusing on:

  • Passwordless authentication with Windows Hello
  • Azure AD integration with authenticator apps
  • FIDO2 security key support

For on-prem AD, third-party solutions remain the most practical path for TOTP implementation today.


The user has a specific use case where they want to implement 2FA for logging into Active Directory, similar to how Google Authenticator works. Their desired solution is an RFC - based MFA system like Google Authenticator, which is widely used in internet - based apps and is already familiar to their user base. They hope that by adding 2FA to AD, other apps using AD as the directory will also benefit from it.

Currently, logins to desktops and PCs are via plain passwords. However, some tools like their VPN server use AD for authentication and also support Google Authenticator on top. They aim to make physical logins as secure as VPN logins using a similar authentication tool.

There is a Technet article about using Google Authenticator with Active Directory Federated Services (AD FS) at https://blogs.technet.microsoft.com/cloudpfe/2014/10/26/using-time-based-one-time-passwords-for-multi-factor-authentication-in-ad-fs-3-0/. But it seems to be a development project that requires code and its own SQL database. And the user is not specifically interested in AD FS, but rather in 2FA with Google Authenticator RFC support built into AD.

Windows Server 2016 does not have native support for Google Authenticator - based 2FA in Active Directory. Microsoft might have made this decision due to various reasons. One could be that they have their own Microsoft - specific multi - factor authentication solutions, such as Azure Multi - Factor Authentication. These solutions are tightly integrated with Microsoft's ecosystem and might be seen as more suitable for enterprise environments from a Microsoft's perspective.

To implement Google Authenticator - like 2FA in AD, one approach could be to use custom development. Here is a high - level example in C# (assuming you are using a.NET environment to interact with AD). First, you need to install the necessary NuGet packages for working with AD.
csharp
using System.DirectoryServices.AccountManagement;
// Other necessary imports

public class AD2FAAuthenticator
{
public bool AuthenticateUser(string username, string password, string otp)
{
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "YOUR_DOMAIN_NAME"))
{
UserPrincipal user = UserPrincipal.FindByIdentity(context, username);
if (user == null)
{
return false;
}
// Here, you would need to implement the OTP verification logic.
// For example, if you have stored the Google Authenticator secret in AD for each user
// You can use a library like Google.Authenticator to verify the OTP
// Google.Authenticator.TotpGenerator generator = new Google.Authenticator.TotpGenerator();
// bool isValidOtp = generator.IsValidCode(user.GoogleAuthenticatorSecret, otp);
// And also verify the password
bool isValidPassword = context.ValidateCredentials(username, password);
return isValidPassword && isValidOtp;
}
}
}

This is a very basic example. In a real - world scenario, you would need to handle errors properly, manage the storage of Google Authenticator secrets securely in AD, and integrate with the actual AD infrastructure more comprehensively.