Managing DirectAccess in PowerShell will be possible with Windows Server 8. In fact, it is already possible with the Beta version available since end of February 2012. We only need a good documentation for that. Microsoft started to publish some part Direct Access Client Cmdlets in Windows PowerShell. Time to play with DirectAccess.

Warnings first

Information provided in this post are based on my hand-on experience of Windows Server 8 Beta and limited documentations available on Microsoft TechNet. For theses reasons, don’t try to use information provided in this post to setup your DirectAccess infrastructure based on a Beta version on your production environment. Remember, it’s not supported, even by me.

Prerequisites

For this PowerShell demonstration, I will consider that :

• Windows Server 8 beta server is already member of my domain
• Network interface are correctly configured
• Network Interface correctly named and ordered
• Required certificate are provisioned

 

DirectAccess is now a part of a role

It’s no longer a feature but a part of the Remote Access role. Let’s install it with a PowerShell command and associated management tools :

Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools

 

Let’s check Everything is on place

Install-RemoteAccess –Prerequisite

 

Find your IPHTTPS certificate

I’m not a PowerShell expert, there might have some new magic trick in PowerShell V3 but my old trick works for a while :

$IPHTTPS = (Get-ChildItem Cert:\\LocalMachine\My | Where {$_.Subject -like « CN=DA.DirectAccessLab.Fr* »})

Write-Host $IPHTTPS

 

Initial configuration

That a big change for me. I’ve been working with DirectAccess since first beta of Windows 2008 R2. It was long and complex to set it up. And now With a single PowerShell Commandlet, you can do it :

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress DA.DIRECTACCESSLAB.FR -ClientGPOName « DirectAccesslab.Lan\DirectAccess Clients GPO » -ServerGPOName « DirectAccesslab.Lan\DirectAccess Server GPO »-InternalInterface LAN

-InternetInterface INTERNET -NLSURL https://nls.directaccesslab.lan -Force

 

This command will :

• Configure DirectAccess for a full access scenarios with selected network cards
• Users will be using DA.DirectAccessLab.Fr as FQDN for the IPHTTPS protocol
• A Server-side GPO will be created
• A Client-Side GPO will be created
• My Network Location Server is already available on my LAN

 

Let’s check everything is in place :

Get-DAServer

 

As we can see there are some parameters that need to be fixed. Let start with the Client-Side parameters.

 

Client-Side parameters

Let start with the beginning and , let’s configure the security group to be used for the Client-Side GPO of DirectAccess. I will start to add a new security group.

Set-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\DA Clients”

Get-DAClient

 

Before removing the default group proposed by the initial configuration. I want to scope DirectAccess deployment more precisely :

Remove-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\Domain Computers”

Get-DAClient

 

Let’s finish DirectAccess Client-Side configuration by disabling WMI filtering on the Client-Side DirectAccess Client GPO :

Set-DAClient –OnlyRemoteComputers Disabled

Get-DAClient

 

Network Connectivity Assistant

Network Connectivity Assistant is the new Name of the DirectAccess Connectivity Assistant.Let’s configure these parameters with a single CommandLet :

Set-DAClientExperienceConfiguration -PolicyStore « DIRECTACCESSLAB.LAN\DirectAccess Clients GPO » -UserInterface $True -SupportEmail admin@DirectAccesslab.fr  -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName « DirectAccess Connection » -IPSecTunnelEndpoints {PING:2002:836B:2:836B:2; PING:2002:836B:2:5::1}

Get-DAClientExperienceConfiguration -PolicyStore « DIRECTACCESSLAB.LAN\DirectAccess Clients GPO »

 

 

Note : 6to4 addresses used as Dynamic End Point are separated by a “;” and not a ‘,’. It’s normal as I’m French and using a French Keyboard. For this reason, it’s a different separator.

 

Finalizing Server-Side Configuration

Default configuration performed by the Install-RemoteAccess CommandLet is almost perfect, except on one point. Even if Microsoft allow us to configure DirectAccess to operate without IPsec certificate, this configuration does not seems to be compatible with Network Access protection. For this reason, I need to configure witch AC will be used for IPsec Certificate. First, I need to locate my internal ADCS certificate with the following CommandLet :

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like « CN=INET* »})

Write-Host $CA

Set-Daserver -IPSecRootCertificate

 

And configure it in the Server-Side on the DirectAccess group policy :

Set-DAServer –IPsecRootCertificate $CA

Get-DAServer

 

 

Configuring extendted DirectAccess options

My favorite DirectAccess option is Network Access Protection. So let’s configure it with the Set-DAServer CommandLet :

Set-DAServer –HealthCheck Enabled

Get-DAServer

 

Note that this Network Access Protection configuration is not complete as compliance is not required to enable the user IPsec tunnel.

 

Adding some management servers

Because Desired Configuration Manager (DCM) is my new Gameboy I want my DirectAccess clients computers to be managed by it. For this reason, I must add it to the list of the management servers allowed to use the IPsec Infrastructure Tunnel.

Add-DAMgmtServer –MgmtServer SCCM.DirectAccesslab.Lan

Get-DAMgmtServer

 

And Now it should works

Let’s see the state of each component involved in DirectAccess. We can also get server-side statistics and current DirectAccess sessions :

Get-RemoteAccessHealth

 

Conclusion

With Windows 8, Microsoft made big improvement in the manageability of it’s operating systems. PowerShell generalization to all roles and features is really helpful. I will spend some time on these PowerShell commandLet to create a script for my future DirectAccess deployments.

 

This post was updated to include Powershell commands.

 

BenoîtS – Simple and Secure by Design but Windows 8 compliant!

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.

 

Warning

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.

 

Wizard time

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.

 

Conclusion

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

DirectAccess is a great feature of Windows 7. Even if some technical requirements remains obscure (Such as IPv6), they are used to provide a user experience. With Windows 7, user experience was great but it was hard for a user to determine if DirectAccess was really operational or not. It was also difficult for helpdesk to collect troubleshooting information’s. For this reasons, Microsoft provide the DirectAccess Connectivity Assistant.

 

A great tool, but not perfect. This tool is not fully integrated, it’s a dedicated tool such as Network Access Protection “NAPSTAT.EXE”, with it’s own user experience. With Windows 8, Microsoft decided on improve user experience in DirectAccess. A single user experience for all features involved in networks is a good thing. When you click on the network icon in the notification area, you have all network information in a single interface.

 

In my example, my Windows 8 computer is connected to a network and have a Workspace Connection witch is the new name for DirectAccess. This unified user experience also include Network Access Protection. If my computer doesn’t meet security standards, user experience will be as illustrated bellow.

 

In this situation, if you click the continue button, you will be facing the old “NAPSTAT.EXE” user interface that provides technical reasons. Problem, this interface is not user friendly. I’ve seen customers of mine reporting me security problem because information provided were not clear for a normal user.

 

In my opinion, Microsoft should invest more on user experience for Network Access Protection. if Microsoft Provides this Consumer Preview of Windows 8, they expect feedbacks. Do you really think a user can understand this user interface? No!

 

Let’s continue with the user experience. Microsoft invest a lot to integrate the DirectAccess Access Connectivity Assistant in Windows 8. User have access to the new DAC with the properties option on the Workspace Connection as illustrated bellow :

 

One thing we can notice is that the user interface did not really change. Except for one this : The Multisite section. Depending on DirectAccess configuration (Multisite option enabled) user may be able to select the DirectAccess entry point he want to be connected or simply leave the system connect him to the nearest DirectAccess entry point.

 

When generating logs, you will see some new commands that will be helpful for helpdesk teams. Almost all DirectAccess troubleshooting now rely on PowerShell. There are many things to learn from this reports. For example, the "Get-Net-HTTPSConfiguration” Powershell commandlet provide some strange results :

 

Yes it’s now possible to have multiple IPHTTTPS interfaces, that’s how DirectAccess works in multisite. There are many DirectAccess enhancements in Windows 8, most of them are technical enhancements that users will never see. These enhancements were introduced in order to respond to customers that consider DirectAccess a a good solution from a user point of view but complex to deploy from a technical point of view.

 

I will spend some time to explain how Microsoft made DirectAccess easy to deploy. Even if you do not plan to switch to Windows 8 in a short time, Combining Windows Server 8 DirectAccess with Windows 7 will become a deployment scenario in a near future that we must consider seriously.

 

BenoitS – Simple and Secure but Business compliant

During a recent DirectAccess deployment I had to troubleshoot an interesting issue. Internal computers that were supposed to have an ISATAP interface were not able to get the ISATAP prefix from my UAG box. According to my configuration, systems should be able to retrieve this information because they were able to reach my UAG box and were configured as ISATAP clients. There were ISATP interfaces but using FE80 prefix only. After doing some research, I finally decided to go deep dive with some network traces. I What I discovered was interesting. According to network traces, ISATAP client computer try to contact my UAG box and send a Router Solicitation message. But no answer? If we refer to a normal ISATAP behavior, we would have expected a results as illustrated bellow :

 

My UAG box is responding with a Router Advertisement message. That provides the ISATAP prefix. But why does it works on my lab and not in production environment? Because my UAG box is also it’s own ISATAP client and successfully generate it’s own ISATAP address, I knew that it was a backend firewall issue. After performing some check with the network team we discovered that there were no firewall rule for the IP41 protocol that ISATAP use to carry IPv6 payload.

 

Conclusion : Having  complete checklist of all points to validate before going in production is a good practice. Even if this information was available in my network matrix flows, too many information can lead to that kind of misconfiguration.

 

BenoîtS – Simple and Secure by design but Business compliant

Because Windows 7 based DirectAccess clients can be connected to a Windows Server 8 DirectAccess infrastructure, a new version of DAC is required.

 

The product still in beta and only concern Windows 7 based DirectAccess clients connected to Windows Server 8 DirectAccess infrastructure. More information are available in this KB2666914. Files are available at this location.

 

Not sure yet buts this new release might be necessary because of the new probing methods used to validate internal resource connectivity.

 

BenoîtS – Simple and Secure by Design