Friday, 29 November 2013

How to Install and Configure KB2862152 for a DirectAccess Scenario

Microsoft recently released a security advisory titled Vulnerability in DirectAccess could allow security feature bypass which can be found here. As part of the associated security update KB2862152 which can be found here, a DirectAccess client enforces more checks in IPsec negotiation when using either certificate-based or Kerberos Proxy authentication methods. During IPsec negotiation, the DirectAccess client now checks specific attributes against a set of registry-configured values. Consequently, it is important to realise that the security update is a client-side fix that strengthens how the identity of a DirectAccess server is validated, and aims to prevent a spoof, or rogue attacker-controlled system, from posing as a legitimate DirectAccess server.

Although the information provided in the KB article is very detailed, it has raised some questions from customers that I wanted to try clarify and explain in this blog post. I have written the blog post in FAQ style to try and provide a suitable reference guide for each consideration.

Please Note: Although the advisory references DirectAccess specifically in the title, and this blog post is focused on a DirectAccess deployment, the advisory also applies to other IPsec-related scenarios like client-to-site and site-to-site VPN deployments. Therefore, these scenarios will need to be considered slightly differently, and adapted as appropriate per the KB article.

 

On which computers do I need to deploy the update?

The key thing to realise is that the security update is a client-side fix and for the DirectAccess scenario, only needs to be deployed to DirectAccess client computers. This is likely to cause some confusion as the article talks about Window Server operating systems, but as DirectAccess is client-to-gateway configuration, the update only actually needs to be installed on the DirectAccess client computers. However, given that a Windows Server can also act as a DirectAccess client, the KB article includes references to Windows Server operating systems. This is not a common deployment model in my experience, but I have seen this configuration used for servers located in branch offices in order to communicate with a central data centre resource. So, in summary, the security update needs to be installed on the DirectAccess client computers which will [commonly] be Windows clients, but could also [less commonly] be Windows servers.

If you are using DirectAccess in Basic Remote Access mode using the Getting Started Wizard (also known as KerbProxy mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 8/8.1 and you DO NOT need to install the update on the DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section. KerbProxy mode only supports Windows 8/Windows Server 2012 and later operating system versions, so this deployment mode will not need to consider Windows 7 clients.

Please Note: If you are using Windows Server 2012 or 2012 R2 servers running as DirectAccess clients, then they will also require the security update to be installed. 

 

If you are using DirectAccess in Advanced Remote Access mode (also known as certificate-based mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 7 and you DO NOT need to install the update on Windows 8/8.1 DirectAccess client computers or DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section.

Please Note: If you are using Windows Server 2008 or 2008 R2 servers running as DirectAccess clients, then they will also require the security update to be installed. 

 

On which computers do I need to make the registry changes?

You will need to make the registry changes on all DirectAccess client computers where the update has been installed. By default, the update remains disabled after installation until specific registry changes are made on the client computer in order to manually enable the update. This will ensure that DirectAccess client computers include the new validation rules. As soon as these rules are set in the registry, the update will automatically start enforcing the new rules when it establishes a tunnel with the remote DirectAccess server. Any errors in the registry configuration will cause the IPsec tunnels connections to fail and consequently break DirectAccess connectivity from the client computer.

 

What registry changes do I need to make?

The registry changes are specific to the DirectAccess client computers operating systems as follows:

For DirectAccess client computers running Windows 7, Windows Server 2008 or Windows Server 2008 R2, you will need to edit the registry configuration to include an IP parameter combined with either a DNS parameter, or an EKU parameter. The following rules are then applied:

  • If only IP and EKU parameters are configured, the DirectAccess client checks that the DirectAccess server IPsec certificate for a matching EKU object identifier (also known as OID).
  • If only IP and DNS parameters are configured, the DirectAccess client checks that the DirectAccess servers IPsec certificate for a matching Common Name (CN) or Subject Alternate Name (SAN).
  • If IP, DNS, and EKU parameters are configured, the DirectAccess client only checks the DirectAccess server IPsec certificate for a matching EKU object identifier. If the DNS parameter is also defined, it is ignored.

For DirectAccess client computers running Windows 8, Windows Server 2012 or Windows Server 2012 R2, you will need to edit the registry configuration to include an IP parameter combined with a Service Principal Name (SPN) parameter. The following rules are then applied:

  • When the IP and SPN parameters are configured, the DirectAccess client checks that the DirectAccess server is using a matching SPN value.

For a DirectAccess scenario, note the following:

  • The <ipaddrv4/ipaddrv6> parameter should reference the Dynamic Tunnel Endpoints (DTEs) of the IPsec tunnels that enable DirectAccess. DTEs represent a collection of IPv6 addresses that each identify a DirectAccess server. In a certificate-based deployment of DirectAccess, there are typically two DTEs, one for the infrastructure tunnel, and one for the intranet tunnel. If using multiple DirectAccess servers, the DTEs will represent virtual IP addresses (VIPs) which are typically used with Windows Network Load Balancing (NLB) or hardware/external load balancer network topologies. An example DTE parameter might be: 2002:836b:1:: 836b:1
  • The <DNS> parameter should reference the DirectAccess server internal fully qualified domain name (FQDN) and the CN/SAN defined in the the DirectAccess server IPsec certificate. If using multiple DirectAccess servers, it is necessary to add each server FQDN to the registry key as denoted by the <DNS1> and <DNS2> references in the KB article. An example DNS parameter might be: daserver.corp.contoso.com
  • The <SPN> parameter should reference the DirectAccess server SPN which will typically be defined as host/FQDN. If using multiple DirectAccess servers, it is necessary to add each server SPN to the registry key as denoted by the <SPN1> and <SPN2> references in the KB article. An example SPN might be: host/daserver.corp.contoso.com

In order to determine the DTE parameters for a Windows Server 2012 DirectAccess deployment, you can use the following PowerShell command:

Get-Item –Path “HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters”

and look for the DTE1 and DTE2 references in the results. These are the DTE values (IPv6 addresses) that will need to be used in the registry keys. For the DirectAccess scenario, it is only necessary to define the IPv6 addresses in the registry keys as DirectAccess is a pure IPv6 technology when considering the IPsec configuration (connection security rules). Consequently, IPv4 addresses are not relevant for this scenario.

The DNS and SPN parameters should be quite easy to determine based upon the computer name and FQDN of the DirectAccess server(s). The IPsec certificate should also be checked to ensure the DNS name of the certificate will match that defined on the DirectAccess client computer registry entries.

 

Do I need to do anything else?

The security update has a dependency on the DirectAccess server certificate in order to meet the new client-side validation rules. Therefore, if you have used an IPsec certificate on the DirectAccess server that DOES NOT contain an Enhanced Key Usage (EKU) field/property, then you will need to replace the certificate with one that does, before making the registry changes on DirectAccess client computers. The DirectAccess server hosting this certificate can be running Windows Server 2008 R2, 2012, or 2012 R2. In general, if you are using a Microsoft CA and follow the guidance of creating a certificate template that has been duplicated from the default Computer certificate template in order to issue a suitable certificate, then the IPsec certificate should contain the correct EKU values to meet the client-side validation process. More information on these aspects can be found here and here.

 

How do I know if the registry changes have worked?

If after making the registry changes, you can still connect to corporate resources from a DirectAccess client that is located outside your internal network then you should be good to go. This can be confirmed several ways; by looking at the DirectAccess connection status of ‘Corporate Connectivity is Available’ in DCA (Windows 7), a ‘Connected’ state in NCA (Windows 8) or from looking at the client connections view in the Remote Access management console. If you can no longer connect, then something went wrong with the registry changes, or the IPsec server certificate is not configured correctly to match the registry values. The troubleshooting section provided in the KB article can be used to look for errors in IPsec logging information and also the general guidance provided here.

 

Can I see a working example?

So, the best way to understand the configuration is to see how it would be applied to a real-world scenario. So, let’s assume we have the following DirectAccess deployment:

 

 

image

 

This deployment is using the more common Advanced Remote Access model (certificate-based) with the DTE, DNS and EKU values as shown in the diagram. Note that the DNS parameter is NOT the IP-HTTPS FQDN, it is the internal FQDN of the DirectAccess server computer object within Active Directory. The EKU used in this example is the standard EKU OID for Server Authentication (1.3.6.1.5.5.7.3.1) but could in theory be a custom OID that is defined in the DirectAccess IPsec certificate.

This DirectAccess deployment would result in the following registry changes on the DirectAccess client computers:

For DNS approach:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 daserver.corp.contoso.com

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 daserver.corp.contoso.com

For EKU approach:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 EKU:1.3.6.1.5.5.7.3.1

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 EKU:1.3.6.1.5.5.7.3.1

Please Note: The data separators can be "space" or "tab" or a "new line" but I would personally use a new line for each entry.

Graphically these registry changes can be seen as shown below.

For the DNS approach:

image

For the EKU approach:

image

A similar approach can be used for Basic Remote Access mode deployments (KerbProxy) by simply using the SPN parameter instead of the DNS parameter in the above example. As a Basic Remote Access deployment only uses a single IPsec tunnel, it will only be necessary to define a single registry key value and the registry subkey will defined as Kerberos and not Cert e.g. HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Kerberos

I hope the above information clarifies and compliments the original KB article and provides some exemplar guidance on configuration of the registry keys based upon an actual working scenario.

Props: Thanks to Ioan Corcodel and Nithin Jose (Microsoft guys) for their assistance with providing a lot of the above information.

Wednesday, 13 November 2013

The Evolution of Collecting DirectAccess Client Diagnostic Log Information

A common administrator question when learning to troubleshoot DirectAccess client connectivity problems is:

“How can you create a client-side diagnostic log which provides specific detail about the DirectAccess configuration, connectivity state and other relevant system information which can be used to isolate the exact problem/issue?” 

Depending on how far along the Windows evolutionary journey you are, the user experience in order to initiate the log capture process is different for specific versions of Windows. In my experience, customers often have a mixed Windows estate and therefore need to be aware of how to collect these diagnostic logs for Windows 7, Windows 8 and potentially even Windows 8.1 DirectAccess clients. Given this need, the following sections define the steps involved to collect/gather the logs for each respective version and associated considerations to be aware of.

 

Windows 7 and the DirectAccess Connectivity Assistant

First introduced as part of the Solution Accelerators series, the DirectAccess Connectivity Assistant (DCA) soon became a common component that was an essential part of any DirectAccess deployment. One of the key benefits of DCA to the administrator was that it would allow the user to create a diagnostic log, with minimal effort, which would collect relevant data and system information. This could then be sent to the administrator for offline review, or used during interactive troubleshooting assistance.

Instructions: Right-click the DCA icon in the System Tray and then select the Advanced Diagnostics option.

 

image

 

Note: If the Advanced Diagnostics option is not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be generated automatically and saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Microsoft\DCA\

 

Windows 8 and the DirectAccess Properties Window

With the advent of Windows 8, the DCA was no longer needed as the operating system had been specifically designed to incorporate DirectAccess connectivity status and other key networking information within the View Available Networks (VAN) user interface. This negates the need to install a separate component and provides a consistent user interface where DirectAccess connectivity status can be viewed alongside all other network-related connectivity information. This was a welcome change.

Instructions: Left-click the Network icon in the System Tray to show the View Available Networks (VAN) window. Right-click the DirectAccess network entry from the list of available networks and select the View connection properties option. From the DirectAccess Properties window, click the Collect Logs button.

 

image

 

image

 

Note: If the Collect Logs button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp\Microsoft DirectAccess Logs\

 

Windows 8.1 and the DirectAccess Modern UI

With the increased need to provide a touch-friendly interface and adhering to Modern UI design specifications, the user experience of DirectAccess connectivity status provided in Windows 8.1 has been moved to the Networks Modern UI page. This avoids unnecessary switching to desktop and maintains uniformity with the rest of the networking connections like VPN, Wi-Fi etc. The existing DirectAccess Properties windows used in Windows 8 also required the user to switch to the desktop, which could be confusing when using Modern UI applications.

Instructions: Place the mouse pointer into the bottom-right corner of the desktop, select the Settings charm and then select the Change PC settings option. From the list of available PC Settings choose the Network option and then select the DirectAccess icon from the right-hand pane of the Connections window. Finally, click the Collect button under the Logs section.

 

image

 

image

 

image

 

image

 

Note: If the Collect button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Once the logs have been collected, a new email message window titled DirectAccess logs from %COMPUTERNAME%\\%DOMAIN%\%Username% - %Date% should appear. This will be rendered based upon the default email application that is defined on the Windows 8.1 DirectAccess client, and is shown below for Outlook 2013.

 

image

 

The log collection process in Windows 8.1 requires that an email program has been installed and/or a default email association has been defined, otherwise you will receive the error shown below. If the log collection process appears to be taking a long time (spinning circle) it may be necessary to switch to the desktop to actually see any errors related to the log collection process.

 

image

 

An email program and/or email association is required as the collected logs files are attached directly into a new email message window. Log files will not be saved to an obvious file location and will need to be either emailed to an administrator by clicking Send, or copied directly from the new email message window to an appropriate file location of choice. However, a copy of the collected log file can also be found in the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp with a default filename of %COMPUTERNAME%-%Date% %Time%-DirectAccess Logs.html

Tip: An alternate (easiest) way to access the DirectAccess Options screen in Windows 8.1 is to use the Search charm, typing direct into the search field and then selecting the Change DirectAccess settings option from the displayed search results.

 

image

 

So, there we have it; three different versions of Windows, three different ways to collect DirectAccess diagnostic log information. Happy log collecting DirectAccess troubleshooters!

Tuesday, 2 April 2013

Useful Guide: Troubleshooting DirectAccess Manage Out Connections

I’ve discussed the concept of ‘Manage Out’ for Forefront UAG DirectAccess and also more recently for Windows Server 2012 DirectAccess; both of which can be a cause of pain when implementing and supporting a DirectAccess solution using either platform. One of my MCS colleagues in NYC, Colin Brown has written an excellent troubleshooting guide which provides a shining beacon of light in the darkness of ‘Where do I even start??!!’

Enjoy and great work Colin, I wish I had written it! :)

You can find the guide hosted on Tom’s ‘Building Clouds’ blog here: Troubleshooting DirectAccess Manage Out Connections

Monday, 18 March 2013

Windows Server 2012 DirectAccess Manage Out using Native IPv6


Please Note: The approach provided within this blog post is not suitable when using an External Load Balancer (ELB) or a multisite DirectAccess topology and you will need to use a more traditional native IPv6 deployment where you define your own IPv6 prefixes which are entered as part of the DirectAccess wizard configuration process.
I wrote a previous blog article titled Limiting ISATAP Services to UAG DirectAccess Manage Out Clients some time ago now which proved to be quite popular as a way to allow manage-out functionality for UAG DirectAccess solutions without effecting the entire network through the use of wide spread ISATAP enablement. That article originated as many people weren't aware that in order to manage DA clients from an intranet machine, it needed to be IPv6 capable (read native IPv6 or using a transition technology like ISATAP). Given the use of ISATAP you needed to be a little careful with how best to enable it for a subset of management clients, otherwise there was potential to impact the entire internal network and bad stuff can happen.
Given the advent of Windows Sever 2012 DirectAccess and the new Unified Remote Access role, Microsoft no longer recommends the use of ISATAP to facilitate manage out scenarios in favour of using native IPv6. This statement is discussed here and appears to be the general MS recommendation given the potential problems associated with ISATAP deployments that can, and often do, go wrong. The likely first reaction to that news is likely to be “…but I don’t understand IPv6 and our intranet doesn’t have it enabled or configured yet, so how do I do that?” or “…why can’t I just stick with ISATAP? It seems easier”. Both of these reactions are understandable, but I wanted to provide an example to show that it isn’t actually that scary and it is potentially even easier to implement than the old ISATAP method, especially for a small number of management clients. Nobody is saying that you can’t use ISATAP; in fact the ISATAP router functionality is still enabled by default on the DA server when using an IPv4 address on the internal network adapter. Although the DA Server is configured as an ISATAP router by default, it should be noted that it will not service clients until the necessary ISATAP DNS A record has been created and the entry removed from the DNS global query blocklist. However, maybe it is time to start thinking about that historic ‘ISATAP or native IPv6’ decision process and the primary reason that I am writing this blog post :)
Please Note: The obvious caveat, or limitation, here is that the communication path (read network infrastructure) between the management client and the DA server will need to support (be able to forward) native IPv6 traffic. This is likely to be very environment specific and may need to be tested, or involve discussions with your network guys to understand if this is a viable option. For example, an IPv4-only back firewall is a good example of something that may prevent the use of native IPv6 for manage out. For networks that cannot support native IPv6, some form of IPv6 encapsulation or transition technology will need to be used (using the method discussed in my previous blog post perhaps).
So, what does it mean to use native IPv6 for managing DA clients from the intranet then? Well, in it’s simplest form it means manually configuring your management clients with static IPv6 addresses from a suitable IPv6 prefix and then providing the appropriate IPv6 routing to reach DA clients by way of the DA server they are connected to. For this blog post, this is the example I am going to use to begin with and is based around the same premise as my last article; namely that the number of management clients involved is usually pretty small, or involves the use of ‘jump hosts’ that are shared by admin/support staff. Hence, the plan is to keep things simple for now and continue with the use of manual IPv6 configuration to describe the overall concept. At this juncture, it may also be useful to know that I wrote a basic overview of IPv6 addressing choices for DirectAccess in a previous blog post here which may also prove useful if you considering a more automated approach to IPv6 configuration.
When DirectAccess is installed, a 6to4-based organisation prefix is created automatically using the following IPv6 prefix format 2002:WWXX:YYZZ:3333::/64 where WWXX:YYZZ are the hexadecimal representations of the primary public IPv4 address octet pairs bound to the external network adapter of the DA server (with the IPv4 address formatted as WW.XX.YY.ZZ). So, using an example where the primary public IPv4 address is: 131.107.0.2 this would result in a 6to4 prefix of: 2002:836b:2:3333::/64 as 131 in hex is 83, 107 is 6b and 2 is 2.
Please Note: If you are using your DirectAccess server behind a NAT device and consequently using private IPv4 addresses on the external network adapter, as opposed to public IPv4 addresses, the IPv6 prefix will be in the form of: FD##:####:####:7777::/96 as per RFC 6147. The DA client IPv6 prefixes for Teredo and IP-HTTPS will also follow a similar structure when using private IPv4 addresses.
Still with me? If so, let’s move on…
Given this IPv6 prefix, we can now use this to generate static IPv6 addresses for the management clients using the format 2002:836b:2:3333::# where # is a manually chosen unique number used by each management client. By default the DA server will automatically use the 2002:WWXX:YYZZ:3333::1 address, so anything above this value should be fine as long as though it is unique and not in use. Furthermore, when defining the static IPv6 address, the subnet prefix length will normally be 64.
So with the static IPv6 address defined, all we need to do now is consider how we ensure that IPv6 traffic can reach the DA clients that are connected to the DA server. This is achieved in two ways; by defining an IPv6 default gateway, or by defining specific individual IPv6 static routes. Focusing on the first option, as mentioned, for our example the DA Server will be assigned a static address of 2002:836b:2:3333::1 so we can simply define this as the IPv6 default gateway on management clients. The final result is shown below:
image
Making the DA server your default IPv6 gateway may not be desirable, or recommended in most cases. Therefore, as an alternative approach you may wish to be more specific and ensure that only IPv6 prefixes that are used by DirectAccess clients are routed to the DA server by way of specific IPv6 static routes. This provides much better control over IPv6 routing and allows for specific DA client management traffic to be considered without impacting on other IPv6 services. This is achieved by defining the static routes, on each management client, to cover necessary DA client IPv6 prefixes, as opposed to defining a global/single IPv6 default gateway. For our example, these include:
IP-HTTPS Clients Prefix: 2002:836b:2:1000::/64
Teredo Clients Prefix: 2001:0:836b:2::/64
Turning these IPv6 prefixes into IPv6 static routes, we get the following respective commands based upon our example above:
netsh int ipv6 add route 2002:836b:2:1000::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
netsh int ipv6 add route 2001:0:836b:2::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1
Please Note: Sharp eyed readers may have noticed that I have not mentioned 6to4 clients. The reasoning behind this decision is that the 6to4 transition technology only works when the DA client has a public IPv4 address (which is a typically rare scenario nowadays) and issues often occur in networks where the DA client gets a public IPv4 address but cannot actually reach the 6to4 relay due to some form of in-path NAT. For these reasons, it is recommended practice to disable the 6to4 transition technology on DA clients and therefore it is not covered above.
At this point, those of you more familiar with IPv6 may be thinking “…is this guy mad? Why is he defining static IPv6 addresses??!!” Well, firstly, it makes things simple for the given example and in reality if you only have a small number of management clients (or ‘jump hosts’) it is actually quite feasible to use static addresses. This approach requires no additional network infrastructure, or network configuration for IPv6, and is actually pretty quick and easy to do. The obvious problem here is that this admin overhead doesn’t scale well and the IPv6 protocol was specifically designed to use a concept of automatic address selection and static addressing is therefore pretty much a thing of the past. However, as discussed, we are dealing with a very specific example, trying to keep things simple and we are not designing IPv6 for the entire intranet.
In the event that you have a larger number of management clients, or just feel that static configuration is not appropriate for your environment, it is better to use some form of IPv6 auto-configuration mechanism in order to provide management clients with addressing information and route assignment, without the need for human intervention. IPv6 auto-configuration can be performed by any capable Layer 3 network device (which includes a Windows Server) although as discussed, this is out of the scope of this blog post at this time. However, it may be interesting to note that the necessary steps for using a Windows Server to provide IPv6 auto-configuration have been covered in one of my previous blog posts here
Now we have management clients with IPv6 addressing information and the appropriate IPv6 routing table entries, we can hopefully begin managing DA clients from the intranet. At this stage you should be able to ping a remotely connected DA client from a management machine and receive an IPv6 response, assuming there is a route to the destination and ICMP echo requests are enabled in the firewall.
Important: Ping is helpful to verify that basic connectivity is working and validate you management client IPv6 configuration parameters, however, should only ping work but not any other type of connection then it’s most likely to be an IPsec-related issue. This is because ICMP is exempted from the DirectAccess IPsec tunnels and therefore provides limited value when testing connectivity from management clients to DA clients. More discussion on this topic cab be found here.
Before we can have a fully working solution it may also be necessary to consider a few additional steps, which based upon my own experience, are not totally obvious and can easily be forgotten.
If you have defined new IPv6 addresses on System Center Configuration Manager servers, it will be necessary to use the Refresh Management Servers option in the Remote Access Management console, as shown below, in order for the new IPv6 address information to be added to the DirectAccess clients GPO:
image
The same thing is true for Domain Controllers, but I am guessing that you will not be defining these as specific management clients. Furthermore, implementing IPv6 addressing on Domain Controllers introduces additional considerations to Active Directory functionality and operation which are key to ensure services are not impacted.
For all other management clients, it will be necessary to manually add each of them to the Management servers list which can be found in the Step 3: Infrastructure Servers section of the Remote Access Management console as shown below:
image
Once entries have been added, the updated configuration can be committed using the Finish… button.
The final task is to run gpupdate /force on management clients and DA clients to ensure they get updated GPOs which have been modified by the changes described above. Alternatively, you can wait for the next Group Policy refresh cycle but I’m normally kinda impatient!
Please Note: Don’t forget that it will still be necessary to define Windows Firewall with Advanced Security (WFAS) inbound rules on the DA clients to allow for the necessary permitted network access as discussed here.
All being well, you should now be able to initiate outbound management requests to DA clients from management clients on the intranet without necessarily have to resort to ISATAP and hopefully you have a little more confidence that using native IPv6 is not quite so scary after all :)
Now, go manage out with native IPv6!
P.S. Special thanks to Philipp Kuhn for the article inspiration and technical review assistance!

Thursday, 17 January 2013

A New Year and a New Job!

As you may have seen from my biography changes on my blogs and also over at the TechNet forums, I now work directly for Microsoft; specifically, for Microsoft Consulting Services (MCS) in the UK as a security consultant. I have therefore lost my MVP status (which is very sad) as I am now a Microsoft full-time employee (which is very good) and you cannot be both. It is an exciting time and I am very much looking forward to the new role and the challenges it will bring.

Given my new role, I am not sure how much time I will be able to dedicate to this blog (or anything new for that matter!) but I plan to keep it available so it is accessible via search engine results, referenced in a few books (thanks Ben/Ran) or included as links I have put into TechNet forum posts. I will still be replying to comments made on existing posts, so feel free to continue to ask questions or comment as required. I still plan to be very much part of the online community and work at helping people use the Microsoft technology to achieve their security goals, but as ever, I will need to balance this with my day job.  

Once I have settled into my new role, I hope to be back when I can to share notes from the field (subject to NDA) and my experiences along the way…  

Sunday, 16 December 2012

DirectAccess Hotfix Summary

I thought it might be useful to provide a summary list of DirectAccess related hotfixes from the past and present that may be of use to those embarking on a DirectAccess deployment for the first time, or those experiencing problems that have been solved already!

PLEASE NOTE: Microsoft have now provided an official dynamic knowledgebase article which provides a summary of Windows 7, Windows 8 and Windows Server 2012 hotfixes which can be found here: http://support.microsoft.com/kb/2883952 and consequently supersedes the below information.

Last updated 14/08/13 with KB2849568.

Hotfixes: Windows 8 and Windows Server 2012

KB2859347: IPv6 address of a DirectAccess server binds to the wrong network interface in Windows Server 2012.

KB2855269: Error message when you use an account that contains a special character in its DN to connect to a Windows Server 2012-based Direct Access server.

KB2849568: Vulnerability in the Windows NAT driver could allow denial of service: August 13, 2013.

KB2845152: DirectAccess server cannot ping a DNS server or a domain controller when a DirectAccess client is pinging the same server in Windows Server 2012.

KB2844033: DirectAccess Setup Wizard fails on a Windows Server 2012-based server in a domain that has a disjoint namespace.

KB2836232: Subnet mask changes to an incorrect value and the server goes offline in DirectAccess in Windows Server 2012.

KB2796394: Error when you run the Get-RemoteAccess cmdlet during DirectAccess setup in Windows Server 2012 Essentials

KB2795944: Windows 8 and Windows Server 2012 cumulative update: February 2013. This update includes fixes for DA that provide stability under heavy load.

KB2788525: You cannot enable external load balancing on a Windows Server 2012-based DirectAccess server.

KB2782560: DNS64 does not resolve computer names when you use DirectAccess and external load balancing in Windows Server 2012.

KB2769240: You cannot connect a DirectAccess client to a corporate network in Windows 8 or Windows Server 2012.

KB2748603: The process may fail when you try to enable Network Load Balancing in DirectAccess in Window Server 2012.

KB2666914: DirectAccess Connectivity Assistant 2.0 is available.

Hotfixes: Windows 7, Windows Server 2008 R2 and Forefront UAG 2010

KB2797301: A Forefront Unified Access Gateway 2010 DirectAccess client experiences repeated OTP prompts.

KB2758949: You cannot build an IP-HTTPS protocol-based connection on a computer that is running Windows 7 or Windows Server 2008 R2.

KB2718654: You are prompted to enter credentials when you try to access a SharePoint server on a Windows 7 SP1-based or Windows Server 2008 R2 SP1-based computer.

KB2680464: Location detection feature in DirectAccess is disabled intermittently in Windows 7 or in Windows Server 2008 R2.

KB2663354: DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010.

KB2633127: DA client cannot reconnect to the UAG DA server when a Windows 7-based or Windows Server 2008 R2-based client computer is connected to the Internet.

KB2615847: "ERROR_IPSEC_IKE_CERT_CHAIN_POLICY_MISMATCH" error when you try to start an IPsec connection between two computers that are running Windows 7 or Windows Server 2008 R2

KB2535133: IP-HTTPS clients may disconnect from Windows Server 2008 R2-based web servers intermittently after two minutes of idle time.

KB2444558: You cannot access a host that is hosting the IPv4 file share by using SMB v1 from a Windows 7-based or Windows Server 2008 R2-based DirectAccess client.

KB2288297: You are unexpectedly prompted to enter your credentials when you try to access a WebDAV resource in a corporate network by using a DirectAccess connection in Windows 7 or in Windows Server 2008 R2.

KB979373: The DirectAccess connection is lost on a computer that is running Windows 7 or Windows Server 2008 R2 that has an IPv6 address.

KB978738: You cannot use DirectAccess to connect to a corporate network from a computer that is running Windows 7 or Windows Server 2008 R2.

KB974080: DirectAccess Workaround for reaching IPv4 address checking sites.

KB973982: The certificate for IP-HTTPS does not rebind if the certificate is changed after the configuration is applied one time in Windows Server 2008 R2.

KB972516: A DirectAccess access failure occurs after the DNS servers that are running Windows Server 2008 return empty responses for AAAA queries in a WINS zone.

Security Updates: Windows Server 2008 R2 and Windows Server 2012

KB2765809: Vulnerability in IP-HTTPS component could allow security feature bypass (MS12-083).

Hope the list is useful!

Thursday, 13 December 2012

Forefront TMG/UAG: Useful Tools and Scripts

I spend a fair bit of time deploying both Forefront TMG and Forefront UAG for customers and therefore have defined a pretty good build checklist that I follow for every deployment. This makes implementations easier to support as we have a standard build and standard toolset available for every customer. As part of these deployments, I install some core tools and also run several scripts to provide a solid foundation for both products.

I thought it may be useful to share my experience and provide the community with some advice for more polished and supportable TMG/UAG deployments.

image

Please Note: As Forefront UAG includes an instance of Forefront TMG, it is recommended to install all tools, but only run the scripts defined in the ‘Scripts: General’ section on UAG servers.

Tools

In terms of tools, my standard build would normally include the following tools:

Forefront TMG Best Practice Analyser which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront TMG server to look for common problems and configuration errors. Run this tool at least once when you have completed your Forefront TMG installation and configuration.

Forefront UAG Best Practice Analyser which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront UAG server to look for common problems and configuration errors. Run this tool at least once when you have completed your Forefront UAG installation and configuration.

Network Monitor which can be downloaded here.

This tool should be pretty self-explanatory and should be installed on every Forefront TMG/UAG server to aid troubleshooting when the time comes. Network Monitor is also a prerequisite for using the Data Packager element of the Forefront TMG Best Practice Analyser.

Please Note: Additional Forefront TMG tools can also be downloaded from here, but I don’t tend to install all of these by default.

Scripts: General (Applicable to TMG and/or UAG)

In terms of general scripts, my standard build would normally include:

SetNetBTNodeType.reg which can be downloaded here.

This script is used to prevent NetBIOS broadcast traffic (and thereby dramatically
improve TMG performance) by configuring Windows as a peer-node host using the NetBT NodeType registry value. Props for this particular registry setting goes to the Microsoft Forefront TMG Administrators Companion book, which is highly recommended! Winking smile

SetServiceDependencies.bat which can be downloaded here.

Since Forefront TMG Service Pack 1 and above, I have had numerous occasions where Forefront TMG server takes a long time to reboot. These problems are well documented on various forums and blogs and I am still unsure if the issue has been fully fixed, even in the latest service pack level. To combat these problems, we which lies with the failure to start the Microsoft Forefront TMG Control service (isactrl) within a timely fashion, it is possible to change/reset the dependencies of the Forefront TMG Control service, thereby eliminating the problem.

RemoveWeakVersions2k8.reg which can be downloaded here.

This script is used to disable SSL version 2 which is enabled by default with Windows Server 2008/R2.

Disabling SSL v2 is a well versed security recommendation as it suffers from several cryptographic flaws and has been deprecated for several years. You can validate this change has been completed successfully using the Qualys SSL LABS: SSL Server Test available here.

Scripts: Web Proxy (N/A to UAG)

In terms of web proxy specific scripts, my standard build would normally include:

SetTemporaryStorageSettings.vbs and ShowTemporaryStorageSettings.vbs which can both be downloaded here.

Until quite recently, I was unaware that Forefront TMG Malware Inspection imposed a maximum disk space, in megabytes, that may be allocated for temporary disk storage for a single client  during malware inspection. The default maximum disk space is set at 50MB, which sometimes needs adjusting depending on the different customer environments. This script can therefore be used to set (or show) the default temporary storage limits to something more appropriate. It is a shame you cannot modify these parameters from within the Forefront TMG console, but this makes the script all the more useful and valuable.

More information (including other temporary storage limit settings) can be found here.

UseDNSforWPAD.vbs which can be downloaded here.

Based upon information provided in this blog article and personally experiencing problems with the WPAD.DAT file containing the IP address of the RAS adapter instead of the correct server primary internal IP address; I started using this script which instructs TMG to use the DNS name of array members (or server) instead of IP addresses in the WPAD script.

Please Note: With the advent of Forefront TMG SP2, using Kerberos with an NLB web proxy array is now much improved as discussed here.

Scripts: Web Publishing (N/A to UAG)

In terms of web publishing specific scripts, my standard build would normally include:

EnableSP2FBACookieSharing.vbs which can be downloaded here.

By default, a Forefront TMG forms-based authentication cookie is only valid on the array member that generated the cookie. If a client request that contains an authentication cookie from one array member is sent to a different array member, the client is asked to re-authenticate. This behaviour may occur when a node is taken offline. Or, this behaviour may occur if the client source IP changes between requests that affect which array member handles the incoming request.

Forefront TMG Service Pack 2 added functionality to support cookie sharing across array members. To do this, SP2 enables support for the cookie encryption keys to be shared across array members.

Please Note: To support sharing cookie encryption keys, the array members must be domain-joined. Be aware that this script does not work for workgroup-based array members.

As this is a pretty significant change in functionality, for the better, I now run this script by default when deploying standalone or EMS-managed arrays where array members meet the domain joined prerequisite.

More information on this new SP2 feature is available here.

Other Important Build Configuration

I wasn’t planning on talking about standard build configuration as this blog post was meant to be dedicated to tools and scripts, but I think they are actually hugely relevant when deploying TMG/UAG server. Hence I have included two key baseline configuration tasks for any TMG/UAG implementation

In addition to installing the above tools and scripts, it is also vital to configure TMG and UAG server network adapter settings and bind order appropriately. More information on this particular aspect is provided in the following TechNet Wiki articles:

Recommended Network Adapter Configuration for Forefront TMG Standard Edition Servers

Recommended Network Adapter Configuration for Forefront TMG Enterprise Edition Servers

Recommended Network Adapter Configuration for Forefront UAG Servers

And finally, make sure you have applied the latest updates and service packs for TMG and/or UAG; at the time of writing, this is Forefront TMG Service Pack 2 (build version 7.0.9193.500) and Forefront UAG Service Pack 1 Update 1 (build version 4.0.1773.10100).

I hope you find these tools and scripts useful and have learned something new to improve your own TMG/UAG deployments. If you have other tool and scripts recommendations, please drop me a comment below and I will endeavour to add these to the list.

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:

http://blogs.technet.com/b/ben/archive/2012/01/09/uag-vs-tmg.aspx

http://tmgblog.richardhicks.com/2010/10/10/what-are-the-differences-between-tmg-and-uag/

http://www.isaserver.org/tutorials/Microsoft-Forefront-TMG-UAG-feature-comparison.html

http://blogs.technet.com/b/ucedsg/archive/2010/08/16/do-i-use-forefront-tmg-or-forefront-uag-for-reverse-proxy-publishing-for-exchange-2010.aspx

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…  

Friday, 10 August 2012

Windows Server 2012 Remote Access: The New Microsoft Edge Server

 image

Windows Server 2012 combines the DirectAccess feature and the RRAS role service into a new unified server role. This new Remote Access server role allows for centralized administration, configuration, and monitoring of both DirectAccess and VPN-based remote access services. Additionally, Windows Server 2012 DirectAccess provides multiple updates and improvements to address deployment blockers and provide simplified management. So, we can welcome a new Microsoft Edge server to the party, alongside the likes of Forefront TMG and Forefront UAG. Given the name of my blog, this continues the ‘Edge’ theme nicely!

It appears the term Unified Remote Access (URA) has also been defined to describe this new offering. Microsoft obviously appear to like three letter acronyms beginning with ‘U’ Smile 

More information on the changes can be found in the pre-release documentation available here. Given the recent announcement of the RTM status for Windows Server 2012, I would expect TechNet to be updated shortly with updated documentation to replace the pre-release version currently available. I’ve got a suspicion it will have also been written by a few friends I have made along the Forefront journey over the last few years…

With the advent of this new role, I plan to spend some time talking about the new features, changes and benefits it will bring for both DirectAccess and more traditional VPN services. Given my background with Forefront UAG DirectAccess and previous blog posts, this will be an area of particular focus. For example, I have already provided a blog post comparing the new DirectAccess feature-set to existing versions of the DirectAccess technology timeline, which can be found here.

I think Windows Server 2012 will be a great release, especially when looking for a feature-rich Remote Access solution…

Windows Server 2012 DirectAccess: Microsoft DirectAccess Comparison Table

image

With the impending release of Windows Server 2012 we will have our third iteration of the Microsoft DirectAccess solution. Life began with the DirectAccess feature coming to Windows in the first release of Windows Server 2008 R2 a few years ago now; it was then supercharged using Forefront UAG to offer a truly more achievable solution which was much easier to implement for many organisations given the improvements offered by the Forefront UAG platform. Now with the release of Windows Server 2012, we have the third generation of the solution which is fully featured and delivered as part of the native operating system. Given the impending third generation release, I thought it might be useful to prepare a DirectAccess comparison table to compare the different technology versions available, as shown below:

DA Solution

Windows Server 2008 R2 DA

Forefront UAG 2010 SP1 DA

Windows Server 2012 DA

Feature

Simplified DirectAccess management for small and medium organisations

No

No

Yes

Automated DirectAccess server configuration

No

Yes

Yes

Mandatory PKI deployment as a DirectAccess prerequisite

Yes

Yes

No1

Built-in NAT64 and DNS64 support for accessing IPv4-only resources

No

Yes

Yes

Support for a DirectAccess server with a single network card

No

No

Yes

Support for a DirectAccess server behind a NAT device

No

No

Yes

Requires at least one Windows Server 2008/R2 Domain Controller

Yes

No

No

Requires at least one Windows Server 2008/R2 DNS Server

Yes

No

No

Load balancing support

No

Yes

Yes

Server fault tolerance

Limited2

Yes

Yes

Support for multiple AD domains

No

Yes

Yes

NAP integration

Yes

Yes

Yes

Support for OTP (token based authentication)

No3

Yes

Yes

IP-HTTPS interoperability and performance improvements

No4

No4

Yes

Manage-out only support

No

Yes

Yes

Multi-site support

Limited5

Limited6

Yes7

Support for Server Core

No

No

Yes

Support for Windows 7 clients

Yes

Yes

Yes

Support for Windows 8 clients

Unknown

Limited8

Yes

Windows PowerShell support

No

Limited9

Yes

User and server health monitoring

No

Yes

Yes

Diagnostics

No

No

Yes

Accounting and reporting

No

Limited10

Yes

Notes and small print:

Items in red represent significant improvement or changes.

1PKI is still mandatory for force tunnelling, Network Access Protection (NAP) integration or two-factor authentication deployment scenarios. A PKI-based solution is therefore still required for some enterprise-class deployments, dependent on the required features. 

2Hyper-V failover cluster is required.

3Smartcard only.

4IP-HTTPS is supported, but there is a performance overhead due to combined/double SSL and IPsec encryption. IP-HTTPS in Windows Server 2012 now support null SSL encryption and additional optimisations but requires Windows 8 clients.

5Complicated setup due to IPv6 requirements.

6Global Server Load Balancer (GSLB) is required.

7Automatic DirectAccess entry-point detection or user selected entry-point requires Windows 8 clients.

8Technically works, but the supportability status is currently unknown (full support provided in UAG SP3).

9Read-only PowerShell.

10Command line via PowerShell only.

As highlighted above, Windows Server 2012 offers the most feature-rich platform when compared to previous versions and can be considered as a superset of the functionality provided by the Forefront UAG SP1 offering. Many of the enhancements included in Windows Server 2012 DirectAccess are based upon direct feedback from customers and changes to facilitate easier adoption and deployment of the technology within both smaller organisations and enterprise environments alike. I am planning on creating two upcoming blog posts which will highlight the changes and benefits in Windows Server 2012 DirectAccess from the perspective of the smaller organisation and then also for the enterprise space. Given the improvements and changes, I think DirectAccess will be even more popular than ever…what do you think?