Peut accéder au partage Windows par adresse IP ou FQDN mais pas par nom d'hôte

L'un des ordinateurs du laboratoire de l'école que j'administre n'est pas en mesure d'accéder à des partages sous le répertoire \\ ad \ data $. Je peux y accéder depuis n'importe quel autre ordinateur du réseau. Si j'utilise l'IP \\ 192.168.1.248 \ data $, je peux accéder correctement aux fichiers. Si j'utilise le nom de domaine complet: \\ ad.domain.name \ data $, cela fonctionne également. Tout autre ordinateur de l'école peut également accéder correctement à ce partage.

Lorsque j'essaie d'accéder au partage avec \\ ad \ data $, j'obtiens le message "Vous n'êtes pas autorisé à accéder à \\ ad \ data $. Contactez votre administrateur pour demander l'accès." Je suis connecté avec le compte administrateur de domaine.

Une idée sur ce qui empêcherait un ordinateur à domaine unique d'accéder à un partage auquel il devrait avoir accès?

Le serveur exécute Windows Server 2008 et l'ordinateur exécute Windows 7 SP1.

MISE À JOUR

Le problème se produit maintenant sur plusieurs autres ordinateurs du réseau, les ordinateurs du personnel et les ordinateurs des étudiants. Je commence à penser qu'il y a un problème grave avec le serveur Active Directory.

Je viens d'avoir un problème similaire.

Nous avons un domaine et AD, et tous les dossiers personnels des utilisateurs sont configurés dans l'AD.

L'utilisateur travaille sur un serveur Terminal Server et son dossier personnel fonctionne correctement Sur le nouveau bloc-notes que nous configurions pour elle, le lecteur a été mappé, mais si vous avez essayé d'y accéder via unc ou en double-cliquant sur le lecteur mappé, il a donné une erreur de l'emplacement est introuvable.

En parcourant quelques autres forums, j'ai remarqué que quelqu'un a demandé si le dossier de départ pouvait être accessible via IP ou FQDN. Quand j'ai essayé, j'ai pu accéder au dossier.

Au début, je pensais aussi que c'était un problème DNS.

En lisant plus loin, quelqu'un a dit "essayez de supprimer le cache CSC", puis je me suis presque juré. Sachant que ce bloc-notes a été utilisé par un autre utilisateur qui a utilisé des fichiers hors ligne (également leur dossier de départ sur le même serveur). J'ai trouvé un moyen rapide de supprimer le cache CSC sur Win 7 (c'est beaucoup plus facile sur XP). Redémarré l'ordinateur et le problème a été résolu.

Voici les liens sur lesquels j'ai trouvé les informations:

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

J'ai vu un problème comme celui-ci et il était dû au fait que le DNS était configuré pour ne pas ajouter automatiquement le nom de domaine.

Donc, je vérifierais que l' ajout des suffixes DNS principaux et spécifiques à la connexion est sélectionné et que les suffixes parentaux d'ajout du suffixe DNS principal sont cochés.

Cela peut être trouvé via

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS

Win7 / server 2008> tapez le panneau de configuration dans "Gestionnaire d'informations d'identification" et supprimez toutes les informations d'identification enregistrées.

J'ai eu le même problème (qui m'est arrivé plusieurs fois) et je l'ai résolu en supprimant tous les partages connectés et en les recréant. Il y a eu plusieurs connexions vers les mêmes emplacements (en utilisant des URL différentes) et je soupçonne que c'est la raison des problèmes.

En utilisant la ligne de commande:

1. Pour voir les partages actuellement connectés
   net use
2. Pour supprimer la connexion pour partager Y sur xxx.xxx.xxx.xxx
   net use \\xxx.xxx.xxx.xxx\Y /delete
3. Pour supprimer la connexion pour partager Y sur XXX
   net use \\XXX\Y /delete
4. Pour supprimer un lecteur réseau mappé
   net use Y: /delete
5. Pour reconnecter le lecteur réseau mappé
   net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Un autre suspect potentiel est le gestionnaire Samsung PC Share. Après l'avoir désinstallé de l'hôte, le problème a disparu.

Il est possible que l'ordinateur client utilise des informations d'identification enregistrées. Vous pouvez vérifier à l'aide du Gestionnaire d'informations d'identification Windows sous Panneau de configuration.

Cela se produit-il sous un compte d'administrateur local, par exemple nom_machine \ Administrateur?

La machine s'authentifie-t-elle correctement auprès du contrôleur de domaine?

Assurez-vous que vous ne vous connectez pas déjà à \ ad en utilisant des informations d'identification différentes (ou anciennes). J'ai rencontré des problèmes similaires lorsque j'avais un lecteur mappé connecté à un partage sur un serveur en utilisant mon compte de domaine "normal", puis j'ai essayé de me connecter à un autre partage sur le même serveur en utilisant mon compte "admin" de domaine.

Un redémarrage résout-il le problème?

J'ai eu un problème connexe. J'ai eu une machine XP Home accédant aux partages / dossiers partagés et aux lecteurs sur une machine Windows 7. Je jouais avec les paramètres du groupe de travail / groupe résidentiel sur Windows 7 et j'ai changé l'option "Partage protégé par mot de passe". Je pouvais voir mes dossiers partagés sur ma machine XP Home, mais je ne pouvais ni lire ni écrire depuis / vers eux. Cela me rendait fou - car lorsque j'ai créé un nouvel utilisateur sur la machine XP Home et accédé à mes partages sur la machine Win 7, il n'y avait aucun problème - je pouvais lire et écrire des fichiers!

Je suis donc retourné à mon ancien compte utilisateur (principal) et je ne pouvais toujours pas accéder aux fichiers partagés ...

J'ai essayé toutes sortes de solutions - net use * / del et j'ai essayé de supprimer les comptes d'utilisateurs net user / delete - j'ai essayé de me débarrasser des informations d'identification mises en cache - mais rien n'a fonctionné. Accéder aux partages via une adresse IP a fonctionné! Argggh !!

J'ai essayé de définir le groupe de travail sur les deux machines sur Workgroup (la machine XP HOME était MSHOME)

Finalement, j'ai dû changer le NOM DE L'ORDINATEUR sur ma machine Windows 7, redémarrer, puis accéder à mes dossiers partagés depuis la machine XP HOME. Il m'a ensuite demandé un nom d'utilisateur / mot de passe de connexion que j'ai ressaisi. Cependant, j'avais des chemins et des trucs qui utilisaient mon ancien nom d'ordinateur, j'ai donc changé mon ordinateur Win 7 pour qu'il soit à l'origine. Alléluia! Cela a fonctionné - encore une fois, on m'a demandé un utilisateur / mot de passe et j'ai pu accéder à mes partages à partir de la machine XP HOME!

Donc, résumé: il y a un problème avec les informations d'identification mises en cache et aucun moyen évident de les supprimer (rien ne s'affichait non plus dans Network Password Manager dans le compte utilisateur). Par conséquent, modifiez temporairement le nom de votre ordinateur et modifiez-le en arrière et cela pourrait résoudre certains problèmes.

J'ai rencontré plusieurs problèmes similaires sur des forums comme ceux-ci, mais pas le même que le mien.

J'ai eu ce problème après la mise à niveau d'une boîte Server 2008 R2 vers Server 2012 R2 avec mise à jour. Pour moi, entrer dans Credentials Manager et supprimer Windows Credentials -> Generic Credentials a résolu le problème.

Dans l'un de mes cas, à ma grande surprise, il s'est avéré que je devais vider le cache DNS en plus d'activer la fonctionnalité de prise en charge SMB 1.0 dans Windows 8.1. Il s'agit d'un ordinateur appartenant à un domaine qui a été déconnecté de son domaine.

Dans l'autre cas, un ordinateur n'appartenant pas à un domaine, vider le cache DNS n'a pas aidé. Cependant, curieusement, le nom complet a \\Name.fonctionné quand il \\Namene l'a pas fait (je n'ai pas essayé ce fils la première machine). Je ne sais pas quel est le problème ici, mais je suppose que cela est lié à l'absence de nom de domaine.

Nous avons rencontré ce problème sur un dossier spécifique uniquement. Il s'avère que les dossiers hors connexion sont à l'origine du problème, car nous utilisons des dossiers redirigés. Ainsi, Windows se connecte littéralement à ce partage avec les informations d'identification des autres utilisateurs dès que Windows démarre, il refuse donc la connexion de l'utilisateur connecté.

La solution utilisée était de désactiver la synchronisation hors ligne.

Il peut s'agir d'ACL réseau. Dans un environnement dans lequel j'ai travaillé, ils ont été modifiés pour bloquer le port 445. Donc:

\ hostname \ share

• Le client a tenté de se connecter via SMB sur le port TCP / IP 445
• Bloqué par les ACL du réseau
• Le client ne parvient pas à se connecter

\ hostname.fqdn \ share

• Le client a tenté de se connecter via SMB sur le port TCP.IP 445
• Bloqué par les ACL du réseau
• Le client se connecte via NetBT sur le port 139
• Connexion réussie

Il s'est donc avéré que la connexion au FQDN tente d'utiliser NetBT et que le port 139 était ouvert, ce qui a réussi.

La solution consistait donc à débloquer le port 445.