Thursday, 7 April 2011

UAG DirectAccess: A More Enjoyable Deployment Experience!

Having just finished a UAG DirectAccess proof of concept (POC) project for a long-standing customer, I am feeling rather upbeat. As a security guy, I often find myself with a relatively negative mind-set as I am often helping customers deploy Microsoft-based solutions to mitigate risk or reduce the potential exposure to security breaches or incidents.

Since working with customers on deploying UAG DirectAccess solutions, this is a much more enjoyable deployment experience and an altogether more positive mind-set compared to something like a server hardening project. This is because although DirectAccess is seen as a secure remote access solution, it is also seen as an business ‘enabler’ rather than a more traditional business ‘blocker’ that security deployments are often tainted with. Consequently, customers have a much more positive reaction which borders on ‘IT enjoyment’. It is also really interesting to see the ‘virtual cogs’ in their heads begin to turn when they see how DirectAccess will change their working environment and also the usability, productivity and manageability of the users that they support. Out of all the reactions, the shear transparency of DirectAccess seems to one of the remaining highlights for most people. However, it sometimes feels a bit deflating after a fair bit of hard “techie work” to hear them utter “Is that it?" or “That was easy!” when they see it working for the first time. There is no doubt that UAG DirectAccess is not quite so easy for the IT guy in terms of troubleshooting and support (or setup either, but at least I can help them out there). There is also the instant dependency that users will place upon the service with comments like “What, you want DirectAccess downtime? But I use it all the time!”

So what does a UAG DirectAccess POC involve? Well, it is very dependent upon the customer requirements of course, but I thought it might be interesting to provide a high-level overview of how I approached this recent POC and what was involved along the way…

First Day – Introduction to DirectAccess and Preparation of the Core Infrastructure Components

I always start a UAG DirectAccess POC with an overview of how DirectAccess works. This usually involves a very messy diagram (well, it’s messy when I am finished!) and a lot of technical tangents and a few bemused looks as the UAG DirectAccess pieces of the puzzle are laid bare, warts and all. Of all concepts discussed, I think IPv6 is probably the one that pushes most people out of their usual techie comfort zone; closely followed by PKI and certificates.

To fully understand DirectAccess, you need to a good grasp on various technologies; two of which are mentioned above. Luckily, most of these dependencies and prerequisite skills fall nicely within my general skillset from the last 15 years of working on Microsoft-based infrastructure security projects. Understanding IPv6 was probably my most challenging area whilst learning DirectAccess. I am certainly no IPv6 guru, by any means, but my netsh repertoire is improving and the fundamentals are starting to stick.

So, as part of preparing the infrastructure, I usually follow the high-level items detailed in my previous blog posts here or here. In this POC instance, the NLS web site would be hosted on a new VMware virtual machine and an existing Enterprise CA was able to provide the necessary certificates (although not as strictly configured to meet best practice as I would have liked).

With the NLS web site ready and PKI validated, we then begun installing and configuring a baseline UAG deployment before running the actual UAG DirectAccess Wizards. In this particular POC, the customer was using a Celestix WSA appliance which greatly reduces deployment time and makes my life a little easier. After whizzing through the Celestix quick start wizards, and the usual UAG Getting Started Wizard, we could then begin looking at enabling the DirectAccess features. The last thing to do was to issue a GlobalSign SSL certificate which would be used for the IP-HTTPS listener. It may be interesting to note that I always recommend using a certificate from a public CA for this role to simplify potential CRL publishing complications, and offload the responsibility of maintaining the CRLs to someone else.

However, time to call it a day I think… 

Second Day – A Working DirectAccess Client and Begin Basic Functionality and Application Testing

With the UAG server in place, we begun configuring DirectAccess using the in-built UAG wizards. Most of the decisions for the wizard were decided on the first day or were reviewed on the fly, with a little explanation along the way, to assist the decision making process. For this particular customer, they were using the same internal Active Directory DNS domain name as their external Internet DNS domain name. This adds some additional complication to the deployment, by way of needing to add NRPT exemptions in Step 4 of the UAG DirectAccess Wizard. This ensures that connections to Internet facing services would resolve using Internet DNS servers and not the DNS64 component of UAG. More information on this particular issue can be found here under the Split-brain DNS section and also here for UAG SP1.

With everything configured, we then used the Web Monitor to assess the health of the DirectAccess server roles. This gives us some confidence that server roles are good to go before even attempting to connect from a DirectAccess client.

The netsh commands described in this recent blog post usually provide a good sanity check that DirectAccess is enabled, configured and connecting, but I often supplement these with some “proper” testing like accessing file servers or intranet web servers. Be careful here that these servers are not accessible via the infrastructure tunnel, as this will not fully test that you have intranet tunnel access.

Testing produced the required results and things were going to plan. 

Please Note: Be careful when using PING and NSLOOKUP to test DirectAccess connectivity as discussed here.

In addition to manual testing, now was a good time to install the DirectAccess Connectivity Assistant (DCA), which is included as part of UAG SP1, on the test DirectAccess client. The GPO settings for DCA are now configured using the UAG DirectAccess wizard in UAG SP1, which makes life a little easier. The DCA reported DirectAccess connectivity is working so things were looking good!

So, with a working DirectAccess client, we can now begin performing some application compatibility testing to ensure core business applications function across the DirectAccess tunnels. It is not really possible to predict what applications may be used by a customer that are not compatible, so this stage of the POC is critical in order to achieve a successful outcome. I started a list of DirectAccess application compatibility in this blog post which defines some common known issues with possible mitigation techniques. However, in reality the customer just needs to test their core business applications using the new DirectAccess connection to determine if applications will work natively, or may require mitigation solutions or workarounds. The key requirement here is application support/awareness for IPv6 as discussed in more detail here.

After some initial testing, it was clear that some of the legacy LOB applications in use by this particular customer were going to be troublesome, so we would need to think about mitigation techniques for these. Other core corporate applications like email, web-based applications and file shares were all looking good.  

However, time to call it a day I think…

Third Day – Mitigation Techniques, Advanced Features and Tying Up Loose Ends

In my experience, the next day is often a “show and tell” and general Q&A day. Most folks are now familiar with the core concepts and begin exposing the solution to IT peers and other potential pilot users. This will often raise many additional questions, normally leading to testing new scenarios or applications that suddenly require consideration.

The third day will also often include the addition of some form of advanced feature or configuration extension; examples include:

  • Enabling Network Access Protection (NAP)
  • Enabling two-factor authentication using Smartcard or OTP
  • Adding a UAG portal to host the Secure Sockets Tunnelling Protocol (SSTP) Remote Network Access application which can be used as a DirectAccess fall back or mitigation solution.
  • Integration with an existing remote session technology like Citrix or Remote Desktop Services to provide a seamless mitigation solution (unlike SSTP) for specific applications.

The original expectation for this POC would be to move onto implementing two-factor authentication for DirectAccess at this point, however as it turns out, the deployment of an internal Citrix Secure Gateway for application compatibility mitigation was actually a higher priority at that stage.

For this particular POC, most of this day was then used to deploy and integrate an internal Citrix Secure Gateway solution for application compatibility mitigation, talk about the user impact of adding two-factor authentication to the solution (Smartcard or OTP via RSA) and also focusing on testing the remote management feature of DirectAccess clients (aka Manage Out).

We decided to call it a day at this point as we had a pretty usable deployment and more time would need to be spent on application testing and more internal “show and tell” stuff which they didn’t need me for…

So, that’s the anatomy of one particular UAG DirectAccess POC with a pretty standard deployment and some interesting, albeit common, challenges. This particular engagement involved three days; sometimes I get things done quicker and other times it can take longer, especially if the UAG portal features are also required or additional prerequisite work is required (like PKI setup).

Am I a geek for enjoying this stuff? Probably. Am I passionate about the technology? Definitely. Do I love DirectAccess? Of course!

If you need help understanding/designing UAG DirectAccess deployments, or just want help with your own UAG DirectAccess POC, you know who to call… Winking smile

2 comments:

  1. Jason,
    You mention that “For this particular customer, they were using the same internal Active Directory DNS domain name as their external Internet DNS domain name. This adds some additional complication to the deployment, by way of needing to add NRPT exemptions in Step 4 of the UAG DirectAccess Wizard” This caught me by surprise a bit, and was hoping you could clarify something.

    Historically there have always been two approaches to internal namespaces; 1.) A non registered “company.lan” address that is isolated to the internal domain only. or 2.) A shared namespace - perhaps a subdomain representing the companyname - e.g. “internaldomain.mycompany.com” With the advent of Direct Access, (and even access federation issues with BPOS, etc.) in an ideal world, would you now used that shared namespace for the most problem-free arrangement? What are your thoughts?

    I’ve always preferred the separate non registered name, but with the new technologies coming along, am beginning to rethink if that is the best way to move forward. I have an internal domain name that is not in the shared namespace of our company, and even worse, it has a legacy company name internally, that of which we no longer own. So if I want want to go through a domain rename, I’d prefer to only do it once. :-)

    ReplyDelete
  2. Hi Pete,

    When you define the DNS suffix using the DA wizard, you are defining the entry in the NRPT such that all requests for {something}.DNS-suffix will be sent to the DirectAccess IPv6 address and the DNS64 service.

    If the same DNS suffix is used both internally and externally that means that requests like www.DNS-suffix will be resolved using the UAG DNS64 service, as opposed to the resolving that name using an Internet DNS service.

    This may not be a problem, but usually there are services that you will want to access directly using these DNS suffix names because they are offering Internet services for your environment and dont require a DirectAccess connection. A good example here is something like Micrsoft OCS or Lync edge servers.

    In order to solve this problem, you can create NRPT exemptions but this adds a little overhead and you need to define and maintain these exemptions for the current and future needs.

    By having an intranet DNS suffix that is completely different, or a sub-domain, this make the NRPT table much simpler and negates the need to create exemptions.

    Perosnally, I dont like TLD names like .local and .lan and would always recommend customers use a sub-domain for the AD domain name where possible (your second example).

    This approach makes the NRPT pretty simply and clearly separates name resolution for DA and non-DA connections.

    Hope this helps.

    Cheers

    JJ

    ReplyDelete