Veelgestelde vragen over Microsoft Entra ID Protection

Bekende problemen met gebruikersrisico's negeren

Als u het gebruikersrisico in Microsoft Entra ID Protection negeert, wordt de actor in de risicogeschiedenis van de gebruiker in ID Protection ingesteld op< Beheer naam met een hyperlink die verwijst naar de blade> van de gebruiker.

Er is een actueel bekend probleem dat latentie veroorzaakt in de ontslagstroom van gebruikersrisico's. Als u een beleid voor gebruikersrisico's hebt, wordt dit beleid niet meer toegepast op gesloten gebruikers binnen enkele minuten nadat u op Gebruikersrisico's sluiten hebt geklikt. Er zijn echter bekende vertragingen bij het vernieuwen van de UX-vernieuwing van de status Risico van gesloten gebruikers. Als tijdelijke oplossing vernieuwt u de pagina op browserniveau om de meest recente gebruikersrisicostatus te zien.

Veelgestelde vragen

Waarom loopt een gebruiker risico?

Het artikel Procedure: Risico onderzoeken biedt een uitleg over waarom een gebruiker risico loopt en hoe u verder kunt onderzoeken.

Waarom is mijn aanmelding geblokkeerd, maar id-beveiliging heeft geen risicodetectie gegenereerd?

Aanmeldingen kunnen om verschillende redenen worden geblokkeerd. Het is belangrijk te weten dat ID Protection alleen risicodetecties genereert wanneer de juiste referenties worden gebruikt in de verificatieaanvraag. Als een gebruiker onjuiste referenties verstrekt, wordt deze niet gemarkeerd door ID Protection, omdat er geen risico bestaat op inbreuk op referenties, tenzij een slechte actor de juiste referenties gebruikt. Enkele redenen waarom een gebruiker kan worden geblokkeerd die geen id-beveiligingsdetectie genereert, zijn onder andere:

  • Het IP-adres kan worden geblokkeerd vanwege schadelijke activiteiten van het IP-adres. Het geblokkeerde IP-bericht maakt geen onderscheid of de referenties juist zijn of niet. Als het IP-adres is geblokkeerd en de juiste referenties niet worden gebruikt, wordt er geen id-beveiligingsdetectie gegenereerd.
  • Smart Lockout kan verhinderen dat het account zich kan aanmelden na meerdere mislukte pogingen.
  • Een beleid voor voorwaardelijke toegang kan worden afgedwongen waarbij andere voorwaarden dan het risiconiveau worden gebruikt om een verificatieaanvraag te blokkeren.

Hoe kan ik een rapport van detecties van een specifiek type krijgen?

Ga naar de weergave risicodetectie en filter op detectietype. U kunt dit rapport vervolgens downloaden in . CSV of . JSON-indeling met behulp van de knop Downloaden bovenaan. Zie het artikel Procedure: Risico onderzoeken voor meer informatie.

Waarom kan ik niet mijn eigen risiconiveaus instellen voor elke risicodetectie?

Risiconiveaus in ID Protection zijn gebaseerd op de precisie van de detectie en aangedreven door onze bewaakte machine learning. Om aan te passen welke ervaring gebruikers worden gepresenteerd, kan de beheerder bepaalde gebruikers/groepen opnemen/uitsluiten van het beleid voor gebruikersrisico's en aanmeldingsrisico's.

Waarom komt de locatie van een aanmelding niet overeen met de locatie waar de gebruiker zich daadwerkelijk heeft aangemeld?

Toewijzing van IP-geolocaties is een uitdaging voor de hele branche. Als u denkt dat de locatie die wordt vermeld in het aanmeldingsrapport niet overeenkomt met de werkelijke locatie, neemt u contact op met microsoft-ondersteuning.

Hoe kan ik specifieke risicodetecties sluiten zoals ik dat in de oude gebruikersinterface deed?

U kunt feedback geven over risicodetecties door de gekoppelde aanmelding te bevestigen als aangetast of veilig. De feedback die wordt gegeven over de aanmeldingsdruppelt omlaag naar alle detecties die zijn uitgevoerd bij die aanmelding. Als u detecties wilt sluiten die niet zijn gekoppeld aan een aanmelding, kunt u die feedback geven op gebruikersniveau. Zie het artikel How to: Give risk feedback in Microsoft Entra ID Protection voor meer informatie.

Hoe ver kan ik teruggaan om te begrijpen wat er met mijn gebruiker gebeurt?

Hoe kan ik meer informatie krijgen over een specifieke detectie?

Alle risicodetecties worden beschreven in het artikel Wat is risico. U kunt de muisaanwijzer op het (i)-symbool naast de detectie bewegen voor meer informatie over een detectie.

Hoe werken de feedbackmechanismen in ID Protection?

Bevestig gecompromitteerd (bij een aanmelding): informeert Microsoft Entra ID Protection dat de aanmelding niet door de eigenaar van de identiteit is uitgevoerd en geeft een inbreuk aan.

  • Na ontvangst van deze feedback verplaatsen we de status aanmeldings- en gebruikersrisico's naar Bevestigd gecompromitteerd en risiconiveau naar Hoog.

  • Daarnaast bieden we de informatie aan onze machine learning-systemen voor toekomstige verbeteringen in de risicoanalyse.

    Notitie

    Als de gebruiker al is hersteld, selecteert u Bevestigen niet gecompromitteerd omdat de aanmeldings- en gebruikersrisicostatus wordt verplaatst naar Bevestigd gecompromitteerd en risiconiveau naar Hoog.

Bevestig veilig (bij een aanmelding): informeert Microsoft Entra ID Protection dat de aanmelding is uitgevoerd door de eigenaar van de identiteit en geeft geen inbreuk aan.

  • Wanneer u deze feedback ontvangt, verplaatsen we de aanmeldingsrisicostatus (niet de gebruiker) naar Bevestigd veilig en het risiconiveau naar Geen.

  • Daarnaast bieden we de informatie aan onze machine learning-systemen voor toekomstige verbeteringen in de risicoanalyse.

    Notitie

    Als u vandaag de optie Bevestigt dat veilig is voor een aanmelding, voorkomt u niet dat toekomstige aanmeldingen met dezelfde eigenschappen als riskant worden gemarkeerd. De beste manier om het systeem te trainen om de eigenschappen van een gebruiker te leren, is door een beleid voor voorwaardelijke toegang te gebruiken met aanmeldingsrisico's en MFA. Wanneer een riskante aanmelding wordt gevraagd om MFA en de gebruiker reageert op de aanvraag, kan de aanmelding slagen en het systeem trainen op het gedrag van de legitieme gebruiker.

    Als u denkt dat de gebruiker niet wordt aangetast, gebruikt u Gebruikersrisico negeren op gebruikersniveau in plaats van Bevestigd veilig te gebruiken op het aanmeldingsniveau. Een gebruikersrisico negeren op gebruikersniveau sluit het gebruikersrisico en alle eerdere riskante aanmeldingen en risicodetecties.

Waarom zie ik een gebruiker met een lage (of hogere) risicoscore, zelfs als er geen riskante aanmeldingen of risicodetecties worden weergegeven in ID Protection?

Gezien het gebruikersrisico cumulatief van aard is en niet verloopt, kan een gebruiker een gebruikersrisico van laag of hoger hebben, zelfs als er geen recente riskante aanmeldingen of risicodetecties zijn die worden weergegeven in ID Protection. Deze situatie kan zich voordoen als de enige schadelijke activiteit op een gebruiker plaatsvond buiten het tijdsbestek waarvoor we de details van riskante aanmeldingen en risicodetecties opslaan. We verlopen het gebruikersrisico niet omdat slechte actoren al lange tijd in de omgeving van klanten blijven voordat ze hun aanval opvoeren. Klanten kunnen de tijdlijn voor risico's van de gebruiker bekijken om te begrijpen waarom een gebruiker risico loopt door naar het Microsoft Entra-beheercentrum > Protection > Identity Protection > Risky-gebruikers > te gaan en een tabblad risicogeschiedenis van gebruikersgegevenslades >> te selecteren. Als u denkt dat de gebruiker niet is aangetast, gebruikt u Gebruikersrisico negeren via Graph API.

Waarom heeft een aanmelding een 'aanmeldingsrisico (aggregaties)' als de detecties die eraan zijn gekoppeld, een laag of gemiddeld risico hebben?

De hoge cumulatieve risicoscore kan zijn gebaseerd op andere functies van de aanmelding of het feit dat er meer dan één detectie is geactiveerd voor die aanmelding. En omgekeerd kan een aanmelding een aanmeldingsrisico (aggregaties) gemiddeld hebben, zelfs als de detecties die zijn gekoppeld aan de aanmelding een hoog risico hebben.

Wat is het verschil tussen de detecties 'Activiteit vanaf anoniem IP-adres' en 'Anoniem IP-adres'?

De bron van detectie van anonieme IP-adressen is Microsoft Entra ID Protection, terwijl de detectie activiteit van anoniem IP-adres is geïntegreerd vanuit Microsoft Defender voor Cloud Apps. Hoewel ze vergelijkbare namen hebben en u mogelijk overlap in deze signalen ziet, hebben ze verschillende back-enddetecties.