Archives mensuelles : octobre 2012

UAG NLB modes precision

At RTM times of Microsoft Forefront UAG 2010, only Unicast mode was supported for Network Load Balancing scenarios. Since SP1, Multicast support was added but it was not clear for what scenarios. A blog post from Ben Ari provide a clear position about unicast/multicast support in Network Load Balancing.

image

 

One thing to remember about DirectAccess is that both mode are supported

 

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

Interesting DirectAccess scenario

DirectAccess can be used in many scenarios. With Windows 8 we will be able to offer new scenarios to customers. An interesting blog post of Jonas Blom show one of these new scenarios. Technical details are provided on his blog, so I will just develop the scenario you can apply it to.

 

Sometime Windows may crash (shits always append at the worst moment ). Most of the time this append when users does not have access to a IT support technician. In this situation, it would be a good idea to provide a previously prepared USB key with Windows To Go. The challenge will be to perform the domain join process in a secure way. We have multiple options :

  • Ask another colleague to get the ODJ package
  • User could be able to order and retrieve the ODJ package from any computer/smartphone connecting to a secure portal based on UAG

Once we get the file we can perform an automated domain join for the Windows to Go (Domain join, certificate provisioning and GPO). This solution provide a temporary solution until a IT technician can solve the problem.

 

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

DirectAccess Challenge Series : NAP strategy based on location

What Changed with Windows Server 2012?

With Windows Server 2008 R2, yon can configure NAP enforcement. NAP deployment is under your responsibility. With Forefront UAG 2010, Network Access Protection configuration can be performed by the UAG wizard and host the Health Registration Authority on the server.  But with Windows Server 2012, there is a small change documented here :

image

 

It’s no longer supported to host the Health Registration Authority with the (URA) Unified Remote Access role. This means we have two solutions. Having the HRA published on Internet or using an internal HRA. For the first solution have a look at this post from the cable Guy (aka Joseph Davies author of the Understanding IPV6 book series). For the second solution, let’s go deeper into NAP.

 

Back to the NAP roots

Technically speaking, its not a problem to combine DirectAccess with NAP. URL corresponding to the HRA must be reachable through the first IPSEC infrastructure tunnel. First, we must enable Network Access Protection at DirectAccess Level :

ENABLENAPINTERFACE

 

In Picture above, we see that enabling Network Access Protection is just a checkbox, but this checkbox is available only if you are using computer certificates for tunnel authentication. Deploying DirectAccess without certificate is a cool feature for quick deployment but if you want extra-cool feature, don’t forget to select an internal CA that will be providing certificate to be used for tunnel authentication .

 

If you want to know, the “Enforce corporate compliance for DirectAccess clients with NAP” status just run a Get-DAServer Powershell as illustrated bellow :

GETDASERVERHEALTHCHECK

 

When Network Access Protection is enabled, some small “changes” are performed into the DirectAccess Policy-DaServerToCorp connection Security Rule (on server-side). Let’s have a look in with an “old–school” way based on NETSH.EXE.

SHOWNAPDACONFIG

 

A specific certificate delivered by the Health registration Authority is required for user-tunnel establishment. This means that HRA URL must be reachable from the first IPSEC tunnel. For this reason, we must add this URL to the infrastructure server list.

APPSERVERSLIST

 

Is is possible to use a single internal HRA?

Technically speaking it’s not a problem. You can have a single HRA but remember one thing. URL will be reachable from DirectAccess clients located on Internet but also DirectAccess clients connected on Intranet. That’s a big (bug?) change. In a DirectAccess project, you expect to have computer compliance checking for External clients, but you may not expect to apply the same compliance criteria for all computers. Unless you are engaged in a global computer compliance enforcement project, you have a problem. It would be great to have different NAP policy based on your location (Internet/intranet). Let’s have a look at NAP filtering capabilities.

 

Network Access Protection filtering capabilities

Let’s have a look at some Network Access Protection Design considerations :

image

 

The only way we have to filter  a DirectAccess client from another from the NAP Point of view is the RADIUS client option. This means, that DirectAccess clients will use a dedicated HRA and internal clients will use another HRA. These two HRA will be considered as Radius clients from a central Network Policy Server that will use the Access Client IPv4/6 address condition. Technically speaking, that might be a solution but :

  • How can we be sure that a computer connected on Intranet will not use HRA dedicated to DirectAccess clients connected on Internet?
  • And more important, how can we be sure that a DirectAccess client connected on Internet will not use HRA dedicated to internal clients?

 

The Multiple NAP Challenge made simple

Specialize Health Registration authorities based on computer security level is a good option. Scenario explained before is technically possible, just complex to setup in a small DirectAccess deployment. The real challenge is how to be sure that NAP enabled client will always use the good HRA. DirectAccess have a solution for that. It’s always a question of name resolution capabilities.

 

In my scenario, I will dedicate a NPS/HRA to intranet clients and another one to Internet clients. Each NPS will have it’s own configuration (I said simple ). NAP enabled computers (DirectAccess or Not) will  be able to use a HRA based on their location (Intranet/Internet).

 

First we need to be sure that DirectAccess clients connected on Internet cannot reach HRA dedicated to Intranet clients. With DirectAccess, we have built-in host resolution blocker capabilities : Name Resolution Policy Table :

NRPTCONTENT

 

If I block name resolution for my internal HRA URL (HRALAN), I’m sure that DirectAccess clients will never be able to use it when connected on Internet. Great thing. But we also need that internal clients cannot resolve DNS host name for the DirectAccess Dedicated HRA (HRADA).

That’s more tricky. In my scenario, I consider that my DirectAccess infrastructure is located on a specific network in DMZ. For security reason, servers in this network can only use Read-Only domain Controllers located in the same network. So internal clients use  different DNS servers. In this case, I will use another host resolution blocker capability : DNS GlobalQueryBlockList. In illustration bellow, you can see the content of the GlobalQueryBlockList I configured on all DNS servers located on Intranet :

DNSCMDINFO

 

We can see the standard WPAD and ISATAP host blocked for DNS resolution. The HRADA host is my HRA dedicated to DirectAccess clients. If I add it to the GlobalQueryBlockList, I’m sure that clients connected on Intranet will never be able to reach it.

 

And last NAP client configuration. All my NAP clients will share the same Trusted Server group List including all HRA available in my environment (simple by design ).

NAPCLIENTCONFIG

 

DirectAccess clients connected on Internet will only be able to resolve “HRADA” hostname. Internal clients (DirectAccess enabled on not) will be able to resolve “HRALAN” only.

 

How fast is it to switch from an HRA to another?

Good question, after some tests on my lab and performing some research, I found the solution here : http://technet.microsoft.com/en-us/library/dd125359(v=ws.10).aspx

image

 

Since Windows Server 2008 R2 the initial timeout for HRA response is four seconds. If you add DirectAccess tunnel negotiation and network latency, I would be up to forty seconds when a DirectAccess clients connected on Intranet network switch to Internet network.

 

BenoîtS – Simple and secure by Design but Business compliant

Security Compliance Manager 3.0 Beta

Security Compliance Manager is a Microsoft solution Accelerator tool. The main objective of this tool is to provide security baselines for Microsoft operating systems  and applications and the ability to develop new security baselines. We will be able to use these baselines from a simple local Group Policy up to Desired Configuration Manager format.

 

The new version of the tool provide security baselines for :

  • Windows Server 2012
  • Windows 8
  • Internet Explorer 10
  • Office 2010

SCM3

 

If we take a closer look at Windows 8 or Windows Server 2012 nodes, we will find Windows 8 and Windows Server 2012 security guides. Great.

W8SECGUIDE

 

So this tool is a must to have in a Windows 7/8 deployment project.

 

Simple and Secure by Design but Business compliant

If you are DirectAccess addict, order this book

I discovered DirectAccess at TechED Barcelona 2008 edition, we can compare it to a technology Lego. I started with lab building, projects,  and delivering sessions at Microsoft Techdays since 2009. I even wrote a book on DirectAccess with Lionel LEPERLIER. We wrote it because there was no reference book on this subject, (except Understanding IPv6 third edition that include a dedicated chapter on DirectAccess).

 

By now there is a reference book on DirectAccess written by Erez Ben-Ari and Bala Natarajan. This book cover all aspects of DirectAccess (except project management).

 

book

 

So like me, if you are a DirectAccess fan boy, order this book now.

 

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

PSPing a new tool from Mark Russinovich

SysInternal tools are a great suite of tool provided by Mark Russinovich and his team. Each tool of this collection is a valuable tool. PSPING.EXE is not an exception.

“PSPING.EXE is a a command-line utility for measuring network performance. In addition to standard ICMP ping functionality, it can report the latency of connecting to TCP ports, the latency of TCP round-trip communication between systems, and the TCP bandwidth available to a connection between systems. Besides obtaining min, max, and average values in 0.01ms resolution, you can also use PsPing to generate histograms of the results that are easy to import into spreadsheets.”

 

SNAGHTML2a2e60

 

PSPING.EXE is compatible with IPv6 that is useful with DirectAccess.

 

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

Enterprise Security MVP renewed : Four in a row!

One more time and for the fourth year . I’m pleased to announce my Enterprise Security MVP renewal. New year and new challenges. While reviewing my post published this year I see a lot of DirectAccess. I will continue with DirectAccess, (There are so many things to do with DA and PowerShell ) but I will start looking a new subject of Interest : Cloud and Security.

 

Benoîts – Simple and Secure by Design but Business compliant