La version 0.3 vient de sortir avec son lot de nouveautés :
- Mode SAMBA ;
- Traduction allemande ;
- Politique locale de mot de passe ;
- Nouvelle feuille de style.
Quelques informations complémentaires sur ces nouvelles fonctionnalités :
- Mode SAMBA : lors du changement de mot de passe, le mot de passe SAMBA est également mis à jour ; le mot de passe SAMBA est en effet maintenu dans un attribut différent avec une empreinte particulière (MD4) ;
- Politique locale de mot de passe : bien qu'il soit conseillé de laisser l'annuaire contrôler la solidité du mot de passe, il est possible d'activer une politique locale qui permet de jouer sur les contraintes suivantes :
- Taille minimale ;
- Taille maximale ;
- Nombre minimal de minuscules ;
- Nombre minimal de majuscules ;
- Nombre minimal de chiffres.
- Taille minimale ;
Cette politique peut être présentée à l'utilisateur avant qu'il change son mot de passe.
Le projet LDAP Tool Box rassemble plusieurs outils destinés à faciliter la mise en place d'annuaires LDAP. Par exemple, des RPMs pour la dernière version stable d'OpenLDAP (2.4.21) ont été publiés très récemment. Il existe également un ensemble de greffons pour Nagios ou Cacti.
Aller plus loin
- Self Service Password (838 clics)
- Capture d'écran (328 clics)
- Annonce officielle (38 clics)
- Téléchargement (103 clics)
- LDAP Tool Box (205 clics)
# GoSA
Posté par Davy Defaud . Évalué à 2.
P.S: petite coquille : "Cette annuaire"...
[^] # Re: GoSA
Posté par KPTN (site web personnel, Mastodon) . Évalué à 5.
Je connais bien GoSA qui est un très bon logiciel de gestion d'annuaire (je laisserai d'autres que moi présenter plus en détail cette solution).
Self Service Password est simplement une page web permettant à un utilisateur de changer son mot de passe, et rien d'autre.Il s'installe et se configure facilement, sans rien toucher à la configuration de l'annuaire existant.
Je pense que ces deux logiciels sont complémentaires et non concurrents.
[^] # Re: GoSA
Posté par Davy Defaud . Évalué à -2.
Mais, rien que du point de vue des utilisateurs, il permet bien plus de choses, comme par exemple changer certains attributs :
- sa photo
- son numéro de téléphone
- son adresse de courriel principale
- de préciser un message d'absence dans sa messagerie avec des dates de début et de fin de période d'absence.
Je conviens que la mise en place de GoSA est nécessairement plus compliquée, mais l'investissement en vaut la peine.
# Pas d'exop ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Pour un projet qui propose une solution de "changement de mot de passe" pour les annuaires LDAP, ne pas supporter l'opération native du protocole, c'est comme une voiture ne pas supporter la fonction rouler.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'exop ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"cette demande de fonctionnalité" : http://tools.lsc-project.org/issues/show/143
"LDAP Password Modify Extended Operation" : http://tools.ietf.org/html/rfc3062
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'exop ?
Posté par KPTN (site web personnel, Mastodon) . Évalué à 3.
Cette opération permet essentiellement de laisser l'annuaire LDAP chiffrer le mot de passe. Cette fonctionnalité est aussi toutefois assurée désormais par l'overlay ppolicy d'OpenLDAP, donc l'utilisation de l'opération étendue se justifie moins.
Self Service Password permet également de chiffrer le mot de passe avant de l'envoyer à l'annuaire (SHA, SSHA, MD5, SMD5, CRYPT).
[^] # Re: Pas d'exop ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
La méthode exop permet de s'assurer que "tous" les mots de passes sont changés. C'est grâce à ça que lorsque je tape "passwd" sur Linux, je change mon mot de passe Windows en même temps. Et lorsque je fais "Ctrl + Alt + Del" -> "changer le mot de passe" sur Windows, je change le mot de passe Linux. Et je change aussi les mots de passes de plusieurs autres services.
Cette opération n'est pas là pour laisser l'annuaire chiffrer, mais bien pour laisser l'annuaire mettre à jour _tous_ les champs nécessaires selon les besoins de chaque champs.
C'est ce qui est triste dans ce genre de projet. Au lieu de prendre les standards, on créer une méthode différente. Si votre application suit le standard, elle fonctionne partout. Là, elle fonctionne chez 90% des gens.
Des outils de changement de mot de passe LDAP comme celui-ci j'en ai trouvé des dizaines, celui-ci n'apporte rien de plus parce que _pas standard_ et donc ne fonctionne pas chez moi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'exop ?
Posté par KPTN (site web personnel, Mastodon) . Évalué à 4.
Soyons déjà clairs sur les termes : la méthode exop ne veut pas dire grand chose. C'est en fait une opération étendue (extended operation), il y en existe plusieurs définies dans des RFC, et modify password est l'une de ces opérations étendues.
Cette opération étendue est supportée par Active Directory et OpenLDAP, mais pas forcément sur tous les produits d'annuaires LDAP.
Et je suis assez surpris que cette opération étendue ait le talent magique de savoir changer à la fois le mot de passe windows et le mot de passe Linux. Il faut certainement révéler quelques ficelles, comme la mise en place de SFU (Services For Unix) sur AD ou la délégation SASL du mot de passe de OpenLDAP vers AD. Des tas de solutions existent pour synchroniser les mots de passe AD (unicodePwd) et LDAP (userPassword), mais utiliser simplement une opération étendue n'est pas suffisant (ou alors je suis preneur d'une bonne doc).
Et pour terminer, dire que c n'est pas standard est un peu exagéré, sachant qu'on utilise quand même les opération standards LDAP (bind, modify) et non une opération étendue, qui par définition étend le standard.
[^] # Re: Pas d'exop ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Tu peux configurer samba pour utiliser exop ( ldap passwd sync = only), tu peux configurer pam-ldap pour utiliser exop (pam_password exop, dans pam_ldap.conf), tu peux, avec un script Perl, faire que n'importe quelle interface Web utilise exop.
Un projet de se type est intéressant dans le sens où l'on a un changement de mot de passe pour les interfaces Web, mais sans exop, il n'apporte rien à ce qu'on trouve déjà.
Vous faites juste réinventer la roue actuellement.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'exop ?
Posté par KPTN (site web personnel, Mastodon) . Évalué à 1.
Plusieurs raisons ont motivé son abandon dans Self Service Password :
* Pas d'opération étendue dans PHP
* Pas forcément supporté par tous les annuaires
C'est vrai qu'on pourrait faire un appel système à un script Perl, voire plus simple à la commande ldappasswd. Mais l'idée était de fournir un petit utilitaire PHP simple.
Je suis d'ailleurs plutôt partisan de Perl, et dans l'un des autres projets sur lesquels je travaille (LemonLDAP::NG / http://lemonldap.ow2.org), qui est entièrement en Perl, on supporte l'opération étendue password modify pour la modification du mot de passe.
Dernièrement, étant donné les différents messages que je reçois, je n'ai pas l'impression de réinventer la roue mais de proposer un produit pouvant remplacer un certain nombre de développements spécifiques. Certes ça ne conviendra pas à tout le monde, mais si ça peut en aider certains, tant mieux.
# Symbole
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Mon programme vérifiait la contrainte sur les 8 premiers caractères mais le mot de passe pouvait en comporter 12, 16 ou plus... Je ne vois pas l'intérêt de limiter la taille maximale du mot de passe par contre, ce qui est intéressant est de forcer la contrainte sur un certain nombre maximum de caractères. C'était surtout très important avec les anciens hash sous Windows qui coupait à deux fois 8.
Ma règle à l'époque était donc la suivante :
- au moins 6 octets
- au moins 1 grande lettre parmi les 8 premiers octets
- au moins 1 petite lettre parmi les 8 premiers octets
- au moins 1 chiffre parmi les 8 premiers octets
- au moins 1 symbole parmi les 8 premiers octets
- pas dans un dico via un recherche rapide (cracklib)
Avec cela, john crackait très peu de mot de passe et mes utilisateurs étaient obligé d'utiliser autre chose que ce qu'il mettait partout (gmail, facebook...).
[^] # Re: Symbole
Posté par GG (site web personnel) . Évalué à 4.
Et pourquoi les mots de passes pour la messagerie chez OVH en mutualisé est limitée à 12 caractères?
Pareil, pourquoi c'est cette même limite pour le ssh, le FTP chez OVH en mutualisé?
Parce que Windows est incapable de gérer les mots de passes qui font plus de 12 caractères.
Certes, Pbpg va nous repréciser tout ça, mais c'est quand même une limitation pénible.
J'ai découvert cette limitation avec les SME-Server, où il est expliqué que cette limitation par défaut est imposée pour que les postes sous Windows puissent se connecter au partage de fichier.
Heureusement, on peut faire sauter cette limitation, sur SME-Server. Pas chez OVH.
Concernant OVH en mutualisé, il faut savoir que les caractères supplémentaires sont simplement ignorés... ça fait quand même peur au début.
Heureusement qu'on a Windows pour rabaisser le niveau de sécurité, sinon on aurait plus de travail.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Symbole
Posté par KPTN (site web personnel, Mastodon) . Évalué à 1.
À noter que la taille maximale existe aussi dans les paramètres de ppolicy d'OpenLDAP.
[^] # Re: Symbole
Posté par KPTN (site web personnel, Mastodon) . Évalué à 1.
En ce qui concerne le reste, la politique locale n'est pas extrêmement développée (en particulier cracklib) car des modules dédiés peuvent faire ce travail côté annuaire. Par exemple pour OpenLDAP, on publie sur le site du projet LTB un module de vérification des mots de passe gérant cracklib.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.