Archives de catégorie : Windows Server 2012

Software-Defined Storage Design Calculator

Avec la génération Windows Server 2012 / 2012 R2, Microsoft a introduit une nouvelle approche du stockage (qui se poursuivra dans Windows Server 2016) basé sur du JBOB et mis en avant avec les fonctionnalités suivantes :

  • Shared Cluster Volume
  • Scale-Out File Server
  • Storage Pool
  • Storage Spaces

Le tout avec une pointe de tiering SSD pour un stockage bien frappé. Cette nouvelle approche du stockage manquait d’information quant à son design. On dispose maintenant d’un Software-Defined Storage Design Calculator, un peu comme le Storage Calculator pour Exchange. Au moment où j’écris ce billet, c’est déjà la version 1.1 qui est disponible. Logiquement, il est très orienté pour les charges applicatives hébergées sous Hyper-V. Pour commencer, nous devons commencer par causer matériel. Cela implique de :

  • Choisir un template (Pour info le 4 nœuds * 4 châssis, c’est l’architecture stockage de CPS qui envoie du poney)
  • Estimer la consommation en pic de la charge applicative que l’on va héberger
  • Estimer la consommation moyenne de la charge applicative que l’on va héberger
  • Fournir les informations concernant le stockage (nombre de disques, capacité brute, nombre de tiroirs, contenu des tiroirs, …)

clip_image001

Note : Attention, avant de commencer, assurez-vous de disposer de la dernière version du fichier disponible à cette adresse.

Vous disposerez d’une première estimation qu’il faudra affiner avec votre fournisseur favori. A un moment, il faudra valider les hypothèses de calcul et se confronter à la réalité. Pour cela, une bonne adresse à conserver : Server and Storage I/O Benchmarking and Performance Resources. Y a tout ce qu’il faut pour casser du disque. Pour finir quelques conseils :

  • Attention à la taille des clusters pour le formatage
  • Attention aux optimisations matérielles réseau
  • Un antivirus sur un Hyper-V ca peut être fatal avec le SCV. Chaque nœud du cluster peut scanner le même fichier

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Publier une PKI sur Internet (republication)

En lisant le billet de mon collègue Alexandre GIRAUD sur le processus de demande de certificats pour IIS 7.0, je me suis rendu compte que souvent, nos clients ont besoin de certificats mais sont rebutés par la mise en œuvre. Une des principales problématiques se situe au niveau de la publication des listes de révocation à l’extérieur de l’entreprise. Si un système d’exploitation n’est pas capable de télécharger les listes de révocation, il ne peut déterminer si un certificat donné est toujours valable ou non. Or, il y a de plus en plus de scénarios (Windows, Exchange 2007, SCCM 2007, SCOM 2007, …) qui nécessitent la mise en œuvre d’une PKI.

 

Avertissement

Attention, ce billet n’est pas censé se substituer à une réelle mise en œuvre d’une infrastructure PKI. C’est juste un raccourci pour couvrir un certain nombre de scénarios et répondre uniquement au besoin technique (obtenir des certificats), l’aspect fonctionnel est volontairement négligé. L’aspect technique a lui aussi été épuré. Je renvoie donc les puristes vers le “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” ainsi que  l’indispensable référence sur la PKI Microsoft : Windows Server 2008 PKI and Certificate Security de l’immense Brian Komar.

Donc ce qui va suivre est volontairement une forme simplifiée de mise en œuvre de PKI. J’espère que les puristes ne m’en voudront pas.

 

Installation du rôle ADCS

Pour la majorité de nos besoins en certificats, nous avons besoins d’une autorité de certification intégrée à l’annuaire Active Directory (le scénario NAP IPSEC par exemple repose sur une autorité de certification autonome).

Mais alors pourquoi installer le rôle “Certification Authority Web Enrollment”? D’une part, on pourrait en avoir besoin pour certains scénarios, d’autre part, cela m’évite de créer un fichier “CAPOLICY.INF” pour personnaliser la mise en œuvre de mon autorité de certification.

clip_image001

 

Comme indiqué plus tôt, mon choix se porte une une autorité de type “Entreprise”, donc intégrée à l’annuaire Active Directory. On en verra les conséquences plus tard dans ce billet. Pour ceux qui veulent se faire mal, il peuvent consulter le WebCast de François LASSERRE des TechDays 2009.

clip_image002

 

Pour la notion de hiérarchie, on va faire très simple, un seul niveau, donc RootCA.

clip_image003

 

Toujours pour simplifier, je nomme mon autorité de certification RootCA.

clip_image004

 

Pour le chemin de la base de données de l’autorité de certification ou son journal de transaction, je conserve les choix par défaut.

clip_image005

 

Le résumé nous présente la liste des modules de IIS. Les choix proposés me conviennent parfaitement pour l’autorité racine, puisque c’est le choix minimum pour notre cas, donc secure!

clip_image006

 

Une fois l’installation terminée, on peut constater que notre PKI est bien opérationnelle et que ses informations sont publiées mais uniquement localement. La CRL est uniquement publiée dans un chemin HTTP.

clip_image007

 

Jusque là tout va bien. C’est simple finalement la PKI?

Optionnellement, on va configurer l’enregistrement et le renouvèlement automatique de certificats dans la stratégie de groupe “Default Domain Policy”. Ceci permettra aux systèmes d’exploitation clients ainsi qu’aux utilisateurs d’obtenir des certificats automatiquement.

clip_image008

 

Personnaliser les extensions

C’est par là que tout passera. Un raccourci pourrait consister à publier les URL de l’AIA et de la CRL avec ISA Server ou son successeur mais, du pointe de vue de la sécurité, c’est pas terrible. On va donc ajouter les extensions pour publier l’AIA et la CDP sur un serveur tiers que l’on pourra lui publier via ISA Server vers l’extérieur.

clip_image009

 

On constate maintenant la raison de mon choix d’installer le “Certification Authority Web Enrollment”. Si je ne l’avais pas installé, l’installation par défaut du rôle ADCS aurait du être corrigé pour ne pas publier l’AIA et la CDP sous forme HTTP. Il aurait été nécessaire de générer un fichier “CAPolicy.INF”. Je suis en vacances donc, on fait court!

clip_image010

 

Ajoutons notre première extension, à savoir la localisation de notre liste de révocation. Celle-ci devant être accessible d’extérieur, c’est nécessairement un nom pleinement qualifié qui doit être référencé, sous forme d’une URL HTTP. La chaine de caractère illustrée ci-dessous est générique. Elle permet surtout de publier plusieurs listes de révocations à un même emplacement.

clip_image011

 

Note : N’essayer pas de publier en HTTPS surtout avec un certificat issu de votre propre PKI, c’est pas marrant. Comment peut-on vérifier la liste de révocation si on ne peut pas y accéder, on part en boucle!

Subtilité, cet emplacement sera configuré pour stocker les CRL. Par extension, les clients pourront y trouver aussi les CRL “Delta” (qui seront publiées au même emplacement).

clip_image012

 

Voila pour l’accès extérieur mais encore faut-il que notre autorité de certification publie les informations à cet emplacement. Pour cela, on va lui indiquer un chemin UNC (qui correspondra au répertoire virtuel dans IIS) dans lequel l’autorité de certification pourra mettre à disposition les informations nécessaires.

clip_image013

 

Le partage référencé contiendra aussi bien les CRL que les CRL “Delta”.

clip_image014

 

Reste plus qu’à redémarrer le rôle ADCS pour prendre en compte les nouvelles extensions.

clip_image015

 

Voyons voir ce que cela a changé pour l’autorité de certification.

clip_image016

 

On constate qu’il y a bien un nouvel emplacement de publication “externe” pour notre autorité de certifications. Cependant, il ne semble pas opérationnel. A ce stade, c’est normal. Les raisons de cette erreurs sont multiples :

1. La résolution de noms DNS externes n’est peut être pas configurée

2. Le serveur sur lequel on doit publier nos informations n’est pas encore configuré

3. On na pas encore de liste de révocation à publier puisque pas encore de certificats révoqués

 

La résolution de noms externes

Pour que le monitoring de la PKI ne remonte pas d’erreur, il est nécessaire que l’autorité de certification puisse résoudre le nom pleinement qualifié de l’emplacement de publication HTTP. On peut  :

1. Autoriser nos serveurs DNS à joindre les RootHints

2. Configurer nos serveurs DNS pour utiliser des redirecteurs DNS

3. Créer une zone DNS représentant le nom DNS extérieur tel qu’illustré ci-dessous

clip_image017

 

Pour le choix, c’est vous qui voyez!

 

Configuration de la publication

Après l’autorité de certification, passons au serveur sur lequel on va publier les informations. Dans mon cas, j’ai retenu un Windows Server 2008 édition standard. Le choix “full GUI” ou “Core” m’importe peu, cela fonctionne dans les deux cas. Dans ce billet, je ne traiterai que le “Full GUI”, le plus communément

L’autorité de certification va publier dans un partage. Encore faut-il que celui-ci existe? Il sera configuré pour accorder le contrôle total au compte ordinateur de l’autorité de certification.

clip_image018

 

Les informations devant êtres accessibles depuis l’extérieur au format HTTP, nous avons donc besoin d’un serveur web mais uniquement le stricte minimum.

clip_image019

 

Etant donné que je n’ai pas demandé l’installation des outils d’administration de IIS, j’ai quand même besoin d’installer les outils d’administration de IIS en ligne de commande :

clip_image020

 

Notre partage doit disposer des permissions tel qu’illustré ci-dessous (Oups pas core!):

clip_image021

 

Reste plus qu’à créer le répertoire virtuel CRLD tel que déclaré dans l’extension de l’autorité de certification et d’y autoriser le parcours de répertoire (Attention à bien avoir installé les outils d’administration et se positionner dans le sous répertoire %Windir%\System32\InetServ!). La dernière ligne est une subtilité. Elle permet l’utilisation du caractère “+” par le client pour demander la CRL Delta.

clip_image022

 

Pour ceux qui veulent en savoir plus : How to avoid Delta CRL download errors on Windows Server 2008 with IIS7 (Merci Stan!). C’est fini? Nan, par ce que cela ne marche pas encore tout de suite.

 

Dernière passe sur ADCS

On a beau avoir tout mis en place, la console ADCS nous remonte toujours une erreur (Pourquoi tant de haine?).

clip_image023

 

Si on regarde de plus près, un accès HTTP nous retourne l’erreur 404. ce qui signifie que le répertoire est vide.

clip_image024

 

A ce stade, c’est normal, mon autorité de certification n’a pas encore délivré de certificat, donc il n’y a pas eu de révocation, donc pas de liste publiée. Même si la liste est vide, on va quand même demander la publication. Attention, cependant, une liste de révocation reste valide jusqu’à son expiration. La révocation de certificat n’est donc pas instantanée. Pour cela, il faut aller faire un tour du coté de OCSP (Attention, aspirine à prévoir!).

clip_image025

 

Et si tout est opérationnel (veillez à sacrifier une souris au dieux de l’informatique, cela sert toujours), le répertoire doit maintenant être peuplé d’une CRL et une DRL “Delta”.

clip_image026

 

Coté supervision de ADCS, tout est maintenant opérationnel. Notre PKI est maintenant accessible de l’extérieur. Pour finaliser la configuration, une petite publication HTTP avec ISA devrait faire l’affaire.

clip_image027

 

Comment prouver que cela fonctionne?

Bonne question. Une simple commande CERTUTIL permet de demander le téléchargement des CRL et CRLD depuis l’URL extérieure.

clip_image028

 

Conclusion

Ce billet est une réponse technique pour la mise en œuvre d’une PKI pour un besoin “Microsoft”. Cela ne se substitue pas à un réel projet PKI. Je n’ai fait ici qu’effleurer un scénario d’usage de la PKI Microsoft. Les usages des certificats sont très nombreux. l’utilisation des certificats augmentant avec le temps (Windows 2008 R2, Geneva, Exchange 2010?, …), il devient urgent d’intégrer les aspects fonctionnels autour de la sécurité dans nos projets.

Maintenant que c’est aspect a été démystifié, il n’y  plus de raison d’utiliser des certificats pour ADDS, TS Gateway, WINRM, SCVMM, SCOM, SCCM et tout les autres produits qui ne demandent que cela.

Benoîts – Mode Vacances (Pas possible!) + U2 (Yeah!)

DFSR Dirty Shutdown Recovery

Un sujet un peu “capilo-tracté” pour changer et un petit retour aux sources (Active Directory). Qu’est ce qui se passe au niveau DFSR lors d’un arrêt non planifié d’un contrôleur de domaine ou d’un serveur hébergeant le rôle DFS-R et participant à un groupe de réplication.

Pour rappel DFSR repose sur une base de données Jet qui va tracer tous les changements opérés sur les fichiers dépendant d’un replicated folder donné localisé sur un volume disque particulier. On comprend tout de suite que le bon fonctionnement de cette base de données est essentiel. Sans elle, DFSR n’est plus capable de répliquer les changements opérés localement ou de déterminer s’il doit prendre en comptes les mises à jour opérées sur les autre membres du groupe de réplication.

 

Avant c’était simple

DFSR a été introduit avec Windows 2003 mais réellement généralisé à partir de Windows Server 2008 où il était possible de basculer le SYSVOL vers DFSR avec l’utilitaire DFSRMIG.EXE. Depuis cette époque, lors d’un arrêt non planifié, on avait le message suivant dans le journal dédié à DFSR :

image

 

C’est clair, rien à faire, le système d’exploitation s’occupe de tout. Si le processus de recovery se passait bien, on avait un event 2214 :

image

 

ou 2216 dans le cas contraire :

image

Dans les deux cas, on n’avait rien à faire, DFSR s’occupait de tout. Mais ça c’était avant.

 

Mais c’était avant (2008 R2/2012)

Avec Windows Server 2012, Microsoft a considéré qu’il y avait un risque de perdre des données et que par défaut DFSR ne devait plus auto-réparer sa base de données.

image

 

L’event donne deux informations :

  • Premièrement, il faut que nous nous assurions de ne pas perdre de données lors de la remise en ligne, c’est de notre responsabilité
  • Deuxièmement, que la remise en ligne s’effectue à l’aide d’une ligne de commande qui doit être exécutée localement sur le serveur incriminé.

 

Cela devient problématique car en cas de crash d’un contrôleur de domaine, Active Directory est bien capable de revenir en ligne, le répertoire SYSVOL est bien partagé et visible par les utilisateur mais le contenu des GPO peut avoir été altéré et ne plus être cohérent avec les autres contrôleurs de domaine.

 

Comme Microsoft est cohérent, il a mis à disposition un correctif KB2663685 pour Windows 2008 R2 pour reproduire le mode de fonctionnement de Windows Server 2012. Tant que le correctif n’est pas généralisé sur tous les serveurs membre du groupe de réplication DFSR, le comportement du processus de recovery va donc varier. ce correctif permet aussi de configurer le comportement du processus de recovery avec la commande suivante :

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE/TRUE

 

Maintenant c’est subtil (2012 R2)

Comme c’était pas encore assez compliqué, on change encore. Il faut lire un billet décrivant les changements opérés sur DFSR dans Windows 2012 R2 pour le comprendre :

clip_image002

 

Il faut comprendre que Microsoft a mis à disposition une clé de registre pour configurer le comportement de DFSR dans le scénario du “Dirty shutdown” mais n’a pas réussi à démontrer qu’il y a réellement risque de perte de données. La racine DFS de domaine gui prend en charge la réplication de SYSVOL échappe au processus de “Dirty shutdown”. Seulement pour lui, le recovery redevient automatique. C’est une bonne nouvelle pour les administrateurs Active Directory qui n’ont plus à se soucier du “Dirty shutdown” sur les contrôleurs de domaine Windows Server 2012 R2 (uniquement).

 

Conclusion

J’avais bien annoncé que le sujet était “capilo-tracté”. Donc pour faire simple un petit tableau pour résumer la situation :

  Windows 2008 Windows 2008 R2 (sans KB2663685) Windows 2008 R2 (avec KB2663685) Windows 2012 Windows 2012 R2
Automatic Dirty shutdown recovery pour SYSVOL Oui Oui Non Non Oui

Non sauf reconfiguration avec WMIC

 

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

URA DirectAccess activation failure in NLB

A MVP colleague of mine challenged me a few days ago about an URA DirectAccess activation process failure in NLB. I already wrote a blog post on that scenario. I tried to reproduce his bug on my platform and succeeded. I was surprised. Why the wizard is asking me for IPv6 addresses? It’s not a HLB deployment.

URANLB1

 

After providing required information, activation started but ended with the following error. What parameter is incorrect. After some research, I found it’s the “Set-RemoteAccessLoadBalancer” Powershell command that fail.

URANLB3

I retrieved the original command generated by the URA Wizard and discovered that the command include IPv6 related parameters. After removing them and run the “Set-RemoteAccessLoadBalancer” Powershell command as illustrated bellow. It works.

URANLB4

That’s why I choose to configure DirectAccess in Powershell.

 

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

Framework Dot Net 3.5 sur Windows Server 2012

Juste un billet rapide sur une erreur rencontrée lors de l’installation de SQL Server 2012 sur un serveur Windows Server 2012. Lors de l’installation de SQL Server, l’installation des outils d’administration a échouée à cause de la fonctionnalité NetFX3 (FrameWork Dot.Net 3.5)

NETFX3_SQLBUG

 

La fonctionnalité n’est pas installée, pas de problème il suffit de l’installer. Manque de bol, il semblerait bien que la fonctionnalité ne soit pas présente dans une installation standard de Windows Server 2012.

ADDFEATUREGUINETFX30

 

Passons sous la moquette avec un peu de Powershell à la recherche du Framework Dot.Net perdu.

SOUSLAMOQUETTE 

Le résultat est sans appel. Le Framework Dot.Net est effectivement pas présent dans une installation de Windows Server 2012. Conclusion, DISM.EXE va donc s’imposer. On va utiliser DISM.EXE sur notre installation pour ajouter la feature manquante et sous ses sous-composants à partir du média d’installation.

DISM

Dès lors, la fonctionnalité devient disponible, il est possible de relancer l’installation de la feature. Après vérification, elle est bien disponible pour installation et même installée.

NETFRAMEWORKFEATUREINSTALLED

 

Ne reste plus qu’à relancer l’installation des mes outils d’administration de SQL Server et miracle, cela fonctionne enfin.

SQLSUCCESS

Comme quoi, tout n’est pas nécessairement inclus. C’est aussi le cas de Powershell V2.

 

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

Publishing IPHTTPS on an alternate port

After a warn-up with the TMG can be a good friend of DirectAccess post, let’s raise the level and try to publish our IPHTTPS protocol on an alternate public port. But why do we need to do such a thing? Maybe we already have an application published on the 443 external port of my TMG box. In my case, it is just another IPHTTPS publishing rule (Why do-I need two DirectAccess, that’s a good question I will answer in another blog post. It’s a part of a future DirectAccess Challenge). So it’s just again a non-Web Server protocol that need to be published. Let’s start the wizard.

 

 

First action, choose a name for our new rule. In my lab, I wanted to introduce an additional Unified Remote Access Server that will be located in a branch office. Don’t ask why I need it, it’s a challengeJ. This new URA Server has been configured with a single Network Adapter and will have its IPHTTPS protocol published on Internet.

 

 

In my lab, my Unified Remote Access Server is located in a branch office. We just provide its internal IPv4 public address.

 

 

It’s a « HTTPS server protocol »yes, but not published on its default port. For this reason, we must customize protocol definition.

 

 

We keep all protocol definition default value except we replace « 443 » by « 444 « .

 

 

This protocol will be published on the same external interface as my first IPHTTPS protocol. This would not cause conflict because we won’t be using the default port.

 

 

That almost terminated. Now it’s time for magic tricks.

 

 

And now two magic tricks. First one, we must customize rule to reconfigure how network frames will arrive to the URA. They must appear to come from the TMG box. Otherwise, it will not work.

 

 

Second magic trick, we must instruct the DirectAccess client to use this new port for IPHTTPS protocol. This information is provided in the Client-Side GPO generated for my branch-office URA Server. Let’s have a look at the IPHTTPS configuration with a Get-NetIPHTTPSConfiguration PowerShell CommandLet.

 

 

Note that I had to specify a domain controller because my lab environments include RODC at branch office. Updating a GPO on a RODC is not a magic trick. If I can retrieve the IPHTTPS protocol configuration from a GPO, I can pass this object to a Set-NetIPHTTPSConfiguration PowerShell Command to reconfigure the ServerURL parameter.

 

 

Now let’s see if the magic trick work on a Windows 7 DirectAccess-enabled computer connecting to the URA Server in my Branch-office. And Yes, IPHTTPS interface is operational and using my alternate port.

 

 

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

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

L’essentiel de DirectAccess dans Windows Server 2012 en une heure

Un peu de retard dans le traitement de mes To-to Lists ces temps-ci.  DirectAccess étant une de mes marottes depuis sa première version (moi aussi j’ai cherché à déployer DirectAccess avec la Beta 3 de Windows Server 2008 R2 ), je ne pouvais passer à coté de cette session Techdays animée par deux pionniers en la matière.

image

 

Bref, un must à voir, surtout pour comprendre que maintenant, DirectAccess c’est plus que pour les pionniers ou pour les Geeks que nous sommes mais c’est une véritable solution qu’il ne faut pas sous-estimer. Aujourd’hui, l’expérience utilisateur tiens une part importante dans la conception d’un poste de travail Windows 7/8.

 

Ecoutez vos utilisateurs pour eux la solution magique doit :

  • être utilisable par tous, y compris madame “Michu”
  • être transparent, ce serait parfait
  • être tout terrain, y compris dans les hôtels

 

 

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

Essayer la déduplication, c’est l’adopter

La déduplication est une des nouvelles fonctionnalités de Windows Server 2012. D’habitude quand la chose est trop belle, j’ai tendance à considérer que c’est trop beau, qu’il y a forcément un piège.

 

Une très bonne idée de la déduplication dans Windows Server 2012, c’est qu’il est possible de l’essayer sans l’activer. Plus précisément, on a juste à installer le rôle et utiliser l’utilitaire DDPEVAL.EXE. Il se chargera d’évaluer l’espace disque qu’on est en mesure d’économiser. Dans l’illustration ci-dessous, c’est le volume dédié au VMM Library Server de mon cloud qui a été évalué :

DDPEVAL

 

84% d’espace disque, je signe. j’évite donc l’achat d’un QNAP ou de partir dans la Winology. Donc La Déduplication +1 pour le facteur WAF.

 

BenoîtS – Simple and Secure by Design but also WAF compliant

Windows Server 2012 DirectAccess with F5 BIG-IP white paper

When designing a highly available DirectAccess infrastructure, many customers choose to use their existing F5 BIG-IP appliances to provide network scalability and failover. With Forefront UAG 2010, F5 and Microsoft provided a deployment guide available here, including detailed information’s about BIG-IP configuration.

 

A new guide is available for Windows Server 2012 at this location. This guide cover all deployment scenarios available for DirectAccess with Windows Server 2012. But, do not expect to find detailed information covering your BIG-IP configuration. You will find most of theses information in the previous version .

 

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