Vanliga frågor och svar om Identity Protection i Azure Active Directory

Ignorera kända problem med användarrisker

Stäng användarrisk i klassiska Identity Protection anger aktören i användarens riskhistorik i Identity Protection till Azure AD.

Stäng användarrisken i Identity Protection anger aktören i användarens riskhistorik i Identity Protection till <Admin’s name with a hyperlink pointing to user’s blade> .

Det finns ett aktuellt känt problem som orsakar svarstiden i flödet för risk för avstängning av användare. Om du har en "Användarriskprincip" slutar den här principen att tillämpas på avvisade användare inom några minuter efter att du klickat på "Stäng användarrisk". Det finns dock kända fördröjningar med att UX uppdaterar "risktillståndet" för avvisade användare. Som en tillfällig lösning kan du uppdatera sidan på webbläsarnivå för att se den senaste användarens "Risktillstånd".

Vanliga frågor och svar

Varför är en användare i riskzonen?

Om du är Azure AD Identity Protection kund går du till vyn för riskfyllda användare och klickar på en användare i riskzonen. I lådan längst ned på fliken Riskhistorik visas alla händelser som ledde till en ändring av användarrisken. Om du vill se alla riskfyllda inloggningar för användaren klickar du på "Användarens riskfyllda inloggningar". Om du vill se alla riskidentifieringar för den här användaren klickar du på "Användarens riskidentifiering".

Varför blockerades min inloggning men Identity Protection genererade ingen riskidentifiering?

Inloggningar kan blockeras av flera orsaker. Det är viktigt att observera att Identity Protection endast genererar riskidentifiering när rätt autentiseringsuppgifter används i autentiseringsbegäran. Om en användare använder felaktiga autentiseringsuppgifter flaggas den inte av Identity Protection eftersom det inte finns någon risk för att autentiseringsuppgifter komprometteras såvida inte en felaktig aktör använder rätt autentiseringsuppgifter. Några orsaker till att en användare kan blockeras från signering som inte genererar en Identity Protection-identifiering är:

  • IP-adressen kan blockeras på grund av skadlig aktivitet från IP-adressen. Det IP-blockerade meddelandet skiljer inte på om autentiseringsuppgifterna var korrekta eller inte. Om IP-adressen blockeras och rätt autentiseringsuppgifter inte används genereras ingen identitetsskyddsidentifiering
  • Smart utelåsning kan blockera kontot från att logga in efter flera misslyckade försök
  • En princip för villkorsstyrd åtkomst kan tillämpas som använder andra villkor än risknivån för att blockera en autentiseringsbegäran

Hur kan jag få en rapport över identifieringar av en viss typ?

Gå till vyn riskidentifiering och filtrera efter Identifieringstyp. Du kan sedan ladda ned den här rapporten i .CSV eller . JSON-format med knappen Ladda ned längst upp. Mer information finns i artikeln How To: Investigate risk.

Varför kan jag inte ange egna risknivåer för varje riskidentifiering?

Risknivåerna i Identity Protection baseras på precisionen för identifieringen och drivs av vår övervakade maskininlärning. Om du vill anpassa vilka upplevelseanvändare som visas kan administratören inkludera/exkludera vissa användare/grupper från användarrisken och Sign-In riskprinciper.

Varför matchar inte platsen för en inloggning var användaren verkligen loggade in från?

IP-geoplatsmappning är en branschomfattande utmaning. Om du anser att den plats som anges i inloggningsrapporten inte matchar den faktiska platsen kan du kontakta Microsoft Support.

Hur stänger jag specifika riskidentifieringar som jag gjorde i det gamla användargränssnittet?

Du kan ge feedback om riskidentifiering genom att bekräfta att den länkade inloggningen är komprometterad eller säker. Den feedback som ges vid inloggningen går till alla identifieringar som görs vid inloggningen. Om du vill stänga identifieringar som inte är länkade till en inloggning kan du ge den feedbacken på användarnivå. Mer information finns i artikeln How to: Give risk feedback in Azure AD Identity Protection.

Hur långt kan jag gå tillbaka i tiden för att förstå vad som händer med min användare?

Hur kan jag lära mig mer om en specifik identifiering?

Alla riskidentifieringar dokumenteras i artikeln Vad är risk. Du kan hovra över symbolen (i) bredvid identifieringen på Azure Portal om du vill veta mer om en identifiering.

Hur fungerar feedbackmekanismerna i Identity Protection?

Bekräfta komprometterad (vid inloggning) – informerar Azure AD Identity Protection att inloggningen inte utfördes av identitetsägaren och indikerar en kompromettering.

  • När vi får den här feedbacken flyttar vi inloggnings- och användarrisktillståndet till Bekräftad komprometterad och risknivå till Hög.

  • Dessutom tillhandahåller vi informationen till våra maskininlärningssystem för framtida förbättringar av riskbedömningen.

    Anteckning

    Om användaren redan är åtgärdad klickar du inte på Bekräfta komprometterad eftersom inloggnings- och användarrisktillståndet flyttas till Bekräftad komprometterad och risknivån till Hög.

Bekräfta säker (vid inloggning) – Informerar Azure AD Identity Protection att inloggningen utfördes av identitetsägaren och inte indikerar att det har komprometterats.

  • När vi får den här feedbacken flyttar vi risktillståndet för inloggning (inte användaren) till Bekräftad säker och risknivån till - .

  • Dessutom tillhandahåller vi informationen till våra maskininlärningssystem för framtida förbättringar av riskbedömningen.

    Anteckning

    Att välja Bekräfta säker vid en inloggning förhindrar i dag inte på egen hand framtida inloggningar med samma egenskaper från att flaggas som riskfyllda. Det bästa sättet att träna systemet att lära sig en användares egenskaper är att använda principen för riskfyllda inloggningar med MFA. När en riskabel inloggning efterfrågas för MFA och användaren svarar på begäran, kan inloggningen lyckas och hjälpa till att träna systemet på den legitima användarens beteende.

    Om du tror att användaren inte har komprometterats använder du Stäng användarrisk på användarnivå i stället för att använda Bekräftad säker på inloggningsnivå. En Stäng användarrisk på användarnivå stänger användarrisken och alla tidigare riskfyllda inloggningar och riskidentifiering.

Varför ser jag en användare med en låg (eller högre) riskpoäng, även om inga riskfyllda inloggningar eller riskidentifieringar visas i Identity Protection?

Med tanke på att användarrisken är kumulativ till sin natur och inte upphör att gälla, kan en användare ha en användarrisk på en låg eller högre nivå även om det inte nyligen finns några riskfyllda inloggningar eller riskidentifieringar som visas i Identity Protection. Den här situationen kan inträffa om den enda skadliga aktiviteten på en användare ägde rum utöver den tidsram som vi lagrar information om riskfyllda inloggningar och riskidentifiering för. Vi upphör inte att gälla användarrisk eftersom dåliga aktörer har varit kända för att stanna kvar i kundernas miljö under 140 dagar efter en komprometterad identitet innan attacken. Kunder kan granska användarens risktidslinje för att förstå varför en användare är i riskzonen genom att gå till: Azure Portal > Azure Active Directory > Risky users’ report > Click on an at-risk user > Details’ drawer > Risk history tab

Varför har en "inloggningsrisk (aggregering)" en poäng på Hög när de identifieringar som är associerade med den är av låg eller medelhög risk?

Den höga aggregerade riskpoängen kan baseras på andra funktioner i inloggningen eller det faktum att fler än en identifiering utades för den inloggningen. Och omvänt kan en inloggning ha en inloggningsrisk (aggregering) på Medel även om de identifieringar som är associerade med inloggningen har hög risk.

Vad är skillnaden mellan identifieringarna "Aktivitet från anonym IP-adress" och "Anonym IP-adress"?

Källan för Anonym IP-adress"-identifieringen Azure AD Identity Protection identifieringen av "Aktivitet från anonym IP-adress" är integrerad från Microsoft Defender för Molnappar). De har mycket liknande namn och du kan se överlappningar i dessa signaler, men de har distinkta identifieringar på backend-plats.