locked
CRM2011 Claims-based auth prompts for credentials with a popup RRS feed

  • Question

  • Hi everyone,

    I've closely followed the "Configuration Claims-based Authentication for Microsoft Dynamics CRM 2011" documentation and I followed a few videos on configuring this feature. My end goal is to configure IFD but I can't get past getting claims-based auth to work even before IFD is enabled. I've searched these forums and read all posts that seemed to relate to this but still cannot get it working.

    When the site is accessed the user gets pop-up (NTLM style) to logon to the ADFS server (which shouldn't be happening). What's worse, entering domain account credentials fail to authenticate.

    I'm using a purchased wildcard SSL cert, DNS is setup, certificate privledges, ADFS Claim Rules configured. I've done all the stuff that seems to get other people working.

    I'm suspecting the problem is SPN related (because every other problem I've had with CRM has been SPN related). I read in the guide that adding the SPN HTTP/sts.contoso.com to the CRM server SPN may be required. I tried this but this step makes no sense to me because STS and CRM are not on the same sever.

    Any help appreciated.

    Monday, August 29, 2011 3:22 PM

Answers

  • I did successfully set this up, but by starting from scratch using instructions provided by CoreMotives and not Microsoft.  Due to IFD complexity the same vendor now supports additional options that do not require IFD.

    We did have a wildcard on ADFS, but it was from a different vendor as we discovered that some vendors cannot (or will not) provide a cert with a name under 128 characters which CRM requires.

    If you have any way at all of avoiding an IFD architecture I suggest you do so until Microsoft tightens this up.

     

    Monday, October 24, 2011 12:38 PM

All replies

  • moving to deployment and bumping

    Regards, Donna

    Tuesday, September 6, 2011 11:41 AM
  • Hi there,

    I'm having the same problem did you find any solution for this?

     

    Regards,

    Zoran

     

    Monday, September 12, 2011 3:37 PM
  • I'm still having this problem - Is there anyone else besides Zoran and me having this problem?
    Monday, September 12, 2011 3:44 PM
  • Same problem here
    Monday, September 12, 2011 3:48 PM
  • Do you get the same prompt for login if you try to connect from another machine that is NOT the ADFS box?  There have been some issues with the disable loopback check or SPN’s here when hitting from the ADFS box itself, but all others work fine. If we cannot hit the initiated sign on page below a case should be created with the ADFS team to help troubleshoot. 

    https://<sts1here>.<domainhere>.com/adfs/ls/idpinitiatedsignon.aspx

    Here are some additional things to try I found in a similar case.

    1. Add the ADFS URL to intranet sites in IE (the ADFS URL is a FQDN URL thus IE will default it to the Internet Sites zone which does not pass credentials. Adding the URL to the intranet sites zone enabled IE to pass credentials by default).
    2. Add SPN for the ADFS URL. Commonly the ADFS URL will not match the Machine name thus SPN’s should be added under the machine account (Kernel Mode auth is turned on by default)
    3. If IE  still prompts you might need to turn off Extended protection on the Integrated auth method on the LS directory on the ADFS server (Open IIS | Goto the Default Web Site | Expand ADFS | Expand LS | Double Click Authentication | Rightclick on Windows Authentication and Click Advanced Settings | Change “Extended Protection: ” to Off
    4. Finally if you continue to get three prompts and then an error you might also need to disableloopbackcheck on the ADFS server. (See KB http://support.microsoft.com/kb/896861 Method 2).

    Hope that helps.


    Corey Hanson, Dynamics CRM Supportability PM
    Monday, September 12, 2011 6:11 PM
  • Corey, I have tried all 4 of your recommendations.

    1 - Bypasses the first adfs prompt and goes to the crm server, prompts 3 times then 401

    2 - No effect

    3 - No effect

    4 - No effect

    I have also started the entire IFD setup from scratch and get the exact same result. 

    Monday, September 12, 2011 11:19 PM
  • Hi Matt,

    You need to create SPN record if you get 401 error.

    Log in to ADFS server and create SPN record from that server.

    cmd->setspn -a http/adfs.domain.com domain\servername$

    do iisreset.

    then try to access https://adfs.domain.com/adfs/ls/IdpInitiatedSignOn.aspx

    If you still find the authentication issue then remove the duplicate SPN records

    setspn -x(this will show the duplicate SPN records)

    You can delete duplicate SPN records from Active Directory Server

    ADSI Edit->Actions-Connect to->Ok->collapse default tree->collapse CN=Computers->select the CRM server name-> Properties->select servicePrincipalName->Edit-> Remove the duplicate SPN's.

    do iisreset

    Then try to access.

     

    Regards,


    Khaja Mohiddin|||||http://www.dynamicsexchange.com/
    Tuesday, September 13, 2011 9:12 AM
  • That is suggestion #2 from Corey's message, which did not solve the issue.
    Tuesday, September 13, 2011 2:19 PM
  • Matt - Just to clarify where you are now getting the prompt at.  So you can now get the ADFS url to resolve fine but it now prompts on when trying to redirect you back over to the CRM URL, is that correct?

    Do you have an SPN under your CRM Service account for the CRM url or under the machine account if you have kernel mode authentication enabled on the CRM Server?

    Are there any Kerberos or KDC errors in the event logs of either your CRM server, ADFS server or DC?

    Can you confirm the identity running CRM application pool has full control on the certificate you selected while configuring claims in CRM?

    Thanks


    Corey Hanson, Dynamics CRM Supportability PM
    Tuesday, September 13, 2011 4:15 PM
  • Yes, I no longer see the original prompt from adfs, the prompt is from the crm server. So I am getting 3 prompts instead of 4 now, still ending in a 401.

    Yes, I have an spn for the crm service account and the crm app pool account in the format:

    HTTP/crm.domain.com:port
    HTTP/crm:port

    On the crm server kernel mode authentication is enabled, extended protection off.

    Don't see any errors, but in the security logs on crm server I see 3 pairs of audit success records, oddly - one special logon (4672) then a logon (4624).  Event 4624 shows a null SID and a logon guid that is all 0's, if that is relevant, but all of the account info is correct and it looks like the logon worked.  I don't see anything at all on the adfs server that correspond with these.

    I have tried both read and full control on the cert for the app pool account, currently it has full control but it doesn't affect the result.

     

     

     

    Wednesday, September 14, 2011 1:39 PM
  • Hi Matt,

    since you tried all the solutions, I suggest you to open a case with Microsoft on this issue.

     

    Regards,


    Khaja Mohiddin|||||http://www.dynamicsexchange.com/
    Wednesday, September 14, 2011 1:59 PM
  • Is your CRM Service Account the same account running the CRM App Pool? If not then you want to make sure you do not have duplicare SPN's setup if you put the same HTTP spn under each account. Normally it should just be needed under the CRM App Pool account.

    However, in your case since you have kernel mode authentication enabled the SPN should be under the CRMServer machine account and not under the user account.

    http://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx

    Make sure to restart IIS after making these changes to test if they worked or not.

    Are you able to browse the CRM federation metadata url that is generated when you run through the CRM Claims wizard to enable claims without getting prompted?

    If the above still doesn't help, you may want to consider logging a support case so we can get one of our engineers more involved in helping troubleshoot this issue.

    Thanks


    Corey Hanson, Dynamics CRM Supportability PM
    Wednesday, September 14, 2011 2:16 PM
  • The app pool and service accounts are different. 

    Let me get this right, the crm server machine account needs an spn to the crm server url?  so i create the spn's in the same format

    HTTP/crm.domain.com:port
    HTTP/crm:port

    for domain\crm$ ?

    The federation metadata is fine from both ends, no prompts.

    Wednesday, September 14, 2011 2:20 PM
  • Right it would be under the crm server machine account.  In the link I sent in the last post take a look at scenario 2a and 2b.  Those would be similar to your scenario and has the syntax of the setspn listed. 

    Setspn -a http/crm.domain.com:port <myIISserver-NetBIOS-name> where <myIISserver-NetBIOS-name> is the IIS machine account.

    Just be sure to remove the other SPN's so you don't end up with duplicate http spns on other accounts.


    Corey Hanson, Dynamics CRM Supportability PM
    Wednesday, September 14, 2011 2:44 PM
  • Tried adjusting the spn as above, same result.

    Wednesday, September 14, 2011 3:09 PM
  • For those poor people still having this problem. I found the resoultion for me that worked great.  The problem came from the fact I was trying to use my wilcard ssl cert on both my crm and ADFS server.   I went out and got the ADFS server its own cert and did not use the wilcard and it all worked perfectly after that.  Hope this helps.

     

    • Proposed as answer by Andrey Belykh Thursday, June 28, 2012 9:30 PM
    Saturday, October 22, 2011 1:03 AM
  • I did successfully set this up, but by starting from scratch using instructions provided by CoreMotives and not Microsoft.  Due to IFD complexity the same vendor now supports additional options that do not require IFD.

    We did have a wildcard on ADFS, but it was from a different vendor as we discovered that some vendors cannot (or will not) provide a cert with a name under 128 characters which CRM requires.

    If you have any way at all of avoiding an IFD architecture I suggest you do so until Microsoft tightens this up.

     

    Monday, October 24, 2011 12:38 PM
  • Just to clarify that the 128 character limit was addressed in Update Rollup 4.  The limit has been increased to 512.

    Matt - Was there specific steps that where missing from the Claims whitepaper we have on the download site that we should get updated?  If you care to share what instructions would have helped, I can make sure the feedback gets back to the doc team to get it updated.  I agree claims is a complex topic, so any feedback you have on the claims whitepaper and what would have helped would be appreciated.

    Thanks


    Corey Hanson, Dynamics CRM Supportability PM
    Monday, October 24, 2011 1:43 PM
  • I would have to go back and compare the two sets of instructions, and since we have abandoned IFD and are now catching up for all the lost time I don't really have the time to do this.

    I suggest contacting CoreMotives if you really want feedback, they have been through many more IFD scenarios.

    Monday, October 24, 2011 2:02 PM