MFA för Windows fjärrskrivbord och inloggning
Lägg till Mideye tvåfaktorsautentisering (MFA) direkt på Windows inloggningsskärm, en inbyggd credential provider-DLL som skyddar varje fjärrskrivbord (RDP) och varje konsol-inloggning. Installeras vid sidan av din befintliga Mideye-installation utan ändringar i backenden.
Drop-in per maskin. Moln eller air-gapped on-prem. Distribueras via MSI eller Group Policy.
När Mideye Credential Provider är installerad efterfrågar Windows inloggningsskärm en andra faktor innan någon användare släpps in. Användaren skriver sitt Windows-lösenord som vanligt; Mideye begär sedan en Touch-Accept i Mideye+-appen, en SMS magic link, eller en hårdvaru-token-OTP. Windows slutför inloggningen endast när MFA lyckas. Aktiveringen omfattar RDP och konsolen samtidigt, och Windows standardruta döljs inte förrän en riktig Mideye-inloggning har bevisat att värden faktiskt kan släppa in någon.
Varför MFA vid själva inloggningen?
Din Mideye Authentication Service hanterar redan multifaktorautentisering för VPN, RADIUS-skyddade applikationer, ADFS och RDS. Mideye Credential Provider utökar det skyddet till den plats dessa integrationer inte når, själva Windows inloggningsskärmen, på varje värd där användare loggar in via fjärrskrivbord (RDP) eller sitter vid konsolen.
Stulna inloggningsuppgifter är den ledande vägen för ransomware på Windows-flottor. Credential providern fångar varje RDP- och konsol-inloggning, oavsett vilken applikation användaren är på väg till.
Pratar med samma Mideye Authentication API eller on-prem Mideye Server som du redan använder för RADIUS, ADFS och RDS-integrationer. En signerad MSI lägger ner två COM-DLL:er och ett konfigurationsverktyg, ingen ny backend, ingen ny identitetslagring, inga AD-schemaändringar.
On-prem-läget pratar enbart med din lokala Mideye Server via en statisk Bearer-token, utan att värden behöver internetåtkomst. Alla metoder är tillgängliga; en helt air-gappad server faller tillbaka till hårdvaru-token-OTP.
Så fungerar det, kort sagt
En kort översikt av vad credential providern gör och var den passar in. Genomgångar av själva inloggningsupplevelsen kommer senare. Videon är på engelska.
Så autentiserar användarna
Tre metodgrupper levereras idag. Credential providern väljer åt användaren utifrån vad som är konfigurerat för hen. Touch-Accept startar direkt där den är tillgänglig, och ett val erbjuds bara som reserv, när pushen inte kan levereras eller besvaras och det finns en token att falla tillbaka på.
Touch-Accept (Mideye+-appen) Moln + on-prem
Användarens Mideye+-app ringer; ett tryck på Godkänn slutför inloggningen. SMS-magic-link som reservalternativ för användare utan installerad app. Minskar risken för nätfiske eftersom det inte finns någon engångskod att lura av användaren.
Hårdvaru-token-OTP Moln + on-prem
Engångskoder från HID Approve- och YubiKey-hårdvarutokens, samt från valfri standard OATH-HOTP-token. Tryck på knappen eller knacka på nyckeln, skriv in koden, klart. Den enda metoden som även fungerar helt air-gapped.
Assisted Login (4-ögon-godkännande) Moln + on-prem
Användaren begär; en godkännare på en separat telefon bekräftar. I molnläge kan godkännare vara lokala SAM-användare, AD-domänanvändare eller externa telefon-kontakter utan Windows-konto på värden. I on-prem-läge kommer godkännarlistan från Assisted Login-profilen på din Mideye Server, alltså central hantering i stället för per maskin.
Moln eller on-prem, välj per maskin
Ett enda registervärde (`Mode`) väljer backenden. Samma MSI, samma konfigurationsverktyg, samma dokumentation.
- OAuth2 client credentials → Mideye Authentication API
- Touch-Accept, SMS-magic-link, hårdvaru-token-OTP, Assisted Login
- Server-Sent Events för omedelbar inloggningsåterkoppling
- Endast utgående HTTPS, port 443
- Statisk Bearer-token → lokal Mideye Server
- Touch-Accept, SMS-magic-link, hårdvaru-token-OTP, Assisted Login
- TOTP-självregistrering vid inloggningsskärmen
- Värden behöver ingen internetåtkomst
On-prem är inget nedbantat läge. Värden skickar ett användar-id och Mideye Server slår själv upp telefonnummer eller token, och når Mideye-molnet åt värden där en telefonmetod kräver det - Windows-värden behöver alltså aldrig internetåtkomst. En server helt utan molnkanal rapporterar det, och inloggningsrutan faller tillbaka till hårdvaru-token-OTP i stället för att låta användaren vänta.
Säkra standardvärden, inga överraskningar
Credential providern är byggd för att fail-closed utan att låsa ut dig, hålla hemligheter borta från icke-administratörer och hålla PII borta från loggarna.
En felkonfigurerad installation är tyst inaktiv, inte utlåsande. Aktivering vägrar utan minst en konfigurerad Break-Glass-principal.
API-uppgifter lagras i en registernyckel som bara SYSTEM och administratörer kan läsa, och skrivs aldrig till loggar eller exporter. De lämnar aldrig värddatorn.
Telefonnummer och token-serienummer maskeras i varje loggrad, även i felsökningsläge. Break-Glass-inloggningar revisionsspåras individuellt via Windows Event Log.
Distribution
En signerad MSI, tre distributionsvägar:
Pilotinstallation på en enskild värd, guide, licens, installera, konfigurera.
SCCM, skriptade utrullningar, anpassad orkestrering. JSON-konfiguration per värd appliceras separat.
Software Installation-policy + ett startup-skript som applicerar JSON-konfigurationen per OU. AD-anslutna flottor.
Vart läser man härnäst
Vad varje del gör: installation, registerkonfiguration, moln / air-gapped, inloggningsschema, Break-Glass, per-användar-overrides, godkännare, anpassning.
Från noll till MFA på RDP på ~10 minuter, installera, klistra in Client ID och Secret, lägg till Break-Glass, aktivera, framtvinga på RDP.
Hur credential provider-DLL:n kopplar in i Windows LogonUI; MFA-beslutsstegen; flödesdiagram för moln + on-prem.
Vanliga frågor
Hur lägger jag till MFA på Windows fjärrskrivbord (RDP)?
Installera den signerade Mideye Credential Provider-MSI:n på varje Windows-värd där RDP terminerar, klistra in Client ID och Secret från din Mideye Authentication Service, konfigurera minst en Break-Glass-principal och aktivera sedan. Det tar cirka 10 minuter per värd. Aktiveringen omfattar RDP och konsolen samtidigt, och den skyddar sig själv först: MFA krävs från första inloggningen, men Windows standardruta är kvar tills värden har genomfört en lyckad Mideye-inloggning på den ytan. En konfiguration som inte kan släppa in någon lämnar därmed en väg in i stället för att låsa maskinen. När en riktig inloggning har bevisat värden blir Mideye den enda rutan.
Fungerar Mideye Credential Provider utan internet?
Ja. I on-prem-läge pratar credential providern enbart med din lokala Mideye Server, via en statisk Bearer-token, och själva värden behöver ingen internetåtkomst. On-prem är inte ett nedbantat läge: Touch-Accept och Assisted Login fungerar också där, eftersom Mideye Server gör de anropen åt värden. På en helt air-gappad server, som rapporterar att den saknar molnkanal, faller inloggningsrutan tillbaka till hårdvaru-token-OTP, som inte behöver något nät alls. Ett enda registervärde väljer moln eller on-prem per maskin.
Vilka Windows-versioner stöds?
Windows Server 2019, 2022 och 2025, samt Windows 11 (23H2 eller senare). Endast x64. Varje DLL-ändring verifieras i labbet på en klient av vardera Server 2019, 2022 och 2025 före release, eftersom credential provider-beteendet skiljer sig mellan versionerna på sätt som kan låsa ute användare. Både Active Directory-anslutna och workgroup / fristående värdar stöds. Windows 10 och Windows Server 2016 stöds inte - båda lämnar Microsofts support i januari 2027. Entra-ID-anslutna och hybridanslutna maskiner är ännu inte testade.
Redo att utvärdera Mideye Credential Provider?
Kör 10-minuters-snabbstarten på en test-VM, eller prata med oss om ett pilotprojekt i din miljö.