Mideye Credential Provider for Windows logon and RDP

The Mideye Credential Provider is a native Windows credential provider DLL that adds MFA to RDP and console logon. The user types their Windows password as usual; the credential provider then prompts for a second factor — a Touch push, a hardware-token OTP, or a code from a standard authenticator app. Windows finishes the logon only when MFA succeeds.

Mideye logon tile on the Windows logon screen — the white-framed Mideye e-mark with the "Mideye MFA" caption, the "Mideye Login" heading, and the Username and Password fields the user fills in exactly as before.

This page is the short story: what each piece does and where to read the full version. Want the 10-minute, hands-on path instead? Go straight to the Quickstart.

Installation

Ships as a single signed MSI — mideye-credential-provider.msi. Run interactively as administrator, or silently with msiexec /i mideye-credential-provider.msi /qn for SCCM and GPO Software Installation rollouts. The MSI lays down two DLLs (MideyeCredentialProvider.dll, MideyeCredentialFilter.dll), the configuration tool, and registers COM. The credential provider is inactive immediately after install — you have to configure it and click Activate before it does anything. → Install

Configuration is stored in the registry

Every Mideye Credential Provider setting lives under one key:

HKLM\SOFTWARE\Mideye\CredentialProvider

The credential-provider DLL re-reads the registry on every logon attempt — no service, no cache. MideyeProviderConfig.exe is a GUI on top of that tree; everything you can do with the GUI you can also do with regedit, reg add, a .reg file, or Group Policy Preferences. The GUI adds input validation, DPAPI encryption for secrets, and audit events (1110) on every save. → Registry reference

Cloud or air-gapped

One registry value (Mode) picks the backend. Cloud mode talks to the Mideye Authentication API over OAuth2 and supports the full set — Touch push, hardware-token OTP, authenticator-app HOTP, and Assisted Login. On-prem / air-gapped mode talks to a LAN-hosted Mideye Server over a static Bearer token and intentionally supports hardware-token OTP only; Touch and Assisted are force-disabled at startup because the on-prem server has no corresponding endpoints. Same MSI, same configuration tool. → Cloud mode · On-prem mode

Not every hour of the week should be treated the same way. The Login Routing tab gives you a 168-cell weekly grid (24 hours × 7 days) where each cell is independently MFA, Assisted Login, or Deny — mix and match in any combination. Presets cover the common cases (always-MFA, always-Assisted, workshift, office-hours-only) and you can paint cells freely from there.

Mideye Credential Provider configuration tool — the Login Routing tab. A weekly grid is painted with green cells for Assisted-login hours, red cells for Deny hours, and the rest set to MFA. Sidebar shows the other tabs. Status pills at the top: Mideye Enabled, RDP Enforced, Console Enforced.

The cell is one input into an 11-step precedence ladder; Break-Glass beats everything, per-user overrides come next, the schedule cell is consulted last. → Login Routing — schedule and precedence

Break-Glass accounts

Break-Glass accounts skip MFA entirely. They are the recovery path if the Mideye backend is unreachable or if a misconfiguration would otherwise lock everyone out — the credential provider refuses to activate without at least one Break-Glass principal. The Break Glass tab lets you add the currently logged-in user in one click, or pick any local SAM account or AD domain principal. Every Break-Glass logon is audited individually (event 5701). → Break-Glass accounts

Per-user overrides

Two overrides let you bend the routing for specific users without rewriting the schedule:

Pin a user to a single MFA method — list a SAM/AD user (or group) under Touch-only or Token-only on the MFA Override tab. That user can authenticate only with the pinned factor. Useful for service-style accounts that must use a hardware token, or for users with no mobile phone but a YubiKey.
Override Deny schedule — for users or groups on the Assisted Login Users tab (or MFA Override), tick Override Deny schedule and they can still log in during red hours via the chosen method. On-call admins get a defensible exception without painting the whole grid green.

→ Login Routing — precedence ladder

External approvers

Assisted Login needs an approver to tap Approve before the user gets in. Approvers can be local SAM users, AD domain users, or External approvers — people who can approve a logon but have no Windows account on the machine (SOC operators, duty supervisors, vendor on-call). External approvers are defined on the External Users tab as Name + Full name + phone number, then picked on the Approvers tab. → Approvers — internal and external rosters

Local user phone/token mapping

For workgroup hosts and untrusted-forest scenarios where AD lookups aren’t available, the Local User Phone/Token tab maps a local SAM username to a phone number (E.164) and an optional hardware-token serial. The credential provider uses these mappings as a fallback when the AD query for mobile / token attribute fails. → User setup — AD attributes and local mappings

Custom prompts for users and approvers

The Customization tab sets the text that appears on the user’s phone during a Touch push or SMS magic-link prompt, and the separate text the approver sees during Assisted Login (SMS body, dialog title, accept/reject button labels, accepted/rejected confirmation text, per-prompt timeout). Available in cloud mode; on-prem deployments configure these strings on the Mideye Server side. → Customization

Security policies

The Security Policies tab applies a hardening profile (NIS2 or Custom) and exposes two security-relevant toggles: resolve the approver roster from AD (recommended) or from the local registry, and enforce strict approver-roster integrity (fail-closed on tamper, warn-only, or off). Several signals are always on and don’t have toggles — NLA misconfiguration warning (event 5501), Safe-Mode policy-tamper detection (event 5602), per-Break-Glass-logon audit (event 5701), PII masking in logs. → Security overview · NIS2 alignment

Debug logs to file

The Diagnostics tab has a one-click Start debug logging button that writes verbose entries to C:\ProgramData\Mideye\credential-provider.log. PII is masked even in debug mode (phone numbers as *** + last 4, token serials as first 2 + … + last 4). Logging auto-stops when the file exceeds 5 MB or when the config window closes. → Troubleshooting — Diagnostics tab

Continue from where you left off

Topic	What it covers
Quickstart	Bare-minimum 10-minute path — install, paste Client ID and Secret, add Break-Glass, activate, enforce on RDP.
Architecture	How the credential provider DLL plugs into Windows LogonUI, the MFA decision ladder, cloud + on-prem flow diagrams, and the filter health watchdog.