Verificatie zonder wachtwoord met Microsoft Intune

Verificatie zonder wachtwoord vermindert phishing en diefstal van referenties door wachtwoorden te vervangen door sterkere aanmeldingsmethoden, zoals Windows Hello, FIDO2-beveiligingssleutels, wachtwoordsleutels, certificaten, aanmelding via microsoft Authenticator-telefoon en tijdelijke toegangspas.

Microsoft Intune geeft geen referenties zonder wachtwoord uit. In plaats daarvan worden apparaten, apps en gebruikerservaringen voorbereid, zodat deze methoden zonder wachtwoord betrouwbaar op schaal werken. Microsoft Entra ID is de identiteitsinstantie die referenties verifieert en verificatie en beleid voor voorwaardelijke toegang afdwingt, terwijl Microsoft Intune apparaatinstellingen configureert, naleving afdwingt en de platformmogelijkheden inschakelt waarvan deze methoden afhankelijk zijn. Samen bieden Microsoft Entra ID en Microsoft Intune de identiteitsbasis en apparaatgereedheid die nodig zijn om verificatie zonder wachtwoord te implementeren op verschillende platforms en formulierfactoren.

De ervaring zonder wachtwoord verschilt per platform. In Windows omvat dit meestal zowel apparaat-aanmelding als app-toegang via eenmalige aanmelding. In macOS richt het zich op platformverificatie en eenmalige aanmelding in apps, in plaats van een diepe apparaatgebonden identiteit. Op iOS/iPadOS en Android richt het zich vaker op app-aanmelding, brokered-verificatie en wachtwoordsleutelgedrag dan op apparaataanmelding. Houd rekening met dit onderscheid bij het evalueren van platformvereisten en het plannen van de implementatie.

In dit artikel wordt uitgelegd hoe Microsoft Intune een strategie zonder wachtwoord ondersteunt vanuit het perspectief van een beheerder. Voor implementatiedetails volgt u de implementatiekoppelingen voor elke methode zonder wachtwoord.

Hoe de oplossing zonder wachtwoord van Microsoft werkt

De oplossingsparen zonder wachtwoord van Microsoft Microsoft Entra ID voor identiteit en eenmalige aanmelding (SSO) met Microsoft Intune voor apparaatconfiguratie en beleidshandhaving. Met deze combinatie kunnen gebruikers zich verifiëren met behulp van sterke referenties, zoals biometrie, FIDO2-beveiligingssleutels of wachtwoordsleutels, zonder wachtwoorden in te voeren.

Microsoft Entra ID is de belangrijkste id-provider. Het controleert referenties zonder wachtwoord, zoals Windows Hello pincodes, FIDO2-sleutels en wachtwoordsleutels. Na een geslaagde verificatie geeft Microsoft Entra ID een PRT (Primary Refresh Token) of een equivalent uit, waardoor naadloze eenmalige aanmelding mogelijk is voor Microsoft 365, Azure en andere beveiligde resources. Beleid voor voorwaardelijke toegang evalueert de apparaatstatus, verificatiesterkte en risicosignalen voordat toegang wordt verleend.

Microsoft Intune bereidt apparaten voor op aanmelding zonder wachtwoord door instellingen te configureren, naleving af te dwingen, vereiste apps te implementeren en de platformervaringen te ondersteunen die wachtwoordloos op schaal praktisch maken. Microsoft Intune biedt beheerders één beheervlak voor Windows, macOS, iOS/iPadOS en Android.

Platformmogelijkheden in Windows, macOS, iOS en Android bieden de apparaatgebonden ervaring, waaronder biometrie, beveiligde hardware (TPM op Windows, Secure Enclave op macOS), ondersteuning voor wachtwoordsleutels en brokered eenmalige aanmelding.

Deze scheiding is belangrijk. Microsoft Entra ID is de identiteitsinstantie. Microsoft Intune is de beheerlaag waarmee gebruikers deze methoden kunnen gebruiken en gebruiken.

Wachtwoordloze, MFA- en phishing-weerstand

Verificatie zonder wachtwoord elimineert geen beveiligingsfactoren. De meeste methoden zonder wachtwoord voldoen daadwerkelijk aan MFA-vereisten (MultiFactor Authentication). Windows Hello gebruikt bijvoorbeeld een apparaatgebonden referentie (bezit) gekoppeld aan een biometrische beweging (inherence) of een pincode (kennis) die voldoet aan MFA. Als gevolg hiervan classificeren beleidsregels voor verificatie van voorwaardelijke toegang veel methoden zonder wachtwoord als MFA-compatibel of zelfs als phishing-resistente MFA.

Niet alle opties zonder wachtwoord bieden hetzelfde beveiligingsniveau. Als u het verschil begrijpt tussen phishingresistente en niet-phishingbestendige methoden, kunt u de juiste verificatiesterkten selecteren en een veilige identiteitsstrategie ontwerpen.

  • Phishingresistente methoden gebruiken hardwaregebonden, asymmetrische cryptografische sleutels die niet kunnen worden onderschept of opnieuw kunnen worden afgespeeld, zelfs niet als een gebruiker communiceert met een kwaadwillende of vervalste prompt.
  • Niet-phishingbestendige methoden maken gebruik van stromen zonder wachtwoord, maar kunnen nog steeds worden gecompromitteerd door social engineering, prompt manipulatie of MFA-vermoeidheid.

Elke methode die verderop in dit artikel wordt beschreven, bevat het niveau van phishingresistentie.

Meer informatie

Voordelen van verificatie zonder wachtwoord met Microsoft Intune

Wanneer u Microsoft Intune, Microsoft Entra ID en platformmogelijkheden samen gebruikt, krijgt uw organisatie er voordeel van:

  • Naadloze eenmalige aanmelding: gebruikers melden zich eenmaal aan bij het apparaat en krijgen automatisch toegang tot apps, cloudservices en - in sommige gevallen - on-premises resources. Oproepen voor wachtwoordherstel en herhaalde verificatieprompts worden geëlimineerd.
  • Gebruikerscomfort op verschillende apparaten: gebruikers krijgen een systeemeigen, consistente ervaring op verschillende apparaten. Windows Hello gebruikmaakt van aanmelding via het besturingssysteem, integreert macOS Touch ID met Microsoft Entra ID en mobiele platforms maken gebruik van Microsoft Authenticator en platform-wachtwoordsleutels. Gebruikers hoeven geen afzonderlijke wachtwoorden per apparaat te gebruiken.
  • Sterkere beveiligingspostuur: phishingbestendige methoden voorkomen diefstal van referenties en herhalingsaanvallen. Het beperken van apparaatnaleving zorgt ervoor dat zelfs geldige referenties alleen werken vanaf gezonde, beheerde apparaten, afgestemd op Zero Trust principes.
  • Minder it-ondersteuningsbelasting: minder wachtwoordherstel, soepelere onboarding met tijdelijke toegangspas en opties voor selfserviceherstel verminderen het helpdeskvolume.
  • Architectuur die klaar is voor de toekomst: naarmate de standaarden zich ontwikkelen, kunnen nieuwe methoden zonder wachtwoord, waaronder gesynchroniseerde wachtwoordsleutels en referenties met hardware-ondersteuning, worden aangesloten op dezelfde Microsoft Entra ID + Microsoft Intune architectuur zonder dat er een groot nieuw ontwerp nodig is.

Hoe Microsoft Intune leidt tot acceptatie zonder wachtwoord

Microsoft Intune maakt verificatie zonder wachtwoord mogelijk en operationeel door ervoor te zorgen dat apparaten en toepassingen correct zijn geconfigureerd voor het gebruik van sterke, moderne referenties. Hoewel Microsoft Entra ID het identiteits- en verificatiebeleid beheert, bereidt Microsoft Intune de apparaatomgeving voor waar methoden zonder wachtwoord van afhankelijk zijn.

Belangrijke bijdragen zijn:

  • Apparaatgereedheid: apparaten registreren, registreren en configureren, zodat ze kunnen deelnemen aan aanmeldingsstromen zonder wachtwoord.
  • Configuratie-implementatie: het beleid leveren dat is vereist voor Windows Hello voor Bedrijven, verificatie op basis van certificaten, eenmalige aanmelding van Apple Platform en vergelijkbare platformmogelijkheden.
  • Signalen voor naleving en toegang: het verstrekken van gegevens over de status en naleving van het apparaat die door voorwaardelijke toegang worden geëvalueerd voordat toegang wordt verleend.
  • Inrichting van apps en brokers: het implementeren van kerntoepassingen, zoals Microsoft Authenticator en Microsoft Intune Bedrijfsportal, die identiteitsbrokering en scenario's zonder wachtwoord mogelijk maken.
  • Geïntegreerd platformoverschrijdend beheer: biedt een consistent beleids- en beheerframework voor Windows, macOS, iOS/iPadOS en Android om de bedrijfsimplementatie te stroomlijnen.

De methoden zonder wachtwoord die beschikbaar zijn voor gebruikers, zijn afhankelijk van zowel het apparaatplatform als de verificatieopties die zijn ingeschakeld in Microsoft Entra ID. Microsoft Intune zorgt ervoor dat elk apparaat is voorbereid, geconfigureerd en in staat is om een veilige en betrouwbare ervaring zonder wachtwoord te leveren.

Windows Hello

Phishing-bestendig

Windows Hello vervangt wachtwoorden door een apparaatgebonden asymmetrische sleutel die wordt gegenereerd en verzegeld met de TPM. De toegang tot de sleutel wordt beheerd door een pincode of biometrische beweging (vingerafdruk of gezichtsherkenning), waarbij bezit en inherentie worden gecombineerd in een stap voor eenmalige aanmelding. Deze methode wordt door hardware ondersteund en is bestand tegen phishing voor Windows-apparaten.

de rol van Intune
Microsoft Intune bereidt Windows-apparaten voor op Windows Hello door Windows Hello voor Bedrijven beleidsinstellingen te leveren en af te dwingen.

Deze methode is het meest relevant wanneer u het volgende moet doen:

  • Cloud-first Windows-apparaten voorbereiden voor aanmelding zonder wachtwoord.
  • Lever Windows Hello voor Bedrijven beleidsinstellingen tijdens inschrijving en doorlopend beheer.
  • Stem Windows-aanmelding uit met apparaatcompatibiliteit en modern beheer.

Meer informatie

FIDO2-beveiligingssleutels

Phishing-bestendig

FIDO2-beveiligingssleutels zijn fysieke apparaten (USB, NFC of Bluetooth) die een FIDO-referentie opslaan en phishingbestendige verificatie bieden zonder afhankelijk te zijn van het apparaatplatform. Omdat de referentie is gebonden aan de hardwaresleutel en is geverifieerd via een cryptografische uitdaging, kan deze niet worden onderschept of opnieuw worden afgespeeld. FIDO2-sleutels zijn ideaal voor gedeelde apparaten, omgevingen met hoge betrouwbaarheid of als herstelpad naast platformreferenties.

de rol van Intune
Microsoft Intune kunt u helpen apparaten gereed te maken voor deze methode door ondersteunde platforms en gerelateerde aanmeldingservaringen te beheren.

Deze methode is vaak een goede oplossing wanneer organisaties het volgende nodig hebben:

  • Een draagbare optie zonder wachtwoord voor gedeelde of gespecialiseerde apparaten.
  • Een sterk phishingbestendige optie die niet is gekoppeld aan één platform of aan Microsoft Authenticator.
  • Een herstel of alternatief pad naast referenties op basis van het platform.

Zie voor richtlijnen bij de implementatie:

Sleutels

Phishing-bestendig

Wachtwoordsleutels zijn de op standaarden gebaseerde paraplu voor FIDO-referenties die apparaatgebonden of gesynchroniseerd kunnen worden tussen apparaten. In Microsoft Entra ID kunt u het volgende gebruiken:

  • Apparaatgebonden wachtwoordsleutels die zijn opgeslagen in beveiligde hardware (TPM of Secure Enclave) op één apparaat, zoals via Windows Hello of Microsoft Authenticator op iOS 17+ en Android 14+.
  • Gesynchroniseerde wachtwoordsleutels die worden beheerd door platformwachtwoordbeheerders (zoals iCloud-sleutelhanger of Google Password Manager) of ondersteunde externe providers, die gebruik tussen apparaten mogelijk maken.
  • Microsoft Entra wachtwoordsleutel in Windows is een FIDO2-wachtwoordsleutel die gebruikmaakt van Windows Hello voor biometrische verificatie, maar waarvoor geen apparaatdeelname of registratie is vereist. Gebruikers kunnen meerdere wachtwoordsleutels registreren voor meerdere Microsoft Entra accounts op hetzelfde apparaat, waardoor het geschikt is voor gedeelde apparaten, onbeheerde eindpunten en scenario's waarin Windows Hello voor Bedrijven niet is ingericht.

de rol van Intune
Vanuit een Microsoft Intune perspectief hebben wachtwoordsleutels voornamelijk betrekking op platform- en app-gereedheid: het beheren van de apparaat- en app-vereisten die de acceptatie van wachtwoordsleutels op verschillende platforms mogelijk maken.

Deze afhankelijkheid is met name belangrijk voor:

  • Windows, waar platform-aanmelding en Windows Hello elkaar kunnen kruisen met een bredere planning zonder wachtwoord. Microsoft Entra wachtwoordsleutel in Windows breidt de dekking van wachtwoordsleutels uit naar apparaten die niet zijn ingeschreven of die niet zijn gekoppeld, als aanvulling op Windows Hello voor Bedrijven op beheerde apparaten.
  • iOS/iPadOS en Android, waarbij wachtwoordsleutels afhankelijk kunnen zijn van de status van mobiele apparaten en het gedrag van app-brokers.
  • macOS, waar integratie van platformidentiteit en gebruikersaanmelding de acceptatie vorm geeft.

Zie voor richtlijnen bij de implementatie:

Microsoft Authenticator-telefoon aanmelden

Niet phishingbestendig

Met microsoft Authenticator-telefoonaanmelding worden wachtwoorden vervangen door goedkeuring op basis van push en nummerkoppeling op het vertrouwde mobiele apparaat van de gebruiker. Het is handig en wordt algemeen ondersteund, maar is afhankelijk van pushmeldingen in plaats van hardware-gebonden referenties, wat betekent dat phishing-aanvallen zoals MFA-promptmanipulatie niet volledig worden voorkomen.

Opmerking

Microsoft Authenticator kan ook apparaatgebonden wachtwoordsleutels (iOS 17+, Android 14+) opslaan, die phishingbestendig zijn . In deze sectie wordt specifiek de push-gebaseerde aanmeldingsstroom voor telefoons behandeld.

de rol van Intune
Microsoft Intune ondersteunt deze stroom door de vereisten voor mobiele apps en apparaten te implementeren en te beheren.

In veel omgevingen omvat deze ondersteuning:

  • Microsoft Authenticator implementeren op beheerde mobiele apparaten.
  • Ondersteuning van de brokered aanmeldingservaring in Microsoft-apps.
  • Houd rekening met overwegingen voor app-beveiligingsbeleid op mobiele platforms wanneer deze deel uitmaken van het bredere ontwerp voor mobiele toegang.

Zie voor richtlijnen bij de implementatie:

Tijdelijke toegangspas

Geen permanente methode die wordt gebruikt voor onboarding en herstel

Tijdelijke toegangspas (TAP) is een tijdsgebonden referentie die een beheerder geeft om gebruikers te helpen bij het opstarten of herstellen van toegang voordat ze hun langdurige wachtwoordloze installatie voltooien. TAP is geen permanente methode zonder wachtwoord en is niet bestand tegen phishing, maar het is vaak een essentieel onderdeel van een geslaagde implementatie, omdat hiermee het probleem met de eerste aanmelding wordt opgelost zonder een wachtwoord uit te geven.

de rol van Intune
Vanuit een Microsoft Intune perspectief is tijdelijke toegangspas van belang wanneer u het volgende wilt doen:

  • Vereenvoudig onboarding naar methoden zonder wachtwoord.
  • Verminder de afhankelijkheid van tijdelijke wachtwoorden tijdens de implementatie.
  • Onboardingscenario's verbinden met de installatie van beheerde Windows-apparaten.

Dag-nul onboarding met TAP

Een veelvoorkomende uitdaging bij implementaties zonder wachtwoord is het kip-en-ei-probleem : een nieuwe gebruiker moet zich aanmelden om zijn wachtwoordloze referenties te registreren, maar u wilt geen wachtwoord uitgeven voor die eerste aanmelding. TAP lost dit probleem op door een kortstondige referentie op te geven voor de eerste installatie van het apparaat en de registratie van referenties.

Een typische onboardingstroom ziet er als volgt uit:

  1. Beheer geeft een TAP uit: de IT-beheerder of geautomatiseerde werkstroom genereert een tijdelijke TAP voor de nieuwe gebruiker in de Microsoft Entra-beheercentrum of via Microsoft Graph API.
  2. Gebruiker stelt zijn of haar apparaat in: de gebruiker voert de TAP in tijdens de inschrijving van Windows Autopilot OOBE, de macOS-installatie assistent of de inschrijving van mobiele apparaten. Op Windows 11 kunt u via webaanmelding tap-invoer rechtstreeks op het vergrendelingsscherm inschakelen.
  3. Gebruiker registreert een methode zonder wachtwoord: nadat hij zich heeft aangemeld met de TAP, wordt de gebruiker gevraagd om Windows Hello, een FIDO2-beveiligingssleutel, een wachtwoordsleutel in Microsoft Authenticator of een andere methode zonder wachtwoord te registreren. Dit is de permanente referentie die de TAP vervangt.
  4. TAP verloopt : de TAP is eenmalig of in de tijd beperkt (configureerbaar), zodat deze niet opnieuw kan worden gebruikt nadat de gebruiker de methode zonder wachtwoord heeft geregistreerd.

Met deze stroom hoeft u geen tijdelijk wachtwoord uit te geven en vervolgens in te trekken en geeft Microsoft Intune een beheerd onboardingpad vanaf de eerste aanmelding.

Zie voor richtlijnen bij de implementatie:

Verificatie op basis van certificaten (CBA)

Phishing-bestendig

Verificatie op basis van certificaten (CBA) maakt gebruik van digitale certificaten en asymmetrische cryptografie om de identiteit te verifiëren, waardoor deze bestand is tegen phishing en het opnieuw afspelen van referenties voorkomt. Het wordt algemeen gebruikt in gereguleerde branches en overheidsomgevingen, vaak via smartcards zoals PIV en CAC. In tegenstelling tot andere methoden zonder wachtwoord waarbij Microsoft Intune voornamelijk de apparaatomgeving voorbereidt, is CBA een gebied waar Microsoft Intune een directe rol speelt bij het distribueren van de referentie zelf.

de rol van Intune
Microsoft Intune ondersteunt twee infrastructuurmodellen voor de levering van certificaten:

  • On-premises PKI: organisaties met een bestaande certificeringsinstantie (CA) kunnen de certificaatconnector voor Microsoft Intune gebruiken om hun on-premises PKI te overbruggingen met Microsoft Intune. Met de connector kunnen Microsoft Intune SCEP- en PKCS-certificaatprofielen implementeren op beheerde apparaten met behulp van uw bestaande CA-infrastructuur. Dit model is geschikt voor organisaties die al een ondernemings-CA uitvoeren of moeten integreren met gevestigde PKI-investeringen.
  • Microsoft Cloud PKI: Voor organisaties die de on-premises certificaatinfrastructuur willen vereenvoudigen of elimineren, biedt Microsoft Cloud PKI een cloudgebaseerde CA als onderdeel van de Microsoft Intune Suite. Cloud PKI problemen en beheert certificaten zonder dat on-premises servers, connectors of hardwarebeveiligingsmodules nodig zijn.

Ongeacht het infrastructuurmodel levert Microsoft Intune certificaten aan apparaten met behulp van certificaatprofielen:

  • Vertrouwde basiscertificaatprofielen distribueren het basiscertificaat van uw CA, zodat apparaten de vertrouwensketen kunnen opzetten.
  • SCEP-certificaatprofielen aanvragen en certificaten implementeren van een CA met SCEP-functionaliteit.
  • PKCS-certificaatprofielen aanvragen en implementeren certificaten met behulp van de PKCS #12-standaard.
  • Geïmporteerde PFX-certificaatprofielen implementeren vooraf gegenereerde certificaten die worden geïmporteerd in Microsoft Intune.

Deze profielen werken in Windows, macOS, iOS/iPadOS en Android, waardoor Microsoft Intune het leveringsmechanisme waarmee uw PKI-infrastructuur ( on-premises of in de cloud) wordt verbonden met de identiteitsmethode die is gedefinieerd in Microsoft Entra ID.

Zie voor richtlijnen bij de implementatie:

Vereisten

Voordat u een implementatie zonder wachtwoord plant, controleert u of uw omgeving voldoet aan de licentie- en platformvereisten voor de methoden die u wilt gebruiken. Voor sommige functies zonder wachtwoord zijn specifieke Microsoft Entra ID- of Microsoft Intune licentielagen vereist en elke methode heeft minimale vereisten voor de versie van het besturingssysteem.

Licentievereisten

Afhankelijk van de methoden zonder wachtwoord die u kiest, heeft uw organisatie mogelijk Microsoft Entra ID P1- of Microsoft Entra ID P2-licenties voor gebruikers nodig, evenals specifieke Microsoft Intune licenties voor apparaatbeheer en levering van certificaten. De volgende tabel bevat een overzicht van de licentievereisten voor algemene mogelijkheden zonder wachtwoord:

Functie Licentievereiste
Windows Hello Microsoft Entra ID P1 (voor het afdwingen van voorwaardelijke toegang)
FIDO2-beveiligingssleutels Microsoft Entra ID P1
Wachtwoordsleutels (apparaatgebonden en gesynchroniseerd) Microsoft Entra ID P1
Microsoft Authenticator-telefoon aanmelden Microsoft Entra ID P1
Tijdelijke toegangspas Microsoft Entra ID P1
Verificatie op basis van certificaten (CBA) Microsoft Entra ID P1 (P2 voor op risico's gebaseerde voorwaardelijke toegang)
Beleid voor verificatiesterkte Microsoft Entra ID P1
Op risico gebaseerde voorwaardelijke toegang Microsoft Entra ID P2
Microsoft Cloud PKI Microsoft Intune Suite of zelfstandige Cloud PKI-invoegtoepassing
Apparaatcompatibiliteits- en configuratieprofielen Microsoft Intune Plan 1

Meer informatie

Platformvereisten

De methoden zonder wachtwoord die in dit artikel worden beschreven, zijn afhankelijk van specifieke platformmogelijkheden die alleen beschikbaar zijn in bepaalde versies van het besturingssysteem. De volgende tabel bevat een overzicht van de platformvereisten voor elke methode:

Methode Windows macOS iOS/iPadOS Android
Windows Hello Alle ondersteunde Windows-clients — — —
FIDO2-beveiligingssleutels Alle ondersteunde Windows-clients — — —
Sleutels Windows 11 Alle ondersteunde versies Alle ondersteunde versies Android 14+
Apparaatgebonden wachtwoordsleutels in Microsoft Authenticator — — Alle ondersteunde versies Android 14+
Platform SSO (Secure Enclave) — Alle ondersteunde versies — —
Webaanmelding (TIKKEN bij vergrendelingsscherm) Windows 11 — — —
Microsoft Authenticator-telefoon aanmelden — — Alle ondersteunde versies Android 11+

Opmerking

Ondersteund verwijst naar besturingssysteemversies die Microsoft Intune momenteel ondersteunt voor volledige functionaliteit, beleidsimplementatie en beheer.
De vereisten voor platformversies kunnen veranderen met elke releasecyclus. Controleer altijd de huidige vereisten in de productdocumentatie voor de specifieke methode die u implementeert.

Meer informatie

Platformoverwegingen

Wachtwoordloos is niet één functie. Het is een set platformspecifieke ervaringen die afhankelijk zijn van Microsoft Entra ID voor identiteit en Microsoft Intune voor apparaatbeheer.

Windows

Windows is het meest complete voorbeeld van hoe apparaatinschrijving, cloudaanmelding, beveiligingspostuur en gebruikerservaring zonder wachtwoord samenwerken.

Microsoft Intune ondersteunt meestal Scenario's zonder wachtwoord voor Windows door:

  • Cloud-first, Microsoft Entra gekoppelde apparaten voorbereiden.
  • Het leveren van Windows Hello voor Bedrijven configuratie.
  • Ondersteuning van FIDO2-beveiligingssleutelervaringen.
  • Apparaatgereedheid afstemmen op naleving en modern beheer.
  • Ondersteuning van onboarding-ervaringen die verbinding kunnen maken met Windows Autopilot.

Wanneer een gebruiker zich aanmeldt met Windows Hello of een FIDO2-sleutel, verkrijgt Windows een primair vernieuwingstoken van Microsoft Entra ID. Deze PRT maakt naadloze eenmalige aanmelding mogelijk voor Microsoft 365-apps, SaaS-toepassingen en - wanneer Cloud Kerberos Trust is geconfigureerd - on-premises resources zoals bestandsshares, allemaal zonder extra aanmeldingsprompts.

Meer informatie

Hybride en verouderde overwegingen

De ervaringen zonder wachtwoord die in dit artikel worden beschreven, gaan uit van een cloud-first-richting met Microsoft Entra gekoppelde apparaten. Organisaties met hybride Microsoft Entra gekoppelde apparaten moeten rekening houden met deze verschillen:

  • Webaanmelding (gebruikt voor TAP op het vergrendelingsscherm van Windows) wordt alleen ondersteund op Microsoft Entra gekoppelde apparaten, niet op hybride Microsoft Entra gekoppelde apparaten.
  • Windows Hello voor Bedrijven werkt op zowel Microsoft Entra gekoppelde als hybride Microsoft Entra gekoppelde apparaten, maar voor hybride implementaties is mogelijk extra infrastructuur vereist, afhankelijk van het vertrouwensmodel.
  • Voor toegang tot on-premises resources vanaf Microsoft Entra gekoppelde apparaten is een Kerberos-cloudvertrouwensrelatie of een vertrouwensrelatie op basis van certificaten vereist. Cloud Kerberos-vertrouwensrelatie is het aanbevolen model omdat hiervoor geen certificaten hoeven te worden geïmplementeerd voor Kerberos-verificatie. Zie [implementatie van kerberos-vertrouwensrelatie in de cloud](/windows/security/identity-protection/> hello-for-business/deploy/hybrid-cloud-kerberos-trust) voor meer informatie.
  • Verouderde toepassingen waarvoor Active Directory Kerberos-verificatie is vereist, kunnen nog steeds werken met methoden zonder wachtwoord, maar toepassingen waarvoor NTLM of directe LDAP-binding is vereist, hebben mogelijk extra planning nodig.

Als uw omgeving hybride is, plant u uw implementatie zonder wachtwoord, te beginnen met Microsoft Entra gekoppelde apparaten en breidt u deze uit naar hybride Microsoft Entra gekoppelde apparaten naarmate uw infrastructuur dit ondersteunt.

Meer informatie

macOS

In macOS is het plannen zonder wachtwoord afhankelijk van hoe Microsoft Entra ID integreert met het platform voor aanmelding en eenmalige aanmelding. Microsoft Intune levert de apparaatconfiguratie die nodig is voor identiteitsintegraties op Apple.

Met de Microsoft Enterprise SSO-invoegtoepassing en het Platform SSO-framework van Apple kunnen Microsoft Intune een configuratie implementeren waarmee gebruikers zich kunnen aanmelden bij de Mac met hun Microsoft Entra ID referenties. Wanneer deze is geconfigureerd met de secure enclave-sleutelmethode, biedt dit een phishing-bestendige aanmeldingservaring met hardware die vergelijkbaar is met Windows Hello.

Deze informatie is van belang wanneer u van plan bent:

  • Platform-SSO en gerelateerde aanmeldingservaringen.
  • Eenmalige aanmelding tussen het apparaat en Microsoft-apps.
  • Een consistent beheermodel naast Windows- en mobiele apparaten.

Meer informatie

iOS en iPadOS

Op iOS en iPadOS richt planning zonder wachtwoord zich meer op app-aanmelding, brokered verificatie en wachtwoordsleutelgedrag dan op apparaataanmelding. Microsoft Intune implementeert en beheert de apps en instellingen die deze ervaringen consistent maken voor gebruikers.

De Microsoft SSO-extensie op iOS kan verificatieaanvragen onderscheppen in microsoft- en apps van derden, waardoor naadloze aanmelding mogelijk is na de eerste installatie van het apparaat. Microsoft Authenticator fungeert als verificatiebroker en kan ook apparaatgebonden wachtwoordsleutels opslaan op iOS 17+ voor phishingbestendige verificatie.

Meer informatie

Android

Op Android stelt Microsoft Intune de beheerde context vast waar verificatiestromen zonder wachtwoord en brokering van afhankelijk zijn. Deze context is met name relevant wanneer Microsoft Authenticator of gerelateerde app-ervaringen deel uitmaken van uw mobiele toegangsontwerp.

Zowel Bedrijfsportal als Microsoft Authenticator kunnen fungeren als verificatiebrokers op Android. Nadat een gebruiker zich via de broker heeft aangemeld, geeft Microsoft Entra ID een primair vernieuwingstoken uit waarmee eenmalige aanmelding mogelijk is voor alle brokerbewuste apps in het werkprofiel. Op Android 14+ kan Microsoft Authenticator ook apparaatgebonden wachtwoordsleutels opslaan voor phishingbestendige verificatie.

Meer informatie

Afhankelijkheden voor verificatie zonder wachtwoord

Zero Trust architectuur

Verificatie zonder wachtwoord maakt deel uit van een bredere strategie voor identiteits- en apparaattoegang. Voor een Microsoft Intune-beheerder omvat planning meestal deze lagen:

  • Identiteit: phishingresistente verificatiemethoden in Microsoft Entra ID.
  • Apparaatvertrouwen: Microsoft Intune inschrijving, naleving en configuratie.
  • Toegangsbeleid: voorwaardelijke toegang en gerelateerde planning van uitsluitingen.
  • Gegevensbescherming: Microsoft Purview-mogelijkheden waarmee u inhoud kunt beveiligen nadat toegang is verleend.
  • Onderzoek en reactie: Microsoft Defender signalen en werkstromen wanneer risico's of compromissen moeten worden opgevolgd.

Meer informatie

Voorwaardelijke toegang

Voorwaardelijke toegang evalueert signalen zoals apparaatstatus en verificatiesterkte voordat toegang wordt verleend. In combinatie met methoden zonder wachtwoord kan voorwaardelijke toegang beleidsregels voor verificatiesterkte afdwingen waarvoor phishingresistente MFA is vereist, waardoor wachtwoordloos wordt afgedwongen door zwakkere methoden zoals wachtwoorden of sms-codes te blokkeren.

Wanneer u voorwaardelijke toegang naast wachtwoordloos implementeert, moet u ook rekening houden met het plannen van noodtoegang om onbedoelde vergrendelingsscenario's te voorkomen.

Meer informatie

Toegang en herstel in noodgevallen

Een veelvoorkomend probleem bij het verwijderen van wachtwoorden is wat er gebeurt wanneer een gebruiker zijn enige apparaat zonder wachtwoord verliest: een telefoon, een FIDO2-sleutel of een laptop met Windows Hello. Zonder een herstelplan kunnen beheerders te maken krijgen met escalaties van ondersteuning en kunnen gebruikers worden uitgesloten van kritieke resources.

Plan deze scenario's als onderdeel van uw implementatie zonder wachtwoord:

  • Accounts voor noodtoegang: onderhoud ten minste twee break-glass-accounts die zijn uitgesloten van beleid voor voorwaardelijke toegang en afdwingen zonder wachtwoord. Deze accounts bieden een terugvalpad als een onjuiste configuratie of storing alle andere toegang blokkeert. Sla referenties veilig op en bewaak de aanmeldingsactiviteiten voor deze accounts.
  • Herstel met tijdelijke toegangspas: wanneer een gebruiker zijn apparaat zonder wachtwoord verliest, kan een beheerder een nieuwe TAP uitgeven, zodat de gebruiker zich kan aanmelden en een vervangende referentie kan registreren. Deze benadering voorkomt dat de gebruiker opnieuw wordt instellen op een wachtwoord en houdt de herstelstroom binnen het model zonder wachtwoord.
  • Meerdere geregistreerde methoden: moedig gebruikers aan om waar mogelijk meer dan één methode zonder wachtwoord te registreren. Een gebruiker die Hello voor Bedrijven op zijn laptop gebruikt, kan bijvoorbeeld ook een wachtwoordsleutel registreren in Microsoft Authenticator op zijn telefoon. Als het ene apparaat verloren gaat, werkt de andere methode nog steeds.
  • Selfservicereferentiebeheer: gebruikers kunnen hun verificatiemethoden beheren via Mijn beveiligingsgegevens. In combinatie met herstel op basis van TAP vermindert deze aanpak de helpdeskafhankelijkheid voor het opnieuw instellen van referenties.
  • Herstel van totaal verlies met Geverifieerde ID: voor scenario's waarin een gebruiker alle geregistreerde referenties en apparaten verliest, biedt Microsoft Entra accountherstel met behulp van Geverifieerde ID een door identiteit geverifieerd herstelpad dat niet afhankelijk is van wachtwoorden of referenties die door de helpdesk zijn uitgegeven.

Het plannen van herstel voordat u zonder wachtwoord afdwingt, is essentieel. Een implementatie die wachtwoorden blokkeert zonder herstelpad, creëert het soort vergrendelingsscenario's die het vertrouwen van beheerders en gebruikers in de overgang aantasten.

Meer informatie

Naleving en apparaatgereedheid

Wachtwoordloos is vaak afhankelijk van de juiste status van het apparaat voordat gebruikers op de ervaring kunnen vertrouwen. Gereedheid omvat doorgaans:

Verificatie en lopende bewerkingen

Om een implementatie zonder wachtwoord te valideren, zijn veelvoorkomende controlepunten:

Gebruikersacceptatie en communicatie

Technische gereedheid is slechts één onderdeel van een implementatie zonder wachtwoord. Gebruikers die gewend zijn aan wachtwoorden kunnen verwarring of weerstand ervaren wanneer aanmeldingsstromen worden gewijzigd. Het plannen van communicatie en ondersteuning van gebruikers kan het verschil maken tussen een soepele overgang en een wijdverspreide helpdesk-escalatie.

Houd rekening met deze procedures:

  • Communiceer de wijziging vroeg: laat gebruikers weten dat hun aanmeldingservaring verandert, waarom deze verandert en wat ze kunnen verwachten. Richt u op de voordelen: minder wachtwoorden om te onthouden, snellere aanmelding en betere beveiliging.
  • Platformspecifieke richtlijnen bieden: de ervaring zonder wachtwoord is anders in Windows (biometrische of pincode voor Hello), macOS (Touch ID met Platform SSO), iOS (Authenticator of wachtwoordsleutels) en Android (Authenticator-broker). Pas de communicatie aan op de platformen die uw gebruikers hebben.
  • Testgroepen identificeren: begin met een groep gebruikers die de ervaring kunnen testen en feedback kunnen geven voordat u wachtwoordloos in de organisatie afdwingt. IT-medewerkers, early adopters en beveiligingsbewuste teams zijn vaak goede kandidaten.
  • Helpdeskmedewerkers voorbereiden: zorg ervoor dat uw ondersteuningsteam weet hoe u een tijdelijke toegangspas moet uitgeven voor herstel, hoe u gebruikers door referentieregistratie begeleidt en waar u aanmeldingslogboeken kunt controleren wanneer zich problemen voordoen.

Meer informatie

  • Last updated on