Enabling new columns in Remote Access Management Console | Remote Client Status

I recently helped a customer roll out DirectAccess on a couple of load balanced Server 2012 boxes. It is pretty common to get some questions after we finish installing, but I was asked something that (surprisingly) I haven’t ever been asked before. Specifically, his question was “When I am viewing the currently connected DirectAccess computers inside the Remote Access Management Console, how can I see what DirectAccess server they are connecting through without having to go into the details of each connection?”

“There’s a column right in there that shows you” was my response. But indeed, there was not. I checked some of my own servers, and sure enough there was a Server column right there where I could identify and even sort the connections by which node they were connecting through. But this column was not showing up in his console. Then we checked his other server, and the Server field was visible on that one! But still not on the first DirectAccess server.

It seems like we poked and prodded around every inch of the interface, but couldn’t find a menu that let us choose which columns were visible and which were not. Then just as I hung up the phone with him (isn’t that how it always happens?), I accidentally clicked on it. All you have to do is right-click on one of the Titles of the existing columns, and you see a list of available columns to select or de-select. The important part is that you must right-click on the name (right on the text) of one of the columns that is already being shown. Right-clicking anywhere else in the Console will not get you this selection.

Server

So there was our answer. We simply checked the Server box in this list, and the new column was immediately available for viewing and helping us to manipulate the data as needed. Sometimes the simplest options are the hardest to find!

Jordan Krause
Microsoft MVP | Enterprise Security
jordan.krause@ivonetworks.com

Forefront TMG SP2 Rollup 5 available for download

Hotfix Rollup 5 for Microsoft Forefront TMG SP2 was recently released, and can be downloaded here:

https://support.microsoft.com/kb/2954173

This rollup includes the following hotfixes:

2963805 – Account lockout alerts are not logged after you install Rollup 4 for TMG 2010 SP2

2963811 – The TMG Firewall service (wspsrv.exe) may crash when the DiffServ filter is enabled

2963823 – “1413 Invalid Index” after you enable cookie sharing across array members

3963834 – HTTPS traffic may not be inspected when a user accesses a site

2967726 – New connections are not accepted on a specific web proxy or web listener in Threat Management Gateway 2010

2965004 – EnableSharedCookie option doesn’t work if the Forefront TMG service runs under a specific account

2932469 – An incorrect value is used for IPsec Main Mode key lifetime in Threat Management Gateway 2010

2966284 – A zero value is always returned when an average counter of the “Forefront TMG Web Proxy” object is queried from the .NET Framework

2967763 – The “Const SE_VPS_VALUE = 2″ setting does not work for users if the UPN is not associated with a real domain

2973749 – HTTP Connectivity verifiers return unexpected failures in TMG 2010

 

Can’t disable the NRPT? New hotfix available for Windows 8.x clients

When running through the DirectAccess configuration wizards, a handy option that is often chosen by DA admins is “Allow DirectAccess clients to use local name resolution”. You can see this option on the screen where you configure settings for your Network Connectivity Assistant (NCA), inside Step 1. When enabled, this setting allows a DirectAccess user to click on their DirectAccess network connection from the systray, and choose “Disconnect”.

What this Disconnect button really does is temporarily disable the NRPT. This stops DNS requests from attempting to flow over the DirectAccess tunnels, and instead places those DNS requests on the locally configured DNS server of the user’s current network connection.

The problem with this Disconnect button is that it only shows up once the NCA tool has successfully “Connected”. So if NCA never goes to a Connected status, the Disconnect button is not available. One scenario where this will cause grief is when users are inside the corporate network, and there is something wrong with the NLS website. If you have a problem with NLS, it can cause all kinds of name resolution problems for your DirectAccess client computers which are inside your network. A nice workaround to this problem, until you fix the NLS of course, is to have everyone click on their Disconnect button. But wait, since there is a problem with NLS, DirectAccess tunnels are trying to build but never can, so your NCA tool in the systray continually says “Connecting” instead of flipping over to “Connected”. Since we are stuck on Connecting, the Disconnect button is not available to click on. So even if you have the option selected where users should be able to turn off the NRPT and resolve their DNS name resolution issues, the button will not be available to them.

The good news is that this bug in the NCA has now been resolved, courtesy of the following hotfix: http://support.microsoft.com/kb/2953212/en-us

Simply install this hotfix on your Windows 8 and Windows 8.1 clients, and should you have the unfortunate event of your NLS website going down, you can at least get folks inside the network back to work by being able to temporarily Disconnect the NRPT.

Server 2012 DirectAccess – Hotfix available for Remote Access Management Console memory leak

For anyone running DirectAccess that is based on Server 2012, you probably know that your Remote Access Management Console has the nice feature of showing you what users and computers are currently connected, and even what resources they are touching. This is a very nice feature, but there has recently been a problem discovered with this part of the console, that it continues to hold onto this information until the service is restarted. Microsoft has released a hotfix to be installed on the DirectAccess server to resolve this Remote Access Management Console memory leak:

http://support.microsoft.com/kb/2895930/en-us

DirectAccess Client Troubleshooting Tool

Microsoft has recently released an interesting new tool for DirectAccess admins. The DirectAccess Client Troubleshooting Tool is a small, easy to use utility that can help diagnose DirectAccess connections gone wrong. Development is still happening on this tool, so expect more versions, but it’s a nice way to run a quick check on the status of DA components on a client machine, especially if you aren’t yet familiar with browsing through the log files.

You can run the DA Troubleshooting Tool on Windows 7, 8 or 8.1 – and you don’t even have to install it! Just download and run, and as long as you’ve got .NET 4, you’re in business.

The existence of this tool certainly doesn’t mean that you can spend your DirectAccess administration career without understanding the real log files, but it can give a nice summary. Also keep in mind that this initial version isn’t perfect, I expect they will be making some changes to help the tool accommodate better for things like a DirectAccess computer being inside the corporate network, or for a DA environment that makes use of OTP.

UAG SP4 is available for download

Microsoft has released SP4 for UAG! I know there are plenty of people out there who have been waiting for this one, as it incorporates support for Windows 8.1 clients, and the Internet Explorer 11 browser. You can also now make use of the built-in Mail app in Windows 8.1 through UAG, and Remote Desktop 8.1.

Learn more about the new features as well as the included KB fixes that are rolled into this new Service Pack, here:

http://support.microsoft.com/kb/2861386

And feel free to download SP4 here:

http://www.ivonetworks.com/downloads/uag_sp4.zip

Installation note: Make sure that you are already running UAG SP3 Rollup 1 before installing SP4.

Is ISATAP required for DirectAccess?

Last night while working with one of my favorite customers to replace a NIC on a DirectAccess server, we discovered that the internal network was configured with a “global” approach to using ISATAP. I have seen this many times over the past couple of years, anyone who has stood up a DirectAccess environment following one of the Test Lab Guides out there most likely ends up with their network in this state, with a DNS host record for the word ISATAP. This is exactly what the TLGs tell you to do, but is actually not a good practice. I believe that some of the documentation out there specifies to take this approach because it’s easy to setup, and also because back when DirectAccess was new, we really didn’t know any better.

What is ISATAP?

Let’s back up a little. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an IPv6 tunneling technology. Most DirectAccess admins are familiar now with 6to4, Teredo, and IP-HTTPS. These three technologies are also IPv6 tunneling technologies, designed to take IPv6 packets and encapsulate them inside IPv4 headers, so that those packets can successfully transport across an IPv4 network. (aka the Internet for these three transition technologies). ISATAP does essentially the same thing, but for the inside of your network. I like to think of ISATAP as a “virtual IPv6 cloud” inside your corporate network. Once your internal computers/servers have set themselves up as ISATAP clients, they will receive an IPv6 address and routing information from the DirectAccess server. When this happens, because Windows prioritizes IPv6 over IPv4, whenever ISATAP host computers communicate with each other, they will do so using their ISATAP IPv6 tunnels, instead of their regular IPv4 LAN transport.

Why is this a problem?

If ISATAP is enabled globally in your environment, that means that any ISATAP capable host system will automatically become an ISATAP connected host system. Any Server 2008, Server 2012, Windows 7 or Windows 8 boxes inside your corporate network will automatically set themselves up with one of these ISATAP IPv6 addresses. When this happens, as stated above, all traffic between these hosts is now going to prefer to use that IPv6 tunnel rather than the regular IPv4 network. Well, it’s technically still using the IPv4 network, but is pushing encapsulated packets across the network now, instead of native IPv4. This means that if you are using an IDS/IPS to monitor traffic inside your network, you probably won’t be able to see this traffic. It will also make troubleshooting network issues inside the network quite a bit harder, because you’re going to notice all of these IPv6 addresses and packets flowing around, and it’ll take a lot longer to identify a connectivity problem with a system inside the network. Finally, you only have one ISATAP router when you setup this global approach, which is the DirectAccess server. This means that your DirectAccess server is now doing all the grunt work of being an ISATAP relay (sort of a DHCP server) for all of these internal hosts, sometimes thousands of them. It also means that the DirectAccess server is now the default router for all of the internal hosts traffic! This is obviously going to put unnecessary load on the DirectAccess server and the network where it resides. In the worst cases, using global ISATAP can cause connectivity issues and even network flooding.

History of ISATAP, as it relates to DirectAccess

So if it has the potential for so many problems, why is it the default implementation path in the Test Lab Guides? This answer goes all the way back to Server 2008 R2’s release. This operating system was the first time that the word DirectAccess appeared. Most folks are familiar with UAG DirectAccess and Server 2012 DirectAccess, now that it’s becoming more and more popular. But there was another version of DirectAccess, back in Server 2008 R2’s native operating system, and it came with some hitches. The biggest requirement was that the internal network had to be IPv6. This just isn’t a reality for customers, even today, and so it would have been a complete showstopper. Cue ISATAP. In Server 2008 R2 DirectAccess, you could use ISATAP to easily spin up a virtual IPv6 environment that ran on top of your internal IPv4 network, and then you could easily make use of DirectAccess! In the newer versions of DirectAccess, both UAG and Server 2012, there are some new components called NAT64 and DNS64 that work together to ensure that you don’t have any IPv6 requirements anymore. In Server 2008 R2, to be able to get those client IPv6 packets into the network, you needed an IPv6 network inside to send them to. With NAT64 and DNS64, the DirectAccess server now has the ability to take those client IPv6 packets and spin them down into IPv4 packets, so you can simply leave your internal network all IPv4. So back in the beginning it was standard practice to enable ISATAP globally. Today, because of the known issues, it is recommended not to use ISATAP at all, unless you have a specific reason for needing it…

In what cases would I actually want ISATAP?

Now you know the history on ISATAP and the fact that we no longer implement it unless needed, but how do you know whether or not you need it? If you have IPv6 inside your network, you definitely do NOT need ISATAP. I just wanted to start by saying that. However, almost nobody has IPv6 inside their network yet. So assuming that your internal network is IPv4, as we talked about already DirectAccess will work just fine, because of the new NAT64 and DNS64 technologies. So with no ISATAP in your environment, we can absolutely get DirectAccess connected and working. However, what happens if you have the need to send packets outbound toward your DirectAccess client machines? I’m not talking about things like updates or Group Policies or anything like that, because those items are all client-side pulls, and they will work over DirectAccess with no ISATAP or any special considerations. But if you have the case where you need to do a true “manage-out” to the DirectAccess client machines, like an internal helpdesk computer needing to RDP into a DirectAccess client computer, this requires the helpdesk computer to have an IPv6 layer of transport available with which to contact the IPv6 DirectAccess client. This is where the need for ISATAP comes in.

How to configure ISATAP

If you do determine that ISATAP could benefit the way that you use DirectAccess, DO NOT CREATE A DNS HOST RECORD CALLED ISATAP. Doing so will turn ISATAP on globally, and I direct you back to the beginning of this article. You will want to create a “Selective ISATAP” environment, where you get to determine manually which internal machines will take advantage of ISATAP and set themselves up as ISATAP hosts. This will leave the majority of your internal network on IPv4, business as usual, and will be a much, much safer way of implementing. Here are a couple of web links that will assist with your ISATAP configuration:

First, Jason Jones has a great article on setting up a Selective ISATAP environment: http://blogs.technet.com/b/jasonjones/archive/2013/04/19/limiting-isatap-services-to-directaccess-manage-out-clients.aspx

And I had the opportunity recently to put an extensive step-by-step together on this topic, in one of the chapters of this book: http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book

Jordan Krause
Microsoft MVP | Enterprise Security

View historical Server 2012 DirectAccess connections with PowerShell

If you’re running Server 2012 DirectAccess and have enabled Reporting inside the Remote Access Management Console, you already know that you can head into that GUI and search historically for DirectAccess and VPN connections. This works well and is nice because of the Search function near the top of the page, where you can sort by dates and type in just about any criteria that you may want to filter the data down into. The interface looks nice and works well. Sometimes though, you may want to send this data out to a file/spreadsheet to be able to email it to someone, to automate some kind of weekly or monthly report, or for further data manipulation purposes. There is an option to configure Reporting to send data to a RADIUS server, but unfortunately that option logs less data than the default internal WID reporting does, so it will be most beneficial to you to use WID (which is the same information that shows up in the Remote Access Management Console), and extract the data from there.

You can do just about anything with PowerShell these days, so let’s explore the commands that we can use to pull useful DirectAccess usage reporting out of a Server 2012 DirectAccess box. Here are the two commands we are going to use, and links to their official TechNet documentation:

Get-RemoteAccessConnectionStatistics – http://technet.microsoft.com/en-us/library/hh918379.aspx

Get-RemoteAccessConnectionStatisticsSummary – http://technet.microsoft.com/en-us/library/hh918386.aspx

I’ll let the documentation speak for itself on all of the different ways that these commands can be used, but here is the procedure (and sample scripts) that I most commonly use for pulling out statistics for a particular date range, which is the most common request that I receive from customers:

  1. Create a folder on the hard drive of your DirectAccess server. I usually name it something like C:\DA_Reporting
  2. Create two new text files inside this folder, called DA_Connections.txt and DA_Connections_Summary.txt
  3. Edit DA_Connections.txt with Notepad to reflect the following:
  4. Edit DA_Connections_Summary.txt with Notepad to reflect the following:
  5. Now you need to rename these text files to be “.ps1” files. You can do this with either File Explorer or a command/PowerShell prompt, but ultimately just change the names of these files so that they are now DA_Connections.ps1 and DA_Connections_Summary.ps1
  6. Open up PowerShell, browse to your folder, and run the scripts. If this is the first time you have run a PowerShell script and you receive an error message about your “execution policy”, see here for information on correcting that behavior: http://technet.microsoft.com/en-us/library/ee176949.aspx. I typically get past this error by simply running the Set-ExecutionPolicy RemoteSigned command, but you should decide for yourself based on that document what option best meets your needs.
  7. Once you have run the scripts, you will now have CSV files inside your DA_Reporting folder that can be opened and manipulated using Excel!

You can, of course, modify these scripts in many different ways, including new variables for filtering and giving it a different file name or path in which to store the CSV files. Also, you will need to modify the script whenever you want to change the date ranges that you want reporting information for. This is just a simple example with some step-by-step direction on getting you to a starting point, and you can tweak your implementation of these scripts as needed in your own environment.

Jordan Krause
Microsoft MVP | Enterprise Security

Microsoft DirectAccess Best Practices and Troubleshooting – new book!

A new book about DirectAccess has recently been authored by none other than our very own Microsoft MVP – Jordan Krause!

This book focuses on DirectAccess provided by Server 2012 (or Server 2012 R2), but most of the best practice and troubleshooting steps and solutions provided are also applicable to UAG DirectAccess for those of you using it.

http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book

Windows 7 DCA with Server 2012 DirectAccess

Anyone who has worked with UAG DirectAccess is probably familiar with the DirectAccess Connectivity Assistant (DCA), a small systray tool that installs onto the Windows 7 clients. This tool is very useful for generating log files in case you need to troubleshoot a DA connection, and it’s just a nice reference for users to be able to see whether or not their DirectAccess connection is working. In the UAG interface, there was a nice, easy way in the wizards for you to configure the DCA so that it knew what to look for in your environment and therefore report back to the user whether or not it was working properly based upon whether or not it could see those things which you defined.

In Server 2012 DirectAccess, there is no way to configure the Windows 7 DCA from inside the configuration wizards. Instead, Server 2012 DirectAccess focuses more on the Windows 8 clients, and the new version of DCA, now called NCA, which is built into Windows 8. During the Server 2012 DA wizards you define the same sort of criteria, basically telling the NCA tool what to look for, but when you are finished with these wizards and your settings are populated to the GPOs, these settings only apply to the NCA inside Windows 8. If you setup a Server 2012 DirectAccess environment, add a Windows 7 client to it, and install the DCA onto that client, it will not be configured. In this case the DCA can still be used to generate log files, but since it is not configured properly with a probe to go looking for, it will always show a status of “Not Working” with a red X.

So, by running through the Server 2012 DA wizards we have the NCA in Windows 8 working properly, but how do we get DCA in Windows 7 also configured? We basically just need to give it the same configuration settings as our NCA, but we have to do it manually, by hand, by way of a GPO.

Note: When you are sending Windows 7 clients through Server 2012 DirectAccess, you should be using DCA version 2.0 on your client machines.

Get your Active Directory ready for this new GPO

The settings for DCA are not part of Group Policy by default. You need to give one of your Domain Controllers the file that contains the settings so that when you go to configure your GPO, the settings you are looking for will exist. When you download the DCA 2.0 from Microsoft, here, it comes with a couple of files other than the installer itself. Log into a Domain Controller and do the following:

  1. Copy DirectAccess_Connectivity_Assistant_2_0_GP.admx into C:\Windows\PolicyDefinitions
  2. Copy DirectAccess_Connectivity_Assistant_2_0_GP.adml into C:\Windows\PolicyDefinitions\en-US

Create the GPO

Now let’s go ahead and create a new GPO for these settings. I try not to touch the existing DirectAccess Clients GPO which contains all of the existing DirectAccess connectivity settings, because this GPO is managed by the DirectAccess server’s wizard and any changes you make in here could potentially be overwritten by the wizard. After you create your GPO and link it wherever you would like, I recommend setting Security Filtering on that GPO (just like the DA Clients GPO does) so that it only applies to your Windows 7 DirectAccess client computers, since these are the only guys who are going to need or care about these settings.

Configure the GPO

Right-click on the GPO and “Edit”. Here are the items that we want to configure:

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | Support Email – Enable this setting and enter a valid email address here. Chances are that nobody will ever actually use this feature to email from the DCA tool, but if you want DCA to be able to generate log files, this setting must be populated.
  2. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | DirectAccess Dynamic Tunnel Endpoints (DTEs) – Enable this setting and click the Show… button to input your DTEs. You should have two DTEs to input here, and you can find this information from the DirectAccess server itself.
    1. To find the DTEs, log into your DirectAccess server and open an elevated PowerShell prompt. Then run the following command: Get-Item –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters
    2. In the output of this command, you will see entries listed for DTE1 and DTE2
    3. Back to the GPO screen, you want to input these two DTE settings by using PING:<DTE_Address> (as shown below)

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | Corporate Resources – Enable this setting and click Show… On this screen we are going to define a probe that the DCA tool is going to simply go out and look for. If it can see the probe, it reports successfully connected. If it cannot see the probe, it reports that there is a problem. You can do either a PING probe where it simply pings a server, or you can do an HTTP probe which validates that it can get to a particular website. Note: It is a common mistake to input your NLS server address here. Do not do this. The NLS website is NOT visible from a DirectAccess connected computer by design, and so the DCA would always report that it was not working. Here are a couple of sample values that you could put into this setting. You only need one, but you can have more than one if you so choose:
    1. PING:server1.corp.contoso.com
    2. HTTP:http://sharepoint.corp.contoso.com

That’s it! Those are the important settings for making the DCA work correctly on a Windows 7 computer that is connecting in through a Server 2012 DirectAccess environment. There is one more setting in that GPO that we occasionally set, but is optional. If you enable this setting, it basically allows the users to be able to turn off DirectAccess by right-clicking on the DCA and choosing a new option called “Prefer Local DNS Names”. If you enable this setting and the user clicks on it, it will temporarily disable the NRPT on their computer, which will cause name resolution requests to stop going through the DirectAccess tunnels. There aren’t many good use-case scenarios where this option would actually be feasible, and so it is quite rare that I see it used in the wild. However, if this option sounds appealing to you, here it is:

  1. Computer Configuration | Policies | Administrative Templates | DirectAccess Connectivity Assistant | LocalNamesOn – You simply enable this option if you want the users to have this capability.

Jordan Krause
Microsoft MVP | Enterprise Security