Mot de passe des comptes ordinateur
Fermé
kaizi
Messages postés
4
Date d'inscription
lundi 6 décembre 2021
Statut
Membre
Dernière intervention
26 janvier 2022
-
6 déc. 2021 à 23:52
kaizi Messages postés 4 Date d'inscription lundi 6 décembre 2021 Statut Membre Dernière intervention 26 janvier 2022 - 9 déc. 2021 à 23:42
kaizi Messages postés 4 Date d'inscription lundi 6 décembre 2021 Statut Membre Dernière intervention 26 janvier 2022 - 9 déc. 2021 à 23:42
A voir également:
- Mot de passe des comptes ordinateur
- Voir mot de passe wifi android - Guide
- Mot de passe administrateur - Guide
- Trousseau mot de passe iphone - Guide
- Identifiant et mot de passe - Guide
- Réinitialiser ordinateur sans mot de passe - Guide
6 réponses
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
7 déc. 2021 à 01:09
7 déc. 2021 à 01:09
Bonsoir,
1. Comment vérifiez vous que le mot de passe d'une machine a changé/n'a pas changé ?
2. Il est possible que le changement du mot de passe par la machine ait été désactivé aussi...
Un bel article sur le sujet : https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/machine-account-password-process/ba-p/396026
Attention, ne pas faire de changement en production sur un coup de tête ...
Il faut d'abord faire de la prise d'infos si toutes les machines sont concernées ou non, vérifier le paramétrage en place etc ... donc de l'export des comptes ordinateurs avec du powershell, permet déja de voir l'ampleur du phénomène.
--> pas de test sur un serveur WSUS ... ça serait dommage de foutre en l'air une machine qui déploie des mises à jour.
1. Comment vérifiez vous que le mot de passe d'une machine a changé/n'a pas changé ?
2. Il est possible que le changement du mot de passe par la machine ait été désactivé aussi...
Un bel article sur le sujet : https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/machine-account-password-process/ba-p/396026
Attention, ne pas faire de changement en production sur un coup de tête ...
Il faut d'abord faire de la prise d'infos si toutes les machines sont concernées ou non, vérifier le paramétrage en place etc ... donc de l'export des comptes ordinateurs avec du powershell, permet déja de voir l'ampleur du phénomène.
--> pas de test sur un serveur WSUS ... ça serait dommage de foutre en l'air une machine qui déploie des mises à jour.
kaizi
Messages postés
4
Date d'inscription
lundi 6 décembre 2021
Statut
Membre
Dernière intervention
26 janvier 2022
8 déc. 2021 à 01:11
8 déc. 2021 à 01:11
Bonsoir,
Je m'attendais à ce que ça soit vous qui répondiez mais pas aussi vite :). J'avais essayé de vous joindre par message privé mais sans succès (j'aurai pas mal de questions à vous poser sur l'AD). Pour pouvoir affirmé que la plupart des serveurs ont un mot de passe inchangé depuis plus de 15 ans, je regarde l'attribut pwdlastset de mes comptes machines (module Utilisateurs et ordinateurs Active Directory).
J'ai mis en place une stratégie de mot de passe cette année pour les utilisateurs, aucun ne le changeait et leur mot de passe ne dépassait jamais les 5 caractères. J'ai effectué un bon nombre de changement dans ce SI et avant chaque changement je fais une très grande prise d'information.
Votre article est très intéressant pour comprendre l'ensemble des paramètres qui se trouve dans: Computer Configuration\Administrative Templates\System\Netlogon mais aussi les différents scénario de demande de changement de mot passe des comptes machines.
Effectivement sur tous les serveurs le changement de mot de passe du compte machine est désactivé. Grâce à votre article j'apprends que la default domain policy n'affecte pas les mot de passes des comptes machines, j'ai vérifié les GPO affectées à mon wsus (module gestion des stratégies de groupe) et aucune n'affecte ce serveur, la désactivation a donc dû être faite à la main.
J'ai l'habitude de travailler sur notre wsus car c'est moi qui l'ai mis en place cette année, je sais revenir en arrière s'il faut. Avant sa mise en place on avait des postes sous W10 en version 1809
Après changement de ce paramètre sur le wsus, l'attribut pwdlastset de ce serveur avait la date du jour. Cependant j'ai appris qu'il n'y avait pas de compte admin local sur les serveurs, uniquement le compte Administrateur par défaut de windows. Et le mot de passe n'est pas identique sur les serveurs et d'ailleurs impossible d'avoir celui pour mon wsus, donc il va me falloir du temps pour prendre conscience de tous les problèmes.
Ma question était de savoir s'il existait des raisons bien connues de problème de renouvellement de mot de passe pour les compte machines mais visiblement non. Mais il faut que je m'assure que chaque serveurs puisse être joignable via un compte local ayant les droits d'admin afin de ne pas être bloqué devant un "Mot de passe incorrect"
Je m'attendais à ce que ça soit vous qui répondiez mais pas aussi vite :). J'avais essayé de vous joindre par message privé mais sans succès (j'aurai pas mal de questions à vous poser sur l'AD). Pour pouvoir affirmé que la plupart des serveurs ont un mot de passe inchangé depuis plus de 15 ans, je regarde l'attribut pwdlastset de mes comptes machines (module Utilisateurs et ordinateurs Active Directory).
J'ai mis en place une stratégie de mot de passe cette année pour les utilisateurs, aucun ne le changeait et leur mot de passe ne dépassait jamais les 5 caractères. J'ai effectué un bon nombre de changement dans ce SI et avant chaque changement je fais une très grande prise d'information.
Votre article est très intéressant pour comprendre l'ensemble des paramètres qui se trouve dans: Computer Configuration\Administrative Templates\System\Netlogon mais aussi les différents scénario de demande de changement de mot passe des comptes machines.
Effectivement sur tous les serveurs le changement de mot de passe du compte machine est désactivé. Grâce à votre article j'apprends que la default domain policy n'affecte pas les mot de passes des comptes machines, j'ai vérifié les GPO affectées à mon wsus (module gestion des stratégies de groupe) et aucune n'affecte ce serveur, la désactivation a donc dû être faite à la main.
J'ai l'habitude de travailler sur notre wsus car c'est moi qui l'ai mis en place cette année, je sais revenir en arrière s'il faut. Avant sa mise en place on avait des postes sous W10 en version 1809
Après changement de ce paramètre sur le wsus, l'attribut pwdlastset de ce serveur avait la date du jour. Cependant j'ai appris qu'il n'y avait pas de compte admin local sur les serveurs, uniquement le compte Administrateur par défaut de windows. Et le mot de passe n'est pas identique sur les serveurs et d'ailleurs impossible d'avoir celui pour mon wsus, donc il va me falloir du temps pour prendre conscience de tous les problèmes.
Ma question était de savoir s'il existait des raisons bien connues de problème de renouvellement de mot de passe pour les compte machines mais visiblement non. Mais il faut que je m'assure que chaque serveurs puisse être joignable via un compte local ayant les droits d'admin afin de ne pas être bloqué devant un "Mot de passe incorrect"
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié le 8 déc. 2021 à 14:02
Modifié le 8 déc. 2021 à 14:02
Bonjour,
Je ne regarde pas mes messages privés ; et il est préférable que les échanges soient ouverts à tous.
La recherche des pwdlastset est la bonne méthode.
-
J'ai mis en place une stratégie de mot de passe cette année pour les utilisateurs, aucun ne le changeait et leur mot de passe ne dépassait jamais les 5 caractères
A. Stratégie de mdp : maxpasswordlenght
C'est une très bonne chose. Bon on va pas se le cacher que c'est difficile pour les users de changer leurs mots de passe trop souvent...
Je conseille généralement 15 caractères minimum ; par contre ce n'est pas possible d'aller au dela de 14 via la GPMC... depuis w2016 il est possible de le faire via GPMC au de la de 14, mais les paramètres ne s'appliquent pas sur le domaine (il y a peut etre un patch, mais je n'ai pas cherché plus loin).
Il faut passer par des PSO en ciblant des utilisateurs (ou groupes d'ailleurs) pour indiquer des stratégies de mots de passe au dela de 14 caractères.
pourquoi 15 ? la manière dont est géré le hash de mot de passe par Lanman (LM/NTLM) : se base sur 2 chaines de 7 caractères ou 14 caractères ; et c'est "plus" vulnérable pour des outils de cracking.
En dépassant 14 (donc minimum 15), le Hash du mot de passe est positionné à NULL (mais le mdp n'est pas null pour autant...), ce qui protège des attaques par brute force sur les hash.
https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
Bon après , faut faire valider et accepter ça ... c'est pas simple.
B. Stratégie de mdp : maxpasswordAge
Faites des rotations plus espacées (genre 3 à 6 mois) dans la stratégie de mdp (maxPasswordAge).
Cela évite aux users de noter les mots de passe sur un papier ... et surtout de faire des mots de passe "prévisibles", basés sur le mois de l'année par exemple...
Il vaut mieux un mot de passe robuste non prédictable changé tous les 6 mois, qu'un mot de passe noté sur un papier et prévisible , même s'il est changé tous les mois...
-
Effectivement sur tous les serveurs le changement de mot de passe du compte machine est désactivé
Il faut s'assurer que les machines sont bien stockées dans une OU (Unité d'Organisation) et non dans le conteneur par défaut "computers".
Ce conteneur "computers" ne permet pas de linker des GPOs... alors qu'une OU est fait pour ça.
Il faut donc appliquer une GPO sur une OU contenant les computers, et qui permet de réactiver la rotation des mots de passe des comptes machines. (donc faire une sous OU pour tester sur un lot de machine de préprod par ex...)
Après connaitre la cause, si c'est historique ... ça peut être compliqué de comprendre ce choix technique...
Il faut également remonter sur la partie provisioning/installation des machines et voir si ce paramètre est injecté au départ.
-
Cependant j'ai appris qu'il n'y avait pas de compte admin local sur les serveurs, uniquement le compte Administrateur par défaut de windows. Et le mot de passe n'est pas identique sur les serveurs
Toute machine windows membre d'un domaine a bien des comptes locaux (base SAM) qui lui sont propres, dont le compte "administrator"
Seuls les contrôleurs de domaine sont un cas à part, ils n'ont pas de "comptes locaux", puisqu'ils stockent les comptes de domaine dans la base NTDS.dit (et n'ont plus de base SAM).
C'est une très bonne chose que les comptes admin locaux soient différents pour chaque machine ; cela évite les mouvements latéraux en cas d'attaque.
De même peut etre que LAPS a été mis en place ? sinon c'est à regarder, attention aux prérequis cependant.
-
Ma question était de savoir s'il existait des raisons bien connues de problème de renouvellement de mot de passe pour les compte machines mais visiblement non. Mais il faut que je m'assure que chaque serveurs puisse être joignable via un compte local ayant les droits d'admin afin de ne pas être bloqué devant un "Mot de passe incorrect"
Il y a bien des problématiques autour de la connectivité principalement (firewall qq part) , parfois DNS, où un poste ne sait pas résoudre le nom du domaine avec DNS et donc ne peut contacter le domaine.
Je ne regarde pas mes messages privés ; et il est préférable que les échanges soient ouverts à tous.
La recherche des pwdlastset est la bonne méthode.
-
J'ai mis en place une stratégie de mot de passe cette année pour les utilisateurs, aucun ne le changeait et leur mot de passe ne dépassait jamais les 5 caractères
A. Stratégie de mdp : maxpasswordlenght
C'est une très bonne chose. Bon on va pas se le cacher que c'est difficile pour les users de changer leurs mots de passe trop souvent...
Je conseille généralement 15 caractères minimum ; par contre ce n'est pas possible d'aller au dela de 14 via la GPMC... depuis w2016 il est possible de le faire via GPMC au de la de 14, mais les paramètres ne s'appliquent pas sur le domaine (il y a peut etre un patch, mais je n'ai pas cherché plus loin).
Il faut passer par des PSO en ciblant des utilisateurs (ou groupes d'ailleurs) pour indiquer des stratégies de mots de passe au dela de 14 caractères.
pourquoi 15 ? la manière dont est géré le hash de mot de passe par Lanman (LM/NTLM) : se base sur 2 chaines de 7 caractères ou 14 caractères ; et c'est "plus" vulnérable pour des outils de cracking.
En dépassant 14 (donc minimum 15), le Hash du mot de passe est positionné à NULL (mais le mdp n'est pas null pour autant...), ce qui protège des attaques par brute force sur les hash.
https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=762c7cbd-bc00-44b1-8d35-cf42bc7fe2e9&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments
Bon après , faut faire valider et accepter ça ... c'est pas simple.
B. Stratégie de mdp : maxpasswordAge
Faites des rotations plus espacées (genre 3 à 6 mois) dans la stratégie de mdp (maxPasswordAge).
Cela évite aux users de noter les mots de passe sur un papier ... et surtout de faire des mots de passe "prévisibles", basés sur le mois de l'année par exemple...
Il vaut mieux un mot de passe robuste non prédictable changé tous les 6 mois, qu'un mot de passe noté sur un papier et prévisible , même s'il est changé tous les mois...
-
Effectivement sur tous les serveurs le changement de mot de passe du compte machine est désactivé
Il faut s'assurer que les machines sont bien stockées dans une OU (Unité d'Organisation) et non dans le conteneur par défaut "computers".
Ce conteneur "computers" ne permet pas de linker des GPOs... alors qu'une OU est fait pour ça.
Il faut donc appliquer une GPO sur une OU contenant les computers, et qui permet de réactiver la rotation des mots de passe des comptes machines. (donc faire une sous OU pour tester sur un lot de machine de préprod par ex...)
Après connaitre la cause, si c'est historique ... ça peut être compliqué de comprendre ce choix technique...
Il faut également remonter sur la partie provisioning/installation des machines et voir si ce paramètre est injecté au départ.
-
Cependant j'ai appris qu'il n'y avait pas de compte admin local sur les serveurs, uniquement le compte Administrateur par défaut de windows. Et le mot de passe n'est pas identique sur les serveurs
Toute machine windows membre d'un domaine a bien des comptes locaux (base SAM) qui lui sont propres, dont le compte "administrator"
Seuls les contrôleurs de domaine sont un cas à part, ils n'ont pas de "comptes locaux", puisqu'ils stockent les comptes de domaine dans la base NTDS.dit (et n'ont plus de base SAM).
C'est une très bonne chose que les comptes admin locaux soient différents pour chaque machine ; cela évite les mouvements latéraux en cas d'attaque.
De même peut etre que LAPS a été mis en place ? sinon c'est à regarder, attention aux prérequis cependant.
-
Ma question était de savoir s'il existait des raisons bien connues de problème de renouvellement de mot de passe pour les compte machines mais visiblement non. Mais il faut que je m'assure que chaque serveurs puisse être joignable via un compte local ayant les droits d'admin afin de ne pas être bloqué devant un "Mot de passe incorrect"
Il y a bien des problématiques autour de la connectivité principalement (firewall qq part) , parfois DNS, où un poste ne sait pas résoudre le nom du domaine avec DNS et donc ne peut contacter le domaine.
kaizi
Messages postés
4
Date d'inscription
lundi 6 décembre 2021
Statut
Membre
Dernière intervention
26 janvier 2022
9 déc. 2021 à 19:08
9 déc. 2021 à 19:08
Bonjour,
Je ne regarde pas mes messages privés ; et il est préférable que les échanges soient ouverts à tous.
Je comprends, il s'agit de petites questions techniques qu'il me reste après m'être documenté sur des objets comme l'adminSDHolder, les protocoles NTFRS et FDSR pour la réplication du sysvol, compte krbtgt etc..., surtout quand j'ai des sources qui se contredisent. Ça m'embête un peu d'ouvrir un nouveau topic juste pour des petites questions comme ça.
-
Il faut passer par des PSO en ciblant des utilisateurs (ou groupes d'ailleurs) pour indiquer des stratégies de mots de passe au dela de 14 caractères.
C'est ce que j'ai utilisé pour mes renouvellements de mot de passe pour les utilisateurs. Le nombre de caractères minimum est de 8 et une durée de vie de 6 mois. Avec maintien en mémoire les 3 derniers mots de passe pour ne pas reprendre un trop ancien, et avec les règles de complexités que propose le gestionnaire AD. Il a déjà fallu être combattif pour imposer ces conditions et je n'imagine pas nos utilisateurs retenir un mot de passe de 15 caractères ou plus.
pourquoi 15 ? la manière dont est géré le hash de mot de passe par Lanman (LM/NTLM) : se base sur 2 chaines de 7 caractères ou 14 caractères ; et c'est "plus" vulnérable pour des outils de cracking.
En dépassant 14 (donc minimum 15), le Hash du mot de passe est positionné à NULL (mais le mdp n'est pas null pour autant...), ce qui protège des attaques par brute force sur les hash.
C'est très intéressant, je pensais que toute authentification dans un domaine ou pour accéder à un domaine se faisait via le protocole kerberos. Mais apparemment c'est le protocole NTLM qui est utilisé pour les services sur comptes locaux ou accès à une machine via son ip.
-
Il faut s'assurer que les machines sont bien stockées dans une OU (Unité d'Organisation) et non dans le conteneur par défaut "computers".
Ce conteneur "computers" ne permet pas de linker des GPOs... alors qu'une OU est fait pour ça.
Elles le sont bien toutes, et j'ai utilisé la commande "redircmp" pour qu'à l'arrivé de machine client ou serveur dans le domaine ces derniers soit placés dans une OU (afin qu'une GPO puisse s'y appliquer).
-
C'est une très bonne chose que les comptes admin locaux soient différents pour chaque machine ; cela évite les mouvements latéraux en cas d'attaque.
De même peut etre que LAPS a été mis en place ? sinon c'est à regarder, attention aux prérequis cependant.
Quelques mois après mon arrivé j'ai découvert cet outil (LAPS) et fait des recherches dessus pour le présenter à mon service mais ça a été refusé malgré ce qu'il aurait pu apporter. J'ai aussi présenté le groupe protected user et proposé une stratégie de mot de passe plus exigeante pour les comptes IT mais sans succès.
-
Seuls les contrôleurs de domaine sont un cas à part, ils n'ont pas de "comptes locaux", puisqu'ils stockent les comptes de domaine dans la base NTDS.dit (et n'ont plus de base SAM).
...
Il y a bien des problématiques autour de la connectivité principalement (firewall qq part), parfois DNS, où un poste ne sait pas résoudre le nom du domaine avec DNS et donc ne peut contacter le domaine.
C'est ce dont je me suis rendu compte hier après-midi, il faudrait donc créer nous-mêmes des comptes admin locaux pour accéder à ces DC en cas de problème de résolution de nom de domaine.
Je vous remercie pour votre réponse et votre suivi, comme je disait en début de discussion avant chaque changement je prends bien le temps de me renseigner sur ce que je fais et les impact que cela aura, même si évidemment on ne peut pas tout prévoir.
Je ne regarde pas mes messages privés ; et il est préférable que les échanges soient ouverts à tous.
Je comprends, il s'agit de petites questions techniques qu'il me reste après m'être documenté sur des objets comme l'adminSDHolder, les protocoles NTFRS et FDSR pour la réplication du sysvol, compte krbtgt etc..., surtout quand j'ai des sources qui se contredisent. Ça m'embête un peu d'ouvrir un nouveau topic juste pour des petites questions comme ça.
-
Il faut passer par des PSO en ciblant des utilisateurs (ou groupes d'ailleurs) pour indiquer des stratégies de mots de passe au dela de 14 caractères.
C'est ce que j'ai utilisé pour mes renouvellements de mot de passe pour les utilisateurs. Le nombre de caractères minimum est de 8 et une durée de vie de 6 mois. Avec maintien en mémoire les 3 derniers mots de passe pour ne pas reprendre un trop ancien, et avec les règles de complexités que propose le gestionnaire AD. Il a déjà fallu être combattif pour imposer ces conditions et je n'imagine pas nos utilisateurs retenir un mot de passe de 15 caractères ou plus.
pourquoi 15 ? la manière dont est géré le hash de mot de passe par Lanman (LM/NTLM) : se base sur 2 chaines de 7 caractères ou 14 caractères ; et c'est "plus" vulnérable pour des outils de cracking.
En dépassant 14 (donc minimum 15), le Hash du mot de passe est positionné à NULL (mais le mdp n'est pas null pour autant...), ce qui protège des attaques par brute force sur les hash.
C'est très intéressant, je pensais que toute authentification dans un domaine ou pour accéder à un domaine se faisait via le protocole kerberos. Mais apparemment c'est le protocole NTLM qui est utilisé pour les services sur comptes locaux ou accès à une machine via son ip.
-
Il faut s'assurer que les machines sont bien stockées dans une OU (Unité d'Organisation) et non dans le conteneur par défaut "computers".
Ce conteneur "computers" ne permet pas de linker des GPOs... alors qu'une OU est fait pour ça.
Elles le sont bien toutes, et j'ai utilisé la commande "redircmp" pour qu'à l'arrivé de machine client ou serveur dans le domaine ces derniers soit placés dans une OU (afin qu'une GPO puisse s'y appliquer).
-
C'est une très bonne chose que les comptes admin locaux soient différents pour chaque machine ; cela évite les mouvements latéraux en cas d'attaque.
De même peut etre que LAPS a été mis en place ? sinon c'est à regarder, attention aux prérequis cependant.
Quelques mois après mon arrivé j'ai découvert cet outil (LAPS) et fait des recherches dessus pour le présenter à mon service mais ça a été refusé malgré ce qu'il aurait pu apporter. J'ai aussi présenté le groupe protected user et proposé une stratégie de mot de passe plus exigeante pour les comptes IT mais sans succès.
-
Seuls les contrôleurs de domaine sont un cas à part, ils n'ont pas de "comptes locaux", puisqu'ils stockent les comptes de domaine dans la base NTDS.dit (et n'ont plus de base SAM).
...
Il y a bien des problématiques autour de la connectivité principalement (firewall qq part), parfois DNS, où un poste ne sait pas résoudre le nom du domaine avec DNS et donc ne peut contacter le domaine.
C'est ce dont je me suis rendu compte hier après-midi, il faudrait donc créer nous-mêmes des comptes admin locaux pour accéder à ces DC en cas de problème de résolution de nom de domaine.
Je vous remercie pour votre réponse et votre suivi, comme je disait en début de discussion avant chaque changement je prends bien le temps de me renseigner sur ce que je fais et les impact que cela aura, même si évidemment on ne peut pas tout prévoir.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
9 déc. 2021 à 21:35
9 déc. 2021 à 21:35
Hello,
C'est ce dont je me suis rendu compte hier après-midi, il faudrait donc créer nous-mêmes des comptes admin locaux pour accéder à ces DC en cas de problème de résolution de nom de domaine.
Un compte local n'existe pas sur un DC, puisque c'est la base NTDS.dit qui remplace la base SAM.
Un DC pourra authentifier sans problème car il contient la base de tous les comptes du domaines.
De plus il contient aussi les partitions DNS, donc il y a peu de risques qu'il perde la résolution DNS.
(après il y a certaines contraintes qd même)
Cependant ces cas peuvent arriver, par exemple si les services AD ne démarrent pas, ou si le DNS est porté par une infra tierce et qu'il y a un souci réseau ou de résolution DNS - et on ne pourrait pas ouvrir localement une session sur le DC isolé...
Mais pas de souci ! Il y un compte dit "DSRM" qui se paramètre lors de l'installation de chaque DC.
C'est ce compte là qu'il faut utiliser en cas de gros pépins en bootant sur le mode "Directory Services Restore Mode"...
C'est ce dont je me suis rendu compte hier après-midi, il faudrait donc créer nous-mêmes des comptes admin locaux pour accéder à ces DC en cas de problème de résolution de nom de domaine.
Un compte local n'existe pas sur un DC, puisque c'est la base NTDS.dit qui remplace la base SAM.
Un DC pourra authentifier sans problème car il contient la base de tous les comptes du domaines.
De plus il contient aussi les partitions DNS, donc il y a peu de risques qu'il perde la résolution DNS.
(après il y a certaines contraintes qd même)
Cependant ces cas peuvent arriver, par exemple si les services AD ne démarrent pas, ou si le DNS est porté par une infra tierce et qu'il y a un souci réseau ou de résolution DNS - et on ne pourrait pas ouvrir localement une session sur le DC isolé...
Mais pas de souci ! Il y un compte dit "DSRM" qui se paramètre lors de l'installation de chaque DC.
C'est ce compte là qu'il faut utiliser en cas de gros pépins en bootant sur le mode "Directory Services Restore Mode"...
kaizi
Messages postés
4
Date d'inscription
lundi 6 décembre 2021
Statut
Membre
Dernière intervention
26 janvier 2022
9 déc. 2021 à 23:42
9 déc. 2021 à 23:42
Je vous remercie pour toutes ces précisions.