Veelgestelde vragen over Microsoft Entra-bewaking en -status

Zie Microsoft Entra ID-licentieverlening om uw Microsoft Entra-editie te upgraden.

Als u al activiteitenlogboekgegevens hebt als een gratis licentie, kunt u deze direct zien. Als u geen gegevens hebt, duurt het maximaal drie dagen voordat de gegevens in de rapporten worden weergegeven.

Als u onlangs bent overgeschakeld naar een Premium-versie (inclusief een proefversie), kunt u in eerste instantie gegevens bekijken tot zeven dagen. Als gegevens worden verzameld, kunt u de afgelopen 30 dagen gegevens zien.

De minimale bevoegdheidsrol voor het weergeven van audit- en aanmeldingslogboeken is Rapportlezer. Andere rollen zijn beveiligingslezer en beveiligingsbeheerder.

Aanmeldings- en auditlogboeken zijn beide beschikbaar voor routering via Azure Monitor. B2C-gerelateerde controlegebeurtenissen zijn momenteel niet opgenomen. Zie Integraties van Microsoft Entra-activiteitenlogboeken en het overzicht van het Graph API-activiteitenlogboek voor meer informatie.

Activiteitenlogboeken van Microsoft 365 en Microsoft Entra delen veel directory-resources. Als u een volledige weergave van de Microsoft 365-activiteitenlogboeken wilt, gaat u naar de Microsoft 365-beheercentrum om office 365-activiteitenlogboekgegevens op te halen. De API's voor Microsoft 365 worden beschreven in het artikel over Microsoft 365 Management-API's .

Verschillende factoren bepalen het aantal logboeken dat u kunt downloaden vanuit het Microsoft Entra-beheercentrum, zoals de grootte van het browsergeheugen, de netwerksnelheden en de rapportage-API's van Microsoft Entra. Over het algemeen werken gegevenssets die kleiner zijn dan 250.000 voor auditlogboeken en 100.000 voor aanmeldings- en inrichtingslogboeken goed met de browserdownloadfunctie. Afhankelijk van het aantal velden dat u hebt opgenomen, kan dit aantal variëren. Als u problemen ondervindt bij het voltooien van grote downloads in de browser, gebruikt u de rapportage-API om de gegevens te downloaden of de logboeken naar een eindpunt te verzenden via diagnostische instellingen.

De actieve filters in het Microsoft Entra-beheercentrum wanneer u met het downloaden begint, bepalen welke specifieke set logboeken u kunt downloaden. Als u bijvoorbeeld filtert op een specifieke gebruiker in het Microsoft Entra-beheercentrum, betekent dit dat uw downloadlogboeken voor die specifieke gebruiker worden opgehaald. De kolommen in de gedownloade logboeken worden niet gewijzigd. De uitvoer bevat alle details van het audit- of aanmeldingslogboek, ongeacht de kolommen die u hebt aangepast in het Microsoft Entra-beheercentrum.

Afhankelijk van uw licentie worden activiteitenlogboeken van Microsoft Entra-id gedurende 7 tot 30 dagen opgeslagen. Zie Bewaarbeleid voor Microsoft Entra-rapporten voor meer informatie.

De opslagretentiefunctie voor diagnostische instellingen wordt afgeschaft. Zie Migreren van opslagretentie van diagnostische instellingen naar levenscyclusbeheer van Azure Storage voor meer informatie over deze wijziging.

Op dit moment is er geen specifieke activiteit in de auditlogboeken voor licentieaankopen of activering. Mogelijk kunt u echter de activiteit 'Resource onboarden naar PIM' van de categorie Resourcebeheer correleren met de aankoop of activering van een licentie. Deze activiteit is mogelijk niet altijd beschikbaar of geeft de exacte details op.

Deze wijzigingen zijn gerelateerd aan hoe MFA en sommige AVG-gebeurtenissen worden verwerkt. Gebeurtenissen zoals het verwijderen van gebruikers of het exporteren van gebruikersgegevens worden vastgelegd in de auditlogboeken, maar de beschrijving van de activiteit kan een beetje cryptisch zijn. We werken aan het verbeteren van deze activiteitslabels. Zie Auditactiviteiten voor een volledige lijst van de activiteiten met betrekking tot de AVG. Deze activiteiten zijn gekoppeld aan de categorie DirectoryManagement.

De signInActivity-resource wordt gebruikt om inactieve gebruikers te vinden die zich al enige tijd niet hebben aangemeld. Het wordt niet in bijna realtime bijgewerkt. Als u de laatste aanmeldingsactiviteit van de gebruiker sneller wilt vinden, kunt u de aanmeldingslogboeken van Microsoft Entra gebruiken om bijna realtime aanmeldingsactiviteiten voor al uw gebruikers te zien.

Het CSV bevat aanmeldingslogboeken voor het type aanmeldingen dat u hebt geselecteerd. Gegevens die worden weergegeven als een geneste matrix in de Microsoft Graph API voor aanmeldingslogboeken, worden niet opgenomen. Beleid voor voorwaardelijke toegang en alleen-rapportgegevens worden bijvoorbeeld niet opgenomen. Als u alle informatie in uw aanmeldingslogboeken wilt exporteren, gebruikt u de functie Gegevensinstellingen exporteren.

Het is ook belangrijk om te weten dat de kolommen in de gedownloade logboeken niet veranderen, zelfs als u de kolommen in het Microsoft Entra-beheercentrum hebt aangepast.

Microsoft Entra ID kan een deel van een IP-adres in de aanmeldingslogboeken redacteren om de privacy van gebruikers te beschermen wanneer een gebruiker mogelijk niet behoort tot de tenant die de logboeken bekijkt. Deze actie vindt plaats in twee gevallen:

• Tijdens aanmeldingen tussen tenants, zoals wanneer een CSP-technicus zich aanmeldt bij een tenant die door CSP wordt beheerd.
• Wanneer onze service de identiteit van de gebruiker niet met voldoende vertrouwen kon bepalen om er zeker van te zijn dat de gebruiker deel uitmaakt van de tenant die de logboeken bekijkt.

Microsoft Entra ID redacts personally identifiable information (PII) gegenereerd door apparaten die niet tot uw tenant behoren om ervoor te zorgen dat klantgegevens worden gegarandeerd. PII wordt niet verspreid over tenantgrenzen zonder toestemming van de gebruiker en de gegevenseigenaar.

Er zijn verschillende redenen waarom aanmeldingsvermeldingen mogelijk worden gedupliceerd in uw logboeken.

• Als een risico wordt geïdentificeerd bij een aanmelding, wordt er direct na het risico een andere bijna identieke gebeurtenis gepubliceerd.
• Als MFA-gebeurtenissen met betrekking tot een aanmelding worden ontvangen, worden alle gerelateerde gebeurtenissen samengevoegd met de oorspronkelijke aanmelding.
• Als het publiceren van partners voor een aanmeldingsgebeurtenis mislukt, zoals het publiceren naar Kusto, wordt een volledige batch gebeurtenissen opnieuw geprobeerd en opnieuw gepubliceerd, wat kan leiden tot duplicaten.
• Aanmeldingsgebeurtenissen waarbij meerdere beleidsregels voor voorwaardelijke toegang zijn betrokken, kunnen worden gesplitst in meerdere gebeurtenissen, wat kan leiden tot ten minste twee gebeurtenissen per aanmeldingsgebeurtenis.

Niet-interactieve aanmeldingen kunnen elk uur een groot aantal gebeurtenissen activeren, zodat ze worden gegroepeerd in de logboeken.

In veel gevallen hebben niet-interactieve aanmeldingen dezelfde kenmerken, met uitzondering van de datum en tijd van de aanmelding. Als de tijdaggregaties zijn ingesteld op 24 uur, worden de logboeken weergegeven om de aanmeldingen tegelijkertijd weer te geven. Elk van deze gegroepeerde rijen kan worden uitgebreid om het exacte tijdstempel weer te geven.

Er zijn verschillende redenen waarom aanmeldingsvermeldingen gebruikers-id's, object-id's of GUID's in het veld gebruikersnaam kunnen weergeven.

• Met verificatie zonder wachtwoord worden gebruikers-id's weergegeven als de gebruikersnaam. Bekijk de details van de betreffende aanmeldingsgebeurtenis om dit scenario te bevestigen. In het veld authenticationDetail staat wachtwoordloos.
• De gebruiker is geverifieerd, maar is nog niet aangemeld. Ter bevestiging is er een foutcode 50058 die correleert met een interrupt.
• Als in het veld Gebruikersnaam 000000-00000-0000-0000 of iets dergelijks wordt weergegeven, kunnen er tenantbeperkingen gelden, waardoor de gebruiker zich niet kan aanmelden bij de geselecteerde tenant.
• Aanmeldingspogingen voor meervoudige verificatie worden samengevoegd met meerdere gegevensvermeldingen, wat langer kan duren om correct weer te geven. Het kan tot twee uur duren voordat gegevens volledig zijn samengevoegd, maar dat duurt zelden zo lang.

Nee, in het algemeen worden 90025-fouten opgelost door een automatische nieuwe poging zonder dat de gebruiker de fout noteert. Deze fout kan optreden wanneer een interne Microsoft Entra-subservice de vergoeding voor opnieuw proberen bereikt en niet aangeeft dat uw tenant wordt beperkt. Deze fouten worden meestal intern opgelost door Microsoft Entra-id. Als de gebruiker zich niet kan aanmelden vanwege deze fout, moet u het probleem handmatig opnieuw proberen.

Als de service-principal-id de waarde 0000000-0000-0000-0000-0000000000000 heeft, is er geen service-principal voor de clienttoepassing in dat exemplaar van verificatie. Microsoft Entra geeft geen toegangstokens meer uit zonder een clientservice-principal, met uitzondering van een paar Microsoft- en niet-Microsoft-toepassingen.

Als de resourceservice-principal-id de waarde 0000000-0000-0000-0000-000000000000 heeft, is er geen service-principal voor de resourcetoepassing in dat exemplaar van verificatie.

Dit gedrag is momenteel alleen toegestaan voor een beperkt aantal resource-apps.

U kunt query's uitvoeren op exemplaren van verificatie zonder een client- of resourceservice-principal in uw tenant.

• Gebruik de volgende query om exemplaren van aanmeldingslogboeken voor uw tenant te vinden waar een clientservice-principal ontbreekt:

  https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and servicePrincipalId eq '00000000-0000-0000-0000-000000000000'
  

• Gebruik de volgende query om exemplaren van aanmeldingslogboeken voor uw tenant te vinden waar een resourceservice-principal ontbreekt:

  https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and resourceServicePrincipalId eq '00000000-0000-0000-0000-000000000000'
  

U vindt deze aanmeldingslogboeken ook in het Microsoft Entra-beheercentrum.

• Meld u aan bij het Microsoft Entra-beheercentrum.
• Blader naar aanmeldingslogboeken voor identiteitsbewaking>en -status>.
• Selecteer aanmeldingen voor service-principals.
• Selecteer een geschikt tijdsbestek in het veld Datum (afgelopen 24 uur, 7 dagen enzovoort).
• Voeg een filter toe en selecteer service-principal-id en geef de waarde 00000000-0000-0000-0000000000000 op om exemplaren van verificatie op te halen zonder clientservice-principal.

Als u wilt bepalen hoe verificatie in uw tenant werkt voor specifieke client- of resource-apps, volgt u de instructies in de Microsoft Entra-app beperken tot een set gebruikers .

Sommige niet-interactieve aanmeldingen zijn beschikbaar gesteld voordat de niet-interactieve aanmeldingslogboeken beschikbaar waren in openbare preview. Deze niet-interactieve aanmeldingen zijn opgenomen in de interactieve aanmeldingslogboeken en bleven in de interactieve aanmeldingslogboeken staan nadat de niet-interactieve logboeken beschikbaar waren. Aanmeldingen met de FIDO2-sleutels zijn een voorbeeld van niet-interactieve aanmeldingen die worden weergegeven in de interactieve aanmeldingslogboeken. Op dit moment worden deze niet-interactieve logboeken altijd opgenomen in het interactieve aanmeldingslogboek.

U kunt de API voor identiteitsbeveiligingsrisicodetecties gebruiken om toegang te krijgen tot beveiligingsdetecties via Microsoft Graph. Deze API omvat geavanceerde filters en veldselectie en standaardiseert risicodetecties in één type voor eenvoudigere integratie met SIEM's en andere hulpprogramma's voor gegevensverzameling.

U kunt problemen met beleid voor voorwaardelijke toegang oplossen via alle aanmeldingslogboeken. Bekijk de status van voorwaardelijke toegang en bekijk de details van het beleid dat is toegepast op de aanmelding en het resultaat voor elk beleid.

Ga als volgt aan de slag:

• Meld u aan bij het Microsoft Entra-beheercentrum.
• Blader naar aanmeldingslogboeken voor identiteitsbewaking>en -status>.
• Selecteer de aanmelding die u wilt oplossen.
• Selecteer het tabblad Voorwaardelijke toegang om alle beleidsregels weer te geven die van invloed zijn op de aanmelding en het resultaat voor elk beleid.

De status van voorwaardelijke toegang kan de volgende waarden hebben:

• Niet toegepast: er is geen beleid voor voorwaardelijke toegang met de gebruiker en app binnen het bereik.
• Geslaagd: er is een beleid voor voorwaardelijke toegang met de gebruiker en de app binnen het bereik en het beleid voor voorwaardelijke toegang is voldaan.
• Fout: de aanmelding voldoet aan de gebruikers- en toepassingsvoorwaarde van minstens één beleid voor voorwaardelijke toegang, en de besturingselementen voor toekenning werken niet of zijn ingesteld om de toegang te blokkeren.

Een beleid voor voorwaardelijke toegang kan de volgende resultaten hebben:

• Geslaagd: het beleid is voltooid.
• Fout: het beleid is niet tevreden.
• Niet toegepast: er is mogelijk niet voldaan aan de beleidsvoorwaarden.
• Niet ingeschakeld: het beleid heeft mogelijk de status Uitgeschakeld.

De beleidsnaam in het aanmeldingslogboek is gebaseerd op de naam van het beleid voor voorwaardelijke toegang op het moment van de aanmelding. De naam kan inconsistent zijn met de beleidsnaam in Voorwaardelijke toegang als u de beleidsnaam na de aanmelding hebt bijgewerkt.

Momenteel worden in het aanmeldingslogboek mogelijk geen nauwkeurige resultaten weergegeven voor Exchange ActiveSync-scenario's wanneer voorwaardelijke toegang wordt toegepast. Er kunnen gevallen zijn wanneer het aanmeldingsresultaat in het rapport een geslaagde aanmelding weergeeft, maar de aanmelding daadwerkelijk is mislukt vanwege een beleid.

Beleid voor voorwaardelijke toegang is niet van toepassing op Windows-aanmelding of Windows Hello voor Bedrijven. Beleid voor voorwaardelijke toegang beschermt aanmeldingspogingen naar cloudresources, niet het aanmeldingsproces van Windows.

Zoek de API-verwijzing om te zien hoe u de API's kunt gebruiken voor toegang tot activiteitenlogboeken. Dit eindpunt heeft twee rapporten (controle en aanmeldingen) die alle gegevens bevatten die u in het oude API-eindpunt hebt gekregen. Dit nieuwe eindpunt heeft ook een aanmeldingsrapport met de Microsoft Entra ID P1- of P2-licentie die u kunt gebruiken om app-gebruik, apparaatgebruik en aanmeldingsgegevens van gebruikers op te halen.

U kunt de API voor identiteitsbeveiligingsrisicodetecties gebruiken om toegang te krijgen tot beveiligingsdetecties via Microsoft Graph. Deze nieuwe indeling biedt meer flexibiliteit bij het uitvoeren van query's op gegevens. De indeling biedt geavanceerde filters, veldselectie en standaardiseert risicodetecties in één type voor eenvoudigere integratie met SIEM's en andere hulpprogramma's voor gegevensverzameling. Omdat de gegevens een andere indeling hebben, kunt u geen nieuwe query vervangen door uw oude query's. De nieuwe API maakt echter gebruik van Microsoft Graph. Dit is de Microsoft-standaard voor dergelijke API's als Microsoft 365 of Microsoft Entra-id. Het vereiste werk kan uw huidige Microsoft Graph-investeringen uitbreiden of u helpen bij het overstappen naar dit nieuwe standaardplatform.

Mogelijk moet u zich afzonderlijk van het Microsoft Entra-beheercentrum aanmelden bij Microsoft Graph. Selecteer uw profielpictogram in de rechterbovenhoek en meld u aan bij de rechtermap. Mogelijk probeert u een query uit te voeren waarvoor u geen machtigingen hebt. Selecteer Machtigingen wijzigen en selecteer de knop Toestemming . Volg de aanmeldingsprompts.

Telkens wanneer een token wordt gebruikt om een Microsoft Graph-eindpunt aan te roepen, worden de MicrosoftGraphActivityLogs tokens bijgewerkt met die aanroep. Sommige van deze aanroepen zijn alleen-app-aanroepen, die niet worden gepubliceerd in de aanmeldingslogboeken van de service-principal. Wanneer er een MicrosoftGraphActivityLogs uniqueTokenIdentifier wordt weergegeven die u niet kunt vinden in de aanmeldingslogboeken, verwijst de token-id naar een token met alleen apps van derden.

Als de service activiteit detecteert die betrekking heeft op die aanbeveling voor iets dat is gemarkeerd als 'voltooid', verandert deze automatisch weer in 'actief'.