[INFO]Méthodes pour redéfinir les mot de passe sur un serveur de domaine (alors qu'on a perdu tout pwd admin)

Le
Jean-Claude BELLAMY
Hello World !

Je viens d'écrire un nouveau paragraphe sur mon site, consacré à la façon de
redéfinir n'importe quel mot de passe (y compris et surtout celui d'un
administrateur) sur un serveur de domaine, alors qu'on a perdu tous les mots
de passe.

La méthode de Petter NORDHAL (avec la disquette ou le CD Linux) ne concerne
que les comptes LOCAUX (infos stockées dans le fichier SAM), et ne peut pas
s'appliquer sur les comptes de domaines (infos stockées dans la base Active
Directory).
Par contre, elle va servir à mettre en place un outil qui lui va pouvoir
redéfinir le mot de passe d'un administrateur du domaine!

http://www.bellamyjc.org/fr/pwdnt.html#domaine

Je décris 2 méthodes :

- une applicable sous W2k SRV et W2K3, assez complexe
Elle est fortement inspirée de celle de Daniel PETRI
(MVP Windows Server System - Exchange Server)
http://www.petri.co.il/reset_domain_admin_password_in_windows_server_2003_ad.htm
Je l'ai rendue AUTOMATIQUE à l'aide de scripts VBS et BAT
de ma conception.

- une applicable seulement sous W2K SRV, très simple
Elle ne nécessite rien de plus.
Mais elle ne fonctionne pas sous W2K3 à cause des
sécurités renforcées de cet OS.


Je rappelle que ce n'est en aucune façon une incitation à l'utilisation
frauduleuse d'ordinateur, mais seulement la description de méthodes
permettant à un administrateur authentique de recouvrer la maitrise d'une
machine après l'oubli de son mot de passe.

Toutefois cela met en évidence la vulnérabilité d'un poste de travail ou
serveur sous Windows (NT, 2000, XP, 2003).
Donc, dans le cas où un ordinateur présente un caractère "sensible", il faut
avant toute chose le protéger physiquement :
- en l'enfermant dans un local protégé
- en définissant un mot de passe suffisamment solide pour la configuration
du BIOS
- en désactivant le lecteur de disquette et de CDROM au niveau du BIOS

Vous pouvez dormir tranquilles à présent ! ;-)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
-
Jean-Claude BELLAMY [MVP] - Jean-Claude.Bellamy@wanadoo.fr
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Stéphane [MS]
Le #468590
Bonjour,

Sans vouloir diminuer le travail de Jean-Claude, je complèterais que pour
éviter que ces techniques ne fonctionnent, il suffit d'utiliser la commande
SysKey dans l'un des modes où la clé n'est pas stockée sur le serveur. A ma
connaissance (La Connaissance s'accroît quand on la partage, n'est-ce pas),
il n'existe pas, aujourd'hui, de moyen d'outrepasser cette protection, sauf à
utiliser des moyens immenses (comme ceux de la NSA) et beaucoup de temps
(plusieurs jours, au minimum). Les contreparties de SysKey sont relativement
lourds et ne doivent être utilisés que pour protéger des données sensibles.

Cf.
http://agent.microsoft.com/technet/prodtechnol/windowsserver2003/fr/library/ServerHelp/ac4945c0-3d7c-4a29-98cb-f80278a7e14c.mspx

Cdlt
Stéphane



Hello World !

Je viens d'écrire un nouveau paragraphe sur mon site, consacré à la façon de
redéfinir n'importe quel mot de passe (y compris et surtout celui d'un
administrateur) sur un serveur de domaine, alors qu'on a perdu tous les mots
de passe.

La méthode de Petter NORDHAL (avec la disquette ou le CD Linux) ne concerne
que les comptes LOCAUX (infos stockées dans le fichier SAM), et ne peut pas
s'appliquer sur les comptes de domaines (infos stockées dans la base Active
Directory).
Par contre, elle va servir à mettre en place un outil qui lui va pouvoir
redéfinir le mot de passe d'un administrateur du domaine!

http://www.bellamyjc.org/fr/pwdnt.html#domaine

Je décris 2 méthodes :

- une applicable sous W2k SRV et W2K3, assez complexe
Elle est fortement inspirée de celle de Daniel PETRI
(MVP Windows Server System - Exchange Server)
http://www.petri.co.il/reset_domain_admin_password_in_windows_server_2003_ad.htm
Je l'ai rendue AUTOMATIQUE à l'aide de scripts VBS et BAT
de ma conception.

- une applicable seulement sous W2K SRV, très simple
Elle ne nécessite rien de plus.
Mais elle ne fonctionne pas sous W2K3 à cause des
sécurités renforcées de cet OS.


Je rappelle que ce n'est en aucune façon une incitation à l'utilisation
frauduleuse d'ordinateur, mais seulement la description de méthodes
permettant à un administrateur authentique de recouvrer la maitrise d'une
machine après l'oubli de son mot de passe.

Toutefois cela met en évidence la vulnérabilité d'un poste de travail ou
serveur sous Windows (NT, 2000, XP, 2003).
Donc, dans le cas où un ordinateur présente un caractère "sensible", il faut
avant toute chose le protéger physiquement :
- en l'enfermant dans un local protégé
- en définissant un mot de passe suffisamment solide pour la configuration
du BIOS
- en désactivant le lecteur de disquette et de CDROM au niveau du BIOS

Vous pouvez dormir tranquilles à présent ! ;-)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr





Jonathan Bismuth
Le #1057304
Moi, je dis bravo jean Claude :)

Pour ceux qui ne veulent pas passer par un automate (mais pourquoi donc???),
la version originale traduite est toujours dispo chez moi :
http://jonathan.bismuth.free.fr/Secu/Reset-Adm-Pass/index.htm

Bravo à Jean Claude pour cet outil qui, mine de rien, fait gagner pas mal de
temps!

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Jean-Claude BELLAMY" message de news:
Hello World !

Je viens d'écrire un nouveau paragraphe sur mon site, consacré à la façon
de redéfinir n'importe quel mot de passe (y compris et surtout celui d'un
administrateur) sur un serveur de domaine, alors qu'on a perdu tous les
mots de passe.

La méthode de Petter NORDHAL (avec la disquette ou le CD Linux) ne
concerne que les comptes LOCAUX (infos stockées dans le fichier SAM), et
ne peut pas s'appliquer sur les comptes de domaines (infos stockées dans
la base Active Directory).
Par contre, elle va servir à mettre en place un outil qui lui va pouvoir
redéfinir le mot de passe d'un administrateur du domaine!

http://www.bellamyjc.org/fr/pwdnt.html#domaine

Je décris 2 méthodes :

- une applicable sous W2k SRV et W2K3, assez complexe
Elle est fortement inspirée de celle de Daniel PETRI
(MVP Windows Server System - Exchange Server)

http://www.petri.co.il/reset_domain_admin_password_in_windows_server_2003_ad.htm
Je l'ai rendue AUTOMATIQUE à l'aide de scripts VBS et BAT
de ma conception.

- une applicable seulement sous W2K SRV, très simple
Elle ne nécessite rien de plus.
Mais elle ne fonctionne pas sous W2K3 à cause des
sécurités renforcées de cet OS.


Je rappelle que ce n'est en aucune façon une incitation à l'utilisation
frauduleuse d'ordinateur, mais seulement la description de méthodes
permettant à un administrateur authentique de recouvrer la maitrise d'une
machine après l'oubli de son mot de passe.

Toutefois cela met en évidence la vulnérabilité d'un poste de travail ou
serveur sous Windows (NT, 2000, XP, 2003).
Donc, dans le cas où un ordinateur présente un caractère "sensible", il
faut avant toute chose le protéger physiquement :
- en l'enfermant dans un local protégé
- en définissant un mot de passe suffisamment solide pour la configuration
du BIOS
- en désactivant le lecteur de disquette et de CDROM au niveau du BIOS

Vous pouvez dormir tranquilles à présent ! ;-)


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr



Jean-Claude BELLAMY
Le #468588
Dans le message :,
Stéphane [MS] suit :
Bonjour,

Sans vouloir diminuer le travail de Jean-Claude,
Mais si, avoue-le, tu veux me néantiser !

Je devine bien ta manoeuvre sournoise de dénigrement systématique ...
;-) ;-) ;-)

je complèterais que
pour éviter que ces techniques ne fonctionnent, il suffit d'utiliser
la commande SysKey dans l'un des modes où la clé n'est pas stockée
sur le serveur.
Exact !


A ma connaissance (La Connaissance s'accroît quand on
la partage, n'est-ce pas), il n'existe pas, aujourd'hui, de moyen
d'outrepasser cette protection, sauf à utiliser des moyens immenses
(comme ceux de la NSA) et beaucoup de temps (plusieurs jours, au
minimum). Les contreparties de SysKey sont relativement lourds et ne
doivent être utilisés que pour protéger des données sensibles.


En particulier, un gros pb de SYSKEY, c'est que même sous W2K3 SP1, les
seuls choix disponibles pour stocker la clef supplémentaire sont :
- le DD de l'ordinateur
- la disquette (3"1/2), et avec la lettre "A:" obligatoirement (j'ai testé!)
Rien d'autre !

En particulier, aucune possibilité d'utiliser une carte à puce ou une simple
clef USB ...
Or c'est de plus en plus fréquent les PC sans disquette.

J'ai alors essayé sur mon serveur W2K3 un lecteur de disquette amovible
connecté à un port USB.
J'ai du commencer par bidouiller dans le gestionnaire de disque pour lui
affecter la lettre A:

Car une fois qu'on a lancé SYSKEY en choisissant la disquette, il exige une
disquette en A:, et n'en démord pas, aucun moyen d'annuler sauf tuer le
processus !

Et attention, si on décide IMMÉDIATEMENT (donc dans la MÊME session admin)
de revenir en arrière, en demandant le stockage de la clef en interne sur le
DD, il faut absolument fournir la disquette ! J'ai failli me sentir mal !
;-)


Quand on connait la fiabilité relative des disquettes, c'est assez osé comme
solution !
Si on a perdu la disquette, ou si elle est illisible, le seul moyen de s'en
sortir est de disposer d'une copie des ruches de la BDR AVANT syskey, puis
de les recopier à la place des ruches existantes à l'aide de la console de
récupération.
Il faut donc avoir bien configuré les startégies de sécurité de la CDR au
préalable.
-> montée d'adrénaline garantie ! ;-)

Par ailleurs, pour une question de sécurité, il est recommandé sur des
machines "sensibles" de désactiver voire retirer le lecteur de disquette.
L'utilisation de SYSKEY en mode "Le plus sûr" est donc contradictoire avec
cette disposition!


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr

Do Re Mi chel La Si Do
Le #521845
Bonjour !


Sans vouloir diminuer la valeur de votre message, je réalise que je suis
beaucoup plus souvent confronté (chez des clients) à des problèmes d'accès
"légal", qu'à des problèmes d'intrusion.

Donc, j'aimerais mieux lire des articles, de Microsoft, donnant les moyens
d'éviter ces problèmes, plutôt que des articles qui entretiennent une
paranoïa latente, en omettant de signaler les risques encourus.

Car, finalement, des utilisateurs qui n'ont plus accès à leurs postes, ou à
leurs données, ont un gros problème de sécurité. Même si ce problème de
sécurité est dû à l'application de règles trop strictes.


Je suis conscient que MS cherche, d'abord, à ne pas offrir le flanc à la
critique. Mais il faudrait au moins prévenir les lecteurs des limites
d'utilisation de ces règles.
Il faut savoir que de nombreux utilisateurs (ou administrateurs), appliquent
au pied de la lettre, et sans réfléchir, les recommandations indiquées dans
des articles comme celui cité.

Avec des résultats affolants.

J'ai un exemple, récent. Je suis intervenu, dans une administration où des
départements entiers n'avaient plus accès aux ordinateurs de la région,
parce que les programmes "non approuvés" avaient été bloqués. Et, parmi ces
programmes non approuvés, il y avait des logiciels de réplication de bases
de données. Ces logiciels résultaient d'un développement spécifique, sous
maîtrise d'ouvrage de la région, mais inconnu du ministère, et donc, "non
approuvés".
Le dit ministère s'appuyait sur les "conseils de Microsoft" (je cite), pour
rédiger des directives d'application obligatoire. Et le représentant du
ministère n'a jamais rien voulu savoir, son rôle étant de faire appliquer
les directives, et pas de faire remonter une information (à chaque
proposition, le réponse était : "les directives du ministère interdisent
cela").

Résultat : des milliers de dossiers, bloqués pendant plusieurs mois, et
plusieurs millions d'euros qui ont "dormi", inutilement, sur des comptes
intermédiaires.


En ce sens, je pense que les informations fournies par JCB seront plus
souvent utiles, que des informations "bloquantes à terme".


@-salutations

Michel Claveau
Stéphane [MS]
Le #468587

Dans le message :,
Stéphane [MS] suit :
Bonjour,

Sans vouloir diminuer le travail de Jean-Claude,
Mais si, avoue-le, tu veux me néantiser !

Je devine bien ta manoeuvre sournoise de dénigrement systématique ...
;-) ;-) ;-)
Et zut ! Encore raté :-)


Merci pour ce partage d'expérience !


En échange, mon retour est le suivant : j'utilise SysKey avec un mot clé au
démarrage sur mes portables ; ce qui tend à me rassurer en cas de vol....
Pour ce qui est de l'utiliser sur des serveurs, comme je l'écrivais (avec des
fautes d'orthographe, honte à moi !), je serais plus mitigé.

Stéphane


Stéphane [MS]
Le #521841
Il est évident que les produits Microsoft sont de plus en plus compliqués à
mettre en oeuvre, en particulier, compte tenu que les composants nécessaires
au fonctionnement ne sont plus actifs, par défaut. Il faut, aujourd'hui,
connaître les liens de dépendance quand, tout "tombait en marche" par le
passé.

Les présentations actuelles de Microsoft sur l'initiative DSI affichent le
besoin impératif de retour des utilisateurs vers les équipes d'exploitation
et les développeurs. Votre propos le démontre.
cf. (en anglais)
http://www.microsoft.com/windowsserversystem/dsi/dsioverview.mspx

Dans le même genre que l'utilisation de SysKey avec une disquette, je trouve
dangereux d'avoir laissé la possibilité de crypter des fichiers à n'importe
quel utilisateur sans avoir fourni toutes les informations nécessaires pour
en mesurer les risques.

Cdlt
Stéphane



Bonjour !


Sans vouloir diminuer la valeur de votre message, je réalise que je suis
beaucoup plus souvent confronté (chez des clients) à des problèmes d'accès
"légal", qu'à des problèmes d'intrusion.

Donc, j'aimerais mieux lire des articles, de Microsoft, donnant les moyens
d'éviter ces problèmes, plutôt que des articles qui entretiennent une
paranoïa latente, en omettant de signaler les risques encourus.

Car, finalement, des utilisateurs qui n'ont plus accès à leurs postes, ou à
leurs données, ont un gros problème de sécurité. Même si ce problème de
sécurité est dû à l'application de règles trop strictes.


Je suis conscient que MS cherche, d'abord, à ne pas offrir le flanc à la
critique. Mais il faudrait au moins prévenir les lecteurs des limites
d'utilisation de ces règles.
Il faut savoir que de nombreux utilisateurs (ou administrateurs), appliquent
au pied de la lettre, et sans réfléchir, les recommandations indiquées dans
des articles comme celui cité.

Avec des résultats affolants.

J'ai un exemple, récent. Je suis intervenu, dans une administration où des
départements entiers n'avaient plus accès aux ordinateurs de la région,
parce que les programmes "non approuvés" avaient été bloqués. Et, parmi ces
programmes non approuvés, il y avait des logiciels de réplication de bases
de données. Ces logiciels résultaient d'un développement spécifique, sous
maîtrise d'ouvrage de la région, mais inconnu du ministère, et donc, "non
approuvés".
Le dit ministère s'appuyait sur les "conseils de Microsoft" (je cite), pour
rédiger des directives d'application obligatoire. Et le représentant du
ministère n'a jamais rien voulu savoir, son rôle étant de faire appliquer
les directives, et pas de faire remonter une information (à chaque
proposition, le réponse était : "les directives du ministère interdisent
cela").

Résultat : des milliers de dossiers, bloqués pendant plusieurs mois, et
plusieurs millions d'euros qui ont "dormi", inutilement, sur des comptes
intermédiaires.


En ce sens, je pense que les informations fournies par JCB seront plus
souvent utiles, que des informations "bloquantes à terme".


@-salutations

Michel Claveau







Do Re Mi chel La Si Do
Le #521591
Bonsoir !


Oui, j'avais aussi oublié les risques liés au cryptage.
Merci de (me) l'avoir rappelé.

Pour le renvoi des utilisateurs vers les services informatiques, je pense
qu'il faudrait, parallèlement, faire évoluer le niveau de ces derniers, et
changer leur mode de fonctionnement, qui les poussent à utiliser des
principes tout faits, glanés ici ou là. Cela se produit d'autant plus
souvent que le service informatique est important.

C'est une autre forme de "lazy evaluation" ;-)


@-salutations

Michel Claveau
Poster une réponse
Anonyme