本文包含有关 Microsoft Entra 监视和运行状况的常见问题解答。 有关详细信息，请参阅 Microsoft Entra 监视和运行状况概述。
许可
如何获得高级许可证？
请参阅 Microsoft Entra ID 许可 以升级 Microsoft Entra 版本。
获得高级许可证后多久才能看见活动日志数据？
如果已有具有免费许可证的活动日志数据，可以立即看到它。 如果没有任何数据，数据最多可能需要三天时间才能显示在报表中。
获取 Microsoft Entra ID P1 或 P2 许可证后，是否可以查看上个月的数据？
如果你最近刚切换到高级版本（包括试用版），最初最多能看到七天的数据。 随着数据累积，可以看到过去 30 天的数据。
活动日志和报告
在 Microsoft Entra 管理中心中查看活动日志需要具有什么角色？
查看审核和登录日志 的最低特权角色 是 报表读取者。 其他角色包括安全读取者和安全管理员。
哪些日志可以与 Azure Monitor 集成？
登录、审核、预配、ID 保护、网络访问和其他许多日志可与 Azure Monitor 和其他监视和警报工具集成。 目前不包括与 B2C 相关的审核活动。 有关可与其他终结点集成的Microsoft Entra 日志的完整列表，请参阅 用于流式传输到终结点的日志选项。
能否通过 Microsoft Entra 管理中心或 Azure 门户获取 Microsoft 365 活动日志信息？
Microsoft 365 和 Microsoft Entra 活动日志共享许多目录资源。 如果想要查看Microsoft 365 活动日志的完整视图，则应转到 Microsoft 365 管理中心以获取 Office 365 活动日志信息。 Microsoft 365 管理 API 一文介绍了 Microsoft 365 的 API 。
可以从 Microsoft Entra 管理中心下载多少条记录？
可以从 Microsoft Entra 管理中心下载的日志数量取决于多个因素，例如浏览器内存大小、网络速度，以及 Microsoft Entra 报告 API 负载。 一般而言，浏览器下载功能适合审核日志小于 250,000 条以及登录和预配日志小于 100,000 条的数据集。 此数字可能因你包括的字段数而异。 如果在浏览器中完成大型下载时遇到问题，请使用 报告 API 下载数据或通过 诊断设置将日志发送到终结点。
你开始下载时在 Microsoft Entra 管理中心内处于活动状态的筛选器决定了你可以下载的具体日志集。 例如，在 Microsoft Entra 管理中心中筛选到特定的用户意味着下载将拉取该特定用户的日志。 下载的日志中的列不会发生改变。 输出包含审核日志或登录日志的所有详细信息，无论在 Microsoft Entra 管理中心自定义了哪些列。
Microsoft Entra ID 存储活动日志多长时间？ 什么是数据保留？
Microsoft Entra ID 会将活动日志存储 7 到 30 天，具体取决于许可证。 有关详细信息，请参阅 Microsoft Entra 报表保留策略。
从“使用情况和见解”报表中选择应用时，为何会看到“找不到”？
使用情况和见解报表现在包括Microsoft云服务应用程序的服务到服务身份验证。 如果应用程序出现在此列表中，则可能意味着它已向租户中驻留的应用程序进行身份验证或从中进行身份验证。 但是列表中的应用程序不驻留在租户中，但报表中只显示一个用于显示身份验证的实例。
审核日志
如何确定用户是否为我的租户购买了许可证或启用了试用许可证？ 我在审核日志中看不到此活动。
目前，审核日志中没有许可证购买或启用的特定活动。 但是，你或许可以将“资源管理”类别中的“将资源载入 PIM”活动与许可证的购买或启用相关联。 此活动可能并不总是可用或提供确切的详细信息。
登录日志
我使用了 signInActivity 资源来查询用户的上次登录时间，但几个小时后尚未更新。 何时会更新最近的登录时间？
signInActivity 资源用于查找 尚未登录一段时间的非活动用户。 它不会准实时更新。 如果需要更快地查找用户上次登录活动，可以使用 Microsoft Entra 登录日志近乎实时地查看所有用户的登录活动。
可从 Microsoft Entra 登录日志下载的 CSV 文件中包含哪些数据？
CSV 包括所选登录类型的登录日志。 但是，不包含 Microsoft Graph API 中以嵌套数组形式表示的登录日志数据。 例如，不包含条件访问策略和仅限报告的信息。 如果需要导出登录日志中包含的所有信息，请使用“导出数据设置”功能。
此外，请务必注意下载的日志中包含的列不会发生改变，即使你在 Microsoft Entra 管理中心中自定义了列也是如此。
我在登录日志中用户的设备详细信息中看到 IP 地址的一部分或“PII 已删除”。 为什么会这样？
Microsoft Entra ID 可能会修改登录日志的一部分，以保护以下方案中的用户隐私：
- 在跨租户登录期间，例如 CSP 技术人员登录到 CSP 管理的租户时。
- 当服务无法以足够的置信度确定用户的身份，从而无法确认该用户属于查看日志的租户时。
- Microsoft Entra ID 会编修不属于租户的设备生成的个人身份信息 (PII)，从而确保客户数据。 PII 不会在未经用户和数据所有者同意的情况下传播到租户边界之外。
我看到每个 requestID 都有重复的登录条目/多个登录事件。 为什么会这样？
可能导致日志中的登录条目重复的原因有多种。
- 如果在登录时发现风险，则会在包含风险后立即发布另一个几乎相同的事件。
- 如果收到与登录相关的 MFA 事件，则所有相关事件都会聚合到原始登录中。
- 如果合作伙伴发布登录事件失败（例如发布到 Kusto），则会重试并再次发布整批事件，这可能会导致出现重复。
- 涉及多个条件访问策略的登录事件可能会拆分为多个事件，这可能导致每个登录事件至少会产生两个事件。
我正在使用 Log Analytics 调查登录事件，但 TimeGenerated 时间与登录的实际时间有出入。 为什么会这样？
Log Analytics 中的 TimeGenerated 字段是 Log Analytics 接收和发布条目的时间。 请记住，为了使日志出现在 Log Analytics 中，必须配置诊断设置以将日志发送到 Log Analytics 工作区。 此过程需要时间，因此 TimeGenerated 字段可能与登录的实际时间有出入。
若药确认日期和时间与登录时间相符，请在 Log Analytics 结果中稍下方查找 CreatedDateTime 字段。 还可以展开字段 AuthenticationDetails 以查看登录的确切时间。 Log Analytics 中的时间以 UTC 格式显示，但Microsoft Entra 管理中心登录日志中的时间在本地时间显示，因此可能需要进行调整。
有风险的登录事件也具有与实际登录时间不同的 TimeGenerated 时间。 风险登录的 TimeGenerated 时间是检测到风险的时间，而不是登录的时间。 检查有风险的登录事件本身的活动时间，这是登录的实际时间。
为什么我的非交互式登录具有相同的时间戳？
非交互式登录每小时可能触发大量事件，因此在日志中将它们归并在一组。
在许多情况下，非交互式登录所有特征都相同（登录日期和时间除外）。 如果时间聚合设置为 24 小时，日志将同时显示各个登录。 可以展开这些分组行中的每一行，以查看确切的时间戳。
我在登录日志的用户名字段中看到用户 ID/对象 ID/GUID。 为何会发生这种情况？
可能导致登录条目在用户名字段中显示用户 ID、对象 ID 或 GUID 的原因有多种。
- 使用无密码身份验证时，用户 ID 显示为用户名。 若要确认此方案，请查看有关登录事件的详细信息。 authenticationDetail 字段显示无密码。
- 用户已通过身份验证但尚未登录。 若要确认，可以查看是否出现了与中断相关的错误代码 50058。
- 如果用户名字段显示 000000-00000-0000-0000 或类似 内容，则可能存在租户限制，从而阻止用户登录到所选租户。
- 多方式认证登录尝试将与多个数据条目聚合，因而可能需要更长时间才能正确显示。 数据可能需要长达两个小时才能完全聚合，但很少需要花费这么长时间。
我在登录日志中看到 90025 错误。 这是否意味着用户无法登录？ 我的租户是否达到了限制？
否，一般而言，90025 错误会通过自动重试来解决，而用户不会注意到该错误。 如果内部 Microsoft Entra 子服务达到其重试限额并且未指示租户受到限制，则可能会发生此错误。 这些错误通常由 Microsoft Entra ID 在内部解决。 如果用户由于此错误而无法登录，则手动重试应该可以解决问题。
在服务主体登录日志中，如果登录日志中显示服务主体 ID 或资源服务主体 ID 为“00000000-0000-0000-0000-000000000000”或“ ”，这是意味着什么？
如果服务主体 ID 的值为“0000000-0000-0000-0000-000000000000”，则表示该身份验证实例中不存在客户端应用程序的服务主体。 在没有客户端服务主体的情况下，Microsoft Entra 将不再颁发访问令牌（少数 Microsoft 和非 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'
也可以在 Microsoft Entra 管理中心内找到这些登录日志。
- 登录到 Microsoft Entra 管理中心。
- 浏览到 Entra ID>监视和运行状况>登录日志。
- 选择 “服务主体登录”。
- 在“数据”字段中选择适当的期限（过去 24 小时、7 天等）。
- 添加筛选器并选择 服务主体 ID ，并提供值“00000000-0000-0000-0000-0000000000000”，以获取没有客户端服务主体的身份验证实例。
如何限制服务主体登录日志中显示的各种应用的登录（身份验证）？
如果想要控制特定客户端或资源应用的租户中的身份验证工作原理，请按照 “限制Microsoft Entra 应用”中的说明作，了解一组用户 文章。
为什么在技术上属于非交互式的登录显示在我的交互式登录日志中？
在公共预览版中提供非交互式登录日志之前，提供了一些非交互式登录。 这些非交互式登录包含在交互式登录日志中，并在非交互式日志可用后保留在交互式登录日志中。 使用 FIDO2 密钥的登录是交互式登录日志中显示的非交互式登录示例。 目前，这些非交互式日志会始终包含在交互式登录日志中。
应使用什么报告 API 来进行标识保护风险检测，例如凭据泄露或从匿名 IP 地址登录？
可以使用 标识保护风险检测 API 通过 Microsoft Graph 访问安全检测。 此 API 包括高级筛选和字段选择功能，并将风险检测标准化为一种类型，以便轻松集成到 SIEM 和其他数据收集工具中。
条件性访问
可以在登录日志中看到哪些条件访问详细信息？
可以通过所有登录日志对条件访问策略进行故障排除。 查看条件访问状态，并深入了解应用于登录的策略的详细信息以及每个策略的结果。
开始操作：
- 登录到 Microsoft Entra 管理中心。
- 浏览到 Entra ID>监视和运行状况>登录日志。
- 请选择要进行排查的登录。
- 选择“条件访问”选项卡以查看影响登录的所有策略以及每个策略的结果。
条件访问状态都有哪些可能的值？
条件访问状态可以具有以下值：
- 未应用：范围内没有用户和应用的条件访问策略。
- 成功：范围中的用户和应用有条件访问策略，条件访问策略已成功满足。
- 失败：登录满足至少一个条件访问策略的用户和应用程序条件，并且未满足或设置为阻止访问。
条件访问策略结果都有哪些可能的值？
条件访问策略可以具有以下结果：
- 成功：已成功满足策略。
- 失败：策略未满足。
- 未应用：策略条件可能尚未满足。
- 未启用：策略可能处于禁用状态。
登录日志中的策略名称与条件访问中的策略名称不匹配。 为什么？
登录日志中的策略名称均基于登录时的条件访问策略名称。 如果你在登录后更新了策略名称，则名称可能与条件访问中的策略名称不一致。
我的登录因条件访问策略而被阻止，但登录日志显示已登录成功。 为什么？
应用条件访问时，登录日志目前可能无法显示 Exchange ActiveSync 方案的准确结果。 在有些情况下，报告中的登录结果显示已成功登录，但由于策略，登录实际上失败了。
为什么 Windows 登录或 Windows Hello 企业版在登录日志详细信息的“条件访问”选项卡上显示为“不在范围内”或“不适用”？
条件访问策略不适用于 Windows 登录或 Windows Hello 企业版。 条件访问策略保护对云资源的登录尝试，不适用于 Windows 登录过程。
Microsoft 图形 API
我目前在使用 `https://graph.windows.net/<tenant-name>/reports/` 终结点 API 以编程方式将 Microsoft Entra 审核和集成的应用程序使用情况报告拉取到报告系统中。 我应当切换到什么？
查找 API 参考 ，了解如何 使用 API 访问活动日志。 此终结点有两个报告（“审核”和“登录”），它们提供了你在旧的 API 终结点中获取的所有数据。 此新的终结点还有一个登录报告，其中包含可用来获取应用使用情况、设备使用情况和用户登录信息的 Microsoft Entra ID P1 或 P2 许可证。
我目前在使用 `https://graph.windows.net/<tenant-name>/reports/` 终结点 API 以编程方式将 Microsoft Entra 安全报告（特定类型的检测，如泄漏的凭据或来自匿名 IP 地址的登录）拉取到报告系统中。 我应当切换到什么？
可以使用 标识保护风险检测 API 通过 Microsoft Graph 访问安全检测。 这种新格式在查询数据的方式上提供了更大的灵活性。 该格式提供高级筛选、字段选择功能，并将风险检测标准化为一种类型，以便轻松集成到 SIEM 和其他数据收集工具中。 因为数据采用的格式不同，所以无法用新查询替代旧查询。 但是， 新 API 使用 Microsoft Graph，它是 Microsoft 365 或 Microsoft Entra ID 等 API 的Microsoft标准。 因此，需要做的工作可以扩展当前 Microsoft Graph 投资或者帮助你开始向这个新标准平台过渡。
运行查询时，我不断收到权限错误。 我认为我具有合适的角色。
你可能需要独立于 Microsoft Entra 管理中心登录到 Microsoft Graph。 选择右上角的个人资料图标，然后登录到右侧目录。 你可能正在尝试运行你没有权限的查询。 选择“修改权限”，然后选择“同意”按钮。 按照登录提示进行操作。
为什么存在与服务主体登录不相关的“MicrosoftGraphActivityLogs”事件？
每次使用令牌调用 Microsoft Graph 终结点时，都会使用该调用更新MicrosoftGraphActivityLogs。 其中一些调用是第一方仅限应用的调用，不会发布到服务主体登录日志。 当MicrosoftGraphActivityLogs显示你在登录日志中找不到的uniqueTokenIdentifier时，令牌标识符会引用第一方仅限应用的令牌。
建议
为什么“已完成”的建议会变回“活动”？
如果服务检测到与标记为“已完成”的推荐相关的活动，它会自动变回“活动”。
Microsoft 服务主体登录日志（预览版）
我已通过诊断设置启用了“MicrosoftServicePrincipalSignInLogs”，但我不确定如何处理这些数据。
此日志为预览版，可能不适用于所有客户。 这些日志提供对服务到服务身份验证的可见性，特别是针对Microsoft拥有的应用程序，以保持对客户拥有资源的令牌颁发身份验证透明。
在不太可能使用应用程序访问其他资源的情况下，这些日志可以提供查明泄露源所需的信息。
在哪里可以了解有关这些呼叫发生的原因的详细信息？
Microsoft拥有的应用程序请求或颁发令牌的具体原因是我们系统设计的一部分，不能公开共享。 这些日志共享以保持透明度，并提供对客户租户边界内发生的身份验证的可见性。
此数据是否对安全调查至关重要？
我们已根据Microsoft Entra 日志流中对数据集进行分类，具体取决于它们对安全调查的重要性。 与其他数据集相比，此特定数据集的优先级要低得多。 虽然拥有此数据是有益的，但不允许它不会对安全状况产生负面影响。
可以对此数据执行哪些作？
建议在对Microsoft拥有的应用程序进行任何更改之前非常谨慎。 这些应用程序通常具有基本设置，例如计费应用程序的令牌颁发。 禁用它们可能会导致失去对帐户的访问权限。 我们的内部安全团队已实施广泛的安全控制和访问策略，以确保这些应用程序的安全。 我们对他们的安全充满信心，我们强烈建议不要对他们进行任何额外的更改。
如果选择阻止或控制这些应用程序，可能会导致意外问题，遗憾的是，我们无法支持或承担这些问题的责任。