Est-il possible de passer le nom d'utilisateur et le mot de passe UNC dans un chemin UNC ?
De la même manière que pour le FTP et le SMB :
smb://user:pass@destination.com/share
ftp://user:pass@destination.com/shareJ'essaie de permettre à un service (PC hors domaine) d'accéder à un chemin DFS.
Y a-t-il un autre moyen de contourner ce problème ? Je pourrais lier le PC au domaine et exécuter le service en tant qu'utilisateur du domaine, mais que se passerait-il si j'utilisais Linux ?
Sous Windows, vous ne peut pas mettre les informations d'identification dans des chemins UNC. Vous devez les fournir en utilisant net use , runas /netonly ou lorsque Windows le demande.
Vous pouvez également enregistrer le mot de passe en tant que "justificatif de domaine" en utilisant la méthode suivante cmdkey /add: ou en utilisant la fonction CredWrite() en C, ce qui équivaut dans les deux cas à cocher la case "Mémoriser le mot de passe" dans Windows.
Sous Linux, cela dépend du programme.
Le Gvfs de GNOME accepte l'option user@host mais semble ignorer complètement le mot de passe. (Cependant, vous pouvez le stocker au préalable dans le trousseau GNOME).
smbclient utilise la même syntaxe UNC que Windows ; cependant, il dispose d'une fonction --authentication-file à partir duquel les informations d'identification peuvent être lues.
Les deux programmes ci-dessus utilisent libsmbclient et peut utiliser l'authentification Kerberos au lieu des mots de passe : run kinit user@YOUR.DOMAIN et utiliser smbclient -k //host/share . Cette méthode est plus sûre que l'authentification par mot de passe.
Notez que le fait de mettre des mots de passe dans les URI est déprécié, et vous ne devriez pas compter sur le fait que cela soit supporté. partout .
Je pense que le nom d'utilisateur et le mot de passe doivent être transmis au serveur pour l'authentification avant tout accès au fichier, donc le code gérant la connexion SMB doit être capable d'analyser et d'extraire le nom d'utilisateur et le mot de passe de l'URL. Vous devrez vérifier si ce code supporte ce format ou non.
Si ce n'est pas le cas, vous pouvez monter ce partage SMB via SAMBA et demander à votre programme d'utiliser ce chemin "local". Vous pouvez placer le montage dans fstab et utiliser un fichier de mots de passe SAMBA pour fournir les informations d'identification de l'utilisateur. N'oubliez pas de définir les autorisations correctes pour le fichier de mots de passe afin que les utilisateurs normaux ne puissent pas le lire.
Notez que c'est une mauvaise pratique de stocker les mots de passe en texte clair dans les fichiers de configuration, donc même si votre programme peut gérer le mot de passe dans l'URL, vous devriez envisager la méthode du partage monté.
Vous pouvez ajouter les informations d'identification dans Panneau de configuration/Utilisateurs/Gestionnaire d'informations d'identification Windows afin que les informations d'identification soient mises en cache. Vous devez ajouter le nom du périphérique (server.domain.local) avec le nom d'utilisateur/mot de passe du domaine, puis vous devriez pouvoir accéder au partage sans avoir à fournir à nouveau les informations d'identification.
Un PC ne faisant pas partie d'un domaine ne devrait pas vraiment se préoccuper du DFS auquel il n'est pas abonné ou auquel il 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 consisterait à 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 d'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 facilite leur mise à jour et les rend 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. Pr
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
