Active Directory MFA solution

Why is Active Directory MFA needed?

Active Directory is the authentication backbone of most enterprise networks. That makes it the primary target for breach. Attackers don't break through perimeter defenses; they steal credentials and log in as trusted users.

A credential-based attack is any attack that exploits stolen, weak, or compromised passwords to gain unauthorized access. To explain a credential-based attack simply, attackers use techniques like phishing, brute force, or credential stuffing to harvest passwords, then move laterally through your network. This covers everything from pass-the-hash attacks leveraging the Kerberos protocol to large-scale password spray campaigns targeting Active Directory. The only reliable credential-based attacks prevention strategy is adding a second authentication factor that makes stolen passwords worthless on their own.

The attack surface grows significantly in hybrid identity environments where on-premises Active Directory is synchronized with Microsoft Entra ID. A single compromised Active Directory account doesn't just open file servers; it grants access to Microsoft 365, Salesforce, and every connected SaaS application. Over 35% of data breaches involve stolen or weak credentials, as per Verizon's reports, and when your directory underpins access to that much infrastructure, the credential itself becomes the perimeter.

Multi-factor authentication (MFA) is the baseline defense. It adds a second verification factor that an attacker can't extract from a stolen password alone. A phishing campaign that captures valid AD credentials still can't produce an authenticated session without that second factor. The password alone no longer opens the door.

ADSelfService Plus enforces MFA at every Active Directory authentication point, from Windows, macOS, and Linux login screens to VPN gateways and self-service password reset operations, with unified policy coverage across on-premises AD identities from a single console.

How Active Directory MFA works

ADSelfService Plus inserts a second verification layer immediately after the Active Directory credential check. The domain controller still performs its standard role; ADSelfService Plus initiates the MFA challenge before the session proceeds. The sequence looks like this:

1. Domain controller check: The domain controller validates the user's AD credentials via NLM pass-through, exactly as it always has.
2. MFA challenge: ADSelfService Plus presents a second-factor prompt via the configured authenticator: a push notification, a TOTP code from an authenticator app, a FIDO2 security key tap, a biometric scan, or another of the 20 plus supported methods.
3. Identity verification: The response is verified against the authenticator app, hardware token, or the ADSelfService Plus server.
4. Access granted: After all verification layers pass, the session proceeds and the user is logged in.

The MFA process for on-premises Active Directory access is not cloud-dependent. The Windows login agent (GINA/Credential Provider), the macOS login plugin, and the Linux PAM integration all intercept the OS-level authentication event locally, with no mandatory cloud routing for core MFA verification.

Cached credentials handle the offline scenario. When a Windows or macOS endpoint has no network connection, offline MFA authenticates using locally cached authenticator state, so remote workers who need to log in before a VPN connection is established aren't blocked.

Supported authentication methods and factors

MADSelfService Plus ships with more than 20 authenticators across the three classical authentication factor categories.

Something you know

Security questions: They are more suited for lower-risk scenarios and fallback verification. They are the weakest factor in the set and should always be paired with a stronger second method.

Something you have

• TOTP authentication: Google Authenticator, Microsoft Authenticator, Zoho OneAuth, and other compatible apps generate a time-based one-time code every 30 seconds, computed locally on the device. Intercepting the network connection during generation yields nothing to an attacker.
• Push notification authentication: A login attempt triggers an approve or deny request to the user's registered mobile device with no code to type or shared secret in transit. It is offered natively by the ADSelfService Plus Android and iOS apps.
• FIDO2 security keys: Compatible passkey hardware signs the authentication challenge using a private key that never leaves the device. Responses are cryptographically bound to the origin domain, making FIDO2 phishing-resistant by design. It also supported for passwordless login into compatible applications.
• Smart card authentication: PIV-compliant smart cards deliver certificate-based two-factor authentication for government agencies and regulated financial institutions.
• Hardware TOTP tokens: Physical tokens generate codes without a smartphone or mobile network, making it the practical choice for air-gapped or device-restricted environments.
• Backup verification codes: One-time recovery codes generated at enrollment, deployed strictly as a last-resort recovery mechanism, not a routine login path.

Something you are

• Biometric authentication: Fingerprint and face ID matching runs on the user's iOS or Android device; only the verification result reaches the server. This local-processing model supports GDPR and HIPAA compliance for biometric data handling.

Phishing-resistant vs. traditional methods

Compared to basic SMS-based verification, phishing-resistant methods like FIDO2 keys and biometric authentication offer significantly stronger protection against phishing attacks. While TOTP codes provide good security for most use cases, organizations handling sensitive data should consider upgrading to passwordless methods for the best protection against phishing. For privileged accounts and executive users, enforce FIDO2 or biometrics as the required second factor.

Where to enforce MFA across your AD environment

Securing Active Directory means closing every authentication path, not just the web portal. ADSelfService Plus enforces MFA across all Active Direcgory access points, including machine logins, VPN connections, remote sessions, cloud applications, and self-service password management.

Secure machine access

• Windows macOS and Linux logins: Login agents for Windows, macOS, and Linux enforce additional factors at the OS level before access is granted. Windows Credential Provider covers interactive logins and RDP sessions. MFA for UAC prompts extends protection to elevated privilege requests.
• Offline MFA: The locally cached authenticator state lets remote and traveling workers complete the MFA challenge without a network connection. This addresses a critical gap that most competitors overlook.
• MFA for Outlook on the web: A dedicated MFA layer secures Outlook on the web and the Exchange admin center, blocking unauthorized mailbox access even when valid Active Directory credentials have been compromised.

Fortify VPN logins

ADSelfService Plus acts as a RADIUS authentication server, extending MFA to any RADIUS-supporting VPN gateway, including Citrix Gateway, VMware Horizon, and Microsoft Remote Desktop Gateway, without changes to existing VPN infrastructure. LDAP authentication is also supported for compatible network access devices. The VPN forwards the credential; ADSelfService Plus fires the MFA challenge and returns an accept or reject, securing remote workforce access to Active Directory resources at the authentication layer.

Protect enterprise application access

ADSelfService Plus' SSO uses SAML 2.0 and OAuth 2.0 to deliver one-click access to over 100 cloud applications authenticated against Active Directory identities. MFA protects the single SSO authentication event, covering every application in the session. Combining SSO security with adaptive MFA means the authentication gate adjusts to the risk profile of each access attempt.

Conditional access policies

Applying the same MFA challenge to every login wastes friction on low-risk sessions while doing nothing extra for high-risk ones. Conditional access policies fix that by connecting the authentication requirement to the actual context of the access attempt.

ADSelfService Plus evaluates access context against configured policy conditions before triggering an MFA challenge. Conditions include IP address or range, device identity, browser type, time of access, geolocation, and business hours. Each conditional access policy maps to one of three outcomes: allow without a challenge, require a specific set of authenticators, or block access entirely.

Conditional access examples show how this works in practice. Users inside the corporate IP range during work hours skip the MFA prompt; users outside the corporate range always see it; logins from geographic locations outside the defined allowlist are blocked outright.

Different OUs and Acitve Directory groups can carry different MFA and conditional access rules, so a department with high data sensitivity gets stricter conditions than a general staff group.

Privileged account protection

Domain admins, enterprise admins, and service account owners are what attackers reach for after initial compromise. Privileged account protection requires MFA as a mandatory control—admin accounts are the highest-value targets, and privileged account security demands stricter policies than standard user accounts. ADSelfService Plus helps applies stricter MFA policies specifically to privileged account groups, independently of the policy in place for standard users. A typical privileged account protection configuration can include FIDO2 security keys or smart card authentication for accounts in the Domain Admins group, while standard end users may have TOTP or push notification.

MFA enrollment management

ADSelfService Plus offers enforced MFA enrollment that requires users to register their MFA methods on first login before accessing other portal features. Coverage doesn't rely on users remembering to enroll themselves. For large deployments, CSV-based bulk enrollment pre-registers MFA configurations without requiring individual end-user action.

The solution supports Windows login script enrollment that captures users who never access the web portal. Built-in MFA enrollment reports show which users are enrolled, which aren't, and which authenticators each user has registered, so the IT team can identify coverage gaps before an incident surfaces.

Key benefits of implementing Active Directory MFA with ADSelfService Plus

Active Directory MFA delivers concrete security outcomes, not just audit checkmarks.

• Blocks credential-based attacks at the gate: A stolen password without the succeeding authentication factors can't produce an authenticated session. Phishing, credential stuffing, and pass-the-hash attacks that capture only the password fail at the MFA challenge.
• Phishing-resistant protection for high-value accounts: FIDO2 security keys and biometric authentication are origin-bound, making them immune to credential harvesting even from sophisticated phishing attempts.
• Reduces help desk ticket volume: Self-service password reset with MFA-backed identity verification eliminates password reset tickets without removing the authentication gate. Users reset their own passwords; the second-factor requirement stays.
• Risk-adaptive enforcement: High-risk sessions face stronger challenges; low-risk sessions stay friction-free. See the conditional access section for configuration details.
• No infrastructure replacement: ADSelfService Plus integrates with existing Active Directory infrastructure and adds MFA without replacing domain controllers, modifying directory schemas, or disrupting existing authentication flows.

Compliance and phishing protection with Active Directory MFA

ADSelfService Plus' more than14 built-in reports cover authentication attempt logs, MFA enrollment status, failed MFA events, and suspected bypass attempts, all exportable as CSV or PDF on a scheduled or on-demand basis.

Best practices for implementing Active Directory MFA

• Start with administrator accounts. Deploy MFA for domain admins and enterprise admins first—they are the highest-value targets and the safest place to validate the rollout before expanding to the broader user base.
• Require multiple enrolled authenticators per user. A single enrolled method means a single point of failure. Requiring two methods at enrollment eliminates most lockout calls before they happen.
• Apply conditional access policies from day one. Enforce MFA for off-network sessions while allowing lighter challenges on-network—this keeps friction low for most users while concentrating authentication requirements where risk is highest.
• Monitor authentication logs on a defined schedule. ADSelfService Plus surfaces failed MFA attempts, suspected bypass events, and incomplete enrollments. A spike in failures against a specific account is often the earliest signal of a credential stuffing or brute-force campaign.
• Run phishing awareness training alongside deployment. MFA limits the damage a successful phish can do, but users who understand why the second factor exists are less likely to approve a push notification they didn't initiate.

Bolster your Active Directory environment with adaptive MFA, phishing-resistant authentication using FIDO2 passkeys, and granular policies using ADSelfService Plus.