Archives de catégorie : Windows 7

Microsoft n'oublie pas la sécurité de ses OS "Legacy"

Avec le cycle "Rapid release" de Microsoft ces derniers temps pour les produits "On premise", on pourrait penser que Microsoft oublie un peu ses systèmes "Legacy". On parle ici de Windows 7 et Windows Server 2008 R2, des OS pas si vieux que cela. Pourtant entre temps, on a déjà eu droit à :

  • Windows 8 / Windows 2012
  • Windows 8.1 / Windows Server 2012 R2
  • Et bientôt Windows 10 preview / Windows Server 10 preview

Donc oui, Windows 7, c’est super véritablement un OS "Legacy" pourtant, il a encore une belle vie devant lui.

    clip_image001

Même si Microsoft pousse en avant ses nouveaux systèmes d’exploitation et les nouvelles fonctionnalités de sécurité, il n’en oublie pas moins les systèmes "legacy". Ce mois-ci, dans le cadre du processus de livraison mensuel des correctifs, Microsoft a mis à disposition :

Initialement, ce sont des fonctionnalités de sécurité qui sont disponibles que depuis Windows 8. C’est un mouvement intéressant de la part de Microsoft, l’éditeur n’oublie pas le système d’exploitation les systèmes d’exploitation les plus déployés.

 

Note : En date du 17/10/2014, Microsoft a retiré le correctif KB2949927. Il semblerait qu’il soit source de problèmes rencontrés par certains utilisateurs suite à son installation. On attendra donc un peu avant de pouvoir le déployer.

 

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

WorkFolders pour Windows 7

Workfolders est une feature propre à Windows 8/8.1. Elle apportait un plus pour les scénarios de BYOD. l’équipe stockage chez Microsoft vient d’annoncer la disponibilité de WorkFolders pour Windows 7.

 

Prenez le temps de lire le billet avant de vous lancer dans l’installation car il y a quand mêmes quelques subtilités avec la version disponible sous Windows 8 :

  • Uniquement les systèmes Windows 7 SP1 connectés au domaine
  • L’absence de l’EAS Engine permettant de gérer le verrouillage et d’autres paramètres
  • Quelques subtilités lors de la création du SyncShare

 

Voila une cool feature que je vais pouvoir proposer avec DirectAccess .

 

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

DirectAccess and Windows Remote Assistance

For those of us who deployed legacy DirectAccess clients (yes Windows 7 is a legacy operating system) with Windows Server 2012 based DirectAccess we encountered the problem of Windows Remote Assistance witch was not working. That sound strange because it was working when the DirectAccess clients was connected a legacy DirectAccess Infrastructure (Yes, Forefront UAG 2010 is a legacy DirectAccess platform).

 

The Following KB2912883, provide a hotfix for Windows 7. Technically, the root cause is located in the Windows Remote Assistance module witch did not recognize the new IPv6 prefix (FD00::/8) introduced with Windows Server 2012 based DirectAccess infrastructure.

 

So don’t forget this KB during your next DirectAccess migration project from UAG.

 

BenoîtS – Simple and Secure by Design

A KB list to keep in mind for your DirectAccess projects

Even if DirectAccess is now much more easier to deploy with Windows Server 2012, there still have some “cases” where Microsoft help is required. Jason Jones (Former Forefront MVP) updated his “Hot list” recently. Keep a bookmark on this list. This can save a lot of time during your next DirectAccess deployment.

 

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

Windows 2012 DirectAccess legacy client considerations

Let’s start this new year with a resolution : Correct previously published blog post including not accurate information (Thank you Alex ).

It might appear strange but with Unified Remote Access included with Windows Server 2012, Windows 7 DirectAccess Clients are considered as legacy clients. Legacy clients can connect to a Windows Server 2012 based DirectAccess infrastructure if we enable some compatibility features that I will describe in this blog post.

By default, A Windows Server 2012 based infrastructure is configured to operate in Kerberos proxy mode. In this default configuration, only Windows 8 clients can connect. In Kerberos Proxy mode, there is a single IPSEC Tunnel and certificates are not required. That’s a new DirectAccess deployment option available with Windows Server 2012. If you want to support Windows 7 clients, don’t forget to enable this checkbox :

ENABLEW7

When you activate the “Enable Windows 7 Clients computers to connect Via DirectAccess” checkbox, computer certificates become mandatory. That’s the minimum requirement to support Windows 7 Clients in a Windows Server 2012 based DirectAccess infrastructure.

Single-Site/Multiple site impact

Multi-site feature is introduced with Windows Server 2012. From user point of view a DirectAccess clients can have multiple entry point for a DirectAccess infrastructure. User can even select witch entry point to use. Unfortunately, this feature is only compatible with Windows 8. For this reasons, Windows 7 clients connecting to a multi-site DirectAccess infrastructure need a dedicated group policy that provide a single entry point for the DirectAccess infrastructure. As a conclusion, we cannot have Windows 7 and Windows 8 clients members of the same group in Multisite deployment (This possibe when Multi-site option is not enabled).

Windows 7 clients are considered as legacy clients. This means that :

  • They still rely on Teredo for DirectAccess
  • They need an IPSEC certificate to establish IPSEC tunnels
  • They will have their own dedicated DirectAccess configuration
  • They need a dedicated security group

From a DirectAccess point of view, there are two kind of clients,so there are two client-side GPO. This also means that there are two security group. You can find it with the Add-DAclient PowerShell command illustrated bellow :

ADDDACLIENTHELP

Great, but if we try to configure the “DownlevelSecurityGroupNameList” parameter with a single-site DirectAccess deployment, you will have the following error message :

ADDCLIENTERROR

In multisite deployments scenarios, we need separate security groups, one for Windows 8 clients and another one for legacy clients. Your Multi-site deployment can be composed of at least a single site. Legacy clients will only be able to connect to one entry point. Let’s switch our DirectAccess infrastructure to Multi-site :

ENABLE-DAMULTISITE

One important thing to notice with multi-site mode : you must separate Windows 7 and Windows 8 clients computers into different security groups because each operating system will have it’s own dedicated client-side GPO. Once we have at least one DirectAccess entry point we can configure it to support legacy clients with the Add-DAClient as illustrated bellow :

ADDCLIENTOK

By now, we have a Windows Server 2012 DirectAccess infrastructure witch is almost ready to accept legacy DirectAccess clients. Let’s have a look at the result of a Get-DAServer command :

GETDASERVER0

Server configuration seems to be fine. I have a certificate for IPHTTPS and an root certificate authority selected. With Windows 7, you still need certificates for DirectAccess. I would say that you always need certificates for DirectAccess because you always deploy it with Network Access Protection. But there is something bad with my configuration : The Teredo state parameter witch is disabled. When disabled (because no consecutive IPv4 public addresses or parameter disabled), client-side and Server-side GPO does not include Teredo configuration. With Windows Server 2012, this is no longer a problem.

If you configure your Internet-facing with a single IPv4 address, Teredo cannot be used (from the server point of view). Two public IPv4 addresses are always required on server side. Because Windows Server 2012 now allow to deploy DirectAccess behind a NAT device, Teredo is no longer a requirement.

Technically speaking you can enable it with the following PowerShell command, but its not mandatory :

ENABLETEREDO

And now, you remember why you need to create inbound rule for ICMP traffic . Now my configuration is fully operational from a technical point of view. But from user perspective there is something missing : The DirectAccess Connectivity Assistant 2.0. It’s included with Windows 8 and configured by the Client-side GPO but not for Windows 7, and more important, version 2.0 is required. This version is only supported when DirectAccess client is connected to a Windows Server 2012 based DirectAccess infrastructure. So don’t forget to create an additional client-Side GPO to configure the DirectAccess Connectivity Assistant for Legacy clients.

Edit : After some research and advices from Jason Jones, Teredo is a mandatory requirement for the Windows Server 2008 R2/UAG DirectAccess generation, not for Windows Server 2012. If Teredo is not operational for the DirectAccess client, IPHTTPS will be fine and even better with Windows Server 2012 based DirectAccess infrastructure. For many clients, having Microsoft box connected on LAN and Internet was not acceptable from a Security point of view. With Windows Server 2012, this is no longer a problem.

Thank you Jason.

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

DirectAccess KB to keep in mind

I was involved in multiple DirectAccess projects. Many projects started with a simple proof of concept and continue with a complete project including final tests in production. This is the most critical phase of the project. Everything must work. Sometimes, I had to face strange behavior of Windows 7 laptops when they come back to LAN, resuming from hibernation. Sometime it worked, sometime not.

 

To avoid such problems, have a look at KB2680464. According to this KB, the corporate location detection functionality might be disabled and it not reactivated witch lead to do not detect domain connectivity.

 

For your next project, just think to deploy this KB on Windows 7 computers.

 

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

DirectAccess Connectivity Assistant 2.0 is available

I’ve been blogging on DAC 2.0 since  RC version, and Beta version. Now DAC 2.0 is ready to be deployed on all Windows 7 (Enterprise or Ultimate editions) that will connect to a Windows Server 2012 DirectAccess infrastructure. KB2666914 have been updated to include latest information about it.

 

Note DCA 2.0 is not supported on Windows 7-based client computers that connect to a network by using the DirectAccess feature in Forefront UAG or in Windows Server 2008 R2.

 

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

DirectAccess challenge series

For me DirectAccess was a technical challenge including multiple technologies and involve multiple teams in a same project. I was involved in multiple DirectAccess deployments in witch customers choose DirectAccess for it’s user-experience focus rather than for the technical solution (until now none of the network teams I worked with is ready for a large IPv6 deployment ).

Customers witch experienced DirectAccess are satisfied of the solution. Some of them want more than the end-user experience. That’s why I start this series of DirectAccess post : The DirectAccess Challenge series. Many times customers asked me for additional configuration for their DirectAccess deployments. Most of the time, it’s simple and “by design”/built-in in the product itself or just require a little extra time. But for some customer requests, it’s a real challenge I had face to. Let’s start with our first DirectAccess challenge : Securing Access to a selected set of servers. This means mixing Direct Access and IPsec isolation.

From a high level point of view, that kind of architecture would look like that (I know, there is no back-end firewall, …). According to Microsoft technical documentation, architecture illustrated bellow is called “Selected Server Access” :

Visio

 

According to Microsoft TechNet, the Selected Server Access have multiple benefits and limitations :

image

 

Now let’s see if my knowledge and experience with DirectAccess allow me to to that. Until today, it’s not documented in TechNet but many of my customers were interested with that deployment scenario.

 

Foundations

From the beginning, let’s start with the foundations. To make this as simple as possible, I will use a “simple” DirectAccess deployment based on a Forefront UAG 2010. This is the simplest deployment scenario to start with but also work for advanced DirectAccess based deployments using NLB of HLB. Before starting the configuration steps, let’s review the different IPsec implementation :

DirectAccess Challenge Series suite

We have IPsec tunnels and IPsec transports. IPsec tunnels are designed to secure network traffic between two networks (from router to remote router) and protect both the Header (AH) and the payload (ESP). IPsec Transports are designed to secure network traffic between two computers and only protect the payload (ESP), not the header (AH). Remember that each time a router route network traffic headers information’s are updated.

Applied to a DirectAccess deployment we have the infrastructure and user IPsec tunnels and the Application IPsec transport. In this scenario we will keep the standard IPSEC tunnels (Infrastructure and Application) and setup a new IPSEC transport to secure a specific server.

 

Note : Technically, it is possible to use the Selected Server access model as foundation but for a reason I did not find, computer group membership filtering will not work.

 

Assumptions

For this scenario, we need a standard UAG DirectAccess deployment including the following considerations for the secured servers :

  • Operating system must be Windows 2008 or Windows 2008 R2 to support IPv6 (ISATAP more precisely)
  • Windows 2008 R2 will be required is you choose IPsec peer authentication without traffic protection
  • Server must be able to reach the ISATAP router (the UAG box) to get the ISATAP prefix
  • Server must be domain member

 

Challenge

The challenge for this deployment is to be able to initiate a secure communication from a DirectAccess enabled computers located on Internet with a secured server located on company internal network. Access to the server will be filtered based on computer and user group membership for a specific protocol (RDP in my demonstration). Let’s start our IPsec inception (IPsec transport inside IPsec tunnels).

 

Client-side configuration

Our IPsec inception scenario start with the client-side configuration on a standard DirectAccess enabled Windows 7 client. IPsec transport must be configured only for a specific IPv6 destination located on my LAN. My SECURE server ISATAP address is 2002:836B:2:8000:0:5EFE:192.168.0.111.

Technically speaking, it is possible to build this connection security rule in a GPO but I will build it locally for a better understanding. I need a transport IPsec rule. According to the wizard, the first type of connection security rule should be fine :

ISOLATIONCLIENT0

 

Even if this IPsec transport will reach my secure server through an IPsec tunnel (inception), this is not a reason to do not enforce authentication whoever initiate the communication. In my scenario, it is always DirectAccess enabled laptops that need to reach my secure server.

ISOLATIONCLIENT1

 

Authentication means protocols. IPsec negotiation rely on the Authenticated IP protocol witch is an extension of IKEv1. Because I need to authenticated both the computer and the user I choose the “Computer and user (Kerberos v5)” choice.

ISOLATIONCLIENT2

My new connection security rule should only be used when DirectAccess is enabled, so only for the public and private firewall profiles.

ISOLATIONCLIENT3

 

At last, I will name my new rule “SECURE ZONE”.

ISOLATIONCLIENT4

 

We have the foundations of our IPsec transport, but it’s not specific to my SECURE server. We need to add a condition based to my destination : the ISATAP address of my SECURE server.

ISOLATIONCLIENT5

 

This is the end for the client-side configuration. Our new connection security rule will establish an IPsec transport to reach my SECURE server only if DirectAccess is enabled, whatever my local IP address (Teredo, IPHTTPS, …).

ISOLATIONCLIENT6

 

Server-side configuration

On the server-side configuration, we will use the same wizard and start with the same choices : Isolation.

ISOLATIONSRV0

 

Authentication will be required for both inbound and outbound connections. If my server is supposed to be secure it is a logic choice.

ISOLATIONSRV1

 

Just like on the client-side configuration we will chose the “Computer and user (Kerberos V5)” choice. Note that you can use the advanced authentication method to define your primary and secondary authentication method. This could be a good idea to enforce the use of a System Health Authentication certificate for the client. Accessing secured zone require your computer to prove it’s security level before (NAP is good for you!) .

ISOLATIONSRV2

 

Because my SECURE server is located on my internal network, my new connection security rule should be applied only to domain profile interfaces.

ISOLATIONSRV3

 

My new connection security rule will be named “SECURE ZONE”, just like on the client-side.

ISOLATIONSRV4

 

Now the fun begin. How to be sure that my server will apply this connection security rule only for DirectAccess enabled clients located on Internet. Simple, if they operate in DirectAccess they use IPv6 transition protocols such as Teredo and IP-HTTPS (I no longer recommend using 6to4 in DirectAccess deployments and this protocol is no longer use in Windows 8). So I need one filter for IP-HTTPS connections with a 56 mask (work for single-node up to eight-node UAG array farm) and a Teredo filter :

ISOLATIONSRV5

 

But I also need to be sure that my connection security  rule only apply to the ISATAP address of my SECURE computer and not my server remote administration interface. For this reason, I add my ISATAP address in the Endpoint1 zone.

ISOLATIONSRV6

That’s the end for the tunnel. At this point, you can try to establish a connection with the SECURE server, you will have an IPSEC association established but no filtering capabilities, that’s for the next part.

ISOLATIONSRV7

 

Connection security rule configuration on the server-side end with ICMP exception management. We need to reconfigure IPsec exception at SECURE server level to ensure that IPsec traffic is not included in our IPsec transport.

RDS4

This is an important point because otherwise you wont be able to ping the SECURE server from a DirectAccess client and DirectAccess clients using Teredo protocols will be blocked (ICMPv6 messages are used in Teredo for signaling usages).

Secure one protocol

Here things become tricky. In this scenario we are working with IPsec transports. This means we cannot filter who use at tunnel negotiation (we need an IPsec tunnel for that). Because of this limitation, filtering must be performed on my SECURE server at inbound Rules level. In my example we will secure RDP protocol usage.

By default, Windows Firewall include all standard protocols to be used. So we will find an incoming rule for Remote Desktop protocol. We will reconfigure this protocol definition to require a secured connection to use this protocol. Our IPsec transport will be our secured connections.

RDS0

 

We will keep the standard choice. My connection must be authenticated and it’s integrity-protected. An interesting choice would be the ‘”Null encapsulation” that only protect the payload (ESP) buts it’s only available since Windows 7 and Windows 2008 R2.

RDS1

 

Enabling the “Allow connection if it is secure” unlock the “Computer” tab of the protocol definition. Authentication information’s provided by the DirectAccess client during IPsec negotiation can be used to allow/deny connections based on computer group membership. In illustration bellow, I consider that I have a security group that permit usage of the RDP protocol from a group a clients computers and a group to deny usage. That’s an interesting scenario to limit remote administration capabilities with DirectAccess to a selected group inside DirectAccess clients.

RDS2

 

We can apply the same filtering approach for users. Only a selected group of users will be able to use the RDP protocol on a selected set of DirectAccess enabled computers.

RDS3

 

By now the RDP protocol on my SECURE server is secured because :

  • Access to the RDP server requires IPsec infrastructure and user tunnels negotiation prior accessing the SECURE server (IPsec inception).
  • RDP access to the SECURE server is limited to a subset of the DirectAccess-enabled computers
  • RDP access to the SECURE server is only possible for a limited subset of users of DirectAccess-enabled computers

 

Limitations

First, this scenario should be supported by Microsoft because no change is performed on the default configuration. We just add new connection security rules .

The most visible limitation is that each protocol must be reconfigured. In my opinion, only application level protocols should be reconfigured. Standard protocols such as RPC must remain accessible without enabling an IPSEC transport with the server.

And at last, clients located on LAN wont be able to access the SECURE server for the secured protocols because our connection security rule configured on the server filter only Teredo and IP-HTTPS access. An easy workaround for this limitation would be to create additional security rules for domain based profiles only. If a server is considered as sensitive for external access, it should be the same for internal access.

 

BenoitS – Simple and Secure but business compliant

DirectAccess Connectivity Assistant 2.0 Release Candidate

As Windows 8 and Windows Server 2012 development are about to be terminated, additional software also reach the Release Candidate stage. Now this is the case of the DirectAccess Connectivity Assistant 2.0 (RC).

 

Note that because this feature is already included in Windows 8, there is no need to deploy it on this release of the operating system. This version is dedicated to legacy operating systems (Yes Windows 7 is considered as legacy) connecting to Windows Server 2012 based DirectAccess platforms.

 

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