如今，任何组织都有一个包含该组织用户的LDAP目录。 如果仔细观察，会发现一个或多个使用同一目录进行“身份验证”的应用程序。 而且这里的引号不是偶然的，因为LDAP是一种目录读取协议，旨在读取，写入和搜索目录服务。 这不是身份验证协议。 相反，术语“ LDAP认证”是指协议的一部分（绑定操作），它确定您是谁以及对目录信息具有什么访问权限。
随着时间的流逝，LDAP已成为事实上的身份验证服务。 诸如Active Directory之类的广泛而负担得起的LDAP服务已经成为想要将身份验证集成到其产品中的软件开发人员的一个小窍门。 LDAP客户端库可用于几乎所有框架，并且集成相对容易实现。
但是，尽管使用LDAP可以帮助解决在公司的各种应用程序中实现用户身份验证的问题，但这仍然会带来许多问题。 与专门设计的身份验证协议不同，使用LDAP会导致各种信息安全漏洞。
要了解这些漏洞是什么，您首先需要了解LDAP身份验证的工作方式。
LDAP验证如何工作
想象以下情况（这与现实相去甚远，但却完美地传达了本质）。
假设我在网上商店下了订单，以便在我不在的时候将其交付到我家。 快递员到达后，在门下留下了一条便条，上面写着“对不起，我们没有找到您”，并要求我在方便的时间在最近的提货地点提货。 在接送点，员工询问我的姓名，地址，并询问房子的钥匙以确认我的身份。 然后，送货服务人员来到我家，用我的钥匙打开门。 他进入屋内以确保我住在那里，例如，从墙上的照片或来往信件中的收件人的名字。 此后，该员工返回问题点，并通知我他已成功确认我的身份，我可以收到我的包裹！ 万岁！
除了物流问题外，这种情况还存在其他问题。 如果不道德的审核者复制了我的密钥怎么办？ 还是他长时间无人看管钥匙，还有其他人吗？ 如果测试人员遭到攻击并拿走了我的钥匙怎么办？ 当我把公寓的钥匙交给一个陌生人时，我不能确定他的体面和我的安全。
幸运的是，在现实世界中，我们有由政府机构签发的身份证件，例如驾照或护照，其真实性毋庸置疑。 我可以将这些文件提供给快递员以供自己识别，而无需交出钥匙。
在LDAP世界中，我们仍然必须传递密钥来代表我们打开门。 我们将密码传送给第三方，他正在尝试将其渗透到LDAP服务器中。 如果他设法获得访问权限，我们不能确定我们的凭据没有受到损害。 在这种情况下，攻击者不仅可以解锁LDAP门，还可以访问使用相同凭据的任何应用程序。
幸运的是，在更完整的身份验证世界中，我们还拥有护照和驾照！ 诸如Kerberos，SAML和OpenID Connect之类的身份验证协议向第三方发行令牌。 令牌确认您是您的身份，因此无需将密钥转让给任何人。 由于LDAP从未被设计为认证协议，因此它缺乏适当的机制。
LDAP作为身份验证系统的缺点
2007年，Shumon Hack发表了科幻小说（
LDAP弱点作为中央身份验证系统 ），其中描述了将LDAP用作身份验证系统时的三个具体问题。
1.该应用程序可能不够安全，无法处理凭据
作者强调指出，保护少量的身份验证服务器不受攻击比保护大量的应用程序服务器容易得多。
通常，身份验证服务器通常在信息安全领域具有丰富经验的专家的密切监督下。
另一方面，应用程序服务器具有完全不同的安全级别，并且更容易受到威胁。 它们的安全性较差，无法与更复杂的软件堆栈一起使用，并且更容易出现漏洞。 而且，通常它们是由对安全性不了解的人来管理的。 建立正确的安全系统是一个复杂的过程，很容易出错。
问题在于，如果一台应用程序服务器受到攻击，那么其所有者在攻击过程中使用的所有凭据也会受到攻击。 使用相同LDAP目录进行身份验证的任何其他系统都将受到威胁。
2. LDAP服务器无法保护用于获取凭据的身份验证机制
LDAP服务器不能保证事务的安全性。 例如，尽管LDAP服务器可以通过TLS强制执行绑定，以确保凭据不会以明文形式传输，但是服务器本身从未在从用户那里获取凭据方面发挥任何作用。 应用程序可能会通过不安全的通道接收密码。
3.用户被迫与第三方共享其身份验证秘密
用户密码或身份验证机密必须保留为
机密 。 只有用户和身份验证系统才知道。 使用LDAP身份验证时，用户被迫与第三方共享他的秘密，以便她随后可以使用该秘密代表用户与LDAP目录进行交互。
重要的是要提到，当使用经过特殊设计的身份验证协议（例如Kerberos）时，甚至是从较早的NTLM使用时，用户的机密都不会通过网络传输。 客户端设备和服务器使用加密操作来相互证明它们具有相同的机密，甚至不交换密钥本身。
关于Shumon Hook的要点，我将根据我自己的经验来描述LDAP身份验证的一些细微差别。 首先，主题涉及Active Directory的使用。
4.许多开发人员对LDAP机制了解不足，无法正确使用它
我过去的
一篇博客文章描述了匿名和未经身份验证的绑定如何使智商超出应用程序开发人员的范围，并导致未经授权的用户跳过。 无需身份验证即可执行绑定操作的能力是该协议的精妙之处之一，即使是最有经验的LDAP专家也不会意识到。
目录不容易组织，并且能够存储大量的组织信息，并提供了许多可自定义的存储方式。 我看到很多情况下，应用程序开发人员认为存在某个对象类或属性，而当未检测到它们时，应用程序崩溃了。 对于用户身份验证，不应要求和应用有关目录中存储的数据结构的知识。 身份验证协议应该从位于较低级别的对象存储库的详细信息中抽象出来。
5.应用程序管理员通常无法正确配置LDAP客户端
在大型分布式环境中管理Active Directory时，有一个令人讨厌的细微差别：很难确定哪些特定应用程序将Active Directory用作LDAP目录，以及应用程序管理员如何精确配置LDAP客户端。
以下是配置错误的恐怖示例。
- 在应用程序中对DN进行硬编码，或在绑定操作中使用DN。 在目录中重命名或移动对象时，总是会出现麻烦，这都是因为有人在某个地方对DN进行了硬编码。 （请注意那些使用Active Directory执行简单绑定操作的用户：无需使用DN。ActiveDirectory还提供了比使用传统格式更可靠的替代DN格式）。
- 对于绑定操作，不使用服务帐户，而是使用开发人员或管理员的个人帐户（想象一下，当帐户所有者离开公司时会发生什么）。
- 将明文密码发送到端口389。
- 在某些使用TLS（端口636）连接到AD的应用程序中，不需要“验证证书”复选框。 为什么这通常可以接受？ 如何在不确信其真实性的情况下将密码传递给第三方服务？
使LDAP客户端工作很容易。 但是，仅它起作用的事实并不意味着该配置正确。
6. LDAP认证和现代认证服务是互斥的
使用LDAP进行身份验证的应用程序将始终必须依赖用户名和密码。 尝试实施现代技术（例如多因素身份验证和单点登录）实际上是不可能的（除非您要实施自己的技术，这本身就是一个坏主意）。 FIDO联盟致力于使密码成为过去的遗物，每个使用LDAP身份验证的应用程序都会成为无密码策略的障碍。
有哪些选择？
如今的Web应用程序确实可以在没有LDAP身份验证的情况下完成工作。 有许多很棒的Web身份验证协议，例如SAML，WS-Federation和OpenID Connect，它们不需要用户凭据即可与第三方应用程序一起使用。 无数产品提供这些服务，包括Active Directory联合身份验证服务（内置于Windows Server）或第三方服务，例如Microsoft Azure AD，Okta，Ping等。 如果您的组织没有联邦IdP，则要做的第一件事就是实施它。
选择新软件时应注意的主要事情是对现代身份验证协议的支持。 即使企业此时此刻需要应用程序，也不要急于选择解决方案，尤其是当此选择仅限于具有LDAP身份验证的产品时。 值得尝试向选定的供应商传达使用更现代的身份验证协议来改进产品的需求。 也许他会听取并修改他的发展计划。
具有支持现代身份验证协议的“胖客户端”的桌面应用程序的数量正在增长，这的确是一个喜人的趋势。 这些应用程序通常是LDAP身份验证的据点。 越来越多的SDK（例如Microsoft身份验证库（MSAL））使开发人员可以轻松地在其移动和桌面应用程序中添加对现代身份验证服务的支持。
最终，值得认识到的是，在当今的现实中，并非所有的应用程序都支持现代身份验证协议，而且可能永远不会。 在任何组织中，都可能无法实现对LDAP身份验证的全面禁止。 但是，绝对不应在组织内部鼓励LDAP身份验证。 仅在没有其他选择的情况下，才应考虑使用LDAP。