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

A KB list to keep in mind for your DirectAccess projects

Benoît SAUTIERE — Thu, 04 Apr 2013 19:13:00 GMT

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

Benoît SAUTIERE — Mon, 07 Jan 2013 20:31:00 GMT

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 :

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 :

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

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 :

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 :

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 :

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 :

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

Benoît SAUTIERE — Sun, 11 Nov 2012 18:19:00 GMT

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

Benoît SAUTIERE — Thu, 11 Oct 2012 19:44:00 GMT

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

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.

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

Benoît SAUTIERE — Thu, 27 Sep 2012 21:22:00 GMT

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

Benoît SAUTIERE — Tue, 31 Jul 2012 22:13:00 GMT

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

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

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 :

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 :

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.

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.

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

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

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.

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, …).

Server-side configuration

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

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

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!) .

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

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

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 :

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.

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.

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.

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.

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.

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.

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.

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

Benoît SAUTIERE — Sat, 07 Jul 2012 07:51:00 GMT

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

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 7 & Windows Server 2008R2 sont certifiés EAL4+

Benoît SAUTIERE — Sat, 02 Apr 2011 09:17:00 GMT

La news a déjà été relayée sur le blog de Stanislas Quastana, mais elle vaut le coup qu’on s’y attarde. Pour reprendre une formule qui n’est pas de moi “La sécurité est un voyage, pas une destination”, il est loin le temps de Windows NT 4.0 et l’introduction de la sécurité dans le cycle de développement de Windows XP SP2.

Tout ca pour dire qu’avec le temps, les préjugés sur le bien fondé de l’utilisation de Windows dans les environnements à contraintes de sécurité élevées n’ont plus lieux d’être. Même les dernières fonctionnalité de Windows 7 ont été passées au crible des tests. Même DirectAccess et NAP ont été qualifiés.

S’il reste encore des sceptiques concernant la robustesse du pare-feu de Windows Server 2008 R2, qu’ils se rassurent. TMG 2010 est lui aussi certifié EAL4+.

Pour plus d’information, le rapport de validation est disponible à cette adresse.

Benoits – Simple and Secure by Design but Business compliant.

Network Access Protection et au Delas!

Benoît SAUTIERE — Sat, 26 Mar 2011 03:36:00 GMT

Network Access Protection est une brique présente depuis Windows 2008. NAP doit être considéré comme une plateforme de gestion de la conformité qui est extensible.

Pour preuve, un produit tel que Forefront UAG vient y mettre son grain de sel avec un nouvel “enforcement client”. Depuis Windows 2008 R2, Network Access Protection est capable de proposer et gérer plusieurs stratégies de conformité.

La capacité à intégrer d’autres solutions et proposer plusieurs niveaux de conformité permettent de développer des nouveaux scénarios dans le domaine de la gestion de la conformité du poste de travail en entreprise.

Le cas du partenaire extérieur

C’est moi, ou plutôt nous tous qui intervenons chez nos clients respectifs. Se pose alors toujours la même problématique. Suis-je autorisé à connecter mon poste de travail au réseau? Lorsque la réponse est oui (Merci!), cela implique que notre poste de travail présente un certain nombre de garanties de sécurité tel que :

Pare-Feu
Antivirus
Antispyware
Mises à jour

Tout cela ressemble furieusement aux critères proposés par le System Health Agent de Windows. Dans le cas d’un scénario Network Access Protection basé autour de DHCP (ce qui est le cas le plus simple à mettre en œuvre), il suffit que je configure mon client NAP pour soumettre mon état de santé au travers de la méthode d’enforcement DHCP. Si je ne le fait pas, le serveur NPS va automatiquement me déclarer non conforme et me limiter fortement l’accès au réseau.

Le cas du poste d’entreprise

Dans le cas du poste d’entreprise, on attend de lui qu’il présente beaucoup plus de garanties. Pour les entreprises qui ont opté pour des antivirus et des pare-feu tiers, elles aimeraient en savoir un peu plus que les produits sont bien installés et opérationnel. Dans le cas des solutions McAfee, celle-ci présente l’intérêt d’être intégralement administrable au travers d’un ePolicy Orchestrator. Si on creuse un peu plus chez cet éditeur, on va trouver un produit nommé McAfee Network Access Control. C’est la solution de gestion de conformité de l’éditeur qui propose entre autre :

De reconfigurer le client NAC en client NAP (donc un SHA)
D’interfacer la gestion de remédiation avec en SHV

Coté client, l’agent McAfee Network Access Control est configuré pour opéré avec NAP. Cela signifie que le SHA de l’éditeur sera activé pour remonter les informations au SHV. Dans l’illustration ci-dessous, on constate que :

J’ai l’enforcement client DHCP actif
J’ai aussi l’enforcement client McAfee actif
Que mon poste n’est pas conforme

On peut aussi constater que j’ai deux SHA :

Celui de Windows qui me dit que tout est conforme
Celui de McAfee qui me dit qu’il y a des problème.

D’un point de vue Network Access Protection, on constate bien que mon poste n’est pas conforme. Ce qui manque, c’est le pourquoi.

Le pourquoi on va le trouver dans l’agent NAC de McAfee qui nous indique que mon poste de travail d’entreprise présente une grave lacune, il n’a pas le pare-feu de l’entreprise. Pour cette raison, le poste de travail est considéré par NAP comme non conforme.

Conclusion

Enrichir Network Access Protection avec une solution tierce est possible et présente un certain nombre d’avantages. D’une part, on peut simplement traiter le cas des partenaires extérieurs, et d’autre part, on dispose d’une plateforme unique pour gérer la conformité des postes de travail de l’entreprise.

La Méthode d’Enforcement DHCP de NAP travaille au niveau du client et non des équipements réseaux. C’est un premier pas vers la gestion de la conformité en attentant une refonte des réseaux d’agences pour intégrer des équipements réseaux supportant le 802.1.X et créer autant de VLAN de remédiation que de sites.

Grand merci à au consultant PHV dit “Pioupiou” grâce à qui j’ai pu travailler sur ce sujet. Suite à cet acte de bravoure il est élevé au rang de “PiouPiou Senior”.

Benoits – Simple and Secure by Design but Business compliant.

ADCS en mode Cross-Forest

Benoît SAUTIERE — Mon, 21 Feb 2011 14:58:00 GMT

Mais à quoi çà sert?

Depuis Windows NT 4.0 et jusqu’à Windows Server 2008, une autorité de certification “Microsoft” ne pouvait prendre en charge que des clients situés dans la même forêt. Donc jusqu’à maintenant, on ne pouvait pas avoir moins d’autorité de certification que de forêts.

De plus en plus souvent, les architectures complexes vont vers une séparation entre les ressources et les utilisateurs. C’est le cas d’Exchange et Lync. Problème, pour ces environnement, on était obligé de déployer au moins une instance du rôle ADCS par forêt. Conclusion, on devait se prendre la tête avec de la Cross certification.

Le rôle ADCS de Windows 2008 R2 supportant maintenant le LDAP Referrals, il est maintenant possible de faire beaucoup plus simple, avec une seule instance du rôle ADCS couvrant plusieurs forêt.

Les pré-requis

Pour obtenir ce résultat, il est nécessaire que :

De mettre en place une forêt de ressource pour notre rôle ADCS
De mettre en place une forêt de compte dédiée aux clients Windows XP ou Windows 2003 minimum
De mettre en place le rôle ADCS dans la forêt de ressources sur un serveur Windows 2008 R2 de type Enterprise ou Datacenter

Les fondations sont la, maintenant place à la mise en œuvre.

Etablir la confiance

C’est la base de tout. Notre Autorité de certification devra être reconnue dans la forêt de compte et accepter les demandes de certificats en provenance de celles-ci. Pour cela, on a besoin de vérifier l’identité. On a donc besoin de Kerberos. Pour cette raison, on a besoin d’une relation d’approbation de type Forêt, ce qui implique un mode de forêt Windows 2003 natif au minimum dans la forêt de compte. Coté forêt de ressources, c’est aussi Windows 2003 natif mais là, c’est normal.

Cette relation d’approbation doit nécessaire être bi-directionnelle. D’un coté les utilisateurs de la forêt de compte doivent pouvoir être identifiés comme autorisés à accéder à des gabarits de certificats et réaliser l’enrôlement. De l’autre coté, notre autorité de certification doit être capable de vérifier l’identité du demandeur dans la forêt de compte.

Lors de l’établissement de la relation d’approbation, il est possible d’utiliser la fonctionnalité “Selective Authentication qui permet de déterminer quels sont les utilisateurs autorisés à utiliser la relation d’approbation. Pour cela, il faut s’assurer que :

Les demandeurs de certificats (machine ou utilisateur) de la forêt de compte puissent se présenter dans la forêt de ressource
L’autorité de certification présente dans la forêt de ressource doit être capable de s’authentifier auprès de tous les contrôleurs de domaine demandeurs dans la forêt de compte. C’est nécessaire pour valider l’identité des demandeurs.

Configuration de l’autorité de certification

Par défaut, une autorité de certification n’est pas capable de traiter les demandes en provenance d’autres forêt. C’est une des nouvelles capacités de Windows 2008 R2 qu’il faut activer. En ce qui nous concerne, le “LDAP Referrals”.

Le redémarrage de l’autorité de certification est nécessaire pour que le paramétrage soit pris en compte. Notre autorité de certification racine devant être reconnue par les forêts de compte. Il nous faudra donc exporter le certificat de l’autorité de certification racine.

Pour que ce certificat soit valable, encore faut-il que les informations inscrites dedans puissent être accessibles dans la forêt de compte. On parle ici d’AIA et de CDP. Il faut donc s’assurer que ces informations sont bien accessibles. Publier la CRL est un de ces éléments.

Configuration de la forêt de compte

Pour que la forêt de compte reconnaisse notre autorité de certification, il est nécessaire de commencer par l’import du certificat de l’autorité de certification racine (généralement mis hors ligne). On utilisera pour cela la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat> ROOTCA”.

Note : L’actualisation des GPO doit permettre de s’assurer que le contrôleur de domaine que nous allons utiliser par la suite dispose bien des bonnes informations.

L’autorité de certification est maintenant déclarée comme autorité racine de confiance. C’est ce qu’on peut constater dans la partition de configuration.

On peut obtenir la même information à l’aide du provider “CERT” inclus avec PowerShell.

Une autorité de certification reconnue comme de confiance c’est bien mais si en plus elle peut être utilisée pour fournir des certificats d’authentification, c’est mieux. Pour cela, il faut positionner le certificat dans le conteneur “NTAuthCA” à l’aide de la commande “certutil.exe –DsPublish –f <Fichier du certificat> NTAuthCA”.

Dans la console ADSIEdit, on doit pouvoir constater l’apparition d’un objet “CertificationAuthority” pour notre précédente commande.

Même si ce n’est pas obligatoire (cela fonctionne sans), il est recommandé de publier tous les niveaux de cette infrastructure. Pour cela, on dispose d’un conteneur “SubCA” et de la commande “CERTUTIL.EXE –DsPublish –F <Fichier de certificat"> SubCA”. Dans l’illustration ci-dessous, il est indiqué que le conteneur est déjà peuplé car mon infrastructure de clé publique n’a qu’un seul niveau. Le certificat est donc déjà dans le bon conteneur.

Le fait de publier les certificat dans les bon conteneurs de suffit pas. Il nous faudra des permissions. Avec l’Active Directory, tout passe par le groupe “Cert Publishers”. Dès lors qu’on installe une autorité de certification dans une forêt, le compte ordinateur est automatiquement positionné dans ce groupe.

Dans le scénario du Cross-Forest, il n’y a pas d’autorité de certification dans la forêt. Le groupe est donc vide. Il faut donc positionner le compte ordinateur de notre autorité de certification dans le groupe. Cela sert aussi à cela la relation d’approbation bi-directionnelle.

On approche de la fin de la configuration. On rentre maintenant dans les détails avec l’activation de la fonctionnalité “Auto-Enrollment” pour tous les systèmes.

On peut être activer la fonctionnalité pour les gabarits de certificats V1 et spécifier les gabarits en question.

Qu’est ce que cela donne dans la forêt de compte?

A ce stade, on va plutôt constater ce qui manque. On constate bien la présente de l’AIA pour notre autorité de certification.

Par contre, on n’a aucun gabarit de certificat à proposer à nos utilisateurs. A ce stade, c’est normal, ils sont toujours dans la forêt de ressource. Il va falloir travailler un peu.

Coté OID, c’est aussi le désert, …

Pour ceux qui ont suivi mon billet sur ADCS Enrollment Web Services, on a découvert la notion des service d’enrôlement. Dans l’état actuel des choses, il n’y en a pas dans notre forêt de compte. Conclusion, les clients ne pourront pas savoir quels sont les gabarits de certificats mis à sa disposition.

Alors, on synchronise à la fin?

C’est bien là l’astuce. On va devoir recopier les objets manquants depuis la forêt de ressources vers la forêt de comptes. Coté Microsoft, il n’y a pas réellement d’outillage sinon un script Powershell disponible sur Technet.

Ce script sera exécuté dans la forêt de compte pour aller chercher les objets manquants dans la forêt de ressources. Ce sera le même script pour la synchronisation initiale et les synchronisation suivantes.

Note : Je recommande vivement l’utilisation du paramètre “-WhatIf” pour identifier les changements que le script va réaliser.

Ca marche?

A ce stade, attention il faut que la réplication inter-site fasse son œuvre. Normalement, on doit pouvoir retrouver les gabarits de certificats en provenance de notre forêt de ressources.

On trouve même un service d’enrôlement, ce qui signifie que les clients de cette forêt peuvent déterminer quels sont les gabarits de certificats mis à sa disposition.

Et pour finir, on a aussi les OID. On est donc au complet.

Pourquoi je ne voit pas mes gabarits de certificats?

Encore un code erreur 40 de Kevin le boulet? Ben oui et non. Celui-là il est volontaire pour illustrer un propos. Oui, on ne voit pas les gabarits de certificats. Par contre, la raison est-elle évidente non?

C’est juste une histoire de permissions, celles positionnées sur les gabarits de certificats. Par défaut, elle ne peuvent concerner que des objets de la forêt de ressources. Il nous faut donc ajouter deux types de permissions. La première est celle nécessaire aux administrateurs de la forêt de compte pour accéder et formuler des demandes de certificat pour un gabarit donné.

La seconde est destinée aux populations pouvant faire de l’Auto-Enrollment”. Eux aussi doivent disposer des permissions “Enroll”et “AutoEnroll”.

Voila pour la gabarit “Domain Controller Authentication”, à vous de travailler pour les éventuels autres certificats.

Journalisation

Dès lors qu’on va ajouter ou modifier les gabarits dans la forêt de ressources, il faudra déclencher une synchronisation des objets. La mise en place d’un compte de service disposant des privilèges appropriés est recommandé. Je recommande même d’encadrer l’exécution du script PowerShell avec le commandlet “Start-Transcript”.

Pour pouvoir journaliser tous les messages dans un fichier texte.

Cette phase d’industrialisation doit être accompagnée d’une supervision. Microsoft documente les différents évènements à suivre dans cet article Technet, Le dépannage est lui aussi disponible à cet emplacement.

La critique

La première critique que l’on pourrait formuler est que l’ensemble repose sur DCOM et donc sur les RPC. C’est vrai. Mais il est aussi possible d’utiliser les Web Proxy livrés avec le rôle ADCS. Par contre, la configuration sera juste un peu plus compliquée que celle présentée dans mon billet sur le sujet.

Benoits – Simple and Secure by Design but Business compliant.

Windows 7 & Windows 2008 R2 service pack tip

Benoît SAUTIERE — Sun, 20 Feb 2011 10:27:00 GMT

Ca a beau être dimanche, c’est mon “Service Pack day”. Même si mes machines sont assez bien tenues à jour en terme de correctifs de sécurité, une bonne remise à niveau générale ne peut pas faire de mal.

Au vue des premiers retours, il ne semble pas avoir de problématiques liées à la mise en œuvre de ce Service Pack. Cependant, on est jamais assez prudent. On doit pouvoir revenir en arrière.

Cependant, si comme moi vos machines sont quelque peu limitées en terme d’espace disque (j’approche le Tera de machines virtuelles), il devient nécessaire de vite récupérer de l’espace disque. C’est que j’ai quelques snapshot à faire ces jours ci.

Pour cela, un petit coup de baguette magique avec “la commande “DSIM.EXE suivante :

Note : Je vais enfin pouvoir installer le pilote vidéo sur le Windows Server 2008 R2 de mon portable .

Benoits – Simple and Secure by Design but Business compliant.

Test Lab guide IPv6

Benoît SAUTIERE — Tue, 01 Feb 2011 14:11:00 GMT

C’est peut être par hasard mais dans peu de temps, Internet entrera dans sa phase “IPv4 exhaustion”. Bientôt, il ne restera que cinq blocs non alloués (102.x.x.x, 103.x.x.x, 104.x.x.x, 179.x.x.x, and 185.x.x.x.). C’est cette période que Microsoft choisit de publier le Test Lab Guide sur IPv6.

Comme tous les tests lab guides, celui-ci est basé sur la “Base configuration”. Donc une bonnes plateforme de virtualisation et assez d’espace disque pour des snapshots sont nécessaires. On découvrira :

L’adressage de type Link-Local
L’IPv6 Natif (routage, …)
ISATAP
6to4

C’est encore les bases de l’IPv6 mais rien que le concept du routage (Publish & Advertise) vaut le détour. Au passage, un peu de pub pour la session d’Arnaud Lheureux et Marc Michault : (SER208) IPv6 pour les Nuls . Je vais pas faire le malin sur le sujet

Benoits – Simple and Secure by Design but Business compliant.

ADCS Enrollment Web Services

Benoît SAUTIERE — Mon, 17 Jan 2011 16:11:00 GMT

Le rôle ADCS est présent depuis Windows NT 4.0. Avec Windows 2000, il a fait son entrée dans l’annuaire Active Directory avec son mode “Enterprise”. Problème, ce mode de fonctionnement implique que les clients soumettent leurs demande de certificats en passant par DCOM et non les RPC.

A l’heure de Windows 7/Windows 2008 R2, l’utilisation de RPC/DCOM pour soumettre ses demandes de certificats, c’est pas ce qu’il y a de mieux pour sécuriser le rôle ADCS. Pourtant, on dispose bien d’un site web d’enregistrement de demande de certificats mais c’est pour traiter des demande manuelle. Avec Windows 7 / Windows 2008 R2, on dispose de deux Web Services pour adresser cette problématique:

Certificate Enrollment Policy Web Service
Certificate Enrollment Web Service

Pourquoi deux Web Services? La raison est simple. Dans un premier temps, le client doit déterminer quelles autorités de certification sont disponibles ainsi que les gabarits de certificats utilisables. Ces informations sont disponibles dans l’annuaire Active Directory. Le “Certificate Enrollment Policy Web Service” joue le rôle de proxy pour les clients. Il n’ont donc plus à accéder à nos contrôleurs de domaine.

Le “Certificate Enrollment Web Service” a lui la charge de recevoir les demandes de certificats pour les soumettre à l’autorité de certification et de retourner les résultats.

Stratégie d’enrôlement par défaut

Sans autre indication, Windows 7 et Windows Server 2008 R2 utilisent l’annuaire Active Directory pour localiser le point d’Enrôlement qui n’est rien d’autre que notre autorité de certification.

Pour être plus précis, nos systèmes d’exploitation effectuent les recherches suivantes :

La liste des Enrollment Services déclarés dans la partition de configuration (pKIEnrollmentService)
La liste des gabarits de certificats disponibles dans l’annuaire Active Directory (pKICertificateTemplate)

Dès lors qu’on a localisé notre service d’enrôlement, on a immédiatement accès à notre autorité de certification pour lui soumettre les demandes de certificats en DCOM, ce qui implique donc de passer par les RPC. C’est à ce stade qu’on va introduire nos deux Web Services.

Bases de travail

Avant de pouvoir installer les Web Services du rôle ADCS, il faut encore avoir préalablement avoir mis en œuvre une autorité de certification intégrée à l’annuaire Active Directory. Le rôle ADCS devra avoir été installé en mode “Entreprise”. Pour cela, je vous renvoie vers une mise en œuvre déjà documentée.

Dans ce billet, il sera considéré que les deux Web Services du rôle ADCS seront installés sur un même serveur distinct de l’autorité de certification. Il existe d’autres scénarios. Pour plus d’information, je vous renvoie vers l’excellent White Paper Certificate Enrollment Web Services whitepaper.

Installation des Web Services

Nos deux Web Services seront installés sur un même serveur membre du domaine.

En premier lieu on configure le “Certificate Enrollment Web Service”. Celui-ci a besoin de savoir vers quelle autorité de certification renvoyer les demandes. A ce stade, on peut noter qu’il est possible de le configurer pour ne traiter que les demandes de renouvèlement de certificat. D’un point de vue sécurité, c’est intéressant, surtout si notre autorité de certification est accessible depuis Internet.

Dès lors qu’on doit dialoguer avec un des deux Web Services, une authentification est nécessaire. Il n’est pas possible de soumettre des demandes anonymes! Les Web Services proposent trois modes d’authentification. Dans le cas qui nous occupe, j’ai choisi l’authentification Windows intégrée, c’est le scénario le plus simple.

Pour que le Certificate Enrollment Web Service puisse soumettre les demandes des clients, il est nécessaire que le serveur web ou le compte de service que l’on précise à ce niveau soit configuré pour la délégation Kerberos. La demande doit être formulée au nom du client et non au nom du serveur web. Dans le cas illustré dans ce billet, j’ai volontairement choisit de réutiliser le contexte par défaut utilisé par le site web de IIS. Ce n’est peut être pas le scénario le plus sécurisé mais le plus simple à illustrer .

Qui dit Web Service et autorité de certification dit impérativement SSL. On va donc avoir besoin de certificats. Dans le scénario développé dans ce billet, les deux Web Services partageront le même certificat et le même nom. Il est possible de faire mieux mais on va continuer à faire “Simple by Design” .

Le résumé de l’installation nous apprend plusieurs choses:

L’URI du Certificate Enrollment Policy Web Service
L’URI du Certificate Enrollment Web Service
Que nous utiliseront le contexte de sécurité du site web par défaut pour le “Certificate Enrollment Web Service”
Que le mode d’authentification est identique pour les deux Web Services
Qu’il manque un certificat

Dans des scénarios plus développés, on choisirait de séparer les deux Web Services avec des URI distinctes. On conserve ces informations dans un coin pour plus tard. La fin de l’installation nous indique un certain nombre d’informations complémentaires :

L’absence de certificat SSL pour finaliser l’installation
La configuration de la stratégie d’Enrôlement à prévoir
La délégation Kerberos à mettre en œuvre

Une fois les Web Services installés, on peut constater la présence de deux nouveaux pools applicatifs dans la console IIS. Chaque Web service dispose d’un contexte de sécurité qui lui est propre. On repassera plus tard.

Pour l’instant, on va se focaliser sur ce qu’il manque, à savoir notre certificat. Etant donné que nos deux Web Services sont mutualisés sur le même serveur web, on va demander un certificat au nom de notre serveur web:

Pour raison de commodité, on va ajouter un “Friendly Name” dans notre demande de certificat. Cela permettra de plus facilement identifier le certificat.

Une fois obtenu, notre certificat doit être associé au listener HTTPS.

On comprend immédiatement l’intérêt d’avoir intégré un “Friendly name”.

Pour parachever la configuration des Web Services, on va aller configurer quelques propriétés dans la console Internet Information Server. Plus précisément, on va aller faire un tout du coté du “Certificate Enrollment Policy Web Service”. A ce stade, nous devons configurer le “Friendly name” sous lequel ce Web service va s’inscrire dans l’annuaire Active Directory.

Le “Certificate Enrollment Policy Web Service” est référencé sous une URI. C’est celle-ci que l’on va réutiliser dans la stratégie de groupe.

A t’on besoin de délégation Kerberos?

Le sujet est complexe et simple à la fois, tout dépend si on sépare ou mutualise les Web Services entre eux et si on désire les cumuler ou non avec l’autorité de certification.

La règle est pourtant simple. Si toutes les conditions suivantes sont remplies alors il sera nécessaire de configure une délégation Kerberos pour le Certificate Enrollment Web Service:

Le rôle ADCS et le Certificate Enrollment Web Service sont installés sur des serveurs distincts
L’authentification retenue pour le Web Service est de type “Windows intégrée” ou “Client Certificate authentication”
Le Certificate Enrollment Web Service sera configuré en mode “Renouvèlement uniquement”.

Pour plus d’informations sur le sujet, je vous renvoie sur le site Technet :

Configuring Delegation Settings for the Certificate Enrollment Web Service Account

Dans le cas de cet article, l’ai volontairement :

Choisit de mutualiser les deux Web Services sur la même machine
Les Web Services ne sont pas mutualisés avec l’autorité de certification (mesure d’isolation)
Le compte de service utilisé pour le Certificate Enrollment Web service a volontairement et conservé

Ayant volontairement réutilisé ne contexte par défaut de IIS, il y aura bien une délégation à mettre en place mais pas pour le compte de service mais le compte ordinateur hébergeant mes deux Web Services. On va mettre en place une délégation Kerberos pour seulement deux services tel qu’illustré ci-dessous:

Configuration d’une nouvelle politique d’enrollment

Par défaut, lorsqu’on demande un certificat à notre autorité de certification, cela ressemble à l’illustration ci-dessous :

Si on creuse un peu dans la partition de configuration, on constate qu’il existe déjà une politique d’enrôlement de certificat pour notre autorité de certification. La référence indiquée dans l’annuaire Active Directory indique même les gabarits de certificats disponibles. Il nous faut donc remplacer cette politique d’enrôlement par une nouvelle référençant non pas l’usage directe de notre autorité de certification mais notre “Certificate Enrollment Policy Web Service”. C’est techniquement possible mais uniquement pour les systèmes de la génération Windows 7 et Windows 2008 R2 au travers des stratégies de groupe.

Le paramétrage peut s’effectuer au niveau de l’ordinateur ou de l’utilisateur. On peut choisir d’avoir une seule stratégie d’enrôlement ou la différencier. La stratégie d’enrôlement se configure au travers du paramètre “Certificate Services Client – Certificate Enrollment Policy”.

La stratégie d’enrôlement initiale prévoit d’utiliser l’annuaire Active Directory, c’est ce qui est inscrit dans la partition de configuration de notre forêt. On va donc commencer par supprimer cette référence. A ce niveau, on peut aussi forcer l’utilisation de la même politique pour l’utilisateur du poste:

Dans une configuration par défaut, la stratégie d’enrôlement indique LDAP comme URL de localisation de la ressource (URI). Etant donné que nous référençons le Web service de notre “Certificate Enrollment Policy Web Service”. C’est l’URI que nous avons préalablement identifié. Le copier/Coller sera ici très utile:

Le processus validation va vérifier que le “Certificate Enrollment Policy Web Service” est référencé dans l’annuaire Active Directory sous forme d’une Enrollment Policy qui elle même référence le “Certificate Enrollment Web Service”. Bref, on valide la chaine.

Etant donné que tout fonctionne, on indique maintenant que cet “Enrollment Policy” est celle qu’il faudra utiliser.

Changements coté Active Directory

Le premier changement, c’est que la politique d’enrôlement par défaut a été remplacée par une nouvelle référençant notre “Certificate Enrollment Policy Web Service”.

Si on interroge la politique d’enrôlement de notre autorité de certification (CERTUTIL.EXE –ADA), on peut constater un certain nombre de choses :

La liste de la ou les autorités de certifications disponibles
La liste des gabarits de certificats mis à disposition
Le mode d’authentification des clients auprès du Web Service
L’URI du Web Service “Certificate Enrollment Policy Web Service”

La commande “CERTUTIL.EXE –POLICY” permet de déterminer quelle est la stratégie d’enrôlement configurée, son URI ainsi que la fréquence de mise à jour. Ce qu’il faut comprendre à ce niveau, c’est que notre “Certificate Enrollment Policy Web Service” agit comme un proxy auprès des contrôleurs de domaine. Le client n’accède plus à nos contrôleurs de domaine.

Changements coté client

Avant, lorsqu’on effectuait une demande de certificat auprès de notre autorité de certification, on obtenait la stratégie par défaut nous envoyant directement vers l’autorité de certification.

Dès lors que la nouvelle stratégie d’enrôlement de certificats a été déployée, on peut constater les premiers changements:

Plus précisément que le client va s’adresser au Certificate Enrollment Policy Web Service pour obtenir son certificat:

Coté demande de certificat, rien ne change à première vue.

Pourtant, lorsqu’on regarde d’un peu plus près la requête qui va être traitée, on constate que celle-ci sera soumise à au “Certificate Enrollment Web Service”:

Pour preuve cela fonctionne.

Conclusion

Il a fallu attendre Windows 7 et Windows 2008 R2 pour sécuriser l’enrôlement de certificats. C’est un peu dommage. C’est très utile pour UAG car par défaut, les RPC sont bloqués (UAG et le RPC Server is unavailable).

Je recommande vivement la lecture du Windows Server 2008 R2 Certificate Enrollment Web Services Whitepaper. Le document référence d’autres scénarios de déploiement dont entre autre un scénario de renouvèlement de certificats pour des clients situés sur Internet.

Benoits – Simple and Secure by Design but Business compliant.

Windows 7 & Windows 2008 SP1 RC

Benoît SAUTIERE — Wed, 27 Oct 2010 00:57:00 GMT

Cela faisait pas mal de temps depuis la beta, voila donc la Release candidate. En temps Microsoft, cela pourrait signifier que la disponibilité est imminente. Cependant, il n’en est rien puisque ce service pack commun à Windows 7 et Windows 2008 R2 ne sera disponible qu’au premier trimestre 2011.

On ne reviendra pas sur les nouveautés apportées (RemoteFX et Hyper-V Dynamic Memory). Pour se préparer, on ne peut que recommander la lecture du Windows 2008 R2 SP1 RC Reviewer’s Guide. Il est certes uniquement focalisé sur les deux grandes nouveautés.

Sinon, point à prendre en considération : l’espace disque nécessaire pour installer ce Service Pack, à savoir 20Gb pour Windows Server 2008 R2. C’est une information importante à prendre en compte dans le dimensionnement des partitions systèmes.

Le Service Pack est disponible à cette adresse.

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