Archives de catégorie : Windows 2008

Prise de tête avec la Terminal Server Gateway (re-publication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2008. 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. A l’époque, il y avait encore de l’ISA/TMG au programme Clignement d'œil.

Voilà une fonctionnalité de Windows Server 2008 qui mérite qu’on creuse un peu plus le sujet. Avec Windows Server 2003, on pouvait déjà encapsuler le protocole RPC de Microsoft Outlook dans un flux HTTP. Avec Windows Server 2008, Microsoft a étendu l’utilisation de l’encapsulation au protocole RDP.

Cette approche permet de sécuriser l’utilisation du protocole RDP sur un réseau LAN ou depuis le réseau extérieur. Tous les flux HTTPS arrivent sur un serveur dit « passerelle » qui se charge de de décapsuler le flux HTTPS pour ressortir sous la forme du protocole RDP. Le principal avantage de cette approche est de pouvoir faire passer tous les flux RDP sous un même port (443) pour de multiples destinations. On évite donc les multiples ouvertures de port sur le pare-feu extérieur.

De l’extérieur, l’accès à la Terminal Server Gateway est contrôlé par les « Connection Authorization Polices (CAP) ». Après, l’accès aux serveurs Terminal Serveurs ou aux clients Remote Desktop s’effectue selon les conditions dictées par les « Ressource Authorization Policies (RAP) ».

En terme d’implémentation, on distingue trois scénarios :

  • Le Terminal Server Gateway sur le réseau interne
  • Le Terminal Server Gateway sur le réseau périmétrique
  • Le Terminal Server Gateway publié par un ISA Server

 

Le Terminal Server Gateway sur le réseau interne

clip_image001

Ce scénario peut être difficile à implémenter dans la mesure où cela nécessitera de mettre en œuvre un pare-feu sur le réseau interne qui non seulement laisse passer le flux 3389 sur le port TCP (tout à fait normal )mais aussi les flux liés à l’ annuaire Active Directory car la CAP impose de sélectionner au minimum un groupe d’ utilisateurs, idéalement, un groupe de domaine si on ne veut pas fournir deux authentifications distinctes (Compte local sur la TS Gateway puis compte Active Directory). Techniquement, c’est possible à condition d’utiliser ISA Server 2006 avec le filtrage de protocole RCP sur les UUID. C’est un peu long à mettre en œuvre mais c’est réalisable. Il est possible d’envisager une version allégée de ce scénario en supprimant le pare-feu sur le réseau interne même si ce n’est pas le meilleur choix.

Le Terminal Server Gateway sur le réseau périmétrique

clip_image002

 

Le second scénario pose le même problème. Là il est obligatoire d’utiliser ISA Server 2006 pour le mettre en œuvre. Reste tout de même à convaincre le client d’accepter ISA Server comme pare-feu même de bas niveau (au plus proche du LAN). Bon nombre de personnes y sont encore réticentes pour des raisons historiques qui n’ont plus vraiment lieu d’être aujourd’***…

Le Terminal Server Gateway publié par un ISA Server / TMG

clip_image003

 

Pour le troisième, c’est un scénario « full ISA Server/TMG », ce qui en matière de sécurité n’est pas une bonne pratique (ISA en DMZ et ISA comme pare-feu de bas niveau). On préfèrera différencier les fournisseurs à ce niveau.

Globalement, c’est le premier scénario qui sera le plus utilisé.

 

Le Nœud du problème

Maintenant rentrons dans le nœud du problème : les certificats. Ayant eu la chance de participer au Tech-Ed 2008 à Barcelone (Merci patron !). J’ai assisté à la conférence « Windows Server 2008 Terminal Services Deep Dive – Gateway Security and certificates » d’Alex Balcanquall, Senior Product Manager chez Microsoft de son état. Au terme de sa présentation, j’ai posé une question toute simple : La TS Gateway n’accepte qu’un seul certificat, donc qu’un seul nom (selon l’interface). Comment peut-on faire pour utiliser un nom pour la TS Gateway interne qui est différent de celui utilisé en externe ? D’un point de vue purement « paranoïaque » de la sécurité, cela se tiens. Techniquement, le plus simple consiste à utiliser ISA Server pour publier sous un autre nom. Mais c’est contourner le problème.

A cette question, il m’a été répondu que c’était une très bonne question mais sans avoir pour autant de réponse (ni le sac à dos promis pour les meilleures questions posées, …).

La réponse

La réponse, elle est normande, cela dépend. Selon les informations de Microsoft sur les caractéristiques du certificat à utiliser (http://technet.microsoft.com/en-us/library/cc731264.aspx) le certificat doit présenter les caractéristiques suivantes :

  • The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
  • The certificate is a computer certificate.
  • The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
  • The certificate has a corresponding private key.
  • The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
  • A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
  • The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer.
L’attribut SAN

C’est le premier point le plus important. Techniquement oui c’est possible, tout dépend de l’autorité de certification. Dès lors qu’on utilise une autorité de certification « Entreprise de Microsoft », c’est là que cela devient compliqué :

  • Le certificat doit être généré à l’aide du template « Computer », sinon la TS Gateway refusera le certificat
  • Les modèles de certificats de l’autorité de certification de Microsoft ne sont personnalisables que sur une autorité de certification de type « Entreprise »
  • Le modèle de certificat « Computer » utilise le FQDN de l’ordinateur pour renseigner le champ « Subject » du certificat. Cela signifie que si on désire utiliser un autre noms, l’autorité de certification ignorera le paramètre dans la demande.

 

Par défaut, l’ extension SAN, n’ est pas activée, qu’ à cela ne tienne on va l’ activer (http://support.microsoft.com/kb/931351/en-us):

clip_image004

 

Après un redémarrage, notre autorité de certification va accepter de traiter l’attribut Subject Alternative Name. Ou presque, …

 

Le modèle de certificat « Computers »

C’est la seconde étape. Oui l’autorité de certification accepte de traiter les demandes de certificats pour l’attribut Subject Alternative Name » mais elle continue obstinément à les refuser dès lors qu’on lui demande un certificat pour un ordinateur. La raison est toute simple, elle tient dans l’illustration ci-dessous :

clip_image005

 

Le modèle de certificat « Computer » prévoit de récupérer le « Subject Name » directement dans l’annuaire Active Directory, ignorant donc l’attribut SAN. La seule solution, c’est de dupliquer ce modèle de certificat. Le nouveau modèle de certificat « TS Gateway Certificate » integer:

  • La reconfiguration de l’attribut « Subject Name »

clip_image006

  • Le modèle soit « Superseeded » le modèle de certificat « Computers »

clip_image007

 

C’est très important, car la TS Gateway vérifie que le certificat qu’on lui soumet a été généré selon le modèle « Computers » ou dérivé de celui-ci.  Le modèle de certificat est alors prêt à être publié pour être utilisable immédiatement.

 

La demande de certificat en ligne (Cas Autorité de certification intégré à l’ AD)

Commençons par le cas le plus simple, une demande de certificat en ligne pour notre futur TS Gateway :

clip_image008

 

Jusque-là, je n’ai perdu personne.

clip_image009

 

Le modèle de certificat « TS Gateway certificate » est bien proposé mais pour être utilisable il est nécessaire de compléter un certain nombre d’informations en cliquant sur « More information is required to enroll for this Certificates ».

clip_image010

 

C’est là que se situe la subtilité. Il faut dans un premier temps spécifier un Subjet Name pour le compte ordinateur de notre TS Gateway mais aussi le ou les Subject Alternatives Names à utiliser. On remarquera que j’ai référencé un nom extérieur, un nom DMZ et un troisième correspondant au nom DNS sous lequel la TS Gateway sera accessible depuis le réseau LAN de l’entreprise.

Note : le dernier n’est utile que si l’on désire rendre accessible sa TS Gateway sur le réseau interne.

clip_image011

 

Pour finir, il est vivement conseillé d’utiliser l’attribut « Friendly Name » pour faciliter la suite de la demande de certificat.

clip_image012

 

La demande de certificat est maintenant complète, elle peut être soumise à l’autorité de certification intégrée à l’annuaire Active Directory et être approuvée

clip_image013

 

La demande de certificat offline (Cas autorité de certification tierce ou autonome)

C’est le même principe. Windows Server 2008 nous aide à formater la requête pour pouvoir la soumettre à une autorité de certification tierce

clip_image014

 

Je n’ai toujours jamais perdu quelqu’un à l’écran d’accueil !

clip_image015

 

On sélectionne note modèle de certificat « TS Gateway Certificate »

clip_image016

 

L’interface est quelque peu différente d’une demande en ligne mais le principe reste identique, à savoir qu’il faut compléter la demande avant de pouvoir la soumettre.

clip_image017

 

Toujours les mêmes informations, à savoir un Subject Nme représenté par le « Full DN » du compte ordinateur puis les « Subject Alternatives names » ajoutés sous formes de noms DNS.

clip_image018

 

La demande ainsi préparée peut-être soumise à une autorité de certification.

 

Le certificat dans la console « Terminal Server Gateway

Dès lors que le certificat a été installé sur le serveur de la TS Gateway et associé à celle-ci, l’interface d’administration indique uniquement le « Subject name » dans le champ « Issued To ».

clip_image019

 

Si on vérifie avec des clients, on peut valider que la TS Gateway répond bien à tous les noms positionnés SAN positionnés dans la demande de certificat.

Conclusion

En conclusion, oui, c’est possible, sauf que ce n’est pas le scénario le mieux documenté. L’interface d’administration n’a pas été prévu pour afficher l’éventuel attribut SAN. Une TS Gateway peut donc répondre à plusieurs noms (interne, externe, nom pour chaque partenaire, …). C’est juste un petit peu plus complexe à mettre en œuvre. Le premier avantage de ce scénario est de pouvoir utiliser la même TS Gateway pour plusieurs usages et non en dédier une par usage. Le second avantage et non des moindre est de pouvoir affiner les stratégies de filtrage CAP par défaut pour différencier les accès internes des accès Externes (aller faire un tour dans la console du NPS installé sur la TS Gateway dans le noeud « Network Policies »).

Note à certains lecteurs : Je mérite encore plus mon sac à dos pour avoir trouvé moi-même la solution au problème posé!

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

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

SID History bis repetita

Voila presque deux ans j’avais publié un article sur les problèmes de SID-HISTORY. Alors que je suis de nouveau sur un projet de migration Active Directory avec ADMT, j’ai voulu savoir si Microsoft avait corrigé la problématique de l’époque avec Windows 2008. On pourrait penser qu’avec Windows 2008 R2 et même un Service Pack 1, Microsoft aurait corrigé le problème. Et bien il n’en est rien.

 

Microsoft a juste actualisé la KB969030 pour indiquer que la problématique concerne aussi Windows 2008 R2 dans son édition française. Au passage, j’ai trouvé un workaround au problème : Réaliser la désactivation du filtrage de SID depuis le domaine source fonctionnant sous Windows 2003. La au moins la commande fonctionne.

 

Règle à noter pour les futurs projets de migration : Les bugs de migration restent constants!

 

Benoits – Simple and Secure by Design but business compliant

Subtilité ADMT et Windows 2008 R2

ADMT, ca fait longtemps que je le pratique (NT4 vers Windows 2000). A force, on ne réfléchit même plus et on déroule.  L’outil n’a pas vraiment changé, donc j’ai déroulé jusqu’à tenter de migrer mon premier poste de travail Windows XP, avec une surprise :

“ERR3:7075 Failed to change domain affiliation, hr=800704f1 The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.”

 

Après quelques recherches, je confirme, ADMT n’a pas beaucoup changé. Pour corriger cette problématique, il faut réactiver les algorithmes cryptographiques de Windows NT 4.0 : KB942564. Ceux-ci sont désactivés depuis Windows 2008 pour des raisons évidentes de sécurité. Conclusion, l’agent ADMT n’a donc pas beaucoup changé, je confirme, …

 

J’ai pas eu le temps de tester mais il semble que cette problématique ait été adressée dans le pack de mise à jour RODC Compatibility Pack pour Windows XP. De mon point de vue, c’est effectivement une alternative plus intéressante que de dégrader la sécurité du système d’information. Encore faut-il pouvoir déployer cette mise à jour avant la migration.

 

Benoits – Simple and Secure by Design but Business compliant.

Une histoire de mot de passe AD

Cela fait quelques années que je conçoit et dépanne des infrastructures d’annuaire Active Directory (pour donner une idée, j’ai commencé avec NT 4.0). On pourrait croire que c’est une routine et bien non, on a toujours quelque chose à apprendre de chaque projet de mise en œuvre ou de migration.

 

Le changement de mot de passe dans AD

Lorsqu’un utilisateur change son mot de passe dans l’AD depuis son poste de travail, cette information est immédiatement transmise au contrôleur de domaine hébergeant le rôle de PDCE. Le but est de pouvoir traiter l’authentification de l’utilisateur avec son nouveau mot de passe alors que ce dernier n’est pas nécessairement répliqué sur tous les contrôleurs dans le domaine. Donc normalement, lorsqu’un utilisateur change son mot de passe, il peut immédiatement l’utiliser pour s’authentifier.

 

Question, peut-il encore utiliser l’ancien?

Voila une bonne question. Du point de vue de l’authentification d’un utilisateur au niveau de la mire d’authentification Windows, la réponse est non. Par contre pour les accès réseaux, c’est une autre histoire. Dans le cas de mon dernier projet, mon client constatait qu’après avoir changé son mot de passe sur un contrôleur de domaine, il était toujours possible d’établir une connexion LDAP authentifiée avec l’ancien mot de passe. Le comportement était reproductible pendant une période de temps d’environ une heure. Voila déjà pas mal d’informations pour qualifier la problématique rencontrée.

 

Ce comportement est du à une fonctionnalité qui a été introduite avec le Service Pack 1 de Windows 2003. Celle-ci est documenté par la KB906305. L’utilisateur est effectivement capable d’utiliser son ancien mot de passe mais uniquement pour les accès réseaux. Ce comportement permet aux utilisateurs connectés de ne pas être bloqué, c’est surtout intéressant pour les comptes de services utilisés par des processus distribués. Sans cette fonctionnalité, changer un mot de passe de compte de service peut s’avérer complexe car tous les services devront être arrêtés et reconfigurés.

 

Selon la KB906305, cela ne concerne que les accès réseau effectués en NTLM. On peut même ajouter les accès LDAP/LDAPS, ce qui était le cas de mon client, dont les contrôleurs de domaine installés avec la dernière génération de systèmes d’exploitation Microsoft. La période pendant laquelle il est possible d’utiliser les deux mots de passe est d’une heure. C’est une clé de registre qui doit impérativement être configurée sur tous les contrôleurs de domaine.

 

Est-ce une faille de sécurité?

Du point de vue de la KB906305, non. Seul l’utilisateur qui a changé son mot de passe connait à la fois son mot de passe actuel et son ancien mot de passe.  Dans certains environnements, où la sécurité doit être renforcée, il peut être tentant de réduire la durée de vie pendant laquelle l’ancien mot de passe est utilisable. Si une telle exigence existe, c’est peut être qu’il y a un besoin d’authentification forte des utilisateurs, que ceux-ci se connecte depuis les réseaux de l’entreprise ou depuis l’extérieur.

 

Conclusion

On a effectivement toujours quelque chose à apprendre. C’est une fonctionnalité que je pensais bien connaitre mais je ne pensais pas qu’elle puisse aussi s’appliquer au contexte de mon client.

 

Benoits – Simple and Secure by Design but Business compliant

Capture de traces réseau sous Core

C’est le chalenge que j’ai eu chez un client cette semaine. Comment faire une capture de trace sur un serveur Windows 2008 R2 installé sous Core. Mon premier réflexe a été de dire Facile : NETSH TRACE START CAPTURE=YES TRACEFILE=c:\CAPTURE.ETL. C’est simple et en plus cette méthode permet de collecter un grand nombre d’informations complémentaires qui peuvent nous aider à comprendre ce qui se passe au niveau du système d’exploitation. Manque de bol, sous Core, c’est pas implémenté!

0

 

Bon ben on va installer le Network Monitor sous Core. Une fois installé, on constatera qu’il est possible de réaliser la capture à l’aide de l’outil NMCAP.EXE

1

 

Avec un peu de recherche, on verra qu’il est possible de mettre en place un filtre pour capturer uniquement le trafic recherché.

2

 

La grande surprise, c’est qu’il est réellement possible d’utiliser le Network Monitor dans une installation de Windows Server 2008 R2 Core. Il semble donc qu’il subsiste en beaucoup de composants de l’interface graphique sous Core. C’est toujours bon à savoir.

3

 

Par contre autre chalenge, comment désinstaller le Network Monitor. Microsoft livre un exécutable et non un package Windows Installer. Avec un peu de recherche, on découvre qu’il est possible de décompresser l’exécutable pour retrouver les packages Windows Installer. Reste plus qu’à désinstaller avec la commande “MSIEXEC.EXE /X”.

4

 

A noter qu’il y a deux packages Windows Installer à désinstaller.

5

 

Chalenge relevé

 

Benoits – Simple and Secure by Design but Business compliant.