To implement a secure IFD on the DMZ all you need is a RO DC (Read-only Domain Controller) and a RO DNS (Read only DNS server) and SQL port open to the CRM SQL server. Normally you find in many companies the RO DNS server running with the RO DC.
Using internal DNS servers as the main DNS servers for DMZ servers, it's a common design mistake that puts the internal infrastructure in danger of DNS poisoning, we know we don't have any major exploits in the wild that could take advantage of this design problem, but this could happen at any moment if it does, can cause major issues to the internal network.
The below diagram illustrates how CRM would work with an internal DNS server, and what happens during CRM authentication.
If you monitor the communication process capturing packets between the CRM server and DNS, you will notice the same communication as the above diagram. CRM initiates a conversation with the DNS server, which in this case is internal. The CRM queries for the SITE-DMZ DC GC Global Catalogue where the CRM server is located, DNS replies with a SRV record indicating the GC responsible for that SITE is RODC01, so CRM now communicates entirely within the DMZ zone, while this information is cached, this example shows that internal DNS servers are not required for CRM to successfully authenticate.
The following is the minimum configuration required:
- CRM IFD server running as Application Server role, deployed on the DMZ. The server needs to be configured first on the internal network, because it needs to join the CRM farm and for this a writable DC is needed.
- You can keep the Platform Server role on the DMZ or internally if you keep it internally you will need to open a firewall rule. The Platform role is needed to generate the CRM tokens otherwise users won't be able to authenticate.
- SQL port 1433 open to the internal network.
With the server now placed on the DMZ and the SQL port open on the firewall, the next step is to configure IFD. Download the IFD configuration tool from the following microsoft page: http://support.microsoft.com/kb/948779 on here you will find the necessary information on how to configure IFD, you place the tool on the dynamics CRM program files folder tools\bin and run it from inside the folder, configure the fields and publish.
When you publish the configuration, your CRM environment will be IFD enabled. It now contains information how to distinguish your internal network from the external. It also now deploys 3 new registry keys to your Outlook CRM clients:
Key: ExtranetServerUrl
Key: ExtranetWebAppUrl
Key: ExtranetDiscoveryUrl
I'm not covering these registry keys on this blog post, if you would like me in future please let me know and will be happy to write a post about this. I mention these keys because they can significantly affect Outlook client users. If you have laptop users with the CRM online version, users may get the following pop-up window constantly prompting for authentication:
If you will not use external access for CRM Outlook client, you can safely delete those keys and the pop-up will not appear. If you prefer to keep the keys but stop the constant pop-up from appearing, you can configure the following registry key:
type: DWORD 32bits
key: ClientAuthAllowRetries
value: 1
I hope this post helped with the design of your IFD solution on the DMZ. The main areas to be aware is to keep the ports opened to the internal LAN to a minimum and to keep in mind if external access is needed for Outlook clients.
No comments:
Post a Comment