locked
Problem using Internal and External addresses with Claim based auth and IFD. RRS feed

  • Question

  • Hi All

    I'm trying to get my system setup to use IFD for the external addresses and have a separate internal address that internal users use, so that they don't have to authenticate using IFD.

    I have followed the new guide for setting up Claims based auth & IFD, and IFD works fine for both internal and extenral users, but I cannot get the internal address working. When I try the Internal address on the local LAN, I get a windows login prompt, and even if I type the users name and password in the in domain\username and username formats it doesn't login.

    Anyone have any pointers?

    Thanks

    Wayne

     

     


    Wayne TAYLOR
    Thursday, March 17, 2011 1:44 PM

Answers

  • Wayne:

    What kind of SSL certificate are you using? A wildcard or SAN? In my environment I ended up using a SAN certificate that allows me to specify different URLs to protect with a single certificate. I understand that the instructions for setting up IFD discuss the ability to use a wildcard cert, but in my case I started setting it up before those instructions were made available, and I couldn't get a wildcard cert to work, but a SAN cert did.

    Also, do you have two Relying Parties set up in AD FS, or just one? Another thing I needed to do to get both internal and external access working was to set up a separate relying party for each method. One used the URL for the federationmetadata.xml that was accessible externally, and one used a URL for internal access, like this:

    External: https://ifd.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml
    Internal: https://crmserver/FederationMetadata/2007-06/FederationMetadata.xml

    Looking at these two URLs, I found that there were two different XML files that listed different identifiers for ADFS. I'm not sure if this is the intended design, or if I generated two different federation metadata files by trying multiple ways of configuring claims in the CRM deployment manager.

    I hope this info helps to get you further along.


    Matt Wittemann CRM MVP C5Insight.com
    • Proposed as answer by Jim Glass Jr Wednesday, March 30, 2011 3:13 PM
    • Marked as answer by Donna EdwardsMVP Wednesday, April 20, 2011 12:35 PM
    Wednesday, March 30, 2011 2:38 PM
    Moderator
  • Had the same problem with the internal CRM site prompting for credentials after setting up claims and IFD, but found that if I added the internal STS (in my case https://adfs.london.crm) to local Intranet, then everything seemed to work fine

     

    Regards

     

    John

    Tuesday, April 19, 2011 1:27 PM
  • Hi Guys,

    The issue has resolved for me. It was SPN issue.

    I have added spn for ADFS and its working fine for me.

    Creating SPN for ADFS: 

    Go to Command prompt

    setspn -a http/adfs.domain.com  domain\crmserver$

    iisreset

    Now try to browse your organization from Deployment Manger.
    regards,

    Khaja Mohiddin
    Wednesday, April 20, 2011 12:05 PM

All replies

  • Hi no this is CRM 2011 using Claims based Auth and IFD.

    Wayne


    Wayne TAYLOR
    Thursday, March 17, 2011 6:39 PM
  • Yes I used that video to get the IFD working, but that only gets external IFD working, not an internal address for use inside the neywork.

    Wayne

     

     

     


    Wayne TAYLOR
    Tuesday, March 29, 2011 11:19 AM
  • Depending on your environment, the steps you need to take to get internal working may vary.  I know the CRM MVP's are planning to post a Wiki article on the new CRM Wiki site.  

    Since you've already read through the Claims Authentication Guide, I won't bother offering that again.  In your post you state that you've gotten the Internal and External link to work but your users receive the login prompt when accessing internally.

    Let's try a couple of things, please ensure the remove windows login credentials.  Sometimes CRM can be a little tricky and try to use those credentials when we don't expect it.  Here are the steps

    Go to control panel, user accounts, manage windows credentials and remove CRM credentials or any credential you think CRM might be trying to use.  Also, add CRM to the Intranet Trusted Sites

    One last thing if none of the above works, run Fiddler and look at the results when trying to log in.  It should point you in the right direction or at least give you some additional information.


    Regards, Donna


    Wednesday, March 30, 2011 1:57 PM
  • Wayne:

    What kind of SSL certificate are you using? A wildcard or SAN? In my environment I ended up using a SAN certificate that allows me to specify different URLs to protect with a single certificate. I understand that the instructions for setting up IFD discuss the ability to use a wildcard cert, but in my case I started setting it up before those instructions were made available, and I couldn't get a wildcard cert to work, but a SAN cert did.

    Also, do you have two Relying Parties set up in AD FS, or just one? Another thing I needed to do to get both internal and external access working was to set up a separate relying party for each method. One used the URL for the federationmetadata.xml that was accessible externally, and one used a URL for internal access, like this:

    External: https://ifd.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml
    Internal: https://crmserver/FederationMetadata/2007-06/FederationMetadata.xml

    Looking at these two URLs, I found that there were two different XML files that listed different identifiers for ADFS. I'm not sure if this is the intended design, or if I generated two different federation metadata files by trying multiple ways of configuring claims in the CRM deployment manager.

    I hope this info helps to get you further along.


    Matt Wittemann CRM MVP C5Insight.com
    • Proposed as answer by Jim Glass Jr Wednesday, March 30, 2011 3:13 PM
    • Marked as answer by Donna EdwardsMVP Wednesday, April 20, 2011 12:35 PM
    Wednesday, March 30, 2011 2:38 PM
    Moderator
  • Hi everybody,

    I have the same problem as Wayne has - I followed the Configuring Claims-based Authentication guide and passed so far only first part - the claims based authentication for internal LAN users. Everything looks good and the intermidiate tests passed (like accessing through IE the metadata xml file) , however when I try to access the CRM using the internal URL: https://internalcrm.contoso.com:444 - the Windows authentication appears again and again and doesn't work even with valid credentials. It looks like it goes first to https://sts1.contoso.com and that is where the repeating authentication screen appears. Control Panel is checked - it is clean there. Also *.contoso.com is in the Trsusted Sites in IE. Please help and thank you.

    Best regards,

    Victor.

     

     

    Monday, April 4, 2011 8:52 PM
  • Hi,

    This is me again. I completed the second part of the Configuring Claims-based Authentication guide - the IFD part. And again the case exactly as Wayne's - it works just fine through IFD and related URL https://org.contoso.com:444 . So the issue is limited only to the access from the inside the LAN - the repeating Windows logon screen. Please help to fix the issue. Wayne, did you resolve the challenge?

    Best regards,

    Victor.

    Monday, April 4, 2011 10:12 PM
  • Hi Victor

    No I've still got the same problem. I've tried all sorts of things, so at the moment I'm just resigned to the fact that I have to use the normal external IFD login for all users!!

    If anyone has any other pointers, please let me know!

    Wayne

     

     


    Wayne TAYLOR
    Friday, April 8, 2011 9:37 AM
  • Hi

    I am using a proper wildcard certificate, so hopefully that will be OK.

    I have created two relying parties, much as you said, although I used a fully qualified name for the internal, ie.  https://intcrm.shinesystems.co.uk:444/2007-06/FederationMetadata.xml

    Wayne


    Wayne TAYLOR
    Friday, April 8, 2011 9:42 AM
  • Hi Donna

    I'll try your suggestions thanks.

    For the Internal access, I get prompted for login credentials but whatever I use I cannot access!

    I'll try the Fiddler etc and see what I can see.

    Thanks

    Wayne


    Wayne TAYLOR
    Friday, April 8, 2011 9:43 AM
  • Did Fiddler provide any additional clues?

    Regards, Donna

    Monday, April 11, 2011 6:06 PM
  • Hi Donna

    I ran it, but to be hinest I wasn;t too sure what I should be looking for!  I've never ran Fiddler before and cannot see what I need to do to get any meaningful info out!

    Can you give me any pointers.

    Thanks

    Wayne

     


    Wayne TAYLOR
    Monday, April 11, 2011 9:36 PM
  • Take a look at this page and focus on the way to see http traffic.  What I was hoping is that you would see the http traffic and see if you were getting a 401 or maybe getting redirected to a site that doesn't exist.  If you watch the http traffic, it might point you in the right direction.

    Regards, Donna

    Monday, April 11, 2011 10:53 PM
  • Had the same problem with the internal CRM site prompting for credentials after setting up claims and IFD, but found that if I added the internal STS (in my case https://adfs.london.crm) to local Intranet, then everything seemed to work fine

     

    Regards

     

    John

    Tuesday, April 19, 2011 1:27 PM
  • Hi Donna,

     

    I have the same issue as Wayne.

    I can able to view the federationmetadata.xml without any errors. Later i have added internal crm in ADFS.

    When i try to access the CRM, it prompts for username and password. It prompts for 4-5 times then i am getting 401.1 error.

    Then i have enabled Form based authentication for Default Website\adfs\ls, then i tried to access its throwing me error as reference ..........some guid.

    tried with Fiddler tool also, but nothing is moving forward.

    Regards, 


    Khaja Mohiddin
    Tuesday, April 19, 2011 4:59 PM
  • H Khaja,

     

    I wish I could help you with this but Matt Wittemann definitely has significantly more experience with this than I.  I'm guessing you followed all the tutorials and guides reference in this post and are still getting stuck.  If it is possible for you, you might want to consider contracting with a Microsoft Partner for a few hours to see if they can have a look and get you pointed in the right direction.  Thank you! 


    Regards, Donna

    Tuesday, April 19, 2011 6:22 PM
  • Hi Donna,

    Thanks for that, i will look forward to raise a case with microsoft or i will contact Henning.

    Previously we worked with henning on IFD, but this is kinda weird issue.

    regards,


    Khaja Mohiddin
    Wednesday, April 20, 2011 9:57 AM
  • Hi Matt,

    Yes i am using SAN Certificate, because my external and internal domains are different.

    This problem due to certificate issue?

    some times from my logs i found that AdfsArtiFact is corrupted.

    how can i delete the existing website(adfs) from default website, and im thinking to delete th database also adfs app and install it again.

    regards,


    Khaja Mohiddin
    Wednesday, April 20, 2011 10:00 AM
  • Hi Guys,

    The issue has resolved for me. It was SPN issue.

    I have added spn for ADFS and its working fine for me.

    Creating SPN for ADFS: 

    Go to Command prompt

    setspn -a http/adfs.domain.com  domain\crmserver$

    iisreset

    Now try to browse your organization from Deployment Manger.
    regards,

    Khaja Mohiddin
    Wednesday, April 20, 2011 12:05 PM
  • You're welcome, I look forward to hearing how you get this resolved.  have a great day!

    Regards, Donna

    Wednesday, April 20, 2011 12:09 PM
  • I had a similar problem and all above solutions didn't work.

    After i followed Rigid suggestions located at: http://social.microsoft.com/Forums/en/crmdeployment/thread/853a38ad-8acd-470f-88b7-bb26b3cfcbd9

    My internal password prompt issue went away.

    No need for SPN for any computer account.

    Use IIS manager (expand to the Crm web site, click on Configuration Editor, navigate to "system.webServer/security/authentication/windowsAuthentication" and update useApplicationPoolCredentials to True).

    Hope this helps anyone with the above problem.



    Wednesday, May 25, 2011 2:27 AM
  • None of the proposed answers worked for me either.  I have my internal .net domain and my public .com domain.  I want my CRM deployment to work for my public domain name.

    SSL Card type:  Wildcard for domain.com

    Solutions I have tried:  

    using setspn for the subdomain name adfs.domain.com

    Following This guide:  http://blogs.msdn.com/b/crm/archive/2011/01/13/configuring-ifd-with-microsoft-dynamics-crm-2011.aspx  

    and This guide:  http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

    typing the machine name, typing the FQDN I want to use

    specifying the port number

     

    Do I need to add the domain.com zone as a secondary name server provider on my internal DNS servers?  What about using host headers?  

    Friday, November 25, 2011 5:28 AM