我不是任何方式的IIS或Active Directory专家，所以我想在这里介绍一个场景，看看我们想要完成的是否可行。
我们有一个托pipe在Windows Server 2008 R2上的应用程序和一系列通过IIS公开为API的Web服务。 这些服务将被多个外部集成系统调用。 如果我们将IIS服务configuration为使用基本身份validation，IIS将默认validation我们传递给Active Directory的凭据，这是一个特殊的configuration设置，还是这不可能？ 我们希望这些凭证能够针对AD进行validation，因此我们会收到令牌/主体作为回报，并将其发送到该服务器上的底层应用程序。
提前致谢。 任何帮助表示赞赏。
基本身份validation对AD进行身份validation会很有效 – 它会根据IIS服务器的本地帐户数据库进行身份validation; 对于一个域成员来说，它包含了它所join的林中的Active Directory域。
你不会得到任何forms的kerberos票 – 基本authentication只是在发送到服务器的请求的头部包含密码，服务器用它做什么 – 返回所请求的资源或401错误。但是如果您正在IIS内的Web应用程序中查找用户标识，则该代码应该可以使用该信息（authentication为哪个用户/域）。
浏览器将在会话期间将input的密码保存在内存中，因此您将被保密以便后续请求访问该服务器，但不能访问其他系统或服务。
有关于configuration基本身份validation的信息，包括configuration默认域和用户收到的提示。
好，所以答案已经被接受了，但是我一般会说：
不要使用Basic。
如果有一个关于哪个Basic-with-domain-credentials看起来是正确答案的问题，那几乎总是没有。
使用集成authentication。
基本允许恶意网页开发人员学习用户的AD凭据，然后游戏结束。
集成允许用户authentication他们是谁，并允许使用约束委派来限制Web开发人员可以对令牌执行的操作。 它不直接暴露用户名和密码来截取（如果SSL是错误的（即不是）configuration，这发生在所有怪异的时间），并且它不允许有写访问权限的Web服务器共享编写拦截凭证的简单Web应用程序。
如果IIS具有用户凭据，则可以使用这些用户凭证为该用户创build主令牌。 IIS可以使用该令牌并模拟该用户访问其他服务器上的资源和应用程序。
IIS机器和应用程序池标识（服务帐户）需要configuration适当的模拟或委派级别以代表具有令牌的用户，但是这种情况在IIS / ASP中实际上相当普遍。净世界。
如果要执行Tristan提到的受限委派 – 实际上可以为用户创build一个完整的授权级令牌，以访问特定机器上的特定服务（这是受限制的部分），并且实际上并不需要他们的密码。 如果您有外部身份validation机制（如智能卡），则这样做更安全，只有身份传递给Web应用程序。 这避免了在安全边界之外传输密码的需要。
如果您希望使用AD来validationWeb用户，则必须使用集成身份validation。
对于有权访问networkingstream量的任何人，HTTP基本身份validation不安全，不受保护，并且受到严重破坏。
Windows对于允许用户使用AD凭证进行基本身份validation会非常不安全 – 这会自动使这些凭据不可信。