Exposing Microsoft Dynamics CRM 2011 Externally

There are many ways to expose an internal server externally, and it would be impossible to cover all possible scenarios in one document, this will serve as a general guide for a couple of common scenarios.
For Microsoft Dynamics CRM 2011 to be available on the internet, the Application server needs to be accessible from the internet, no matter if you choose to just open up the port or choose to do a full IFD implementation.

Port Forwarding Tunnelling Reverse Proxy

Port forwarding / tunnelling / reverse proxy are all possible ways of making an Internal IP address available to be accessed from an External (internet facing) IP address.

This will all depend what your company current have in place, most of the above can either be achieved through hardware or software.

Examples of software that can be used for port forwarding includes Microsoft Forefront Treat Management Gateway (TMG) and Microsoft Forefront Unified Access Gateway.

Basically what it comes down to is the following:

The user enters an internet address e.g. http://crm.mycompany.com.au
The internet address is recognised and points to the external registered IP address e.g. 162.123.123.11
The external IP address is redirected to your internal IP address through your reverse proxy / tunnelling / port forwarding e.g. 10.0.0.10
The user enters username and password and gets authenticated.
The Microsoft Dynamics CRM 2011 pages is displayed to the user.

Note: Security is not discussed in this document.

Requirements

Listed below is the minimum requirements for exposing Microsoft Dynamics CRM 2011 to the internet, assuming you have Microsoft Dynamics CRM 2011 already installed.

An External Facing IP address registered to an External DNS entry through your ISP
e.g. http://crm.mycompany.com.au or https://crm.mycompany.com.au
If you are going to use SSL you need a Certificate from one of the SSL Certificate providers, like VeriSign
A reverse proxy or similar technology to redirect/forward/tunnel the External IP address to the Internal IP address
An internal DNS entry (CNAME) with the same URL e.g. http://crm.mycompany.com.au
Ports needs to be allowed through the firewall. You can use any port, but if you want to use SSL you need to use either port 443 or 444.

Diagram

Example of one possible scenario. (Unsecured)

Advantages

The advantages of port forwarding are listed below:

Quicker and easier to set up
No additional server required
Users can access MS Dynamics CRM 2011 from the internet
No SSL certificate required if you don’t use SSL

Disadvantages

The disadvantages of port forwarding are listed below:

Less secure if you don’t use SSL
Users cannot use Microsoft Dynamics CRM 2011 client for Outlook to connect to MS Dynamics CRM 2011 externally

Internet Facing Deployment

Full IFD deployment will not be discussed in this document, but the general requirements will be addressed. For IFD access MS Dynamics CRM 2011 makes use of claims-based authentication, the following explains the difference between internal and external access using claims based authentication.

Claims-based authentication: Internal access

If you have a multiple domain environment where trust does not exist between the domains, or where some users exist in a different attribute store such as a partner organization, you can use claims-based authentication to handle internal user authentication.

Claims authentication flows as follows:

The client sends a request to access the Microsoft Dynamics CRM website.
IIS refuses the connection with an HTTP 302 error message and redirects the user to the trusted claims provider (also known as the STS) for Microsoft Dynamics CRM (AD FS 2.0).
The client sends a request for a security token to AD FS 2.0.
AD FS 2.0 returns an HTTP 401.1 error, indicating that the client must supply a Kerberos ticket.
The client sends a Kerberos authentication request to Active Directory.
Active Directory validates the client and sends a Kerberos ticket.
The client sends a request for a security token to AD FS 2.0 and includes the Kerberos ticket.
Note: If the client already has a valid Kerberos ticket on the network, this ticket is sent to AD FS 2.0 in step 3 and steps 4 through 7 are skipped.
AD FS 2.0 provides a security token containing claims for access to Microsoft Dynamics CRM data.
The client sends the security token containing claims obtained from AD FS 2.0 to the Microsoft Dynamics CRM server.
The Microsoft Dynamics CRM server decrypts and validates the security token and presents the user with the requested information.

Claims-based authentication: External access

Accessing Microsoft Dynamics CRM data over the Internet through an Internet-facing deployment (IFD) is done with claims-based authentication.

The flow for claims with IFD access is largely unchanged from the flow described above for internal access. The major difference is that user authentication does not include a Kerberos ticket. When accessing AD FS, users are prompted for credentials on an AD FS 2.0 logon page. If more than one attribute store is trusted by AD FS 2.0, users are prompted to select an attribute store. Users then enter their credentials and the AD FS 2.0 server validates these logon credentials with the selected attribute store, such as AD DS.