是否可以修改 ADFS 以使用 NTLM 凭据（如果存在）来对用户进行身份验证？
我们正在使用带有 ADFS 2.0 的 CRM 2011。我们的用户希望内部和外部用户都使用一个 url，但是如果我们还想通过用户当前的 NTLM 凭据使用自动登录，那么使用 CRM 2011 中的 IFD 配置，这是不可能的。是否可以修改 ADFS 登录页面以检测 NTLM 凭据是否存在且来自正确的域，如果是，则自动登录用户并使用正确的 ADFS 令牌将其重定向回应用程序？
是否有足够的 API 表面积和正确的类型供我们以这种方式修改登录页面，或者票务 API 是否已关闭以至于我们无法以编程方式执行此操作？
评论：我们知道，使用 UAG SP1，我们可以强制使用 NTLM 凭据登录 ADFS，但我们的客户不打算很快部署 UAG。
We are using CRM 2011 w/ ADFS 2.0. Our users would like for one url to be used for both internal and external users, but w/ the IFD Config in CRM 2011 this is not possible if we also want to use automatic login via the users current NTLM credentials. Is it possible to modify the ADFS signin page to detect if NTLM credentials are present and from the correct domain and if so automatically log the user in and redirect them back to the application with the correct ADFS tokens?
Is there enough API surface area and of the right types for us to modify the login page in this way or is the ticketing api closed off to the point that we couldn't do this programatically?
Comment: We know that using UAG SP1 we can force a logon to ADFS to occur with NTLM credentials but our client is not planning on deploying UAG anytime soon.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你的问题对我来说不太清楚，但无论如何，这里的某个地方可能有答案。
如身份验证处理程序概述页面中所述，AD FS 2.0 有几个的认证机制。选择其中的哪一个是根据“认证请求允许的”来确定的。这与来自用户浏览器的 HTTP 请求无关，而是与来自依赖方（在您的情况下为 CRM 2011）的登录请求有关。并且没有后备方案：对于四个处理程序中的每一个，“如果被调用，它不会将请求传递给下一个处理程序。”
例如，如果从 CRM 到 AD FS 的 WS-Federation 登录请求（通过浏览器发送）表示集成 Windows 身份验证没问题，并且您的
顶部有集成处理程序; 您想对不同的用户使用不同的身份验证方法吗？如果是这样，那么影响所选择的身份验证方法的唯一方法是从源头开始：理论上，CRM 可以根据来自用户或用户浏览器的某些信息来调整其身份验证请求。如果 CRM 基于 WIF，您也许能够在 WSFederationAuthenticationModule.RedirectingToIdentityProvider 事件。同事使用此机制在 SharePoint 中成功完成了 WIF 登录请求操作。
您是否总是希望无提示登录（而不是从浏览器获取 Windows 凭据对话框）？根据我们的经验，由于各种原因，IWA 协商可能无法使服务器相信客户端的 Windows 凭据实际上是有效的，从而导致浏览器明确要求提供凭据。最明显的原因是浏览器无法到达服务器的AD，但还有更多。
Your question is not really clear to me, but there may be an answer in here somewhere anyway.
As described on the Authentication Handler Overview page, AD FS 2.0 has a couple of authentication mechanisms. Which of these is chosen is determined based on what the "authentication request allows for". This is not about the HTTP request from the user's browser, but about the sign-in request coming from the relying party (CRM 2011 in your case). And there is no fallback: for each of the four handlers, "[I]f invoked, it does not pass the request on to the next handler."
So for example, if the WS-Federation sign-in request from CRM to AD FS (sent through the browser) says that integrated Windows authentication is fine, and if you have the Integrated handler at the top of your
<localAuthenticationTypes>list, then IWA is always used for authenticating the user (so either NTLM or Kerberos, depending on browser/server capabilities). Whether the user is "internal" or "external" doesn't matter.Do you want to use different authentication methods for different users? If so, then the only way to influence the chosen authentication method is at the source: in theory CRM could adapt its authentication request based on some information from the user or the user's browser. If CRM is based on WIF, you might be able to do request manipulation in the WSFederationAuthenticationModule.RedirectingToIdentityProvider Event. Colleagues did WIF sign-in request manipulation successfully in SharePoint, using this mechanism.
Do you always want silent sign-in (as opposed to getting a Windows credentials dialog from your browser)? In our experience, there are all kinds of reasons why an IWA negotiation can fail to convince the server that the client's Windows credentials are actually valid, making the browser ask explicitly for credentials. The most obvious reason is that the browser cannot reach the server's AD, but there are more.