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

Conférence DirectAccess

Benoît SAUTIERE — Sat, 12 May 2012 08:22:00 GMT

Si le sujet intéresse (ce qui est normal si on lit assidument ce blog), je vais animer une conférence DirectAccess à SUPINFO Paris. C’est programmé pour le vendredi 30 mai à 18h15 dans les locaux de SUPINFO. Au programme, du DirectAccess avec Windows 7 mais aussi avec Windows 8.

Avis aux amateurs.

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

TMG SP2 Rollup 2

Benoît SAUTIERE — Sat, 05 May 2012 12:39:00 GMT

C’est tout neuf de la veille. Le Rollup 2 du Service Pack 2 de TMG. Au menu quelques jusques quelques KB autour de la fiabilité du produit. C’est disponible à cette adresse : http://support.microsoft.com/kb/2689195.

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

DirectAccess and SCCM integration

Benoît SAUTIERE — Mon, 30 Apr 2012 08:45:00 GMT

Debra SHINDER (MVP Enterprise Security) just published two excellent articles about DirectAccess Remote Management capabilities concerning System Center Configuration Manager. Configuring inbound rules to allow Remote Management is only a part of SCCM integration with DirectAccess. Configuring SCCM boundaries and AD sites is also important :

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

Multisite DirectAccess scenario in Powershell

Benoît SAUTIERE — Sat, 21 Apr 2012 11:41:00 GMT

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

Get-DAClient

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

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

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.

Get-NetIPHTTPSConfiguration

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 :

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!

MS12-026 Security Bulletin concerning UAG 2010

Benoît SAUTIERE — Fri, 13 Apr 2012 12:10:00 GMT

It’s not so common but Microsoft published the Security Bulletin MS12-026 concerning Microsoft Forefront UAG. Technically, two reported vulnerabilities were discovered in Microsoft Forefront UAG and Microsoft rated it important. Because there is no possible Workaround or mitigating factors, we should apply the corresponding patch :

ForeFront UAG 2010 Service Pack 1

ForeFront UAG 2010 Service Pack 1 Update 1

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

DirectAccess in PowerShell

Benoît SAUTIERE — Wed, 28 Mar 2012 19:28:00 GMT

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!

DirectAccess High-Availability in Windows 8

Benoît SAUTIERE — Sun, 18 Mar 2012 20:08:00 GMT

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

How Windows 8 improve DirectAccess user experience

Benoît SAUTIERE — Sat, 10 Mar 2012 16:49:00 GMT

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

The Missing ISATAP prefix case

Benoît SAUTIERE — Thu, 08 Mar 2012 20:23:00 GMT

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 this network trace, 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

Vous avez manqué la session DirectAccess des techdays?

Benoît SAUTIERE — Thu, 08 Mar 2012 19:56:00 GMT

On sait, la salle était trop petite pour accueillir tout le monde, c’est pas la première fois qu’on me le dit depuis la fin des Techdays. En attendant l’année prochaine et peut être une session dans un grand amphithéâtre (Tellement à faire découvrir sur le DirectAccess avec Windows 8), vous êtres invités à revoir la session : Retour d'expérience sur DirectAccess, bonnes pratiques, dépannage (SEC2307).

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

DirectAccess Connectivity Assistant 2.0 Beta

Benoît SAUTIERE — Thu, 01 Mar 2012 04:27:00 GMT

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

Windows Server 8 Consumer Preview disponible

Benoît SAUTIERE — Wed, 29 Feb 2012 08:00:00 GMT

C’est pas souvent que je peux dire qu’une insomnie à du bon, mais ce matin (6h00 à Seattle), je peux le dire :

Pour le serveur : http://technet.microsoft.com/en-us/evalcenter/hh670538.aspx
et plus généralement : http://bink.nu/news/download-windows-8-consumer-preview-now.aspx

Dommage pour l’accès Internet de mon hôtel. RIP

Simple and Secure by Design but Business compliant

TCPv4 based applications with DirectAccess

Benoît SAUTIERE — Sat, 11 Feb 2012 11:34:00 GMT

Client-side Applications used on DirectAccess laptops must be bale to communicate with their server-side with IPv6. In most case, theses applications does explicitly require IPv4 based connectivity. But for some of them they only use TCPv4 based connections. In my special case, my client-side application check for IPv4 based connectivity to communicate with it’s server-side part.

Because of this, my application does not work with DirectAccess. This does not means it is impossible. In my case, my application need to contact a Windows 2003 SMTP service and it works in IPv6 thanks to DNS64/NAT64.

This was a real problem for my customer because it was one of his major business application. I was looking for a solution when I found the PORTPROXY feature provided by my favorite network took : NETSH.EXE.

Let’s have a look at the V4toV6 interface type. It is possible to redirect an IPv4 TCP based connection to a IPv6 destination :

Problem, with DirectAccess, we have an IPv4 based connectivity but this may charge each time I need to connect to my application. This is right, but we all have an IPv4 address that never change located on our computer, the loopback interface. So let create an V4toV6 interface that will listen on my loopback interface for my port and connect it to the same port on the server-side part of my application.

Let’s check this new interface is operational. We can list it.

But most important : Does it works?

yes it works!

This solution looks great but it is only a workaround. You should contact your application editor for a fix. But watch out, there are some limitations.

Limitations of this approach

First limitation of this solution is that it only apply to TCP based connections. Maybe one day, UDP will be supported.

Second problem, user must have Administrator level privilege to create the interface as illustrated bellow :

And Finally, the NAT64 limitation. NAT64 address structure is composed as illustrated bellow :

Problem, the EUI64 Interface ID include a random part because it is a temporary address. This means that the IPv6 address that will be configured for the PORTPROXY Interface will change. This means, you must recreate the interface each time you want to use this type of address.

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

DirectAccess session retour d’expérience

Benoît SAUTIERE — Thu, 02 Feb 2012 23:21:00 GMT

Ca y est, on a le premier slide et le dernier. Non, c’est un peu plus avancé que cela. Donc Du DirectAccess, de la bonne humeur, des démonstrations (pas celles de l’année dernière). Bref, la synthèse de tout ce qu’il faut savoir sur DirectAccess en une heure de temps.

Et comme une heure de temps, c’est toujours trop court, je rappelle qu’il y aura des ouvrage DirectAccess à gagner (et non jetés dans la salle ).

Donc “venez tous à la session!

BenoîtS – Simple and Secure by Design but Tablet compliant

Mais alors, il est mort chuck Norris?

Benoît SAUTIERE — Thu, 02 Feb 2012 20:17:00 GMT

Je n’ai pas pu résister, c’est la saison des techdays. Mais Facebook qui annonce la mort de Chuck Norris. Bien souvent, un titre racoleur cache bien autre chose. Dans le cas présent, l’objectif est tout simplement financier en attirant le maximum de monde sur des pages publicitaires.

Bref, voila un travail pour Check Norris. Car Chuck Norris n’a pas peur des malware. ce sont les malware qui ont peut de Chuck Norris.

Benoits – Simple and Secure by Design but Tablet compliant!