Archives mensuelles : novembre 2015

Architecture WAP : Introduction

Ca faisait quelques temps que nous avions pas fait un tour dans le donjon, le revoilà. On va continuer à parler de Windows Azure Pack. Non pas pour ajouter de nouveaux composants mais pour les revisiter et discuter architecture et répondre principales questions liées au design d’une infrastructure Windows Azure Pack hautement distribuée. Avant de parler de Windows Azure Pack, nous allons avoir beaucoup de sujets de discussions :

Cela va rester du haut niveau. L’idée est de répondre aux questions les plus importantes pour poser les fondations de votre future infrastructure Windows Azure Pack. Je fais l’impasse sur la conception même des Stamps que vous allez déployer, il y a trop de paramètres à prendre en compte, ça dépasse de loin le cadre de l’architecture d’une infrastructure Windows Azure Pack. On commence avec une page blanche, à savoir deux Datacenters interconnectés par un bon WAN :

clip_image001

Bonne lecture, on commence avec un sujet simple pour commencer : Design infrastructure Active Directory.

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

Architecture WAP – Design infrastructure Active Directory

Ça semble tellement simple qu’on se demande pourquoi il faudrait se poser la question. Si simple vous dites? Entrez, on va discuter, … On va effectivement commencer avec un AD pour le cœur de notre infrastructure. On va donc y raccorder :

  • L’infrastructure ADFS
  • Notre infrastructure Windows Azure Pack (partie privilégiée)
  • Notre infrastructure Windows Azure Pack (partie locataire)
  • L’infrastructure SCOM (management Server et Dataware House Server)
  • L’infrastructure Service Manager Automation / Orchestrator
  • L’infrastructure SCVMM avec son Service Provider Foundation

Etrange, je n’ai pas cité les clusters Hyper-V? C’est normal car on va faire les choses correctement. Tous les produits cités précédemment constituent le Fabric Management de notre infrastructure Windows Azure Pack. Une bonne pratique est d’isoler ces composants dans une forêt d’administration dont l’accès sera limité aux seuls exploitants de la plateforme. Maintenant, parlons des Clusters Hyper-V. On va distinguer :

  • Les clusters Hyper-V utilisés pour héberger le Fabric Management
  • Les Clusters hyper-V utilisés pour héberger les workloads de nos futurs locataires

 

Pour le Fabric Management, il est logique de les raccorder à la forêt d’administration. Au passage, c’est dans ce domaine que sera réalisé la préparation de domaine pour stocker les secrets de SCVMM. Pour rappel, lors de l’installation de SCVMM on doit décider si on veut stocker les clés de SCVMM localement ou dans l’Active Directory. C’est ce dernier choix qui sera le bon. Ces clés sont essentielles car sans elles on ne peut pas accéder à la base de données de SCVMM. Je vous laisse deviner ce qui se passerait si on avait retenu de les stocker localement et qu’on ait perdu le serveur physique ou virtuel. Comme une petite piqure de rappel ne fait jamais de mal, autant, quelques lectures saines :

clip_image001

Maintenant attaquons nous au problème des clusters Hyper-V prévus pour héberger les workloads de nos futurs locataires. Doit-on les raccorder à la forêt d’administration? La réponse est dans la question. Il faut une claire séparation entre les usages. On va donc avoir une second forêt que je nomme « hosting.local » qui disposera d’une relation d’approbation unidirectionnelle (sécurité oblige). On y placera les clusters Hyper-V qui hébergeront les workloads de nos locataires. Si tout était si simple ce serait bien. Nous n’avons pas encore parlé de l’infrastructure WebSites. Pour rappel, elle comprend les rôles suivants :

  • Management Server
  • Controller
  • Database
  • Publisher
  • File Server
  • Web Worker
  • Frond-End

L’infrastructure Azure Pack Web Sites présente l’avantage de pouvoir fonctionner indépendamment des domaines avec des machines en Workgroup. Sur le papier, c’est pas mal. Le problème, c’est que cela rend cette infrastructure plus compliquée à exploiter. Essayons de raisonner différemment. Quels sont les rôles qui assurent la gestion de l’infrastructure et quels sont ceux qui sont consommés par les locataires :

  • Management : Participe à la gestion de l’infrastructure
  • Controller : Participe à la gestion de l’infrastructure
  • Database : Participe à la gestion de l’infrastructure
  • Publisher : Participe à la gestion de l’infrastructure
  • File Server : Participe à l’usage par les locataires
  • Web Worker : Participe à l’usage par les locataires
  • Frond-End : Participe à la gestion de l’infrastructure

On comprend que bon nombre de rôles sont liés à la gestion de l’infrastructure. Les instances de ces rôles seront donc déployées sur des machines virtuelles raccordées au domaine d’administration. Il ne nous reste que File Server et Web Worker. Ces deux rôles sont directement liés aux locataires :

  • File Server : Stockage et dépôt des packages WebDeploy des locataires et donc repository des sources pour alimenter les instances Web Worker
  • Web Worker : Consommation des packages Web Deploy en mode cohabitation ou isolé

Pour ces deux rôles, la recommandation est effectivement de les raccorder au domaine « hosting.local ». Pour conclure, voilà les bases de notre infrastructure Active Directory posées :

clip_image002

Avec deux Datacenters, je commence par poser deux zones réseau distinctes pour bien séparer les deux forêt Active Directory qui vont être mises en place. Dans chaque Datacenter, les contrôleurs de domaine de chaque forêt seront hébergés sur des clusters Hyper-V distincts. Nous aurons donc :

  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine WindowsAzurePack.Local
  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine hosting.local

De cette manière, chaque Datacenter est indépendant de l’autre. La défaillance d’un Datacenter n’aura donc aucun impact sur le service Active Directory et ce pour les deux forêts.

Remarques :

  • J’ai volontairement exclus le choix Workgroup pour l’infrastructure Web Sites de Windows Azure Pack. Ce mode de fonctionnement nous interdit de proposer à nos locataires une authentification Windows intégrée dans leurs sites web. S’interdire de proposer du service à nos futurs locataires est un non-sens
  • Les contrôleurs de domaine sont nécessairement des serveurs physiques, Pas de concession sur ce point.
  • J’ai volontairement exclus de parler des RODC. Pour la forêt d’administration, il n’y a pas de besoin vu que c’est une forêt isolée. Pour la forêt dédiée aux locataires, ça peut avoir un sens mais uniquement pour le rôle Front-end

Alors, toujours un simple Active Directory posé sur un coin de table?

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

Active Directory recycle bin (re publication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

 

Pour ce billet, un sujet que j’ai eu à traiter plusieurs fois : La restauration d’objets AD. La mise en œuvre d’un annuaire Active Directory ne pose pas de problème particulier en terme de conception. Par contre quand un exploitant viens vous demander comment on peut restaurer un utilisateur supprimé, là, cela devient sportif.

Pour ceux qui n’ont pas pratiqué ce sport au moins une fois, il faut savoir que :

  • L’objet supprimé reste dans l’annuaire Active Directory pendant un certain temps (dépend du système d’exploitation et du niveau de Service Pack), c’est la notion de TombStone
  • L’objet est dépouillé d’un certain nombre de ces attributs, donc en particulier l’appartenance aux groupes

La restauration d’un utilisateur ne pose pas de problème particulier, par contre, son appartenance à d’éventuels groupes implique de savoir à quel(s) groupes il appartenait. Le sujet se corse quand on sait que l’appartenance à un groupe est un attribut du groupe et non de l’utilisateur. L’attribut “MembeOf” de l’objet utilisateur n’est qu’un attribut calculé. Autre problème, si on restaure l’utilisateur et les groupes, on risque de repositionner des membres qui devraient ne plus l’être.

Maintenant que les règles de ce sport sont clairement établies, voyons comment traiter cette problématique  :

Etant donné que Windows Server 2008 R2 fait la part belle à PowerShell avec des cmdlets dédiées à Active Directory, il était donc tout naturel de faire le tour du propriétaire avant de s’attaquer à la restauration d’un objet utilisateur et de son appartenance à un groupe sans restaurer le groupe en question (challenge!).

Mise en place de la cible

Objectif, tout faire en Powershell, en premier lieu, créer un conteneur organisationnel dans lequel on va créer le compte qui sera supprimé. La commande utilisée est “New-ADOrganizationalUnit” :

clip_image001

Une fois le conteneur créé, on peut afficher toutes ses caractéristiques à l’aide de la commande “Get-ADOrganizationalUnit” :

clip_image002

 

Remarque : On peut constater la présence de l’attribut “ProtectedFromAccidentalDeletion”, une des nouveautés de Windows Server 2008 qui permet de positionner des permissions empêchant un administrateur de supprimer un conteneur sans réfléchir!

Une fois le conteneur créé, passons à l’utilisateur avec la commande “new-ADUser” tel qu’illustré ci-dessous :

clip_image003

 

Vérifions que notre utilisateur existe bien dans le conteneur. Comment? Simplement avec l’aide du provider “AD:”, c’est comme se balader dans une structure de répertoire :

clip_image004

 

Passons à la suite avec la création de notre groupe global avec la commande “New-ADGroup” :

clip_image005

 

Et le plus important, le positionnement de notre utilisateur comme membre de ce groupe avec la commande “Add-ADGroupMember” :

clip_image006

 

Histoire de vérifier, voyons la liste des membres de ce groupe avec la commande “Get-ADGroupmember” :

clip_image007

 

Tout est maintenant prêt pour notre démonstration, à l’exception de l’Active Directory Recycle Bin qui n’est pas activée par défaut.

Mise en place de l’Active Directory recycle Bin

Avant de commencer, il faut respecter un certain nombre de pré-requis :

  • Tous les contrôleurs de domaine de la forêt en Windows Server 2008 R2
  • Augmenter le niveau de forêt à “Windows Server 2008 R2”

Le décors est posé. Maintenant la pièce de résistance! Celle-ci est une fonctionnalité optionnelle d’Active Directory qu’il faut activer à l’aide de la commande “Enable-ADOptionalFeature, tel qu’illustré ci-dessous :

clip_image008

 

Pour vérifier que c’est bien fait, on peut demander la liste des fonctionnalités Active Directory actuellement installées dans notre environnement avec la commande “Get-ADOptionalFeature” :

clip_image009

Tout peter comme il disait commandant Sylvestre!

Et toujours en PowerShell :

clip_image010

 

Pour s’en assurer, on peut lister le contenu du conteneur avec le provider “AD:”

clip_image011

***, je vais me faire engueuler!

Une fois l’objet supprimé, il est six pieds sous terre. Pour pouvoir le restaurer, encore faut-il pouvoir le retrouver parmi les objets supprimés avec la commande “Get-ADObject” sur un conteneur bien précis “Deleted Objects” en n’oubliant pas de préciser d’inclure les objets supprimés :

clip_image012

 

A ce stade, on n’est pas plus avancé qu’avant. L’objet est supprimé. Une simple restauration autoritaire de l’objet (pourvu qu’on dispose d’une sauvegarde récente!) ne restaurera pas les appartenances aux éventuels groupes.

C’est là que l’Active Directory Recycle Bin change tout. La commande “Restore-ADObject” à laquelle on précise le GUID de l’objet à restaurer (d’ou l’intérêt de lister préalablement les objets supprimés et les attributs) va nous permettre de restaurer non seulement l’utilisateur mais aussi ses appartenances à un ou plusieurs groupes sans pour autant effectuer une restauration de ces groupes :

clip_image013

 

On peut s’assurer que l’objet est bien restauré en affichant le contenu du conteneur organisationnel à l’aide du provider “AD:” et même afficher la liste des membres du groupe.

clip_image014

 

L’utilisateur restauré est de nouveau membre du groupe.

Dans cette démonstration, j’ai supprimé un user mais j’aurai tout aussi bien pu supprimer l’intégralité du conteneur. L’opération aurait juste été un peu plus complexe dans la mesure où il faut penser à restaurer le conteneur parent d’un objet avant de pouvoir restaurer celui-ci.

Voila une fonctionnalité de Windows Server 2008 R2 qui est plus qu’intéressante pour les exploitants. Quand on sait que les extensions Active Directory de PowerShell reposent sur un Web Service, donc plus besoin de RPC pour administrer des contrôleurs de domaine!

Pour plus d’informations sur la restauration d’objets Active Directory, un excellent article de Technet Magazine de l’époque, bien plus digeste que la KB.

 

BenoîtS – Simple by Design

Un challenge fait de CERTREQ, CERTUTIL, NETSH et APPCMD

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

C’est en relisant le billet de mon collègue Alexandre GIRAUD sur la demande de certificats sous IIS 7.0, que je me suis rendu compte du parcours accompli par Microsoft. C’est devenu si simple de demander un certificat qu’on ne se rends plus compte de comment cela fonctionne en dessous.

A quoi cela sert-il de le savoir? Et bien par exemple à savoir comment se débrouiller sous Windows Server 2008 Core ou de faire un pied de nez à mon collègue Alexandre GIRAUD qui a présenté la chose de manière graphique (la honte!).

Je prend donc le pari de refaire le même billet que mon collègue mais uniquement en ligne de commande (Les Core-Septiques peuvent aller directement à la fin du billet).

Pré-requis

Tout comme mon collègue, je considère que la PKI est opérationnelle (installée avec ADCS, en mode entreprise).

Création du fichier de demande

C’est la première étape, c’est un peu ce que l’assistant de IIS 7.0 nous cache. Le contenu ci-dessous constitue un fichier de demande de certificat.

[Version]

Signature= »$Windows NT$”

[NewRequest]
Subject = « CN=nom pleinement qualifié du site web »
Exportable = FALSE
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = « Microsoft RSA SChannel Cryptographic Provider »
ProviderType = 12
SMIME = FALSE
RequestType = CMC

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

[RequestAttributes]
CertificateTemplate= WebServer

 

Le tout est sauvegardé dans un fichier INF nommé “SSL.INF”. Pour l’instant, ce n’est que du texte brut (mais cela va changer!).

la ligne “Subject” désigne le nom pleinement qualifié du site web Internet pour lequel on désire obtenir un certificat. Pour des raisons de sécurité, l’export de la clé privée n’est pas demandé, donc, il ne sera pas possible de l’exporter (par exemple pour mettre en place du NLB pour le site web sur le second nœud). A noter qu’il est possible d’utiliser un caractère wildcard (*.siteweb.com).

La ligne KeySpec indique l’échange de clés. Quant à la ligne “KeyUsage”, la valeur indiquée correspond aux usages nécessaires des certificats de site web, à savoir Digital Signature et Key Encipherment.

Très important, la ligne “MarchineKeySet = True” pour indiquer que le certificat obtenu devra être placé dans le magasin de l’ordinateur pour que IIS puisse y accéder (sinon je suis bon pour l’asile de fou!).

Pour les derniers, c’est du standard. Le plus important, c’est la dernière ligne, indiquant le modèle de certificat que l’on désire demander. C’est donc normal de voir figurer “WebServer”.

Génération du fichier de requête

On va transformer notre simple fichier texte en fichier correctement formaté pour une demande de certificat.

clip_image001

Histoire de valider que tout s’est bien passé, une seconde commande CERTUTIL.EXE devrait nous confirmer que tout s’est bien passé.

clip_image002

 

Histoire de voir à quoi ressemble une demande de certificat encodée, on peut consulter le contenu. La ligne d’entête nous confirme bien que c’est une demande de certificat.

clip_image003

 

Soumission la demande

Notre demande de certificat doit encore être soumise à notre autorité de certification. Etant donné que celle-ci est de type “Entreprise”, elle est publiée dans l’annuaire Active Directory. On peut donc soumettre la demande en ligne, tout comme le propose l’assistant de IIS. Si on ne peut réaliser la demande en ligne, ce sera donc la même commande mais exécutée directement sur l’autorité de certification (avec le fichier de demande qui va avec).

clip_image004

 

Etant donné que mon autorité de certification est de type entreprise et qu’en tant qu’administrateur du domaine, j’ai le droit de soumettre une demande pour ce gabarit de certificat, alors, la demande est automatiquement acceptée. Et pour preuve :

clip_image005

 

Il ne reste plus qu’à intégrer le certificat dans le magasin personnel de l’ordinateur.

clip_image006

 

On peut même s’en assurer avec l’exécution de la commande suivante :

clip_image007

 

Finissons en avec notre demande de certificat en acceptant son usage par la commande suivante :

clip_image008

 

A ce stade, notre certificat est utilisable dans la console IIS. Donc on pourrait faire le binding SSL immédiatement. Cependant, on continue en ligne de commande.

APPCMD et les certificats : Un truc de fou!

Avec IIS, cela se complique un peu (juste un peu). APPCMD.EXE qui permet de gérer IIS en ligne de commande est bien capable de configurer un site web pour répondre en HTTPS mais pour le certificat, c’est pas dans IIS que cela se passe mais à l’étage en dessous (HTTP.SYS). Nous voila donc dans les sous-sols de IIS, plus précisément dans l’antre de NETSH.EXE, la boite à outil pour tout ce qui sort de l’ordinaire dans le réseau Windows. Mais avant d’en arriver à NETSH, on va avoir besoin de récupérer quelques informations sur le certificat importé :

clip_image009

 

Globalement, j’ai besoin de deux choses. Le CertHash (logique) mais aussi le Simple Container Name. Plus précisément la partie après “CertReq-WebServer-“ (J’ai prévenu, on entre dans l’asile de fou!).

Welcome to the NETSH HELL!!. Depuis IIS 6.0, le moteur HTTP a été dissocié de IIS. Toute la gestion des certificats passe donc par NETSH. Dans le cas qui nous occupe, on va associer un certificat à une adresse IP et un port donné (toutes les adresses IP dans mon cas en HTTPS s’il vous plait) pour un certificat stocké dans le magasin ordinateur, identifié par son Hash pour un usage qui sera celui de son Key Container (Ne pas me demander pourquoi, ça marche comme cela, c’est fou non?). On peut même constater que c’est bien fait avec une seconde commande NETSH (bien plus simple cette fois) :

clip_image010

 

Après être descendu aux enfers, on va remonter un étage au dessus avec APPCMD.EXE pour lui demander d’ajouter le protocole HTTPS pour le site web par défaut, avec le certificat identifié par son Hash (C’est toujours à couper au couteau!) :

clip_image011

 

Je peux même prouver que cela a bien marché en affichant la nouvelle configuration du site web par défaut :

clip_image012

 

Pour les septiques de la ligne de commande, on peut constater que le résultat est bien celui attendu, à l’exception peut être du retrait de HTTP.

clip_image013

 

Un dernier tout de magie avec APPCMD pour faire disparaitre le protocole HTTP :

clip_image014

 

Et oui, seul le protocole HTTPS subsiste (J’ai gagné mon pari!)

clip_image015

 

A quoi cela sert-il?

Déjà, à ceux qui sont arrivé jusqu’ici sans ferme le navigateur chapeau. C’est vrai, a quoi cela sert-il de demander der certificats en ligne de commande?

  • Automatiser la configuration d’une ferme de serveurs Web
  • Configurer un serveur web sous Windows Server 2008 Core
  • Automatiser l’installation de serveurs SCCM (le mode natif, …)
  • A relever un pari à la con, aussi, …

Benoîts – Simple by Design (Besoin de vacances + Arrêter le café)

DFSRMIG & SYSVOL (Republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Lors de la mise à niveau d’une infrastructure Active Directory, la mise à niveau des contrôleurs de domaine vers Windows Server 2008 doit être finalisée par une migration de NTFRS vers DFS-R. En effet, même avec des contrôleurs de domaine sous Windows Server 2008, c’est toujours NTFRS qui est utilisé pour répliquer le contenu de SYSVOL (sauf si on a pas migré). DFS-R présente un certain nombre d’avantages dont :

  • Une meilleure fiabilité dans les environnements complexes comprenant de nombreux contrôleurs de domaine
  • La possibilité de répliquer au niveau des changements opérés dans les fichiers (Remote Differential Compression)
  • Une meilleure sécurisation du contenu de SYSVOL sur les RDOC.
  • Jusqu’à seize transferts de fichiers simultanément, au lieu de quatre
  • Une gestion asynchrone des transferts
  • Une reconstruction automatique suite à un arrêt brutal du serveur

Pour bénéficier de ces avantages et de beaucoup d’autres, il est nécessaire de migrer  SYSVOL vers DFS-R. Ce processus doit être réalisé sur l’ensemble des contrôleurs de domaine de chaque domaine. le processus de migration est intégralement piloté au travers d’un seul et unique outil : “DFSRMIG.EXE”.

Pré-requis

  • La migration vers DFS-R n’est possible que dès lors que le mode de domaine est “Windows Server 2008”. Ceci implique que tous les contrôleurs de domaine de version antérieurs ont bien été migrés. Pour rappel, cette opération sera irréversible. Il ne sera plus possible de promouvoir des serveurs membre en contrôleurs de domaine pour les systèmes d’exploitation antérieur à Windows Server 2008.
  • Chaque contrôleur de domaine reportera son état de migration ainsi que son avancement dans des objets créés pour l’occasion dans l’annuaire Active Directory. Il est donc impératif que la réplication d’annuaire Active Directory soit opérationnelle. De ce fait, on peut tout de suite poser la règle suivante : “C’est la vitesse de propagation des mises à jour Active Directory qui donne le tempo de la migration et impose la durée globale de l’opération” (Commandant Sylvestre s’abstenir!).
  • Le processus de bascule vers DFS-R va reprendre le contenu du partage SYSVOL actuel. Il est donc impératif de s’assurer qu’il n’y a pas de problème à ce niveau. Par exemple qu’il y a bien cohérence entre la version de la GPO inscrite dans l’annuaire Active Directory et son contenu dans le partage SYSVOL.

Démarche

La démarche de l’outil DFSRMIG.EXE repose sur quatre phases :

  • Phase “Start” : DFSRMIG.EXE va mettre en place les moyens nécessaires au suivi de la migration pour chaque contrôleur de domaine. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Prepared” : DFSRMIG.EXE va mettre en place un nouveau répertoire SYSVOL et alimenter son contenu. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • phase “Redirected” : DFSRMIG.EXE va continuer à maintenir l’ancien répertoire SYSVOL  mais rediriger le partage vers le nouveau répertoire SYSVOL. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Eleminated” : Lors de cette dernière phase, NTFRS sera démantelé. Seul DFS-R sera utilisé pour répliquer le contenu de notre nouveau partage SYSVOL.

 

Il est à noter que l’ensemble du processus sera intégralement pilote depuis le contrôleur de domaine hébergeant le rôle de maitre d’émulateur principal de domaine (PDCE). De plus, le processus de migration est réversible (possibilité de revenir à l’état précédent ou de tout annuler) sauf pour la dernière étape. On peut donc considérer que la migration ne présente pas de risque majeur pour l’infrastructure.

Dans quel état suis-je?

C’est la phase d’initialisation. L’objectif de cette phase est de mettre en place les moyens nécessaire au suivi de la migration. D’un point de vue technique, chaque contrôleur de domaine devra reporter son état de migration dans l’annuaire Active Directory toutes les cinq minutes. C’est grâce à cela que l’on va consolider les informations et déterminer l’avancement de la migration. Pour déterminer dans quel état se trouve la migration, on dispose de la commande DFSRMIG.EXE /GetGlobalState tel qu’illustré ci-dessous :

clip_image001

 

Dans le cas illustré ci-dessous, le processus de migration n’a pas encore commencé. Pour ma démonstration, mon environnement comprend un domaine composé de trois contrôleurs de domaine opérant sous Windows Server 2008, dans un seul site Active Directory.

Initialiser la migration : Phase “Start”

Pour passer d’un mode à un autre, on dispose de l’argument “/SetGlobalState” auquel on associe une valeur. Dans le cas présent, la valeur “0” pour initialiser la phase “Start”. tel qu’illustré ci-dessous :

clip_image002

 

On peut immédiatement s’assurer que la commande a bien été prise en compte avec une nouvelle exécution de la commande “DFSRMIG.EXE /GetGlobalState” tel qu’illustré ci-dessous :

clip_image003

 

On peut même obtenir un peu plus de précision avec l’argument “/GetMigrationState” :

clip_image004

 

Pour plus d’informations, on dispose même d’un journal d’exécution de chaque commande “DFSRMIG.EXE” dans le répertoire “C:\Windows\Debug” sur chaque contrôleur de domaine. A ce stade, rien n’a encore changé, on a juste initié le processus de migration.

Préparer la migration : Phase “Prepared”

Entrons dans le vif du sujet. Le passage à la phase “Prepared” va engendrer la création d’un répertoire “SYSVOL_DFSR” sur chaque contrôleur de domaine. Son contenu sera recopié à l’aide de ROBOCOPY.EXE.

clip_image005

 

L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 1” indique que chaque contrôleur de domaine devra procéder à la création de son propre répertoire”SYSVOL_DFSR”. Pour accélérer les choses, on peut  forcer nos contrôleurs de domaine à travailler un peu plus rapidement avec la commande : “DFSRDIAG.EXE POLLAD” :

clip_image006

 

De cette manière, on force notre contrôleur de domaine à prendre en considération le changement d’état au lieu d’attendre cinq minutes. Avant de pouvoir continuer, il faut s’assurer que chaque contrôleur de domaine a bien pris en charge le changement d’état avec la commande “DFSRMIG.EXE /GetMigrationState”.

clip_image007

 

L’illustration ci-dessous nous indique que le contrôleur de domaine “DC2” n’a pas encore réaliser la première réplication initiale. Il n’est donc pas encore possible de passer à la suite.

clip_image008

 

Avec un peu de patience, tous les contrôleurs de domaine ont fini par créer leur propre répertoire “C:\Windows\SYSVOL_DFSR”. Pour s’en assurer, on trouvera même le journal d’exécution de la commande “Robocopy.Exe” dans le répertoire “C:\Windows\Debug”. On pourra y constater que l’opération à consister en une copie locale des données. On comprend donc pourquoi il est important que le contenu de SYSVOL soit cohérent entre tous les contrôleurs de domaine :

clip_image009

 

Un peu plus tôt dans ce billet, j’ai indique que chaque contrôleur de domaine reportait son état individuel de migration dans l’annuaire Active Directory. Chaque contrôleur de domaine va créer un conteneur “DFSR-LocalSettings” tel qu’illustré ci-dessous pour y référencer son état dans l’attribut msDFSR-Flags :

clip_image010

 

La valeur “16” indique un état “Prepared”. Voila donc un moyen fiable de suivre l’avancement de chaque contrôleur de domaine.

Une petite subtilité pour les RODC. Chaque contrôleur de domaine est censé maintenir son état en créant le conteneur et en renseignant l’attribut. Pour eux, ils ont besoin d’un petit coup de pouce avec la commande “DFSRMIG.EXE /CreateGlobalObjects” pour créer le conteneur à leur place. Les RODC maintiendront leur état en actualisant l’attribut directement sur le PDCE.

 

Redirection : Phase “redirected”

Jusqu’à maintenant, SYSVOL est toujours SYSVOL, il n’a pas changé. Pour s’en assurer, rien de mieux qu’une commande “NET SHARE” :

clip_image011

 

L’objectif de cette phase est de remplacer le répertoire partagé pour SYSVOL, tout en continuant à maintenir la réplication NTFRS, ce qui nous permet de toujours revenir en arrière, voire même d’annuler toute l’opération. Et bien basculons avant la commande “DFSRMIG.EXE /SetMigrationState 2” tel qu’illustré ci-dessous :

clip_image012

Lors de cette phase, chaque contrôleur de domaine va de nouveau effectuer un Robocopy entre son répertoire “SYSVOL” et “SYSVOL_DFSR” pour s’assurer qu’il dispose bien des fichiers les plus récents. Ici encore, on peut suivre chaque migration avec les fichiers de journalisation générés dans le répertoire “C:\Windows\Debug” ou bien plus globalement tel qu’illustré ci-dessous :

clip_image013

 

Si on va plus vite que la réplication, la commande “DFSRMIG.EXE /GetMigrationState” nous indiquera que nos contrôleurs de domaine n’ont pas encore commencé l’opération. Avec un peu de patience (ou à la méthode “Commandant Sylvestre”  : DFSRDIAG.EXE POLLAD + REPADMIN /SYNCALL /E = *** j’ai le réseau qui lag!), on arrive au résultat suivant :

clip_image014

 

Petite remarque, il serait opportun de “figer” les modifications réalisées sur “SYSVOL” avant de passer à la phase “Redirected” pour s’assurer que chaque contrôleur de domaine dispose bien des fichiers les plus récents.

L’avancement individuel de la migration peut être constaté en consultant la valeur de l’attribut msDFSR-Flags” qui doit être passé à 32 :

  clip_image015

 

Ou bien plus simplement avec une commande “NET SHARE”:

clip_image016

 

On constate donc que les partages “NETLOGON” et “SYSVOL” désignent maintenant un sous-répertoire différent. A ce stade, il est toujours possible de revenir en arrière, voire d’annuler toute la migration. Pour s’en convaincre, chaque contrôleur de domaine de dispose toujours de sa propre copie du répertoire SYSVOL, toujours maintenue :

clip_image017

 

Elimination: Phase “Eliminated”

L’ultime étape, celle qui est irréversible (merci de maintenir les commandants sylvestre à l’écart). L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 3” va supprimer le répertoire “SYSVOL” ainsi que les souscriptions FRS de chaque contrôleur de domaine :

clip_image018

 

Comme toujours, on peut constater l’avancement avec la commande “DFSRMIG.EXE /GetMigrationState”

clip_image019

 

Une fois l’opération terminée :

clip_image020

Et dans l’annuaire Active Directory :

clip_image021

Le service NTFRS est arrêté et n’est plus considéré comme un service dépendant pour le démarrage de l’annuaire Active Directory.

Encore une fois, petite subtilités pour les RODC. Ils ne pourront supprimer les abonnements FRS eux même. Ils ont besoin d’aide avec la commande “DFSRMIG.EXE /DeleteRoNtfrsMember”

 

Rollback ?

Oui, c’est possible mais uniquement jusqu’à la phase “redirected”. Il suffit juste d’exécuter la commande “DFSRMIG.EXE /SetGlobalState’ avec le numéro de l’état correspondant.

 

Conclusion

C’est simple, transparent pour l’utilisateur final, sans risque majeur pour l’infrastructure. En plus, cela permettra d’éviter qu’un “commandant Sylvestre” auquel on aura accordé le privilège d’administrer un RODC de supprimer le contenu de son partage SYSVOL et par extension de répliquer son erreur sur l’ensemble de l’infrastructure. DFSR détectera la problématique et procèdera automatiquement à une restauration autoritaire du contenu du partage. La migration DFSR est donc impérative dès lors que notre infrastructure comprend des RODC.

BenoîtS – Simple by Design

DFS-N et DFS-R en ligne de commande (republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Tout est dans le titre. Comment mettre en place une racine DFS ainsi que sécuriser son contenu en le répliquant entre deux serveurs, le tout en ligne de commande ? Certes il est possible de le réaliser en passant par les assistants de la console “Server Manager”, mais pour en comprendre les arcanes, il faut mettre les mains dans le moteur.

Environnement

Histoire de faire simple, mon environnement est composé d’un unique contrôleur de domaine et de deux serveurs membres. L’objectif est de proposer un point d’accès unique à un contenu qui sera hébergé sur les deux serveurs membres.

Installation

DFS-N et DFS-R sont des sous-ensembles du rôle “File Services”. N’ayant besoin que d’eux, une simple commande “ServerManagercmd.Exe” me permettra de les installer sur chaque serveur membre :

clip_image001

Qui dit DFS-R, dit répertoire à répliquer. On va donc créer un répertoire sur chaque serveur membre :

clip_image002

On va monter un peu le niveau en positionnement des permissions sur notre répertoire avec ICACLS.EXE, successeur de CACLS.EXE sous Windows 2008 :

clip_image003

Reste plus qu’à partager ce répertoire avec des permissions sur le partage qui sont cohérentes avec celles positionnées sur le répertoire NTFS :

clip_image004

Jusqu’à maintenant, rien d’insurmontable. On passe à la vitesse supérieure ?

Création de la racine DFS

La création de toute racine DFS requiert la création d’un partage dit “racine”. Personnellement, je suis d’avis de toujours laisser ce répertoire vide. De ce fait, les permissions positionnées sont restrictives.

clip_image005

A noter le paramètre “Cache” configuré à “none”. Il ne faut jamais oublier que la mise en cache en mode “Hors ligne” est activée sur les partages. Cela peut devenir problématique pour des répertoires dont le contenu est partagé entre plusieurs utilisateurs.

Attaquons-nous à DFSUTIL.EXE, la boite à outil de DFS-N. Pour commencer, la création de la racine DFS de domaine (de type Windows Server 2008) :

clip_image006

On a constaté que la création de la racine s’est bien passée. Le serveur SRV1 héberge cette racine. Cependant que se passe-t-il si ce serveur est indisponible ? Pour assurer la disponibilité d’une racine DFS, on va juste lui ajouter un “target”, référençant lui aussi un répertoire partagé sur le serveur SRV2. :

clip_image007

Maintenant que notre racine DFS est plus fiable, on va s’attaquer à son contenu. Pour faire simple, notre racine DFS va héberger un lien nommé DATAS pour lequel on va fournir deux emplacements UNC (toujours une histoire de disponibilité) que DFS-R nous permettra de maintenir synchronisé. Donc on commence par créer un lien auquel on va ajouter un “target” en plus :

clip_image008

Note racine DFS n’est pas totalement opérationnelle, il reste un peu de configuration, en particulier comment la sélection des liens sera réalisée par le client (deux “targets” pour la racine et deux chemins UNC pour Datas). Je vais me reposer sur la topologie Active Directory et donc sur la notion de proximité de site. Encore faut-il le configurer dans la racine DFS:

clip_image009

Depuis Windows 2003, on peut activer la fonctionnalité (Access-Based Enumeration) sur un partage pour en cacher le contenu pour lequel l’utilisateur n’a pas la permission lire. Depuis Windows Server 2008, c’est aussi possible sur la racine DFS :

clip_image010

Dans ma configuration, j’ai deux “targets” pour la racine et deux chemins UNC pour le lien “DATAS”. Donc, en cas d’indisponibilité, on utilise l’autre lien. Mais comment fait-on pour indiquer aux clients de revenir sur le premier s’il est de nouveau opérationnel ? Avec la notion de FailBack, il suffit juste de l’activer :

clip_image011

A ce stade, la partie DFS-N est opérationnel. Si on utilise un client, on peut effectivement accéder au contenu du lien “DATAS” mais il est vide sur les deux serveurs.  Il est possible de configurer d’autres propriétés à ce niveau (Priority, Rank, …) mais commençons par quelque chose de simple. Jusqu’ici tout va bien. On passe la troisième ?

Configuration de DFS-R

C’est maintenant que cela devient sportif. DFSRADMIN.EXE est un peu moins facile à utiliser. La première étape, c’est de créer un groupe de réplication DFS-R pour lequel on va spécifier que toute la planification de réplication sera réalisée selon le fuseau horaire local du serveur (très utile quand on fait du DFS-R entre les continents !).

clip_image012

Par défaut, le planning de réplication sera complet, c’est à dire 24h/24h sans aucune restriction de bande passante.

Pour répliquer du contenu entre deux serveurs, encore faut-il que nos serveurs soient déclarés comme membre de notre groupe de réplication :

clip_image013

 

A ce stade, pas encore de réplication car DFS-R ne sait pas quel répertoire il faut répliquer. Il faut donc déclarer un “Replicated Folder” qui va correspondre à notre lien DATAS dans notre racine DFS-N de domaine :

clip_image014

Avant de poursuivre, j’ai besoin de créer une structure de répertoire pour DFS-R. L’objectif est d’isoler dans ce répertoire les “Staging Folder” et “Conflict and Deleted Folder” pour lesquels des exceptions doivent impérativement être mises en œuvre au niveau des des antivirus.

clip_image015

C’est maintenant l’heure de la ligne de commande à coucher dehors, à savoir la configuration des propriétés de chaque membre du groupe de réplication pour répliquer le “Replicated Folder”. Pour chaque membre, on spécifie :

  • L’emplacement local des données à répliquer
  • L’état du membre dans le groupe de réplication
  • L’emplacement du “Staging Folder” (répertoire utilisé pour gérer la réplication entre les membres d’un même groupe de réplication)
  • La taille du “Staging Folder”, une notion très importante
  • La taille du répertoire “Conflict and Replicated”
  • Le lien DFS lié à l’emplacement local
  • Si le serveur membre doit être utilisé comme source pour la première réplication ou non

clip_image016

Bien évidemment, c’est une opération à réaliser pour chaque membre. On remarquera que seulement l’un d’entre eux est désigné comme serveur primaire pour la réplication initiale.

A ce stade, la réplication n’a pas encore commencé. Pourquoi ? La raison est simple, on sait quels serveurs, quel répertoire mais pas selon quelle topologie de réplication. Dans notre cas, c’est assez simple puisqu’il y a deux serveurs. Il faut donc deux objets de connexions :

clip_image017

Dans Windows Server 2008, pour qu’une topologie soit considérée comme valide, il faut que chaque serveur soit lié à un autre et inversement. Dans Windows Server 2008 R2, il est possible de configurer une topologie avec des connexions unidirectionnelles et donc de la réplication unidirectionnelle.

A ce stade, la réplication devrait commencer. Cependant, si on regarde le contenu de notre répertoire “C:\DATAS” sur nos deux serveurs, il semble que cela ne fonctionne pas encore. La raison est simple, le service DFS-R actualise sa configuration toutes les soixante minutes. Avec une commande DFSDIAG.EXE, on va forcer chaque serveur à actualiser sa configuration :

clip_image018

Si on consulte le journal d’évènements “DFS Replication” de SRV2, on devrait trouver l’évènement suivant m’indiquant que la réplication initiale de mon “Replicated Folder” est terminée. C’est normal de trouver cet évènement sur SRV2 puis que SRV1 était déclaré comme serveur primaire pour la réplication initiale.

clip_image019

 

Superviser DFS-R

La supervision de DFS-R est un sujet complexe. Pour ceux qui veulent en savoir plus, je recommande les articles de l’équipe en charge de son développement et plus particulièrement celui-ci.

La première solution consiste à utiliser le module de reporting dans la console d’administration. C’est très complet mais c’est manuel. Une seconde possibilité serait d’utiliser le Management Pack de SCOM dédié à DFS-N et DFS-R. Il y a un peu plus de travail mais le résultat en vaut le coup.

Enfin il reste WMI. Une simple commande WMIC nous retourne l’état de la réplication pour le “Replicated Folder” au sein du groupe de réplication :

clip_image020

A la lecture de ces informations, mon groupe de réplication est opérationnel, la réplication initiale est bien terminée et il y a bien cohérence entre les deux serveurs. La taille de mon “Staging Folder” ne dépasse pas les seuils, donc tout va bien. Pour ceux qui veulent obtenir plus d’informations sur la supervision de DFS-R, c’est la classe WMI DFSRReplicatedFolderInfo.

Pour faire simple, la signification des valeurs d’état sont : 0 =Non initialisé, 1=Initialisé, 2= Réplication initiale en cours, 3=Mode récupération automatique, 4=Condition normale, 5=En erreur.

Voilà une mise en œuvre simple de DFS-N/DFS-R. Pour ceux que la mise en œuvre intéresse, je conseille vivement de lire le blog l’équipe en charge de son développement. DFS-R peut vite devenir un casse-tête à exploiter s’il n’est pas correctement mis en œuvre.

Benoîts – Simple By Design

Le RODC en image (republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Read Only Domain Controller, une nouveauté de Windows Server 2008 qui permet de mettre en place un contrôleur de domaine qui présente la particularité de ne pouvoir répliquer de manière unidirectionnelle depuis le site central. Ce mode de fonctionnement permet de réduire les problèmes de réplication dans les architectures complexes et de limiter les informations répliquées vers ce contrôleur de domaine (très utile ce cas de vol!).

Le RODC pour qui?

Le premier scénario de mise en œuvre du RODC, c’est le Branch Office. Pour ces sites distants, on hésitait toujours à positionner un contrôleur de domaine, ne sachant pas si la sécurité serait assurée (qui a dit que le contrôleur de domaine est dans un placard à balais?). Le scénario de déploiement complet serait même RODC + Bitlocker sur un socle Windows Server 2008 Core.

Les limitations

Globalement l’approche est bonne, il faut juste tenir compte d’un certain nombre d’incompatibilités notoires documentées dans la KB944043 ou bien sur le site Technet au sujet des problématiques identifiées de déploiement.

Pré-requis?
  • Une extension de schéma Windows Server 2008 : ForestPrep
  • Une préparation de domaine Windows Server 2008 : DomainPrep
  • Une préparation spécifique RODC : RodcPpep
  • Au moins un contrôleur de domaine Windows Server 2008 avec lequel il pourra dialoguer (perso, je recommande deux DC pour le failover)
  • Pour la localisation du RDOC attention à ne pas placer notre RODC dans un site Active Directory contenant déjà un contrôleur de domaine “Writable” du même domaine, tel que documenté dans la rubrique “Site with Multiple Domain Controllers
  • Ne pas demander à Exchange 2007 d’utiliser ce Global Catalog, il va de lui même l’esquiver!
La mise en œuvre sur Core?

C’est le scénario le plus intéressant. Si en plus on y ajoute la délégation d’installation et d’administration, c’est presque Byzance.

Configuration réseau & raccord au domaine.

Core, c’est pas parlant du tout, on va donc y aller “step by step”. La configuration du nom du serveur qui va devenir RODC à l’aide de la ligne de commande suivante :

0

Pour la configuration réseau, le couteau suisse NETSH.EXE est fait pour cela. Il faut juste savoir avec quelle interface on va configurer :

1

Maintenant que l’on dispose de l’identifiant de l’interface, on peu s’attaquer à la ligne de commande à rallonge :

2

La configuration du client DNS histoire de pouvoir joindre le domaine :

3

Oui, je sais IPV6 est toujours présent! Mais passons au plat de résistance, à savoir la mise en œuvre du RODC. DCPROMO.EXE est déjà présent, pas la peine de tenter d’installer le rôle, c’est pas recommandé! Par contre, sans interface graphique, l’installation s’effectue soit en ligne de commande, soit à l’aide d’un fichier de réponse automatisé. Etant donné que l’on désire suivre les bonnes pratiques, commençons par pré-créer notre futur serveur RDOC dans l’annuaire Active Directory :

4

L’assistant existe, alors utilisons le. Objectif, pré-créer le compte dans l’annuaire Active Directory. De cette manière, on s’assure du respect de la charte de nommage de nos contrôleurs de domaine :

5

Les rappels habituels, …

6

Pour faire simple, je suis connecté en tant que “Admins du domaine”. je sais c’est “Mal”.

7

Spécifions le nom de notre futur contrôleur de domaine (il est impératif que notre futur contrôleur de domaine porte ce nom) :

8

Autant placer notre futur contrôleur de domaine dans le site Active Directory Approprié (pourvu qu’un ait bien créé le site et le sous-réseau associé au préalable, …) :

9

Notre contrôleur de domaine sera tout à fait basique sinon qu’il sera RODC. La bonne pratique est de conserver ces serveurs DNS et Global Catalog :

10

Le processus nous autorise de déléguer l’installation et l’exploitation de notre RODC, autant ne pas s’en priver :

11

Au final, il nous autorise à exporter la configuration dans un fichier de commande. C’est très pratique car l’assistant DCPromo est assez pointilleux. Mais bon, on est en mode “Core”, on va tout faire le ligne de commande, donc passons notre chemin  (on est des guerriers de la ligne de commande ou pas?) :

12

C’est fini pour la partie graphique (overdose):

13

On peut constater la présence du compte ordinateur du futur RODC, il n’est pas encore utilisable :

14

Revenons à notre interface de l’âge de pierre et tentons de convaincre DCPROMO d’accepter tous les paramètres :

15

Qui a dit qu’il n’y a pas d’interface graphique sous “Core”. Allez donc voir un peu ce qu’il est possible de faire (NOTEPAD.EXE, REGEDT32.EXE, TIMEDATE.CPL, …). Etant donné que je n’ai pas donné la réponse dans la ligne de commande kilométrique, il faut bien le saisir ce mot de passe :

16

Et le miracle s’accomplit progressivement :

17

Le dernier paramètre de ma ligne de commande permet de se rendre compte de l’impact de IPV6 non configuré sur un contrôleur de domaine :

18

Cela permet aussi de reconfigurer le client DNS préféré  de l’interface réseau pour respecter les règles de configuration DNS d’un contrôleur de domaine :

19

Même punition mais pour configurer un client DNS additionnel pour le failover :

20

Reste plus qu’à redémarrer. Coté console d’administration, on constate que le compte ordinateur est bien activé et que c’est bien un contrôleur de domaine “ReadOnly” :

21

Des subtilités à voir?, plein,  on peut commencer par la gestion des mots de passe stockés sur le RODC et ceux automatiquement refusés (très instructifs) :

22

Ou alors l’aspect délégation d’administration de ce contrôleur de domaine :

23

Ou encore le fait qu’un objet de réplication a bien été créé pour mettre en place la réplication :

24

Mais que cette réplication n’est qu’unidirectionnelle :

25

Voila pour le RODC, il reste encore une subtilité sur le filtrage des attributs répliqués, histoire d’affiner la sécurité de notre contrôleur de domaine, mais l’essentiel est fait.

BenoîtS – Simple by Design

Patching out of band, cas concrêt

C’est quand on traite des sujets qui n’arrivent jamais que ça tombe. J’avais publié voilà quelques jours une série de billets sur le Patch Management d’une infrastructure de type cloud privé. Certaines personnes m’ont demandé pourquoi devait-on prévoir un processus pour les patchs out of band, … La réponse est tombée ces jours-ci : Microsoft Security Advisory 3108638.

L’alerte est d’importance car ça touche l’Hyperviseur. En lisant plus précisément le bulletin de sécurité, on découvre que la « faille » ne se trouve pas dans Hyper-V mais dans le processeur lui-même. Conséquence, c’est toutes les versions d’Hyper-V qui sont affectées :

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2
  • Windows 8.1
  • Windows 10

C’est disponible dans Windows Update, donc pour action immédiate. Vu que c’est une problématique indépendante du logiciel, tous les Hyperviseurs sont donc affectés. Une recherche rapide sur Google Bing vous donnera les liens pour les autres hyperviseurs du marché :

Remarque : Il ne faut pas voir de mauvais esprit anti-VMWARE de ma part mais Google / bing n’a pas été mon ami pour trouver l’information chez eux sans accès à la Knowledge Base.

Alors convaincu qu’il est important d’avoir un process de patch management out of band dans votre infrastructure Cloud privé? Maintenant, vous avez deux choix :

  • Choix n°1 : Tester le déploiement en urgence à l’arrache sans concertation avec vos locataires avec un résultat attendu.

clip_image001

clip_image002

Alors, prêt à patcher?

­

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

Patch Management – Réflexions – Bonus : Les urgences

Jusqu’à maintenant, on a parlé de patching organisé. Cependant, on aura certainement un jour à traiter une urgence, avec un RSI qui nous impose le patching de notre infrastructure dans des délais beaucoup plus court que les cycles de maintenance que nous pouvons proposer. Que ce soit dans le contexte d’un cloud privé ou hybride, il faudra impliquer nos locataires. Il y a de grandes chances que le problématique rencontrée par l’hébergeur impacte aussi le locataire (cas Heartbleed). Il devra aussi prendre ses responsabilités. Si son application a bien été pensée pour la scalabilité et la résilience, alors cela devrait bien se passer. Netflix en a fait l’expérience, c’est un enseignement à méditer : Lessons Netflix Learned from the AWS Outage.

Le problème, c’est comment y faire face quand ça nous tombe dessus. Réagir implique d’organiser un cycle de maintenance dans l’urgence, donc communiquer auprès de nos locataires pour les informer des impacts sur leurs workloads. Le risque avec les cycles de maintenance exceptionnels, c’est que c’est une organisation lourde, organisée dans l’urgence, donc un fort risque d’avoir des problèmes. A côté de cela, on a déjà des cycles de maintenance en place. Donc, de mon point de vue les stratégies sont les suivantes :

  • Tenir jusqu’au prochain cycle de maintenance. Ce qui implique que les cycles de maintenances sont rapprochés et qu’on peut tenir jusqu’au prochain, genre chaque week-end. Ça peut permettre de patcher une partie de l’infrastructure en cumulant patching Microsoft et urgence au sein de la même plage de maintenance. Avec nos runbooks qui se ressemblent beaucoup, c’est juste une histoire d’intégration.
  • Improviser. Généralement, ça ressemble à du freestyle sans filet, on connait tous les résultats.
  • Appeler la terre entière pour demander à redémarrer la plateforme, ce qui va détruire nos SLA à 0 et ruiner la confiance de nos locataires

Ma préférence va à la première stratégie. Plus votre infrastructure est importante plus il devient difficile d’organiser des actions dans l’urgence. Les dépendances deviennent de plus en plus nombreuses. En ayant des cycles de maintenance courts, il est plus simple d’inscrire des actions urgentes dans ces cycles de maintenance plutôt que d’introduire des cycles de maintenance exceptionnels qu’il est complexe d’organiser sous contrainte de temps. C’est une solution envisageable uniquement si on est capable de mettre en place des mesures de mitigation pour parer aux risques encourus jusqu’à ce que l’infrastructure soit totalement patchée.

Etre en situation d’urgence sans préparation, c’est le mur assuré. Le problème, c’est qu’il faut bien apprendre. Pour cette raison, l’organisation de cycles de maintenance dans l’urgence ne doit pas être rejetée. Cela peut effectivement générer des problèmes mais on a beaucoup à apprendre de ces incidents si on en sort avec :

  • Un REX, ce qu’on en a appris, ce qu’il faut corriger
  • Un plan d’action pour prendre en compte les corrections
  • Des processus éprouvés et partagés

Après, il faut valider que nos corrections techniques / processus vont dans le bon sens. Pour cela rien de vaut de se remettre en situation de risque. Je ne dis pas qu’il faut planter tout son Cloud privé mais créer une situation de risque contrôlée

clip_image002

C’est là qu’un environnement de Prototypage un tant soit peu représentatif prend tout son intérêt!. Pour nous, c’est encore un sujet en cours de réflexion pour lequel on espère poser les bases prochainement.

L’idée générale serait d’organiser des campagnes de « Stress test » pour tester aussi bien l’infrastructure, que les processus et les équipes. Ce type de campagne devrait être organisé au moins deux fois par an. Plus, c’est qu’on a eu beaucoup trop d’urgences dans l’année écoulée. C’est possible mais mettre en place un environnement contrôlé prend du temps. Moins, c’est prendre le risque d’oublier ce qu’on veut qualifier. Quelques conseils pour organiser ces Stress tests :

  • Disposer d’un environnement de prototypage représentatif est l’idéal mais ce n’est pas toujours possible. Il faudra certainement isoler une partie de l’environnement de production
  • Procéder par itérations. On ne peut pas tout tester en un seul cycle annuel
  • Se fixer des objectifs réalistes

Pour conclure, la conception et la mise en place du Patch Management d’un cloud privé prend du temps, beaucoup de temps. Dans notre approche, nous avons tenu à observer quelques règles :

  1. Si le design ressemble à l’étoile de la mort, c’est pas bon
  2. Plus on complexifie les processus, plus on va jongler avec des briques
  3. Une brique qui tombe ça fait mal
  4. Toujours garder en mémoire les trois premiers points

Voilà pour le Patch Management d’une infrastructure cloud privé basée sur les produits System Center. Pour les locataires, c’est une autre histoire qui peut se résumer ainsi : Pets or Cattle. Nos locataires doivent t-ils être au petits soin pour leurs machines virtuelles ou les traiter comme du bétail? Ce sera un autre sujet de discussion.

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

Patch Management – Réflexions – n°5 : Les cycles de maintenance

C’est bien d’automatiser au maximum, encore faut-il planifier ces opérations. Doit-on planifier toutes ces opérations selon le même cycle de maintenance « long » (option big-bang au risque de se transformer en big-badaboum) ou des cycles « courts » (option « blind-test » pour la découverte des bugs / comportements non prévu)? La réponse est bien plus compliquée. Déjà, tous les types de Patching ne s’inscrivent pas dans le même cycle de maintenance. Raisonnons donc en fonction des différents domaines :

  • Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V : Pour maintenir la stabilité de la plateforme et le support des éditeurs, on est obligé de suivre un rythme soutenu. Certes, on n’est pas obligé de suivre au jour le jour et de s’imposer des cycles courts mais on doit quand même suivre. On aura besoin d’un à deux cycles de maintenance par an. A mon sens, difficile de faire plus car il faudra du temps pour valider que les changements opérés produisent bien les effets escomptés et qu’on n’observe pas de régression pouvant affecter nos SLA et par extension les SLA de nos locataires.
  • Patch Management Microsoft : On est tous d’accord pour suivre le rythme mensuel imposé par Microsoft. C’est sportif mais pas impossible. En fonction de la taille de l’infrastructure, on devra découper en plusieurs phases. Par exemple, patcher un certain nombre de châssis par semaine sur un cycle d’un mois. A mon sens, c’est une approche à privilégier car avec Windows 10 et Windows Server 2016, la notion de « Ring » va changer les choses. Devra t’on passer sur le modèle Long-Term Branch? C’est une bonne question, pas encore assez de recul pour juger. Par contre le choix du mode d’installation Nano devrait nous faciliter grandement la tâche pour réduire drastiquement le nombre de correctifs à installer et le nombre de redémarrages nécessaires.
  • Patch Management « Out of band » : Là, c’est la criticité qui impose le cycle. La première option serait de travailler dans le mode urgence. Pas évident à organiser et le résultat risque d’être approximatif. On peut aussi prévoir de pré-réserver des créneaux pour réaliser ce type d’opération et les utiliser ou non. C’est l’option que je préfère. On évite l’organisation dans l’urgence et on inscrit cela dans un cycle régulier, plus facile à maîtriser. Après, on peut prévoir d’intégrer ce type de patching dans le cycle du Patch Management Microsoft. C’est envisageable si on a bien prévu un cycle de maintenance court. On profite du créneau horaire du premier pour intégrer le second.
  • Patch Management de la Fabric : Avec les solutions Cloud Privé / Hybride de Microsoft, c’est facile, les équipes System Center fournissent des Update Rollup tous les trimestres. Autant on n’a pas de problème ou presque à appliquer les correctifs Microsoft & Out of Band sur notre Fabric, autant les updates UR sont trop spécifiques et nécessitent trop de tests. Pour cette raison, choix a été fait de ne pas suivre le rythme de publication de Microsoft. Il a été décidé de sauter un UR sur deux sauf si l’UR en question nous corrige des problèmes nous impactant ou apportant des fonctionnalités requises par nos locataires. En plus chaque UR apporte son lot de nouvelles fonctionnalités à mettre en place / qualifier, …

clip_image001[4]

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