This article discusses ho Forefront TMG 2010 can be configured to securely publish Outlook Web App.
In a web publishing scenario, the Forefront Threat Management Gateway (TMG) 2010 firewall serves as a reverse proxy for public requests for the internal published application. In order to support publishing Exchange 2013 OWA with Forefront TMG 2010, there are a few changes that must be made on the Exchange 2013 server. You’ll receive a warning indicating that you need to also change the authentication settings on the ECP virtual directory. Although there is no native Exchange 2013 OWA web publishing wizard in Forefront TMG 2010 at the time of this writing, we can leverage the existing Exchange 2010 OWA web publishing wizard as a starting point for publishing Exchange 2013 OWA.
Give the new web publishing rule a descriptive name and then select Exchange Server 2010 for the Exchange version and choose Outlook Web Access for the Web client mail services. Next, choose whether you want to publish a single web site or load balancer or a server farm of load balanced web servers. Provide the Internal site name and optionally select to Use a computer name or IP address to connect to the published server.
Select HTML Form Authentication from the drop-down list and Select how Forefront TMG will validate client credentials. Optionally select to Enable SSO for web sites published with this web listener and specify an SSO domain.
Before you save and apply the changes, double-click the newly created rule and select the Application Settings tab. Once complete, save and apply the changes, wait for the configuration to synchronize, and then begin testing. In its default configuration, Forefront TMG 2010 leaves a lot to be desired in terms of its default SSL security posture.
In the absence of native support for publishing Exchange 2013 Outlook Web App in Forefront TMG 2010, it is possible, with a few mall adjustments to the default setting used by Exchange 2010 OWA, to configure Forefront TMG to securely publish Exchange 2013 OWA. Richard Hicks (MCP, MCSE, MCTS, MCITP:EA, Enterprise Security MVP) is a network and information security expert specializing in Microsoft technologies.
Cloud Admin CON is a cost-effective, convenient opportunity for busy System Administrators and IT Managers to stay up to date on the most recent industry trends and vendor solutions and build their network of IT experts and vendors.
TechGenix Ltd is an online media company which sets the standard for providing free high quality technical content to IT professionals. In the first 5 parts of this series, I went through all the steps required to successfully install Forefront Protection 2010 for Exchange Server and Forefront Threat Management Gateway (TMG) 2010 on the same server as your Exchange Server Edge Transport role.
This post also assumes that your domain controllers already accept LDAP connections over SSL.
It is also important to change the authentication settings by clicking on the “Authentication” tab. If you are using a wildcard certificate, you can enter the root domain name here, I have elected not to use a wildcard certificate.
Review your certificate domains, I usually enter the server name without a suffix as well, but this is not necessarily required. Now that we have completed out certificate request, it is time to submit this request to a CA. We now need to assign services to the certificate, click “Server Configuration” and select your new certificate.
Now that we’ve installed the new certificate and assigned services to it, lets give it a quick test internally. Before we can import the certificate on the TMG server, you need to export the certificate along with its private key from the CAS server.
The second certificate is the new exchange certificate we just installed, it should be located in the “Personal” store. Lets start with the Enterprise Root CA certificate, right-click the certificate and click “Export”. First we import the Enterprise Root CA certificate, expand the “Trusted Root Certificate Authorities” store, right-click “Certificates” and select “Import”. Once this is done, should should be able to double-click the exchange certificate and check the status.
Click “Select Certificate” and then select the exchange certificate we installed in the previously. Next we look at authentication settings, since our server is not a part of the domain, we are unable to use “Windows” authentication. We need to add at least one LDAP server for user authentication, add your domain controllers here, type your domain name and I highly recommend that you make use of LDAP over SSL.
Enter your user name in the format “Domain\user name” and your password and click “Log On” If you have any certificate alerts, you may need to install your Root CA certificate to the “Trusted Root Certification Authorities” store on your workstation. To summarise, in this final part of the series I created a new certificate request and then submitted it to certificate authority. In this 6 part series, I went through the process of installing Exchange Server Edge, Forefront Protection 2010 for Exchange Server and TMG 2010 on the same server.
This error occurs when the name in the SSL client request from ISA Server does not match the common name on the Web site certificate. For the certificate on the ISA Server computer, the name must match the name that the external clients specify to reach the site. For the certificate on the published Web server, the name must match the name that appears on the To tab of the rule. In the case of the certificate on the Web server in a server publishing scenario, the certificate should have the name that users will use to connect to the server.
My OWA was working just fine but never managed to get my active sync working; always complaining about certificates. Your problem sounds strange as you mentioned that you are able to view OWA internally, correct? I understand that you may not want to share your urls publicly, in fact I’d advise against it so perhaps we should take the discussion off list and just do it via email for now.
I have separate my Domain Controller (DC-Win 2008) and my Global Catalog (GC-GC-Win2003) in two servers. My question is, How and where i can installing and using a CA and all this certificate stuff? For LDAP over SSL you need to have server certificates installed on your domain controllers. This article continues our journey through the TMG firewall Web Publishing Rules by taking a look at some of the SSL settings that are available to you. In previous installments of this series, we've gone into great depth and detail regarding web and server publishing rules in TMG 2010. Before we take a look at some of the SSL related settings, though, let’s talk about the ways you can deploy an SSL Web Publishing Rule in the TMG firewall.
There is actually another way you can perform SSL publishing but we don’t see it used very often. Note that in this configuration, you have an additional security option that you might want to consider. SSL client certificate timeout (seconds): This is the amount of time that the client certificate will be considered valid before requiring the user to authenticate again. The TMG firewall must be able to trust any certificate provided by clients when you use client certificate authentication. Only accept client certificates trusted by the Root Certification Authorities selected below. As you can see, when you enable SSL publishing and authentication, you have a number of options available to you. In this article, we talked about some of the design options that are available to you when it comes to secure web publishing with the TMG 2010 firewall.
DEBRA LITTLEJOHN SHINDER, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. If you had a chance to read parts 1 through 5 of this series, you have probably figured out by now that while web publishing might seem as easy as using a the Web Publishing Wizard and creating a Web Publishing Rule, when you go under the hood, things get a bit more complicated.
We’ll pick up this time where we left off, going over the configuration options for the Web Listener. Finally, there is a Connection timeout (seconds) option that enables you to specify the length of time that you want the TMG firewall to wait before timing out as an idle connection. When you click the Select Certificate button, you’ll see the Select Certificate dialog box.
In the lower half of the dialog box you can see the Certificate Installation Details section.
In this article, we continued our series on the TMG firewall’s Web Publishing feature by going over some more of the settings in the Web Listener properties dialog boxes.
In this scenario, Forefront TMG provides essential protection for the published resource, such as denial of service (DoS) protection, pre-authentication, multi-factor authentication, protection from application-layer attacks, and much more. By default, Exchange 2013 OWA is configured to use Forms-based Authentication (FBA), to which Forefront TMG cannot perform authentication delegation to.
In the Forefront TMG 2010 management console, right-click Firewall Policy in the navigation tree and choose New and Exchange Web Client Access Publishing Rule.

Even if you are publishing a single web server, it can still be useful to select the option to publish a farm of servers. Give the new web listener a descriptive name and choose the option to Require SSL secured connections with clients. The public name specified earlier should resolve to an IP address assigned to this network. Make certain that the public name for the published site matches the subject name (or one of the subject alternative names) on the SSL certificate. One thing you will of course notice is that the logon and logoff pages still resemble the Exchange OWA 2010 look and feel. To provide the highest level of protection for your Exchange 2013 OWA published web site, please refer to the article Improving SSL Security for Forefront Threat Management Gateway (TMG) 2010 Published Web Sites.
By publishing Exchange 2013 OWA with Forefront TMG, we can effectively leverage the added security features provided by the TMG firewall to provide the highest level of protection for our on-premises Exchange 2013 OWA infrastructure.
As a five-time Microsoft Most Valuable Professional (MVP), he has traveled around the world speaking to network engineers, security administrators, and IT professionals about Microsoft edge security and remote access solutions.
Individual focus sessions are scheduled to run consecutively, allowing you to attend all sessions, or selectively choose only those you wish to attend.
I also looked at some basic configuration so we should now be able to send and receive email. TMG 2010 can also securely publish all your Exchange Server related services such as Outlook Web App (OWA), Outlook Anywhere and ActiveSync (EAS).
While my focus is mainly on OWA, Outlook Anywhere and EAS should also work after very little or no additional configuration. When working with certificates, there are two options, I have opted to use my own Enterprise Root CA which has been installed on my domain controller.
To enable this, you need to install a server certificate on each of your domain controllers.
This can of course be done from the Exchange Management Shell by making use of the New-ExchangeCertifate cmdlet or by making use of the new wizard included in the Exchange Management Console.
The log onto the TMG server and open the “Certificates” MMC and make sure you are viewing the “Local Computer”. If you are using an Enterprise Root CA, it uses Group Policy to propagate its certificate to the “Trusted Root Certification Authorities” store for all users and computers in the domain. Once I had downloaded the issued certificate, I installed it on my exchange CAS server and assigned services to it.
This time, we continue our journey through the TMG firewall Web Publishing Rules by taking a look at some of the SSL settings that are available to you. In this type of SSL Web Publishing, the remote client establishes an SSL connection to the TMG firewall. This is sometimes referred to as “SSL offload” because the TMG firewall does the SSL heavy lifting on behalf of the published Web site. Since we’re talking about a high security situation, wouldn’t it be nice if you could require the upstream TMG firewall to authenticate to the downstream?
One opinion is that it’s great to use SSL to HTTP bridging because you can offload the processing overhead from the web server and put it on the TMG firewall.
It's a business decision, but you should have a discussion with your security and legal teams regarding this issue in order to come to a consensus on what your best course of action might be.
This option requires that all users who use the Web Listener associated with the Web Publishing Rule must authenticate. This option requires that all users who connect to the Web Publishing Rule using this Web Listener will need to present a client certificate.
This doesn’t define the duration of the session, rather it controls the duration for the period of time for which the client won’t have to reauthenticate in the event that the client should become disconnected. This option is not related to an SSL publishing scenario because it pertains to enabling authentication over an non-SSL connection. This allows you to set the interval of time in which the client needs to validate with the TMG firewall again.
This option will configure the TMG firewall to trust any certificate that chains to one of the certificates in the TMG firewall's Trusted Root Certification Authorities store. This option gives you more control over which CA(s) you want to trust when it comes to certificates delivered by client computers.
If you select this option, you can add restrictions that are to be placed on the client certificate. You have the choice of four fields on which you can set your restrictions: Issuer, Subject, Enhanced Key Usage and Extensions.
This is just one of the many reasons that we consider TMG firewall Web Publishing to be one of the most secure methods of web publishing available today.
We talked about the types of SSL bridging that can be used, and some of the advantages and disadvantages of each type. Not that it has to be difficult, but if your Web Publishing Rules are going to do everything that you want them to do, then you are going to need to know all the finer details of web publishing and how to access the controls that enable you to create rules that will accomplish your specific purposes. As you know, the Web Listener is a software construct that is used by the TMG firewall Web Publishing Rules to accept incoming requests for the rule. If you select this option, users will be redirected to an HTTPS connection if authentication is required. This option enables you to forward all connections that are accepted by the Web Listener to an SSL connection. However, when you click this, you find that the options you see there really aren’t very advanced :). Here you can configure the certificates that the Web Listener will use when securing an SSL connection with clients. In the top section of this dialog box, you’ll see a list of certificates that have been installed on the TMG firewall. This tells you the friendly name that you might have assigned to the certificate when you requested or created it.
If you want to filter the list to see only the valid certificates that are installed on the TMG firewall, you can enable the Show only valid certificates option.
When you click the Advanced button you will see the Advanced Certificate Options dialog box. Most of what we covered today was focused on SSL and the certificates that are bound to the TMG firewall’s Web Listener, which make secure client connections possible. One of the more commonly published web applications is Microsoft’s Outlook Web App (OWA). If left in this state you would receive two authentication prompts, which is not only confusing, it is needless.
Be advised that by default, Exchange will use a self-signed certificate for the OWA web site, which will not work with Forefront TMG. In cases where split DNS is not configured, enter the public hostname that will be used by clients to connect to the published web site. This is vital to the security of the published Exchange 2013 web site as we’re using basic authentication which is unencrypted.
I’ll start by creating a new certificate request and then submitting it to certificate authority and then install the issued certificate.
You are of course welcome to purchase a certificate from a third-party CA, if you decide that this is a better option for you, the basic configuration steps below will not differ all that much, the only difference will be in how you submit the request to the CA. The following Microsoft TechNet article may provide some guidance if you need further assistance with this.
If you keep Exchange forms based authentication enabled your users will be prompted to log into OWA twice. Notice the “Secured by Microsoft Forefront Threat Management Gateway” banner at the bottom.
Wouldn’t be nice in case of an incident to just open a browser, type the address (public address) of your VMware vShpere Web Client Server and manage the infrastructure from here ? The remote client establishes an SSL connection with the published web server and the TMG firewall decrypts the connection and performs application layer inspection.
The “upstream” firewall (the one that is closest to the Internet connection) accepts the SSL request from the remote client. However, there is an opposing argument that states that the user has an implicit agreement with the published web server when establishing the SSL connection and that this agreement is broken when you deploy SSL to HTTP bridging.
Of course, you can also choose to require additional authentication requirements, but if you select this option, the users must at least provide a client certificate. If the client certificate doesn’t meet the criteria you set, the client certificate will be rejected even if it is issued by a trusted CA. If you select Issuer, Subnet or Extensions option, you will see the Value field become available. Then we took a look at some of the advanced authentication options that are available to you, which relate to SSL and certificates.
The Web Listener controls the web protocols that will be accepted as well as the authentication requirements. The default port 80 is listed automatically, but you can change the port to another one if you like.

The default port 443 is listed, and once again, you can change it to another one if you like.
If you select this, the traffic that comes in as HTTP traffic will stay HTTP traffic and there will be no SSL redirection. This is a good option to enable whenever you have chosen to enable authentication on the TMG firewall, since you never want the credentials to be sent out in the clear. This is useful if you want to make the web site easy to access (users don’t have to remember to use SSL) and you’re not initially requiring authentication, but you want to keep the session secure – either because you are going to be asking for authentication later or perhaps because users will be entering some data that you’d rather not have transmitted in the clear over the Internet.
In the Advanced Settings dialog box, you can set the number of allowed concurrent client connections for the web listener. You can change this if you have client applications that might want to stay connected longer while idle.
In the example in the figure below, you can see that the certificate is not valid because it has expired. If you have a TMG firewall array, you will see the certificate installed on all the machines in the TMG firewall array. This is important because if the private key is not included with the certificate, then the certificate will not work. You don’t have a lot of choice here; there is the single option Certificate per server on all IP addresses. Forefront TMG 2010 supports the (wizard based) publishing of Exchange OWA going all the way back to Exchange 2000.
With Forefront TMG performing authentication of external users on behalf of the Exchange server, it will be necessary to change the default authentication settings in Exchange from FBA to basic authentication. Before proceeding you should make sure that you have a valid certificate configured in Exchange that is issued by a certificate authority that is trusted by the TMG firewall. I’ll then go over how to correctly export the issued certificate and import it on the TMG server. I highly recommend purchasing a UC Certificate for this, please see the following Microsoft TechNet article for more information. The first is the Enterprise Root CA certificate located in the “Trusted Root Certificate Authorities” store.
This is because the TMG firewall is able to perform application layer inspection on SSL connections.
Then the TMG firewall establishes a new SSL connection between itself and the published web server. Then the TMG firewall forwards the connection to the published web server over an unencrypted HTTP session.
When using this kind of back-to-back TMG firewall combination, you can configure the downstream TMG firewall to require the upstream firewall to present a certificate for authentication. You would select the CA that you trust for client certificates and then only the clients who have certificates that chain to the trusted CA will be able to successfully authenticate with the TMG firewall using a certificate. Make sure that the client application is aware of the non-default port though, because otherwise the client won’t be able to connect on the alternate port. Similarly to the HTTP connection, you need to make sure the client is aware of the non-default port if you’re going to change from the default. If authentication is not required, then the connection will remain an HTTP unencrypted session. This is the number of clients that can be connected to a web site at the same time using this Web Listener.
You might remember that this was a bit of a challenge back in the Exchange ActiveSync days, because the connection timeout was causing ActiveSync push updates not to work correctly. You are typically going to use this option when there is a single IP address assigned to the Web Listener. If the client request includes a name that is different from this one, the connection attempt will fail. It is very common for TMG firewall administrators to install certificates in the wrong location (for example, in a user account’s certificate store). To begin, open the Exchange admin center, highlight servers in the navigation tree, select virtual directories and then double-click owa (Default Web Site).
I’ll then conclude the series by creating a new “Exchange Web Client Access Publishing Rule”. In fact, the TMG firewall can perform SSL application layer inspection on both incoming and outgoing connections through the TMG firewall. The published web server responds to the TMG firewall’s request and sends the response to the TMG firewall. The published web server responds to the request by sending its response to the TMG firewall, where the TMG firewall performs application layer inspection on the response. The TMG firewall then forwards the request to the “downstream” TMG firewall (the firewall that is closest to the published web site) using an SSL connection. If you select the Enhanced Key Usage option, then you will see the options in the Object ID section become available. In the next article in this series, we will begin our journey through the Server Publishing Rules. Now, when you using the Exchange Server Publishing Wizard, there are no problems with timeouts anymore.
Click authentication in the navigation tree, choose the option to Use one or more standard authentication methods and select Basic authentication.
The certificate used here is a SAN certificate and is issued by an Internal Enterprise Root CA, and all my external clients have the root CA certificate installed in the certificates store. The TMG firewall again decrypts the connection, inspects it, and then encrypts it again and forwards the response to the client computer that made the initial request.
Then the TMG firewall forwards the response to the client that made the original request over an SSL connection. There you have the choice to Match any OID in the selected certificate field or Match this OID in the selected certificate field and then you would enter the OID.
However, if you want to reduce the number of connections that the Web Listener can accept, you can select the Maximum per server setting and then enter a value. If the Web Listener has multiple IP addresses assigned to it, this option will allow you to select the IP address and assign a certificate to it. Try doing a Bing search for “ISA Server Advanced Certificate Options” and you’ll come up empty. If you’re one of those organizations who has not yet moved to Exchange online and is still supporting an on-premises deployment of Exchange 2013, Forefront TMG 2010 can be configured to securely publish Outlook Web App. Finally, the downstream firewall forwards the connection to the published web server using SSL or HTTP. The reason it says “per server” is because, if you have an array of TMG firewalls, each server in the TMG firewall array will be able to accept this many connections. You would use this option if the Web Listener was being used in a Web Publishing Rule that was listening for connections on different Fully Qualified Domain Names (FQDN) and each IP address was assigned to a different FQDN. Try some other permutations of this same search and you’ll still find nothing on this option. The good news is that the TMG firewall will alert you if your SSL certificates are about to expire. Before we start I presume you already created an A or CNAME record on your public DNS server which points to the external IP address of your TMG server.First we need to take care of the VMware vSphere Web Client Server certificate, by replacing the default one with the one issued by our internal CA. This is a high security configuration that you can use when your front-end TMG firewall is in a DMZ and you don’t want it to be a domain member, but you do want to enable authentication (pre-authentication) on the connections. I guess they put this option there in case somebody calls Customer Support Services with a problem that CSS determines that this option will fix. Next time, we’ll continue with our step-by-step journey through Web Listener properties and look at some advanced SSL settings (and this time they really are advanced).
In that case, I guess the only people who know what this option does are the TMG firewall Product Group and CSS!
After the certificate is in place on the vSphere Web Client Server, we need to copy the rui.pfx certificate on the TMG server. Follow the wizard.When you get to the password screen type the certificate password which is testpassword. The public name needs to exist in the certificate (imported on the TMG server) SAN attribute or the Common Name.Now we need to create a new listener, so TMG will process the HTTPS traffic matching the FQDN we put in the certificate. I published the vsphere site on the back firewall (TMG 2010) as above, and forwarded port 9443 to the back firewall from the front firewall (TMG 2010) but can not access. Here are the list of ports that VMware uses.AdrianLeave a Reply Cancel replyYour email address will not be published.

Create mobile website for wordpress
How to find death day
Is there a what a girl wants 2

Comments to «Web publishing tmg 2010 licensing»

  1. SES_REJISORU writes:
    And far more laid back in social that stunning Thoughts.
  2. centlmen writes:
    Anything that can are psychological exploit her limbic technique.
  3. Henry writes:
    You and how to use them.
  4. Ramin62 writes:
    Ladies, have to locate a person who.

2015 Make video presentation adobe premiere pro | Powered by WordPress