Bonjour,
 
On est confronté a un probleme un peu particulier.
 
 
En début de semaine, une utilisatrice d'un domaine enfant nous appelle pour nous dire qu'elle n'arrive plus a se logguer.
En effet, la relation d'approbation entre la station et le domaine a échoué. Bref, du cou le poste ne peut plus s'authentifier sur l'AD. J'ai tenter de reinitialiser le compte ordinateur dans l'AD mais ca n'a pas résolu le probleme. Je tente de prendre la main sur la machine via sccm -> impossible, mon compte n'a plus les droits (normal le poste est considéré comme hors domaine).
Je tente de me loguer avec le compte administrateur local -> echec aussi.
En essayant en mstsc on se rend compte que le compte Administrateur est en realite désactivé.
On a donc pas moyen de la dépaner, étant donné qu'elle est dans un pays étranger et qu'il n'y a pas de service informatique sur place.
On lui demande d'utiliser un autre poste temporairement en attendant qu'on lui en envoie un nouveau.
2 jours après, même problème sur ce nouveau poste, le pc sorti du domaine, et le compte administrateur désactivé.
 
Je peux pas certifié a 100% que sur ces postes le compte administrateur n'avait pas été activé, bien que je trouve ca bizarre car on a vraiment très peu de poste du parc dans ce cas.
Par contre, je peux affirmer que les 2 postes étaient bien dans le domaine, et qu'elle est la seule à rencontrer ce problème.
 
Je n'ai strictement aucune idée de pourquoi un pc ne peut plus se connecter sur un domaine à moins que ce ne soit pas arrivé depuis 90 jours auquel cas la il me semble que c'est normal.
La si j'ai bien compris, quand on a ce message d'erreur c'est tout simplement que le compte ordinateur s'authentifie avec un mot de passe différent que celui présent dans l'AD.
 
Auriez vous des pistes de recherches ? Des solutions à proposer ?
 
Parce qu'aujourd'hui, la seule c'est faire faire à quelqu'un la manip d'installer un W7 sur une cle USB et la méthode ultiman pour réactiver le compte admin qu'on puisse au moins prendre la main sur ce pc. en mstsc

Salut Matteu,

Nous avons exactement les même soucis dans notre Société.

On essai d'analyser et d'en trouver la cause, sur un parc de 2000 PCs on a en moyenne une trentaine de PC qui sortent tout les mois.

mon analyse des causes probables :

- Désynchronisation de l'heure entre le PC et le DC (Pile bios possible)
- Windows en statuts non-activé

Dans ton cas, après avoir réinitialisé le compte AD, as-tu rejoins le domaine avec la machine ?

Dans notre infrastructure, nous avons un mot de passe et un login admin local spécifique, mais dès que l'on met un ordinateur sur le domaine et qu'on change l'emplacement du compte "Ordinateur" dans une autre OU, une GPO recreer un autre compte administrateur avec un Login et mot de passe différent.

Pour info si tu arrives à faire un ping sur la machine en question à partir de ton poste , tu peux :

Faire un clic droit sur "Ordinateur" -> Gérer -> Clic droit sur Gestion de l'ordinateur (Local) -> Se connecter à un autre ordinateur, et la met l'adresse IP de l'ordinateur sorti du domaine.

Ensuite dans l'arborescence tu vas dans : Outils Sytèmes-> utilisateurs et Groupes locaux-> Utilisateurs -> Et la double clic sur le compte Admin local et essaie de le réactiver toi même.

Confirme moi si ça marche

A+

c'est peut être aussi que quelqu'un a intégré un nouveau poste avec le même nom. Faut regarder qd date le last modified de l'objet qd il y a le soucis voir regarder les logs des DC ...

La désynchronisation de l'heure entre le pc et le dc je sais qu'il ne faut pas qu'elle dépasse 5 minutes, mais je pensais que ca affichait un autre message d'erreur.
En tous cas, dans ce cas précis, c'est étonant que pour un MEME utilisateur ca arrive sur 2 pc différents en 3 jours ^^ mais ca reste une piste a explorer !  
 
Windows non activé ca affiche un écran noir en fond et ca te demande de l'activer normalement non ? j'ai déjà eu ce problème mais pas de poste qui sortaient du domaine a cause de ca mais je prendrai la peine de vérifier au cas ou
 
Le compte AD du PC je l'ai reinitialiser mais je ne peux pas joindre la machine sur le domaine etant donné que je ne peux pas prendre la main dessus, et qu'aucun compte ne peux plus se connecter sur la machine puisque le seul compte local administrateur est désactivé pour je ne sais pas quelle raison mais j'ai vu qu'on avait quelque poste comme ca.
Pour résoudre le problème la il n'y a que 2 solutions :
-Faire avec le responsable du site la manipulation pour avoir une cle usb bootable et utiliser le ultiman.exe pour réactiver le compte admin et ainsi pouvoir sortir puis rejoindre le domaine. On peut lui donner le mot de passe local à lui puisque c'est la seule personne habilité a faire des manipulations informatique mais il ne vient pas de ce domaine.
-Remasterise le poste avec SCCM mais a l'heure actuelle, ce n'est pas configuré pour pouvoir être fait depuis ce site qui n'est que point de distribution.
 
Nous n'avons pas de compte local en dehors du compte administrateur.
 
Ton astuce j'ai déjà tenté mais bien évidement ca ne fonctionne pas ^^ Pour pouvoir avoir accès à un poste distant via l'option gérer, il faut les droits admins sur ce poste. Vu que ce poste n'a aucun compte avec des droits admins actuellement... Impossible d'avoir la moindre info dessus.
 
Je te remercie pour ton message en tous cas et je regarde les 2 pistes demain.
 
@Jeanb concernant la partie ou un poste a ete integre avec le meme nom je me suis posé cette question, qui en théorie est impossible dans notre cas, mais que je vérifierai également.
Le poste est crée d'abord dans SCCM avant d'être masterisé et porte le numéro d'objet présent dans SCCM.
Les postes en questions etant vieux, plus de 5 ans, ils n'ont jamais été modifié.  
Par contre la piste des logs des DC va peut etre m'aider a diagnostiquer le problème, en faisant se loguer la personne voir si j'ai un enregistrement qui se crée sur le DC à ce moment la.
 
Merci encore pour votre aide précieuse. Ce forum est vraiment bien et on y trouve des gens compétent ca fait plaisir.

Voila ce qui apparait au niveau du DC :
 
Le client Kerberos a reçu une erreur KRB_AP_ERR_MODIFIED du serveur nompc$. Le nom cible utilisé était RPCSS/NOMPC.domaine.net. Cela indique que le serveur cible n’a pas réussi à déchiffrer le ticket fourni par le client. Cela risque de se produire lorsque le nom principal du serveur (SPN) cible est inscrit sur un compte différent de celui utilisé par le service cible. Veuillez vous assurer que le SPN est inscrit sur, et uniquement sur, le compte utilisé par le serveur. Cette erreur peut aussi se produire lorsque le service cible utilise un mot de passe pour le compte du service cible qui diffère par rapport à celui que possède le centre de distribution de clés Kerberos pour le compte du service cible. Veuillez vous assurer que le service sur le serveur et le centre de distribution de clés Kerberos sont tous deux mis à jour pour utiliser le mot de passe actuel. Si le nom de serveur n’est pas pleinement qualifié, et que le domaine cible (domaine.net) diffère du domaine client (domaine.NET), vérifiez s’il existe des comptes de serveur de même nom dans ces deux domaines, ou utilisez le nom pleinement qualifié pour identifier le serveur.

Nous n'avons pas de compte local en dehors du compte administrateur.  

Pas bien
Et y'a pas un compte domaine en cache sur le PC qui a les droits d'admin ?
Ca peut dépanner sur un coup de bol.
 
Tu as le nltest.exe pour avoir quelques infos aussi (sans forcément reset) :
http://blogs.msdn.com/b/sudhakan/a [...] shots.aspx
 
Vérifie aussi le  pwdlastset machine si tu as pas déjà fait
http://serverfault.com/questions/5 [...] make-sense

Ca marche pas quand j'essaye de me connecter avec mon compte admin ^^

Le nltest faut le faire sur la machine -> impossible dans mon cas du cou
On va au plus loin sur l'authentification user et apres on peut rentrer sur aucun compte

pour le pwdlastset j'ai hier un peu avant qu'elle ai eu le probleme je pense

 
Je voulais dire quand (si) tu vas récupérer la machine pour analyse évidemment ^^
On est d'accord que c'est un peu mort pour dépanner à distance...

Bé, je vais quand même essayer de faire dépanner
En faisant faire une cle USB bootable + procédure pour renommer l'ultiman.exe en .old et le cmd en ultiman et réactiver le compte admin local a partir de la je peux normalement reprendre la main et le remettre dans le domaine.

mmm il me semblait que cette technique "ultiman.exe" ne fonctionnait plus. tu l'as testée ?
si l'utilisatrice est pas trop neuneu, c'est jouable la clé USB. j'ai testé Hiren, ça marche bien.

je suis justement en train de faire le test avec Hiren sur usb pour pouvoir guider au mieu la personne.
Apres c'est pas une solution ca, c'est une solution d econtournement^^ donc je veux trouver la vraie cause du problème pour la corriger.

 
Oui ça c'est l'erreur comme quoi il arrive pas à s'auth. Mais tu dois avoir des logs avant qui te donneront l'info que le compte a été modifié.

Ok je vais regarder ca car la c'est ce que mon responsable a envoyé a microsoft xD
 
Bref, sinon super :
 
J'appelle tout a l'heure elle me dit ca marche, je lui dis c'est pas normal ca... Je lui fais fermer la session, elle l'ouvre de nouveau -> echec de la relation d'approbation etc donc la ca ne fonctionne plus.
Bref j'ai contacter le responsable la bas qui va acheter une cle USB pour fait avec ultiman et je regarde les logs tout de suite

Échec de l’authentification de la configuration de session de l’ordinateur NOMPC. Le nom du compte référencé dans la base de données de la sécurité est NOMPC$. L’erreur suivante s’est produite :  
Accès refusé.

 
Normal, ses credential sont en cache donc elle peut ouvrir sa session en n'étant pas connecté au réseau puis se connecter au réseau. Elle aura pas de kerberos donc à mesurer l'impact, le NTLM fonctionnera.
 
 

 
Oui l'erreur là va avec celle d'avant mais c'est toujours pas ça.

 
Mais oui lol, c'est la technique qu'on utilise en plus.... que jsuis con  
 

 
ils vont demander de prendre les logs de diag habituels à partir du PC, le truc qui prend 15/20 minutes et pour se rendre compte que c'est pas suffisant et qu'il faut
également des logs côté DC. On a eu le cas avec eux mais c'est l'équipe AD vers qui il faut se tourner, nous on avait été vers l'équipe réseau Microsoft...
Bref, bon courage et ça m'intéresse de voir ce que Microsoft va te raconter.

C'est en cache etc je comprends pas forcement.
Moi sur mon poste je le retire du reseauje peux me logguer ca ok.
 
Mais elle, elle se logue sur le reseau ce matin , ca lui charge sa session en cache puis elle ouvre une session tse ca fonctionne. je lui fais fermer sa session, ca ne fonctionne plus pour se logguer. reboot du poste, meme probleme.  
Apparement en jouant avec le cable reseau un peu elle a reussi a se reconnecter, meme si je vois mal comment ca pourrait etre lié.
 
Oui j'attends leur appel voir ce qu'ils vont proposer même si j'y crois moyen chaque fois c'est un peu peine perdue... Les logs du DC ils ont demandé, mais il y a que ce que je vous ai envoyé j'ai pas d'autre info.

 
normal que ça marche plus pour se relogger vu qu'elle est connectée au réseau.
Le TSE normal que ça marche vu que c'est un autre PC qui lui est dans le domaine.
 
Si tu as pas d'autres infos c'est que tes logs ne remontent pas ces infos. Peut être le genre d'audit à activer ... Ca peut aussi être sur d'autres DC hein.
 
J'ai un client qui a eu un problème similaire, un de ses techos a fait un reset du compte AD d'un des serveurs SQL qui héberge les applis critiques, je te dis pas la merde que ça a généré. Heuresement un event est généré qd tu reset le compte ordi et on lui a mis la tête dans son caca.

En connexion AD par DC classique :
Vérification que ton utilisateur AD est bien un utilisateur AD validé par le(s) DC.
C'est les contrôleurs qui valident que tu es légitime.
 
En connexion sans DC (déconnecté du réseau) :
L'authentification ne peut pas se faire par un DC vu que y'a pas de réseau, donc au lieu de ne pas pouvoir du tout se connecter (ça serait balot), il utilise le cache credentials qui contient différentes infos et qui considère que ton utilisateur AD est quand même légitime (vu que tu t'es connecté y'a pas longtemps avec succès, que ton profil est présent dans C:\users etc...).
 
Sachant que ça, c'est unique au moment du login.
 
Du coup :
- tu démarres ton PC en débranchant le câble réseau.
- tu te loggue avec les caches credentials.
- quand t'as session est ouverte, tu reconnecte le réseau.
- tu as accès a tout car ton user est vu comme correct.

Merci pour ces explications.

ok je comprends mieux la

Bé moi j'ai aussi fait reinitialiser le compte sur le compte ordinateur ca rj'avais trouvé ca sur un site.

La j'ai microsoft au tel apparement elle m'a dit qu'on allait recrée la chaine de sécurité.
De ce que je comprends, le pc s'authentifie avec un pass, et le dc en attend un autre donc ca peut aps fonctionner.

La manipulation qu'elle m'a fait effectuer : netdom resetpwd /s:@IPDC2 /ud:nomcompte admin /pd:* sur le DC1 et netdom resetpwd /s:@IPDC1 /ud:nomcompte admin /pd:* sur le DC2
Elle m'a demandé de les redémarrer et de redémarrer la machine cliente également.
Je ne peux redémarrer dc1 que cette nuit, donc résultat lundi au plus tot mais ca me parait bizarre de faire une manipulation a l'echelle de tout un DC alors qu'il y a un probleme seulement avec 2 comtpe ordinateurs.

euh ça a l'air sympa cette commande

C'est ce qui est expliqué sur le lien que je t'ai filé :
http://blogs.msdn.com/b/sudhakan/a [...] shots.aspx

AU lieu de passer par netdom ou de reset le compte ordinateur, commence par essayer Test-ComputerSecureChannel et Repair-ComputerSecureChannel, ça t'évitera d'aggraver la situation.

je regarde ca lundi de plus prêt mais sinon, si je dois faire un bilan de tout ce qui est dis la il y a beaucoup d'idée, en théorie j'aurai ete sensé commmencer par quoi et poursuivre par quoi ?
Parce qu'il y a bien 5 pistes de recherche, apparement j'ai un peu grillé les étappes dans mon cas, mais pour la prochaine fois j'aimerais bien faire les choses mieux .

Bon alors, j'ai acces a la machine qui avait le probleme, je l'ai sorti puis rerentré dans le domaine et ca fonctionne.
 
Au niveau des logs, voila ce que j'ai :
 
Cet ordinateur ne peut pas authentifier avec \\DC1.XXX, un contrôleur de domaine Windows pour le domaine XXX. Cet ordinateur pourrait par conséquent refuser les demandes d’ouvertures de session. Cette impossibilité d’authentification pourrait avoir été causée par un autre ordinateur sur le même réseau, utilisant le même nom ou ayant un mot de passe non reconnu pour ce compte d’ordinateur. Si ce message s’affiche encore, contactez votre administrateur système.
 
NtpClient n'a pas pu définir de domaine homologue utilisable comme source de temps en raison de l'échec de l'établissement d'une relation approuvée entre l'ordinateur et le domaine "" afin de synchroniser l'heure de façon sécurisée. NtpClient réessaiera dans 3473457 minutes, puis doublera l'intervalle d'attente pour les tentatives suivantes. L'erreur était : La relation d’approbation entre cette station de travail et le domaine principal a échoué. (0x800706FD)
 
Le serveur Terminal Server ne peut pas inscrire « TERMSRV » comme nom principal du service pour l’authentification du serveur. L’erreur suivante s’est produite : Accès refusé.
 
NtpClient n’a pas pu définir de domaine homologue utilisable comme source de temps en raison d’une erreur de découverte. Il réessaiera dans 3473457 minutes, puis doublera l’intervalle d’attente pour les tentatives suivantes. L’erreur était : Rubrique introuvable. (0x800706E1)
 
 
 
Cet ordinateur n’a pas pu configurer une session sécurisée avec un contrôleur de domaine dans le domaine XXX pour la raison suivante :  
Aucun serveur d’accès n’est actuellement disponible pour traiter la demande d’ouverture de session.  
Cela peut entraîner des problèmes d’authentification. Vérifiez que cet ordinateur est connecté au réseau. Si le problème persiste, contactez votre administrateur de domaine.  
 
INFORMATIONS SUPPLÉMENTAIRES  
Si cet ordinateur est un contrôleur de domaine pour le domaine spécifié, il installe la session sécurisée sur l’émulateur de contrôleur de domaine principal dans le domaine spécifié. Sinon, cet ordinateur installe la session sécurisée sur n’importe quel contrôleur de domaine du domaine spécifié.
 

Pour moi dans l'ordre ça serait :
 
- Vérifier la date + heure du PC
- Vérifier l'état du pare-feu du PC
- Vérifier la connexion AD par la commande PShell : Test-ComputerSecureChannel
- Si False, vérifier si un compte AD avec droits admin est utilisable avec les credentials cache.
- Si False et droits admin, investiguer avec les commandes NLTEST et vérifie le LastPwdSet
et récupérer les logs du DC et du poste.

je te remercie pour les check a faire si jamais le probleme se reproduit

les messages que j'ai mis au dessus n'inspirent personnes quant au probleme eventuel ?

en gros le premier message veut dire : quelqu'un a rejoint le domaine avec le meme nom que ton pc donc byebye a toi

le deuxieme : le client ne sait pas vers qui se tourner pour régler son heure, donc il n'est surement pas a la meme heure a 5 min pret qu'un dc pour l'authentifier.

le 3eme je sais pas ce que c'est

le 4eme meme lien que 2nd

le 5eme : comme si le pc n'avait pas le cable (ce qui n'est pas impossible a ce moment la)

non dans tous les cas l'erreur est la même, il arrive pas à s'authentifier sur le dc

OK et donc un indice de résolution ne se trouve pas dans ses logs ?
Le but serait de comprendre qu est ce qui a provoque ça j ai tout le journal d événement de la machine

tu trouveras pas gd chose sur la machine

donc c'est plutot au niveau du dc qu'il faudrait chercher...
pas de soucis, je vais voir de regarder ca demain si j'ai le temps.  
Apres est ce que ca vaut la peine de perdre du temps la dessus pour 2 machines en 1 semaine et depuis aucun probleme, je ne sais pas... C'est juste que j'aimerais comprendre :s

Bon alors au niveau du DC j'ai rien au final ...
Juste
Échec de l’authentification de la configuration de session de l’ordinateur XXX. Le nom du compte référencé dans la base de données de la sécurité est XXX$. L’erreur suivante s’est produite :
Accès refusé.

Avec ca on ira pas loin, il aurait fallu avoir l'audit AD activé je suppose pour voir un peu plus ...

J'ai pas lu tout le topic, mais dans le doute : tu n'aurais pas cloné des postes de travail sans faire de sysprep ou de réinit de SID par hasard ?!

non

Salut tout le monde
 
J'ai bien peur d'avoir déjà vu ce problèmes chez des clients ... et sur mon infra W2012 interne.
 
Cela ne vient pas du clonage ( aucun clonage chez le client)
a priori, cela ne vient pas de la date heure non plus.
 
La seule solution (pourrie) que j'ai trouvé, c'est  
1° débrancher le PC du réseau,
2° se logger en user, changer le nom du PC et changer le domaine en Workgroup.
3° redémarrer
4° Sur le DC, supprimer l'entrée du PC
5° Sur le PC, remettre son ancien nom et le remettre sur le domaine.
 
Malheureusement, pour faire tout ca, faut un MDP admin pour logger/delogger du domaine, et CA, on n'a pas forcement envie de le donner au client. ( tenter un Teamviwer si le web fonctionne hors domaine !)
 
Voila, ma soluce toute pourrite, mais je continue à lire ce poste pour voir si vous trouvez mieux!
 
PS : Prob identique de temps à autre lors de restauration de VM VmWare !
 

oui ca je savais que ca fonctionnait mais ca ne résoud pas la cause du problème c'est juste la solution rapide.

On est d'accord
C'est juste pour remettre le PC sur le domaine, mais ca ne réglé pas la question du Pourquoi, ni le 'comment ne plus avoir ce problème'

Les ordinateurs changes de mot de passe à leur initiative et transmettent ce mot de passe au DC et ont une validité de 60jours normalement du coup, si le PC que tu lui a envoyé avait un mot de passe vieux de 59j, il est possible qu'il ai changé de mot de passe mais comme il n'a pas pu contacter le DC, il se soit sortie du domaine (mot de passe qui ne correspondent plus).
(c'est pour ça que normalement ils stockent l'ancien password également pour le retransmettre en cas de pb)
 
Si tu as la machine sous la main, vérifie le "pwdlastset" dans les propriété du compte ordinateur dans l'active directory.
Ensuite, sur l'ordinateur local, dans le registre vérifie la valeur correspond à celle dans HKLM\SECURITY\Policy\Secrets\$MACHINE.ACC\CupdTime & OupdTime
(Le temps est stocké en 100ns écoulé depuis le 01/01/1970)
 
Note que si ce type de problème est récurrent, tu peux faire une tâche planifié (que l'utilisateur pourra lancer quand il a le problème) qui tournera sous le compte "système" et qui modifie cette valeur (en utilisant LsaStorePrivateData) pour lui mettre une valeur définie.
Ensuite il te reste à mettre la même valeur dans l'AD (en utilisant SetPassword pour le coup), ça restaurera la relation d'approbation.
(Vu que le password sera le même à nouveau, une fois la relation restauré il est vivement conseillé de le modifier, via NetDom par exemple)
 
Enfin, ton utilisateur n'aurait il pas branché son PC sur un réseau d'entreprise (autre que la votre) ?

Pas tout lu non plus...désolé.
C'est un vrai PC ou un client léger ?

30 jours, pas 60.
http://blogs.technet.com/b/askds/a [...] test2.aspx
MaximumPasswordAge (default 30 days)