Le partage de fichiers : optimiser SMB sur Mac

Classé dans : À la une, Logiciels et solutions | 0

Au gré des mises à jour de macOS, Apple a pu subtilement modifier le comportement du protocole SMB, ce qui conduit à quelques surprises, parfois désagréables. Voici quelques point interessants à connaitre.

Serveur Mac, partages SMB et Clients Windows : le casse-tête NTLM

Après la mise à jour d’un serveur Mac vers macOS 10.10 (Yosemite) ou supérieur, nombreux sont ceux qui constataient une incapacité de leurs postes clients Windows à se connecter aux partages SMB hébergés par le serveur en question. Cela n’est pas dû au hasard : depuis Yosemite, certaines choses ont changé. Par exemple, l’authentification NTLM peut se retrouver désactivée sur un serveur Mac. Mais surtout, depuis cette version, il est très important de savoir qu’un serveur Mac n’autorise plus l’authentification des Clients avec NTLM v1. Seule l’authentification avec NTLM v2 est supportée. Et cela ne va pas sans causer quelques problèmes…

Voici quelques astuces à connaitre pour gérer la situation.

Activer l’authentification NTLM sur le serveur macOS

Pour rappel, NTLM (acronyme de NT Lan Manager) est un protocole d’identification utilisé dans diverses implémentations des protocoles réseaux Microsoft. Lorsqu’on tente de connecter un client Windows à un serveur Mac, il est donc interessant de vérifier que l’authentification NTLM est bien activée sur notre serveur. Car non, ce n’est pas systématiquement le cas.

La commande Terminal suivante permet d’en savoir plus sur la configuration smb du serveur macOS et de vérifier si NTLM est activé :

sudo serveradmin settings smb

En cas de nécessité, activer NTLM est possible par la commande Terminal suivante :

sudo serveradmin settings smb:ntlm auth = "yes"

 

Forcer l’authentification d’un client Windows avec NTLM v2

Comme indiqué précédemment, un serveur Mac sous Yosemite ou supérieur ne permet plus à un Client Windows de s’authentifier par NTLM v1. Hors, il est encore fréquent que les postes Windows soient configurés pour une authentification NTLM v1 uniquement.

Le problème est assez facilement identifiable du côté du serveur Mac, dans la Console où on voit apparaitre des logs de ce type, confirmant que le client utilise la v1 de NTLM :

od failed with 2 proto=ntlmv1

user=domain\\username

kdc failed with -1561745600 proto=ntlmv1

Pour arranger cela, tout se joue côté client dans la base de registre de Windows, au niveau de la clé LmCompatibilityLevel située à cet endroit :

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Souvent positionnée à la valeur « 0 », elle empêche Windows d’utiliser NTLM v2. Remplacer cette valeur par la valeur « 3 » permet régler le problème.

Une note technique de Microsoft permet d’en savoir plus sur les valeurs possibles et leurs implications, afin d’ajuster le comportement du client comme désiré.

 

Autoriser l’authentification NTLM v1 directement sur le serveur macOS

La méthode précédente au niveau des clients Windows règle très efficacement ce problème d’authentification NTLM. Cependant, il n’est pas toujours possible de la mettre en oeuvre. Certaines contraintes de type GPO ou règles locales diverses et variées peuvent nous empêcher d’effectuer ce type de modification sur le poste client.

S’il n’est pas possible d’agir coté client, une autre solution consiste alors à agir coté serveur, afin de rajouter le support de NTLM v1.

Pour connaitre quelle version de NTLM est autorisée, macOS Yosemite (et supérieur) interroge le fichier /Library/Preferences/com.apple.GSS.NTLM.plist

La subtilité vient du fait que ce fichier n’existe pas par défaut dans une installation fraiche de macOS. Il est alors nécessaire de le créer, avec le contenu suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NTLMv1</key>
<true/>
<key>NTLMv2</key>
<true/>
</dict>
</plist>

Après un redémarrage, le serveur acceptera l’authentification des clients NTLM v1 et NTLM v2.

 

Comment régler les problèmes de performances SMB depuis macOS 10.11.5 et supérieur ?

Depuis la mise à jour macOS El Capitan 10.11.5, beaucoup d’utilisateurs se plaignent d’une dégradation importante des performances lors de transferts de fichiers en SMB sur des serveur ou des NAS. La raison est extrêmement simple. El Capitan dans sa version 10.11.5 active par défaut la signature des paquets sur les protocoles SMB 2 et SMB 3.

En soit, cela constitue un plus pour la sécurité. Dans les faits, dans la plupart des cas, le Mac et le serveur sont sur le même réseau sécurisé. Dans les autres cas, personne ne devrait permettre l’utilisation de SMB par internet ou des réseaux non sécurisés…

Vérifier l’état de la signature des paquets SMB

Rien de plus simple. Après avoir monté le partage SMB concerné, taper la commande suivante dans le Terminal permet d’obtenir des informations sur le partage SMB :

smbutil statshares -a

L’entrée SMB_VERSION révèle quelle version du protocole SMB est utilisée.

L’entrée SIGNING_SUPPORTED indique si le serveur hébergeant le partage supporte la signature des paquets. Attention, cela ne signifie pas qu’elle est activée ! C’est l’entrée SIGNING_ON qui révèle la bonne réponse…

Désactiver la signature des paquets SMB sur un client Mac

Tout se passe dans le fichier /etc/nsmb.conf. Il suffira d’ouvrir ce fichier et de rechercher l’entrée suivante :

[default]
 signing_required=yes

Remplacez la valeur « yes » par « no », déconnectez votre partage SMB.

Le prochain montage se fera sans utiliser la signature des paquets SMB, et les performances devraient s’en trouver grandement améliorées.

Si le fichier /etc/nsmb.conf n’existe pas (cas par défaut dans une installation macOS), tapez l’ensemble de commandes suivant dans le Terminal pour le créer avec l’entrée adéquate :

sudo -s
 echo "[default]" >> /etc/nsmb.conf
 echo "signing_required=no" >> /etc/nsmb.conf
 exit

ATTENTION : si le serveur hébergeant les partages SMB est configuré pour imposer la signature, le fait de la désactiver du côté des clients Mac va logiquement rendre inopérante la connectivité SMB vers ce serveur !

Il est alors possible de revenir en arrière. Un sudo rm /etc/nsmb.conf dans le Terminal supprimera le fichier et rétablira la signature des paquets SMB.

 

Désactiver la signature des paquets sur un serveur Mac hébergeant des partages SMB

Si vos partages SMB sont hébergés sur un serveur Mac, vous pouvez désactiver la signature des paquets directement du coté serveur dans le Terminal :

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server SigningRequired -bool FALSE
sudo /usr/libexec/smb-sync-preferences

L’opération permettant de revenir en arrière et de réactiver la signature des paquets SMB côté serveur est :

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server SigningRequired -bool TRUE
sudo /usr/libexec/smb-sync-preferences

 

Empêcher macOS d’utiliser les fichiers .DS_Store sur un partage SMB

Lors de l’ouverture d’un dossier, macOS collecte les métadonnées des fichiers, les compare avec le fichiers .DS_Store du dossier en question, puis affiche le contenu du dossier. Il est possible de désactiver ce comportement sur des partages réseau SMB afin d’améliorer la vitesse de consultation.

Dans le Terminal, tapez la commande suivante :

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Un redémarrage de la session et le tour est joué ! Le Finder utilisera les informations par défaut pour afficher instantanément les contenus par ordre alphanumérique. Inconvénient : nous perdons la personnalisation de l’affichage des dossiers. Mais c’est un choix à faire, entre vitesse ou personnalisation de l’affichage…

B. Massey