Microsoft Dynamics CRM Team Blog: Microsoft Dynamics CRM E-mail Router and Exchange 2007: Keeping it Secure

[Blog bot]

Источник: http://blogs.msdn.com/crm/archive/20...it-secure.aspx
==============

In the last several months, there have been increasingly greater numbers of questions from customers and partners regarding the configuration of the Dynamics CRM E-mail Router against Exchange 2007 in 'On Premise' deployments.  Specifically, how can one workaround those "invalid cert" pop-ups and the resultant error message during the Test Access phase of router configuration?  I mean, besides just un-enforcing the use of SSL…a solution more than a few have resorted to when pressed to find an easy answer.
By default, Exchange 2007 users certificates to secure client access and as such it's becoming increasingly important to familiarize oneself with the basics of PKI.  The problem is, even the basics tend to glaze the eyes of even seasoned admins despite their best efforts.  Additionally, it's often tough to find a one-size-fits-all checklist because when it comes to security, one size really can't fit all and take into account specific environments and implementation goals.  The end result is that there are lots of articles scattered about that all tell part of the story.   
Recently, I collaborated with our intrepid CRM Support Escalation team on such a case.  While I don't presume to think that my method can or will work for everyone in their production environments, it's the type of thing that I would recommend going over a couple of times in a lab or at home to de-mystify some of these concepts.  I think you'll find once you do this once or twice and are comfortable with the tools and methods, implementing cert-based security, while not always the most intuitive process, can be done.
Scenario: 

I have a lab environment the consists of 4 servers--a Domain Controller, an Exchange 2007 server, a CRM 4.0 full server install, and its back-end SQL 2005 server, all Windows 2003.  I'm trying to configure the E-mail Router on the DC but I keep getting the error: 
Incoming Status: Failure - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. The remote certificate is invalid according to the validation procedure. 
When I attempt to Test Access in Router Configuration Manager.  Additionally, I notice that when I try to use OWA, I get a pop error in IE regarding an invalid cert. 

This seems to be the general blueprint for the types of questions we’ve been receiving so I set out to repro the issue and document step-by-step its resolution.  I'll cite the resources that I used further below since, as mentioned, it's tough to describe a catch-all procedure--I think you'll find you can adapt these and other steps to your own lab.
Establish a standalone root CA 
In my test environment, I decided it would be overkill to get a 3rd party cert but in production this might be the way you want to go.  In any case, for my lab the first step was to create a new Standalone Root Certificate Authority (CA).  A standalone root will basically be the first and last word in my environment as to a machine or user identity.  It will, of course, not be valid in the real world.  For my purposes, though, it's perfect.  I decided to install the CA on my DC.
Open Control Panel > Add/Remove Programs > Windows Components > Certificate Services  and install Standalone Root CA.
You'll see some other options including Enterprise CA, etc.  One of the biggest differences is that requests of certificates must be *manually* approved/denied in a Standalone.  Something to think about if you intend to use this in a non-lab environment.
Create a new certificate request on the Exchange 2007 server 
The next step is the generate a request for certification by your CA from the Exchange server.  There are different ways you can go about this and you can even generate a request that can validate the cert Exchange 2007 installs by default.  For my purposes, though, I used the following command:
From Exchange Management Console:

New-ExchangeCertificate -GenerateRequest -FriendlyName "AdamCert" -Path c:\reqest.req -SubjectName "c=us, o=adam bly, cn=ablye2k7.ablydom.local" -DomainName *.ablydom.local 

FriendlyName -  This is just a simple, logical name for the cert
Path - File system location/filename for the REQ file this request will output
SubjectName - This is where a lot of people get hung up.  This is the NAME on the cert.  It should match whatever you want the name to resolve to (i.e. what you intend to enter on the router).  This field can be multi-valued…that is, you could add the NetBIOS name so that you can use the cert internally without using the FQDN.  This could also be used to enter the CNAME or alias (ex. My mail server is ablye2k7 but the CNAME is mail.ablydom.local). Also, c is the region, o is the owner/organization (I used my name but this could just as well be Contoso Ltd.  Something to be aware of if you go the 3rd party route)
DomainName - domain for which the cert is valid.  I used a wildcard, but this isn’t explicitly necessarily.
The Certificate request (.REQ) file should be created where you specified in the Path parameter.
Submit the request to your CA and approve it 
The next step is to process the request and issue the certificate.  To start, I copied the REQ file to my Certificate Authority (my DC :)) and opened the Certification Authority MMC snap-in.    
Right-click on the server name and select All Tasks > Submit a new request.  In the Open Request File dialog, specify the REQ file you copied over.   Next, right-click on the Pending Requests node, select All Tasks > Issue.  Finally, click on the Issued Certificates node and double-click the cert you JUST issued. 
Make sure the certificate information includes includes "Ensures the identity of a remote computer" and that the "Issued to" makes sense in your environment.  Mine would be ablye2k7.ablydom.local based on the request above.  The "Valid from"  should be the current date through at least a year in the future.  Now we need to export the cert in a format that Exchange can consume.
Open the certificate and click on Details tab, select Copy to File which will invoke the Certificate Export Wizard.  Click Next at the Welcome screen, and ensure the radio button corresponding to DER encoded binary X.509 (.CER) is selected, enter a filename and a location for the .CER file and click Finish. 
Almost done!  Copy the certificate back to your Exchange server. 
Import and Enable the new cert 
Back on the Exchange server, open the Exchange Management Console. 

Import-ExchangeCertificate - Path c:\adam.cer |Enable-ExchangeCertificate -Services SMTP, IIS 

If you are prompted, confirm the overwrite of existing cert (if applicable).  Just need to do a few more housekeeping chores and we're ready to go. 
Fix up OWA, etc., Virtual Directories 
In the Exchange Management Console, expand Server Configuration > Client Access > Outlook Web Access tab, right-click OWA (Default Web Site), Properties
Note the internal and external URL -- these should be the same (or whatever you specified in the SubjectName in the request; additionally, if you included the NetBIOS name of the server, you could set the Internal URL to be simply "http://ablye2k7/owa").  
Theoretically, you would perform these same steps for the OAB, POP3, IMAP4, EWS, and AutoDiscover.  

[PS] C:\Documents and Settings\Administrator.ABLYDOM>Set-WebServicesVirtualDirectory -Identity "EWS*" -InternalURL https://ablye2k7.ablydom.local
-ExternalURL https://ablye2k7.ablydom.local 
[PS] C:\Documents and Settings\Administrator.ABLYDOM>Set-ClientAccessServer -Identity "ablye2k7" -AutoDiscoverServiceInternalUri https://ablye2k7.ablydom.local/autodiscover/autodiscover.xml 

Configure the router 
Finally we're ready to configure the router.  Our cert is in place and valid per our environment's very own standalone root CA.  
My config profiles in the Router Configuration Manager look like the following:
IN - Location:  https://ablye2k7.ablydom.local
OUT - Location: https://ablye2k7.ablydom.local
Check "Use SSL"
It's very important that the URLs match what's on the cert!  This may seem like a "duh" type thing, but you'd be surprised how many people (me included) have kicked themselves when they realized they were trying to use the NetBIOS name for the Exchange server when the FQDN is what was on the cert.  :)
Test Access should succeed for BOTH methods and everything should be secure.  Perhaps a little drawn-out, but not entirely impossible, right?  Once you've run through this a few times, I think you'll agree it can be extrapolated to meet your environments needs once you understand the end-to-end process.  Additionally, the following resources helped me immensely when I was getting started.
More on Exchange 2007 and certificates - with real world scenario
http://msexchangeteam.com/archive/2007/07/02/445698.aspx 
Creating a Certificate or Certificate Request for TLS
http://technet.microsoft.com/en-us/library/aa998840(EXCHG.80,printer).aspx 
White Paper: Domain Security in Exchange 2007
http://technet.microsoft.com/en-us/library/bb266978.aspx 
A big thank-you to the folks responsible for those from me. 
Adam Bly


Источник: http://blogs.msdn.com/crm/archive/20...it-secure.aspx