简而言之：我是否应该使用一些众所周知的 uid 来验证 ldap 客户端，然后使用该客户端内的其他方式来验证用户输入的 uid 和 pw？
长格式：我们有一个基于 .net 的商业 Web 产品，该产品已在许多客户站点中实现，并且目前使用内部用户身份验证。
我正在研究使用 LDAP 进行目录身份验证。由于我们的产品是在各种环境中实施的，因此我希望它能够与尽可能广泛的符合 LDAP 的目录服务和配置兼容，包括但不限于 Active Directory。
除了身份验证之外，我还想使用用户的目录属性来确定他们是否有权使用该应用程序。我期望这将通过用户在特定组中的成员身份来指示。该组的名称将是应用程序的配置点。
目录服务仅用于确认用户 ID、密码和组成员身份。应用程序在处理用户的后续请求时不会假定用户的身份。因此，没有 FormsAuthenticationTicket。
我的第一个问题来自我审查过的身份验证示例，例如http://tldp.org/HOWTO/LDAP-HOWTO/authentication.html和http://msdn.microsoft.com/en-us/library/ff649227.aspx。这些使用用户输入的 ID 和密码来验证 LDAP 客户端。我认为这是合理的，但就我而言，客户端将继续执行其他 LDAP 搜索以确认组成员身份。我是否需要担心最终用户可能没有足够的目录权限来执行成员资格检查？在我看来，更好的做法是使用保留凭据进行 ldap 客户端身份验证，然后通过其他方式确认用户输入的 uid/pw。或者，也许绑定两次，一次使用用户凭据进行身份验证，第二次使用内置凭据进行搜索。我应该这样做吗，还是我只是让事情变得比需要的更难？
答案1
最小特权原则在这里适用。您用来绑定到 LDAP 并枚举用户、组和任何其他相关信息的帐户肯定应该是“服务帐户”，并且不是真实人类的账户。
与大多数人类用户相比，此帐户所需的权限有所不同。副总裁的助理不需要能够枚举所有组并查看给定帐户是否存在，但您用于绑定到 LDAP 的帐户确实需要这样做。
答案2
如果您使用系统帐户授予常规用户帐户所不具备的权限，则会发生权限提升。（在您的示例中，应用程序的用户可以看到他们自己无法看到的组成员身份。）这没问题，但请注意，任何权限提升都有可能被滥用。
就我个人而言，我更愿意这样编写 ACL，让用户帐户拥有他们需要的任何权限，并使用我的 LDAP 服务器（而不是我的下游应用程序）来管理访问权限。为什么您的用户帐户不能看到他们属于哪些组？
至于“最小权限”，这里的意思是使用用户的凭证，因为他已经有权访问它们。如果你使用共享系统帐户，那么——根据设计——额外的普通用户所不具备的特权。