MFA for help desk and Active Directory -
step-by-step setup

Weak and reused passwords are one of the most common causes of account takeover. If an attacker steals the password of a help desk technician, they can gain broad access to systems. MFA changes that equation: even with a stolen password, an attacker needs a second factor (phone, token). According to Microsoft, enabling MFA blocks the vast majority of automated account attacks. In this article I show why MFA, which methods to choose, how to deploy it for AD and the help desk, and how to support the team without excessive account lockouts.

Why MFA - risks without MFA

Fact 1: A significant share of security breaches stems from insufficient access controls - mostly lack of MFA or poor password management (credential theft, phishing, password reuse).

Fact 2: Passwords get reused across many services. If one of them is breached, the password may end up in databases used by attackers.

Fact 3: MFA significantly reduces the effectiveness of attacks based on guessing/stealing passwords and on phishing. According to Microsoft, enabling MFA blocks more than 99.9% of automated account attacks - even with the password, an attacker needs the second factor.

Risks without MFA:

• An attacker logs in as a help desk technician with password-reset privileges and can reset the CIO's account
• Lateral movement across the network - if one account is compromised, the rest of the organization is exposed
• Ransomware - the attacker logs in overnight and deploys malware across every machine
• Regulatory non-compliance - NIS2, ISO 27001, SOC 2 require MFA for admin accounts

MFA types - TOTP, SMS, push notification, hardware token

MFA = something you have + something you know. "Something you have" is the second factor:

• TOTP (Time-based One-Time Password): a 6-digit code that changes every 30 seconds. Apps: Google Authenticator, Authy, Microsoft Authenticator. No internet required. Best fit: standard for IT/admin.
• SMS: a 6-digit code sent by SMS. Simple, but vulnerable to SIM swap attacks (the attacker takes over the number). Avoid where possible.
• Push notification: the user gets an "approve login" notification on the phone and taps OK. Convenient, but requires internet and clock sync. Risk: phishing ("approve this").
• Hardware token (YubiKey, Titan): a physical USB-C device with an embedded certificate. The most secure method (phishing-resistant), but carries the cost of buying the devices. Best for C-suite and administrators.

Best practice for an organization:

• IT/Admin/help desk → TOTP (Authenticator app) + backup codes
• Management (50-100 people) → Push notification (Microsoft Authenticator) or TOTP
• Regular users (100-500 people) → Push notification (least friction)
• C-suite/Board → Hardware token (YubiKey)

MFA method comparison table (cost, security, UX)

MFA integration with Active Directory and Azure AD

On-Premises AD (Windows Server 2019+):

• Use Azure AD Connect + Azure AD MFA Cloud - a hybrid model
• On-premises AD checks the password, Azure cloud checks MFA
• The employee signs in to the machine → password + MFA code in the Authenticator app
• Backup: emergency access (a Global Admin account kept offline in a safe)

Azure AD (cloud-native):

• Native MFA support - Microsoft Authenticator app, SMS, OATH tokens
• Conditional Access Policies - require MFA for sign-ins from unknown locations, legacy browsers, etc.
• Configuration: Azure Portal → Users → Per-user MFA (deprecated) or Security → MFA (modern)
• Phishing-resistant sign-in: Windows Hello for Business (facial/fingerprint recognition) + FIDO2 keys

Rollout plan - 4 phases, timeline, support

• Phase 1: Pilot (IT/Admin, 20 people, 1-2 days)

  Set up the Authenticator app, test AD login, distribute backup codes. Feedback loop - fix common issues (token drift, app reinstall).

• Phase 2: Management (50 people, 3-5 days)

  5-minute training video, roll out push notifications (less friction than TOTP). Help desk ready for 50+ requests per day.

• Phase 3: Knowledge Workers (80 people, 7-10 days)

  Push notifications setup, adoption-rate monitoring. Tracking: every 2 days review % adoption vs timeline (target 80% per day).

• Phase 4: Guests/Contractors (50 people, 2-3 days, optional)

  Conditional Access - MFA only when accessing from external IPs. Contractors keep their TOTP setup as part of the same rollout.

Common problems - locked accounts, token drift, legacy apps

Problem 1: "I lost / forgot my Authenticator"

Fix: backup codes (8-10 one-time codes generated at setup, stored securely). If both the Authenticator and the backup codes are lost, an administrator resets MFA (requires verification).

Problem 2: Token drift (the 123456 code is rejected even though it looks right)

Cause: the phone clock is out of sync with the server (time skew > 1 minute). Fix: Settings > Date/Time > Auto-synchronize. Or in the Authenticator app: "Account settings > correct time drift".

Problem 3: Legacy apps (SharePoint 2013, Oracle DB) do not support MFA

Fix: App Passwords in Azure AD - dedicated 32-character passwords for legacy apps (no MFA). Alternative: Conditional Access rules (MFA only for browser, not for direct API access). Migration plan: a 2-year timeline for legacy app modernization.

Problem 4: "The employee didn't get the SMS code"

Best practice: don't use SMS. If you must, keep TOTP as a backup. The SMS network may be overloaded or the carrier may block delivery.

FAQ