Bonjour,
 
Simple question : J'ai 4-5 clients qui viennent de me prévenir que suite au redémarrage de leur serveur (cause KB), leur compte administrateur semble <locked>. En effet, avec la combinaison user/password habituelle cela ne fonctionne pas.  
 
J'ai essayé à distance de prendre la main sur des postes clients de leur réseau et j'accède à la base de registre à distance du serveur (sauf la partie qui m'intéresse [HKLM] où j'ai un access denied). J'ai également essayé de faire des modifs avec pstools mais bon, access denied too.
 
Les serveurs sont en workgroup donc c'est pas trop gênant, les clients accèdent toujours aux db, etc,... mais bon, 4-5 clients d'un coup ayant le même problème, c'est bizarre.
 
Les informaticiens locaux ont essayé avec "recovery nt password" (boot linux) de modifier les password, ils y arrivent avec un message notifiant qu'ils ont bien écrit dans la base de registre SAM l'information mais au redémarrage, cela ne fonctionne toujours pas.
 
Auriez-vous vu des problèmes de ce même type récemment ? une KB ? quelque chose ?
 
Merci.

Domaine ou Workgroup ?nt password ne fonctionnant qu'en local ...
Perso à jour sur quasiment les versions Windows  2003 /2008 .. Heureusement aucun soucis a signaler ... Ca me surprend que plusieurs clients aient ce soucis ...

Workgroup chez les clients (petite structure).
J'ai fais la même manip sur un de nos serveurs et cela a bien fonctionné pour reset le password.
Je suis assez surpris que plusieurs clients aient ce soucis également, je ne sais quoi faire pour résoudre le problème.

Petite idée : J'ai toujours accès aux ressources partagées <$> sur les serveurs en question.  
 
Est-il envisageable de lancer un batch via pstools (net user administrateur * / toto / toto) ou autre script afin de modifier localement le password local ? à distance évidemment.

Je n'y arrive pas "Access denied" lorsque je souhaite lancer le batch à distance , je m'en remets donc aux experts.  
Bonne journée

normal, ce que tu as essayé d'inventer c'est un root-kit
 
par contre le verrouillage du compte administrateur est normal si tu as paramétré le verrouillage à "x" essais... mais il aurait dû se déverrouiller avec les bons paramètres !
 
et sans savoir de quel KB, impossible de remonter à la source de l'erreur

C'est tout con mais bon pas de bol, j'avais pas les droits sur le répertoire!
 
Là, je confirme qu'il y a bien eu un changement du mot de passe administrateur local chez 5 clients d'une manière inconnue et je ne sais même pas quoi faire pour agir sur le problème.
 
A supposer que cela vient d'une KB hein je fais confiance à moitié au client .
 
J'aurai bien aimé lancer une invite de commandes via pstools sur le serveur avec un vieux : net user administrateur toto et vas-y.

ils ont quoi comme antivirus ?

à moitié, c'est déjà trop : ne jamais faire confiance
 
encore plus si tu as sur place des "informaticiens", suivant les cas, tu en tombes (sur des cas ).
 
certains ne vont jamais te dire par exemple "oh ben j'ai voulu changer le mot de passe admin pour renforcer notre sécurité, malgré notre contrat de maintenance avec vous". meuh bien sûr, et la meuh-meuh elle emballe le chocolat dans le papier d'alu  
 
au pire, si tu arrives à prendre la main dessus, paf tu leur colles un second compte administrateur avec mot de passe.

Aïe [Touched]
Et ne répond pas Mc Afee    
 

Trend Micro.  
J'ai l'impression que tous les serveurs ont été basculé en DC ce qui expliquerait l'inutilité des resets des comptes locaux (avec NT PASSWORD) qui n'existent plus sur l'AD.
Toujours en galère.

Oui enfin tu "bascules" pas en DC comme ça ...
Mon avis c'est que ca n'a rien a voir avec une quelconque Kb, le plus soucieux reste que ca touche plusieurs de tes clients apparement ... Donc qu"un de tes sites partent en vrille .. ca passe .. mais que plusieurs simultanément .. ca me parait plus improbable ...
Tu as un moyen de prise en mains ?

Oui tout à fait, c'est ce que je fais.
RDP ouvert que depuis mon IP publique.

Donc si tu as accés en Rdp tu dois avoir le choix du domaine ou du local ...
Si tu as le domaine ... c'est que tu n'es plus en workgroup ...
C'est du 2003 ou 2008 ?

Justement, maintenant j'ai uniquement un seul choix avec "se connecter à : XXXXXX" donc bien sur un domaine et je n'ai plus l'option pour démarrer en local.
 
Et ce sur les 5 sites.

Tu devrais te rapprocher des locaux du coup ... Tu ne passes pas en domaine comme ça ...
Le nom de domaine est explicite ?

En effet, c'est le même nom que l'on donne aux groupes de travail. On va rapatrier un serveur chez nous voir si on peut modifier quelques choses car je suis largué là.
 
Niveaux tests à distance je suis assez limité et je pense avoir fait le tour.  

Solution trouvée mais hardcore !

Annonce

roule, ça m'intéresse aussi

Crack des comptes de l'AD et décryptage des password hash : surtout celui de l'admin.   ! <pas très correct donc je vais éviter de décrire les softs ici je pense>

Oaip c'est ce que je qualifie de verrue .. Tu n'as, finalement, aucune idée de l'origine du problème .... Ce qui n'est jamais bon signe.
Tes 5 clients ont eu le même problème ?

De ce que je vois, il y a une modification "humaine" dans les stratégies qui refusent les ouvertures de sessions locales car après avoir crack les comptes de l'AD, j'ai eu des messages d'erreurs différents lors de mes tests d'ouvertures de session. Un autre compte administrateur avait été créé complètement différent de celui initial.
 
Sinon oui, le même problème.

Nan mais au départ tu n'avais pas d'AD ...
Que sur un site tu aies un admin rigolo qui effectue un dcpromo, je veux bien mais sur 5 sites ...

Nan mais au départ tu n'avais pas d'AD ...

En effet, je n'avais pas d'AD au départ sauf pour un de ces sites.
Maintenant, je me retrouve avec 5 serveurs DC.
Je crois qu'on a affaire à un rigolo chez nous qui fait mumuse en TSE.

C'est bon, tout le monde connait ntpasswd (et pour les autres, ben voilà!) - ou un outil de backtrack?
De toute manière il faut booter dessus pour avoir acces à la base SAM.
La 1ere sécurité, c'est d'isoler physiquement tes serveurs.

Euh, tu dis n'importe quoi... Tu m'expliqueras comment crack un AD avec un logiciel permettant de récupérer des comptes locaux sur la base SAM hein !
 
@ton triple edit ( ) : Oui.

...en effet, j'ai pas du voir "compte AD" dans ce que tu as écrit

Comprends bien que si j'étais sur place et que j'accédais à un quelconque compte j'aurai pas pris la peine de poste ici.
Puis, sur un DC dans un environnement AD, les comptes locaux ? gné
Bref, oui, il y a eu déclaration du serveur en DC, un disable dans les stratégies des connexions locales au serveur ... d'où le crack dump AD.