Forum Linux.debian/ubuntu samba/openldap : forcé un type de cryptage pour les mots de passe

Posté par  .
Étiquettes : aucune
3
5
déc.
2011

Bonjour à toutes et à tous,

Vous l'aurez compris vu le titre, il y a dans mon infrastructure un serveur samba (3.2.5) et un serveur openldap(2.4.11). Ils travaillent ensemble pour le confort des utilisateurs qui, eux, sous sous windows XP(comme quoi on peut arrêter le progrès :-p).

J'aimerais faire en sorte que quand un utilisateur change de mot de passe, celui-ci se retrouve crypté dans le ldap dans un autre format que celui utilisé actuellement.

Actuellement : ssh
Idéalement :md5 ou sha1

Est-ce qu'on peut le faire ? et si oui, comment ?

ça fait plusieurs jours que j'essaie de trouver des infos, du côté de la config de samba ou de pam_ldap mais je n'arrive pas à mettre le doigt sur l'info qui répond à mes questions.

Merci d'avance pour vos réponses

Ivy

  • # man slapd.conf

    Posté par  (site web personnel) . Évalué à 1.

    C'est écrit dans la doc.

    Système - Réseau - Sécurité Open Source

    • [^] # Re: man slapd.conf

      Posté par  (site web personnel) . Évalué à 4.

      Je vais me faire moinsser, mais je trouve ce commentaire bien dommage pour la communauté.
      Il y a quelques années, quand je me suis remis à Linux, j'étais un chouilla perdu, et parfois même dans un Man je me retrouvais pas, trop de possibilité, pas vu un paramètre. Ça peut arriver à tous, surtout à ceux qui commencent. Alors plutôt que de faire un commentaire sec comme ça, tu aurais pu dire la même chose, mais en rajoutant ou trouver cette info dans le fichier conf, comme ça le brave demandeur aurais pu voir ce qu'il avait raté, et être meilleur la prochaine fois ! Et ça éviterais à la communauté linuxienne de passer pour des ours mal léchés ...

      Bon, ben bonne journée, vous pouvez moinsser :-)

      • [^] # Re: man slapd.conf

        Posté par  (site web personnel) . Évalué à 2.

        Les occurences du mot "password" ne sont pas légion dans le fichier de configuration.C'est certain le boulot ne va pas se faire tout seul.

        Système - Réseau - Sécurité Open Source

      • [^] # Re: man slapd.conf

        Posté par  . Évalué à 4.

        Parce que je suis gentil : http://linux.die.net/man/5/slapd.conf

        password-hash <hash> [<hash>...]
            This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}.
        
            {SHA} and {SSHA} use the SHA-1 algorithm (FIPS 160-1), the latter with a seed.
        
            {MD5} and {SMD5} use the MD5 algorithm (RFC 1321), the latter with a seed.
        
            {CRYPT} uses the crypt(3).
        
            {CLEARTEXT} indicates that the new password should be added to userPassword as clear text.
        
            Note that this option does not alter the normal user applications handling of userPassword during LDAP Add, Modify, or other LDAP operations. 
        
        
  • # résolus

    Posté par  . Évalué à 3.

    Merci à tous, pour votre aide.
    C'est exactement ce que la dernière personne dit dans son commentaire.

    Je sais que parfois certain ont l'impression que j'ai pas beaucoup cherché, c'est qu'en réalité j'ai mal cherché (comprenez par là googler sur les mauvais termes, chercher dans les mauvais man, ect..)
    Je ne savais pas si c'était dans le smb.conf, les outils smbldap, ou le ldap qu'il fallais chercher, c'est sûre ça parait toujours évident une fois qu'on connais la réponse, "simple comme l'oeuf de colomb" =)

    Merci encore,

    Ivy

    • [^] # Re: résolus

      Posté par  . Évalué à 0.

      D'ailleurs le mot "password" ne figurait absolument nul part dans slapd.conf(il a vu plusieurs génération d'amin), impossible donc de le débusquer à coup de grep

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.