A good resource for understanding unsupported scenarios for Forefront UAG is the Support Boundaries document. This is dynamic resource that is updated by Microsoft at regular intervals to reflect changes in supported UAG scenarios; sometimes due to new features added by updates, or sometimes based upon completion of additional scenario testing.
During a recent UAG engagement which involved Office Communications Server (OCS) I referenced the above resource to try an determine the level of supportability in UAG for OCS. The following statement is included within the document:
You can publish the following applications via Forefront TMG:
- Exchange SMTP/SMTPS
- Exchange POP3/POP3S
- Exchange IMAP/IMAPS
- Office Communications Server (OCS)
Due to the location of the statement within the Support Boundaries document, I suspected this reference to OCS was actually related to the use of server publishing for the Session Initiation Protocol (SIP) element (which uses TCP5060/5061) as opposed to the web publishing aspects. After confirming this with the product group, I then began thinking about how to support the OCS web components for customers using UAG as their only remote access gateway solution.
Disclaimer: At this time, it is my understanding that support for OCS Web Component publishing via Forefront UAG is not available from Microsoft, so please consider the implications of using the procedures in this blog post. However, the reverse proxy configuration is actually based on the current TMG guidance, just re-interpreted for the UAG platform.
Support for publishing the OCS web components with ISA/TMG is well documented, but not for UAG it would seem. One option, as covered here, is to use the web publishing feature set of the TMG instance that exists below UAG. However, with no offence to Kevin (OCS Guy), the unbinding is a pretty brutal approach and very unlikely to ever be supported by Microsoft support. As an alternative, I took inspiration from a recent blog by Tom called How to Configure UAG to Publish Your Private Certificate Revocation List in order to define the solution provided in the walkthrough below. The key difference with this approach being that we are using the UAG management console and native feature set.
OCS Web Components
In order for the OCS communicator client to provide full functionality when away from the office, it is necessary to provide access to several web services that are not natively handled by the OCS edge roles. These web services or components include:
- Download meeting content for your meetings.
- Expand distribution groups.
- Download files from the Address Book Service.
These components are defined using a public (external) fully qualified domain name and utilise the HTTPS protocol for secure communication.
So, why do we actually need a reverse proxy?
The reverse proxy role provides additional functionality not provided by any of the three edge roles. Consequently, it is recommended to deploy a reverse proxy server if you want to enable remote users to do one or more the following:
- Download the address book.
- Expand distribution groups.
- Download Live Meeting content.
Specific guidance is provided for Microsoft ISA Server (and consequently Forefront TMG) in the OCS 2007 R2 Edge Configuration Guide. If you already have a dedicated instance of ISA Server or Forefront TMG (or other third-party reverse proxy) you do not need to utilise UAG for OCS web component publishing. However, if UAG is your only inbound remote access gateway, read on…
Even though UAG can act as a reverse proxy for many web applications, it does not provide a default template or wizard for any OCS services (including SIP publishing) or provide any specific UAG guidance/documentation for OCS. So we are kind of on our own here. By looking at the documentation available for Forefront TMG and using the concept of configuring UAG as a generic reverse proxy (with input from Tom’s article) we have most of the answers we need to begin the configuration.
|Please Note: It is likely that existing UAG trunks will be configured to enforce authentication, so are not suitable for use with OCS web components which cannot handle default UAG pre-authentication. Consequently, it will be necessary to define a new trunk to host the OCS web components which will require an additional IP on the UAG external interface. Unless you are already using a suitable SAN or wildcard certificate on UAG, you will also likely need to purchase an additional SSL server certificate to cater for the public name (FQDN) used to reference the OCS web components (often termed the OCS external web farm FQDN).|
Step 1: Assign a unique IP address for use with the OCS trunk
If you are using a UAG array with integrated NLB, it will first be necessary to define a new external VIP using the Network Load Balancing option from the Admin menu of the UAG management console. Otherwise, you will just need to add a new IP address to the external interface.
This IP address will need to be registered in your external DNS zone and assigned to your OCS external web farm FQDN. For this purposes of this post, this will be defined as ocsrp.msedge.org.uk
Step 2: Create the OCS trunk
With a dedicated IP address (or VIP for an NLB array) now available, we can begin the trunk creation process. Create a new trunk as follows:
Select Portal trunk:
Enter an appropriate Trunk name, Public host name and IP address binding. The public host name is not actually used for our scenario, so it can be a fake entry and doesn't need to specifically match the OCS external web farm FQDN. However, the fake name must contain the same parent DNS domain as the external web farm FQDN (e.g. [name].msedge.org.uk in our example):
When presented with the Session authentication server option, add an existing repository or create a new one. As we will be disabling authentication later, this step is only really needed to satisfy the wizard and allow us to progress:
Select the appropriate certificate that contains a Common Name (CN) or Subject Alternate Name (SAN) that matches the chosen OCS external web farm FQDN (e.g. ocsrp.msedge.org.uk in our example):
Accept the default Use Forefront UAG access policies option; although we will be disabling endpoint component activation later:
Accept the default Endpoint Policies options; although we will be disabling endpoint component activation later:
Verify your settings and click Finish:
Step 3: Configure advanced OCS Trunk properties
Once created, amend the trunk as follows:
Disable (untick) the Require users to authenticate at session logon option from the Advanced Trunk Configuration | Authentication tab:
Disable (tick) the Disable component installation and activation and Disable scripting for portal applications options from the Advanced Trunk Configuration | Session tab:
Step 4: Add the custom OCS Web Components application
Create a new custom application as follows:
Select the Other Web Application (application specific hostname) template:
Enter an appropriate Application name and Application type:
Accept the default Endpoint Policies (these are irrelevant for our particular scenario anyhow):
Assuming you have a single OCS server, select the Configure an application server option, otherwise use the farm option:
Enter your OCS server name (pool name) in the Addresses field, select HTTPS port:443 and enter the appropriate Public host name that matches your OCS external web farm FQDN (e.g. ocsrp.msedge.org.uk in our case):
Accept the default SSO setting of Disabled (we cannot use this for our scenario):
Accept the default Portal Link settings:
Accept the default Authorisation setting:
Verify your settings and click Finish:
Step 5: Amend the OCS Trunk properties
Define the custom OCS Web Components application as the Initial Internal Application, disable (untick) the Use portal frame option and remove the default Portal application from the Applications list. This should leave you with the following:
Step 6: Create the HTTP to HTTPS redirection trunk
Although I don’t believe this is entirely necessary, for completeness, we can create a HTTP to HTTPS redirection trunk which maps to the OCS HTTPS secure trunk. This ensures that any attempted access over HTTP will automatically be redirected to the secure OCS trunk.
Step 7: Configure UAG Servers to Support Full Authentication Passthrough
The default behaviour of UAG is to “downgrade” the supported authentication schemes that a backend web server sends in the WWW-Authenticate header within an HTTP 401 Unauthorised response. However, when using the OCS Communicator client this behaviour introduces unwanted authentication prompts when the client attempts to access OCS web components (like during an address book download). In order to prevent this default UAG behaviour we can use the FullAuthPassthru registry key as defined here. When this registry key does not exist, or added with a value of ‘0’, UAG will only send the client a WWW-Authenticate:Basic request, even if the backend web server also sent NTLM and/or Negotiate. When the registry key is added with a value of ‘1’, the WWW-Authenticate headers are no longer modified by UAG and the original response from the backend server, will reach the client unchanged. Therefore, we need to amend the default UAG behaviour by using the following registry file:
Windows Registry Editor Version 5.00
When making changes to the registry on UAG servers, it is useful to understand the correct process as discussed here.
This change will ensure that the WWW-Authenticate headers sent from the OCS edge role are not modified and subsequently will allow the OCS Communicator client to transparently provide credentials without prompting the user.
Step 8: Activate the new configuration
Activate the new configuration to apply the changes to UAG.
By activating the changes, we also ensure that custom UAG registry keys (as defined in Step 7) will be written to TMG storage and will not be lost during a reboot cycle.
|Please Note: If necessary, use the Forefront UAG Activation Monitor application to monitor the activation process and be patient as it often takes a while to complete|
In terms or testing, we can achieve a good level of confidence by using a standard browser combined with some specific OCS web component URLs, as follows:
Test the Address Book Service
Open a web browser and access https://<Public Hostname>/abs/ext/
as this virtual directory is protected with Windows Integrated authentication, you should expect to see an authentication pop-up. Enter valid domain credentials and you should be presented with the following (a blank screen):
Test the Group Expansion Service
Open a web browser and access https://<Public Hostname>/GroupExpansion/ext/service.asmx
as this virtual directory is protected with Windows Integrated authentication, you should expect to see an authentication pop-up. Enter valid domain credentials and you should be presented with the following (the Live Server Distribution List Expander page):
Test the Web Conferencing Service
Open a web browser and access https://<Public Hostname>/conf/ext/Tshoot.html
as this virtual directory is not protected with Windows Integrated authentication, you will not expect to see an authentication pop-up and you should be presented with the following (the Microsoft Office Live Meeting Client Troubleshooting page):
Once the above tests have been completed successfully, you can then test the communicator client from an external location. You can use the Forefront UAG Web Monitor Event Log to verify application access and troubleshoot any potential problems. However, if the above tests were successful, it is very likely that the communicator client will also work.
So, that completes this walkthrough for publishing the OCS web components using UAG. I hope it proves useful until such time as official Microsoft documentation or guidance is available.
|Please Note: From what I understand, the above walkthrough should also support Microsoft Lync (the impending successor to OCS 2007 R2) as the web component elements of the product remain largely unchanged.|
I plan to write a follow up article very soon which covers UAG publishing for OCS 2007 R2 Communicator Web Access (CWA) with specific support for the iDialog iPhone application from Modality Systems. This is a pretty cool iPhone app that provides OCS communicator client functionality on your iPhone – nice!
Props: Many thanks to Ran Dolev (MSFT) and Steve Mercieca for valuable input to this blog post.