Beware: Using UAG with an SSL decryptor in front

A quick beware: In UAG you set up your trunks as http or https - which is fine unless you have an SSL decryptor in front of the UAG server. Using this, you access the site using https, but the traffic is decrypted and reaches the server as http.
The problem here is that UAG uses HTTP 302 redirects extensively. However, the content of these are defined by whether the trunk is http or https and as such in the scenario above returns redirects with http links.
This means that (assuming your SSL decryptor cannot/does not rewrite those links for you), users directed to the http version of the site not the https, which completely breaks the site for the user.
The easy fix is to set up something that accepts those http requests and redirects users to the https site (I use my load balancer)
More complicated is to use AppWrap to rewrite the 302s - I will update when I test this
--Chris

(update below following MS answer:)

* Create the file c:\program files\Microsoft Forefront Unified Access Gateway\von\conf\websites\\conf\CustomUpdate\WhlFiltAppWrap_HTTP.xml (you may have to create the CustomUpdate folder)


* Paste the XML snippet below into it



==============START=================
<APP_WRAP ver="1.0" id="RemoteAccess_HTTPS.xml">
<MANIPULATION>
<HEADER_CHANGE>
<RESPONSE>
<APPLICATION>
<SERVER_NAME mask="">localhost</SERVER_NAME>
<PORT>6001</PORT>
<URL>
<URL_NAME>.*</URL_NAME>
<HEADER>
<NAME>Location</NAME>
<SAR>
<SEARCH encoding="">http://www.example.com</SEARCH>
<REPLACE encoding="">https://www.example.com</REPLACE>
</SAR>
</HEADER>
</EDIT>
</URL>
</APPLICATION>
</RESPONSE>
</HEADER_CHANGE>
</MANIPULATION>
</APP_WRAP>

===============END==================


* Activate UAG.

* You can still use appliciation manipulation tags in here if you have other AppWrap

Customising the portal is complicated

For info, a summary of my thread on the UAG forums re customising the portal: (http://bit.ly/cXr8kf)

Question: I am trying to customise the layout of the portal pages - I know of the changes in Technet etc to hide the left bar, top har, toolbar etc, but I want to rearrange the look of the whole page. However, I am having an almighty battle with changing the DIVs' positioning in CSS (no help from IE & Firefox layout differences!).

I have spent a couple of hours on this, playing with DIV positioning etc, but not really in huge depth as every change I made caused odd effects. DIVs within tables within DIVs etc...I spent about an hour trying to stop the main content window overflowing off the bottom of the page acheiving only some loss of sanity

Has anyone made wholesale changes to the layout of the Portal? Does it work well or are there gotchas?

And is this beyond the support boundary for UAG (the technet article is unclear on how far you can go)

Ben Ari MSFT: As for supportability, customizations beyond what the documentation instructs are not supported.

Ran MSFT: The boundaries of supported web-content customizations in UAG are actually simple to define: if you can do it in a CustomUpdate customization, then it's supported. Another supported customization is for some very specific resources where the UAG management console allows you to specify a new file, instead of the default one (i.e. the Login and the Error page). Other than these, other changes are not supported. True, there is nothing stopping you from modifying one of the default files that UAG comes with, but besides those changes not being backed-up, and not being replicated across UAG array members, they are also not supported.

Ran MSFT: ... the CSS is customizable via a CustomUpdate folder, and so is the .master file. You can find references to these under the http://technet.microsoft.com/en-us/library/ff607389.aspx section, and to be more specific, customizing the Standard.master file is mentioned in these articles: http://technet.microsoft.com/en-us/library/ee861154.aspx and http://technet.microsoft.com/en-us/library/ee861172.aspx

SuperNaraen: We've had to revamp the layout. Here is our experience.

At first we tried to change the css. It turned out to be very involved. So, we dropped that approach.

Then we tried the other extreme, to completely create our own portal web application that would paint the UAG links (Can't locate the article (by Tom Shinder?) right now, which described how to do it for IAG. We found that article very helpful). We found that we were investing a lot of time getting functionality like logoff, timeout behavior etc that comes bundled with the portal.

We have now settled on a hybrid approach. We published our custom portal web application within the portal frame. We then hid the headers and the navbar from the portal frame completely. This is giving us the best of both worlds.

Issues with .inc files with custom ASP scripts

Another strange one...if you modify an ASP page (eg logon.asp) I found that there can be problems with that script accessing inc files, as the links in the script seem to assume that the inc folder is in the same folder as the script - which of course it is until you make your own version.

What happens is that the script will not find inc files properly when it runs and strange things happen. What it needs is the inc files to not be in von/InternalSite/inc but be in von/InternalSite/CustomUpdate/inc

One answer is to copy all of the files that are in von/InternalSite/inc to a new folder von/InternalSite/CustomUpdate/inc. This fixes the problem nicely. However, when you update a file you need to remember to update it in both places. And UAG will not back this folder up either.

The best answer is to create a soft link (aka symlink in UNIX) in the CustomUpdate folder to the inc folder. What this does is create a link in the file system so rather than have a copy of the inc folder under CustomUpdate you actually have the real folder instead. Google symlinks to understand more about how this concept works

In windows, you use mklink to create a soft link. From the InternalSite folder run the following command

mklink /D ./CustomUpdate/inc ./inc

You should see a new folder in CustomUpdate, which should contain everything in inc. In Explorer it is shown as a shortcut (the folder has a little arrow)

Be careful when renaming files when you put them in CustomUpdate

Remember when you customise any file and place it in CustomUpdate to use the same filename, only appending the trunk name and 1 or 0 (for https or http) to the name and nothing else. If you so change the filename, update the rules in the trunk Advanced Settings URL Set: find the rule that affects the file you changed, copy it (placing it directly below) and modify the new rule to include your filename. GIYF when it comes to Regex++ expressions used in UAG if you are using strange filenames.

You need to modify every trunk if you change a major file like login.asp if they all use that file. If you have a custom naming convention so each trunk has its own version of the file, you might be able to write one rule that matches all your names and use that in each trunk, or you might have to write a rule from scratch on each trunk.

[GIYF: Google is your friend]

(Offtopic) Using RemoteApp - signing a cert for your Terminal Server

Just fixed an annoying, off topic problem with Terminal Services behind UAG

Current Task: Publish a RemoteApp through UAG

Problem: I generated a certificate on my own Windows Server 2008 CA but it is not suitable for use with Remote Desktop

Solution: see http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx

Contains a WMI script that converts the file to be suitable for Remote Desktop. Note the cert must be signed, and in the terminal server personal certificates store

Customising InternalError.asp

If you want to customise InternalError.asp and place a copy in CustomUpdate (as you would with other files) and you change the path of the error page (under the trunk Advanced Settings) to this new file, you will find you get an HTTP 500 error. Remember when entering the path in the Advanced Settings that it (bizarely) requires /InternalSite/CustomUpdate/InternalError.asp

You need to do two things to get this to work

- In the URL Set tab of the trunk Advanced Settings, browse down the rules until you find the InternalSite rule for InternalError.asp. Change the rule from /internalsite/internalerror\.asp to read /internalsite/(customupdate/)?internalerror\.asp
[if you have renamed InternalError.asp, make a copy of the rule above instead of editing it, put it under the one above, and amend the file name too. The out-of-the-box rules do not allow you to change filenames of most files]

- the InternalError.asp page references the files in InternalSite\inc directly. This means that when run it cannot find any of the inc files it needs. The answer is to create a 'symlink' - which is a very UNIXy thing to do but it possible in Windows too. Open a command prompt in Administrator mode, and change directory to [your UAG directory]\von\InternalSite\CustomUpdate. Run the command 'mklink .\inc ..\inc'

Apply your config and this should now work

Adding links to a Portal that point outside (eg Google)

I had a need recently to add links to external sites eg Google onto a UAG portal. I thought it was obvious and it was just me, its really not...

Thanks to Ran who answered with a solution

http://bit.ly/9mCwQ8 {social.technet.microsoft.com}

This can also be used to link between UAG trunks manually

---

Follow these steps:

1. Add a new application to your portal trunk, using the type Other Web App (portal hostname)

2. On the Web Servers step of the Add Application Wizard, in the Addresses list, enter a dummy hostname address

3. On the Portal Link step of the wizard, in the Application URL, delete the automatically created URL and instead enter the actual URL of the external site to which you want to direct your users.

4. Choose YES on the "The application URL is not valid. Illegal server address" error message.

5. Complete the wizard and activate the configuration

Some notes:

- You will get some activation warning messages about the dummy server address you entered in step 2 above not being resolvable.

- You probably should select the option to open this site in a new browser window, otherwise, when accessed, the site will be contained in a frame within the UAG portal, and your users will get a Security Warning if the external application link points to an HTTP address, while your portal is accessed via HTTPS.

HTH,

-Ran

Strange Problem: 500 errors when using Login.asp in CustomUpdate - *FIXED* (Beware of the slashes)

I have a strange issue, that I have logged on the Technet forums (http://bit.ly/9ptWzS) and am logging with MS Support shortly
When you login to a trunk with valid credentials, everything works fine, and you get to the site behind the UAG with no errors.  However logins with invalid credentials to the domain result in a 500 error page - not the Login.asp page you would expect to see saying "Authentication failed" or similar - but a plain page that just has the ASP 500 error text.  Neither is the 500 error page the one that exists in the UAG von folders, and I have disabled IE from showing me a 'nice' version of errors.  The URL in IE when the 500 page is showing is:
https://mytrunk.mydomain.com/uniquesig323ea943fa68b62274545754478452/uniquesig0/InternalSite/Validate.asp
The error text on the page is:
"An error occurred on the server when processing the URL. Please contact the system administrator.
If you are the system administrator please click here to find out more about this error."

Customising UAG - InternalSite / Login.asp

One of the first requirements I addressed was the customisation of the login pages of the site.  Initially, Microsoft support stated that customisation was not permitted, later dismissed by Professional Services, and on the contrary was encouraged by them.

The aim of this post is to give a very high level summary of what I did – the aims of the work were:

o   to corporately brand the page properly and completely remove the UAG branding. 

o   to ensure consistent look and feel to corporate standards

o   to make a first attempt of customising UAG

I then got MS PS to verify how I went about the task to be sure I did it right.

I make a lot of assumptions here about basic knowledge of UAG as I could write forever, but within the first hour or two of customising a deployment these assumptions will be second nature.

Essential skills: good understanding of HTML; javascript and (classic) ASP are a benefit but you can just go around them otherwise

Raison d'etre

So...a new blog starts here.  But why?

I have recently started a project to create a Microsoft UAG deployment, with a specific requirement of delivering reverse proxying of published web sites, but with added security over a TMG solution.  No Direct Access, no Microsoft applications, just proxying.  And infomation on this is thin at best

Many would say that TMG would have acheived what I needed, I won't argue either way here.

But why the blog?  Well, to be honest I needed somewhere to keep information that I have found about UAG, and a blog I hope will allow others to use what I have found.  Microsoft have only a handful of people who understand UAG - though those people are very knowledgable - and I have struggled to get information on getting UAG to work how I want it to.

I have found lots of sites that have valuable information, for both IAG and UAG.  But I also have found a lot of gaps.  When I find a solution to these gaps, I will post it.  When I find a good site, I'll post that too.

With any luck, someone going down the same path as I have will find this reference useful