Archives mensuelles : juin 2014

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  :


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


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


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


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


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


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




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 -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName « DirectAccess Connection » -PassThru


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


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



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  :



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 »



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 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



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



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



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



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!



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.



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”



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”



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.




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



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



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 :




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!

MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege

Les GPO de préférences sont une évolution intéressante des GPO introduite avec Windows 2008. Cependant, il y a une petite faiblesse que Microsoft a enfin corrigé. Les GPO de préférences peuvent être utilisées pour créer/ mettre à jour des comptes de services sur les systèmes gérés. Problème, il faut bien stocker le mot de passe dans la GPO. Avec un peu de recherche dans le répertoire SYSVOL d’une GPO utilisant la fonctionnalité incriminée, on trouve le fichier GROUPS.XML :


Déjà en 2009, l’équipe Group Policy reconnaissait que les mots de passe manipulés par les GPO de préférence étaient plus “masqués” que “chiffrés” et qu’il fallait bien évaluer le risque. A la vue de l’illustration ci-dessus, on pourrait penser que le mot de passe est bien chiffré. Vrai, il est chiffré en AES 256 et faux car la clé est disponible sur le MSDN. Pour vous en convaincre, exécutez le script Get-SettingsWithCPassword.ps1 mis à disposition avec la KB2962486 (il faut toujours lire un KB jusqu’au bout).


Dans l’illustration ci-dessus le script a identifié une GPO avec un mot de passe masqué. Il a juste été nécessaire d’accéder à mon répertoire SYSVOL ou a une sauvegarde des GPO. Pour rappel toute GPO est librement accessible en lecture par défaut. 

Installer la KB2962486 ne fait que bloquer l’usage de la fonctionnalité, cela ne fait pas le ménage à votre place (d’ou l’intérêt de lire une KB jusqu’au bout). Le problème, c’est qu’il y a des développeurs Powershell talentueux qui ont développé des scripts plus complet, voire même trop  :


Dans l’exemple ci-dessus, le script va jusqu’à révéler le mot de passe associé au compte “SECOURS_ADM”. Pour rappel, cette information est en libre accès (sauf si on retire le droit “read” sur la GPO pour les utilisateurs).

Que fait la KB alors? Ben elle corrige l’interface d’édition des stratégies de groupe de préférence pour nous empêcher d’utiliser la fonctionnalité.


C’est bien mais pour cela, il faut s’assurer de patcher tous les systèmes sur lesquels un administrateur utilisera l’éditeur de stratégies de groupes pour manipuler son contenu. Cela implique donc de patcher :

  • Les contrôleurs de domaine (GPMC est nativement installé)
  • Les serveurs membres (GPMC est potentiellement installé)
  • Les stations de travail (GPMC peut être installé si les RSAT sont installés)


En conclusion :

  • Abandonnez immédiatement l’utilisation des GPO de préférence pour manipuler les comptes & mots de passe
  • Faites la chasse aux stratégies de groupe utilisant cette fonctionnalité
  • Installez le correctifs sur tous les systèmes ou GPMC est potentiellement installé (pour éviter qu’un Administrateur ne recréé une GPO de préférence avec un mot de passe)
  • Formez vos Admins pour ne plus utiliser cette fonctionnalité!


Enfin, si c’est pour gérer le mot de passe Administrateur local de vos stations de travail, la solution ADMPWD est faite pour cela.


BenoitS – Simple and Secure by Design but Business compliant