Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]

Simple, yes, Secure Maybe, by design for sure, Business compliant always

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

Multisite DirectAccess scenario in Powershell

Multisite is a very interesting scenario that was complicated to deploy with Windows 7 and Forefront UAG. If this challenging scenario does not scared you, have a look at this Edge Man post. Technically speaking, it was also possible to achieve a “similar” configuration with a Global Server Load Balancing configuration using F5 Big-IP for example. With Forefront UAG 2010, we had load-balancing capabilities with Network Load Balancing and Hardware Load Balancing but it was long to setup. Have a look at my high-availability blog post series if you want to compare to this blog post!

 

In Windows server 2012, multisite will become (this post is written with the Consumer Preview released in February 2012!) a much more easier deployment. What an interesting challenge to deploy it with PowerShell only. First, let’s see my configuration  :

MULTISITEVISIO 

We have two sites having their own Windows 2012 server. The challenge is to setup the DA1 server as a DirectAccess server, convert it to multisite and and add DA2 as a new Entry Point for my Multisite configuration. Now let’s switch to PowerShell!

 

Initial DirectAccess configuration

Let’s start with my first DirectAccess server setup. It’s name is DA1.DirectAccessLab.Lan we start with the role installation :

Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools

ADDFEATURE0

 

In order to be sure that everything is operational, let’s check it with a single PowerShell command : Install-RemoteAccess –Prerequisite

ADDFEATURE1

 

I will need an IPHTTPS certificate on DA1.DirectAccessLab.Lan. Public name record in my certificate will be DA1.DirectAccessLab.Lan. Let’s check that my certificate is present in the computer store with the following command :

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

Write-Host $IPHTTPS

IPHTTPS1

 

Now, it’s time to configure our first DirectAccess server with a single PowerShell command :

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress DA1.DIRECTACCESSLAB.FR -ClientGPOName "DirectAccesslab.Lan\DirectAccess Clients GPO" -ServerGPOName "DirectAccesslab.Lan\DirectAccess Servers GPO"-InternalInterface LAN-InternetInterface INTERNET -NLSURL https://nls.directaccesslab.lan –Force –PassThru

INSTALLREMOTEACCESS0

 

Server-side configuration is almost terminated. We need to configure Certification Authority to be used for IPSEC tunnels authentication. It is mandatory for multisite deployments, just like having a real IPHTTPS certificate for each entry point. The following PowerShell command will configure this :

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

Write-Host $CA

Set-Daserver -IPSecRootCertificate $CA -PassThru

FINALIZESERVER1

 

Now let’s switch to the client-side configuration with the Following PowerShell commands :

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

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

Set-DAClient –OnlyRemoteComputers Disabled

Get-DAClient

CLIENTSIDE

 

Client-side configuration is almost complete, we just need to configure some settings for end-user experience for the Network Connectivity Assistant. PowerShell commands bellow will configure it with an HTTP type probe located on a domain controller : 

Set-DAClientExperienceConfiguration -PolicyStore "DIRECTACCESSLAB.LAN\DirectAccess Clients GPO" -UserInterface $True -SupportEmail HelpDesk@DirectAccesslab.fr -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName "DirectAccess Connection" -PassThru

SETDACLIENTEXPERIENCE

 

Our first DirectAccess server is now operational. Let’s check that with a Get-RemoteAccessHealth command :

GET-REMOTEACCESSHEALTH0

 

If you need more explanations on this part, have a look at my DirectAccess in Powershell blog post.  Now we are ready for Multisite!

 

 

Enabling Multisite

We have a standalone server that must be converted as the first entry point of a Multi-site DirectAccess configuration. Each DirectAccess Server (or High-available group of DirectAccess servers) is considered as a DirectAccess Entry point. Let’s convert to Multi-Site :

Enable-DAMultiSite -EntryPointName "EMEA Headquarter" -ComputerName DA1.DirectAccesslab.Lan -ManualEntryPointSelectionAllowed Enabled -Name "DirectAccesslab Multi-Site Infrastructure" -PassThru – Force

ENABLEMULTISITE

 

Multi-site configuration is enabled with a single entry point named “EMEA Headquarter”. The  Get-DAEntryPoint command will provide some details on this entry point  :

GETDAENTRYPOINT1

 

Not many information. This entry point is not GSLB enabled and include a single server. Let’s have a look at this entry point with the Get-DAServer PowerShell command :

Get-DAServer -EntryPoint "EMEA Headquarter"

GETDAENTRYPOINT2

 

We have the same information as in standalone configuration. From a server point of view, there is not much more difference. At this point our only requirements are :

  • Do not use self-signed certificate for IPHTTPS
  • Enable computer certificates

 

By now we have operational Multisite DirectAccess infrastructure And that's all for Multisite activation!

 

Adding a new entry point

Now come the most interesting part of this blog post : How to add a second entry point remotely. At the beginning of this step, my DA2.DirectAccessLab.Lan server is :

  • Joined to the DirectAccessLab.Lan Domain with a LAN named interface
  • Configured with a public interface named INTERNET with a public IP address
  • Having a public IPHTTPS certificate with DA2.DirectAccessLab.fr as subject name

 

Here are the only prerequisites that wont be performed remotely! Just like our first DirectAccess server, we need to install roles. Let’s use PowerShell remoting capabilities : Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools -ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE2

 

And check it remotely : Install-RemoteAccess –Prerequisite –ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE3

 

Before performing the magic trick, we must be sure that’s my IPHTTPS certificate for DA2.DirectAccessLab.Fr is present on my remote server :

$IPHTTPS = Invoke-Command –ComputerName DA2.DirectAccessLab.Lan –ScriptBlock {(Get-ChildItem Cert:\LocalMachine\My | Where {$_.Subject –Like “CN=DA2.DirectAccessLab.Fr*”}}

Write-Host $IPHTTPS

IPHTTPS2

 

And now, the magic trick. How to add a new DirectAccess Entry Point in an exiting Multi-site configuration remotely. As long as all prerequisites are already present, it’s a simple PowerShell Command :

Add-DAEntryPoint -Name "Backup Site" -ConnectToAddress DA2.DIRECTACCESSLAB.FR -InternalInterface LAN -InternetInterface INTERNET -ServerGPOName "DirectAccessLab.Lan\DirectAccess Backup Servers GPO" -RemoteAccessServer DA2.DirectAccessLab.Lan -PassThru – Force

ADDDAENTRYPOINT2

 

One thing we can notice is that we need an additional GPO to configure our new server. Each Entry point must have it’s own dedicated GPO. By now, our DirectAccess multi-site infrastructure have two entry point. The Get-DAMultiSite also report that users will be able to select the entry point they want to use. Windows 8 is able to connect to the first available entry point, but it’s not capable to really detect witch one is the closest from the client. Global Server Load Balancing feature was designed for that!

GETDAMULTISITE

 

If we take a look at our new entry point configuration with a Get-DAServer –EntryPoint “Backup Site” PowerShell command we can notice that there a much less information than for the first entry point. Information such as Internal Interface, InternetInterface or SSLCertificate are not provided. That’s must be a bug in the Consumer Preview version because these information are available if you run the same command on the remote server! That’s not a bug, it’s by design. Theses information will be available if you use the same Powershell CommandLet querying the server name and not the entry point.

GETDASERVERBACKUP

 

Let check everything

Everything seems to be operational on my first entry point. Some services are disabled but it’s normal (no 6to4 or Teredo support, no management server declared, no more OTP, …).

Get-RemoteAccessHealth –EntryPoint “EMEA Headquarter”

REMOTEACCESSHEALTH1

 

But on my second entry point we can notice one minor difference with ISATAP. My DA2.DirectAccessLab.Lan is not considered as an ISATAP router. It’s only an ISATAP client from my DA1.DirectAccessLab.Lan server.

Get-RemoteAccessHealth –EntryPoint “Backup Site”

REMOTEACCESSHEALTH2

 

In my opinion, it’s a bug on my lab. During DA2.DirectAccessLab.Lan configuration, my server already had an ISATAP interface properly configured. That’s must be why there is no ISATAP router on my server. This should not append in production environment (My lab need to be fixed on this point!)

 

And now from the client-side perspective

From a Windows 8 point of view, a DirectAccess Multi-site infrastructure is just two URL, one for each Entry point. So Multi-site only rely on IPHTTPS transition protocol. That’s why Teredo support is not active on my infrastructure (and because each entry point have only one IPv4 public address!). Windows 7 only support one URL for IPHTTPS interface, that’s why legacy operating systems cant use Multi-site.

Get-NetIPHTTPSConfiguration

GETNETIPHTTPSCONFIGURATION

 

It’s cool to have two entry point, but witch one is currently used? Simple : Get-NetIPHTTPSState

GETNETIPHTTPSSTATE

 

Back to server-side

Multi-site infrastructure is now operational. We need more than an active IPHTTPS interface to validate that point. We need to be able to track IPSEC sessions :

Get-RemoteAccessStatistics | Format-List

Get-RemoteAccessStatisticsSummary | Format-List

FINALSTATS

 

At last, the console view

Now we have an operational DirectAccess infrastructure with Multi-site capabilities. From the console point of view, here what’s it look like :

CONSOLEVIEW

 

Conclusion

I’m sure this deployment process can be fully automated (With PowerShell jobs). If you compare with my high-availability blog post series on Forefront UAG 2012, it will be now more easier to deploy DirectAccess in a high availability scenario and avoiding complex networking issues with Windows Server 2012. Infrastructure described in this post is not compatible with legacy clients (yes Windows 7 is a legacy client!) but there only few changes to allow these clients to connect to an entry point.

 

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