locked
Arborescence de domaine dans une Foret RRS feed

  • Question

  • Bonjour tout le monde

    Je souhaiterais modifier mon infrastructure de Domaine Contrôler qui a à son sein 5 sites dont chacun a son DC sous WS2008R2, chaque site est indépendant et ils portent le même nom de domaine (monentreprise.com).

    - Mon souci est seul de savoir si je peut unifier tous les DC dans un seul domaine?

    - Quel DNS utilisé dans poste client du site distant?

    - Quels sont les avantages et désavantages:

      - Avoir un domaine parent et domaine enfant

      - Avoir un domaine avec plusieurs site

    Merci d'avance.


    hussein demo


    mardi 19 février 2019 16:07

Réponses

  • Bonjour, si je comprends bien, vous souhaitez fusionner les domaines ci-dessous en un seul domaine? 

    monentreprise1.com

    monentreprise2.com

    monentreprise3.com

    monentreprise4.com

    monentreprise5.com

    Si c'est le cas je vous conseille:

    - d'avoir une seule forêt

    - pas de domaines enfant

    -Chaque domaine doit avoir son propre DNS

    Petit lien qui peux vous aider:

    https://fr.slideshare.net/TechnetFrance/active-directory-en-2012-les-meilleures-pratiques-en-design-scurit-et-administration

    Cordialement

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mardi 19 février 2019 21:30
  • Bonsoir,

    s'il s'agit de 5 forêts indépendantes ayant le même nom, cela ne va pas être pratique de les regrouper !

    Surtout s'il faut récupérer les informations (comptes, ...) de chaque domaine, sans parler des machines clientes à migrer/réintégrer. En espérant qu'il ne s'agit pas d'un même contrôleur de domaine qui aurait été dupliqué sur chaque site.

    Le premier besoin est d'avoir un réseau suffisant entre chaque site (10 Mbits/s).

    Pour répondre aux questions...

    -> techniquement, on peut avoir 5 DC dans un seul domaine. Mais la logique sera d'approuver chaque domaine distant, de transférer les objets, de dépromouvoir le DC distant, puis de le réintégrer (promouvoir) dans le domaine que l'on veut conserver.

    -> Après migration, chaque site distant utilisera en priorité le DNS du (nouveau)DC local qui aura été configuré, et en backup un DNS distant.

    * il est recommandé d'avoir le minimum de forêt, le minimum de domaines, ce qui diminue le nombre de serveurs nécessaires tout en augmentant la tolérance aux pannes.

    -> Aucun intérêt à un domaine parent/enfant dans ton cas. Chaque domaine nécessite au moins 2 contrôleurs de domaine. La dépendance entre domaines, fait que le domaine racine doit être particulièrement protégé.

    -> La notion de site permet souvent d'optimiser au mieux l'utilisation du réseau, et de configurer certains éléments de manière spécifique (proxy par exemple, ...).

    A+


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mardi 19 février 2019 22:35
  • En plus de la réponse de Thierry, il est à noter :

    - si tu veux unifier dans une forêt unique les sites doivent être relié avec des liaisons "stables" et les contrôleurs de domaine doivent répliqués régulièrement.

    - si chaque site dispose de ses propres ressources, il n'y pas forcément d'intérêt à migrer dans un environnement unique. Une forêt (avec un ou plusieurs domaines) est toujours un environnement unique ( même partition de schéma, même partition de configuration) dont les contrôleurs de domaine doivent répliqués. Un domaine enfant n'est viable que s'il peut dialoguer avec le domaine parent.  

    - pour utiliser des outils comme ADMT, il faut pouvoir créer une approbation entre les sites et pour cela ils doivent avoir des noms différentshttp://www.pbarth.fr/node/106. C'est d'ailleurs le principe de base de DNS de ne pas créer plusieurs environnement différent avec le même nom.

    -évite les forêts multi domaines, en général, on le fait s'il y a une contrainte forte extérieur en matière de limite de sécurité, de délégation et s'il faut mutualiser es ressources. Si chaque site est autonome et à ses propres serveurs il est plus simple de ne pas mutualiser et d'utiliser des approbations entre les forêts autonomes (ce qui évite une lourde charge de travail, alors qu'il n'y a pas de réél besoin d'unifier les éléments). Comme expliqué par Thierry dans une forêt multi domaine, le domaine racine est particulier, déja en terme de sécurité étant donné qu'il contient des groupes qui n'existent pas dans les autres (administrateur de schéma, administrateurs d'entreprises ...)

    Si tu dois tout de même regrouper, il y a trois possibilités :

    -renommer le domaine AD, mais c'est périlleux, en général l'AD le supporte bien mais par contre cela impact fortement tous les services dépendant (application, site intranet qui marche plus...), du coup c'est rarement recommandable. Cela n'aura pas d'intérêt par contre si tous les domaines ont été créés par clonage d'un autres (déja vu dans ces forums) et utilisent le même identifiant unique en pus d'avoir le même nom.

    -faire une migration ADMT vers un domaine temporaire puis refaire une deuxième migration ADMT

    - faire une migration manuelle, des utilisateurs des postes et des ressources.

    Du coup, il y a deux questions que tu dois te poser :

    - Comment seront géré les ressources ? Chaque site à ses serveurs ? 

    - plusieurs équipes indépendantes pour gérer les environnements ? Tu dois déléguer la gestion sur chaque site  ?

    Migrer vers un environnement AD unique n'est pas un objectif ni une finalité en soi, cela peut-être un moyen d'atteindre tes objectifs. A toi de déterminer le profit que tu en attends, et si la charge et le coût reste réaliste par rapport aux attentes.

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mercredi 20 février 2019 03:52
  • Hello,

    la solution 3 de migration manuelle est possible, mais suppose un nombre limité de postes/utilisateurs par site. Elle a un impact sur les postes clients qui souvent se retrouve avec un nouveau profil dans lequel l'utilisateur doit remettre ses paramètres et personalisation.

    Si le nombre est important, l'utilisation de ADMT (Serveur temporaire de migration) permet de récupérer les objets (Utilisateurs, etc...) et migrer les stations et leurs profils dans le nouvel environnement avec un minimum d'impact pour les utilisateurs.

    A bientôt


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    jeudi 21 février 2019 05:58
  • Bonjour,

    il y a néanmoins un gain (économique) potentiel évident à regrouper au maximum l'administration:

    - un seul admin au lieu de 5 (potentiellement)

    - une seule action d'administration pour l'ensemble (stratégie,...)

    - unicité des paramètres

    - mobilité des utilisateurs entre les sites

    - facilité de migration/hybridation vers le cloud/Office 365

    - ...

    Eventuellement, suppression de serveurs sur les petits sites, si les liaisons réseaux le permettent.

    A bientôt,


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mercredi 20 février 2019 07:28
  • Bonsoir,

    Merci beaucoup pour votre intervention.

    J'ai souhaiterais vraiment regrouper au maximum l'administration comme l'a dit @Thierry :

    - un seul super-admin site principal (siège), le reste des sites auront de délégation d'administration

    - Une seule action d'administration surtout pour le GPO

    - mobilité des utilisateurs entre sites (c'est le point le plus important voilà le pourquoi j'ai de la réplication des objets )

    ....

    @Philippe j'avais bien réfléchi à ces questions avant même de poster 

    - Comment seront géré les ressources, Chaque site à ses serveurs ? Oui

    - plusieurs équipes indépendantes pour gérer les environnements, Tu dois déléguer la gestion sur chaque site  ? Oui

    Du coup la 3 ème possibilité proposée par @Philippe me va parfaitement

    ..... j'espère être dans la bonne direction ? @Philippe @Thierry



    hussein demo

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    mercredi 20 février 2019 19:57
  • Il est même possible de mixer les solutions en fonctions de la taille des sites et des services présents sur les sites.

    L'installation d'outils comme ADMT n'est pas forcément très longue et très lourde.  

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    jeudi 21 février 2019 08:59
  • ADMT permet également de migrer les informations de sécurité, les permissions NTFS, il peut permettre de conserver l'accès aux ressources pour les utilisateurs migré et ce qui ne le sont pas encore. Cela permet de migrer progressivement en limittant les interruptions et impact utiilsateur.

    Il peut également migrer les groupes.

    Les serveurs de ressources sont a migré en dernier.

    PAr contre les contrôleurs de domaine de l'ancien domaine ne peuvent être migré, ce qui est génant dans des architectures physiques avec un serveur qui cumul les rôles.

    http://www.pbarth.fr/node/106

    Eviter l'utilisation de nom public en deux parties pour votre domaine interne, comme monentreprise.com qui peut provoquer des conflits.

    http://www.pbarth.fr/node/5


    jeudi 21 février 2019 20:49

Toutes les réponses

  • Bonjour, si je comprends bien, vous souhaitez fusionner les domaines ci-dessous en un seul domaine? 

    monentreprise1.com

    monentreprise2.com

    monentreprise3.com

    monentreprise4.com

    monentreprise5.com

    Si c'est le cas je vous conseille:

    - d'avoir une seule forêt

    - pas de domaines enfant

    -Chaque domaine doit avoir son propre DNS

    Petit lien qui peux vous aider:

    https://fr.slideshare.net/TechnetFrance/active-directory-en-2012-les-meilleures-pratiques-en-design-scurit-et-administration

    Cordialement

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mardi 19 février 2019 21:30
  • Bonsoir,

    s'il s'agit de 5 forêts indépendantes ayant le même nom, cela ne va pas être pratique de les regrouper !

    Surtout s'il faut récupérer les informations (comptes, ...) de chaque domaine, sans parler des machines clientes à migrer/réintégrer. En espérant qu'il ne s'agit pas d'un même contrôleur de domaine qui aurait été dupliqué sur chaque site.

    Le premier besoin est d'avoir un réseau suffisant entre chaque site (10 Mbits/s).

    Pour répondre aux questions...

    -> techniquement, on peut avoir 5 DC dans un seul domaine. Mais la logique sera d'approuver chaque domaine distant, de transférer les objets, de dépromouvoir le DC distant, puis de le réintégrer (promouvoir) dans le domaine que l'on veut conserver.

    -> Après migration, chaque site distant utilisera en priorité le DNS du (nouveau)DC local qui aura été configuré, et en backup un DNS distant.

    * il est recommandé d'avoir le minimum de forêt, le minimum de domaines, ce qui diminue le nombre de serveurs nécessaires tout en augmentant la tolérance aux pannes.

    -> Aucun intérêt à un domaine parent/enfant dans ton cas. Chaque domaine nécessite au moins 2 contrôleurs de domaine. La dépendance entre domaines, fait que le domaine racine doit être particulièrement protégé.

    -> La notion de site permet souvent d'optimiser au mieux l'utilisation du réseau, et de configurer certains éléments de manière spécifique (proxy par exemple, ...).

    A+


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mardi 19 février 2019 22:35
  • En plus de la réponse de Thierry, il est à noter :

    - si tu veux unifier dans une forêt unique les sites doivent être relié avec des liaisons "stables" et les contrôleurs de domaine doivent répliqués régulièrement.

    - si chaque site dispose de ses propres ressources, il n'y pas forcément d'intérêt à migrer dans un environnement unique. Une forêt (avec un ou plusieurs domaines) est toujours un environnement unique ( même partition de schéma, même partition de configuration) dont les contrôleurs de domaine doivent répliqués. Un domaine enfant n'est viable que s'il peut dialoguer avec le domaine parent.  

    - pour utiliser des outils comme ADMT, il faut pouvoir créer une approbation entre les sites et pour cela ils doivent avoir des noms différentshttp://www.pbarth.fr/node/106. C'est d'ailleurs le principe de base de DNS de ne pas créer plusieurs environnement différent avec le même nom.

    -évite les forêts multi domaines, en général, on le fait s'il y a une contrainte forte extérieur en matière de limite de sécurité, de délégation et s'il faut mutualiser es ressources. Si chaque site est autonome et à ses propres serveurs il est plus simple de ne pas mutualiser et d'utiliser des approbations entre les forêts autonomes (ce qui évite une lourde charge de travail, alors qu'il n'y a pas de réél besoin d'unifier les éléments). Comme expliqué par Thierry dans une forêt multi domaine, le domaine racine est particulier, déja en terme de sécurité étant donné qu'il contient des groupes qui n'existent pas dans les autres (administrateur de schéma, administrateurs d'entreprises ...)

    Si tu dois tout de même regrouper, il y a trois possibilités :

    -renommer le domaine AD, mais c'est périlleux, en général l'AD le supporte bien mais par contre cela impact fortement tous les services dépendant (application, site intranet qui marche plus...), du coup c'est rarement recommandable. Cela n'aura pas d'intérêt par contre si tous les domaines ont été créés par clonage d'un autres (déja vu dans ces forums) et utilisent le même identifiant unique en pus d'avoir le même nom.

    -faire une migration ADMT vers un domaine temporaire puis refaire une deuxième migration ADMT

    - faire une migration manuelle, des utilisateurs des postes et des ressources.

    Du coup, il y a deux questions que tu dois te poser :

    - Comment seront géré les ressources ? Chaque site à ses serveurs ? 

    - plusieurs équipes indépendantes pour gérer les environnements ? Tu dois déléguer la gestion sur chaque site  ?

    Migrer vers un environnement AD unique n'est pas un objectif ni une finalité en soi, cela peut-être un moyen d'atteindre tes objectifs. A toi de déterminer le profit que tu en attends, et si la charge et le coût reste réaliste par rapport aux attentes.

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mercredi 20 février 2019 03:52
  • Bonjour,

    il y a néanmoins un gain (économique) potentiel évident à regrouper au maximum l'administration:

    - un seul admin au lieu de 5 (potentiellement)

    - une seule action d'administration pour l'ensemble (stratégie,...)

    - unicité des paramètres

    - mobilité des utilisateurs entre les sites

    - facilité de migration/hybridation vers le cloud/Office 365

    - ...

    Eventuellement, suppression de serveurs sur les petits sites, si les liaisons réseaux le permettent.

    A bientôt,


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo mercredi 20 février 2019 18:55
    mercredi 20 février 2019 07:28
  • Exactement Thierry

    Réduction de coût, gestion centralisé, infrastructure centralisé, mobilité, hybridation... Tu es clairement sur des objectifs

    mercredi 20 février 2019 10:17
  • Bonsoir,

    Merci beaucoup pour votre intervention.

    J'ai souhaiterais vraiment regrouper au maximum l'administration comme l'a dit @Thierry :

    - un seul super-admin site principal (siège), le reste des sites auront de délégation d'administration

    - Une seule action d'administration surtout pour le GPO

    - mobilité des utilisateurs entre sites (c'est le point le plus important voilà le pourquoi j'ai de la réplication des objets )

    ....

    @Philippe j'avais bien réfléchi à ces questions avant même de poster 

    - Comment seront géré les ressources, Chaque site à ses serveurs ? Oui

    - plusieurs équipes indépendantes pour gérer les environnements, Tu dois déléguer la gestion sur chaque site  ? Oui

    Du coup la 3 ème possibilité proposée par @Philippe me va parfaitement

    ..... j'espère être dans la bonne direction ? @Philippe @Thierry



    hussein demo

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    mercredi 20 février 2019 19:57
  • Hello,

    la solution 3 de migration manuelle est possible, mais suppose un nombre limité de postes/utilisateurs par site. Elle a un impact sur les postes clients qui souvent se retrouve avec un nouveau profil dans lequel l'utilisateur doit remettre ses paramètres et personalisation.

    Si le nombre est important, l'utilisation de ADMT (Serveur temporaire de migration) permet de récupérer les objets (Utilisateurs, etc...) et migrer les stations et leurs profils dans le nouvel environnement avec un minimum d'impact pour les utilisateurs.

    A bientôt


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    jeudi 21 février 2019 05:58
  • Il est même possible de mixer les solutions en fonctions de la taille des sites et des services présents sur les sites.

    L'installation d'outils comme ADMT n'est pas forcément très longue et très lourde.  

    • Marqué comme réponse Hussein demo jeudi 21 février 2019 19:25
    jeudi 21 février 2019 08:59
  • Hello,

    @Thierry et @Philippe si je comprends bien l'outil ADMT me permettra de migrer les objets (utilisateurs, ordinateurs ...)vers le site principal envisagé, ensuite refaire le domaine du site distant en choisissant forêt existant ===> ajouter un DC à un domaine existant pour enfin répliquer les objets migrés.

    Cette migration prend en compte le changement du nom de domaine? (compte: nom d'ouverture de session utilisateur)

    Ex: on migre de monentreprise.com vers moneglise.com, les comptes utilisateurs prendra le nom du domaine de destination j’espère

    Merci!


    hussein demo

    jeudi 21 février 2019 19:23
  • Bonsoir Hussein,

    ADMT va "copier" l'utilisateur entre les 2 forêts...

    => Après copie, il continue à exister des 2 côtés avec différents choix (activé ou désactivé ou non comme on le souhaite). Il est aussi intéressant de migrer le SID (Sid History). On peut copier le mot de passe avec un outil supplémentaire proposé par ADMT.

    Les comptes sont modifiés par défaut pour s'adapter au nouveau domaine. Attention aux doublons potentiels, on peut fusionner s'il s'agit vraiment du même utilisateur, ou interdire la fusion et créer un nouvel objet.

    ADMT va "modifier" l'appartenance d'un ordinateur, qui ne peut appartenir qu'à un seul domaine à la fois. Attention, l'objet reste dans l'ancien domaine, mais n'est plus fonctionnel.

    A bientôt,


    Thierry DEMAN. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(84 MCPs). MCSA Office 365 http://base.faqexchange.info

    jeudi 21 février 2019 19:36
  • ADMT permet également de migrer les informations de sécurité, les permissions NTFS, il peut permettre de conserver l'accès aux ressources pour les utilisateurs migré et ce qui ne le sont pas encore. Cela permet de migrer progressivement en limittant les interruptions et impact utiilsateur.

    Il peut également migrer les groupes.

    Les serveurs de ressources sont a migré en dernier.

    PAr contre les contrôleurs de domaine de l'ancien domaine ne peuvent être migré, ce qui est génant dans des architectures physiques avec un serveur qui cumul les rôles.

    http://www.pbarth.fr/node/106

    Eviter l'utilisation de nom public en deux parties pour votre domaine interne, comme monentreprise.com qui peut provoquer des conflits.

    http://www.pbarth.fr/node/5


    jeudi 21 février 2019 20:49
  • monentreprise.com: c'est juste un exemple pour me faire comprendre

    "ADMT va "modifier" l'appartenance d'un ordinateur, qui ne peut appartenir qu'à un seul domaine à la fois. Attention, l'objet reste dans l'ancien domaine, mais n'est plus fonctionnel."

    "PAr contre les contrôleurs de domaine de l'ancien domaine ne peuvent être migré, ce qui est génant dans des architectures physiques avec un serveur qui cumul les rôles."

    ====> Pas de souci, je veux de-promouvoir l'actuel domaine et promouvoir le nouveau domaine qui est dans le site principal; j’espère que les objets migrés  vont se comporter normalement. puisqu'il va hérité tous les objets du domaine principal.

    je veux que les utilisateurs ne remarque rien de ce changement.

    Merci!


    hussein demo

    samedi 23 février 2019 13:36
  • Pas de souci, je veux de-promouvoir l'actuel domaine et promouvoir le nouveau domaine qui est dans le site principal. 

    Je n'ai pas tout compris de la méthode que tu comptes utiliser.

    Si tu rétrograde tous les contrôleur de domaine de l'ancien domaine, ADMT ne sera plus opérationnel. Donc par principe tu ne peux migrer les DCs avec ADMT. Dans ce scénario, il faudrait d'abord migrer le rôle AD DS sur un DC temporaire qui ne sera pas repris.

    On évite de migrer des anciens contrôleurs de domaine dans un nouveau domaine, cela ne donne pas des machine propres. Il est préférable au possible de migrer les autres services présent sur le serveur.

    "ADMT va "modifier" l'appartenance d'un ordinateur, qui ne peut appartenir qu'à un seul domaine à la fois. Attention, l'objet reste dans l'ancien domaine, mais n'est plus fonctionnel."

    La machine en question sera membre du nouveau domaine, mais l'objet Active Directory compte d'ordinateur peut encore exister dans le domaine source 

    dimanche 24 février 2019 12:20