Life in a Post TMG World – Is It As Scary As You Think?


Let’s start this post about Exchange with a common question: Now that Microsoft has stopped selling TMG, should I rip it out and find something else to publish Exchange with?

I have occasionally tried to answer this question with an analogy. Let’s try it.

My car (let’s call it Threat Management Gateway, or TMG for short), isn’t actively developed or sold any more (like TMG). However, it (TMG) works fine right now, it does what I need (publishes Exchange securely) and I can get parts for it and have it serviced as needed (extended support for TMG ends 2020) and so I ‘m keeping it. When it eventually either doesn’t meet my requirements (I want to publish something it can’t do) or runs out of life (2020, but it could be later if I am ok to accept the risk of no support) then I’ll replace it.

Now, it might seem odd to offer up a car analogy to explain why Microsoft no longer selling TMG is not a reason for Exchange customers to panic, but I hope you’ll agree, it works, and leads you to conclude that when something stops being sold, like your car, it doesn’t immediately mean you replace it, but instead think about the situation and decide what to do next. You might well decide to go ahead and replace TMG simply based on our decision to stop selling or updating it, that’s fine, but just make sure you are thinking the decision through.

Of course, you might also decide not to buy another car. Your needs have changed. Think about that.

Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to.

  1. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online.
  2. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either.
  3. We have spent an awfully large amount of time as a company working on securing our code, writing secure code, testing our code for security, and understanding the threats that exist to our code. This is why we feel confident enough to do #1 and #2.
  4. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity.
  5. We have invested in getting our policies right and monitoring our systems.

This basically says we didn’t buy another car when ours didn’t meet our needs any more. We don’t use TMG to protect ourselves any more. Why did we decide that?

To explain that, you have to cast your mind back to the days of Exchange and Windows 2000. The first thing to admit is that our code was less ‘optimal’ (that’s a polite way of putting it), and there were security issues caused by anonymous access. So, how did we (Exchange) tell you to guard against them? By using something called ISA (Internet Security and Acceleration – which is an odd name for what it was, a firewall). ISA, amongst other things, did pre-authentication of connections. It forced users to authenticate to it, so it could then allow only authenticated users access to Exchange. It essentially stopped anonymous users getting to Windows and Exchange. Which was good for Windows and Exchange, because there were all kinds of things that they could do if they got there anonymously.

However once authenticated users got access, they too could still do those bad things if they chose to. And so of course could anyone not coming through ISA, such as internal users. So why would you use ISA? It was so that you would know who these external users were wouldn’t you?

But do you really think that’s true? Do you think most customers a) noticed something bad was going on and b) trawled logs to find out who it was who did it? No, they didn’t. So it was a bit like an insurance policy. You bought it, you knew you had it, you didn’t really check to see if it covers what you were doing until you needed it, and by then, it was too late, you found out your policy didn’t cover that scenario and you were in the deep doo doo.

Insurance alone is not enough. If you put any security device in front of anything, it doesn’t mean you can or should just walk away and call it secure.

So at around the same time as we were telling customers to use ISA, back in the 2000 days, the whole millennium bug thing was over, and the proliferation of the PC, and the Internet was continuing to expand. This is a very nice write up on the Microsoft view of the world.

Those industry changes ultimately resulted in something we called Trustworthy Computing. Which was all about changing the way we develop software – “The data our software and services store on behalf of our customers should be protected from harm and used or modified only in appropriate ways. Security models should be easy for developers to understand and build into their applications.” There was also the Secure Windows Initiative. And the Security Development Lifecycle. And many other three letter acronyms I’m sure, because whatever it was you did, it needed a good TLA.

We made a lot of progress over those ten years since then. We delivered on the goal that the security of the application can be better managed inside the OS and the application rather than at the network layer.

But of course most people still seem to think of security as being mainly at the network layer, so think for a moment about what your hardware/software/appliance based firewall does today. It allows connections from a destination, on some configurable protocol/port, to a configured destination protocol/port.

If you have a load balancer, and you configure it to allow inbound connections to an IP on its external interface, to TCP 443 specifically, telling it to ignore everything else, and it takes those packets and forward them to your Exchange servers, is that not the same thing as a firewall?

Your load balancer is a packet filtering firewall. Don’t tell your load balancing vendor that, they might want to charge you extra for it, but it is. And when you couple that packet level filtering firewall/load balancer with software behind it that has been hardened for 10 years against attacks, you have a pretty darn secure setup.

And that is the point. If you hang one leg of your load balancer on the Internet, and one leg on your LAN, and you operate a secure and well managed Windows/Exchange Server – you have a more secure environment than you think. Adding pre-authentication and layers of networking complexity in front of that buys you very little extra, if anything.

So let’s apply this directly to Exchange, and try and offer you some advice from all of this. What should YOU do?

The first thing to realize is that you now have a CHOICE. And the real goal of this post is to help you make an INFORMED choice. If you understand the risks, and know what you can and cannot do to mitigate them, you can make better decisions.

Do I think everyone should throw out that TMG box they have today and go firewall commando? No. not at all. I think they should evaluate what it does for them, and, if they need it going forward. If they do that, and decide they still want pre-auth, then find something that can do it, when the time to replace TMG comes.

You could consider it a sliding scale, of choice. Something like this perhaps;

TMGScale

So this illustrated that there are some options and choices;

  1. Just use a load balancer – as discussed previously, a load balancer only allowing in specified traffic, is a packet filtering firewall. You can’t just put it there and leave it though, you need to make sure you keep it up to date, your servers up to date and possibly employ some form of IDS solution to tell you if there’s a problem. This is what Office 365 does.
  2. TMG/UAG – at the other end of the scale are the old school ‘application level’ firewall products. Microsoft has stopped selling TMG, but as I said earlier, that doesn’t mean you can’t use it if you already have it, and it doesn’t stop you using it if you buy an appliance with it embedded.

In the middle of these two extremes (though ARR is further to the left of the spectrum as shown in the diagram) are some other options.

Some load balancing vendors offer pre-authentication modules, if you absolutely must have pre-auth (but again, really… you should question the reason), some use LDAP, some require domain joining the appliance and using Kerberos Constrained Delegation, and Microsoft has two options here too.

The first, (and favored by pirates the world over) is Application Request Routing, or ARR! for short. ARR! (the ! is my own addition, marketing didn’t add that to the acronym but if marketing were run by pirates, they would have) “is a proxy based routing module that forwards HTTP requests to application servers based on HTTP headers and server variables, and load balance algorithms” – read about it here, and in the series of blog posts we’ll be posting here in the not too distant future. It is a reverse proxy. It does not do pre-authentication, but it does let you put a non-domain joined machine in front of Exchange to terminate the SSL, if your 1990’s style security policy absolutely requires it, ARR is an option.

The second is WAP. Another TLA. Recently announced at TechEd 2013 in New Orleans is the upcoming Windows Server 2012 R2 feature – Web Application Proxy. A Windows 2012 feature that is focused on browser and device based access and with strong ADFS support and WAP is the direction the Windows team are investing in these days. It can currently offer pre-authentication for OWA access, but not for Outlook Anywhere or ActiveSync. See a video of the TechEd session here (the US session) and here (the Europe session).

Of course all this does raise some tough questions. So let’s try and answer a few of those;

Q: I hear what you are saying, but Windows is totally insecure, my security guy told me so.

A: Yes, he’s right. Well he was right, in the yesteryear world in which he formed that opinion. But times have changed, and when was the last time he verified that belief? Is it still true? Do things change in this industry?

Q: My security guy says Microsoft keeps releasing security patches and surely that’s a sign that their software is full of holes?

A: Or is the opposite true? All software has the potential for bugs and exploits, and not telling customers about risks, or releasing patches for issues discovered is negligent. Microsoft takes the view that informed customers are safer customers, and making vulnerabilities and mitigations known is the best way of protecting against them.

Q: My security guy says he can’t keep up with the patches and so he wants to make the server ‘secure’ and then leave it alone. Is that a good idea?

A: No. It’s not (I hope) what he does with his routers and hardware based firewalls is it? Software is a point in time piece of code. Security software guards against exploits and attacks it knows of today. What about tomorrow? None of us are saying Windows, or any other vendor’s solution is secure forever, which is why a well-managed and secure network keeps machines monitored and patched. If he does not patch other devices in the chain, overall security is compromised. Patches are the reality of life today, and they are the way we keep up with the bad guys.

Q: My security guy says his hardware based firewall appliance is much more secure than any Windows box.

A: Sure. Right up to the point at which that device has a vulnerability exposed. Any security device is only as secure as the code that was written to counter the threats known at that time. After that, then it’s all the same, they can all be exploited.

Q: My security guy says I can’t have traffic going all the way through his 2 layers of DMZ and multitude of devices, because it is policy. It is more secure if it gets terminated and inspected at every level.

A: Policy. I love it when I hear that. Who made the policy? And when? Was it a few years back? Have the business requirements changed since then? Have the risks they saw back then changed any? Sure, they have, but rarely does the policy get updated. It’s very hard to change the entire architecture for Exchange, but I think it’s fair to question the policy. If they must have multiple layers, for whatever perceived benefit that gives (ask them what it really does, and how they know when a layer has been breached), there are ways to do that, but one could argue that more layers doesn’t necessarily make it better, it just makes it harder. Harder to monitor, and to manage.

Q: My security guy says if I don’t allow access from outside except through a VPN, we are more secure.

A: But every client who connects via a VPN adds one more gateway/endpoint to the network don’t they? And they have access to everything on the network rather than just to a single port/protocol. How is that necessarily more secure? Plus, how many users like VPN’s? Does making it harder to connect and get email, so people can do their job, make them more productive? No, it usually means they might do less work as they cannot bothered to input a little code, just so they can check email.

Q: My security guy says if we allow users to authenticate from the Internet to Exchange then we will be exposed to an account lockout Denial of Service (DoS).

A: Yes, he’s right. Well, he’s right only because account lockout policies are being used, something we’ve been advising against for years, as they invite account lockout DoS’s. These days, users typically have their SMTP address set to equal their User Principal Name (UPN) so they can log on with (what they think is) their email address. If you know someone’s email address, you know their account logon name. Is that a problem? Well, only if you use account lockout policies rather than using strong password/phrases and monitoring. That’s what we have been telling people for years. But many security people feel that account lockouts are their first line of defense against dictionary attacks trying to steal passwords. In fact, you could also argue that a bad guy trying out passwords and getting locked out now knows the account he’s trying is valid…

Note the common theme in these questions is obviously – “the security guy said…..”. And it’s not that I have it in for security guys generally speaking, but given they are the people who ask these questions, and in my experience some of them think their job is to secure access by preventing access. If you can’t get to it, it must be safe right? Wrong. Their job is to secure the business requirements. Or put another way, to allow their business to do their work, securely. After all, most businesses are not in the business of security. They make pencils. Or cupcakes. Or do something else. And is the job of the security folks working at those companies to help them make pencils, or cupcakes, securely, and not to stop them from doing those things?

So there you go, you have choices. What should you choose? I’m fine with you choosing any of them, but only if you choose the one that meets your needs, based on your comfort with risk, based on your operational level of skill, and based on your budget.

Greg Taylor
Principal Program Manager Lead
Exchange Customer Adoption Team

Comments (40)
  1. UAG says:

    If this is true, then why is Microsoft still keeping UAG?  Why not just discontinue UAG and advise everyone to setup all servers that have remote capabilities with public IPs or behind a NLB?  

  2. wow says:

    There are too many false assumptions to rebut here. First, and probably most importantly, load balancers are not hardened devices. Of course, they act to proxy tcp ports to another device (such as Exchange) but they aren't necessarily hardened to protect themselves from attack. Should they be? Of course. Why aren't they then? Most likely, it is the usual excuse. Developers spend their time coding in new functionality and not necessarily security. I don't know ANY load balancer that recommends running it directly on the internet. Second, comparing a firewall to a car is completely insane. Sure, your car might keep running after the warranty expires. Your firewall, however, requires constant updates to secure against the latest threats. Even thought we will continue to use our TMG firewall for the foreseeable future, the lack of any code updates such as service packs or even any more rollups definitely causes concern.

  3. This article totally makes sense, if it was published three or five years ago. In reality Microsoft recommended a reverse proxy even after the EOL announcement of TMG and did so consistently in every document and guideline. The same author telling us here why we don't need TMG anymore wrote several articles and whitepapers on how to deploy TMG and UAG with recent versions of Exchange.

    blogs.technet.com/…/publishing-exchange-server-2013-using-tmg.aspx

    blogs.technet.com/…/3410408.aspx

    I have great respect for the author, but not for the message the team is giving here. First of all, this is the first proper response since September 2012. Why on earth took that so long, knowing almost every Exchange deployment uses TMG as reverse proxy? Many people asked for guidance in the forums and there was no clear answer. This leads me to believe that the team saw itself forced to tell us we don't need TMG anymore because the product was pulled.

    Also I would not recommend anybody to use TMG in a new Exchange design, knowing that support ends in a short time. UAG makes no sense either, it's not very likely that we see a version compatible with Server 2012 or Server 2012 R2. That leaves WAP in Server 2012 R2, obviously this is where the missing features from TMG and UAG seem to reappear. It is a complete mystery to me why Microsoft decided to pull TMG almost 18 months before a (kind of) replacement appears in the form of Server 2012 R2 WAP.

    And a final point. Many companies have the requirement to terminate unauthenticated traffic in a perimeter network. It's not up to me as the Exchange consultant to convince them why their security policy is outdated, it's up to me to design a solution meeting their needs. And this has become a lot more difficult in the post TMG era, no TechNet blog is gonna fix that.

  4. Good article. I'm of the mindset that the TMG retirement scenario is a good opportunity to start partnering with web application firewall partners.

    I wrote an article with a more pragmatic approach to TMG alternatives a while ago http://www.the-little-things.net/…/exchange-the-state-of-external-client-access

  5. Greg Taylor [msft] says:

    @ UAG – because it's a choice. If you want the additional protection UAG offers, use UAG. If you don't feel you need it, don't.

    @ Wow – I just did a quick Bing search for "<insert vendor name> hardened attack" and found multiple blog posts and technical details describing how they are hardened against attack.

    @ Jetze – I certainly have invested time over the last few years writing documents on how to use TMG and UAG to protect Exchange, and the realization this post describes took me time to come to terms with too. I think TMG did an amazing job protecting Exchange, when it needed it. Some customers who still have it, still need it, and shouldn't rip it out, and that's my point to. It's a choice. An informed choice, not just a dumb 'put a firewall in front of it' situation any more.

  6. DavidJCarr says:

    @Greg I am sure the many questions you got at TechEd north America 2013 also prompted you to write this.

    I think we will deploy it since we were planning to before the decision to stop selling TMG was made. We will be testing TMG with Exchange Server 2013 and Lync 2013 in our lab.

  7. steve siyavaya says:

    @Greg – What's the word on service packs or updates fro TMG to fully support Exchange 2013 and future releases?  Some organisations I work with already have TMG deployed and are looking to go to 2013 – if the support isn't going to be available then it makes the ripping out decision for them.

  8. Greg Taylor [msft] says:

    Steve, there will be no more updates to TMG to add full 2013 support. TMG is no longer being actively developed, only supported.

    Publishing Exchange Server 2013 using TMG
    has some steps I wrote to help use it, but support really is best efforts, nothing more.

  9. Geo says:

    I've implemented ARR and it works nicely. Last time I looked Exchange wasn't supported behind ARR, but I can attest it works with all Exchange remote work loads (OWA, ECP, Outlook Anywhere, EWS and AS). I am looking to go to WAP when I get more cycles. Good write up and ARR! to all pirates all around the world. :)

  10. Greg, it would be interesting to know when Microsoft stopped using TMG in front of Exchange.  Was that prior to the Sept. 2012 announcement that TMG would not be continued?

    Knowing that Microsoft stopped using TMG at an earlier date would help make the point that TMG is unnecessary.

  11. vadimk01@yahoo.com says:

    Greg, you touch briefly on WAP, but what about Layer 7 application aware firewalls in general, something like Palo Alto's line?   I do think this article makes some very good points on general stances from a lot of security departments within large corporations.  

    However, sometimes you do need something to act for pre-authentication, SSL endpoint, IDS, etc… even if its not for purely technical reasons as trying a large corporation to change policies is a tough and time-consuming tasks which runs right against deadlines so it can be a more long-term goal.

  12. Rodrigo Andrade says:

    @Greg

    Fantastic point of view, Greg.

    There are too many reading this as a "must do" post, when it's actually about provide more information to, only then, call a decision.

    Moreover, it's – sadly – impressive how some "hard security lovers" can't think different then the recipe that is being spread over a decade. Security is based in models, and models gets old. Physics is here to support my point. However, we are still trying to prevent attackers on the old-school approach, meanwhile they are attacking us using new ways; and the only thing that we achieved was to make the authentic user to get struggling with "Access denied" (and variants) resultant of our effort.

    There's no short answer, no "only solution", no out-of-box (OOF TLA?) design to secure any infrastructure. There's only best practices, analysis, and new approaches (like the one purposed by you/o-365). There's no version of "forever secure". And, that's the "why" the attack surface can be increasing: We are very confident about the way we do security (the same way that it was being done, 10 years ago).

    Congrats!

    Rodrigo

  13. shawn says:

    I commented on Linkedin on this same discussion point, TMG/Exchange. I fully concur with Greg.

    The decision to deploy TMG depends on your business's security profile. At the end of the day its just not a requirement anymore and is entirely optional. For web services only 443 needs to be accessible which as you know Exchange accommodates for web service workloads as the traffic is encrypted.

    But if your InfoSec department mandates no direct connections from the internet then TMG considering you already have it deployed is an option. But deploying TMG simply for pre-auth and termination of web traffic in a DMZ, with the current version(s) of Exchange represents only anecdotal 'increases' in security at best. You could also view it as lessening your security as its represents an additional component in your Exchange deployment.

    These are only decisions that you can answer by talking to the relevant teams in your organisation responsible for these decisions. Personally though i think its time for InfoSecurity teams to start understanding the changing application layer landscape instead of repeating and implementing the same sage habits simply because it makes them feel warm and fuzzy about how 'secure' their environment is. As Exchange since Exchange 2003 has never required a reverse proxy.

    Building on the above i don't see the point in using IIS-ARR for Exchange either. For Lync a reverse proxy is a mandatory requirement for publishing web traffic for services such as mobility that have to connect via a RP. But whats the point of using IIS-ARR for Exchange when it adds no additional security nor inspection of web traffic to your deployment if securing web traffic is the goal.

  14. priitv@prfinance.com.au says:

    I understand that this is an Exchange blog so most of it here is about Exchange usage through TMG, however TMG itself was a more rounded product than just for Exchange protection, so keeping the product running is actually not up to the customers as much as it is up to MS allowing it to be kept running.

    For instance the Web Protection Service component on the TMG was only subscription based from the volume licensing.

    Now our subscription is running out this year and MS refuses to extend it and is telling us that if we do not stop using the product after the subscription runs out, we would be violating the license agreement, so we have no choice but to replace TMG with another product. I do not believe I am the only one on that boat, so it is easy to say that extended support continues, but if you did not extend your subscription before they announced the end of sale for the product you are not allowed to keep using it and can no longer extend the subscription to keep using it.

  15. Greg Taylor [msft] says:

    Thanks for the ongoing feedback, some responses to the questions raised;

    @Geo – Arr!

    @ Jeff – some years ago as it happens. Way before Sept 2012. But then, I'm not one of those people who believe that our customers should do what we do, necessarily. Too many times I get on calls with customers who want to know what we do, so they can just copy it. I ask them what their requirements and skills are, and then tell them what ours are. And they aren't the same. So why would you just copy what we do? Makes no sense.

    @ vkaydanov – the problem I have with any device or code that promises to tell you what makes 'good' Exchange traffic and 'bad' Exchange traffic, is they can only see so far into the packets, and we encrypt everything (unless you turn that off, which we don't suggest you do). So they become something of man-in-the-middle attack, put in place by security. And if they log that traffic, they are possibly capturing credentials too… so where does the line stop? Then, any time we change things, they break, as frankly there is no way for those devices to know what really constitutes good from bad, as we reserve the right to change it as we need to. We made our application understand what is good from bad traffic. It knows how to deal with invalid requests way better than anything you could put in front of it.

    @ Shawn – ARR – for those that require an endpoint in their old-skool DMZ. To reverse proxy, nothing more. If you only need that, that's all you need. If you need pre-auth, sorry, if the security people require pre-auth, you need something else.

    Thanks for all the other comments.

  16. Peter says:

    "account lockout policies are being used, something we’ve been advising against for years" – could you point us to where that is actually published?  All I can find are words of caution when specifying the actual lockout policies., not explicitly advising against it.

  17. Michel says:

    Well, the point of a DMZ is/was that IF something gets breached (yes, Software HAS security holes, even Exchange does…) that the attacker then does not have Access to your whole production LAN, but only to the DMZ part. And somehow this concept still makes sense to me

  18. mike says:

    Hi,

    Interesting article. My only comment is that you're actually trusting IIS which is the most hacked web service on the planet..?!!!

    Mike

  19. Marc K says:

    It is odd to see a car analogy in a Microsoft blog post considering the existence of the "If Microsoft Made Cars" joke.  

    I too would appreciate a link showing Microsoft recommending against account lockout policies.  I'm trying to figure out how I missed something important like this that you've "been telling people for years."

  20. jk-ak@outlook.com says:

    If you can convince my CEO not to use "hello" as his password, I'll get my "security guy" to agree with you…

  21. Pmeijden says:

    I'm wondering what to do with customers that require some kind of Two-Factor Authentication. I have a few customers who use OTP or other Radius token based authentication which I configured with TMG. Now with a new environment and Exchange Server 2013 what are my options on using Two-factor on OWA? or is UAG the only option?

  22. Freg says:

    At the end of my previous post I forgot to say that Microsoft, which in my opinion takes security more seriously than before, should consider developing a specific edge security service for Exchange,Lync and Sharepoint.

    The answer can't be UAG because it is a far more complex product than a reverse pre-auth proxy, it is designed for certain scenarios where the expensive cost and user CALs are justified.

  23. Freg says:

    So… Microsoft decided to discontinue TMG simply because they are confident that we don't need it anymore? I don't think so.. I have and I want to belive that Microsoft don't take security in this simplicistic way.

    I agree that security adds complexity and I agree that we have evidence that Microsoft in the last years wrote better code from a security perspective, but software can have bugs (for example: undisclosed 0days), Exchange and IIS too… these pieces of code aren't "bugs free" for sure.

    I bet I'm not the only one who heard of IIS remote code execution bugs in the last years.

    Yes, it is true that the modern client computer's mobility is virtually extending the network perimeter to the Internet, but this doesn't mean that we have to forget about the protection of exposed services in our security measures.

    I can think of multiple reasons why a reverse proxy in the DMZ is still needed these days, a few ones:

    – Pre-Auth can take out all reverse shells, automated attacks and casual attackers… I don't think that the protection from these kind of attacks can be seen as "very little extra" or "anything". Yes this can be seen as an insurance: a low-cost and effective insurance.

    – If the reverse proxy supports IDS/protocol analysis we can easily fight against direct shells or covert channels (protocol tunneling) too.

    – To add support for OTP/Two Factor Authentication, a lot of security can be added to the entire infrastructure if we don't require to type domain passwords when using public networks or devices.

    – To expose a different attack surface (different services) on the Internet, getting into a LAN server would require two different exploits.

    – blah.. blah…

    I can understand if Microsoft decided to leave this kind of business to other vendors/partners, I can live with this decision… end of the discussion. But please… don't tell us that Exchange and IIS are bullet proof and security measures are so "old school", if Microsoft really thinks that they can guarantee on the security of their products than why not create a "refund program" for all those customers hacked by using exploits?

  24. zumarek says:

    Security advice from company that does not support DMZ placement for CAS …

    Regardless of what you think (or feel) certain common sense applies. you shoukd never forward Internet traffic to your LAN based device/server.

  25. zumarek says:

    Greg FYI there are VPN engines that allow for granular access to LAN seriously …. they exist.

  26. Greg Taylor [msft] says:

    Excellent feedback and arguments. Love it.

    @ Peter (and others) – I Bing’d for “account lockout policies strong passphrase DoS”. The top link has a bunch of advice in this area. In fact, that Bing search turns up a lot of useful related links. Well worth a read.

    @ Michel – if the attacker is smart enough to break into the DMZ, and if all your reverse proxy is doing is poking a hole back to the LAN, and delegating (re-using creds), you will have an attacker inside your LAN very soon thereafter…

    @ Mike – yes, IIS is core. Not sure I agree it’s the most hacked web service on the planet, but let’s agree to disagree.

    @ Jabagi – Get him to use Hello123! Instead. Much stronger. I’m KIDDING.

    @ Pmeijden – Good reason for having something in front of Exchange, if those are your absolute requirements, then you might find UAG or something other solution can help. You could also consider using IPsec, and authenticating the machine as well as the user… http://www.microsoft.com/…/details.aspx

    @ Freg – TMG was not discontinued because Exchange didn’t need it any more. The reasoning is discussed here – blogs.technet.com/…/important-changes-to-forefront-product-roadmaps.aspx . No evolving code is bug free, I discussed the need for keeping security patches and updates installed too, it’s a complete package this security thing, not one single measure. Your other comments are fair, and considerations one must take into account when deciding where on the sliding scale of skills/insurance I drew, the company is. Some are at one end, some at the other. One size does not fit all.

    @ zumarek – Putting a domain joined CAS in a DMZ is not at all the same as allowing TCP443 all the way through. If the only window open from outside, through your router and load balancer is TCP443, that’s where your attacker is coming from (assuming he’s coming from outside… which likely, he isn’t). So you can watch for him. Great news that some VPN’s can provide granular access. It’s good to know it was acknowledged as a risk by at least one VPN vendor.

    Appreciating the feedback, and the discussion.

  27. anthonynz2000@hotmail.com says:

    Thanks for the great article, I wish I had read it last week,  but….

    Along the lines of what @Jetze said, there is a lot of online documentation which makes statements and recommendations for Exchange 2010.

    Like this whitepaper you co-authored http://www.microsoft.com/…/confirmation.aspx

    "Therefore it's critical to take measures to ensure that the data is being accessed securely, which means implementing technologies such as certificates, firewalls, enforcing pre-authentication, and device or endpoint validation."

    And in the Technet articles, which I coincidentally read all of earlier this week as we were removing TMG from the equation to make federated gateway work for calendar sharing, they all refer to securing Exchange and enforcing pre-authentication.

    Not one of them suggested a scenario where you would directly publish the server through your firewall.

    I think it's important that these other documents are updated to reflect the new philosophy before you drive all of your followers insane! or over the edge if they were already insane to begin with :)

  28. Lync says:

    Shouldn't this be true for your other products as well? Why does Lync insist on using a reverse proxy?

    blogs.technet.com/…/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

  29. MilanBanjac says:

    I feel that the problem with TMG discontinuation is somewhat a technical issue, and now we have the official view from MS about it. I am more worried about the general "discontinuation" policy for such infrastructure products as TMG.

    If a company builds its entire infrastructure around ISA and later TMG, it is pretty bad news to hear that the product is declared dead by the vendor.

    Also there is a feeling that we (customers) are being betrayed or fooled in believing that some of the products in the list of software we bought from Microsoft in the Enterprise agreement is being discontinued in the middle of our agreement. If we knew that TMG will be discontinued in 2011, we would think twice about including it in our Software Assurance.

    Who knows, maybe you will drop Exchange next year?

  30. codex@cenotaph.nl says:

    Excellent article and a great way to tell people how network security is shifting from just closing the front door to secure software. However, I do think the article should have been named “Exchange in a post tmg world, is it as scary as you think” because in many mid-size environments there is still plenty of poorly written code that suffers from SQL injections and other badly written code. In this case TMG is not so much making things more complex, it’s a way to be sure that all published applications use your predefined way of authentication or at least use SSL. And in that way, its making our lives more simple.

    CRM, document management, financial and other LOB applications are not always written by Microsoft and are not always updated by the vendor that much.

    Same counts for SSL offloading, SSO and other usefull things we use TMG for, I do think it’s still far from obsolete.

    Eventually, when moving to IPv6, maybe we will go back to the beginnings when all computers where using public ip’s without using NAT or a central firewall. If computers and software become intrincically secure, that will be the time when network architecture will become simple.

    So having exchange secure enough to make this step is a very good and important one indeed, but it is only a small part of the software that companies need to manage and secure.

  31. Greg Taylor [msft] says:

    @ Anthonynz – I wrote that paper you linked to three years ago. Three years. At the time I firmly believed it was the right thing to do (though I do remember a discussion with a senior person in the Exchange team at the time who was telling me I was wasting
    my time, even then). I have changed my perspective. I am not saying there is no need for any kind of firewall/protection, I am saying it is a choice.

    @ Lync – Lync states, in the post you linked to "Lync Server uses two websites to service its web requests, one for the internal network and one for the external network. The external website listens on port 4443, instead of on the standard port 443, thus
    requiring a reverse proxy to translate between the two". No-where do they say pre-auth is required. They need a reverse proxy for translation.

    @ Milan – just like the car analogy – just because we don’t sell it any more, doesn’t mean you can’t use it any more. If you built up around it, keep using it, it has support.

    @ Marco – You are right, it is Exchange in a post TMG world. Good point. I’ll also say, the whole Ipv6 idea, brilliant. In fact, this whole concept was something Steve Riley used to talk about. IPv6 and IPsec and throw away the firewall altogether.

    http://www.bing.com/search plenty of good links there.

  32. Cloud Cloud Cloud says:

    I can see a bigger picture here and I guess I'm not the only one. For me it looks like new OS and server products are not primarily developed for customers (like it used to be) but for Microsoft itself because they can run their services in the cloud. In the long run Microsoft's plan (IMO) is to get customers away from on-premises environments to the cloud a little by little. This TMG episode is just a small chapter in bigger story. Exchange team just has to explain something to the customers (It's just teams bad luck that TMG is primarily used for Exchange services). There may come a time when Exchange and many others products are available only in the cloud. I guess Microsoft has put so much effort and money to the cloud business that they forgot partners and customers. Or even worse, they don't even care. But hey – it's only me and I really hope I am wrong with all this.

  33. Thomas Poett (MVP Lync) says:

    @Lync and @Greg

    well Lync brought to the point, and finally, I can agree with your article. If we see how Lync Setup for the external WebServies is required, we see (No Authentication, but Client may authenticate directly).

    This is exactly what Greg refers to Exchange, so I need to ask everyone how wants TMG in front of Exchange, "why do you propose 2 different solution to a customer?", this is not logic.

    So no since TMG is out of the picture, its clear what we need to do!

    Btw, regarding a non authenticating RevProxy, there are hundreds of other solutions outside. I know this, since for Lync, I designed the right publishing way and user access.

    I personally believe now, we are back on track and have the same solution for Lync and Exchange in case for pre-authentication.

    Thanks Greg putting this clear.  

  34. zumarek says:

    Q. Greg what us your security guy has to say about this blogs.technet.com/…/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx

    I personally think one of the better blogs from MS. Thank you Scott.

  35. saigon says:

    @Cloud Cloud Cloud

    I think that you are 100% right!!

  36. Ari says:

    @Lync and @Greg – Pre Auth is not required for Lync (nor it is supported).  However supportability mandates a reverse proxy is required for scenarios requiring external access whereby a simple NAT/PAT on the firewall (443->4443) works although it is not officially supported by Microsoft.

    I complete agreed with Greg PoV that the product should be secure by design and a reverse proxy add little to no value when there is no pre auth.

  37. Petri X says:

    You have no TMG and no Edge for Exchange (on the new deployments) and you are asking "…is it scary…"  ;-)

    Some of the comments says that reverse proxy with pre-auth is only thing matters, but personally I feel we should not forget the URL filtering either. And this fits for Exchange and Lync. I don't want to let all kinds script guys to knocking our servers just like that.

  38. TDR says:

    "@ Mike – yes, IIS is core. Not sure I agree it’s the most hacked web service on the planet, but let’s agree to disagree."

    It isn't by a long way. That would be Linux based web servers: http://www.zone-h.org/…/4737

    Even adjusted for market share, you are several times more likely to be hacked running Linux than Windows as an internet facing server.

  39. Gary says:

    Probably not the place to ask this but does the same confidence in product quality apply to Sharepoint?

  40. luca.bandinelli@live.com says:

    @Gary: SharePoint doesn't require pre-authentication either leaving the authentication piece to AD (in case of Windows Auth), delegating it to your preferred IP-STS (in case of SAML) or your custom provider in case of FBA. SharePoint used to use UAG (not TMG) in case of Windows auth when you want to host an FBA form outside from the corporate network and have UAG authenticating the user on its behalf (using Kerberos Constraint Delegation) and / or for 2fact auth scenarios.

Comments are closed.