A voir également:
- Erreur Active Directory à propos des relations de confiance
- Erreur 0x80070643 - Accueil - Windows
- Directory list & print - Télécharger - Divers Utilitaires
- Erreur 0x80070643 Windows 10 : comment résoudre le problème de la mise à jour KB5001716 - Accueil - Windows
- Erreur 1001 outlook - Accueil - Bureautique
- Erreur vidéo freebox ✓ - Forum TV & Vidéo
2 réponses
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
4 déc. 2021 à 13:04
4 déc. 2021 à 13:04
Bonjour,
Le souci est la machine, pas le compte utilisateur.
Si vous essayez le login de cet utilisateur sur une autre station "viable", cela devrait fonctionner.
La machine n'arrive pas à contacter correctement l'AD.
Les 2 causes les plus répandues sont un problème de résolution DNS et/ou les flux réseaux manquants entre la station et les contrôleurs de domaine.
Il est préférable de se logguer avec un compte local à la station pour faire les tests :
1. de flux
tester les ports AD avec un outil comme Portqry (source : la station, destination : les DCs)
Source : https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts
Les ports hauts (ou dynamic RPC - 49152-65535) ne sont pas tous à tester, le serveur n'est pas forcément en écoute sur tous les ports lors du test. Il faut s'assurer que c'est bien ouvert sur tous les firewalls.
Généralement je teste le 49152,50000,60000 ; mais bcp de faux positifs, car les ports ne sont pas en écoute.
2. DNS
Vérifier la conf TCP/IP du poste, s'assurer que les DNS primaires et secondaires pointent bien sur les DCs, et rien d'autre.
Utiliser la commande nslookup pour résoudre - à minima - le FQDN du domaine et du DC avec un point à la fin.
--> S'assurer que tous ces tests sont OK, ensuite réintégrer la machine dans le domaine.
Le souci est la machine, pas le compte utilisateur.
Si vous essayez le login de cet utilisateur sur une autre station "viable", cela devrait fonctionner.
La machine n'arrive pas à contacter correctement l'AD.
Les 2 causes les plus répandues sont un problème de résolution DNS et/ou les flux réseaux manquants entre la station et les contrôleurs de domaine.
Il est préférable de se logguer avec un compte local à la station pour faire les tests :
1. de flux
tester les ports AD avec un outil comme Portqry (source : la station, destination : les DCs)
123/UDP W32Time
135/TCP RPC Endpoint Mapper
464/TCP/UDP Kerberos password change
49152-65535/TCP RPC for LSA, SAM, NetLogon (*)
389/TCP/UDP LDAP
636/TCP LDAP SSL
3268/TCP LDAP GC
3269/TCP LDAP GC SSL
53/TCP/UDP DNS
88/TCP/UDP Kerberos
445/TCP SMB (**)
Source : https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts
Les ports hauts (ou dynamic RPC - 49152-65535) ne sont pas tous à tester, le serveur n'est pas forcément en écoute sur tous les ports lors du test. Il faut s'assurer que c'est bien ouvert sur tous les firewalls.
Généralement je teste le 49152,50000,60000 ; mais bcp de faux positifs, car les ports ne sont pas en écoute.
2. DNS
Vérifier la conf TCP/IP du poste, s'assurer que les DNS primaires et secondaires pointent bien sur les DCs, et rien d'autre.
Utiliser la commande nslookup pour résoudre - à minima - le FQDN du domaine et du DC avec un point à la fin.
nslookup
domain.local.
[...résultat...]
nomduDC.domain.local.
[...résultat...]
--> S'assurer que tous ces tests sont OK, ensuite réintégrer la machine dans le domaine.