Microsoft Dynamics CRM 2016 On-Premise Deployment on Azure VM – Part 2 – Internet-Facing Deployment Configuration

Objectives

This article in 2 parts, explains step by step how to set up a Microsoft Dynamics CRM 2016 development server on an Azure Virtual Machine and to open it to the Internet via the CRM Internet-Facing Deployment.

These steps are not intended to be followed for a Production server as they rely on a single Virtual Machine for all the infra-structure including:

  • Windows Server 2012 R2 Operating System
  • Active Directory Domain Services role,
  • Web Server (IIS) Role
  • Active Directory Federation Service (ADFS) V3.0 role,
  • SQL Server Enterprise 2014 SP1,
  • and of course Dynamics CRM 2016 with all roles on the same server.

This is clearly not a configuration recommended and supported by Microsoft but it’s very didactic as it touches to a good range of Microsoft server technologies and concepts.

This deployment adds a bit of complexity regarding some required work-arounds to make it run properly, but also remove some complexity in overall (less servers to deploy and configure, lower administration). Some straight lines and assumptions are taken, for example regarding the Windows accounts that again is not suitable for a Production environment.

Part1 covers the core infrastructure installation with MS Dynamics CRM 2016 configured for a simple AD Authentication, restricted to internal users. The schema below highlights the process:

You can complete Part 1 of this article and stop there with a fully functional Dynamics CRM 2016 server accessible only from the internal network.

Part 2 covers the Internet-Facing Deployment configuration of Dynamics CRM 2016 to have it support Claim-Based authentication for internal and external access thanks to the MS Active Directory Federation Service. The schema below highlights the process:

Requirements

For this deployment you need:

  • A SSL wildcard certificate provided by a well know Certificate Authority,
  • Admin access to a domain provided by an Internet Domain Name Registration Provider or by your company (access to the DNS),
  • Full Administration access on the infrastructure of your servers,
  • If you are building a development environment hosted on Azure, then the Part 1 of this article is assumed to be covered.

SSL Certificate Application

Our development instance of Dynamics CRM will be accessed via the URL https://crm2016.mydomain.com:444 (In this article mydomain.com is a fake domain to be replaced by your domain of choice).

We need to purchase a standard SSL wildcard certificate to be applied to our IIS Server. If you intend to stop this deployment to Dynamics CRM only, then you could eventually consider to use a free self-signed certificate for testing/dev purpose, but be aware that some integrations with other systems, following this article, may not work.

As a SSL Certificate Provider, we’ll use the services of https://www.namecheap.com that is one of the cheaper provider of the market with pretty good tracking records.

On your Windows Server, open IIS Manager:

  • Click the Server Name of the left panel
  • On the central panel, double click the ‘Server Certificates’ icon
  • On the right panel, click ‘Create Certificate Request’

Fill-up the ‘Distinguished Name Properties’ pop-up fields with alphanumeric symbols (no special ones such as ‘&’, ‘/’,’@’, etc. allowed):

  • Common Name – The name through which the certificate will be accessed (example *.mydomain.com for a wildcard certificate)
  • Organization – The legally registered name of your organization/company
  • Organizational unit – The name of your department within the organization
  • City/locality – The city in which your organization is located
  • State/province – The state in which your organization is located
  • Country/region – two-digit country code

The next screen ‘Cryptographic Service Provider Properties’ offers to choose 2 parameters. Check with your Certificate Provider in order to be sure what values to fill there. The most common values today are:

  • Provider = ‘Microsoft RSA SChannel Cryptographic Provider’
  • Bit length = 2048

Next select a place where to store the Certificate Request text file, any place and any file will work.

Now on the SSL Certificate Provider web site, activate your newly purchased certificate and paste the content from the previously generated file to the Certificate Signing Request (CSR) field. Select IIS as a web server if this choice is available.

Your SSL Certificate provider will require to go through a Domain Control Validation (DCV) process for security purpose.

We opted for the Email method to complete the DCV (Other possible alternative: HTTP-based validation or DNS-based validation). The validation can take a few hours to a couple of days.

Once the SSL Certificate delivered, download it and select the Action “Complete Certificate Request” in IIS Manager and upload your certificate.

Our SSL Certificate Provider delivered the certificate under different formats, we selected the one with the extension p7b (.cer, .p7s, .p7b should be equally accepted by IIS).

Web Sites Binding with SSL Certificate

Default Site

On your Windows Server, open IIS Manager:

  • Click the Server Name of the left panel
  • Expand the Sites and select the Default Web Site
  • On the right Action panel, click “Bindings”
  • Click the button “Add” in the Site Bindings” pop-up

  • Select Type = ‘https’
  • Leave IP address to ‘All Unassigned’
  • Set Port = 443
  • Select your wildcard SSL Certificate by its friendly name
  • Click OK

Dynamics CRM Site

in IIS Manager:

  • Click the Server Name of the left panel
  • Expand the Sites and select the Microsoft Dynamics CRM Web Site
  • On the right Action panel, click “Bindings”
  • Click the button “Add” in the Site Bindings” pop-up

  • Select Type = ‘https’
  • Leave IP address to ‘All Unassigned’
  • Set Port = 444 (must be different from the port used for the default web site)
  • Select your wildcard SSL Certificate by its friendly name
  • Click OK

DNS Configuration

Our DNS requirements are the following:

  • To set up Claims-based authentication for our Dynamics CRM server:
    • internalcrm.mydomain.com – URL accessed by internal network users à Internal access
    • sts.mydomain.com – URL pointing to the security token service (ADFS) à Internal and external access
  • To set up IFD:
    • crm2016.mydomain.com – URL accessed by external network users à External access

      Important: this name has to match the name of your Dynamics CRM Organization

    • dev.mydomain.com – Discovery service URL à External access
    • auth.mydomain.com – external IFD URL à External access

We need the services of an Internet Domain Name Registration Provider to create an external domain. Typically, providers such as Namecheap (http://www.namecheap.com) or GoDaddy (http://godaddy.com) can provide this for a reasonable cost.

For External accesses, we create the following A Records pointing to our public IP (See Part 1 of this article to find out how did we get this IP from Azure) From the user interface of the Domain Provider.

For internal accesses, we can set up A Records via our local DNS Manager…

… or add the following entries within the host.file. This file is located on your loca server: C:\Windows\System32\drivers\etc. This is acceptable for a development server.

(replace holes by your domain and 10.0.0.4 by your private IP adress)

Test all the DNS names, from your server and from the internet.

Notes:

  • You may not be able to ping those names because Azure may block those request
  • In case of local name resolution problems, you can try to clean up the DNS cache

Open your Server to the Internet

The following steps are specific to the Dynamics CRM server deployed on an Azure VM (Part 1 of this article). If your server is hosted by a different Cloud platform provider, then you’ll need to refer to their documentation. In any cases, the second step about configuring the Firewall stay valid.

Inbound Security Rules on Azure

Create Inbound Security Rules on your Network Security Group to allow inbound access from the outside world.

On the Azure Portal:

  • Select your Virtual Machine
  • Select your current Network Interface associated with your Static IP
  • Select the Network Security Group
  • Click on the “Inbound Security Rules”
  • Create the following rules depending on your need
    • Open Port 80 (only if access to default web site on HTTP is required)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 80 / Action: Allow
    • Open Port 443 (required for our Dynamics CRM IFD set up where port 443 is bound to the default web site for ADFS)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 443 / Action: Allow
    • Open Port 444 (required for our Dynamics CRM IFD set up where port 444 is bound to the Dynamics CRM web site)
      • Source:any / protocol:TCP / Source port range:* / Destination:any / Destination port range: 444 / Action: Allow

Firewall configuration

On the Windows Server, launch the “Windows Firewall with Advanced Security” Tool from the Server Manager and create the following Inbound Rules reflecting the rules you have defined via your Azure Network – Security Group:

  • Open port 443 on TCP
  • Open port 444 on TCP
  • Optionally if you want to leave access to your default web site in HTTP, open port 80 on TCP

The firewall could eventually cause problems for the remaining steps of this deployment if not configured properly, we recommend to temporarily turn it off until you can verify the IFD is working properly with Dynamics CRM and then turn it back on again later.

Declare your Domain’s Web sites in Internet Explorer

Include all your web sites in the local intranet zone in order to avoid some security blockages with Internet Explorer later.

Within IE, click on the “Tools” Icon and select “Internet Options”.

Pick the tab “Security”, select “Local Intranet” and click the “Sites” button, and then click the “Advanced” button on the pop-up.

Finally, add all the web sites of your domain, e.g. add the entry “*.mydomain.com”.

Claim-Based Authentication Configuration for Internal Access

Active Directory Federation Services Installation and Configuration

We need to install ADFS 3.0 that will act as the Security Token Service (STS) for our Claim-based authentication. It will be using our default IIS web site.

On your Server, open the Server Manager:

  • Click “Add Roles and Features”
  • In the wizard, select “Server Roles”
  • Check the role “Active Directory Federation Services”

  • In the wizard, select “ADFS” and read the content
  • In the wizard, select “Confirmation” and tick the box “Restart the destination server automatically if required”
  • Click “Install”

Once the installation is complete, click “Configure the federation service on this server”.

On the Configuration wizard, leave the choice “Create the first federation server farm” and click “Next”.

Next screen, select an account with AD domain admin permissions, your account should be fine in the context of this development installation.

On the “Specify Service Properties” screen:

  • Select the SSL certificate we created at the beginning of this article (do not click Import)
  • Set the Federation Service Name (e.g. sts.mydomain.com)
  • Choose a relevant FS Display Name as the users will see it at sign in (something like “MS Dynamics CRM”

If you click Next, you’ll see the following error:

Open Windows PowerShell and execute the following command:

  • Add-KdsRootKey -EffectiveTime(Get-Date).AddHours(-10)

Now you can click “Previous” and then click “Next” on the wizard if you see a Guid provided as an answer.

You can go for the creation of a Group Managed Service Account since you are on a development environment. It would be recommended to use a defined account in Production.

On the next screen we create a database on the server using Windows Internal Database, but you can choose to leverage the existing SQL Server on your Windows Server.

Click “Next” and review your selections and then go to the Pre-requisite Checks.

You can safely ignore the 1st warning, as long as All prerequisite checks passed successfully. Click “Configure”.

Finally, if everything goes well, you should obtain the success confirmation screen.

Let’s check the URL of the ADFS metadata in Internet Explorer to verify the ADFS is working properly; you’ll need this URL later.

It should look like the URL below:

https://sts.mydomain.com/federationmetadata/2007-06/federationmetadata.xml

  • Replace “sts” eventually by another DNS name of your choice dedicated to ADFS (done in step “DNS Configuration”)
  • Replace “mydomain.com” by your own domain
  • If Internet Explorer doesn’t display the XML file, make sure you have done the steps described in section “Declare your Domain’s Web sites in Internet Explorer”
  • Another important thing to check is that no error appears on the browser regarding your SSL certificate (click on the locker icon close to the URL for more info about it)

Configure MS Dynamics CRM Server for Claims-Based Authentication

Open the CRM Deployment Manager and follow these steps:

  • Select “Properties” in the Action menu
  • Go to the “Web Address” tab

  • Change Binding Type from HTTP to HTTPS
  • Replace all occurrence of the server name by the URL accessed by internal network users internalcrm.mydomain.com (see step “DNS Configuration”)
  • Change all occurrences of the port 5555 to 444

  • Click the “Apply” button and close the pop-up
  • Back to the Microsoft Dynamics CRM Deployment Manager, right click on the top of the tree “Microsoft Dynamics CRM” and select in the menu “Configure Claims-Based Authentication”

  • Click Next on the welcome page of the wizard
  • On the “Specify the security token service”, enter the Federation metadata URL we tested in the previous steps, setting up ADFS

  • Click “Next” and pick your SSL Certificate declared previously with a friendly name

  • Click “Next” and review the System Checks, you should have 2 successes à this stage

  • Click “Next” and then click “Apply”
  • On the last screen, click “View the log file”

  • Click “Finish” on the wizard
  • Test that the Internal Federation Metadata URL is working (You may have to do the next step prior to test successfully this URL)

Next we need to grant to the account NETWORK SERVICE the access to the encryption certificate because it’s the account that has been associated by default to the CRMAppPool in IIS. You can double check it on the Application Pools in IIS.

  • From the Windows Start button, right click and select “Run”
  • Type the command “mmc” to launch the Microsoft Management Console

  • Select “Add/Remove Snap-in” from the “File” menu

  • Select the “Certificates” snap-in and click “Add”

  • Select “Computer Account” and click “Next”
  • Make sure “Local computer” is selected and click “Finish” and “OK”

  • Select “Console Root” à “Certificates” à “Personal” à “Certificates”
  • Right click on your SSL Certificate we declared for the CRM and select “All Tasks” à “Manage Private Keys”

  • Click the “Add” button
  • Click the “Advanced” button
  • Type a search string like “network service” and click “Find Now” button
  • Pick the account “NETWORK SERVICE” and click “OK”

  • Ensure the NETWORK SERVICE has got Read access

  • Apply and close MMC.

Create and configure Claims Provider Trusts and Relying Party Trusts in ADFS

Start AD FS Management from the Server Management’s Tools and follow these steps:

  • Select “ADFS” à “Trust Relationships” à “Claims Provider Trusts” on the side panel
  • Right click on “Active Directory” and select “Edit Claim Rules…” on the menu

  • In the Claim Rules editor click the button “Add Rule”

  • Select “Send LDAP Attributes as Claims” for the Claim rule template and click “Next”

  • In the Claim Rule configuration screen, create the following rule:
    • Claim rule name: UPN Claim Rule
    • Attribute store: Active Directory
    • LDAP Attribute: User Principal Name
    • Outgoing Claim Type: UPN

  • Click “Finish” and “OK” to leave the Claim Rules editor

Now it is time to configure the CRM as a relying party to consume claims from ADFS.

Stay in the ADFS Management and follow these steps:

  • Select “ADFS” à “Trust Relationships” à “Relying Party Trusts” on the side panel
  • Click “Add Relying Party Trust” in the right Actions panel

  • Click “Next” and specify a display name in the following screen like “CRM Claims Relying Party”

  • Click “Next” and do not configure the “Configure Multi-factor Authentication”, so click “Next” again
  • On the step “Choose Issuance Authorization Rules”, leave the option “Permit all users to access this relying party” checked

  • Click “Next” and leave the step “Ready to Add Trust” as it is by clicking again “Next”

  • On the “Finish” step, make sure to check the tick box “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and push the “Close” button

  • On the Claim Rule Editor, click the button “Add Rule”
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”

  • Create the Rule n°1:
    • Claim rule name: Pass Through UPN
    • Incoming claim type: UPN
    • Check “Pass through all claim values”
  • Click “Finish”

  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”
  • Create the Rule n°2:
    • Claim rule name: Pass Through Primary SID
    • Incoming claim type: Primary SID
    • Check “Pass through all claim values”
  • Click “Finish”
  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Transform an Incoming Claim” and click “Next”
  • Create the Rule n°3:
    • Claim rule name: Transform Windows Account Name to Name
    • Incoming claim type: Windows account name
    • Outgoing claim type: Name
    • Check “Pass through all claim values”

  • Click “Finish”
  • Back to the Claim Rules editor, check you have your 3 rules and click “Apply” and “OK”

We need now to enable Forms authentication for internal access which is off by default.

Stay in the ADFS Management and follow these steps:

  • Select “ADFS” à “Authentication Policies” on the side panel
  • Click “Edit” on section “Primary Authentication” – “Global Settings” – “Authentication Methods”

Check the box “Forms Authentication” in the Intranet section.

Apply and close the ADFS Management console.

Open Internet Explorer and open the Internet Options.

Open the tab “Advanced” and make sure the option “Enable Integrated Windows Authentication” is checked.

This should be done for every PC accessing the internal access points so that ADFS and CRM can pass the Kerberos tickets without being prompted for credentials.

Finally, we need to register the ADFS Service Principal Names (SPN) on the user running the ADFS Service:

  • Open PowerShell or CMD
  • Enter the following command:
  • setspn -a HTTP/sts.mydomain.com mydomain\Administrator
  • setspn -a HOST/sts.mydomain.com mydomain\Administrator

(adjust those parameters with your domain and the user you choose to run the ADFS Service)


  • Reset IIS with the command
  • iisreset

Before to move to the IFD configuration, you can test the internal access to Dynamics CRM by typing the URL https://internalcrm.myserver.com:444.

If it doesn’t work at this stage, you need to troubleshoot it before to move on to the next stage. The SPN config. is critical, make sure it’s done correctly.


Internet-Facing Deployment Configuration for External Access

Configure MS Dynamics CRM Server for Internet-Facing Deployment

Open the Dynamics CRM Deployment Manager:

  • Right Click on “Microsoft Dynamics CRM” and pick “Configure Internet-Facing Deployment” in the contextual menu

  • Click “Next” on the 1st screen
  • On the next screen, enter the URLs with the port 444 for
    • the Web Application server domain (it’s a domain, not a server)
    • the Organization Web Service domain (identical to web application since we are installing all CRM roles on the same server)
    • The Discovery Web Service Domain (here we need a resolvable host name, we defined “dev.mydomain.com” for the Discovery Service in the DNS setup phase)

  • Click “Next”
  • Leave the default for the Internet Facing Server location (“auth.mydomain.com” has been also defined in the DNS setup phase)

The system checks should come with 2 successes.

  • Click the “Apply” button on the summary screen and you reach the Finish screen

Create and configure Relying Party Trusts in ADFS for the IFD Endpoint

Start AD FS Management from the Server Management’s Tools and follow these steps:

  • Right click on “ADFS”
  • Select “Add Relying Party Trust…” on the contextual menu

  • This open the “Add Relying Party Trust Wizard”, click “Start”
  • On the “Select Data Source” page, click the choice “Import data about the relying party published online or on a local network”
  • Type the Federation Metadata URL to locate the federationmetadata.xml file for IFD (should start with the prefix URL you specified in the IFD setup, https and port 444 and then the suffix is the same as for the Internal Federation Metadata URL: https://auth.mydomain.com:444/federationmetadata/2007-06/federationmetadata.xml

  • Click “Next” and on the “Specify Display Name” page, set the Display name as “CRM IFD Relying Party” for example

  • Pass the “Configure Multi-factor Authentication” with a “I do not want to configure …”
  • On the “Choose Issuance Authorization Rules” page, keep “Permit all users to access this relying party” and click “Next”
  • Confirm the page “Ready to Add Trust” by clicking “Next”

  • On the Finish page, leave the tick box “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” and close the wizard
  • If you missed the previous step, you can right click on the relying party that you created, and click “Edit Claim Rules”
  • On the Claim Rules editor popup, click “Add Rule” and select the rule template “Pass Through or Filter an Incoming Claim”

  • Create the Rule n°1:
    • Claim rule name: Pass Through UPN
    • Incoming claim type: UPN
    • Check “Pass through all claim values”
  • Click “Finish”

  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Pass Through or Filter an Incoming Claim” and click “Next”
  • Create the Rule n°2:
    • Claim rule name: Pass Through Primary SID
    • Incoming claim type: Primary SID
    • Check “Pass through all claim values”
  • Click “Finish”
  • On the Claim Rule Editor, click the button “Add Rule” again
  • Select the Claim rule template “Transform an Incoming Claim” and click “Next”
  • Create the Rule n°3:
    • Claim rule name: Transform Windows Account Name to Name
    • Incoming claim type: Windows account name
    • Outgoing claim type: Name
    • Check “Pass through all claim values”

  • Click “Finish”
  • Back to the Claim Rules editor, check you have your 3 rules and click “Apply” and “OK”

  • You should have 3 Relying Party Trusts in the ADFS Trust Relationships

Change the Port of ADFS with the command line and restart the ADFS Service (adfssrv):

  • Set-adfsProperties -nettcpport 809

Restart IIS with the command line:

  • iisreset

For information, you can browse the following URL and get the ADFS Web Service WSDL:

https://sts.mydomain.com/adfs/services/trust/mex (replace with your adfs name and your domain).

Internet-Facing Deployment Test

Access to Dynamics CRM 2016 from the internet (not from the server you did the install) and use the following URL:

https://{crmOrg}.{mydomain.com}:444

e.g.: https://crm2016.mydomain.com:444

that should lead your browser to this authentication screen:

Login with the following format: domain\username

Congratulation !!! you made it through the IFD for Dynamics CRM 2016.

In case of issue, there are ways to help you troubleshoot it. Your favourite search engine is your best friend. Check out also the links below that helped a lot to complete this installation.

Mobile App (Optional)

Once you got MS Dynamics CRM working with the IFD, you can access it from the Dynamics CRM mobile app.

You can download this app on multiple phones and tablets OS:

CRM for phones app



CRM for tablets app



Once the mobile app started, just enter your external CRM URL, e.g. https://crm2016.mydomain.com:444.

And that’s it, after a short time loading some modules, you should be able to use your CRM from your phone or tablet.

Useful Links

Here is a list of great links that really guided me very well through this installation:

Here are some official documentation links:

Finally, some useful links that helped me for troubleshooting some issues during the installation:

Advertisements

One thought on “Microsoft Dynamics CRM 2016 On-Premise Deployment on Azure VM – Part 2 – Internet-Facing Deployment Configuration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s