Bonjour,
sur une machine Linux (Debian squeeze/testing), j'aurais besoin de me connecter à un répertoire partagé d'un serveur XP Pro.
Le répertoire étant protégé par un mot de passe, j'ai trouvé sur le net que l'on pouvait utiliser un fichier ".smbcredential" contenant en clair le login/password du Windows. Comme par exemple http://www.michel-eudes.net/blog/index.php?2007/03/09/29-fai(...)
Ce stockage en clair du mot de passe n'étant pas très sécurisé, je me demandais si il n'y avait pas une autre manière de faire.
Sur la machine Linux, je peux notamment installer un serveur Samba, et utiliser la commande "smbpasswd" afin de sauver dans une base de données "tdbsam" le même couple login/password du serveur XP Pro.
A partir de là, est-ce qu'il serait possible d'utilisé ce le mot de passe chiffré dans tdbsam, afin de s'authentifier auprès du Windows ? Sachant que pour s'authentifier auprès d'un Windows, ce n'est pas le mot de passe qui est envoyé sur le réseau, mais son "hash", ou quelque chose équivalent.
Merci d'avance pour vos réponses.
Forum Linux.général Alternative sécurisé à ~/.smbcredential
5
juil.
2010
# Domaine ?
Posté par ze_lionix (site web personnel) . Évalué à 2.
Sinon je pense que si tu fait entrer ta machine dans le domaine windows, les politiques de droits du domaine s'appliqueront, et donc il devrait y avoir matière à faire joujou peut-être :
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/d(...)
Ca se tente...
Fuse : j'en Use et Abuse !
[^] # Re: Domaine ?
Posté par Olivier (site web personnel) . Évalué à 1.
Le montage doit se faire via un script, et l'idée était qu'il soit autonome... :=(
Sinon je pense que si tu fait entrer ta machine dans le domaine windows
Le PC Windows est en tout seul dans le réseau.
Par contre, l'idée est bonne :
- Je pourrai transformer la machine Linux en un contrôleur de domaine pour le Windows
- Le Linux interrogerait le Windows pour accéder au répertoire partagé, celui-ci demandant au PDC (Linux) si il peut y accéder.
C'est un peu tordu comme idée, mais intéressant.
Merci pour l'idée
# entree dans la fstab
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: entree dans la fstab
Posté par Olivier (site web personnel) . Évalué à 1.
Et c'est cette limitation-là que je veux éliminer.
D'où ma question : Comment faire pour que se connecter à une machine MS, sans que le mot de passe ne soit pas sauvé en clair (et que, bien sûr, l'utilisateur n'ait pas à le taper) ?
# Stockage en clair
Posté par Kerro . Évalué à 3.
Hélas non.
L'idéal serait un accès par clef publique/privée, mais il ne faut pas trop rêver.
# chmod ?
Posté par Stéphane Gully (site web personnel) . Évalué à 2.
chmod go-rwx ~/.smbcredentialne peut il pas faire l'affaire ?[^] # Re: chmod ?
Posté par Olivier (site web personnel) . Évalué à 1.
Mais le contenu du fichier reste visible de la part de son propriétaire, et c'est quand même un mot de passe.
Je pourrai sécuriser un peu plus les choses en ne laissant qu'au root un accès en lecture au fichier, et en utilisant un sudo pour faire le montage. Mais le mot de passe restera toujours en clair.... :=(
[^] # Re: chmod ?
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: chmod ?
Posté par Olivier (site web personnel) . Évalué à 1.
Mais ce mot de passe (utilisé pour le partage de fichier) permet aussi d'avoir un login sur la machine Windows, donc il serait préférable d'éviter de corrompre 2 machines (Windows + Linux) uniquement en accédant en temps que root à une seul (Linux).
[^] # Re: chmod ?
Posté par nono14 (site web personnel) . Évalué à 1.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Incompatibilité
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Il ne faut pas rêver, cette base tdbsam contient un mot de passe en clair.
A partir de là, est-ce qu'il serait possible d'utilisé ce le mot de passe chiffré dans tdbsam, afin de s'authentifier auprès du Windows ? Sachant que pour s'authentifier auprès d'un Windows, ce n'est pas le mot de passe qui est envoyé sur le réseau, mais son "hash", ou quelque chose équivalent.
Non, ce n'est pas un hachage qui est envoyé, c'est un défi-réponse. En revanche, pour effectuer ce défi-réponse, il faut, sur le serveur comme sur le client, le mot de passe, en clair. Lorsqu'on utilise des mots de passe, il y a deux possibilités :
— envoyer le mot de passe en clair au serveur, qui peut alors le hacher et le comparer à un hachage enregistré : il n'a pas besoin de stocker le mot de passe en clair dans sa base ;
— procéder par défi-réponse, le serveur comparant alors la réponse à celle qu'il obtient avec le mot de passe, qu'il doit connaître et stocker en clair.
Certains systèmes, comme NTLM Auth et HTTP Digest, ont introduit une pseudo-solution, qui consiste à faire un défi-réponse, non sur le mot de passe lui-même, mais sur son hachage, pour ne pas transmettre ni stocker le mot de passe en clair. En réalité cette technique est un leurre, qui n'apporte rien du tout, vu que le hachage joue alors le rôle de mot de passe, et suffit à s'identifier : le stockage sur le serveur contient toujours des données critiques.
Le seul moyen à ma connaissance de sécuriser convenablement un système d'identification par mot de passe, c'est de le transmettre en clair, comparé à son hachage par le serveur — PAM UNIX, HTTP Basic, SASL PLAIN ou LOGIN — mais sur un canal chiffré — SSH, SSL, TLS.
[^] # Re: Incompatibilité
Posté par Olivier (site web personnel) . Évalué à 1.
Mes informations étaient de toute évidences erronées !
# AD/Kerberos
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
c'est l'auth Kerberos, via un domaine Active Directory ou un simple realm kerberos.
mais c'est pas le plus evident a mettre en place
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.