Archives de catégorie : Windows Server 2008 R2

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

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

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

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

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

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

    clip_image001

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

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

 

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

 

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

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

Mais pourquoi mon HRA refuse t’il de s’installer?

Il y a des jours quand ça veux pas, ça veux pas. Voila le me message d’erreur que j’ai obtenu lors de l’installation d’un Health Registration Authority sur une plateforme Windows Server 2008 R2 française. Premier reflexe, la localisation. Mes récentes expériences avec Orchestrator m’ont démontré la subtilité qui existe entre des produits globalisés versus localisés. Dans mon cas, l’interface graphique ne nous donne pas beaucoup d’informations sur la nature de l’erreur. Par contre, il m’indique que l’installation de sous-rôles ou rôles complémentaires a elle échouée et qu’il est nécessaire de redémarrer.

clip_image001

Après avoir exclue la cause française (problématique reproduite sur plateforme full US), j’attaque une approche dichotomique (non, je ne fais pas de développement, juste de la recherche d’erreur de la manière rationnelle). Pour faire simple, installer manuellement chaque rôle, sous-rôle et fonctionnalité jusqu’à tomber sur celle qui pose problème. A première vue, c’est bien le HRA. Cette fois l’erreur est plus précise (détail recherches sur le code erreur). On avance, on a un code erreur, c’est déjà mieux.

clip_image002

Tous les autres composants ou sous-composants se sont bien installés. Il faut aller plus avant dans les logs du composant ServerManager. Allons donc faire un tour dans le fichier « C:\Windows\Logs\ServerManager.Log ». Le code erreur affiché dans la console ne nous aide pas. Une rapide consultation de votre moteur de recherche ne nous fournira pas de piste spécifique. Remontons donc la liste dans le fichier de log.

clip_image004

On retrouve bien l’information. Elle vient même du composant Component Based Servicing (CBS) qui est plus connu sous le nom de Trusted Installer. Allons donc faire un tour dans le fichier journal de ce composant : « C:\Windows\Logs\CBS\CBS.Log ». En remontant le fichier de journalisation en partant de la fin, on arrive bien à identifier que le problème vient bien du package « Microsoft-Windows-HealthCertificateServer-RunTime ».C’est bien le HRA, plus précisément un package particulier. Est-il corrompu? Nan, c’est beaucoup plus simple. Ce n’est pas non plus un problème de quota comme l’indique le fichier de journalisation.

clip_image006

La réponse est quelques lignes au-dessus. De belles commandes « APPCMD.EXE » pour assurer la création des répertoires virtuels « DomainHRA » et « NonDomainHRA ».

clip_image008

Ce sont ces commandes qui ne passent pas. A tout hasard, j’ouvre une invite de commande MS-DOS pour tenter de les exécuter manuellement pour finalement me rendre compte de ce qui manque. Et si mon site web par défaut n’existait tout simplement pas? Bingo, dans mon cas, ce n’est pas qu’il n’existe pas mais qu’il a été renommé (des normes applicatives, toujours des normes applicatives, …). Ben celle-là elle ne passe pas. Le processus d’installe ignore le fait qu’on puisse renommer le « Default Web Site ». Une fois le site renommé, le HRA s’installe tout seul.

clip_image009

Un petit tour rapide dans la console « Gestionnaire des services Internet (IIS) » pour vérifier la présence de mon répertoire virtuel. C’était bien cela.

clip_image011

Conclusion : Quand on vous dit que l’installation du serveur est « fresh out of the box », premier réflexe ne rien en croire et vérifier plutôt deux fois qu’une. C’est comme les projets qui se déroulent sans problème, c’est de la science-fiction.

 

Note : le processus d’installation du HRA n’est pas un cas isolé. Il existe d’autres produits Microsoft pour lesquels la présence du site web par défaut est nécessaire pour que le processus d’installation se déroule normalement.

 

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

Retour expérience migration DFS-R en inter-forêt

Les migration Active Directory se suivent et se ressemblent à quelques exceptions près. Chaque nouvelle version de système d’exploitation Microsoft vient apporter son lot de nouvelles fonctionnalités que les clients pourront mettre en œuvre à loisir. C’est lors d’une ces ces migrations que j’ai eu l’occasion de travailler sur la migration de namespaces DFS-N et groupes de réplication DFS-R, le tout hébergé sur plateforme Windows Server 2008 R2.

 

Quelques points à connaitre

Une racine DFS-N de domaine est basées sur le nom du domaine. Lors de la migration, la racine DFS recréée portera donc un nouveau nom. A priori, cela ne semble pas poser de problème, sauf quand il existe des liaisons. C’est par exemple le cas entre des classeurs Excel. C’est le chemin UNC qui est référencé, pas le lecteur réseau. Il existe bien des outils sur le marché pour traiter ces problème, mais cela implique que l’utilisateur n’ait pas verrouillé son fichier avec un mot de passe.

La configuration d’une racine de domaine DFS-N est stockée dans partition de domaine de l’Active Directory. Lorsque le serveur migrera vers le domaine “cible”, les informations relatives à la racine ne migreront pas, voir : About the DFS Namespaces service and its configuration data on a computer that is running Windows Server 2003 or Windows Server 2008 pour savoir comment effacer les informations proprement.

La configuration d’un groupe de réplication DFS-R est nécessairement stocké dans l’annuaire Active Directory. Ici encore, la configuration ne suivra pas lors de la migration vers le domaine ”cible”. Si la configuration ne suit pas, c’est qu’il faudra reconstruire le groupe de réplication DFS-R. On peut reconstruire à partir de zéro avec un processus de réplication initial standard mais on peut aussi utiliser le Pre-seeding pour accélérer le processus. La procédure est un peu particulière mais bien documentée : http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx. Veuillez à respecter scrupuleusement la procédure, sinon, on perd l’avantage du pre-seeding.

Il n’est pas possible de désinstaller les sous-rôles DFS-N et DFS-R si le rôle ADDS est aussi installé. Conclusion, si le serveur est aussi contrôleur de domaine, une rétrogradation en simple serveur membre et une désinstallation du rôle sont nécessaires avant de commencer.

Lorsque deux membres d’un groupe de réplication DFS-R sont connectés à un réseau local et que les fichiers à répliquer sont de petites tailles, désactiver le protocole RDC, c’est bien plus efficace.

 

Avant de commencer

Cela peut paraitre bête à dire mais si on ne supervise pas DFS-R, on ne sait pas si tous les serveurs membres du groupe de réplication DFS-R sont synchronisés. Pour cela quelques outils :

  • “DFSRDIAG.EXE Replication state” : Permet de déterminer si des réplications sont en cours
  • “DFSRDIAG.EXE BACKLOG” : Pour suivre précisément ce qui est en cours et en attente de réplication entre deux membres d’un même groupe de réplication DFS-R
  • Le Health Report proposés par la console DFS Management

 

Dès lors qu’on est assuré de la bonne synchronisation de tous les membres d’un groupe de réplication DFS-R on peut s’attaquer à la migration. Chaque serveur devra être migré individuellement. L’objectif est de désactiver progressivement les target DFS-N correspondants pour que les clients ne puissent plus utiliser qu’un seul target DFS-N, c’est ce serveur qui sera migré en dernier et utilisé comme maitre pour la réplication initiale ainsi que le pre-seeding.

 

Lors d’une migration inter-forêt, il est nécessaire de remplacer les références aux objets de sécurité du domaine “source” par celles équivalentes dans le domaine “cible”. Cette opération nommée Reacling va avoir un impact sur le processus de réplication DFS-R dans la mesure ou les ACL de tous les fichiers vont être modifiées. Ces modifications devant être répliquées vers les autres membres du groupe de réplication DFS-R, elles peuvent saturer le staging folder. Il conviendra donc de prévoir une taille suffisante pour celui-ci. Si possible se reposer sur le SID-History, à moins d’être contraint de le faire, on économise ainsi une phase de reacling. L’erreur serait de réaliser une opération de reacling alors que le groupe de réplication DFS-R vient de finir sa synchronisation initiale.

 

Réalisation de l’opération
  • Supprimer les objets connexions DFS-R pour les serveurs à migrer
  • Supprimer les “membership” DFS-R pour les serveurs à migrer
  • Supprimer les “replicated Folder” avant de supprimer les “Replication Group”
  • Si le serveur est “Root Namespace server” pour une racine DFS-N, penser à le supprimer avant la migration, sinon, il ne pourra plus le redevenir une fois migré
  • Désinstaller DFS-R et DFS-N des serveurs à migrer
  • Supprimer les données contenues dans le “staging folder” des groupes de réplication DFS-R, elles ne serviront plus.
  • Migrer les serveurs vers le nouveau domaine
  • Réinstaller les sous-rôles DFS-N et DFS-R
  • S’assurer que les correctifs relatifs à DFS-N et DFS-R sont bien installés sur les serveurs migrés : KB968429
  • Si on pense effectuer le pre-seeding des futurs membres DFS-R avec ROBOCOPY.EXE, alors s’assurer qu’on dispose bien de la dernière version : KB979808
  • Recréer la racine DFS-N
  • N’activer qu’un seul “target DFS” le temps que le groupe de réplication DFS-R ne réalise sa synchronisation initiale
  • Recréer le groupe de réplication DFS-R
  • Bien penser à configurer des tailles de “staging folder” suffisantes, sinon, la réplication initiale ne pourra être réaliser
  • Sur les serveurs membres du groupe de réplication DFS-R qui n’ont pas été désignés comme primaire, on droit trouver trace de l’évènement ci-dessous indiquant le début de la synchronisation initiale :

image

Puis, si le processus de preseeding s’est bien déroulé, on doit trouver trace de l’évènement ci-dessous indiquant la fin de la phase de synchronisation initiale.

image

  • Réactiver les “Target DFS” pointant sur les membres de groupes de réplication DFS-R qui ont été identifiés comme synchronisés.

 

Bonne fêtes.

 

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

MS12-083 and DirectAccess

This month, Microsoft released  MS12-083 security bulletin as a part of it’s monthly release. This particular bulletin address a vulnerability in IP-HTTPS protocol used in DirectAccess deployment. This vulnerability allows a revoked computer certificate to be accepted for authentication. This means that the infrastructure tunnel in DirectAccess could be established even with a revoked certificate.

 

That’s a good reason to always the following rule for stolen or lost Direct Access clients computers : Always disable the computer account in Active Directory.

 

Microsoft released a hotfix applicable to Windows 2008 R2 and Windows Server 2012. Install it.

 

More information available on the Security Research & Defense blog.

 

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

Security Compliance Manager 3.0 Beta

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

 

The new version of the tool provide security baselines for :

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

SCM3

 

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

W8SECGUIDE

 

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

 

Simple and Secure by Design but Business compliant

DirectAccess challenge series

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

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

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

Visio

 

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

image

 

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

 

Foundations

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

DirectAccess Challenge Series suite

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

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

 

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

 

Assumptions

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

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

 

Challenge

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

 

Client-side configuration

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

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

ISOLATIONCLIENT0

 

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

ISOLATIONCLIENT1

 

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

ISOLATIONCLIENT2

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

ISOLATIONCLIENT3

 

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

ISOLATIONCLIENT4

 

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

ISOLATIONCLIENT5

 

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

ISOLATIONCLIENT6

 

Server-side configuration

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

ISOLATIONSRV0

 

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

ISOLATIONSRV1

 

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

ISOLATIONSRV2

 

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

ISOLATIONSRV3

 

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

ISOLATIONSRV4

 

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

ISOLATIONSRV5

 

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

ISOLATIONSRV6

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

ISOLATIONSRV7

 

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

RDS4

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

Secure one protocol

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

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

RDS0

 

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

RDS1

 

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

RDS2

 

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

RDS3

 

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

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

 

Limitations

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

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

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

 

BenoitS – Simple and Secure but business compliant