HTTP to HTTPS Redirection Options in Forefront TMG and UAG
When publishing SSL-protected web sites such as Microsoft Outlook Web App with Forefront Threat Management Gateway (TMG) 2010 or Unified Access Gateway (UAG) 2010, it is often desirable to allow clients to enter the URL of the site without specifying the HTTPS protocol explicitly. For example, when publishing Outlook Web App (OWA) 2010 where the full URL is https://mail.celestix.net/owa/, for convenience an administrator might want to redirect non-secure requests for http://mail.celestix.net/owa/ to use the secure HTTPS protocol automatically. This can be done in a number of ways, depending on which Forefront solution is used for publishing.
Forefront TMG
With TMG, HTTPS redirection can be enabled by opening the properties of the web listener used in the publishing rule and selecting Enable HTTPS connections on port: and Redirect authenticated traffic from HTTP to HTTPS.
Now when users request the non-secure http://mail.celestix.net/owa/ they will automatically be redirected to the secure https://mail.celestix.net/owa/.
Even more convenient is to redirect requests for the base URL http://mail.celestix.net/ to the correct path https://mail.celestix.net/owa/. The easiest way to accomplish this is to create a new publishing rule that denies requests to http://mail.celestix.net/ and redirects them to https://mail.celestix.net/owa/. To enable this functionality, use the Web Site Publishing Wizard to create a publishing rule that denies access to http://mail.celesitx.net/ and redirects those requests to https://mail.celestix.net/owa/.
Be sure to place this rule before the publishing rule allowing access to the SSL-protected web site.
Now when users request the non-secure http://mail.celestix.net/ they will automatically be redirected to the secure https://mail.celestix.net/owa/.
Forefront UAG
Configuring Forefront UAG to redirect HTTP to HTTPS is even simpler. After you’ve created a trunk and published OWA, right-click HTTP Connections in the UAG management console navigation tree, select New Trunk, and then select the HTTP to HTTPS redirection option.
Connect
Richard Hicks' Forefront TMG Blog 
Why even allow port 80 to your TMG/UAG box? Seems risky. Wouldn’t it be better to have a firewall in front of TMG/UAG that only allows port 443 (and whatever other ports you need) and block port 80? We do the redirection on our website that is being hosted elsewhere then it sends it to our corporate network via https only.
That depends on your security policy and your appetite for risk. For many, allowing inbound port 80 is acceptable, and this article discusses ways in which to improve usability by redirecting those requests to port 443 (HTTPS). I do like your method of using an externally hosted web site to do the redirection though!
It does not seem like a true redirect? the new rule provides the default TMG forms based login page while the actual OWA rule would show the Exchange forms based page. Sure you could change the redirect rule to show the Exchange login page but its not the same really.
Not sure what you are talking about, Chris. The redirect is a function of a ‘deny’ rule in TMG. The client never gets an FBA page from the deny rule in question, just an HTTP 302 response (object moved).
Thank you! this the easiest way to redirect a link to an other…
I spent two days trying things… very helpfull thanks
so, if i have several sites to use https and i want to make redirects from http to https i should make several rules?
for example:
i have svn and git repos with addresses https://svn.blahblah.com and https://git.blahblah.com
so i have to make 2 “deny” rules to make redirects from http://svn.blahblah.com and http://git.blahblah.com ?
That’s correct. 🙂
Thank you Richard for posting this info and for your other blog regarding upgrading from ISA 2004/2006. I thought I would pass along some critical info that helped me get the HTTP redirection working on our TMG server. After a whole day’s work of frustration I was about to give up and start over with TMG server implementation until I found this blog by Andy Olson:
http://blogs.pointbridge.com/Blogs/olson_andy/Pages/Post.aspx?_ID=22#EntryTabs
He speaks about having IIS installed on the TMG server and how it will cause problems.
Thank you.
Mike
Thanks for the tip, Mike. It certainly underscores what we typically preach with the TMG firewall; don’t install unnecessary services on the TMG firewall! Not only does it introduce additional attack vectors, as you discovered it can also cause conflicts that can impact proper operation of the firewall too.
Hi Richard.
Thank you for this article. I’m new to TMG so forgive me my (possible) ignorance! 🙂
We have two url’s to our OWA: The “real” url which is: https://mobile.company.com, and a url (http://wmail.company.com) which should redirect to the real one.
We only have one listener on the TMG (for OWA and EAS).
The people who (tried) to set up the redirect deny rule have used “Perimeter” instead of a listener.
When I go to http://wmail.company.com it tries to redirect me to https://wmail.company.com instead of https://mobile.company.com/owa (which is specified in the deny rule)
I can see that you have a HTTPS and a HTTP listener in your example. Could the missing HTTP listener be the reason my redirect doesn’t work?
Best regards
Klaus Ringe Nielsen
Most likely. Try creating an HTTP listener as outlined in this article. Should work perfectly after that. 🙂
is it possible to save url path after redirection?
i mean how to teach TMG to do that:
http://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd -> https://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd
instead of:
http://ddd.ddd.dd/dd.ss.dd/ddd/sss/dd -> https://ddd.ddd.dd/
I don’t believe it is possible using the method I described in this post to capture the URL. You could accomplish this by adding each URL as a separate deny rule, but that would likely be cumbersome and ineffective. Something like you are looking for would be better handled at the web server using ASP code.
Unfortunately your solution will not work for ADFS Trunk examples where you have purchased just UAG. You cannot use the TMG to do the redirect because it is not supported and you cannot do the UAG method because it isn’t supported for ADFS trunks. At this point, we are kind of stuck in trying to get this part to work properly.
Thanks for making that point. Perhaps one of my readers has encountered this scenario and has a workaround?
Can i redirect http://www.facebook.com and https://www.facebook.com to http://www.yahoo.com
Regrads
Not using the techniques described in this post. You might be able to do this using an access rule that denies requests to http://www.facebook.com/ and redirects to https://www.facebook.com/, however, this is not something that I’ve ever been asked to do and I’m not certain it will even work as you expect. You can certainly try it though. 🙂
https://mail.local.net -> https://mail.local.net/owa is working !!!
http://mail.local.net-> https://mail.local.net/owa is NOT working !!!!
any advice !!!!
Look closely at your redirect rule. Make sure that the rule matches the incoming request and redirects correctly. Keep in mind that if you want to redirect HTTP and HTTPS, that will require two separate rules.
yes that what i did, two rules one for HTTPS(Working) with HTTPS Listener and another one for HTTP(Not working) with HTTP listener !!! but should i redirect traffic in HTTP -> HTTPS only for authentication or all traffic !!! in HTTP rule
No need to worry about authentication for the rule. Just redirect everyone and you’ll be fine, trust me. 🙂
I did, now the message Network Access Message: The page cannot be displayed.
Technical Information (For support personnel)
Error Code:403 Forbidden, Forefront TMG denied the specified Uniform Resource Locator(URL).(12202)
any advice thanks for ur support
Not sure what the trouble is. All I can tell you is that if you follow the steps in this article it should work. It does for me every time. 🙂
Hi richard,
Nice article…if the users are accessing via only https itself like the webmail address known to the outside world is https://webmail.contoso.com how can we redirect this https request or how can we append /owa to this from tmg.
HTTP port is closed from the firewall right now re direction done from IIS bcoz owa directly hits cas. iam configuring tmg have configured publishing rule and https://webmail.contoso.com/owa works but without /owa no luck.any work around you can suggest in this will be helpful.
thanks
Using the method I described in this article won’t work for redirecting only the path of an HTTPS request. Honestly, if a user is going to type in the correct protocol, they are typically going to enter the path as well. The redirect method I’ve demonstrated works in the most common scenario in which a users fails to enter the correct protocol.
Very good article. Helped me twice 🙂
Tried the UAG HTTP to HTTPS redirection and it works with OWA, but now Outlook Autodiscover is prompting users about the redirection with “Allow this server to configure..” prompt. I can see that UAG replies with 302, and that causes the prompt. Has anyone experienced the same and has a workaround?
Yes, the redirection feature can have some unintended side effects. You may have to create another trunk for your Outlook Anywhere clients to workaround this conflict.
Hi,
Richard, great guide.
I hope someone can help on my issue.
Is there a simple way to redirect an old HTTPS to a new HTTPS site on UAG 2010?
e.g. https://Test.old.com > https://Test.new.com
Its very simple on ISA using the Action Tab and selecting Deny. UAG, I can see is on the Trunk is Manual Redirection but its very complex due to the applications in use.
Thanks,
In UAG, no. At least not that I’m aware of. 😦
Hi Richard, nice guide,
I know this is a diferent topic but maybe u can help me
I need to publish lync in UAG but i have already used the port 443 with direct access, the question is can i assign the same port for lync?
Thx
PD. Sorry for my english!!
No, you can’t use the same port on the same IP address. You can, however, assign another IP address to the UAG server’s external network interface. Once you’ve done that you can create another trunk for which you can publish Lync web components on TCP port 443.
Hi Richard,
Just to add some information on the redirection. It seems there is a different way also, which allows it outside “Trunk only”. Spent quite a few hours trying to figure out something, so I will be trying the referenced in given time 🙂
http://blogs.technet.com/b/ben/archive/2013/04/03/how-to-create-a-static-redirector-on-a-uag-trunk.aspx
Excellent. Thanks for sharing that, Jesper! 🙂
redirection is working fine for my setup. But when i enabled for user must change password in first logon. It’s ending with SSL error. when i entered http://webmail.test.com it takes me to https://webmail.test.com/owa after entered the user name password which set as password must change it takes me to https://webmail.test.com:80/owa/auth/expiredpassword.aspx?url=/owa/auth.owa which you can see 80 port is getting added automatically and it’s ending with SSL error. If i remove manually 80 from url it’s taking me to password change screen with out any issue. I believe something i’m missing in my configuration. Any idea?
intranet it’s working fine. it’s takes me to password change screen with out any issue. Only the issue over the internet. thanks in advance
I’m not sure what could be causing this. However, if you take a network trace on both sides of the TMG firewall you should be able to identify who is appending the :80 to the URL. I don’t know if there’s a good way to resolve this using TMG though. If you’re using an external load balancer like F5, you could create an iRule to remove this from the response to resolve the issue.
Same issue i am also having,
I tried all those mentioned steps,
But no luck…
Is there any other way to make it possible?
Not to my knowledge. One of the methods described in this post should work though. It has for me countless times. 🙂
how to aalow http://www.google.com in forfront tmg 2010 ?
please help me . I instal tmg 2010 and allow all sites trafic and all are working good but GOOGLE cant open and not working so please elp me I shell be very thankfull to you for that …..
Regards : Pir Hamed Ali Shah
Allowing access to Google should be as easy as creating an access rule that allows access to that domain for all users on ports 80 and 443 (HTTP and HTTPS).