locked
CRM 2013 Claims Based Authentication & IFD Configuration Errors Help RRS feed

  • Question

  • Hi there CRM experts & experienced implementers,

    We’re trying to configure our On-Premise CRM 2013 Sandbox Server with Claims Based Authentication & IFD – this is a CRM Test Environment only. I’ll try to detail as much info aic so you can review & see where you think we missed something / went wrong, so thanks for bearing with me.

    CRM Server: Our Sandbox is a VM Server (Windows Server 2012 Standard) with single server setup = CRM 2013 Server (Full Server Roles) + SQL DB Server.

    AD FS Server: AD FS 2.1 is installed on the same sandbox server (since this is a test environment); thus CRM 2013 was not installed on the default website, and uses port 5555. CRM works properly.

    SSL Certificate: We used a Self-Signed Wild Card Certificate (since it’s a test deployment) created via Makecert.exe as stated on page 18 of Guide 01.

    AD Certificate Services was also installed on the server since it’s required before a certificate can be created for CRM.

    Firewall configuration: Firewall is disabled on this server.

    We used and followed the following guides:

    1.        Guide 01: CRM 2013 updated “Configuring Claims-based Authentication for Microsoft Dynamics CRM Server” official guide from MS Download found here: http://www.microsoft.com/en-us/download/details.aspx?id=41701      
    2.        Guide 02: MSDN Blog by Niran - Step by Step: Configuring CRM 2013 Internet facing deployment (IFD) Link: http://blogs.msdn.com/b/niran_belliappa/archive/2014/01/16/step-by-step-configuring-crm-2013-internet-facing-deployment-ifd.aspx

    Of course, we started with Implementing claims-based authentication: Internal Access (required for IFD) and involves the following steps (Steps 1-4 are planning steps, and then 5-8 are the specific steps for implementing claims-based authentication: internal access as structured on Guide 01). Here are their summary and the corresponding questions/issues under them:

    1. Install & configure AD CS. à Done. No errors but see Question 1.

    • Question 1: AD CS Setup Type of CA

    Not sure if this has impact but when we installed & configured AD CS, on the Specify the Setup Type of the CA page, we were able to select and use “Standalone CA” only, and “Enterprise CA” was greyed out. Whereas in this guide, “Enterprise CA” was used. à http://blogs.msdn.com/b/crminthefield/archive/2013/12/09/creating-ssl-certificates-for-crm-test-environment.aspx,

    2. Create a self-signed wildcard certificate for a test deployment. à Done as stated above.

    3. Bind the SSL Certificate to the CRM Website (Note: CRM when installed is on port 5555) à Done. No errors but not sure if there’s a mistake.

    • Question 2: We didn’t have to do this beforehand because we noticed that after deploying and configuring AD FS 2.1 (Step 5 below), the https binding gets created automatically on CRM Website (on port 443 and using our SSL wildcard certificate). Is this correct?

    4. DNS Configuration. à Done. No errors but not sure if there’s a mistake.

    5. Deploy and configure AD FS. à Done. No errors but not sure if we made a mistake.

    • On the ‘Configure ADFS for WinServer 2012’ step, on the AD FS Federation Server Configuration Wizard, I entered the Federation Service Name “adfs.ourdomain.com” using the wildcard certificate we created on default port 443. The configuration finishes without any warnings or errors.
    • On ‘Verifying the AD FS installation’ step, I can browse & view properly the URL of the federation metadata: https://adfs.ourdomain.com/federationmetadata/2007-06/federationmetadata.xml. No certificate-related warnings appear.

    6. Configure the Microsoft Dynamics CRM server for claims-based authentication. à Done. No errors but not sure if we made a mistake.

    • Question 4: On the ‘Set MS CRM Server binding to HTTPS and configure the root domain web address’ step, I entered “internalcrm.ourdomain.com:443” on all. Is this correct? I put the port because Guide 01 states: “If you install AD FS and Microsoft Dynamics CRM Server on separate servers, do not specify port 443 for the Web Application Server, Organization Web Service, or Discovery Web Service”.
    • On the ‘CRMAppPool account on the MS CRM encryption certificate’ step, Read permission was granted accordingly to the service account that we use (not Network Service).
    • On the ‘Configuring claims-based authentication using the Configure Claims-Based Authentication Wizard’ step, on the Specify the security token service page, I entered the federation metadata URL (same as above): https://adfs.ourdomain.com/federationmetadata/2007-06/federationmetadata.xml, and then selected the correct certificate, and then System Checks are all good, and then before finishing the wizard, I viewed the Log file and copied the generated Federation Metadata URL during claims-based auth configuration: https://internalcrm.ourdomain.com/FederationMetadata/2007-06/FederationMetadata.xml, and configuration finishes without errors.

    7. Configure the AD FS server for claims-based authentication. à Done. No errors, but there’s a discrepancy in step ‘Configure a relying party trust’ – see Question 5 below.

    • ‘Configure the claims provider trust’ step is done without any errors.
    • Question 5: On the ‘Configure a relying party trust’ step, on step 5, I entered the federation metadata created during claims setup which is: https://internalcrm.ourdomain.com/FederationMetadata/2007-06/FederationMetadata.xml, and then proceeded with the wizard. Now here’s the discrepancyà On Step 10 (page 31), guide states that we’re supposed to see a single identifier only, such as https://internalcrm.domain.com on the Identifiers tab. But ours have multiple identifiers and looks like this:

    http://adfs.ourdomain.com/adfs/services/trust

    https://adfs.ourdomain.com/adfs/services/trust/205/issuedtokenmixedasymmetricbasic256

    https://adfs…etc....(see image below). Is this correct? What did we miss and what should we do to achieve a single identifier?

    Relying Party Indentifiers

    We just ignored this and finished the wizard (no errors or warnings), and then moved on to adding the rules. The 3 rules were added accordingly as instructed. I also added the ADFS URL and internal access URL to the local intranet security zone – https://adfs.ourdomain.com & https://internalcrm.ourdomain.com, in IE on the server.

    At this point, we tried to test & browse our internal access URL on the server: https://internalcrm.ourdomain.com (because on Guide 02, ‘Registering the ADFS server as SPN step’ was not instructed); but we get the following errors:

    Error 1: Error: An error has occurred. Try this action again. If the problem continues....etc.

    And then after rebooting the server, it changed to Error 2: We think this has something to do with the multiple relying party indentifiers.

    Error 2

    8. Test internal claims-based authentication. à Work in Progress – see Question 6 below:

    • Question 6: On the ‘Register the AD FS server as a service principal name (SPN)’ step, I executed the following syntax on cmd (tried both the CRM server name and ADFS server name):
      • setspn –s http/ourcrmservername.domain.com domain\crmapppoolaccount
      • setspn –s http/adfs.domain.com domain\crmapppoolaccount

    But we get the error message “Failed to assign SPN on account …. error 0x2098/8344 à Insufficient access rights to perform the operation.” Our helpdesk guy says that Active Directory must be upgraded to the 2012 schema since CRM 2013 is installed on Windows Server 2012 (they’re still working on it). First, is this the correct solution? Is there anything else we’re missing? And second, is our syntax correct? Guide 01 (p. 36) says use the following command: setspn -s http/sts1.contoso.com contoso\crmserver$ à what’s the correct value for crmserver$?

    Please help. Any input is greatly appreciated.

    Appreciate your taking the time to review and help. 

    Thanks.

    ProgCRM




    • Edited by Progressive CRM 2011 Monday, May 5, 2014 8:59 AM changed https to http in the setspn command
    Friday, April 25, 2014 8:30 AM

All replies

  • Insufficient access rights to perform the operation

    I believe the account used to set SPN's must have Domain Admin Privs.

    My 2 cents

    Wednesday, April 30, 2014 9:26 AM
  • Step 7: I have had this also. In a prior step configuring CRM IFD external connection you must use 4 x port 443 in the url. these URL's must route (ping) to the CRM server. Check the cnames in your step 4 again.
    Wednesday, April 30, 2014 9:34 AM
  • One minor point - I expect the reason you can only choose a standalone CA and not an Enterprise one is that you are not installing Certificate Services on a Domain Controller. So your clients may not trust the issued certificates without being explicitly allowed.

    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    UK CRM Guru Blog

    Monday, May 12, 2014 10:59 AM