web-dev-qa-db-fra.com

Comment diagnostiquer un échec de connexion NAS SMB?

J'ai un boîtier NAS (Noontec N5) avec lequel je peux uniquement interagir via une interface Web (c'est-à-dire non ssh). Cela me permet d’exposer le service SMB et d’ajouter des utilisateurs, avec ou sans mot de passe.

Je peux me connecter anonymement, par exemple. avec smbclient -L 10.1.0.25 -UGuest et sans mot de passe:

~ • smbclient -L 10.1.0.25 -Uguest
Enter guest's password: 
Anonymous login successful
Domain=[R] OS=[R] Server=[R]

    Sharename       Type      Comment
    ---------       ----      -------
    PUBLIC          Disk      
    IPC$            IPC       
Anonymous login successful
Domain=[R] OS=[R] Server=[R]

    Server               Comment
    ---------            -------

    Workgroup            Master
    ---------            -------

Je ne peux pas me connecter avec un mot de passe cependant:

~ • smbclient -L 10.1.0.25 -Ujason
Enter jason's password: 
session setup failed: NT_STATUS_LOGON_FAILURE

Ce même nom d'utilisateur fonctionne si je supprime le mot de passe et me connecte sans ce mot de passe (identique à l'identifiant "invité").

Comment est-ce que je peux diagnostiquer ceci davantage, ou le réparer?

Mise à jour: informations sur le groupe de travail

Le groupe de travail utilisé pour le périphérique est SUNNYDALE:

~ • nmblookup -A 10.1.0.25 | grep GROUP 
    SUNNYDALE       <00> - <GROUP> B <ACTIVE>

Ajouter ceci à la commande smbclient n'aide pas (c'est maintenant aussi dans /etc/samba/smb.conf):

~ • smbclient -L 10.1.0.25 -W SUNNYDALE -U jason
Enter jason's password: 
session setup failed: NT_STATUS_LOGON_FAILURE

Mise à jour: autres systèmes d'exploitation

J'ai trouvé un ordinateur sous XP OS X et Windows à tester, et les deux peuvent se connecter très bien. Il semble y avoir une certaine magie que smbclient ne connaît pas (ce qui ne minimise pas la possibilité que cela ne soit pas dans le protocole officiel SMB _).

Mise à jour: mount.cifs

J'ai également essayé d'utiliser mount.cifs, avec tous les types d'option sec= et vers= différents répertoriés dans la page de manuel, sans succès.

Mise à jour: Wirehark

J'ai utilisé Wireshark pour capturer des paquets entre Windows XP test VM et le NAS. Il semble que XP essaie à plusieurs reprises diverses combinaisons de noms de domaine et de protocoles de sécurité jusqu'à ce que quelque chose fonctionne. La dernière tentative (réussie) semble utiliser SMB pour le nom de domaine et NTLMSSP pour l'authentification.

Essayer ces réglages avec smbclient et mount.cifs ne fonctionnait pas.

sambanas
2
detly

Étant donné que la question concerne les diagnostics plutôt que la solution éventuelle, je vais décrire ce que j’ai essayé qui m’a rapproché de la solution (les mises à jour de la question en résument la majeure partie).

Lors de la lecture du résultat de la commande ci-dessous, notez que mon NAS s'appelle giles et que le nom de domaine est SUNNYDALE. Mon nom d'utilisateur local, et celui sur la boîte est jason. J'ai défini un mot de passe de test de abcd pour cela.

Spoiler: c'était la méthode d'authentification.

Le problème était que le lecteur NAS ne semble fonctionner que lorsque l'authentification NTLM est utilisée à partir d'Ubuntu; la plupart des utilitaires utilisent NTLMv2 par défaut ou une variante de ceux-ci. J'ai été contrarié par le fait que les premiers outils que j'utilisais ne me permettaient pas de contrôler cela.

Gardez la boîte éveillée

La plupart des NAS boîtiers mettent le lecteur en veille après une période d'inactivité. En règle générale, c'est une bonne chose, mais cela peut provoquer des erreurs de résolution de nom ou d'authentification lors des diagnostics, en fonction des outils utilisés.

Désactivez la fonctionnalité veille lorsque vous êtes inactif pendant le débogage ou laissez l'interface Web ouverte dans un navigateur et actualisez-la régulièrement pour vous assurer qu'elle est opérationnelle. N'oubliez pas de le réactiver lorsque vous avez terminé!

Assurez-vous que vous pouvez le résoudre

Assurez-vous d'abord que vous pouvez résoudre le NAS. Utilisez nmblookup:

~ • nmblookup giles
192.168.1.114 giles<00>

Si vous ne le voyez pas, vous devrez peut-être installer le package libnss-winbind (c'est-à-dire avec Sudo apt-get install libnss-winbind) et éditer /etc/nsswitch.conf. Cherchez une ligne commençant par hosts: et placez wins quelque part:

hosts:          files mdns4_minimal [NOTFOUND=return] dns wins mdns4

(Veuillez noter que je ne suis pas un expert sur ces paramètres; enregistrez ce que la ligne était avant si vous rencontrez des problèmes plus tard.)

Utilisez mount.cifs, pas smbclient

J'ai trouvé que smbclient n'avait pas intercepté mon problème car il ne vous permettait pas d'ajuster les paramètres d'authentification. L'utilitaire mount.cifs le fait cependant. Il y a quelques autres détails sur lesquels vous donne plus de contrôle, par exemple. la version du protocole SMB utilisée. Cette session de terminal montre comment vous pouvez essayer différents domaines et méthodes d'authentification:

~ • mkdir temp
~ • Sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • Sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlmv2
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • Sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlm
~ •

(Cette dernière commande a réussi.)

Notez que mount.cifs risque toutefois d’obtenir des échecs parasites, par exemple:

~ • Sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error: could not resolve address for giles: Unknown error
~ • Sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Parfois, j'ai même une erreur d'authentification au premier essai mais pas au suivant. Essayez chaque commande deux ou trois fois pour être sûr.

Remplacer les paramètres/paramètres par défaut de l'outil smb.conf

Soyez prudent lors du débogage de SMB problèmes que vous ne vous fiez pas aux valeurs par défaut dans /etc/samba/smb.conf ou mount.cifs (ou quel que soit l'outil que vous utilisez). En particulier, le groupe de travail (ligne commençant par workgroup =) et la méthode d'authentification (client ntlm auth = ..., par exemple, avec plusieurs lignes pour différents protocoles).

Notez que dans la session de terminal mount.cifs ci-dessus, je spécifie toujours le domaine lors du changement de méthode d'authentification. Soyez scientifique! Changer une et une seule chose à chaque fois. Si cela vous ennuie, écrivez un script!

Essayez différents groupes de travail

Comme Ben Grimm souligne , ces cases ignorent parfois le groupe de travail que vous leur avez attribué. Essayez l'une des solutions suivantes:

  • GROUPE DE TRAVAIL
  • SMB

Trouver une machine Windows ou OS X

Ceci est une vérification de base: si vous pouvez vous connecter depuis une machine Windows ou Mac, il devrait au moins être possible (même si difficile) de se connecter à partir d'Ubuntu. Si vous ne pouvez pas vous connecter depuis une autre machine, revenez au début et essayez de configurer les choses jusqu'à ce que vous le puissiez.

Dans mon cas, je n'avais pas de machine non Linux à essayer au début. Finalement, j'ai trouvé un vieux XP VM (c'était une sauvegarde d'une machine d'il y a des années). Je me suis rendu compte que je pouvais me connecter au NAS tout va bien! Cela m'a conduit à ma prochaine tactique…

Wireshark

Wireshark est un programme qui inspecte et vide les paquets transitant par une interface de votre ordinateur. Une fois que j'ai réalisé que mon XP VM pouvait se connecter, il était devenu une question de savoir ce que cette machine était en train de faire, ce que ma machine Ubuntu n'était pas.

Wireshark ne surveille que les interfaces de l'ordinateur sur lequel il est exécuté. Cela signifie que vous devez l'exécuter sur une machine située entre vos machines de test et la zone NAS. Je ne vais pas vous donner un tutoriel complet sur le routage, etc. ici, mais cela a fonctionné pour moi car je l'ai exécuté sur la machine hébergeant la machine virtuelle XP, de sorte que tous les paquets passaient par eth0 en ce qui concerne Wireshark.

Dans mon cas, le XP VM avait l'IP 192.168.1.111 et le NAS avait l'IP 192.168.1.114. Donc, le filtre de capture que j'ai utilisé dans Wireshark était:

(Host 192.168.1.111) and (Host 192.168.1.114)

Alors je:

  • démarrage de la machine virtuelle XP
  • a commencé la capture
  • dans le XP VM j'ai lancé l'Explorateur, entré \\giles\jason et cliqué enter
  • entré mes informations d'identification et le domaine
  • une fois le partage ouvert, je suis retourné à Wireshark et ai arrêté la capture.

À ce stade, j’ai parcouru les paquets en utilisant Edit > Find packet... et en sélectionnant l’option "by string". Je viens de rechercher mon nom d'utilisateur et la première tentative d'authentification réussie. Vous pouvez voir quels sont un avec succès en cherchant STATUS_LOGON_FAILURE quelques paquets plus tard.

Ce qui m'a surpris, c'est le nombre incroyable de tentatives de XP. Il utilisait le nom d'utilisateur et le nom de domaine donnés. Parfois, il utilisait WORKGROUP ou SMB ou même le nom du client comme domaine, et il tentait plusieurs méthodes d'authentification.

Curieusement, je n'ai même jamais identifié la tentative réussie! C’est à ce moment-là que j’ai réalisé que smbclient n’allait pas aider, puis je suis retourné à mount.cifs et je l’ai utilisé beaucoup plus scientifiquement.

Une note sur NTLM et Nautilus/GVFS

Enfin, après avoir identifié le problème et accédé au partage via mount.cifs, je n’ai toujours pas réussi à connecter Nautilus. Le problème ici est que Nautilus utilise GVFS pour monter les partages SMB, et GVFS utilise NTLMv2 par défaut.

Vous pouvez modifier cela à l'échelle du système en modifiant /etc/samba/smb.conf et en ajoutant:

   client ntlm auth = yes
   client ntlmv2 auth = no

J'ai ajouté ceci juste en dessous du paramètre workgroup = .... Toutefois, cela forcera la modification pour tous les SMB partages que GVFS a tenté de monter, ce qui pourrait rendre les autres partages inaccessibles.

(Pour une raison quelconque, mount.cifs se plaint de cette première ligne, mais testparm ne le fait pas. Peut-être que cela peut être supprimé, mais je ne suis pas prêt à essayer.)

5
detly

Avec ces cases, il semble que forcer le groupe de travail est nécessaire:

smbclient -L 10.1.0.25 -W WORKGROUP -U jason

Vous pouvez vérifier le groupe de travail de la boîte en lançant:

$ nmblookup -A 10.1.0.25 | grep GROUP 
    ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
    WORKGROUP       <00> - <GROUP> B <ACTIVE>
    WORKGROUP       <1e> - <GROUP> B <ACTIVE>
2
Ben Grimm

Je recevais le message NT_STATUS_LOGON_FAILURE mais aussi:

Server does not support EXTENDED_SECURITY  but 'client use spnego = yes and 'client ntlmv2 auth = yes'

Pour résoudre le problème, j'ai dû ajouter la ligne

use spnego = no

vers la boîte client linux

/etc/samba/smb.conf

(dans la partie supérieure avant le [global])

Maintenant, si je me connecte à mon NAS, cela fonctionne et je reçois:

root@localhost:~# smbclient -L \\\\192.168.1.1\\ -U admin
WARNING: The "syslog" option is deprecated
Enter admin's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.33]

        Sharename       Type      Comment
        ---------       ----      -------
        ipc$            IPC       IPC Service (SERVERUS)
        Backup          Disk      8tb_Seagate_2's Backup in Seagate Backup+ Hub BK
        dropbox         Disk      Toshiba_EXT's dropbox in Toshiba External USB 3.0
        WindowsImageBackup Disk      Toshiba_EXT's WindowsImageBackup in Toshiba External USB 3.0
        Rug             Disk      Seagate_8tb_1's Rug in Seagate Backup+ Hub BK
        drive_backup    Disk      Toshiba_EXT(1)'s drive_backup in Toshiba External USB 3.0
        ntfsck.00000000 Disk      Toshiba_EXT(1)'s ntfsck.00000000 in Toshiba External USB 3.0
        archive         Disk      Seagate_Backup_Plus_Drive's archive in Seagate Backup+ Hub BK
        data_dump       Disk      Seagate_Backup_Plus_Drive's data_dump in Seagate Backup+ Hub BK
        Decimus_bac     Disk      Seagate_Backup_Plus_Drive's Decimus_bac in Seagate Backup+ Hub BK
        images          Disk      Seagate_Backup_Plus_Drive's images in Seagate Backup+ Hub BK
        Net             Disk      Seagate_Backup_Plus_Drive's Net in Seagate Backup+ Hub BK
        share           Disk      Seagate_Backup_Plus_Drive's share in Seagate Backup+ Hub BK
        test            Disk      Seagate_Backup_Plus_Drive's test in Seagate Backup+ Hub BK
        tools           Disk      Seagate_Backup_Plus_Drive's tools in Seagate Backup+ Hub BK
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.33]

        Server               Comment
        ---------            -------
        LIBREELEC            LibreELEC
        SERVERUS             SERVERUS

        Workgroup            Master
        ---------            -------
        WORKGROUP            LIBREELEC
0
Pitpat

Je recevais le message NT_STATUS_LOGON_FAILURE mais aussi:

Server does not support EXTENDED_SECURITY  but 'client use spnego = yes and 'client ntlmv2 auth = yes'

Pour résoudre le problème, j'ai dû ajouter la ligne

use spnego = no

vers la boîte client linux

/etc/samba/smb.conf

(dans la partie supérieure avant le [global])

Maintenant, si je me connecte à mon NAS, cela fonctionne et je reçois:

root@localhost:~# smbclient -L \\\\192.168.1.1\\ -U admin
WARNING: The "syslog" option is deprecated
Enter admin's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.33]
0
San7ace