KPTN a écrit 99 commentaires

Tout à l'air de fonctionner de nouveau !

Désolé pour l'indisponibilité du site, on regarde pour rétablir ça très rapidement. Je suis certain qu'on fera mieux que notre vitrine nationale...

Je suis entièrement d'accord qu'utiliser l'opération étendue password modify est plus sympa qu'une simple modification des attributs LDAP.

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.

C'est certain que la taille maximale est souvent moins utile que la taille minimale, mais certaines personnes en ont besoin, c'est donc un des paramètres de l'application.

À noter que la taille maximale existe aussi dans les paramètres de ppolicy d'OpenLDAP.

Je vais intégrer les symboles dans la prochaine version, j'ai d'ailleurs reçu un patch d'un utilisateur dans ce sens.

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.

Bon alors il ne faut pas raconter n'importe quoi.

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.

Si tu lis bien le contenu du ticket que tu cites, il est expliqué que cette opération étendue n'est pas disponible dans PHP.

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).

En fait ces deux solutions n'ont pas la même vocation.

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.

Juste un petit mot pour remercier Rémi et Brice (eMerzh) d'avoir soumis leurs remarques sur le gestionnaire d'incidents du projet.

J'espère que nous pourrons rapidement en compte les remarques et sortir de nouvelles versions.

L'intérêt est je pense de laisser les utilisateurs choisir le paquet qui leur correspond le mieux. Dans le cas des paquets LTB, ceux-ci embarquent le script d'initialisation LTB et la module de vérification des mots de passe.

La version 2.4.16 est la dernière étiquetée stable chez OpenLDAP. Ce n'est donc pas être en retard que de fournir les dernière stable, et non la dernière version sortie.

Avant de faire nos propres paquets RPMs, nous en avons essayé plusieurs. Pour diverses raisons, nous avons préféré faire les nôtres (en particulier avant un module check_password déjà compilé). S'ils peuvent servir à d'autres tant mieux. Voilà pourquoi ils sont publiés.

Bien entendu, je suis preneur de remarques permettant d'améliorer les paquets fournis.

Je n'ai pas rencontré ce type de problème. Je suis preneur d'informations pour améliorer le code.

Le projet est libre, et possède un gestionnaire du bugs ici : http://tools.ltb-project.org/projects/ltb/issues

Merci.

La complexité du mot de passe doit plutôt se gérer côté serveur, afin que tous les moyens utilisés pour changer le mot de passe soient soumis aux mêmes contraintes. C'est d'ailleurs l'objectif du module check_password pour OpenLDAP :
http://ltb-project.org/wiki/documentation/openldap-ppolicy-c(...)

Ensuite, il faudrait en effet que l'interface renvoie un message correct à l'utilisateur. Je pense implémenter cela en utilisant le contrôle étendu ppolicy. Pour l'instant, avec une politique correcte au niveau du serveur, l'utilisateur aura juste un message « le mot de passe a été refusé par le serveur ».

Effectivement ce n'est pas encore documenté, car cette fonctionnalité sort tout juste du carton, C'est en haut de ma liste ;)

Pour Cacti par contre, il est possible d'utiliser un mécanisme d'authentification externe, donc ça s'intègre nativement.

De plus en plus d'applications sont capables de faire confiance au REMOTE_USER, c'est vers cette technique qu'il faut aller. Pour les vieilles applis, on pourra effectivement passer par la soumission de formulaires (avec une bonne doc...)

Clément.

L'installation par défaut crée une application de test. Il suffit de regarder le fichier /etc/lemonldap-ng/apache2.conf.

Les paquets sont dans Debian, mais pour avoir la dernière version, il faut soir passer en testing ou unstable, soit installer les paquets manuellement:
http://wiki.lemonldap.ow2.org/xwiki/bin/view/NG/DocInstallDe(...)

Une archive de tous les paquets est disponible sur la forge OW2:
http://forge.ow2.org/project/download.php?group_id=274&f(...)

J'encourage vivement à poursuivre ces discussions sur la liste lemonldap-ng-users@ow2.org

En fait LemonLDAP::NG est utilisé directement dans les fichiers de conf d'Apache.

Si tu as déjà configuré tes applications pour qu'elles reposent sur la sécurité Apache, alors il te suffit dans tes hôtes virtuels Apache de remplacer la configuration de l'authentification (généralement les paramètres Auth*) pour faire appel au module LemonLDAP::NG (PerlHeaderParserHandler My::Package).

Bien entendu il faudra inscrire les hôtes virtuels protégés dans l'interface d'administration de LemonLDAP::NG (le Manager).

En conclusion, toute application compatible avec un mécanisme htaccess d'Apache est directement compatible avec LemonLDAP::NG.

Bonjour,

il suffit de récupérer l'identifiant de session stocké dans le cookie et se connecter à la base de session configurée (fichier, LDAP, SQL). Un accès SOAP aux sessions est possible :
[http://wiki.lemonldap.ow2.org/xwiki/bin/view/NG/DocSOAPSessi(...)]

Sinon il est possible de protéger l'autre SSO X par LemonLDAP::NG, en demandant au SSO X d'utiliser le REMOTE_USER.

Un système de couplage de portails peut également être utilisé :
http://wiki.lemonldap.ow2.org/xwiki/bin/view/NG/AuthRemote

Je suis preneur de tout retour d'expérience sur le couplage de LemonLDAP::NG avec d'autres SSO.

Le choix de XML est en cours, mais cela nous semble une bonne solution pour modéliser l'arbre de configuration du logiciel. De plus, avec XML, il devient simple d'ajouter des paramètres de configuration et par transformation en déduire le schéma de la base de données de stockage.

On peut imaginer conserver sans problème un mode de stockage de configuration en fichier plat, comme c'est le cas actuellement.

Je n'ai pas de retour d'expérience sur la centralisation des configurations de serveurs virtuels dans un annuaire. Ce qui est certain, c'est que l'annuaire peut déjà centraliser les utilisateurs et les groupes. Sudo propose également de stocker sa configuration dans un annuaire LDAP.

Cela sort toutefois du cadre de LemonLDAP::NG qui est dédié aux applications Web, et donc comme cité en début de commentaire, permet de centraliser l'authentification et les règles d'accès aux applications protégées.

Et également des supports de formation (sous Creative Commons) :
http://www.linagora.org/rubrique73.html

Clément.
http://coudot.blogs.linagora.com/

Pour ceux que ça intéresse, j'ai publié un petit article avec quelques photos :
http://coudot.blogs.linagora.com/index.php/post/2008/05/22/L(...)

Clément.

Bonjour,

j'ai rédigé plusieurs supports de formations pour LINAGORA qui sont en Creative Commons et publiés sur http://www.linagora.org:
* Protocole LDAP : http://www.linagora.org/article138.html
* OpenLDAP : http://www.linagora.org/article137.html
* Optimisation OpenLDAP : http://www.linagora.org/article143.html
* SSO avec LemonLDAP::NG : http://www.linagora.org/article166.html

Le support Liberty Alliance est en effet une fonctionnalité intéressante, apportée grâce au projet FederID.

En effet, une application Web peut être facilement transformée pour venir s'inscrire dans le WebSSO de LemonLDAP::NG : il suffit qu'elle récupère l'identifiant de l'utilisateur (et d'autres informations si nécessaires) dans les en-têtes HTTP au lieu de présenter le formulaire d'authentification. Coût d'intégration : très faible.

Faire du Liberty Alliance est plus complexe : l'application doit pouvoir dialoguer avec un fournisseur d'identités en utilisant des assertions SAML. La bibliothèque Lasso[1] (utilisée dans les différents composants de FederID, dont LemonLDAP::NG), permet de réaliser cette intégration, mais prend plus de temps (et nécessite plus de connaissances).

L'idée ici est de transformer LemonLDAP::NG en fournisseur de service (donc vu comme une application client vis à vis d'un fournisseur d'identités), qui saura créer automatiquement une session SSO sur les applications qu'il protège déjà : c'est donc une solution très simple d'intégrer une application Web dans un cercle de confiance Liberty Alliance.

[1] http://lasso.entrouvert.org/

Lapinator ?

Mais non, elle a raison.

Salut à tous,

il se trouve que je fais partie d'une de ces SS2L et je tenais à apporter ma vision "interne" à ce débat.

- Non les SS2L ne sont pas les mieux placées pour parler de contribution au libre.
- Non les salariés des SS2L n'utilisent pas autant qu'ils le pourraient des logiciels libres dans leur travail quotidien.
- Non l'ASS2L n'est pas impartiale.

Mais de là à traiter les SS2L de parasites, c'est à mon avis faire fausse route. Aider le logiciel libre, ce n'est pas simplement coder jour et nuit, c'est aussi savoir le vendre dans des propositions commerciales, le documenter, former les autres sur ces technologies, adapter le code aux problématiques du client, faire des tests de performances pour montrer qu'il vaut (et qu'il dépasse) ses équivalents propriétaires.

Concernant ce sondage, ce n'est pas l'état de l'art des logiciels libres mais plutôt une vision instantanée (les 3 jours de SL2006) de comment sont vus ces logiciels par la profession informatique (et elle contient encore beaucoup de néophyte dans le domaine). Le manque de support ? Oui, c'est la première crainte des DSI, et pas selon les chiffres du sondage, mais de mon expérience sur le terrain.

Soyez sûrs d'une chose, les personnes qui travaillent dans les SS2L sont convaincues par le logiciel libre et font tout pour qu'il s'implante dans les entreprises. Seulement leur action est certainement moins visible dans les communautés, bien que la plupart d'entre nous sont impliqués dans des projets et des associations.

J'espère avoir pu apporter un peu d'eau au moulin sans susciter trop de polémiques...