Cours Ubuntu 26.04 / Créer un partage Samba à accès limité

Un partage Samba limité exige une authentification correcte, une règle d’accès au partage, des permissions Linux et un réseau autorisé. Ce laboratoire crée LabShare sur une VM Ubuntu dédiée, puis vérifie séparément un utilisateur admis, un utilisateur exclu et le transfert réel d’un fichier.

Définir les comptes et le réseau du laboratoire

Samba fournit des partages de fichiers utilisant SMB, Server Message Block, accessibles depuis Windows ou un client Linux. Gardez ce service dans un réseau local de confiance ou un VPN administré ; ne publiez pas directement SMB sur Internet. L’installation du paquet peut démarrer un service : préparez l’isolation réseau avant cette étape.

Ce cours concerne un serveur autonome neuf, pas un contrôleur de domaine Active Directory. Utilisez le réseau privé des VM du cours Ubuntu, avec le serveur 192.168.56.20 et le client Linux autorisé 192.168.56.10. Ces adresses sont des exemples à vérifier dans votre laboratoire ; l’hôte Windows peut avoir une autre adresse et n’est pas automatiquement couvert par la règle destinée au client .10.

Les comptes sharelab et sharedeny, le groupe ubuntu-share-lab, le partage LabShare et /srv/ubuntu-share-lab doivent être absents. Sur un serveur existant, inspectez les comptes locaux et Samba, les groupes, les inclusions de smb.conf et les autres partages avant toute modification. Ne réutilisez pas ces noms en changeant le mot de passe d’un compte existant.

Créer les identités et un répertoire neuf

Installez les paquets sur le serveur dédié. Le guide du serveur de fichiers Ubuntu situe la configuration principale dans /etc/samba/smb.conf :

sudo apt update
sudo apt install samba smbclient
getent passwd sharelab
getent passwd sharedeny
getent group ubuntu-share-lab
sudo pdbedit -L
sudo testparm -s
ls -ld /srv/ubuntu-share-lab

Les recherches de noms et de chemin doivent confirmer leur absence ; les commandes correspondantes peuvent alors renvoyer un état non nul. Arrêtez-vous si elles révèlent un objet existant ou une erreur d’annuaire à résoudre. N’interprétez pas toute erreur comme la preuve d’une absence.

Après cette inspection, exécutez le bloc de création. Il s’arrête en cas d’échec et refuse un chemin déjà présent, y compris un lien symbolique :

(
set -eu
if sudo test -e /srv/ubuntu-share-lab || sudo test -L /srv/ubuntu-share-lab; then
    printf 'Chemin déjà présent ; arrêt.\n' >&2
    exit 1
fi
sudo addgroup ubuntu-share-lab
sudo adduser --disabled-password --gecos "" --no-create-home --shell /usr/sbin/nologin --ingroup ubuntu-share-lab sharelab
sudo adduser --disabled-password --gecos "" --no-create-home --shell /usr/sbin/nologin sharedeny
sudo smbpasswd -a sharelab
sudo smbpasswd -a sharedeny
sudo mkdir -m 2770 /srv/ubuntu-share-lab
sudo chown root:ubuntu-share-lab /srv/ubuntu-share-lab
sudo chmod 2770 /srv/ubuntu-share-lab
id sharelab
id sharedeny
ls -ld /srv/ubuntu-share-lab
)

Saisissez les deux mots de passe Samba à leurs invites, sans les placer dans une commande ou une capture. sharelab doit appartenir au groupe autorisé et sharedeny doit en être exclu. La documentation Ubuntu des contrôles d’accès Samba explique que la base Samba est distincte des mots de passe de connexion Linux et exige d’abord un utilisateur Linux.

Les comptes utilisent nologin et n’ont pas de mot de passe Linux valide pour ce laboratoire ; cela ne désactive pas leur authentification Samba. Le manuel smbpasswd précise que -a appliqué à un compte Samba déjà présent change son mot de passe : l’inspection préalable reste nécessaire.

Dans le mode 2770, le bit setgid favorise l’héritage du groupe pour les nouveaux éléments, tandis que 770 réserve l’accès au propriétaire et au groupe. Ces permissions Linux n’autorisent pas tous les utilisateurs locaux ; les droits des répertoires parents et les éventuelles ACL comptent aussi. Évitez chmod 777 comme solution de dépannage.

Ajouter uniquement le partage et valider la configuration

(
set -eu
backup_dir=$(sudo mktemp -d /root/samba-lab.XXXXXX)
sudo cp -a /etc/samba/smb.conf "$backup_dir/smb.conf"
printf 'Sauvegarde : %s/smb.conf\n' "$backup_dir"
)
sudoedit /etc/samba/smb.conf

Notez le chemin de sauvegarde. Ajoutez une seule fois cette section au fichier existant, après avoir vérifié qu’aucun partage LabShare, y compris avec une autre casse, n’existe dans la configuration chargée. Conservez [global], les inclusions et les autres partages :

[LabShare]
    path = /srv/ubuntu-share-lab
    browseable = yes
    read only = no
    guest ok = no
    valid users = @ubuntu-share-lab
    create mask = 0660
    directory mask = 2770

Dans ce serveur autonome à groupes locaux, @ubuntu-share-lab désigne le groupe admis. guest ok = no refuse l’accès invité à ce partage ; browseable concerne sa visibilité, pas son autorisation. Les masques limitent les modes créés sans garantir que chaque fichier aura exactement 0660 : les permissions demandées et d’autres paramètres peuvent intervenir. Le manuel smb.conf détaille ces interactions.

sudo testparm -s
systemctl is-active smbd.service

Relisez les avertissements, les paramètres effectifs et le chemin de LabShare. testparm vérifie la cohérence interne, mais ne garantit pas qu’un client pourra utiliser le partage. Après réussite, si smbd est actif, demandez sa relecture :

sudo smbcontrol smbd reload-config
sudo ss -lntp
sudo journalctl -u smbd.service -n 50 --no-pager

Si le service n’est pas actif, examinez la configuration et ses journaux avant de tenter un démarrage. La relecture ne transforme pas les sessions déjà établies en nouvelles connexions ; fermez celles du laboratoire et reconnectez-vous pour les tests d’autorisation. Ne forcez pas la fermeture des sessions d’autres utilisateurs sur un serveur partagé.

Limiter l’accès réseau au client prévu

Le chemin direct utilisé ici emploie TCP 445. La découverte réseau et certains usages NetBIOS peuvent impliquer d’autres ports ; ils ne sont pas nécessaires pour tester directement //192.168.56.20/LabShare. L’absence du serveur dans une liste de découverte n’est donc pas une preuve d’échec du partage.

Sur cette VM gérée par UFW, préservez SSH et suivez la procédure d’activation et de vérification UFW. Quand le client a réellement l’adresse .10 et le serveur .20, ajoutez l’autorisation étroite suivante :

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 445 proto tcp
sudo ufw status numbered

Une règle étroite n’annule pas une autorisation générale antérieure. Vérifiez toutes les règles, les interfaces, IPv6 et le pare-feu de l’hôte. Si UFW est inactif, l’ajout de cette règle ne rend pas à lui seul le réseau filtré ; n’activez pas le pare-feu à distance sans la préparation de l’accès d’administration.

Tester séparément l’admission et le refus

Sur le client Linux .10, installez smbclient si nécessaire ; l’installation effectuée sur le serveur ne prépare pas le client :

sudo apt update
sudo apt install smbclient
smbclient //192.168.56.20/LabShare -U sharelab

À l’invite, saisissez le mot de passe Samba de sharelab. Une fois dans la session smbclient, exécutez les commandes suivantes, puis ouvrez une nouvelle connexion avec sharedeny :

ls
quit

smbclient //192.168.56.20/LabShare -U sharedeny

Avec le mot de passe correct de sharedeny, la connexion au partage doit être refusée, typiquement à l’étape tree connect avec NT_STATUS_ACCESS_DENIED. Un échec session setup avec NT_STATUS_LOGON_FAILURE indique un problème d’authentification et ne démontre pas la restriction de groupe. Revérifiez les comptes et les journaux si l’étape de refus n’est pas claire.

Depuis Windows, saisissez \\192.168.56.20\LabShare dans la barre d’adresse de l’Explorateur et utilisez le compte Samba prévu. Le client Windows doit être autorisé par son adresse réelle. Les identifiants ou connexions SMB déjà mémorisés peuvent réutiliser un autre compte ; inspectez les connexions du laboratoire avant de conclure, sans déconnecter arbitrairement les partages utiles.

Testez aussi depuis un réseau exclu, avec une nouvelle connexion. Une temporisation peut provenir du routage ou d’un autre filtre : comparez l’adresse source, les règles et les journaux. Le succès sur localhost ne couvre ni le trajet depuis un autre appareil ni le filtrage réseau.

Vérifier un aller-retour de fichier et conserver une issue de retour

Sur le client Linux, préparez un répertoire local neuf, puis connectez-vous en mode interactif. Le partage doit encore être vide ; si check.txt existe déjà à distance, choisissez un autre nom et adaptez toutes les commandes avant put, qui peut remplacer un fichier :

lab_dir=$(mktemp -d)
printf 'samba-lab\n' > "$lab_dir/check.txt"
cd "$lab_dir"
smbclient //192.168.56.20/LabShare -U sharelab

Dans smbclient, listez d’abord le contenu et confirmez l’absence du nom, puis envoyez et récupérez le fichier. Lisez le résultat de chaque opération avant la suivante :

ls
put check.txt check.txt
get check.txt downloaded.txt
quit

De retour dans le terminal du même répertoire :

cmp check.txt downloaded.txt

Un état de sortie nul sans différence confirme le contenu de cet aller-retour. Ce test ne remplace pas les essais de refus ni une sauvegarde. Le manuel smbclient décrit les commandes interactives ; ici les mots de passe restent saisis à l’invite et ne sont pas enregistrés dans la ligne de commande.

En cas d’échec, distinguez authentification, règle du partage, groupe réel, traversée du chemin, ACL, montage et éventuels refus AppArmor. Sur le serveur, contrôlez les groupes avec id et les fichiers créés avec ls -l ; n’accordez pas plus de droits au réseau pour résoudre un problème de permission locale.

Pour retirer le laboratoire, préservez ses données, enlevez seulement sa section de partage et sa règle UFW si vous l’avez créée ici, puis validez et relisez la configuration. Vérifiez les sessions actives. Avant de supprimer les comptes et le groupe de test, recherchez leurs autres usages et les fichiers qu’ils possèdent. La restauration entière de smb.conf ne convient que si elle n’écrase aucune modification ultérieure ; préférez un retour limité aux lignes de cet exercice.