我们正在使用带有 ADFS 2.0 的 CRM 2011。我们的用户希望一个 url 可用于内部和外部用户，但是如果我们还想通过用户当前的 NTLM 凭据使用自动登录，则使用 CRM 2011 中的 IFD 配置是不可能的。是否可以修改 ADFS 登录页面以检测 NTLM 凭据是否存在并且来自正确的域，如果存在则自动登录用户并将其重定向回具有正确 ADFS 令牌的应用程序？
是否有足够的 API 表面积和正确的类型让我们以这种方式修改登录页面，或者票务 API 是否关闭到我们无法以编程方式执行此操作的程度？
评论：我们知道使用 UAG SP1，我们可以强制使用 NTLM 凭据登录到 ADFS，但我们的客户不打算很快部署 UAG。
你的问题对我来说不是很清楚，但无论如何这里可能有一个答案。
如身份验证处理程序概述页面中所述，AD FS 2.0 有几个身份验证机制。选择哪一个是根据“认证请求允许的”来确定的。这与来自用户浏览器的 HTTP 请求无关，而是关于来自依赖方的登录请求（在您的情况下为 CRM 2011）。并且没有回退：对于四个处理程序中的每一个，“[I] 如果调用，它不会将请求传递给下一个处理程序。”
例如，如果从 CRM 到 AD FS 的 WS-Federation 登录请求（通过浏览器发送）表明集成 Windows 身份验证很好，并且如果您的<localAuthenticationTypes>列表顶部有集成处理程序，那么 IWA 始终用于对用户进行身份验证（因此是 NTLM 或 Kerberos，具体取决于浏览器/服务器功能）。用户是“内部”还是“外部”并不重要。
您想对不同的用户使用不同的身份验证方法吗？如果是这样，那么影响所选身份验证方法的唯一方法是从源头上：理论上 CRM 可以根据来自用户或用户浏览器的某些信息调整其身份验证请求。如果 CRM 基于 WIF，您可能能够在WSFederationAuthenticationModule.RedirectingToIdentityProvider Event中进行请求操作。同事使用这种机制在 SharePoint 中成功进行了 WIF 登录请求操作。
您是否总是想要静默登录（而不是从浏览器获取 Windows 凭据对话框）？根据我们的经验，IWA 协商无法让服务器相信客户端的 Windows 凭据实际上是有效的，导致浏览器明确要求提供凭据的原因有很多。最明显的原因是浏览器无法访问服务器的AD，但还有更多。