我在一个非常小的学校环境中工作。他们使用 M365 A3 许可证，并使用 Entra 和 InTune 进行 mdm。
我们（至少在理论上）禁用了所有 MFA，以便所有用户（特别是学生）无需使用 Authenticator 即可登录。
问题是，当我们进行“工作/学校”登录时，一些学生被提示下载 Authenticator pp。我们收到的提示说我们的组织需要它。
我已在 Entra 中禁用 MFA。我可能会遗漏什么？
我们有一个 Microsoft Azure/Entra 域或“租户”，最初从“工作帐户”自我注册转换为具有免费计划（学术）的完全托管域，因此它以我们的基本域（即，example.com而不是类似的域ad.example.com）作为主域。
我们很少使用 Azure，但现在我们正在逐个添加一些 Teams 帐户。到目前为止，我们已选择与本地电子邮件地址相匹配的帐户名称 - 例如，我的工作电子邮件地址是 ，[email protected]同样，我的 Teams Entra 帐户也是[email protected]。
但我注意到，如果 Teams 发送邀请电子邮件至[email protected]，它永远不会到达我们的本地电子邮件服务器 - 相反，当我通过打开它并使用我的 Azure 帐户登录时，我们会在O365邮箱中找到该电子邮件。https://outlook.com
我不知道我们的免费计划中包含邮箱，但更重要的是，我可以让它将邮件发送到我们的本地电子邮件服务器，正如 MX 记录已经表明的那样？我们根本不使用 O365 邮件（目前还没有？），所以我不需要每个邮箱都使用它，而是需要整个域——至少目前是这样。如果是：我该如何让它做到这一点？
（编辑：我们为用户分配了“Office 365 A1 for Faculty”许可证，因为过去不这样做似乎会完全破坏 Teams（甚至必须删除帐户并重新创建），但我猜这也是授予他们 O365 邮箱的原因。）
或者我们应该切换 Azure 租户以使用不同的 DNS 子域作为主域（如az.example.com），然后删除旧的基础域？我犹豫不决，因为我不想像以前发生过的那样，意外地最终导致有人通过自我注册创建另一个幽灵租户。
请原谅术语的混乱；我们两人的 IT 团队对微软的云产品几乎没有任何经验。
我正准备使用 Entra/AD FS 为一组新用户提供 MFA 身份验证，但遇到了一些麻烦（幸运的是仍在测试阶段！）
该环境是本地 AD/AD FS 服务器 (2019)，与 P1 同步到 Entra 以支持 MFA。这适用于大多数用户。当用户激活新帐户时，他们将根据文档重定向到位于 mysignins.micrsoft.com/security-info 的 MS“ProofUp”流程，并可以完成注册/身份验证。它允许他们最初绕过 MFA 要求到达“mysignins.micrsoft.com/security-info”页面，直到提供其他因素（这是应该的）。
然而，现在有一类用户来到我们这里，他们已经拥有 Microsoft Authenticator 应用程序，并且已经使用我们的“工作或学校帐户”登录了该应用程序，但尚未实际完成 MFA 注册应用程序我们的 Azure/Entra 租户。值得注意的是，该应用程序根本不会出现在 Entra 管理控制台中用户的“身份验证方法”部分中。这些学生（我们是一所大学）在我们要求学生 MFA 之前，使用该应用程序通过外部服务进行 MFA，但我们现在不再使用该服务。
这些用户无法加载 mysignins.micrsoft.com/security-inf ProofUp 页面，而是进入重定向循环，他们不断地返回我们的 AD FS 站点，表示他们需要完成 MFA 注册。
关键是用户永远不会看到实际的错误消息。他们只是无法越过要求他们注册 MFA 令牌的 AD FS 页面。他们为前进所做的任何事情都会将他们重新引导回这一点。此外，这些用户在 Entra 中的登录日志只会显示“成功”结果，除非他们实际上输入了错误的密码，即使这些结果是在我们为用户启用 MFA 要求之前（或者在我们因以下原因而释放它们之后）失败）。
更新：
我现在可以通过以下步骤按需为新测试用户重新创建此内容：
- 在本地 Active Directory 中创建用户
- 确保用户尚不需要 MFA 并让它同步到 Azure AD/Entra
- 使用尚未在 Entra 注册的测试移动设备
- 在设备上全新安装 MS Authenticator 应用程序（首先将其完全删除，如果已存在则重新安装，以便清除之前测试的所有本地数据）
- 使用步骤 1 中创建的用户凭据作为工作/学校帐户登录身份验证器应用
- 关闭并退出应用程序。
- 将用户设置为要求我们的 AD FS 依赖方之一进行 MFA（我们通过在 AD 中添加组成员身份来实现此目的）
- 让用户尝试访问受保护的应用程序
重要的是步骤 5 和 6 发生在步骤 7 之前。
AD FS 现在将正确确定用户需要完成 MFA；它会根据文档向他们显示一条消息，然后在 5 秒后尝试将他们重定向到 Entra ProofUp 页面。但验证页面将不允许访问并立即将其重定向回 AD FS 以重复该循环。用户无法完成 ProofUp 过程。
在管理控制台中为用户使用如下所示的“需要重新注册多重身份验证”按钮无法解决此问题。
到目前为止，我有两种方法可以推动这些用户前进：
- 手动输入他们的附加因素（例如手机）。我们很快就会通过这种方式增加数百名用户，但我不一定有这些手机号码。我需要更好的东西。
- 专门更改 Office 365 应用程序的访问控制策略，以不需要 MFA。这并不像乍看起来那么糟糕，因为我们使用 Google Workspace 来处理电子邮件和大多数文档服务，但它显然也不好，而且我不想长期忍受这种情况。
如何清除这些用户半完成的身份验证器应用程序注册，或以其他方式允许他们继续进行 MFA 注册？
我不是第一个遇到这种情况的人，因为任何跳过正常流程中的步骤并试图过早添加身份验证器应用程序的人都可能会遇到这种情况。