Archives mensuelles : décembre 2012

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

A KB to know for your next DirectAccess based project with Windows Server 2012.

If you are planning your next DirectAccess project with Windows Server 2012 just consider this KB2782560. This KB provide a fix for Windows Server 2012 (does not concern DirectAccess projects based on UAG 2010). This KB is required if you plan to configure the Unified remote Access Role for DirectAccess in a high availability scenario using Hardware-Load Balancing.

 

If you are in this situation, don’t forget to install this KB. Otherwise DNS name resolution for DirectAccess clients will not work.

 

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

UAG 2010 SP3 for 2013, what to expect for DirectAccess?

According to Forefront UAG team blog, UAG 2010 Service Pack 3 is in progress and should be available in the first quarter of 2013. Additional information are provided by a recent Ben Ari blog post.

image

 

According to ben Ari, support for Windows 8 clients connecting to a UAG 2010 SP3 in DirectAccess will be for SP3. This means that it’s not supported today with UAG 2010 SP2. Why? Because Windows 8 now includes the DirectAccess Connectivity Assistant as a part of the operating system.

 

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