none
Rendre autonome un serveur au sein d'une forêt RRS feed

  • Question

  • Bonjour,

    Quelle est la procédure la plus appropriée pour rendre autonome un contrôleur de domaine (W2019 Server Standard) ?

    Le niveau fonctionnel de la forêt est Windows 2008.

    En fait, il s'agit d'un serveur d'une succursale d'un groupe qui a été vendue, et le but de l'opération serait de rendre le serveur de cette succursale totalement autonome.

    Le serveur ne détient actuellement aucun rôle FSMO, et il est toujours connecté à la forêt.

    J'avais imaginé le déconnecter physiquement et forcer l'assignation de tous les rôles FSMO à lui même en ligne de commande par NTDSUTIL.

    Garder le même nom de forêt n'est pas gênant pour la suite.

    Cela vous parait-il être la meilleure méthode, ou existe t-il un façon de faire plus académique pour rendre un serveur autonome et sans conséquence au niveau des stations de la succursale ?

    Merci pour votre aide.

    Cordialement.

    MEMSEL

    mercredi 17 février 2021 13:48

Toutes les réponses

  • En fait, il s'agit d'un serveur d'une succursale d'un groupe qui a été vendue, et le but de l'opération serait de rendre le serveur de cette succursale totalement autonome.

    Le serveur à d'autres rôles que contrôleur de domaine et DNS ?

    Le plus propre est de faire une migration ADMT vers un nouveau domaine pour les utilisateurs, serveurs membre et ordinateur.

    On ne sépare pas pas un AD de cette manière. 

    J'avais imaginé le déconnecter physiquement et forcer l'assignation de tous les rôles FSMO à lui même en ligne de commande par NTDSUTIL.

    En toute sincérité c'est du travail de cochon. Il faut des compétences pour faire cela et conserver un AD viable lorsque tu supprimes un serveur sans dépromotion. Entre autre il faut purger les métadonneés pour la réplication de l'annuaire et corrigé la réplciation sysvol sinon tu vas avoir des problèmes sur le domaine principal.

    je ne connais personne d'expérimenté qui ferait cela.


    Garder le même nom de forêt n'est pas gênant pour la suite

    Oui mais cloné le SID du domaine c'est juste 0 pointé. 

    La sécurité dans un AD est lié entre autre aux SId  interne (unique et aléatoire à la création du domaine) du domaine que tu vas dupliqué. C'est vraiment plus la peine de se préoccuper de la sécurité si c'est pour faire des trucs pareil ....

    mercredi 17 février 2021 18:33
  • Bonjour,

    Merci pour votre réponse.

    Le serveur en question a les seuls rôles de contrôleur de domaine et DNS.

    Il me semblait, par ce que j'ai appris lors de cours Microsoft, et aussi par expérience (Depuis 1983 dans le monde du PC), que dans le cas d'une perte définitive d'un serveur membre d'un domaine, Microsoft avait tout mis en œuvre pour ne pas affecter le fonctionnement du domaine.

    D'ailleurs la perte de la notion de contrôleur de domaine "Principal", que nous avions dans les versions antérieures n'était-elle pas dans le but de rendre la redondance entre les serveurs la plus proche possible, afin de palier à toute perte d'un des membre ?

    Mais dans ce cas précis, il s'agirait de quitter le domaine sans avoir à solliciter le DSI du groupe.

    En effet; la séparation se passe très (Très) mal, et le DSI de la succursale n'aura donc aucune aide de la part du groupe et de son administrateur, pour effectuer une migration ADMT.

    Pour l'instant le lien avec la forêt est encore actif pour des raisons contractuelles, mais cela ne va pas durer, c'est pour cela que j'essaye de trouver la solution la plus appropriée auprès de personnes désireuses de partager leur savoir et leur expérience.

    Par ailleurs; j'espère ne pas avoir de mauvaises manières, ni de faire du travail de cochon, ni d'être incompétent et inexpérimenté, comme vous pouvez le sous entendre dans votre réponse, sinon cela ferait longtemps que je n'aurais plus de client.

    Désolé de ne peut-être pas avoir votre expérience et votre savoir en matière d'AD, mais il s'agit simplement de trouver une solution à un administrateur désabusé pour lequel je soumet son problème sur un site dédié aux partages d'expériences. 

    Pour citer un vieux routard de notre métier, qui nous a toujours apporté son expérience sans préjugé, et qui malheureusement a pris sa retraite bien méritée, je veux parler de Monsieur Jean-Claude BELLAMY : "La connaissance ne vaut que si elle est partagée".

    Cordialement.

    MEMSEL


    jeudi 18 février 2021 11:05
  • Il me semblait, par ce que j'ai appris lors de cours Microsoft, et aussi par expérience (Depuis 1983 dans le monde du PC), que dans le cas d'une perte définitive d'un serveur membre d'un domaine, Microsoft avait tout mis en œuvre pour ne pas affecter le fonctionnement du domaine.

    Oui l'AD est multi maitre et supporte nativement la perte ou l'indisponibilité d'un contrôleur de domaine. Si la parte est définitive, il est nécessaire de nettoyer les métadonnées dans l'AD( toujours ) et avant la limite du TombStoneLifeTime.

    S'il avait un rôle FSMO il faut forcer le transfert sur un autre serveur. Si l'on force le transfert l'ancien serveur ne doit jamais revenir dans le réseau.

    D'ailleurs la perte de la notion de contrôleur de domaine "Principal", que nous avions dans les versions antérieures n'était-elle pas dans le but de rendre la redondance entre les serveurs la plus proche possible, afin de palier à toute perte d'un des membre ?

    Il n'existe plus de contrôleur de domaine principal depuis Active Directory( windows 2000). Il ne faut pas confondre avec le rôle FSMO émulateur PDC. C'est souvent source d'erreur et d'incompréhension. Par contre sur DNS il reste la notion de primaire et secondaire. Dans les systèmes précédent la notion de contrôleur secondaire permettait également d'assurer la continuité de service même en cas de panne du PDC. Mais un seul des contrôleur de domaine le PDC était en écriture. Ce qui peut allourdir la gestion dans une organisation répartie sur plusieurs pays. Du coup à l'époque on multiplié le nombre de domaine en fonction de la géographie de l'entreprise, ce qui n'est plus nécessaire. La notion de domaine Active Directory est plus une lié à une limite de sécurité.

    Par ailleurs; j'espère ne pas avoir de mauvaises manières, ni de faire du travail de cochon, ni d'être incompétent et inexpérimenté, comme vous pouvez le sous entendre dans votre réponse, sinon cela ferait longtemps que je n'aurais plus de client.

    Je ne sous entend rien et je n'ai aucun préjugé sur votre façon de travailler. Comme tout le monde je suis parti de 0. Je suis expert dans peu de chose, j'ai une connaissance général qui me suffit  sur certains sujets et limité dans beaucoup d'autres. ( en plus mes phrases sont pourris, j'avoue que je fais pas d'effort dans la rédaction) 

    Par contre je préfère être clair quitte à marquer les esprits plutôt que d'encourager ce genre de méthode. Mais forcément je me suis posé les mêmes questions un jour ou l'autre. On a tous des trucs  à apprendre des autres et à apprendre aux autres. 

    Si votre question est peut-on séparer  et nettoyer l'AD pour que chacun vive de leur côté, la réponse est oui. Est ce que c'est bien  de le faire ? la réponse est non ! 





    jeudi 18 février 2021 13:25
  • Philippe a répondu, j'ajouterais juste au

    [...Il me semblait, par ce que j'ai appris lors de cours Microsoft, et aussi par expérience (Depuis 1983 dans le monde du PC),...]

    et bien depuis 83, l'informatique a évolué. En 83, l'Active Directory n'existait pas. Il y avait bien des domaines, mais des domaines NT4 (et aussi Novell :-) ) qui n'ont rien à voir avec les Domaine AD, ... et même avec les Domaines LDAP par extension.

    Pour aller plus loin, je dirais même que certaines pratiques qui étaient faites ne serait-ce il y a 10 ans ne sont absolument plus d'actualité de nos jours. Les connaissances, ça se met à jour régulièrement, et notamment dans nos métiers.

    Cordialement

    Olivier


    jeudi 18 février 2021 14:34
  • Bonsoir Philippe,

    Merci en tout cas pour votre réponse, qui me rassure.

    Je ne confond pas les rôles FSMO et la notion maintenant disparue, de contrôleur de domaine principal.

    Ce que je voulais dire; c'est que Microsoft a supprimé cette notion de contrôleur de domaine principal pour justement éviter l'exclusivité d'un serveur afin de les rendre entre eux totalement redondants en cas de défaillance de l'un d'eux, et que l'AD, quel que soit le site continue de fonctionner.

    Mais ce que je voulais soumettre ici, c'est le cas d'un serveur DC faisant partie d'une forêt et qui perd de façon définitive, (Peu importe la raison), tous les autres DC de la forêt.

    Dans ce cas; quelle serait la marche à suivre pour qu'il devienne autonome et qu'il continue à faire fonctionner son environnement le plus proprement possible ?

    Je suis conscient qu'il s'agit d'un cas qui ne devrait pas arriver, que nous avons à notre disposition tous les outils pour toujours travailler proprement et en sécurité afin d'éviter de se retrouver dans de telle situation.

    Mais l'impensable, l'inimaginable, représente toujours une variable supérieure à zéro (J'évite le terme "positive"), dont il faut tenir compte, et qu'il faut savoir gérer.

    C'est pour cela que je soumet ici ce problème, qui peut se rencontrer plus souvent qu'on ne le pense. Le cas de groupe avec des filiales qui se séparent dans de mauvaises conditions est assez fréquent et peu intéresser bon nombre de DSI au moins une fois dans leur carrière.

    Je soumet donc le cas d'un séparation d'AD imposée, et il ne s'agit plus de savoir si c'est bien ou pas bien, il s'agit d'un fait accomplit par les circonstances et la volonté humaine, pour lequel ni le DSI de la filiale ni moi même ne pouvons rien. 

    Et dans ce cas; hormis le transferts des rôles FSMO forcés, quelles sont les actions à mener pour nettoyer proprement toutes les relations qui existaient avec les serveurs avec lesquels les liens vont être coupées ?

    Par ailleurs, je tiens à vous féliciter pour votre site que j'ai découvert grâce à nos échanges, et plus particulièrement celui dans lequel vous détaillez la migration ADMT. Je vois que vous êtes dans le même courant de pensée que Monsieur Jean-Claude BELLAMY.

    Merci.

    MEMSEL

     

    jeudi 18 février 2021 18:46
  • Bonjour Olivier,

    Cela me parait une évidence que notre métier exige une maintenance permanente des connaissances.

    Et croyez moi depuis le DOS, en passant par toutes les version de NOVELL (précurseur de l'AD), puis toutes les versions de Windows, jusqu'aux dernières "Mise à niveau des connaissances vers le MCSA Windows Server 2016", je n'ai pas dérogé à toutes ces formations nécessaires à la bonne pratique de notre métier. <o:p></o:p>

    Mais ce n'est pas le sujet que je voulais évoquer ici, mais une question technique précise qui peut se poser à tout DSI. 

    Cordialement.

    MEMSEL

    jeudi 18 février 2021 19:13
  • Je ne confond pas les rôles FSMO et la notion maintenant disparue, de contrôleur de domaine principal.

    Souvent je détaille plus que de nécessaire sans présumer de quoi que soit car d'autres personnes lisent les forums

    Dans ce cas; quelle serait la marche à suivre pour qu'il devienne autonome et qu'il continue à faire fonctionner son environnement le plus proprement possible ?

    C'est un peu comme lorsque l'on doit restaurer un domaine complet. La procédure de base consiste à restaurer un DC et a nettoyer les metadonnées puis reconstruire proprement les autres, plutôt que de restaurer tous les DCs, afin d'être sur d'avoir un AD cohérent entre les serveurs.

    Dans les grandes lignes :

    -faire une sauvegarde de l'état du système

    - isoler le serveur et ne jamais reconnecter le lien avec l'autre site

    - modifier la conf réseau pour qu'il n'utile plus que lui même en DNS

    - metadata cleanup 

    -vérifier la réplication sysvol

    -vérifier les redirecteurs DNS et -nettoyer les zones DNS

    - forcer le déplacement des rôles FSMO

    -configurer la synchronisations des horloges 

    -réinitialiser le mot de passe du compte d'ordinateur pour le DC, réinitialiser krbtgt (2*)

    - modifier les pool RID et invalider le pool actuel du DC

    - utiliser DCdiag et corriger toutes les erreurs.

    - reconstruire le catalogue global 

    -ajouter un deuxième DC pour la sécurité (surveiller dcdiag et repadmin)


    jeudi 18 février 2021 19:32
  • Bonjour Philippe,

    Je pense que nous avons tous les éléments pour pouvoir couper le cordon en toute sérénité.

    Merci beaucoup

    Très cordialement.

    MEMSEL 

    vendredi 19 février 2021 08:12