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…  

15 comments:

  1. Well written, and this is the question that all IT professional have in their mind.

    -Ashish

    ReplyDelete
  2. great article Jason - good to see you feel the same as i do my friend

    ReplyDelete
  3. Hi Jason,

    it´s interesting to see what broad view is necessary today to get the big picture and the evolution of M$ products to well integrated and orchestrated solutions leveraging a broad range of key services and technologies ...

    Very well written !

    rgds,
    AgentSmith73

    ReplyDelete
  4. Couldn't agree more. What was learned with UAG transfers to WS2012 very well and lets you pick up the new tech very quickly.

    ReplyDelete
  5. No one has wasted there time,if anything we will be the super stars. 2012 DirectAccess has simplified the process so much that when it goes wrong the average Technician doesnt know what to do.
    Also a bigger point I would like to show is that like you said people are not instantly going to more to Windows 8 / 2012 so the use of UAG is still growing.
    Also there has been a small boom in people using mydanat to get Teredo tunnels to work behind nats which may be why people are not concerned about moving to 2012 as it renders no advantage at this point as the connections are faster than 2012's connections when people are behind nat's. Just another thing to remember.

    ReplyDelete
  6. Jason:

    I have a customer that has a problem with implementing UAG 2010 DirectAccess Server on their DMZ since the DA server must be a domain member. They do have Microsoft ISA and TMG servers in the DMZ but they're not joined to the domain. I started going down the route of suggesting Win2012 DA since the DA server would be internal with no external public ip address but as far as I know Win2012 DA server also needs to be a domain member. I thought since one of their prerequistes was to enable force tunneling that they may be open to shunting that 443 traffic from the DA CLients to the DA server may be an acceptable solution.

    I'm looking for a way to implement either UAG-DA 2010 or Win Server 2012 URA DA so something will be in the middle or proxy the exteral DA client's authentication to the DA server. They currently have the following in their DMZ: Cisco ACS, Microsoft TMG, and Microsoft ISA. They want any authentication to "terminate" in the DMZ and if possible any AD lookups to be LDAP. I think it may be defeating the intended purpose of the DA solution but I know I'm going to have this issue with other customers and I'm not sure how to handle it. Any solutions you're aware of? I appreciate all the helpful solutions I've found on your blog in the past.

    Sincerely,
    Dan

    ReplyDelete
  7. Hi Dan,

    I am not aware of any solution for UAG DA or Win2k12 DA that supports a workgroup mode deployment.

    In terms of isolation, you could put the DA servers into their own forest, but you would still need two-way forest trusts to the forest that contains user and computer accounts. However, this is unlikely to that well received.

    With a dual NIC setup, I don't see domain membership as an inherent security risk, just like I never saw ISA/TMG as a domain member being a security risk as discussed here: http://www.isaserver.org/tutorials/debunking-myth-that-isa-firewall-should-not-domain-member.html

    Placing the DA servers between two perimeter/DMZ networks is the usual good practice and only allowing domain member communications to flow via the internal firewall. Traffic from client to DA is then controlled by the external firewall and traffic from the DA server to the corp network is then controlled by the internal firewall. In terms of authentication, this is much more complicated than something like TMG LDAP auth as DirectAccess relies on NLTM, Kerberos and certificate authentication which cannot be met without domain membership to my knowledge.

    Hope that helps (a bit!)

    Cheers

    JJ

    ReplyDelete
    Replies
    1. Thanks for the reply. Everything you said makes sense and the information in the link drove it home as well. I think this DA solution is a real paradigm shift and will take some convincing of security teams to warm up to it. I think it has a lot of merit to replace the necessity for a vpn solution. Particularly from the business end user and the I.T. support staff. While I need to think it through some more, I believe DA may be arguably even stronger that a separate vpn solution given the information in the link you provided as well as the use of smart cards, certificates (both public and internal CA certificates), NAP, HRA, and the enhanced security as a part of domain membership over workgroup member (kerberos, AES, etc). Please let me know if you have any other information to pile onto that argument in order to replace vpn solutions and evangelize the opportunity of seemless, secure connectivity.

      Also would you mind taking a looking at the reghacks at the bottom of the link provide below. While I think vpn clients defeat the intended purpose of DA, I'd like to look into the pluses and minues if it is indeed an alternative to help alleviate the security teams concerns. The link below has information related planning DA's and 3rd party VPN clients? I'd like know what VPN clients or solutions their referring to or maybe you might be able to point me in the direction of someone who might know which or how to use a 3rd party vpn client with DA. Also, if you have any information regarding DA's posture in relation to Sarbanes-Oxley, PCI and HIPPA compliance I would be more grateful and think that would help to "drive a stake in the heart" of any security concerns. Thanks Again for your thoughtful help. Sincerely, Dan Crew
      http://technet.microsoft.com/en-us/library/jj134232.aspx

      Delete
    2. With reference to 3rd party VPN clients, you will need to test them with DA to see if they need the registry changes. Essentially, when the 3rd party VPN connects it is important that DirectAccess is disabled by way of the VPN client being able to access the NLS server. The registry changes enable the client to detect the presence of the NLS server when the VPN client "connects" which will in turn disable DA. Not all VPN clients trigger the detection mechanism when they connect...

      Delete
    3. P.S. Some people like to keep a 3rd party VPN client as a fallback method or provide the user with both VPN/DA options during a coexistence migration - hence the potential need for the regkeys to ensure the VPN "connect" is in line with DA location detection...

      Delete
    4. P.P.S this old UAG DA link may be of use too: http://technet.microsoft.com/en-us/library/ee809093.aspx

      Delete
  8. Unified access gateway is a great way to extending company network to users when they are outside of the office. I read your post and your really written very well. Thanks for sharing UAG information.Keep Posting.

    ReplyDelete