Archive | Threat Management Gateway RSS feed for this section

How to Create a Certificate Request in Windows Server 2008 R2 for Use with Threat Management Gateway 2010

For a recent project I needed to create a certificate request for use with a new listener on Threat Management Gateway 2010. I wanted some specific criteria on the cert, so I really needed to use the Certificates Snap-In in Windows to create the necessary .req file. I had a little difficulty to get this to work right at first, but it turns out there are just a couple of tricks to getting this to work right.

First, open the Certificates snap-in for the local computer and navigate down to the Personal – Certificates certificate store. Right-click on it and go to All Tasks – Advanced Operations – Create Custom Request.

Click Next on the first information screen that comes up, and then verify that Proceed Without Enrollment Policy is highlighted on the following screen. Now Click Next.

Now, by default, the Template combo box has “(No Template) CNG Key” selected, but this won’t work for Threat Management Gateway, as it does not support CNG keys. So you need to change this to “(NO Template) Legacy Key” and click Next (the default selection of PKCS #10 is fine).

On the next screen, you need to click the down arrow next to details, which will expose the Properties button.

Click Properties and fill out the form with the following.

General Tab
Friendly Name – The friendly name is however you want to refer to the certificate, I usually use the full URL so I know exactly why I got this particular certificate, but you can use whatever you want.

Subject Tab
At a minimum you should use the same fields I have listed in Subject Name.

Alternative names are optional, but if you have other URLs the certificate should be valid for you would list them here. You need to verify that the type of certificate you intend to purchase from your certificate authority supports alternative names.

Extensions Tab
There are five subsections under this tab; Key Usage, Extended Key Usage, Basic Constraints, Include Symmetric Algorithm and Custom Extension Definition.

Under Key Usage, you would normally select Digital Signature and Key Encipherment. Your application may vary, but this is a typically what you would use to publish a web site.

For Extended Key Usage, you’ll select Server Authentication and Client Authentication.

The final three you’ll leave as the defaults. Again, you may need them in some specific applications, but this is for publishing a web site or other web service.

Private Key
There are four subsections under this tab; Cryptographic Service Provider, Key Options, Key Type, and Key Permissions.

Under Cryptographic Service Provider, you can really select any one, but I typically use Microsoft RSA SChannel Cryptographic Provider (Encryption).

Under Key Options, you will probably want to change the key size to 2048, which is the new minimum for most SSLs…. Any larger and you may have to pay more for your SSL certificate.

Personally, I generally select the option “Make Private Key Exportable” as this allows me to freely back up and move the key to other servers in the array.

The options under Key Type and Key Permissions can be left as the default. Again, under specific circumstances or for specific applications, you may need to set those options, but this is just for a published web site, nothing more.

Hit Apply and then OK, and that should take you back to this screen:

Click next, select where you want the .req file stored, and you’re all done. After you have submitted the request to your Certificate Authority and recived your signed certificate back, you can import it using the Certificates snap-in for Windows. At that point it will be available for assignment to a Lister in Threat Management Gateway.

How to configure Exchange 2010 & Threat Management Gateway for iMExchange 2 or Other EWS-based Apps

We recently began a whole migration of users over to our Exchange 2010 environment after a successful months-long pilot program. One of our users reported that they could no longer successfully sync iMExchange 2 on their Apple iPhone and iPad after they were migrated from Exchange 2003 to Exchange 2010.

iMExchange 2 is a great program you can use to synchronize your tasks & notes with your iPhonei/iPad/iPod as well as manage your Out-of-Office settings. I only downloaded it for troubleshooting purposes, but it’s an app I’ll keep and use.

In order to troubleshoot it, I installed iMExchange 2 on my own iPhone and began to troubleshoot it.  It was a little puzzling because we didn’t have anything restricted any more than we did in Exchange 2003.  We still had ActiveSync and Outlook Web Access enabled, so one would think everything should work just as well under Exchange 2010.

However, iMExchange 2 doesn’t appear to use Outlook Web Access or ActiveSync under Exchange 2010 (and I would suspect the same is true with Exchange 2007). It actually uses Exchange Web Services, which would normally be set up as a component of Outlook Anywhere. Unfortunately, we don’t use Outlook Anywhere in this environment due to erroneous InfoSec concerns, so I needed to enable some of the functions while still restricting Outlook Anywhere.

So, in order to support it or any apps like it, you need to configure your environment with some of the same things that are used for Outlook Anywhere, but you don’t have to go all the way with it.

On Forefront Threat Management Gateway, you’ll need to use the Exchange Publishing Wizard to publish Outlook Anywhere (note: enable the option for Outlook 2007 extra folders when you come to it) just as you would have for ActiveSync & Outlook Web Access. You can use the same Listener you set up for the other services as well… no need for a unique IP or certificate.

In addition, you’ll likely need to enable Basic Authentication for the /EWS and /OAB folders in IIS Manager on each of the Client Access Servers.

At this point, iMExchange 2 should work great and all you have changed is that you are now publishing the /EWS and /OAB folders. They still require authentication, they are still protected via SSL, and Outlook Anywhere still will not work… leaving your end users’ and InfoSec needs satisfied.