locked
Accès lecteurs réseaux Windows 10 dans domaine Windows Server 2008 R2 RRS feed

  • Question

  • Bonjour,

    Lors de tests d'intégration de postes Windows 10 dans notre domaine (avec serveurs Windows Server 2008 R2), nous avons remarqué plusieurs "bugs", dont celui-ci:

    -les lecteurs réseaux ne montent pas automatiquement à l'ouverture de session (malgré les GPO)

    Nous avons dans notre domaine des postes sous Windows 7 qui fonctionnent parfaitement.

    Voici les différents tests que nous avons fait avec un compte administrateur du domaine :

    - Ping avec adresse IP, nom et alias : OK

    - Accès lecteurs réseaux avec IP et nom : OK (le protocole SMB2 autorise le compte à accéder aux dossiers partagés)

    - Accès lecteurs réseaux avec alias : KO ("Access denied" par SMB2)

    (Nous savons que le protocole utilisé est SMB2 grâce à Wireshark)

    Avez-vous une idée du problème?

    mercredi 19 septembre 2018 07:59

Réponses

  • C'est dommage de devoir lire des message "agressifs" (et qui ne permettent aucune aide à l'auteur de ce message) de votre part momonita sur un forum d'entraide.

    Philippe bart n'a plus à démontrer qu'il est quelqu'un de sérieux et efficace. Je vous invite à lire certains de ces posts pour vous rendre compte que c'est une des personnes les plus compétentes parmi celles qui répondent ici. Je ne dis pas ça parce qu'il a plus de 30 000 points, mais bien parce qu'il ne se contente pas toujours d'envoyer un lien vers un site web mais en explique aussi la raison comme il la fait ci dessous.Il a très certainement fourni la réponse à ce thread car si ca fonctionne avec l'IP et non pas le nom, c'est qu'il y a bien un soucis avec kerberos puisque la résolution du nom fonctionne. Mes connaissances personnelles s’arrêtaient la et c'est la raison pour laquelle je n'ai pas posté cette information. Elle n'aurait pas été suffisante pour pouvoir résoudre le problème.

    Dans son cas, il apporte non seulement la solution (via l'ajout de SPN) mais en plus il se permet, de part son retour d'expérience et ses compétence de proposer une meilleure méthode pour faire ce que l'utilisateur souhaite (utilisation du DFS).

    Je trouve pour ma part, son intervention toute à fait justifiée et elle permet de faire avancer la problèmatique de l'utilisateur. Il me semble que c'est bien le but de ce forum.

    Enfin : La modification du fichier host est à bannir dans un poste du domaine justement pour les raisons qu'il a évoqué. Cela peut servir à des fin de test pour diagnostiquer un problème mais pas plus.


    Merci de marquer comme reponses les interventions qui vous ont ete utile.




    lundi 24 septembre 2018 07:05

Toutes les réponses

  • Bonjour,

    Il est normal que ce soit smb 2 qui soit utilisé.

    2008r2 sait faire du smb 1 et 2.

    W10 sait faire du 1,2,3.

    Lors de la négociation de la communication, le protocole smb v2 sera donc choisi car c'est le meilleur de ceux qu'ils ont en commun.


    Merci de marquer comme reponses les interventions qui vous ont ete utile.

    dimanche 23 septembre 2018 17:38
  • - Accès lecteurs réseaux avec alias : KO ("Access denied" par SMB2)

    Tu as définit un Alias plutôt que le nom ou l'IP du serveur ? 

    Si oui ajoute dans le registre :

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
    Nom DWORD : DisableStrictNameChecking
    Valeur DWORD : 1

    Si tu utilises des Alias  (ce n'est pas recommandé comme solution), il faudrait également mettre à jour le SPN de l'objet ordinateur correspondant

    SETSPN -a host/nom_alias serveurcible
    SETSPN -a host/nom_alias.contoso.com serveurcible

    Les SPNs sont utilisés pour obtenir des tickets d'accès KErberos lorsque ce protocole est utilisé pour l'authentification.SMB V2

    Il est également préférable de crée un enregistrement A plutôt qu'un CNAME pour l'Alias à cause de l'authentification Kerberos.


    Si le nom n'est pas inclus dans le SPN et si tu utilises Kerberos tu aura forcément des accès refusé car le ticket d'accès que tu reçois du contrôleur de domaine pour accéder au serveur de fichier n'est pas valide pour ce nom.

    Maintenant si tu définis des Alias pour essayer de faciliter la gestion plutôt que d'utiliser le vrai nom du serveur, le plus simple dans un domaine c'est d'utiliser des espaces de noms DFS. DFS ne sert pas juste a faire de la réplication.

    NOTE : On ne modifie le fichier host qu'en dernier recours  et pour des raisons spécifiques. Il n'y a pas de raison de le faire si la résolution de nom fonctionne. Modifier le fichier host systématiquement c'est un peu une méthode de cochon ... De plus cela entraîne souvent des problèmes quelques temps après car on a oublié cette modification. DNS est généralement suffisant, sauf pour des serveurs isolés en DMZ par exemple.



    dimanche 23 septembre 2018 18:40

  • Le fichier host existe pour de vieille raison et pour certains cas particuliers , la résolution DNS assure ce rôle très bien et de manière centralisé. 

    C'est le principe même du DNS ! 

    Si le DNS  fonctionne il n'y a pas de raison de mettre en place de méthode parallèle individuel qui présente plus de problème en entreprise qu'il n'en résout. C'est juste une question de bon sens. 

    De plus en utilisant DNS il est possible d'activer DNSSec (depuis 2008) afin de signer et garantir  le résultat

    Certains code malveillants avait tendance à polluer le fichier host pour rediriger des noms sur d'autres adresses.

    C'est d'ailleurs clairement écrit dans le lien que vous postez :

    "The hosts file may present an attack vector for malicious software. The file may be modified, for example, by adwarecomputer viruses, or trojan horse software to redirect traffic from the intended destination to sites hosting malicious or unwanted content.

    Aussi ce vielle article datant d'avant DNSSec:

    https://technet.microsoft.com/en-us/library/bb727005.aspx

    The advantage of using a Hosts file is that users can customize it for themselves. Each user can create whatever entries they want, including easy-to-remember nicknames for frequently accessed resources. However, the individual maintenance required for the Hosts file does not scale well to storing large numbers of FQDN mappings or reflecting changes to IP addresses for servers and network resources. The solution for the large-scale storage and maintenance of FQDN mappings is DNS. The solution for the maintenance of FQDN mappings for changing IP addresses is DNS dynamic update. 

    Dans un domaine il est préférable d'utiliser des zones DNS intégrés AD, d'utiliser les mises à jours sécurisés AD (ne pas autoriser les mises à jours non sécurisé), activer DNSSEc est un plus.

    Le fichier host n'a pas de raison d'être polluer si la résolution fonctionne de manière centralisé et sécurisé avec DNS ...

    De plus les problèmes de résolution de noms sont rarement une réponse au erreur d'accès refusé. 

    Il n'y a donc pas de raison de faire cette modification.




    dimanche 23 septembre 2018 20:04
  • Et tu n'apportes pas d'alternatif au fichier hosts lorsqu'on a un accès refusé

    L'alternatif pour la résolution de nom c'est DNS et depuis très longtemps (Windows 2000, avant les domaines NT utilisait Wins et les noms courts ) .

    Elle n'est en aucun cas dans le fichier host lorsque tu as un message d'accès refusé. Le fichier host c'est pour faire de la résolution de nom tout comme DNS le fait de manière centralisé. 

    L'alternative à ne pas vouloir utiliser les noms physiques des serveurs de fichiers sous Windows est DFS qui existe depuis pas mal d'année.

    A vous écoutez il faudrait se passer de Windows car des virus s'infiltrent par d'autres voies pour atteindre le fichier hosts et ect

    Tu n'es pas obligé d'inventer les propos des autres ... 

     Si Windows 10 pouvait avoir la même consistence que Windows 7 on n'en serait pas là à modifier ce fichier hosts

    La différence entre les deux se situent dans les préférences de protocoles d'authentification. Certaines failles sont fermés sur Windows 10 pour des raisons de sécurité, c'est l'évolution normal des choses.

    Comme SMBV1 , comme les vieux  protocoles LAn Manager et NTLm V1. 

    En 2018 il représente un risque qui n'existait pas à l'époque.

    Un jour il ne sera plus conseillé d'utiliser NTLM V2, SMB V2 etc ... c'est dans l'ordre logique des choses 

    Un peu de lecture :

    https://blogs.msdn.microsoft.com/openspecification/2017/05/26/smb-2-and-smb-3-security-in-windows-10-the-anatomy-of-signing-and-cryptographic-keys/



    dimanche 23 septembre 2018 21:01

  • A vous écoutez il faudrait se passer de Windows car des virus s'infiltrent par d'autres voies pour atteindre le fichier hosts et ect

    Cette phrase n'est pas de moi et pourtant tu me l'attribue

     Et je parle toujours en mon nom et non pas au nom des autres comme tu le dis.

    Essaye à minima d'être cohérent.

    Hahaha! Tu l'as trouvé tout seul. Smbv1 est interdit et bien d'autres utilitaires ont été aussi interdits 

    Tu comprends la légère subtilité de sens entre "n'est pas recommandé" et "interdit" ?


    dimanche 23 septembre 2018 21:26
  • C'est dommage de devoir lire des message "agressifs" (et qui ne permettent aucune aide à l'auteur de ce message) de votre part momonita sur un forum d'entraide.

    Philippe bart n'a plus à démontrer qu'il est quelqu'un de sérieux et efficace. Je vous invite à lire certains de ces posts pour vous rendre compte que c'est une des personnes les plus compétentes parmi celles qui répondent ici. Je ne dis pas ça parce qu'il a plus de 30 000 points, mais bien parce qu'il ne se contente pas toujours d'envoyer un lien vers un site web mais en explique aussi la raison comme il la fait ci dessous.Il a très certainement fourni la réponse à ce thread car si ca fonctionne avec l'IP et non pas le nom, c'est qu'il y a bien un soucis avec kerberos puisque la résolution du nom fonctionne. Mes connaissances personnelles s’arrêtaient la et c'est la raison pour laquelle je n'ai pas posté cette information. Elle n'aurait pas été suffisante pour pouvoir résoudre le problème.

    Dans son cas, il apporte non seulement la solution (via l'ajout de SPN) mais en plus il se permet, de part son retour d'expérience et ses compétence de proposer une meilleure méthode pour faire ce que l'utilisateur souhaite (utilisation du DFS).

    Je trouve pour ma part, son intervention toute à fait justifiée et elle permet de faire avancer la problèmatique de l'utilisateur. Il me semble que c'est bien le but de ce forum.

    Enfin : La modification du fichier host est à bannir dans un poste du domaine justement pour les raisons qu'il a évoqué. Cela peut servir à des fin de test pour diagnostiquer un problème mais pas plus.


    Merci de marquer comme reponses les interventions qui vous ont ete utile.




    lundi 24 septembre 2018 07:05