In 2010, I proposed on this blog a series of posts on how to set-up a high availability DirectAccess infrastructure with Microsoft Forefront Unified Access Gateway 2010. As Windows 8 server Consumer Preview edition will offer this capability, it was interesting to see how easy it will be to configure the new operating in a DirectAccess High availability scenario. For this first post, I will use Network Load Balancing.
This post is based on my own experience of the Consumer Preview build of Windows 8 that was available the 29th march of 2012. Don’t try this in a production environment today.
Until RTM version of Windows 8, Microsoft can operate some changes according to customer feedbacks. So consider my post as a source of information but not your only source of information that must remain the Microsoft Technet web site (My blog is not Technet).
In order to make this post as short as possible, I made some choice that would not be your choice in your production environment.
A global view first
This is my lab. My goal is to provide the same level of service that Microsoft Forefront UAG 2010.
There is something wrong with this schema. Why does my Windows 8 box only have a single IPv4 public address. Teredo requires two public address. That’s right but I wanted to experiment a new DirectAccess deployment scenario (as many customers request to bypass this limitation).
Let start with roles and feature installation
As introduced in my DirectAccess in Windows 8 sneak preview post, DirectAccess is no longer a feature of Windows but a part of the Remote Access role. The first operation is to install the Remote Access feature.
The Remote Access feature have many dependencies with other roles and features. Only required features will be installed. For example, required feature for accounting or high-availability will not be installed by default.
This is the only role we need.
Because Network Load Balancing feature is not installed by default, let’s add it with some PowerShell Stuff on both nodes :
Add-WindowsFeature –Name NLB –Computer DA1.DirectAccessLab.Lan
Add-WindowsFeature –Name NLB –Computer DA2.DirectAccessLab.Lan
Add-WindowsFeature –Name RSAT-NLB –Computer DA1.DirectAccessLab.Lan
Add-WindowsFeature –Name RSAT-NLB –Computer DA2.DirectAccessLab.Lan
My IPHTTPS certificate
Microsoft made some major improvements in DirectAccess, especially in performance. In a high availability scenario, we still need a Web certificate delivered by a recognizable CA that should be public (much more easier to manage). This certificate must be installed on all future Windows 8 servers that will be used to form the NLB farm.
Even if DirectAccess is now fully manageable with PowerShell comandlets, we will follow the expert DirectAccess wizard. There are many things to learn. Here is the new Remote Access Management Console. The “Getting Started Wizard” will allow you to configure DirectAccess in less than five mouse clicks. But we are here for a deep-dive, so let’s chose the “Remote Access Setup Wizard”.
What an interesting choice. We can combine DirectAccess with VPN. In some situation that may be useful. There might many things to say about those scenarios, but maybe for another post and let choose “Deploy DirectAccess only”.
The Wizard is organized in section just like UAG or Windows 2008 R2 wizard. The first section focus on clients. Since UAG 2010 SP1, we hard two deployment scenarios for DirectAccess. The second one limit DirectAccess usage to Remote management capabilities and does not offer users access to internal resources. This is not my favorite scenario. For this reason, we will deploy DirectAccess in the standard scenario that offer full access to the network.
First question on the client side is how to identify DirectAccess clients? Response with one or more security groups. The “Enable DirectAccess for mobile computers only” checkbox add a WMI query to the DirectAccess GPO that configure clients computers.
We can notice that the force tunneling option is now available in the client section configuration interface and not on the server section configuration interface. But where are the others parameters of the Force tunneling mode? The nest step will focus on the Network Connectivity Assistant witch is new new name for DirectAccess Connectivity Assistant that is now fully integrated in Windows 8 (See how Microsoft improve DirectAccess user-experience in Windows 8). In this Consumer Preview, we can notice a minor change. We can use HTTP or PING to test internal probes, no trace of HTTPS. In my opinion, PING is not a relevant test as ICMP messages are not included in IPSEC. You could be able to ping internal resources be unable to access theses resources because of IPsec negotiation failures.
Server section configuration present some interests. By now we will be able to deploy DirectAccess in multiple topology, even with a single network card (good for the private cloud!) But more important, we will be to deploy DirectAccess behind an Edge device With Network Access Translation enabled. That’s an interesting scenario that deserve more than a single post. For this reason, we will chose the standard deployment topology (Edge) and specify the FQFN of the Virtual IP address that will be configured on the external side of the Network Load Balancing.
Note that the wizard will check this information with the subject name of your IPHTTPS certificate. So don’t try to configure the VIP address at this stage.
That an interface we all know. In an Edge DirectAccess scenario (with two network cards), the console must be able to identity the public and domain interface (based on Windows Firewall profile). The wizard was able to select the good certificate because the FQDN I provided match the subject name of my certificate.
Note that the wizard was not able to detect an IPv6 connectivity on my internal network card. For this reason, transitions protocols will be enabled (DNS64/NAT64 now included).
In my opinion, use of self-signed certificate for IPHTTPS is helpful for small deployments only or Proof of Concept, but in real deployment, this is something to avoid.
Windows 8 is now able to offer OTP and Smartcard as strong authentication mechanics. Great, but there is something I do not understand clearly. What is the interest to provide a deployment scenario without computer certificate? It is not realistic from a security point of view to deploy DirectAccess without strong authentication mechanisms and compliance enforcement (NAP).
Note that in the Consumer Preview version of Windows 8 server, there is no interface to configure the enforcement mode of NAP (Audit or enforce). You must configure it manually by editing the server GPO just like in Windows 2008 R2.
Here is some thing that will not change : The Network Location Server. In UAG 2010, we were no longer able to host it on the UAG box. in Windows 8, you can host it on the DirectAccess server and even choose a self-signed certificate.
No change at this step of the configuration wizard, we still need to configure NRPT entries for the clients for internal DNS reference and Network Location Server exception.
Here is something interesting in the Consumer Preview version. Microsoft introduce a new step to configure DNS suffix search list on the client side. That’s helpful . If your Active Directory environment is composed of multiple domains, the wizard will automatically populate the DNS suffix list.
Management server configuration does not change from Windows 2008 R2. This is a regression from UAG 2010 that was able to detect HRA and SCCM server automatically. Maybe Microsoft will fix that before RTM.
Note : My HRA is not located on my Windows 8 server. This is a personal choice. I want NAP to be available for DirectAccess clients but also for desktop on the LAN. It is just a question of multiple Network policies and multiple SHV configuration.
Time to hit the Finish button
Now it’s time to configure our first Windows 8 node for DirectAccess. A simple click on the “Finish” button and you can review your DirectAccess choice and even change GPO names.
Until now, Windows and UAG wizard allowed us to access to the PowerShell script that was generated. It seems that this option is missing in the Consumer Preview edition. Hope to see it back because it is the easiest way to learn about new PowerShell commandlets to manage DirectAccess!
Enable Network Load Balancing
That’s a major change from UAG. In UAG we had to setup an UAG farm, configure it for Network Load Balancing and then configure DirectAccess on the farm. With Windows 8, it is much simple. We just switch our first DirectAccess server to High-availability mode. Our server will automatically become the first node of your NLB farm.
Let’s start by choosing the High-Availability scenario. Just like UAG we are able to choose between Network Load Balancing and Hardware Load Balancing. In this post, I will focus on Network Load Balancing scenario.
Note that in the Consumer Preview edition, you cannot choose what type of Network Load Balancing. You have no other choice that Unicast, witch is not the best one in my opinion.
Our first action is to define the IPv4 address that will be used as the external VIP by the Network Load Balancing feature. Just like for UAG, this address must be on the same IP subnet that dedicated external address of Windows 8 servers.
This is the same for the internal Load Balancing, we need a virtual IP address.
Activating the Network Load Balancing feature is something really easy for the first node. It is no easy no add new nodes to the NLB farm?
Adding a new node to the NLB farm
Adding a new node to the NLB farm is just a simple wizard. It is the same wizard to add or remove nodes.
Adding a new node to the NLB farm requires some configuration just like our first DirectAccess server. Prerequisites for Windows 8 NLB are the same that they were in UAG 2010. Be sure that the IPHTTPS certificate on your new node!
Note that is not possible to use self-signed certificate for IPHTTPS in a high-availability scenario. Now we have two nodes in our NLB farm. It’s time to activate this new configuration.
And finally some PowerShell stuff. if you respect prerequisites, it will work like a charm.
At last some management features
Management capabilities of DirectAccess was one of the most important features expected by my customers. Microsoft made some great efforts. For example, the Remote Access Management Console provides you a global view of you High-Availability DirectAccess infrastructure. Great improvement!
PowerShell commandlets included in Windows 8 also offer a lot of information about your farm configuration.
Note : You can notice that my PowerShell commandlet indicate that Teredo is disabled. Yes, On my NLB farm, there is only one public IP address on each Windows 8 box.
A single “Get-RemoteAccessHealth” commandlet provide status information of all Windows 8 nodes included in our NBL farm. In my situation, everything is operational.
The Remote Access Management Console also offer new reporting capabilities. You can also trace theses information’s in a Windows Internal database (Will requires to deploy the Network Policy Server role on each node).
And you can have the same information’s with a single PowerShell commandlet.
What to say, … It is much more easier to deploy DirectAccess in a high-Availability scenario in Windows 8 than it is with UAG 2010. Microsoft made great effort to make DirectAccess simple to deploy even in a complex scenario. In my opinion, we should consider Windows 8 as a new platform to deploy DirectAccess even with Windows 7 clients.
BenoîtS – Simple and Secure by design but Business and Tablet compliant
Les derniers articles par Benoit (tout voir)
- Forecast de consommation Azure - 30 août 2019
- Gestion de la sauvegarde de vos VM Azure avec des tags. - 18 juillet 2019
- Azure BluePrint Import/Export - 18 juin 2019