Monter un partage de fichiers VPN avec le compte Samba que le serveur connaît

Connectez le tunnel et le partage demande encore un mot de passe que l’utilisateur croit correct. Dans un déploiement Samba autonome, la connexion VPN et la connexion SMB sont des identifiants sans rapport : l’une autorise le tunnel, l’autre est vérifiée par le serveur de fichiers. Monter le lecteur avec le compte VPN échoue donc même lorsque le mot de passe est correct et le chemin réseau parfait. Cette distinction explique la plupart des échecs de montage à travers un VPN.

La solution n’est pas de réinitialiser le compte VPN. Elle est de nommer une identité que le serveur Samba connaît réellement, puis de vérifier que cette même identité dispose de droits sur le partage et le répertoire.

La connexion VPN et la connexion SMB sont des identités différentes

Un compte VPN est évalué par la passerelle VPN selon sa propre politique. Elle répond si ce client peut entrer sur le réseau privé. Elle ne dit rien du compte SMB qui existe sur un serveur de fichiers au sein de ce réseau.

Un compte Samba réside dans le backend d’authentification du serveur, avec sa propre base de mots de passe et son propre nom. Deux machines peuvent toutes deux avoir un utilisateur nommé alice sans partager un système d’identité, un mot de passe ni un identifiant utilisateur. Les noms coïncident ; les comptes non.

Un serveur Samba intégré au domaine change la donne : l’identité vient de l’annuaire et de Kerberos, pas d’une liste locale de comptes. Dans ce cas, utilisez l’identité de l’annuaire et la configuration SMB prise en charge plutôt que de créer des doublons locaux pour imiter l’appartenance au domaine. Vérifiez quel modèle le serveur utilise avant de créer le moindre compte.

Voyez quelle identité Windows utilise réellement

Windows met en cache les connexions par serveur. Si une session existante vers le même serveur a été ouverte avec un autre compte, un nouveau montage peut réutiliser cette session ou échouer avec une erreur d’authentification qui nomme le mauvais utilisateur. C’est ainsi qu’un mot de passe correct paraît faux. Inspectez les connexions en cours avant de changer d’identifiants.

net use
cmdkey /list
klist

La première commande affiche les lecteurs montés et les sessions ouvertes, la deuxième les identifiants enregistrés qui peuvent être appliqués automatiquement, et la troisième les tickets Kerberos lorsqu’un domaine est utilisé. Un identifiant enregistré peut remplacer silencieusement le compte que vous vouliez saisir.

Supprimez uniquement la connexion ou l’identifiant lié à ce problème. Déconnecter tous les lecteurs ou remplacer le nom du serveur par une adresse IP masque le choix d’identité et peut casser la signature ou les politiques fondées sur les noms.

Montez le partage avec le compte reconnu par le serveur

Indiquez le compte sous la forme attendue par le serveur et laissez Windows demander le mot de passe, afin que le secret ne finisse pas dans l’historique des commandes ni dans un script :

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

Le composant serveur avant la barre oblique inverse est le contexte d’identité du serveur Samba, pas la passerelle VPN. L’astérisque demande une invite de mot de passe interactive, et /persistent:no garde le montage hors de la prochaine ouverture de session. Choisissez une lettre de lecteur libre.

Si le serveur est intégré au domaine, le composant utilisateur peut être à la place un nom d’annuaire ou une identité qualifiée par le domaine. Utilisez la forme documentée par l’administrateur ; inventer un compte local du même nom crée une seconde identité et un second mot de passe à maintenir.

Validité du compte, accès au partage et droits du système de fichiers sont trois contrôles

Samba vérifie si l’identité s’authentifie, si la définition du partage l’admet, et si le système de fichiers accorde l’opération demandée. Réussir le premier contrôle n’implique pas les deux autres. Un partage peut être visible et refuser malgré tout les écritures parce que les permissions du répertoire en décident ainsi.

Un partage restreint avec valid users n’admet que les comptes ou les groupes listés. Le compte peut s’authentifier correctement et être malgré tout rejeté par cette ligne. Vérifiez la définition du partage avant de conclure que le mot de passe est faux.

Côté système de fichiers, le processus Samba et l’identité montée comptent tous deux. Un répertoire appartenant à root avec le mode 700 n’acceptera pas les écritures d’un compte ordinaire même lorsque la définition du partage l’autorise. Testez avec une lecture, puis une écriture, dans un répertoire que le compte est censé utiliser.

Résolvez une session en conflit sans casser la politique

Lorsqu’une session obsolète est la cause, fermez cette seule connexion et montez de nouveau avec le compte prévu. Si un identifiant enregistré revient sans cesse, supprimez cet identifiant plutôt que la liste complète des lecteurs. Confirmez ensuite la nouvelle session avec net use.

Conservez la signature SMB, le chiffrement et la politique de comptes exigés. Un serveur qui refuse une session non signée ou non chiffrée applique sa politique, il ne lit pas mal le mot de passe, et l’affaiblir pour faire réussir le montage échange de la sécurité contre un symptôme.

Notez le nom du serveur, la forme exacte du compte et les droits de partage et de répertoire qui ont fonctionné. Sinon, la prochaine personne qui monte le lecteur essaiera d’abord la connexion VPN, car ce sont les identifiants avec lesquels elle a atteint le réseau.