我绝不是 IIS 或 Active Directory 专家，所以我想在这里介绍一个场景，看看我们想要完成的事情是否可行。
我们在 Windows Server 2008 R2 上托管了一个应用程序，该应用程序通过 IIS 以 API 的形式公开了一系列 Web 服务。这些服务将由多个外部集成系统调用。如果我们将 IIS 服务配置为使用基本身份验证，IIS 是否会默认根据 Active Directory 验证我们传递给它的凭据，这是一种特殊的配置设置，还是不可能？我们希望根据 AD 验证这些凭据，以便我们收到令牌/主体作为回报，可以将其发送到该服务器上的底层应用程序。
提前致谢。如能提供任何帮助，我们将不胜感激。
答案1
基本身份验证非常适合针对 AD 进行身份验证 - 它针对 IIS 服务器的本地帐户数据库进行身份验证；对于域成员，这包括它所加入的林中的 Active Directory 域。
您不会得到任何类型的 Kerberos 票证 - 基本身份验证仅将密码包含在发送到服务器的请求标头中，服务器将对其进行执行 - 返回请求的资源或错误401..但如果您在 IIS 中的 Web 应用程序中寻找用户身份识别，那么该信息（他们以哪个用户/域进行身份验证）应该可供代码使用。
浏览器会在会话期间将输入的密码保存在内存中，因此您将可以访问该服务器的后续请求，但无法访问其他系统或服务。
有关于配置基本身份验证的信息，包括配置默认域和用户收到的提示，这里。
答案2
好的，答案已经被接受了，但我总体上要说的是：
不要使用 Basic。
如果对于某个问题，Basic-with-domain-credentials 看起来似乎是正确的答案，但事实几乎总是如此。
使用集成身份验证。
Basic 允许恶意的 Web 开发人员了解用户的 AD 凭据，然后游戏就结束了。
集成允许用户验证他们的身份，并允许使用约束委派来限制 Web 开发人员可以使用令牌执行的操作。它不会直接将用户名和密码暴露给拦截（如果 SSL 配置错误（即未配置），这种情况经常发生），并且它不允许对 Web 服务器共享具有写访问权限的人编写拦截凭据的简单 Web 应用程序。
答案3
如果 IIS 拥有用户凭据，则可以使用它们为该用户创建主令牌。IIS 可以使用该令牌并模拟该用户来访问其他服务器上的资源和应用程序。
需要将 IIS 计算机和应用程序池标识（服务帐户）配置为适当级别的模拟或委派，以便使用其令牌代表用户行事，但这种情况在 IIS/ASP.Net 世界中实际上相当常见。
如果你要表演受约束的授权- Tristan 提到 - 实际上可以为用户创建一个完整的委托级令牌，用于访问特定机器上的特定服务（这是受约束的部分），并且您实际上不需要他们的密码。如果您有外部身份验证机制（例如智能卡），并且只有他们的身份被传递给 Web 应用程序，那么这会更安全。这消除了在安全边界之外传输密码的需要。
答案4
如果您希望使用 AD 来验证 Web 用户，则必须使用集成身份验证。
HTTP 基本身份验证不安全、不受保护，并且对于任何有权访问网络流量的人来说都很容易受到破坏。
对于 Windows 来说，允许人们使用 AD 凭据进行基本身份验证是非常不安全的 - 这会自动使这些凭据变得不可信。