Category Archives: Threat Management Gateway

Users Are Unable to Use Activesync After Migration from Exchange 2007 to Exchange 2010

ActiveSync, exchange 2007, Exchange 2010, Threat Management Gateway


At a recent customer, we ran into an issue where a set of users were migrated from Exchange 2007 to Exchange 2010.  All of the users activesync worked without issue, but one user was unable to connect.  No matter what we tried, he would get”unable to connect to server” on his phone.  We checked the activesync logs, would see an initial connection but then nothing else.

Checking the event logs of one of the CAS servers, we found error event ID 1053: “Exchange Activesync doesn’t have sufficient permissions to create the container under Active Directory User”Untitled

So I opened Active Directory Users and Computers, selected View-Advanced Features:


Then I opened the user account, went to to the security tab->;Advanced:


Here, the “Include inheritable permissions from this objects parent” was UNCHECKED:


I checked this box, hit apply, and boom active sync started working. Since this account was not a domain admin and just a standard user account, this was unexpected.

How to Publish Outlook Web Access with RSA SecureID on Exchange 2007 or Exchange 2010

exchange 2007, Exchange 2010, Security, Threat Management Gateway

With many companies putting an emphasis on security, especially given the recent events involving Google and China, one of the things many companies turn to is two form authentication. The most popular brand out there is RSA, a subdivision of EMC.

Those who work with RSA know the deal. You get an appliance that you install on your internal LAN, and give your users a key fob.  This key fob has a display that changes a number sequence every sixty seconds. Users then use this key code, along with their user name and password, to log onto company resources. It’s regularly seen with network resources such as Citrix XenApp and web resources. Another solution where you can leverage it is by securing Outlook Web Access from Exchange 2007 or Exchange 2010 with RSA two form authentication. This means that users would need to use an RSA token along with their user name and password to log onto OWA.

Besides the RSA appliance, you would need also a Microsoft Threat Management Gateway Server (formerly called ISA Server) installed and operational. In the remainder of this article, I’ll show you how to publish the OWA page utilizing RSA for two form authentication.

Our test network is as follows:

1. NYRSA1 (RSA Server) –

2. NYTMG1 (TMG Server) – Local LAN, Internet

3. NYCAS01 (Exchange 2007 Client Access Server) –

Remember, with TMG the server generally has 2 NICS, one is connected to the unprotected network, or internet, and one is connected to the protected LAN, or internal network.  With Threat Management Gateway, you can either have it external to the domain, joined to a workgroup, or joined to the internal domain.  In our example, we have the TMG server joined to the domain.

So, the first thing we need to do is make the RSA server and the RSA Agent (in this case the TMG server) aware of each other and allow the TMG server to authenticate users with RSA. Log into NYRSA1 and launch RSA Authentication Manager Host Mode:

From here select “Agent Host” and select Add Agent Host. Fill out the name of the TMG server. (Ensure the server name is resolvable from the host, you can tell if it automatically fills in the IP of the TMG server):

Ensure the Agent Type is set as NET OS Agent and check Open to All Locally Known Users.

Select OK to save the host. Next, we need to export a file that we will import on the TMG server to establish communications. Go to Agent Host, Generate Configuration File and select One Agent Host:

Select the TMG server, NYTMG1 and save the resulting sdconf.rec file to the RSA appliance desktop. Next, move that file to a location on the TMG server that you can access from that server. You may need to use a USB key or CD if your TMG server is set with the default settings, which doesn’t allow remote or network share access.

Next, log onto NYTMG1, and copy the sdconf.rec files to two locations:

1. C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig

2. C:WindowsSystem32

***If you do not copy the sdconf.rec file to C:Program Files location, you will receive an error later on that I will show you***

Next, we need to export a copy of the certificate that is installed on NYCAS01, so that we can install this same certificate on NYTMG1. This is because the TMG server does SSL bridging between the two servers, and needs this certificate in order to unwrap the SSL packets from the client.

On NYCAS01, open an Exchange Management Shell. First we need to figure out the thumbprint for our certificate. You can get this by running the command Get-ExchangeCertificate:

Next, you can export this certificate to a .pfx file with the command above. Note we are exporting the certificate whose thumbprint begins with 331BF.At the end of this command, a logon prompt will appear which will force you to enter logon credentials to password protect the certificate. The prompt forces you to enter a logon name with a domain, but rest assured, it’s the password that’s important.

Now, copy the file export.pfx to the TMG server so you can access it locally, we need to import this certificate. On NYTMG01, open a blank console by running the command mmc and pressing enter. Now, select Add/Remove Snap In and select the Certificates snap in:

Select Computer Account and Local Computer and finish:

Next, navigate to the Personal store and select Import:

Now, the Import Certificate Wizard starts:

Select Next, and browse to the .pfx file you copied over:

At the next screen, select Mark This Key as Exportable, enter the password you created earlier and select next and finish. Now this certificate is available for use in TMG.

Next, let’s start creating our rule to publish OWA. Open the Threat Management Gateway Console and Select Firewall Policy:

Click on Publish Exchange Web Client Access from the Tasks bar on the right, which will start a Wizard. Give the rule you are creating a name:

Click Next, and select the version of Exchange you are using, as you can see, it supports all versions from 2000 through 2010:

Click next, and it will ask you if you want to publish a single site, or multiple sites for load balancing. In this example, since we only have one CAS server, we’ll select Publish a single Web Site or Load Balancer:

Click Next. The next screen is how you want the TMG server to speak to the CAS server. Since security is paramount here, we want to select “Use SSL”.

Click next, and now it will ask for the Internal Site Name. This is the DNS name of the internal CAS server. Since the TMG server is also on the local LAN, this would be the INTERNAL DNS NAME of the server, or in our example, NYCAS01.internal.local

Click next, and this screen is asking what EXTERNAL DNS NAMES your users will be typing into their browsers to connect to this page from an external computer. If you set the public name wrong, users won’t be able to connect. In our example, users will type in to access the OWA page from outside the organization.

Next, we have to select a Web Listener. Since we haven’t created on, there are none from the drop down:

Select “New” and we’ll be presented with the New Web Listener Wizard

After creating a name, select next, and you’ll be presented with should the listener require SSL. Since, again, security is paramount, we select require.

Next, it will ask what networks will be connecting to the server through this listener; here select External since this will be a web page that users will access from outside the company network.

Next, you’ll need to select the SSL certificate to use to secure this connection. Select the certificate we imported earlier:

Next, we are selecting particulars of how the user will log in through this listener. Here, we want to select HTML Form Authentication, and we need to select Collect Additional Delegation Credentials in the Form, and select RSA SecurID. This will add an extra field in the OWA logon page, requesting the SecureID token from the user’s key fob.

At the next screen, uncheck the option for Single Sign On:

At the next screen, you’ll get prompted with the following screen:

Select Yes. The TMG server has built in RSA dll’s, so you don’t need to install the RSA Agent software on the TMG server. You do need to select yes though here, to create the necessary firewall rules to enable communication between the TMG server and the RSA server.

Now, you’ll be returned to the Exchange Publishing Rule Wizard, and the Web Listener should be populated with the new Web Listener you just created:

At the next screen, you are presented with how the TMG server is going to authenticate to NYCAS01. Here, we are going to select Basic Authentication. Since it’s wrapped in an SSL wrapper, Basic Authentication in this case is secure:

The next screen will allow you to select which users can authenticate through this connection:

We’ll leave All Authenticated Users and select next. This will finish the creation of the rule. Ensure you hit apply at the top of the Firewall Page to apply the changes made:

So that takes care of the configuration on the TMG server side, but we need to ensure of some configuration on the Client Access Server side of NYCAS01.

On NYCAS01, open the Exchange Management Console, and Browse to Server Configuration->Client Access Server->NYCAS01 and right click the OWA virtual directory and select properties:

Remember, before we selected Basic Authentication as the method the TMG server would use to authenticate to NYCAS01, so ensure this is selected as an authentication option. After you apply these settings, you’ll need to run IISRESET /NOFORCE from a command line to recycle the IIS process and apply the changes.

So, now we should be all set, let’s test it out! If we point our browser to the external IP of the TMG server we should be presented with the correct logon page:

There we go! Notice the three boxes, one for user name, password and pass code.

One more thing. Remember before, how I warned you that if you didn’t copy the sdconfig.rec file to C:Program FilesMicrosoft Forefront Threat Management Gatewaysdconfig you would receive an error? The error is actually received by the end user, as a web server busy message as below:

Just copy the file to correct location, no need to recycle services, and you should be all set!

Any questions just shoot me an email!