Archives de catégorie : SID-Filtering

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

Les challenges des nouveaux projets de migration

Après le marathon DirectAccess (qui aura une suite dès que j’ai un peu plus de temps), j’avais besoin d’un peu de temps pour le prochain billet, un peu moins technique, plus axé sur les challenges des futurs projets de migration.

 

Multiplicité des sources de migration

C’est un fait, les infrastructure AD/Exchange mises en œuvre depuis Windows 2000 n’ont pas permit de réduire le nombre de domaines et donc de serveurs. On a souvent migré à l’identique, en conservant le nombre de domaine. Pour quelles raisons?

  • Techniques : En France, la principale limitation a été le coût du WAN. Maintenant, ce facteur et beaucoup moins important avec la généralisation des technologies DSL et le déploiement de la fibre optique.

  • Conformisme : C’est tellement plus simple de refaire ce qu’on a déjà fait dans le passé.

De ce fait, lorsqu’on migre ces infrastructures, on a plusieurs “sources” de migration. Qui dit plusieurs sources dit conflits de noms lors de la migration. Pour adresser cette problématique, on a deux possibilités  :

  • Traiter la problématique à la source : C’est la méthode la plus simple. On renomme les objets dans le domaine “source” de la migration. Par contre, renommer un compte utilisateur a un certain nombre d’impacts. Il faut donc pouvoir anticiper cette phase au plus tôt.

  • Traiter la problématique à la cible : Renommer sur le domaine “cible” demande autant de travail mais on peut communiquer aux utilisateurs au plus tôt, ce qui permet de minimiser l’impact.

 

Un conflit peut aussi donner lieu à la fusion des objets (contacts en double, groupes en double). Cela ne pose pas de problème particulier sauf que plus on multiplie les sources, plus nos utilisateurs migrés seront membres de groupes (via le Sid-History). Cas concret, la fusion de sept domaines en un seul, l’utilisateur migré est membre au minimum du groupe “Utilisa. Du domaine” mais aussi des mêmes groupes issus des groupes des domaines sources (cas de migration vers Windows 2000). Que va t’il se passer si nos utilisateurs sont membres de trop de groupes? Y a t’il une limité? Et bien oui, 1015 KB328889, et cela a un impact sur les GPO : KB263693. L’impact sur les utilisateurs sera multiple.

Limitations autour du Sid-History

Le fait qu’un utilisateur migré puisse accéder à ses données dans l’environnement “source” repose uniquement sur le “Sid-History”. Encore faut-il que les applications soient capables de l’utiliser. Un exemple chez Microsoft? SharePoint :

Mais sans aller aussi loin, il y a une limitation propre à Windows. Si on regarde ADMT, il n’est pas capable de migrer l’appartenance aux groupes “Built-in”. Or, il arrive souvent qu’on ait utilisé des groupes tels que ‘”Utilisa. du domaine”. Et là, ADMT bloque. Pas de problème me direz-vous, la solution de migration de Quest elle y arrive. Vrai, sauf si la source est Windows Server 2003. La raison est toute simple : The security IDs for built-in domain groups are filtered in Windows Server 2003. Pour adresser cette problématique, il n’y a que deux solutions :

  • Corriger les permissions positionnées sur les ressources à la source et les remplacer par de nouveaux groupes (Démarche ADMT)

  • Migrer ces groupes sous un autre nom dans le domaine “cible”

Les serveurs d’impression

Migrer un serveur d’impression, c’est facile, super facile avec Windows Server 2008. Il y a un assistant qui fait cela très bien. Pour que la migration fonctionne, encore faut-il disposer du pilote d’imprimante équivalent sous Windows Server 2008 qui ne fonctionne pas en mode noyau (car impossible sous Windows Server 2008 64bits). En plus, l’outil de migration est bien capable de migrer mais depuis Windows Server 2003, pas Windows 2000. Pour ce dernier, il faut passer par un serveur pivot Windows Server 2003 et le bon vieux Print Migrator. Dispose t’on des pilotes pour les imprimantes pour Windows 2008? Bonne question. Il y a un risque pour que non ou que le pilote ne reprenne pas toutes les fonctionnalités du pilote initial.

GPO installation d’applications

Lorsqu’on utilise les stratégies de groupe pour installer des applications, la migration peut poser problème. Lorsque le poste va migrer, l’application va automatiquement être réinstallée si on migre aussi la stratégie de groupe. Comment éviter la réinstallation sur les postes migrés et continuer à déployer l’application sur les nouveaux postes? Pour cela, pas d’autre solution que d’identifier la population des postes migrés par un groupe que l’on va utiliser sur la stratégie de groupe pour en filtrer l’application (en refus).

DFS

C’est là le pire. Certains clients ont découvert DFS avec Windows 2000 (pas brillant sur la réplication) et surtout avec Windows Server 2003 (bien mieux avec DFS-R). Migrer une racine DFS est impossible, il faut la recréer. On a deux problèmes :

  • Le changements de chemin UNC
  • La réplication

 

En recréant une racine de domaine dans le domaine “cible”, c’est un nouveau chemin UNC. Que va t’il se passer pour les documents Office qui font référence à d’autres documents? La réponse est simple, la référence ne fonctionne plus car elle est exprimée avec le chemin UNC de la racine DFS. Donc l’utilisateur vient se plaindre que ses fichiers Excel avec multiples références ne fonctionnent plus. Il est a noter que la problématique est identique sans DFS, le simple fait de migrer les données de l’utilisateur sur un autre serveur de fichiers produit le même effet.

La réplication DFS. Un cauchemar sous Windows 2000, nettement mieux sous Windows Server 2003. Le problème, c’est qu’un groupe de réplication ne peut contenir des membres que de la même forêt. Dans le cadre d’une consolidation de forêts, il y a donc un problème. Mais alors comment migrer? Il n’y a pas de réponse “Microsoft” à cette problématique, sinon un exemple. Comment migrer la racine DFS SYSVOL de la réplication. Avec DFSRMIG, tel que je l’avais présenté dans le billet DFSRMIG & SYSVOL. Voila l’idée de base qu’il faut reproduire. Cette fois on ne migre pas quelques mégaoctets mais des giga-octets. L’erreur est ici interdite.

La virtualisation

C’est devenu un composant essentiel pour tous les projets de migration, que ce soit plus la plateforme de pré-production ou même la plateforme de migration. Cependant, la virtualisation pose aussi un certain nombre de problèmes. Premièrement, tous les logiciels ne sont pas entièrement supportés. Le cas Exchange est le plus connu, mais c’est aussi valable pour MOCS.

Conclusion

Les projets de migration seront d’autant plus compliqués qu’il y aura plusieurs domaines à consolider. L’aspect technique peut être traité. Cependant, il ne faut pas sous-estimer la communication aux utilisateurs et l’assistance à fournir en avance de phase de la migration. Plus les domaines “sources” seront rationnalisés, plus la migration s’en trouvera simplifiée.

BenoîtS – Simple and Secure by Design (J’insiste sur le Secure)

Problème de Sid-Filtering avec Windows Server 2008

Pour ce billet, un cas concret rencontré par un de mes collègues sur notre projet actuel. Un scénario de migration inter-forêt. Dans la mise en œuvre, dès que les domaines “source” et “destination” sont interconnectés, on continue en désactivant le filtrage de SID (Actif par défaut depuis Windows 2000 SP3) pour bénéficier de la fonctionnalité Sid-History. Pour rappel, la commande NETDOM.EXE ressemble à cela et elle fonctionne très bien :

NETDOMW2K3

Le premier blanc correspond au nom du domaine “destination” et le second au nom du domaine “source”. On constate que la commande fonctionne bien lorsqu’elle est exécutée sous Windows Server 2003.

Maintenant, essayons sous Windows Server 2008, plus précisément une édition localisée “française” :

NETDOM0

C’est étrange, que l’on demande d’activer ou désactiver le filtrage de SID, on obtient la même réponse : “Le filtrage des SID est activé pour cette approbation”. Et en plus tout s’est bien passé? Déjà cela ne ressemble plus beaucoup à ce qu’on obtenait sous Windows Server 2003.

Quelques recherches plus tard (Merci François L de MCS), on tombe sur la KB969030 qui comme son titre nous l’indique rapporte que “Some Netdom commands do not work correctly in localized versions of Windows Server 2008”. Nan pas possible? Si on teste la solution proposée, cela ne change pas grand chose à notre problème :

NETDOM1

Par contre, si on utilise “Oui” et “Non” à la place de “Yes” et “No” pour le paramètre “Quarantine”, là, on retrouve un comportement normal :

NETDOM2

Un grand merci à mon collègue Yassine B pour avoir identifié cette problématique et la solution qui va avec.

 

BenoîtS – Simple and Secure by Design (j’insiste sur le Secure)