Saturday, January 27, 2018

Active Directory : récupération de la forêt (FR) - 6 - remise en état du contrôleur de domaine restauré

English summary: after the restore of the selected domain controller (forest recovery scenario) and the metadata cleanup performed in the previous blog post, I observe the effects of the cleanup (dcdiag results, for example) and continue to follow the steps in the Microsoft Forest Recovery guide, including RID pool invalidation, computer and krbtgt password resets and NTP settings.


***


Nous avons pris quelques mesures pour remettre en état notre forêt après la restauration d'un (seul) contrôleur de domaine (voir l'article précédent). Nous ne sommes encore qu'à mi-chemin mais je ne résiste pas à l'envie de voir si les choses commencent déjà à aller un peu mieux.

J'exécute les mêmes commandes que nous avons vues avant de prendre les premières mesures de remise en état :
  • repadmin /showrepl
  • repadmin /replsum
  • dcdiag

Les deux premières ne donnent plus d'erreurs. En effet : il n'y a plus d'autres partenaires de réplication :





Cela ne prouve donc rien, sinon que nous avons réussi à enlever toute trace des autres contrôleurs de domaine. C'est peut-être un bon indice après tout.

DCDIAG s'exécute sans relever de problèmes sinon quelques erreurs pour le test SystemLog. En raison de la longueur des données affichées à l'écran, je ne vais pas tout reproduire ici.

***


Mais reprenons les mesures de remise en état de notre forêt...


8. Augmenter la valeur de la réserve des RID disponibles (available RID pool).

Il s'agit de s'assurer qu'un contrôleur de domaine n'alloue pas un SID qui aurait déjà été associé à un autre objet après la sauvegarde mais avant la restauration.

Le pourquoi de cette mesure n'est pas évident à première vue.

Remarque : RID ? Ou SID ? Le RID est la dernière partie du SID qui doit distinguer les principaux de sécurité les uns des autres, à l'intérieur de l'entreprise et (pour le SID) même à l'extérieur. Faites une recherche sur "Active Directory RID SID" pour plus de détails.

Si nous n'augmentons pas cette valeur, un nouveau "principal de sécurité" (utilisateur ou groupe, par exemple) pourrait obtenir le même SID qu'un principal créé entre le moment de la sauvegarde et celui de la restauration. Certes, ce objet n'existerait plus, n'ayant pas été compris dans la sauvegarde. Toutefois, l'accès à des ressources (dossiers, fichiers, imprimantes, etc.) pourrait avoir été accordé à cet objet maintenant disparu. Si un nouveau objet avait le même SID, il aurait accès aux mêmes ressources. Voilà pourquoi nous devons faire le nécessaire pour éviter la délivrance de SID identiques.

Le document recommande d'augmenter la valeur de 100.000. Nous pouvons l'augmenter encore plus, mais seulement s'il le faut absolument, car le nombre de SID n'est pas illimité (1 milliard jusqu'à Windows 2008 R2 et 2 milliards pour Windows Server 2012 et les OS suivants). Bien peu d'organisations risquent de s'approcher de cette limite mais il serait prudent, par exemple, de ne pas augmenter la valeur par des millions.

Nous pouvons effectuer cette opération dans "Modifications ADSI" ou ldp.exe. Je vais présenter la première des deux options.

Il faut donc ouvrir ADSIEdit et se rendre à cette section de l'annuaire (avec un de mes noms de domaine d'essai comme exemple) :

CN=RID Manager$,CN=System,DC=machlinkit,DC=biz



Remarque : notez bien que nous sommes dans le contexte de la domaine (plutôt que la partition de la configuration ou du schéma).


Nous ouvrons les propriétés de CN=RID Manager$ :



Nous copions la valeur actuelle :




Et en faisant bien attention à mettre l'affichage scientifique...



Nous collons la valeur dans la calculatrice :


Remarque : l'option "Coller" est en gris parce que j'avais déjà collé la valeur.


Ensuite, j'ajoute 100.000...




Et je copie la nouvelle valeur ([...] 445209 passe à 545209)...




Que je colle dans les propriétés de CN=RID Manager$ (remplaçant la valeur précédente) :







C'est la méthode que Microsoft propose dans sa documentation. Je me dis qu'on pourrait, en y mettant beaucoup de soin, modifier la valeur directement en comptant bien les chiffres (augmentant de "1" le sixième chiffre à partir de la droite).

Nous n'avons pas besoin de refaire la même opération avec ldp.exe. Un seul outil suffit. Nous pouvons d'ailleurs voir que ldp.exe affiche déjà la nouvelle valeur pour la propriété rIDAvailablePool :




Remarque : je fournis, à la fin de cet article, des liens vers la documentation officielle (exclusivement en anglais) sur chacune de ces opérations.


***


9. Invalider la réserve actuelle des RID (current RID pool).

Il faut invalider la réserve des RID pour empêcher le contrôleur de domaine restauré d'assigner un RID déjà assigné après la sauvegarde (mais avant la restauration). Je crois qu'en faisant cela, nous suivons la même logique que dans l'étape précédente. Je tiens à préciser que si nous avons effectué une restauration de l'état système, la réserve aura été invalidée alors (une telle restauration invalide toujours la réserve des RID). Dans le cas contraire, nous devons coller l'ensemble des commandes suivantes dans PowerShell et les exécuter :

$Domain = New-Object System.DirectoryServices.DirectoryEntry
$DomainSid = $Domain.objectSid
$RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://RootDSE")
$RootDSE.UsePropertyCache = $false
$RootDSE.Put("invalidateRidPool", $DomainSid.Value)
$RootDSE.SetInfo()




La première fois que nous tentons de créer un objet (un utilisateur, par exemple) après l'invalidation, nous verrons s'afficher un message d'erreur :



Il suffit de cliquer sur "Terminer" à nouveau et cette fois-ci l'opération réussit :





10. Réinitialiser le mot de passe du compte ordinateur du contrôleur de domaine.

Note : à faire deux fois.

C'est une mesure de sécurité (en cas d'une brèche, on change les mots de passe) et pourrait aussi servir à empêcher la communication avec d'autres contrôleurs de domaine qui n'auraient pas été mis hors tension. A priori, nous voulons éviter la communication avec ces machines, non seulement pour des raisons de sécurité mais aussi pour bloquer la réplication de données en mauvais état.

Nous réinitialisons le mot de passe avec l'outil NETDOM. Nous pouvons en voir la syntaxe avec cette commande :

netdom help resetpwd



La réinitialisation elle-même se fait avec cette commande :


Rappel : il faut l'exécuter deux fois.




10. Réinitialiser le mot de passe du compte krbtgt.

Note : deux fois, comme pour le compte ordinateur plus haut.

Nous naviguons jusqu'à l'unité d'organisation "Users" (avec l'option "Fonctionnalités avancées" cochée)...




Nous faisons un clic-droite sur l'objet et choisissons dans le menu l'option "Réinitialiser le mot de passe" :



Nous saisissons un nouveau mot de passe (décochant l'option de forcer un changement à la prochaine ouverture de session)...




Et nous changeons le mot de passe une seconde fois en répétant les actions ci-dessus.



12. Décocher la case "Catalogue global" dans les propriétés NTDS.

Si la forêt compte de multiples domaines (et si le contrôleur de domaine était un serveur de catalogue global avant l'incident), nous devons décocher la case "Catalogue global" dans les propriétés "NTDS Settings". Nous ferions cela sur les contrôleurs de domaine restaurés dans chacun des domaines. Ensuite, quand les contrôleurs de domaine de chaque domaine sont remis en rapport les uns avec les autres sur un réseau commun, nous cocherions la case de nouveau. Dans ma topologie (une forêt à un seul domaine), nous n'avons pas besoin de décocher cette case et je la laisse telle quelle :





13. Configurer le service Windows Time.

Dans le domaine racine de la forêt, nous devrions configurer l'émulateur de PDC (PDCe) pour qu'il synchronise l'heure à partir d'une source externe. Si nous avons restauré le contrôleur de domaine qui tient ce rôle, nous n'avons pas grand chose à faire. Sinon, les paramètres NTP du serveur devraient, au départ, ressembler à ceux que nous voyons dans la capture d'écran ci-dessous, et notamment les deux marqués par un point rouge : 




La synchronisation avec une source externe se fait avec l'ensemble des commandes suivantes :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual /reliable:yes /update

net stop w32time
net start w32time

w32tm /resync

Pour le première commande, certaines sources donnent une commande plus courte :

w32tm /config /manualpeerlist:"time.nist.gov",0x8 /syncfromflags:manual


Bien entendu, "time.nist.gov" n'est qu'un exemple. Vous pourriez utiliser une autre source si vous vouliez.

Voici à quoi cela ressemble à la ligne de commande :



Après l'exécution de la commande, les valeurs des paramètres NtpServer et Type ont changé :



En outre, nous devrions pouvoir trouver une entrée dans l'Observateur des événements qui confirme que notre PDCe reçoit des "données de temps valides" de la source externe que nous avions choisie :



***


Quand nous aurons achevé toutes ces opérations, nous pourrons remettre tous les contrôleurs de domaine restaurés en rapport les uns avec les autres (dans mon scénario, une forêt à domaine unique, je n'en ai restauré qu'un seul) et puis rajouter le catalogue global au contrôleur de domaine du domaine racine. Encore une fois, si nous n'avons qu'un seul domaine, nous n'aurons pas supprimé le catalogue global et, en toute logique, n'aurons donc pas besoin de le rétablir.

C'est enfin (!) à ce moment-là que nous pourrons commencer à mettre en place de nouveaux contrôleurs de domaine par ce qui s'appelait autrefois "dcpromo".

Pour l'ensemble des instructions qui m'ont guidé jusqu'ici, je renvoie toujours le lecteur à ce document (seulement en anglais au moment où je l'ai consulté) :

Perform initial recovery



Références :

On les trouve dans le document cité ci-dessus mais pour un accès plus rapide, je donne les liens pour chacune des sections présentées dans cet article (celui que vous venez de lire) :

AD Forest Recovery - Raising the value of available RID pool

AD Forest Recovery - Invalidating the current RID pool

AD Forest Recovery - Resetting the computer account on the DC

AD Forest Recovery - Resetting the krbtgt password

AD Forest Recovery - Removing the global catalog

Configure the Windows Time service on the PDC emulator in the Forest Root Domain.

(Le lien original ne fonctionne plus mais j'ai trouvé ces instructions - en français de surcroît) :

https://technet.microsoft.com/fr-fr/library/cc816748(v=ws.10).aspx

Sunday, January 21, 2018

Active Directory : récupération de la forêt (FR) - 5 - remise en état du contrôleur de domaine restauré

English summary: in my previous blog post, I validated the restore of my domain controller and observed a multitude of error messages. In this post, I will begin to remove objects referring to the domain controllers that were not restored (and that I do not intend to restore in this scenario - restoring other domain controllers is, however, an option). Among other tasks, I perform an authoritative restore of SYSVOL, I demonstrate how to seize the FSMO roles (which may or may not be necessary depending on the domain controller we restore), and I perform "metadata cleanup" of former domain controller entries in Active Directory Users and Computers (ADUC), ADSIEdit, Active Directory Sites and Services (ADSS) and DNS. Once again, some operations may or not be necessary depending on the scenario. In case of a security breach, we would want to change administrator passwords. In other circumstances, this would not be mandatory and would only increase the time to complete recovery.  


***


Dans ce texte, je continue à suivre les étapes énumérées dans le document ci-dessous pour la récupération de la forêt :

AD Forest Recovery - Perform initial recovery

Remarque : je présente les étapes 1 à 7 (DNS) dans ce texte et m'occupe de la suite dans mon prochain article.

Je rappelle au lecteur qu'il s'agit de restaurer un contrôleur de domaine dont nous sommes certains qu'il se trouve en bon état. En pratique, cela veut dire que nous disposons d'une sauvegarde valable et antérieure à l'événement qui a provoqué la perte de notre forêt (acte malveillant ou échec d'une mise à jour du schéma (rare) ou encore autre chose).

Le document précise qu'il faut restaurer le domaine racine de la forêt parce que celui-ci contient les groupes administrateurs du schéma et de l'entreprise. Cela est crucial dans une forêt à plusieurs domaines. Dans mon scénario, nous avons une forêt à un seul domaine et nous n'avons donc pas à nous soucier de l'ordre de restauration des domaines.

Nous devons faire attention à ne pas compromettre le contrôleur de domaine restauré en évitant toute interaction avec les autres contrôleurs de domaine. Le document semble nous offrir deux possibilités. A la page 2/7 du document, on nous recommande de débrancher le câble réseau du contrôleur de domaine (ou de supprimer l'adaptateur de la machine virtuelle s'il s'agit d'un environnement virtuel). Mais comment faire si la sauvegarde se trouve dans un dossier partagé à distance ? Dans une autre section de la documentation, à la page 6/6 du document "Determine how to recover the forest", on recommande plutôt de fermer tous les autres contrôleurs de domaine avant de restaurer celui que nous avons l'intention de remettre sur pied.

AD Forest Recovery - Determine how to recover the forest

Remarque : "2/7" et "6/6" concernent la copie imprimée du document.

C'est cette option que je vais retenir. Je remarquerai seulement qu'en cas de piratage, on pourrait préférer restaurer le contrôleur de domaine dans un réseau isolé, car il est apparemment vulnérable à certains moments de la restauration (faute d'un pare-feu activé ?).

Et maintenant, je vais suivre les étapes du document. Ces étapes sont numérotées mais non pas intitulées. Je fournis donc, par section, un titre qui en résume le principal sujet.



1. Protéger le contrôleur de domaine.

Je viens d'aborder cette question. J'ai éteint les autres contrôleurs de domaine de ma forêt (DC6 et DC7) afin que les éléments à l'origine de la perte de la forêt ne puissent pas se retrouver sur le contrôleur de domaine restauré (éventuellement par réplication).



2. Restaurer le contrôleur de domaine choisi (restauration "normale") et puis restaurer SYSVOL "avec autorité".

J'ai déjà restauré le contrôleur de domaine DC5 à même le matériel dans l'article 3 de cette série et vérifié sont état de marche dans l'article 4, tout en observant de nombreuses erreurs, notamment de réplication. Dans les lignes suivantes, je vais restaurer SYSVOL "avec autorité".

Nous pouvons atteindre cet objectif de deux manières :

  • Après la restauration du serveur entier (à même le matériel), nous pouvons restaurer l'état système.
  • Après la restauration du serveur entier, nous pouvons forcer une synchronisation de SYSVOL.

Je veux dire tout de même deux mots sur le pourquoi de cette seconde opération concernant SYSVOL.

Tous les contrôleurs de domaine que nous ajouterons au domaine plus tard (dans ce scénario de récupération de la forêt, il s'agit de les recréer à partir de zéro), devront synchroniser leur répertoire SYSVOL avec un exemplaire du répertoire marqué comme primaire ou "authoritative". Si aucun exemplaire n'est marqué comme tel, la réplication ne s'amorcera jamais. Une restauration du serveur entier ne marque pas ainsi l'exemplaire du SYSVOL. Voici pourquoi nous devons recourir à d'autres méthodes.

Je commence la démarche en ouvrant la console "Utilisateurs et ordinateurs Active Directory" (ou "ADUC") et en cochant les deux options ci-dessous :




Je navigue jusqu'à l'emplacement indiqué ici :




Je cherche l'attribut msDFSR-Options dans les propriétés du "SYSVOL Subscription - msDFSR-Subscription" et je mets "1" pour la valeur :


Référence :




3. Vérifier les données sur le contrôleur de domaine restauré.

C'était le sujet de l'article 4 de cette série de textes. Si les données ne sont pas valables, il faut essayer une autre sauvegarde.

Cette section précise que si le contrôleur de domaine tient un des rôles dits "FSMO" (maître des opérations), nous pourrions devoir ajouter une clé dans le registre afin d'éviter que "Active Directory Domain Services" soient indisponibles. Cela "pourrait" être le cas. La section ne donne pas d'autres précisions. Quoi qu'il en soit, il suffit d'ajouter la clé suivante dans le registre :

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations





Nous donnons à la clé (de type REG_DWORD) la valeur 0 pour le moment. Après la récupération complète de la forêt, nous pouvons changer cette valeur à 1, ce qui oblige le contrôleur de domaine tenant les rôles FSMO d'avoir des réplications entrantes et sortantes réussies avec ses partenaires avant qu'il puisse s'annoncer comme contrôleur de domaine et fournir ses services.

***

A ce point, le guide nous avertit que nous devrions passer aux étapes suivantes seulement après avoir bien vérifié les données Active Directory et avant de rejoindre le contrôleur de domaine au réseau de production. Dans mon cas, pour la raison donnée (sauvegarde résidant dans un dossier partagé), le contrôleur de domaine est déjà branché sur le réseau, ce qui est peut-être une entorse aux règles (à considérer).

***


4. Si la défaillance de la forêt tient à un acte malveillant (piratage), réinitialiser les mots de passe des comptes administratifs.

Dans mon scénario, ce n'est pas le cas. Selon le document, il s'agirait des comptes suivants :
  • Admins de l'entreprise
  • Admins du domaine
  • Admins du schéma
  • Opérateurs de serveur
  • Opérateurs de compte (et ainsi de suite)


5. Saisir tous les rôles dits "FSMO" sur le premier contrôleur de domaine restauré.

(Bien entendu, si le contrôleur de domaine que nous venons de restaurer ne les tient pas déjà.)

Remarque : il faut être membre des groupes administrateurs de l'entreprise et du schéma pour saisir les rôles qui ont pour étendue toute la forêt, soit le maître (ou contrôleur) du schéma et le maître des noms de domaine.

J'ai répété cette opération à de nombreuses reprises dans d'autres circonstances et dans ce scénario, le contrôleur de domaine que nous avons restauré tient les rôles en question.

---

Au cas où il faudrait le faire, nous le pouvons, soit dans l'interface graphique, soit à la ligne de commande avec l'outil NTDSUTIL. Je préfère la ligne de commande et c'est cette option que je vais résumer ici. Voici donc la marche à suivre avec, comme exemple, le rôle émulateur de PDC :



Il s'agit d'exécuter ntdsutil, de choisir "roles", de se connecter au serveur (DC6 dans cet exemple) avec la commande "connect to server DC6", de quit(ter) et finalement, de lancer la commande...

seize pdc

Chaque fois (et bien que nous soyons en ligne de commande), une fenêtre s'affichera avec un message qui nous demande de confirmer notre choix. Il faut, bien sûr, cliquer sur "oui".

NTDSUTIL tentera de transférer le rôle et après avoir échoué (puisque le partenaire n'est pas accessible), saisira le rôle. Les détails sont abondants mais si nous regardons avec attention, nous devrions voir les détenteurs des rôles après la saisie. Dans ce cas, nous avons réussi à saisir le rôle "pdc" mais un autre contrôleur de domaine (DC4) tient toujours les autres rôles :



Nous pouvons saisir ces autres rôles avec les commandes suivantes :

seize rid master
seize infra master
seize schema master
seize nam master

Remarques : c'est bien "pdc" sans "e". Nous pouvons raccourcir les termes à condition qu'ils ne deviennent pas ambigus. Par exemple, "infra" est un raccourci de "infrastructure" et "nam" un raccourci de "naming". Nous pouvons aussi, bien entendu, saisir le nom complet.

Encore une fois, dans le scénario présent, le contrôleur de domaine restauré tient les rôles et aucune saisie n'est nécessaire. Les captures d'écran sont d'une autre expérience menée dans d'autres circonstances, présentées pour illustrer la procédure à suivre. Les serveurs DC4 et DC6 dans ces captures d'écran n'ont rien à voir avec l'expérience en cours. Nos serveurs sont DC5, DC6 et DC7. Il y a un DC6 dans les deux cas mais ce n'est pas le même.

En dernier lieu, nous pourrions choisir de restaurer plus d'un (seul) contrôleur de domaine. Si un des autres contrôleurs tient les rôles, là encore, il n'est donc pas nécessaire (ni logique) de les saisir. 

---


6. Nettoyer les métadonnées concernant les contrôleurs de domaine que nous n'avons pas l'intention de restaurer.

Dans notre scénario, je ne vais pas restaurer les contrôleurs de domaine DC6 et DC7. Il faut donc purger Active Directory de toutes les métadonnées les concernant. A cette étape aussi, nous avons le choix entre l'interface graphique et la ligne de commande. J'ai toujours préféré la ligne de commande mais l'interface graphique nous permet désormais de supprimer un contrôleur de domaine comme tout autre objet de l'annuaire - et prend beaucoup moins de temps. C'est donc l'interface graphique ("ADUC" en fait) dont je me servirai ici.


ADUC

Ainsi, j'ouvre "ADUC" et je sélectionne les contrôleurs de domaines à supprimer :




Tout est fait afin que nous ne supprimions pas un contrôleur de domaine par inadvertance. Nous devons confirmer notre volonté de le faire plusieurs fois :






Je fais de même pour DC7.

A la fin, seul le contrôleur de domaine restauré, DC5, devrait rester :




Cela supprime les métadonnées concernant DC6 et DC7 mais il reste encore des références à ces deux contrôleurs de domaine ça et là. Voici les endroits où il faut voir s'il en reste des traces :



ADSI (Modification ADSI ou ADSIEdit)

Dans ce cas, aucun objet ne représente plus DC6 ou DC7 dans la section CN=DFSR-GlobalSettings (voir la capture d'écran ci-dessous). Dans le cas contraire, il suffirait de sélectionner l'objet et de le supprimer :





ADSS (Sites et Services Active Directory)

A l'emplacement indiqué dans la capture d'écran ci-dessous, nous devons effacer tout objet représentant les contrôleurs de domaine que nous n'avons pas restaurés (ou n'allons pas restaurer) :  




DNS

Nous devons passer nos zones DNS au peigne fin et supprimer tout enregistrement concernant les contrôleurs de domaine que nous n'allons pas restaurer (DC6 et DC7 dans notre cas).

Dans le document, cette partie fait l'objet d'une section à elle seule (la suivante - numéro 7).



7. DNS

D'abord, nous devons configurer le contrôleur de domaine restauré avec sa propre adresse IP (si ce n'est pas déjà le cas) :



Remarque: les avis divergent sur la configuration des serveurs DNS pour les contrôleurs de domaine. Les uns recommandent de mettre l'adresse d'un autre contrôleur en premier et les autres de mettre l'adresse IP du contrôleur de domaine en question lui-même. 

Dès que les autres contrôleurs de domaine sont reconstruits, nous pouvons revenir à nos pratiques habituelles.


Ensuite, nous devons supprimer tous les enregistrements A, NS et SRV pour les contrôleurs de domaine que nous n'allons pas restaurer. Voici quelques captures d'écran comme exemple :





Pour les enregistrements NS, il faut cliquer sur l'un d'eux afin de modifier la liste des serveurs de noms :




Il faut parfois développer toute l'arborescence pour trouver les enregistrements :




Sans oublier les enregistrements PTR :



Cette commande est supposée faciliter le processus mais ne nettoie pas tous les enregistrements (loin s'en faut) :

nltest /dsderegdns:server.domain.tld

Je l'ai exécutée avant de supprimer tous les enregistrements à la main ci-dessus. Comme vous voyez, il en restait tellement que je suis amené à douter de l'efficacité de la commande.


***


Remarque : tout cela ne change rien à un point d'exclamation sur fond jaune que j'ai remarqué sur l'icône réseau dans le coin inférieur droite (barre des tâches) :



De quoi s'agit-il ?

J'ai découvert que cela tient à la configuration de la redirection DNS. Pour une raison inconnue (mauvaise configuration au départ ?), l'adresse IP du redirecteur est celle d'un des contrôleurs de domaine que nous avons supprimés (DC6) :




Si je remplace cette adresse par celle d'un service DNS extérieur (OpenDNS ou Google, par exemple)...



Le point d'exclamation sur fond jaune disparaît (et même après avoir décoché la case pour les indications de racine dans la capture d'écran ci-dessus) :



A suivre...