Category Archives: Forefront TMG 2010
In my first blog post around TMG 2010, I outlined the setup of TMG and configuration for publishing OCS 2007 R2 web components and then CWA services through that same server. Please reference that post for the basics around the network configuration for this TMG server, and I will cover configuring publishing rules for your Lync Server Simple URLs and web components in this post.
First, I assume you have configured simple urls and web services when deploying your topology, and now need to publish this externally.
My URL information is as follows:
|Component||URL||IP Internal||IP External||Port on Front End||Port on External/ISA|
|Web Services||lyncweb.winxnet.com||10.117.117.9||126.96.36.199||8080 and 4443||80 and 443|
|Dialin Simple URL||dialin.winxnet.com||10.117.117.9||188.8.131.52||8080 and 4443||443|
|Meet Simple URL||meet.winxnet.com||10.117.117.9||184.108.40.206||8080 and 4443||443|
First off, let me point out by saying that you can use a single external IP address for all three of these URLs, as they go to the same place. Also, if you open IIS manager on your front end server, you will notice there is an internal, and an external site, the internal listens on 80 and 443, and the external on 8080 and 4443. When proxying requests through TMG, you will be sending external clients to the external site, listening on 8080 and 4443.
Also, one not so commonly known fact is that the Meet simple URL is required to provide external access to meetings. You will notice when clicking on the link to Join Online Meeting in your outlook, it is directing you to your meet simple URL.
As far as certificates go, you must also have a certificate with the following names:
Common Name: lynecwebservicesexternalurl.domain.com (lyncweb.winxnet.com
Subject Alt Name(s): meetsimpleurl.domain.com,dialinsimpleurl.domain.com(meet.winxnet.com,dialin.winxnet.com)
Import this certificate to the TMG server, and you can proceed with the following steps for configuration.
Another important thing regarding DNS:
If you have a separate internal domain name, you will need split brain DNS to get this working. You should already have split brain DNS configured to get your internal clients to work with auto signin.
For example, if your internal domain name is winxnet.local and your external is winxnet.com, your simple urls should be for the winxnet.com namespace, however you will need to resolve the winxnet.com simple URLs to the correct internal address.
At winxnet, we actually have a single namespace, winxnet.com so it was an oversight to point out the fact that you would need these DNS entries resolvable
internally and externally for this to work.
Thanks to Adam in the comments for pointing this out and working through the issue with me. Check out this link for a great review on how this DNS
configuration works for the rest of the services:
Steps to Create Publishing Rule
While in the TMG or ISA management console, Right click on Firewall Policy and choose New->Web Site Publishing Rule
Enter a name for the rule like Lync Web
Follow the wizard with the following options:
Select Rule Action : Allow
Publishing Type: Publish a single web site or load balancer
Server Connectivity Security: Use SSL to connect to the published Web server or server farm
Internal publishing details:
Internal Site Name: FQDN of front end server (winx-lyncrc1.winxnet.com)
If your internal server is a Standard Edition server, this FQDN is the Standard Edition server FQDN. If your internal server is an Enterprise pool, this FQDN is a hardware load balancer VIP that load balances the internal Web farm servers. The TMG Server must be able to resolve the FQDN to the IP address of the internal Web server. If the TMG Server is not able to resolve the FQDN to the proper IP address, you can select Use a computer name or IP address to connect to the published server, and then in the Computer name or IP address box, type the IP address of the internal Web server. If you do this, you must ensure that port 53 is open on the TMG Server and that it can reach an internal DNS server or a DNS server that resides in the perimeter network.
Path (optional): /*
Public Name Details:
Public Name: FQDN of external web services (lyncweb.winxnet.com)
Select Web Listener: Select New(This will open the new web listener wizard)
Web Listener Name: Anything you want, something like Lync Web Listener)
Client Connection Security: Require SSL secured connections with clients
Web Listener IP Address: Select External and then Select IP Address choose the appropriate IP address and add it to the listener
Listener SSL Certificates: Select Assign Certificate for Each IP Address, select the IP associated before, and choose your valid certificate.
Authentication Setting: No Authentication
Single Sign On Setting: Ignore, click Next
Complete the web listener wizard and choose Finish
Authentication Delegation: No Delegation, but client may authenticate directly
User Set: Ignore, click Next
Complete the rule configuration wizard and choose Finish. Then at the top hit Apply to save the configuration.
Once the rule is created, there are a couple important settings that need to be changed, this is really the only thing that makes the Lync setup different from OCS R2.
Open the newly created rule and modify the following settings.
On the To tab, ensure that the Forward the original host header instead of the actual one check box is checked.
On the Listener Tab, click to modify the properties of the web listener
Navigate to the Connections tab and enable port 80
On the Bridging tab, select to Redirect requests to SSL port and Redirect requests to HTTP port, enter 8080 and 4443 for your ports.
On the Public Name tab, add the Simple URLS to the list of allowed public names. In my example: meet.winxnet.com and dialin.winxnet.com.
Once these changes have been made, Apply the configuration and you are done. To verify access, you can test the following URLs in Internet Explorer.
For address book server: https://externalwebservicesfqdn/abs (https://lyncweb.winxnet.com/abs) You should receive an HTTP challenge, because directory security on the ABS folder is configured for Windows Authentication by default.
For Web conferencing: Generate an online meeting request in Outlook, or a meet now request in Lync 2010, try joining the URL provided from external, it should be similar to this: https://meet.winxnet.com/rwintle/KG2K4HDM
You should now have functioning simple URLs and web services which provide the following functionality:
- Enabling external users to download meeting content for your meetings.
- Enabling external users to expand distribution groups.
- Enabling remote users to download files from the Address Book Service.
- Accessing the Reach client
- Accessing the dial-in Web page
- Accessing the Location Information Service
- Enabling external devices to connect to Device Update Service and obtain updates.
In my previous post I outlined configuring Forefront TMG 2010 to publish the OCS 2007 R2 web components. Please see that post for basic installation instructions and network configurations.
In this post, I will outline publishing Communicator Web Access (CWA) to the internet using Forefront TMG 2010.
DNS Records and Certificate Requirements
First lets cover the new DNS records and certificate entries required for communicator web access. With the addition of desktop sharing to CWA, additional DNS records and certificate entries are required to provide that functionality.
The following DNS records are required for CWA:
CWA Desktop Sharing
CNAME to cwa.domain.com
CWA Desktop Sharing
CNAME to cwa.domain.com
Your certificate will need to have all of the names above on it.
In my environment I have the following certificate information:
Common Name: cwa.winxnet.com
Subject Alt Name(s): as.cwa.winxnet.com download.cwa.winxnet.com
CWA Web Site Configuration
In my example I have two web sites configured on the CWA server. One for internal access and one for external access. When you create virtual servers for CWA you have two options for site types, Internal and External. The only difference is authentication type. Internal sites will let you choose NTLM authentication, which allows for simple access from inside the corporate network on domain joined machines. External sites will use Forms-Based Authentication, or Custom Authentication. Custom authentication can be used to perform two factor authentication with services like RSA or other smart card/pin authentication methods.
In our example our Internal site will be a standard internal site listening on port 443. Our external site however will run on port 4443, and we will perform bridging with the forefront TMG server to give users access to this site.
I will outline creating the external web server, assuming an internal web server has been configured listening on port 443.
First, open the Communicator Web Access management console, this is separate from the OCS 2007 R2 primary admin console, but is included when you install the admin tools on any machine.
Right click on the server name and choose Create Virtual Web Server.
At the next window, this is where you will choose your web server type, choose External.
The next window allows you to choose your authentication types. If you were using a third party authentication method you would specify it here. Although it says in the description that the built in windows integrated and forms-based authentication will be used, the external web site will only allow Forms-Based Authentication.
The next window confirms those authentication settings, notice NTML is grayed out.
The next screen has you specify an SSL certificate to be used with the https requests. You can choose HTTP if you are using an SSL Accelerator device, but you cannot use CWA over HTTP without such a device.
Choose the certificate you created with all the necessary name entries and hit Next
The next screen has you specify the IP address and port the web site will listen on. If you have an additional IP address you can use port 443 with a separate IP than your internal server. In our example, I will be using a single IP address and utilizing bridging with Forefront TMG, so I will enter the port as 4443.
On the next screen, enter a name to identify the external web site such as CWA External.
The next screen has you specify a port to listen to OCS traffic. This is seperate from the web site listening settings. This port is really important if you are collocating OCS Services, or even in this case where we have multiple CWA virtual servers on the same server. This port really does not matter, as long as it does not conflict with another port on the same server used for OCS Traffic. In my case I am entering 5071, my internal server listens on 5070.
At the next screen you must specify a Next Hop Pool, this drop down will display all the pools in your environment and allow you to choose a pool and listening port. In my case our poolname is ocs.winxnet.com.
Hit Next twice to confirm your settings for the new virtual server, the wizard will create the virtual directory and start the web site for you. As with all of the OCS installations, a log is available at the end for success and failure.
Now review your two sites, a screenshot of how the site summary should display is below.
Now that the OCS configuration is complete, we will configure Forefront TMG Web Site Publishing rules to allow traffic to your CWA services.
Forefront TMG 2010 Configuration
My last post reviewed networking configurations for this Forefront server. You can get away with a single External/DMZ IP address for all of these services if you have a single certificate with all of the names. In my case I have multiple certificates, so another IP address will need to be assigned to the DMZ network card on my Forefront TMG 2010 server.
Once you have added your external IP address, and imported the certificate used on your web server; (See my last post for instructions on both of these steps). We will now create the web site publishing rule for CWA.
Right click on Firewall Policy and choose New->Web Site Publishing Rule.
For a rule action, choose Allow. Hit Next
For the Publishing Type choose Publish a single web site or load balancer. Hit Next.
For Server Connection Security choose Use SSL to connect to the published Web server or server farm. Hit next.
For your internal site name, you will want to specify the same Internal/External site name, whatever is the common name on your certificate, in my case it is cwa.winxnet.com.
If you cannot resolve the name correctly from the TMG server, or want to specify a different computer to connect to for that name, you can do so by specifying a computer name or IP Address.
Once you have made the necessary entries, hit Next.
For internal publishing details, under path type /* to allow all sub directories required by CWA. Hit Next.
Under Public Name Details enter the public name for your site, and hit Next. In my case it is cwa.winxnet.com.
On the next page to specify a web listener, choose New.
In the new web listener wizard first page, enter a name for the listener like CWA.
For Client Connection Security choose Require SSL secured connections with clients.
On the Web Listener IP Address page, select the check box next to External, highlight external and choose Select IP Addresses… On this next page, specify the IP address you set aside for CWA.
Hit Next, on the next page for Listener SSL Certificates, highlight the IP Address selected on the last page and choose Select Certificate… Choose your valid certificate and choose Select. Hit Next.
For Authentication settings, choose No Authentication.
Because we chose No Authentication, we have no SSO options, just choose Next.
Review the settings for your listener and hit Finish.
With your listener selected from the drop down menu, hit Next.
For Authentication Delegation choose No Delegation, but client may authenticate directly. Hit Next.
Leave the default settings for User Sets and hit Next.
On the next page, select Test Rule to verify all rule settings are correct. If the result is OK, hit close, then select Finish.
Make sure to Apply your settings to the Forefront TMG server before continuing.
If you had a separate IP address for you internal site, and your external site you do not need to do the next step. This next step will configure bridging to direct our user request to port 4443 for this external virtual server.
Right click on your CWA rule and choose Properties.
On the Properties page, select the Bridging tab.
Where it says Redirect requests to SSL port, enter port 4443, or whatever port you specified during your website configuration. Hit OK.
Again, apply your changes before continuing.
You can test the rule again from the Properties page. Simply open the Properties page for the rule and Test Rule will be an option there. If the test returns OK, continue to test your site from a computer outside the network.
Testing and Known Issues
You can test access to this site from Internet Explorer outside the network, you should simply be able to specify the https:// URL of your site, and TMG 2010 will handle bridging the request to the correct virtual server on the CWA server. You can also use CWA for access to a great IPhone OCS App called iDialog by Modality Systems.
A very common known issue for CWA configurations is receiving the error Cannot sign in because your computer clock is not set correctly or your account is invalid. (Error Code: 0-1-492)
This is an easy fix, and has to do with Service Principal Name (SPN) settings for the CWA Site.
To fix this issue, simply add the correct SPN to your CWA Service Account. This is the account specified during CWA installation to run the service.
You can modify this setting using ADSI Edit, and looking for the attribute servicePrincipalName.
Other than those two instances, this configuration is pretty straight forward and just works.
The reverse proxy installation can be confusing if you have never done it before. In this scenario I will be standing up a new server to replace my ISA 2006 SP1 Server. I will create all of the rules from scratch and walk through the installation.
The most important part of this reverse proxy setup is the networking configuration. It is recommended to have at least two network interfaces on the TMG server, in my case we have a network card in the DMZ with public IP addresses and one on the internal network. Depending on your actual network configuration this could be different.
An important thing to note is that in windows you can have multiple network interfaces on different networks, but not multiple default gateways. Because of this, we need to choose an adapter with the default gateway, and one without any gateway, using manual routes to get to internal resources. In most scenarios it would be ideal to assign the default gateway to your internet facing NIC, this is because it is impossible to enter manual routes for all possible internet traffic. The internal or DMZ NIC typically has no gateway, but we will assign persistent routes for the internal networks.
In my case, the NIC is directly on the internal network, so servers can communicate directly on the same subnet with no routing needed. However, I will show you how to configure these routes for another internal network to simulate the need to route. In an edge server configuration you will need routes for the desktops as well as servers, so it is important to know how to do it.
In my situation, the address spaces involved will be as follows:
Server LAN: 10.117.117.0
Desktop LAN: 10.1.2.0
DMZ: Public IP addresses
Because my TMG server has a NIC directly on the 10.117.117.0 network I do not need a route for that network, but in order to talk to the 10.1.2.0 network, I will need persistent routes. To see the route setup on your server:
Open a command prompt as administrator
Type Route Print and hit enter
Your output should resemble something like the picture above. Note the 10.117.117.0 network has routes directly on that link, and the default gateway is set to our public interface.
To add a route to the 10.1.2.0 network type the following at the command prompt and hit enter:
route add –p 10.1.2.0 MASK 255.255.255.0 10.117.117.2
Where 10.117.117.2 is the router on your network.
If you see OK! after you hit enter, the command took succesfully.
This means any requests for that network are in the route table, and are to go to 10.117.117.2, which will happen via the 10.117.117.106 interface, or our Internal interface.
This is a fairly basic network configuration, in most environments it will be more complex and involve more subnets. However hopefully this gives you a good idea of how to setup the network in your environments.
Before I get started, the diagram below will show the basic environment as it relates to the reverse proxy and my OCS Pool.
Update the server with the latest patch levels, and then launch the TMG Install. You will get a screen prompting you to Perform Updates, Run the Preparation Tool, or Run Installation Wizard.
Select Run Preparation Wizard. This Wizard will add the server role required for TMG to operate on the server. As you click through the installer you will have to choose a type of installation, choose Forefront TMG services and management for a complete install.
Let the wizard run, it will install all roles and services needed. When completed you will be presented with a screen that shows Success or Failure, Click Finish and Launch the TMG Installation Wizard.
The installation wizard will have a few defaults to accept, and then you will be asked to choose your internal network ranges. Choose Add, then choose Add Adapter. Select the Internal network interface on the server. If you previously entered persistent routes you will notice those subnets show up as being associated with that adapter as well.
Hit OK twice and your window should look something like this:
The address ranges should reflect your DMZ adapter address and any internal networks you will be routing to.
Hit Next twice to acknowledge the services that will be restarted during the install. The next page will notify you that forefront will create rules to allow domain traffic to domain controllers listed
If this information looks correct, hit Next, then Install and let the installation complete.
The installation will take some time to complete, but once it is done you should see this screen, click Finish to launch the configuration wizard.
The initial configuration wizard will then launch. Note: You can import ISA 2006 XML configuration files to this if you do not wish to recreate your rules. I am going to start from scratch however to show the whole configuration process.
Run the wizard to configure network settings. This setup is an Edge Firewall configuration. Choose Edge and click next.
Choose your internal network adapter to be associated with the LAN. You may also enter routes here, I am not sure if this makes the previous routes entered not needed, but I will do more testing and update the blog if that changes.
The next step is to define Deployment Options which chooses your license information, and update settings. I will not cover that in this post.
Once you launch the TMG Console, you will notice a somewhat familiar interface with a whole lot of new features.
OCS Website Publishing Rules
Before starting with any OCS rules you should import the public certificates for your OCS Web Farm.
You should have a standard SSL certificate with a common name that matches the External Web Farm FQDN you specified during setup, or that name should reside on a UCC certificate. Either way, you must import that certificate into the Local Computer store with a valid Private Key before it can be used with ISA.
To do so, open the certificates MMC.
Right click on the Personal certificates store and choose All Tasks –> Import
Hit Next, then Finish. Your certificate should now be ready for use with ISA.
For OCS, we are simply concerned with Firewall Policies, there are a lot more features to TMG 2010, which I hope to cover at a later date.
Select Firewall Policies, and choose Publish Web Sites from the tasks pane on the right
Hit Next, for the path enter /* to allow all traffic to the pool for the various services.
Choose the radio for Specified IP Addresses on the forefront TMG Computer in the selected network.
Select the IP address that will your web farm FQDN dns A record points to, and choose Add so it shows in the selected IP addresses column.
Highlight the IP address and choose Select Certificate…
The next page will show you the valid certificates installed to the local computer personal store on your server. Choose the certificate for your OCS web Components and choose select.
Hit Next twice, choose Finish to complete the listener configuration, you will be brought back to the web site publishing wizard with the new listener selected.
Hit Next, for authentication delegation choose No Delegation, but client may authenticate directly.
Make sure you hit Apply to actually commit the rule.
Now that this rule has been configured and you have an external DNS A record pointing to your External Web Farm FQDN, your users should be able to access the OCS web components remotely.
In the next post I will outline configuring TMG 2010 for Communicator Web Access.