Passage du nom d'utilisateur et du mot de passe UNC dans un chemin UNC

La réponse de Matt concernant le stockage des informations d'identification est la plus élégante pour un PC Windows moderne. Bien que cela ne soit pas précisé, le stockage des informations d'identification utilisé doit être celui du compte de service. C'est à la fois pour assurer la disponibilité du service et pour que les autres utilisateurs que vous ne voulez pas voir accéder à ce partage ne le puissent pas (par exemple, il s'agit plutôt de se souvenir de nettoyer les informations d'identification ajoutées par erreur sous le mauvais compte).

Mais s'il s'agit d'un ancien système d'exploitation Windows ou Linux, vous devrez peut-être opter pour un système un peu plus large.

Un PC hors domaine ne devrait pas vraiment se soucier des DFS auxquels il ne souscrit pas ou ne participe pas directement. Il a juste besoin de voir un chemin de partage (c'est-à-dire serveur/sharename). Les sharenames suppriment toutes les considérations relatives au chemin du serveur de fichiers hôte.

Honnêtement, il existe des moyens plus sûrs de se connecter à des partages que l'UNC URI. UNC et URI sont eux-mêmes un protocole de communication en texte clair.
Si c'est une sécurité acceptable... pourquoi ne pas simplement avoir un partage ouvert sans utilisateur ni mot de passe ?

La solution immédiate la plus simple serait de donner aux informations d'identification du service un accès direct à la connexion au partage (par exemple en faisant correspondre l'utilisateur et le mot de passe). À long terme, cette correspondance pas si évidente pourrait rendre difficile le fait de se souvenir de mettre à jour les permissions chaque fois que les choses changent. Et c'est aussi un domaine dans lequel MS pourrait changer une fois de plus la façon dont la sécurité passe les informations d'identification et casser les choses.

À long terme, la meilleure solution est probablement de mapper de façon permanente une lettre de lecteur local sur le partage réseau. Protégez le lecteur mappé avec des autorisations uniquement pour le service (et les administrateurs appropriés, etc.) et le nom de fichier peut être masqué par le caractère &.

Mais DFS donne un indice sur une solution plus élégante. Linux exige que les partages réseau soient d'abord montés ... généralement comme un répertoire dans le système de fichiers racine d'une manière très similaire à DFS. La commande mount de Linux permet de spécifier un fichier d'identification pour le nom d'utilisateur et le mot de passe, ce qui les rend plus faciles à mettre à jour et plus sûrs que la ligne de commande script ou fstab (c'est-à-dire la table du système de fichiers). Je suis presque sûr que les shells de commande Windows et DFS peuvent faire la même chose (cela fait un moment). Il s'agirait simplement d'un système DFS différent privé du PC cible pour incorporer des partages réseau montés en utilisant des informations d'identification stockées transmises par les services SMB et de connexion plutôt que codées en dur dans script et envoyées en texte clair UNC.

Demandez-vous également si ce PC non-domaine restera un PC non-domaine à long terme. Les serveurs de connexion Kerberos dans les domaines *NIX peuvent être liés aux domaines AD de Windows. C'est probablement ce que vous voulez faire pour tout projet sérieux à long terme impliquant plus de quelques personnes. D'un autre côté, c'est probablement trop pour la plupart des réseaux domestiques. Mais si vous utilisez DFS pour une raison autre qu'un défi personnel d'amateur, c'est probablement la meilleure solution.