我有一个微软支持案例，已经开庭一个月了，很遗憾他们没有达到我通常对微软支持的体验。所以我会在这里发布这个。
大约一个月前，我们实施了 Azure AD App Proxy 来为我们的本地 Exchange 2010 提供前端，这样我们就可以为 OWA 和移动设备执行 MFA（从技术上讲，为 OWA 和 InTune 注册执行 MFA，并使用 EAS 上的条件访问来要求 InTune。瞧。）它通常运行良好。对于 Outlook Anywhere 和 EWS，我们只是允许直通身份验证而不是预身份验证，因为在 Ex2010 上，这些协议不会为客户端执行 MFA，这对我们来说没问题。
但是 - Outlook for Mac（2016）将不再起作用。
重要编辑- 正如标题所示，这仅适用于异地，通过 AADAP 进入的情况。当他们直接连接到 CAS 服务器时（在本地或 VPN 上），其工作方式与往常相同。我们的 CAS 服务器没有变化。
因此，EWS 正在运行。如果我将 Windows 计算机移出本地，Outlook 仍可以连接到 EWS，因为我可以设置 OOO 并查看空闲/忙碌信息。
Mac 版 Outlook 无法连接。它抱怨 Kerberos，要求我输入新信息，但始终无法连接。在 MS 支持的帮助下，我们使用 Charles（类似于 Fiddler）进行了 SSL 捕获，他们说问题在于我们在 EWS 中允许 NTLM 和 Negotiate，而 AADAP 始终只会将最强的方法传递给客户端，而 Mac Outlook 无法与 Negotiate 配合使用。
作为测试，昨晚我删除了 CAS 服务器上 IIS 中的 Negotiate 作为 Windows 身份验证提供程序，我的 Mac 开始工作，现在根据 Charles 的说法使用基本身份验证。但是，Windows 客户端无法访问 EWS，因此 OOO、MailTips、忙/闲功能都坏了。我们的 Windows 用户比 Mac 用户多得多，所以我们恢复了。我仍在与 MS 合作，但 Azure AD 团队似乎已经消失了，Exchange 人员不在状态（不是他的错），他们甚至从未让 Outlook for Mac 团队参与进来。
有人知道从哪里开始吗？
答案1
几周前，我和 Azure AD 的一位产品经理通了电话。他们在 App Proxy 中推出了一项功能，用于检测 Mac Office 连接，然后仅显示其可以使用的 AUTH 类型。所以，太棒了。