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

Friday, 1 April 2011

UAG DirectAccess: Useful NETSH Commands

During UAG DirectAccess deployments, I will use several netsh commands as part of the initial deployment testing from a DirectAccess client. In the event of problems, this will often include include the use of additional advanced netsh commands which are more troubleshooting focused. After seeing these commands, many customers often ask for a list of the most useful ones that they can learn to assess and troubleshoot problems at the DirectAccess client. Consequently, I thought this might be something useful to document in a short blog post. The netsh tool is immensely powerful, but hopefully the following commands provide a good starting point to assess, understand and troubleshoot the DirectAccess client.

DirectAccess Client: Settings and Status

Useful Command: netsh dns show state

Description: This is probably the first and most useful command you will run, as it provides essential information on the current DirectAccess status and general configuration state.

Useful Command: netsh namespace show policy

Description: This command is used to display the Name Resolution Policy Table (NRPT) that has been defined within Group Policy.

Useful Command: netsh namespace show effectivepolicy

Description: This command is similar to the previous command but outputs the actual NRPT entries that are currently active on the DirectAccess client.

DirectAccess Client: Common Transition Technology Interfaces

Useful Command: netsh interface teredo show state

Description: This command shows the current status of the Teredo interface, if used at that time.

Useful Command: netsh interface httpstunnel show interfaces

Description: This command shows the current status of the IP-HTTPS interface, if used at that time.

DirectAccess Client: Windows Firewall Settings and Status

Useful Command: netsh advfirewall monitor show firewall

Description: This command is used to show the current status and configuration state of the local Windows Firewall.

Useful Command: netsh advfirewall show currentprofile

Description: This command is used to show the current Windows Firewall profile that is in use.

Useful Command: netsh advfirewall monitor show mmsa

Description: This command is used to show the current status of the Windows Firewall main mode security associations that are present when the DirectAccess infrastructure and intranet IPsec tunnels are active.

Useful Command: netsh advfirewall monitor show consec

Description: This command is used to show the current status of the Windows Firewall connection security rules which are used to define the DirectAccess infrastructure and intranet IPsec tunnels.

Please Note: The commands above have been shown in their verbose form for clarity, however many of the netsh parameter can actually be abbreviated for brevity. For example the ‘interface’ parameter is often actually entered as simply ‘int’.

To see these commands in action for both intranet and Internet scenarios, along with their respective outputs, I recommend you test drive the UAG DirectAccess Troubleshooting Test Lab Guide (TLG) available here.

Preparing an IPv6 Addressing Plan

For those looking at learning a little about IPv6 and guidance on addressing in the new 128bit world, SURFnet have written a useful document that is well worth reading. You can download an English translated PDF version (thanks to RIPE) titled Preparing an IPv6 Addressing Plan: Manual from here with more details also available here.


For a more in-depth learning experience and more detailed guidance, I would highly recommend the Understanding IPv6, Second Edition book written by Joe Davies (aka Cable Guy) as discussed here.