Qu'est-ce qui fait qu'une station de travail perd la confiance avec le contrôleur de domaine?

J'ai reçu l'erreur plusieurs fois sur les postes de travail et les ordinateurs portables Windows 7 où elle perd confiance avec le contrôleur de domaine, et je sais comment la corriger, mais pourquoi fait-elle cela?

Vous le savez probablement déjà, mais soyez indulgent avec moi.

Les ordinateurs ont des mots de passe dans AD, tout comme les utilisateurs. Nous ne connaissons pas le mot de passe de notre ordinateur et il change régulièrement via une logique intégrée.

La réponse courte est que le mot de passe de l'ordinateur n'est plus valide, et donc AD ne fait plus confiance à cette machine pour les connexions.

Pourquoi? Comment? Beaucoup de choses en sont la cause. Quelque chose a interféré avec le processus de changement de mot de passe ou a fait revenir la machine à un ancien mot de passe. Les coupables possibles incluent:

• Restauration à partir d'une sauvegarde.
• Être éteint suffisamment longtemps pour que le mot de passe expire, suivi de problèmes de réseau.
• Problèmes généraux de réseau intermittent avec un mauvais timing.
• Virus, malwares, etc.
• Plus de choses qui ne me viennent pas à l'esprit pour le moment, probablement.

J'espère que ça aide.

S'étendant sur la réponse de Katherine:

Un poste de travail perdra confiance avec le contrôleur de domaine si son compte a été remplacé. Il est tout à fait possible (avec les autorisations appropriées) d'ajouter un ordinateur avec un nom qui existe déjà dans le domaine, mais cela entraînera la perte de confiance de l'ordinateur qui était auparavant connu sous ce nom avec le contrôleur de domaine.

Une raison peut être la dérive de l'horloge. Si l'horloge de la station de travail dérive à plus de 5 minutes du serveur, elle perdra la connexion au domaine. Cela peut provenir de matériel floconneux, ou lorsque le système est hors tension pendant une période assez longue, ou parfois lorsqu'un ordinateur portable est souvent éloigné du réseau, etc.

Le processus de mot de passe de l'ordinateur AD (documenté ici) n'a pas beaucoup changé et n'est certainement pas la cause première des problèmes de canal cassés. (en fait, c'est le CLIENT qui change le mot de passe et le mot de passe est exempté de la politique d'expiration du mot de passe. Maintenant, selon le système d'exploitation du client, c'est là que les choses deviennent intéressantes. 1 raison du verrouillage est XP. Si c'est XP et ci-dessous, le client changera c'est mot de passe - puis essayez de communiquer le nouveau mot de passe au contrôleur de domaine. Dans la version 7 ou supérieure, le client n'essayera pas tant qu'il ne sera pas connecté à un contrôleur de domaine. Les problèmes de réplication de domaine peuvent entraîner des échecs de canal. où le même nom a été réutilisé. Les problèmes de synchronisation de l'heure peuvent également entraîner des problèmes avec le canal, et dans la plupart des cas, vous pouvez évaluer ce qui s'est passé (si vous êtes si enclin) en activant la journalisation de netlogon (https://support.microsoft.com/en-us/kb/109626 ) et en examinant les journaux pour savoir pourquoi le canal n'a pas pu être configuré. L'échec de sysprep une image semble également causer un problème (je n'ai pas compris exactement pourquoi mais un disjoin et un rejoin semblent toujours résoudre le problème)

L'autre façon serait d'utiliser ADUC et de réinitialiser le compte d'ordinateur (s'il vient de se désynchroniser avec le domaine), faites simplement un clic droit sur le nom de l'ordinateur et choisissez "Réinitialiser le compte" (environ 80% du temps, cela résoudra votre problème ).

Le «pourquoi» est que dans Microsoft Windows 2003, ils ont étendu leur implémentation d'annuaire pour obliger les postes de travail à réinitialiser leurs mots de passe tous les 30 jours environ. Je le sais bien, il a cassé beaucoup d'installations SAMBA que je maintenais à l'époque.

Normalement, cette réinitialisation de mot de passe est entièrement automatique, mais j'ai vu de très nombreux cas où cette conception ne fonctionne tout simplement pas. Lorsque j'éteins un bloc-notes pendant un certain temps, puis tente de me connecter avec un compte non mis en cache, je reçois immédiatement ce message d'erreur, quel que soit le système d'exploitation Microsoft post-2000 que j'utilise.

Ainsi, le moyen le plus simple de maintenir un réseau fonctionnant de manière transparente dans cette situation conçue en mode de défaillance est de modifier ou de désactiver ce paramètre de stratégie au niveau du domaine: stratégies de groupe / paramètres Windows / paramètres de sécurité / stratégies locales / options de sécurité, puis recherchez: Membre de domaine: âge maximal du mot de passe du compte d'ordinateur Membre du domaine: désactivation des modifications du mot de passe du compte d'ordinateur

J'espère que ça aide.