我们正在尝试用 MS365 的内置电子邮件加密来取代安全电子邮件网关解决方案。
我们设置了一个邮件流规则，强制从特定发送地址到任何收件人进行加密，如下所示：
条件：
如果满足以下条件，则应用规则：
发件人为“[email protected]”执行以下操作： 修改邮件安全性 - 应用 Office 365 邮件加密和权限保护
- 使用“加密”权限保护消息（默认加密策略）
现在，当我们从该租户中的Business Basic 许可帐户alwaysencrypt发送时，我们会得到奇怪的结果。
- 发送到非 MS365 帐户/租户/域时，电子邮件是财产传递的，并且需要发送 OTP 代码来验证访问权限。这很好用。
- 对于某些 MS365 租户收件人（但不属于原始租户的一部分），权限管理可以正常工作，并正确将此外部租户识别为收件人，并且允许用户访问。
- 对于不属于原始租户的其他 MS365 租户收件人，系统不允许其用户登录并使用 MS365 租户身份验证来访问文档，并会失败并显示类似于以下内容的消息：
Selected user account does not exist in tenant 'Example Tenant' and cannot access the application 'UUID' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.
我们有第三种选择，这是非常新的，并且 MS365 不向外部租户提供 OTP 代码选项。
我没有找到解决此问题并允许外部租户访问权限系统的方法，而无需将其手动添加到我们的原始租户，这是一个问题，因为这是一个自动化系统，将加密消息数据作为警报系统的一部分发送给外部收件人。
有没有人看到过这个，是否有人知道我们如何解决这个问题，以强制它不使用 MS365 租户身份验证来访问加密消息，而仅在组织外部时进行 OTP 代码验证？
我应该指出，MS365 现在强制使用 Microsoft Purview，因此旧版 OME 解决方案将无法运行，并且关于如何更改此解决方案或根据需要进行这些修订的文档为零。
请注意，我有权访问原始租户上的全局管理员，因此如果需要，我应该有权访问所有 Powershell 选项。
所以，事实上，事实证明这根本不是一个“租户”问题，而是一个许可问题。在文档中很难找到它，因为基本的 Purview 页面甚至没有引用它，它只是在常见问题解答中，当您尝试调试加密内容时您看不到它。
它埋藏在常见问题解答中的 Microsoft Purview OME 文档中（但不在 Purview 文档的其他任何地方），它指示 Purview 自动支持哪些计划：
不幸的是，这没有在 MS365 计划页面上列出，并且在有关 MS365 计划的任何其他文档中都没有详细说明 - 至少没有任何明显的地方。
我们获得了所示的 Azure 信息保护计划 1 的许可证，并将其附加到
alwaysencrypt原始租户中的用户。在给 Microsoft 时间将此更改和 AIP 服务应用到原始租户后，它按预期工作，外部租户现在可以查看消息，非 MS365 收件人也可以。微软今天在他们的文档中得分为-1，但至少我们通过一个简单的解决方案解决了这个问题：向微软投入更多资金。