We have been working on a site which requires a bespoke configuration to present their internal applications such as OWA, Sharepoint,CRM and some legacy out onto the Internet.
The solution that we have recommended to securely publish these resources and integrate them into Active Directory authentication is to install TMG 2010 alongside UAG 2010 within a Microsoft Hyper V 2008 R2 cluster environment.
We had suggested to the customer that they could present the resources either through a single url SSL Portal - e.g. https://vpn.domainname.com/ or through individual application trunks such as - https://owa.domainname.com/ or https://sharepoint.domainname.com/
When we went about deploying the remote access, the OWA publishing worked straight away both inside the UAG SSL Portal and also as an individual trunk through https://webmail.domainname.com/
The problems all started when we tried to get the published Sharepoint resources out through UAG. Firstly, this customer had a contiguous namespace for their DNS as per the recommended configuration by Microsoft, e.g. internal was domainname.com and external was domainname.com. Secondly, they were accessing their internal Sharepoint server over port 80 (HTTP) and naturally wanted to access their external Sharepoint resource through port 443 (SSL).
When the Sharepoint was presented through the SSL Portal configuration, we would have all of the applications contained within one single window after the original Single Sign On (SSO)of Active Directory was authenticated. The url at the top of this Portal was https://vpn.domainname.com/
When we clicked on the Sharepoint application to open the site, the site would open in an new page, but would have a url of https://vpn.domainname.com/
Although most of the links worked, when documents were tested to be checked in or out, created or deleted, we came across a number of errors and quickly realised that we needed to translate the original url of the internal Sharepoint site across to the UAG SSL Portal application - https://sharepoint.domainname.com/ instead of the Portal url of https://vpn.domainname.com/
This is where the fun began! Mainly because of our lack of experience on the installation of this product, and also because of the lack of concise documentation on UAG, we had all kinds of issues trying to get this to work.
Eventually, we called in our resources from Microsoft Ireland who put me in touch with a UAG Specialist in the UK. Here is the basics of what we had to do in order to get the URL Translation working between Sharepoint and UAG 2010:
1.Changed the Web Servers Tab and Portal link tab so that https://sharepoint.domainname.com was used as the public host name for SharePoint
2.Changed the Path on the Web Servers tab to ‘/’
3.Used a ‘fake’ host header to allow SharePoint to distinguish between intranet and internet clients
4.Configured SharePoint AAM rules to generate the correct public URLs for Internet clients
It's worth noting that these steps were additonally on top of the original configuration that we had implemented and they were the changes needed to get the configuration working the way we needed.
After all that, I'm now at last much clearer on configuring UAG 2010 with Sharepoint thankfully!
Hi Kevin,
ReplyDeleteGreat post. I am trying to also publish out our Sharepoint page using UAG. I am trying to use SSO but I am failing to get it to work.
My network does not have a contiguous namespace for my DNS. So my internal domain and external domain are different. Does that mean it basically won't work?
ANy help would be appriciative.
Thanks
AS
Hello Kevin, we have the same problem, perhaps you can provide some more details how to to it in UAG and sharepoint?
ReplyDeleteThanks
Stefan