calendar - 没有明文密码的 Exchange Web 服务服务器到服务器身份验证？

Question

我正在构建一个运行自动化流程的服务器应用程序，该应用程序需要与回退版本 2007 的 Exchange 服务器兼容。我目前通过 Azure AD 使用 OAuth 进行 Office 365 连接，但我仍在尝试为本地找到解决方案2013 年之前的交易所。

我一直在阅读有关 Exchange 身份验证(基本、NTLM 等)的信息，但似乎找不到任何对允许我使用一次性密码设置身份验证的长期 token 系统的引用。我会 非常强烈而不是将用户密码存储在中央数据库中，无论加密与否，这是一项巨大的安全责任，并且可以进行逆向工程。

有什么我想念的吗？

有没有办法每次都在没有密码的情况下对 Exchange 进行身份验证？

Answer 1

回答我自己的问题作为后续行动，因为我对某些回复和/或通过广泛搜索能够找到的内容不满意。

在对 Exchange 服务器、它们如何进行身份验证以及支持和使用的协议(protocol)进行大量研究之后，我发现了我认为最好的选择: NTLM .

现在，让我解释一下。

我试图实现的目标如下:

能够对 Exchange 2007+ 服务器进行身份验证

通过初始过程使身份验证成为“一次性设置”

永远不要存储纯文本密码(尤其是在平台/服务中央数据存储中)

考虑到这些要点:

我无法使用“基本”身份验证，因为它需要将用户的密码以纯文本形式存储在中央数据存储中

OAuth 不起作用，因为它仅在 Exchange 2013+ 上受支持

有了这个，我真的只剩下 NTLM 了。不幸的是，我知道 NTLM 在其多年遗留下来的安全漏洞方面有着粗略的历史，但我更深入地研究它是否能够以某种方式满足我的要求。

不幸的是，很长一段时间以来，NTLM 在其规范方面一直保持着一些“ secret ”。这是一个专有规范，因此不幸的是，有关其内部结构的信息并不常见。长期以来，有关 NTLM 规范信息的唯一真正来源实际上是 info that was reverse-engineered (thanks Eric Glass!) .值得庆幸的是，微软终于开始了 publish documentation on NTLM on their MSDN site more recently .

在仔细研究了协议(protocol)，并在测试 Exchange 服务器上以许多不同的配置排列运行了一些测试之后，我意识到 NTLM 实际上可以满足我的所有要求。如何？好吧，由于协议(protocol)的工作方式，一旦凭证被散列(以规范 [LM, NTv1, NTv2] 中可能的 3 种方式之一)，它 不需要为同一目标再次散列 .这意味着，类似于为典型​​的注册机制散列用户密码，您可以简单地预先要求 Exchange/NTLM 凭据，然后散列凭据一次。

笔记!!!有一个问题!

请记住，能够对凭证进行一次散列并多次使用它意味着散列在某种程度上是“密码等价物”。我的意思是，一旦知道哈希值，就可以像密码一样使用它，因为它是将来进行身份验证所需的唯一信息之一。 (这通俗地称为 "pass-the-hash" )。

然而，考虑到以纯文本形式存储密码的替代方案，这仍然要好得多。为什么？因为至少您没有存储可用于任何其他身份验证方案的原始凭证或泄露可能在其他环境中共享的密码(是的，不幸的是人们确实这样做了)。

鉴于这些知识，在存储这些散列凭证时仍应非常小心。最后，如果可以使用另一个更强的身份验证方案，请使用它。

因此，由于 NTLM 协议(protocol)的工作方式，它满足要求:

能够对 Exchange 2007+ 服务器进行身份验证

NTLM 适用于所有 Exchange 服务器 2007+

通过初始过程使身份验证成为“一次性设置”

凭证和目标只需要输入一次，因为一旦与服务器进行了初始握手，您就会知道身份验证方案有效。 (这当然没有考虑到可以随时更改远程 Exchange 服务器的配置。因此仍然应该适本地进行错误处理)

永远不要存储纯文本密码(尤其是在平台/服务中央数据存储中)

而是存储散列凭据。然而，由于前面注释中解释的“捕获”，应该非常小心，使用潜在的双重加密技术。

无论如何，我希望其他人在某个时候发现这一点，这样他们就不必像我那样做太多的规范阅读和实验。

此外，就其值(value)而言，因为我注意到 NTLM 的开源实现不仅很少见，而且更常见的是只完成了一半，所以我的团队已经在 PHP 中开源了我们的 NTLM 实现。 It's available on GitHub .