Thursday, 13 September 2012

Initial Considerations for Migrating from Forefront TMG to Forefront UAG

Give the recent Microsoft announcement notifying customers that Forefront TMG is being discontinued, as discussed in my previous blog post, it is likely that many customers will consider migrating to Forefront UAG in order to provide publishing services that protect Microsoft server workloads like Exchange, SharePoint and Lync.

Therefore, given the recent news, I thought it might be useful to highlight a previous comparison of Forefront TMG and Forefront UAG to help identify some of the benefits of shifting solutions, but more importantly also highlight areas of Forefront TMG that cannot be satisfied by Forefront UAG at this time. The importance of the benefits and limitations are going to be very specific to individual needs, therefore a breakdown will undoubtedly be useful as part of the initial “What next?” thought process.

In my mind, one of the best comparisons was provided by Tom at the following location:

Choosing Between Forefront TMG or Forefront UAG for Publishing Scenarios

Please Note: It should noted that this article was written in April 2011 and Forefront UAG is now at Service Pack 2 level, which introduced several improvements as discussed here. Therefore, these should also be considered.

I really wish I had written that article (but I didn't!) so the best I can do is highlight its existence and potential value as people consider their options in light of the recent announcement. It is factual, concise, easy to consume and therefore a great reference at this time.

UPDATE: If you are considering using Forefront UAG as a replacement for Forefront TMG, you should review in detail the supported scenarios discussed here and also specific considerations for Lync as highlighted here.

Unfortunately, for customers using Forefront TMG for caching, secure web gateway, and firewall scenarios, there is no Microsoft equivalent that can be migrated to at the end of this support period. No doubt it would be very useful if a similar comparison table could be created to compare Forefront TMG against other vendor solution like Bluecoat, Cisco, Juniper, Fortinet and Websense – at this time, I’m not sure if that exists unfortunately…so the “What next?” question is a little harder to answer at this time if you use Forefront TMG in one of the above outbound scenarios. The original Microsoft mantra of Forefront TMG for outbound and Forefront UAG inbound is sadly no longer viable.

Additional notable references for TMG vs. UAG include:

Wednesday, 12 September 2012

Important Changes to the Microsoft Forefront Product Roadmap

Microsoft has recently announced publically the future roadmap for various Forefront products which can be found here: Important Changes to Forefront Roadmaps 

So, with a focus on Forefront TMG and Forefront UAG for this post, we can summarise the public announcement as follows:

Forefront TMG

  • There will be no further releases of the Forefront TMG product (or service packs).
  • Forefront TMG mainstream support will end on April 14, 2015 and extended support will end April 14, 2020.
  • Forefront TMG Web Protection Services (WPS) subscriptions will continue to be supported until December 31, 2015.
  • As of December 1, 2012, Forefront TMG will be removed from the price list and will not be available for purchase.
  • For customers using Forefront TMG for caching, secure web gateway, and firewall scenarios, there is no Microsoft equivalent that can be migrated to at the end of the extended support period.
  • Most web publishing scenarios that are supported by TMG can be published by UAG, including SharePoint and Exchange. In addition, UAG provides many additional publishing scenarios with federated authentication and granular authorisation policies.
  • VPN capabilities previously provided by Forefront TMG can be provided by the Unified Remote Access (URA) features of Windows Server 2012 (or UAG for SSL VPN).

Forefront UAG

  • There is no change to the UAG roadmap.UAG continues to be actively developed as seen by the recent release of UAG Service Pack 2 in August 2012.

So finally, we have an answer on the future of Forefront TMG and Forefront UAG products. In many ways it is a great shame to see such a well engineered, community supported and customer admired product like Forefront TMG finally laid to rest, but I guess things move on unfortunately. It will be interesting to see how UAG continues to be actively developed over time. If you haven’t looked at Forefront UAG, it may be worth brushing up your skills (or consultancy relationships) if you currently use Forefront TMG for reverse proxy or remote access scenarios. End of an era…you betcha!

Friday, 7 September 2012

So, Did I Waste My Time Learning UAG DirectAccess???

When I first heard that the feature set provided by UAG DirectAccess was going to be provided natively in Windows Server 2012 (as discussed in my recent blog post here) I wondered how much of my UAG DirectAccess knowledge would still be applicable to the Windows Server 2012 DirectAccess server role and how much ‘new stuff’ I would have to learn. Over the years, I have spent quite a lot of time and effort learning new technologies only to a find a few years later that technology moves on and those skills become side-lined by something newer. Hence I have got quite used to assessing reusable skills and resetting skill priorities. A good example here is the years I spent as a Novell Master CNE; I certainly haven’t used those skills for quite some time now! Smile

Given that many larger Enterprises are only just rolling out Windows 7, let alone Windows 8, and/or require advanced security features like two-factor authentication/multi-site/NAP it will not be possible for them to take advantage of the new single IPsec tunnel model with the Kerberos proxy. Hence, the traditional two IPsec tunnel solution used by UAG DirectAccess will still be used even with Windows Server 2012 deployments.

Understanding these IPsec tunnels, how they are established, how they are authenticated, and how to troubleshoot why they fail to establish, are all going to be pretty familiar ground for those that have been in the trenches with UAG DirectAccess at some point. So, is this knowledge still relevant? You betcha!

Then there’s IPv6; yes, you don't need to understand it with UAG DirectAccess, but it sure makes things a lot easier to if you get the basics. Even though Windows Server 2012 now natively supports NAT64/DNS64, first seen in UAG DirectAccess, all communication between the DirectAccess client and the DirectAccess server still occurs over IPv6. Management of DirectAccess clients from the intranet (historically termed ‘manage out’) still requires intranet IPv6 capability (via ISATAP or native IPv6) in order to function. So, is this knowledge still relevant? You betcha!

Then there’s PKI; yes, PKI may no longer be mandatory with Windows Server 2012 DirectAccess, but in order to achieve this simplification you need to have Windows 8 clients and/or have no interest in the advanced security features like two-factor authentication/multi-site/NAP which rely upon IPsec tunnels that utilise certificate-based authentication. In reality, a PKI solution is still required  for a large proportion of enterprise deployments; it’s just the smaller organisations whose life is made a little easier. To be honest, I think this was the exact design goal as most smaller organisations may not already have PKI solutions in-place or don’t have IT staff with the appropriate PKI skills to implement/manage one. So, is this knowledge still relevant? You betcha!

Please Note: Given the increasing dependency on certificates and PKI in many areas of IT nowadays, I would strongly advise this is a skill you add to your knowledge utility belt anyhow; not just as part of learning DirectAccess.

Then there’s all those lovely netsh commands you have memorised off by heart when troubleshooting the client-side of UAG DirectAccess; So, is this knowledge still relevant? You betcha!

Having spent some time with Windows Server 2012 DirectAccess now, I am pleased to report that a lot of the skills learnt from deploying and troubleshooting UAG DirectAccess are still very much relevant and applicable to the evolutionary new kid on the block. As UAG DirectAccess was never really a product per se, but more a collection of complementary technologies working together to produce a great user experience, there is a fair chance that some of these technologies are not just applicable to DirectAccess, but also more generic in nature (e.g. good to know anyhow). I was in a pretty good place as I already had skills in many of the components, like PKI and IPsec, I just needed to align my knowledge with an understanding of how UAG DirectAccess was engineered to use them. However, more familiarity with IPv6 and a better netsh vocabulary will no doubt be beneficial to me in future times.

If you learned UAG DirectAccess from the ground up and had never really used PKI, IPsec tunnels, Group Policy, IPv6 etc. then all of those skills are still very relevant, even if you learned them with a specific UAG DirectAccess bias.

So, depending upon your Windows client version and your desire for advanced DirectAccess security features there is a very strong likelihood that skills learnt from UAG DirectAccess will still be very much relevant to Windows Server 2012 DirectAccess. Sure, there are new things to learn with Windows Server 2012, coupled with a few prerequisites you may be able to worry less about. However, even if you only ever deploy Windows Server 2012 DirectAccess for smaller organisations with Windows 8 clients, and never get asked about managing DirectAccess clients from intranet management clients/servers, I think you will be glad that you learnt a little bit about PKI and IPv6 whilst learning UAG DirectAccess. If anything, these skills are going to become increasingly useful in your day job, especially if you work with other Microsoft products or get involved in security-related projects. 

So, to conclude my original question, did I waste my time learning UAG DirectAccess? No, not at all; I’m actually kind of glad I did. Given the potential of Windows Server 2012 DirectAccess I see this becoming an increasingly popular remote access solution for Microsoft-based customers and environments; it’s easily one of the highlights of the Windows Server 2012 release along with other security headliners like Dynamic Access Control and Server Core flexibility. Interesting times…