Peut accéder au partage Windows par adresse IP ou nom de domaine complet mais pas par nom d'hôte
L’un des ordinateurs de laboratoire de l’école que j’administre n’est pas en mesure d’accéder aux partages du répertoire \\ ad\data $. Je peux y accéder depuis n'importe quel ordinateur du réseau. Si j'utilise l'IP \\ 192.168.1.248\data $, je peux accéder aux fichiers correctement. 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 à ce partage correctement.
Lorsque j'essaie d'accéder au partage avec \\ ad\data $, 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 du domaine.
Avez-vous une idée de 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.
UPDATE
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 quelque chose qui ne va vraiment pas avec le serveur Active Directory.
Je viens d'avoir un problème similaire.
Nous avons un domaine et AD, et tous les dossiers de base des utilisateurs sont configurés dans AD.
L'utilisateur travaille sur un serveur de terminal et son dossier personnel fonctionne bien. Sur le nouveau bloc-notes que nous étions en train de configurer pour elle, le lecteur était mappé, mais si vous tentiez d'y accéder via unc ou en double-cliquant sur le lecteur mappé, une erreur s'est produite. de l'emplacement n'a pas pu être trouvé.
En parcourant quelques autres forums, j'ai remarqué que quelqu'un demandait 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, j’ai aussi pensé que c’était un problème de DNS.
En lisant plus loin, quelqu'un a dit "essayez de supprimer la mémoire cache du SCC", puis je me suis presque juré. Sachant que ce bloc-notes a été utilisé par un autre utilisateur utilisant des fichiers hors connexion (leur dossier personnel également sur le même serveur). J'ai trouvé un moyen rapide de supprimer le cache CSC sur Win 7 (c'est beaucoup plus facile sous XP). Redémarrez l'ordinateur et le problème a été résolu.
Voici les liens sur lesquels j'ai trouvé l'info:
J'ai vu un problème comme celui-ci et il était dû au fait que le DNS était configuré pour ne pas ajouter le nom de domaine automatiquement.
Donc, je voudrais vérifier que Ajouter les suffixes DNS primaire et spécifique à la connexion est sélectionné et que Ajouter les suffixes parent du primaire Le suffixe DNS est coché.
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> type de panneau de contrôle dans "Gestionnaire d'informations d'identification" et supprimez toutes les informations d'identification enregistrées.
J'ai eu le même problème (il 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 aux mêmes emplacements (en utilisant des URL différentes) et je soupçonne que c'était la cause des problèmes.
Utilisation de la ligne de commande:
- Pour voir les partages actuellement connectés
Net Use - Pour supprimer la connexion pour partager Y sur xxx.xxx.xxx.xxx
Net Use \\xxx.xxx.xxx.xxx\Y /delete - Supprimer la connexion pour partager Y sur XXX
Net Use \\XXX\Y /delete - Pour supprimer un lecteur réseau mappé
Net Use Y: /delete - Pour reconnecter un 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 de Windows Credential Manager sous Panneau de configuration.
Cela se produit-il sous un compte administrateur local, par exemple nom_ordinateur \Administrateur?
La machine s’authentifie-t-elle correctement sur le contrôleur de domaine?
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, accéder à Credentials Manager et supprimer les informations d'identification Windows -> Les informations d'identification génériques ont résolu le problème.
A trouvé cette solution: Impossible d'accéder au serveur d'impression avec un nom d'alias ou un enregistrement DNS CNAME. http://winplat.net/2018/10/13/unable-to-access-print-server-with-the-alias-name-or-cname/
J'ai eu un problème connexe. J'ai eu une XP machine personnelle accédant à des partages/dossiers partagés et à des lecteurs sur une machine Windows 7. Je jouais avec les paramètres de groupe de travail/groupe de maison sur Windows 7 et ai changé l'option "Partage protégé par mot de passe". Je pouvais voir mes dossiers partagés sur ma XP Maison personnelle, mais je ne pouvais ni les lire ni les écrire. Cela me rendait fou - parce que 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 a eu 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 des 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 DID work! Argggh !!
J'ai essayé de régler le groupe de travail sur les deux machines sur groupe de travail (la machine XP HOME était MSHOME)
Finalement, je devais changer le nom de l'ordinateur sur mon ordinateur Windows 7, le redémarrer, puis accéder à mes dossiers partagés à partir de la machine XP HOME. Il m'a ensuite demandé un nom d'utilisateur/mot de passe que j'ai saisi de nouveau. Cependant, j'avais des chemins et des trucs qui utilisaient l'ancien nom de mon ordinateur. J'ai donc modifié mon ordinateur Win 7 pour qu'il redevienne tel qu'il était à l'origine. Alléluia! Cela a fonctionné - encore une fois on m'a demandé un utilisateur/mot de passe et je pouvais 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 n'a été affiché dans Network Password Manager dans le compte d'utilisateur). Par conséquent, modifiez temporairement le nom de votre ordinateur, puis rétablissez-le, ce qui pourrait résoudre certains problèmes.
Je suis tombé sur plusieurs problèmes similaires sur des forums comme ceux-ci, mais pas les mêmes que les miens.
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 lorsqu'un lecteur mappé était connecté à un partage sur un serveur à l'aide de mon compte de domaine "normal", puis j'ai essayé de me connecter à un autre partage sur le même serveur à l'aide de mon compte "admin" de domaine.
Un redémarrage résout-il 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 pour activer le SMB 1.0 fonctionnalité de support dans Windows 8.1. Il s’agissait d’un ordinateur appartenant à un domaine qui était déconnecté de son domaine.
Dans l'autre cas, un ordinateur non associé à un domaine, vider le cache DNS n'a pas aidé. Cependant, curieusement, le nom qualifié \\Name. fonctionnait alors que \\Name ne fonctionnait pas (je n'ai pas essayé ce fils comme premier ordinateur). Je ne sais pas quel est le problème, mais je suppose que cela est lié à l’absence de nom de domaine.
Nous avons constaté que cela se produisait dans un seul dossier. 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 le démarrage de Windows, de sorte qu'il refuse la connexion de l'utilisateur connecté.
La solution utilisée était de désactiver la synchronisation hors ligne.
Pourrait être des ACL de réseau. Dans un environnement dans lequel j'ai travaillé, ils ont été modifiés pour bloquer le port 445. Ainsi:
\ nom d'hôte\partage
- 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 se trouve que la connexion au nom de domaine complet tente d’utiliser NetBT et que le port 139 était ouvert et a donc réussi.
La solution consistait donc à débloquer le port 445.