有关 Microsoft Entra 监视和运行状况的常见问题解答

请参阅 Microsoft Entra ID P1 或 P2 入门以升级 Microsoft Entra 版本。

如果获得免费许可证时已有活动数据，则可以立即看到这些数据。 如果没有任何数据，则最多需要三天，数据就会显示在报告中。

如果最近刚切换到高级版本（包括试用版），最初最多能看到七天的数据。 随着数据累积，可以看到过去 30 天的数据。

可以使用标识保护风险检测 API 通过 Microsoft Graph 访问安全检测。 这种新格式在查询数据的方式上提供了更大的灵活性。 该格式包括高级筛选和字段选择功能，并将风险检测标准化为一种类型，以便轻松集成到 SIEM 和其他数据收集工具中。 因为数据采用的格式不同，所以无法用新查询替代旧查询。 但是，新 API 使用 Microsoft Graph，它是 Microsoft 365 或 Microsoft Entra ID 等 API 的 Microsoft 标准。 因此，需要做的工作可以扩展当前 Microsoft Graph 投资或者帮助你开始向这个新标准平台过渡。

否，查看审核和登录日志的最低特权角色是报告读取者。 其他角色包括安全读取者和安全管理员。

登录日志和审核日志都可用于通过 Azure Monitor 进行路由。 目前不包括与 B2C 相关的审核活动。 有关详细信息，请参阅 Microsoft Entra 活动日志集成和图形 API 活动日志概述

有关支持的 SIEM 工具的当前列表，请参阅将 Azure 监视数据流式传输到事件中心供外部工具使用。

是的。 若要通过自定义应用程序来访问日志，可以使用事件中心 API。

Microsoft 365 和 Microsoft Entra 活动日志共享许多目录资源。 如果需要全面查看 Microsoft 365 活动日志，应转到 Microsoft 365 管理中心，以便获取 Office 365 活动日志信息。

Microsoft 365 管理 API 一文中介绍了适用于 Microsoft 365 的 API。

可以从 Azure 门户下载多少日志取决于几个因素，包括浏览器内存大小、网络速度和 Microsoft Entra 报告 API 上的当前负载。 一般情况下，最多可以从 Azure 门户下载 250,000 条记录。 此数字可能因你包括的字段数而异。 若要下载超过 250,000 条记录的数据集，请使用报告 API 来下载数据。 开始下载后，下载的特定日志集由 Azure 门户中的活动筛选器确定（例如，筛选到 Azure 门户中的特定用户意味着你的下载会为该特定用户拉取日志）。

Microsoft Entra ID 会将活动日志存储 7 到 30 天，具体取决于许可证。 有关详细信息，请参阅 Microsoft Entra报表保留策略。

新的保留策略将应用于更改后收集的日志。 策略更改前收集的日志将不会受到影响。 诊断设置存储保留功能即将弃用。 有关此更改的详细信息，请参阅从诊断设置存储保留迁移到 Azure 存储生命周期管理。

目前，审核日志中没有许可证购买或启用的特定活动。 但是，可以将“资源管理”类别中的“将资源载入 PIM”活动与许可证的购买或启用相关联。 此活动可能并不总是可用或提供确切的详细信息。

signInActivity 资源用于查找一段时间未登录的非活动用户。 它不会近实时更新；最多需要 6 小时才会更新给定用户的属性。 如果需要更快地查找用户上次登录活动，可以使用 Microsoft Entra 登录边栏选项卡近乎实时地查看所有用户的登录活动。

CSV 包含用户和服务主体的登录日志。 但是，它不包含 MS Graph API 中以嵌套数组形式表示的登录日志数据。 例如，不包含条件访问策略和仅限报告的信息。 如果需要导出登录日志中包含的所有信息，请使用“导出数据设置”功能。

当用户不属于查看日志的租户时，Microsoft Entra ID 可能会编辑登录日志中的 IP 地址部分，以保护用户隐私。 在两种情况下会进行此操作：第一，在跨租户登录期间（例如，当 CSP 技术人员登录到 CSP 管理的租户时）。 第二，当服务无法以足够的置信度确定用户的身份，从而无法确认该用户属于查看日志的租户时。

Microsoft Entra ID 会编修不属于租户的设备生成的个人身份信息 (PII)，从而确保客户数据不会在未经用户和数据所有者同意的情况下传播到租户边界之外。

有多种原因可导致日志中的登录条目重复。

• 如果在登录时发现风险，则会在包含风险后立即发布另一个几乎相同的事件。
• 如果收到与登录相关的 MFA 事件，则所有相关事件都会聚合到原始登录中。
• 如果合作伙伴发布登录事件失败（例如发布到 Kusto），则会重试并再次发布整批事件，这可能会导致出现重复。
• 涉及多个条件访问策略的登录事件可能会拆分为多个事件，这可能导致每个登录事件至少会产生两个事件。

非交互式登录每小时可能触发大量事件，因此在日志中将它们归并在一组。

在许多情况下，非交互式登录所有特征都相同（登录日期和时间除外）。 如果时间聚合设置为 24 小时，日志将同时显示各个登录。 可以展开这些分组行中的每一行，以查看确切的时间戳。

使用无密码身份验证时，用户 ID 显示为用户名。 若要确认此方案，请查看有关登录事件的详细信息。 authenticationDetail 字段将显示无密码。

否，一般而言，90025 错误会通过自动重试来解决，而用户不会注意到该错误。 如果内部 Microsoft Entra 子服务达到其重试限额并且未指示租户受到限制，则可能会发生此错误。 这些错误通常由 Microsoft Entra ID 在内部解决，不会对用户造成任何影响。 如果用户由于此错误而无法登录，则手动重试应该可以解决问题。

如果服务主体 ID 的值为“0000000-0000-0000-0000-000000000000”，则表示该身份验证实例中不存在客户端应用程序的服务主体。 在没有客户端服务主体的情况下，Microsoft Entra 将不在颁发访问令牌（少数 Microsoft 和第三方应用程序除外）。

如果资源服务主体 ID 的值为“0000000-0000-0000-0000-000000000000”，则表示该身份验证实例中没有资源应用程序的服务主体。

目前仅允许有限数量的资源应用使用此方式。

在租户中没有客户端或资源服务主体的身份的情况下，可以查询身份验证实例。

• 若要查找缺少客户端服务主体的租户的登录日志实例，请使用以下查询：

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

• 若要查找缺少资源服务主体的租户的登录日志实例，请使用以下查询：

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

也可以在 Azure AD 门户中查找这些登录日志。

• 登录到 Azure 门户并转到Microsoft Entra ID。
• 导航到“监视”下的“登录日志”，
• 选择“服务主体登录”。
• 在“数据”字段中选择适当的期限（过去 24 小时、7 天等）。
• 添加筛选器并选择“服务主体 ID”，然后提供值“00000000-0000-0000-0000-000000000000”，以在没有客户端服务主体的情况下获取身份验证实例。

如果要控制特定客户端或资源应用在租户中进行身份验证的方式，请按照将 Azure AD 应用限制为一组用户一文中的说明进行操作。

在以公共预览版提供非交互式登录日志之前，提供了部分非交互式登录。 这些非交互式登录包含在交互式登录日志中，并在非交互式日志可用后保留在交互式登录日志中。 例如，使用 FIDO2 密钥的登录是交互式登录日志中显示的非交互式登录。 目前，这些非交互式日志将始终包含在交互式登录日志中。

可以通过所有登录日志对条件访问策略进行故障排除。 查看条件访问状态，并深入了解应用于登录的策略的详细信息以及每个策略的结果。

开始操作：

• 登录到“Azure 门户”并转到“Microsoft Entra ID”，然后选择“登录日志”。
• 请选择要进行排查的登录。
• 导航到“条件访问”选项卡。在这里，可以查看影响了登录的所有策略以及每个策略的结果。

条件访问状态可以具有以下值：

• 未应用：在范围内没有针对用户和应用的条件访问策略。
• 成功：在范围内存在针对用户和应用的条件访问策略，并且已成功满足条件访问策略。
• 失败：登录满足了至少一个条件性访问策略的用户和应用程序条件，授权控件要么未满足，要么设置为阻止访问。

条件访问策略可以具有以下结果：

• 成功：成功满足策略。
• 失败：不满足策略。
• 未应用：可能未满足策略条件。
• 未启用：策略可能处于禁用状态。

登录日志中的策略名称均基于登录时的条件访问策略名称。 如果你在登录后更新了策略名称，则名称可能与条件访问中的策略名称不一致。

应用条件访问时，登录日志目前可能无法显示 Exchange ActiveSync 方案的准确结果。 在有些情况下，报告中的登录结果显示已成功登录，但由于策略，登录实际上失败了。

请查看 API 参考，了解如何使用 API 访问活动日志。 此终结点有两个报告（“审核”和“登录”），它们提供了你在旧的 API 终结点中获取的所有数据。 此新的终结点还有一个登录报告，其中包含可用来获取应用使用情况、设备使用情况和用户登录信息的 Microsoft Entra ID P1 或 P2 许可证。

可以使用标识保护风险检测 API 通过 Microsoft Graph 访问安全检测。 此新格式在数据查询方式上提供了更大的灵活性，具有高级筛选、字段选择等功能，并将风险检测标准化为一种类型，以便轻松集成到 SIEM 和其他数据收集工具中。 因为数据采用的格式不同，所以无法用新查询替代旧查询。 但是，新 API 使用 Microsoft Graph，它是 Microsoft 365 或 Microsoft Entra ID 等 API 的 Microsoft 标准。 因此，需要做的工作可以扩展当前 Microsoft Graph 投资或者帮助你开始向这个新标准平台过渡。

你可能需要独立于 Azure 门户登录到 Microsoft Graph。 选择右上角的个人资料图标，然后登录到右侧目录。 你可能正在尝试运行你没有权限的查询。 选择“修改权限”，然后选择“同意”按钮。 按照登录提示进行操作。

如果服务检测到与标记为“已完成”的推荐相关的活动，它会自动变回“活动”。