Reputation: 1821
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.
Upvotes: 4
Views: 7015
Reputation: 9769
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.
Upvotes: 1