je sais, ma réponse est hors sujet, mais je me permet de signaler qu'avec vraiment peu d'efforts j'ai fait passer une bonne quinzaine de personnes à Jabber, sans leur faire abandonner leur MSN chéri bien sûr. Google est d'une bonne aide pour ça, le client google talk est un client très discret, et dont l'apparence graphique ne fait pas peur aux utilisateurs. C'est simple d'obtenir un compte google (si ça marche encore par invitation, je peux aider si besoin), et google talk est intéropérable avec tous les réseaux Jabber, c'est-à-dire que depuis ton compte Jabber tu pourras ajouter des comptes google talk à ta liste.
En ce qui concerne les clients Jabber, j'utilise GTalk pour mon compte google sous windows, Pandion (tjs sous windows) pour mon compte APINC, et Gajim sous Linux pour mes deux comptes Google et Apinc.
Gajim fonctionne également sous windows mais je le trouve trop instable.
Pandion et Gajim fonctionnent bien avec les passerelles MSN. Si tu ne connais pas, c'est une fonctionnalité offerte par certains serveurs Jabber (celui de l'APINC, mais pas celui de Google) te permettant de communiquer avec tes contacts MSN directement avec ton compte Jabber, après l'avoir configuré pour qu'il utilise ton compte MSN pour ces contacts là.
Moi je trouve que FDS jouit d'une bonne popularité. Dans mon boulot où on bosse énormément avec les différents annuaires du marché, il revient très souvent.
Est-ce normal pour la france où il gagne de l'argent qu'il ne paye ses impôts qu'en Irlande ?
Oui, parce que c'est la règle du jeu. Inversement, des entreprises françaises gagnant de l'argent en Irlande paieront leurs impots en France, et tout ça garantit un semblant d'équilibre. Si les gens se mettent à choisir l'endroit où ils paient leurs impots, tout ça n'a plus aucun sens. Les impôts sont quand même le mécanisme principal du partage des richesses, car ils sont plus élevés pour les plus riches, et leur produit bénéficie aux plus pauvres. Choisir le pays bénéficiaire de ses impôts, c'est priver beaucoup de monde de ce partage, c'est choisir qui profite du partage, c'est se prendre pour un état alors qu'on n'est qu'un homme, c'est outrepasser ses droits.
tu dois laissé écrit "attribute=userPassword" tel quel, sans remplacer userPassword par quoi que ce soit
en effet la chaine "userPassword" est le nom d'un attribut LDAP servant à stocker le mot de passe d'un utilisateur dans l'objet LDAP le représentant (dans un annuaire LDAP en règle générale, chaque utilisateur est lui-même représenté par un objet de l'annuaire).
cette règle d'accès te permet donc de dire que :
- l'administrateur a un accès en écriture sur l'attribut "userPassword" des objets de l'annuaire, c'est à dire qu'il peut changer le mot de passe des utilisateurs de l'annuaire,
- l'utilisateur anonyme peut utiliser le mot de passe à fin d'authentification,
- tout utilisateur peut changer son propre mot de passe,
- toute autre personne n'y a pas accès.
Merci d'avoir lu jusqu'ici, car ton problème n'a rien à voir avec ça :-)
néanmoins comme visiblement tu n'avais pas compris ce point il me semblait bon de te donner une petite explication.
Ton problème vient du fait qu'en t'authentifiant tu donnes le mot de passe crypté, ce qui est contraire au protocole LDAP. En effet l'authentification LDAP simple telle qu'utilisée par ldapadd -x nécessite impérativement le mot de passe en clair. Utilise donc le mot de passe en clair dans ta commande ldapadd, et ça marchera !
Pour information, le cryptage du mot de passe permet juste de ne pas avoir de mot de passe en clair stocké sur le disque dur du serveur, et pas du tout de protéger le mot de passe lors de son passage sur le réseau, ce qui n'aurait strictement aucune utilité avec un simple hash.
Si tu veux plus d'info, mon mail/jabber : francois.beretti@gmail.com
il y a aussi des écoles ou on ne fait que des maths comme l'ENSAI (école de statistique), où les étudiants s'amusent à faire des trucs aussi téoriques que les maths de prépa (genre théories de l'intégration étendues ou autre).
Non non, en Corse par exemple, les villes sont en résolution pourrie, mais le centre, là ou il y a 3 villages, 10 vaches et du maquis, est en super résolution o_O
Désolé, je ne connais pas bien Mandriva et KDE, donc je ne pourrai pas t'aider, mais c'est juste pour dire que si une fille célibataire motivée par linux n'arrive pas à avoir de l'aide sur ce site, c'est la fin de tout...
l'authentification standard en LDAP envoie le mot de passe en clair.
A ce propos, un hash du mot de passe ne sert à rien au niveau client, car si le serveur attend ce hash, alors il suffit au pirate qui l'a sniffé de l'envoyer au serveur pour être authentifié.
Pour sécuriser une authentification LDAP il y a deux moyens possibles :
- chiffrement de l'ensemble de la connexion par SSL/TLS
- utilisation d'une méthode d'authentification sécurisée, comme DIGEST-MD5, Kerberos, ou un certificat client TLS, qui t'assure qu'aucun mot de passe en clair ne se ballade.
Je n'ai jamais utilisé la seconde solution en PHP.
# Parle un peu de Jabber
Posté par Nap . En réponse au message Adresse Jabber et accès aux autres réseaux.. Évalué à 2.
je sais, ma réponse est hors sujet, mais je me permet de signaler qu'avec vraiment peu d'efforts j'ai fait passer une bonne quinzaine de personnes à Jabber, sans leur faire abandonner leur MSN chéri bien sûr. Google est d'une bonne aide pour ça, le client google talk est un client très discret, et dont l'apparence graphique ne fait pas peur aux utilisateurs. C'est simple d'obtenir un compte google (si ça marche encore par invitation, je peux aider si besoin), et google talk est intéropérable avec tous les réseaux Jabber, c'est-à-dire que depuis ton compte Jabber tu pourras ajouter des comptes google talk à ta liste.
En ce qui concerne les clients Jabber, j'utilise GTalk pour mon compte google sous windows, Pandion (tjs sous windows) pour mon compte APINC, et Gajim sous Linux pour mes deux comptes Google et Apinc.
Gajim fonctionne également sous windows mais je le trouve trop instable.
Pandion et Gajim fonctionnent bien avec les passerelles MSN. Si tu ne connais pas, c'est une fonctionnalité offerte par certains serveurs Jabber (celui de l'APINC, mais pas celui de Google) te permettant de communiquer avec tes contacts MSN directement avec ton compte Jabber, après l'avoir configuré pour qu'il utilise ton compte MSN pour ces contacts là.
[^] # Re: Fedora Directory Server
Posté par Nap . En réponse au journal FC6 test 2 est sorti. Évalué à 3.
enfin d'un autre coté, c'est tellement monolithique que tu peux l'installer sur n'importe quelle distrib à mon avis, il a pas 350 dépendances.
[^] # Re: Google a t'il besoin de publicité ?
Posté par Nap . En réponse au journal Google Life of Code pour Andrew Morton. Évalué à 3.
# Fedora Directory Server
Posté par Nap . En réponse au journal FC6 test 2 est sorti. Évalué à 1.
[^] # Re: Google a t'il besoin de publicité ?
Posté par Nap . En réponse au journal Google Life of Code pour Andrew Morton. Évalué à 10.
[^] # Re: Mature ou alpha ?
Posté par Nap . En réponse au journal WebKit pour Windows : sortie de Swift alpha !. Évalué à 2.
Sinon j'espère que pour la béta ils vont virer le principe du multidocument avec les sous fenêtres, parce que j'aime pas trop...
[^] # Re: Bof
Posté par Nap . En réponse au journal Bono et l'argent : La colère du samedi. Évalué à 2.
qui a le plus gros membre ?
# Mature ou alpha ?
Posté par Nap . En réponse au journal WebKit pour Windows : sortie de Swift alpha !. Évalué à 3.
[^] # Re: Bof
Posté par Nap . En réponse au journal Bono et l'argent : La colère du samedi. Évalué à 3.
Oui, parce que c'est la règle du jeu. Inversement, des entreprises françaises gagnant de l'argent en Irlande paieront leurs impots en France, et tout ça garantit un semblant d'équilibre. Si les gens se mettent à choisir l'endroit où ils paient leurs impots, tout ça n'a plus aucun sens. Les impôts sont quand même le mécanisme principal du partage des richesses, car ils sont plus élevés pour les plus riches, et leur produit bénéficie aux plus pauvres. Choisir le pays bénéficiaire de ses impôts, c'est priver beaucoup de monde de ce partage, c'est choisir qui profite du partage, c'est se prendre pour un état alors qu'on n'est qu'un homme, c'est outrepasser ses droits.
[^] # Re: Le passage Mono dans le document
Posté par Nap . En réponse au journal Mono et Gnome. Évalué à 1.
[^] # Re: pour ou contre ?
Posté par Nap . En réponse au journal Mono et Gnome. Évalué à 1.
Ton navigateur ne l'ouvre pas via un plugin ?
[^] # Re: Beurk
Posté par Nap . En réponse à la dépêche You OS, un OS en ligne. Évalué à 0.
[^] # Re: les vrais geek ont un mac
Posté par Nap . En réponse au journal Envie de frapper votre ordinateur ?. Évalué à 1.
[^] # Re: le calvaire des plug-ins
Posté par Nap . En réponse à la dépêche Sortie d'Opera 9. Évalué à 5.
on dit "les plugins de firefox", connard.
[^] # Re: Commande ldapadd
Posté par Nap . En réponse au message ldap_bind: Invalid credentials (49) avec openldap.. Évalué à 2.
tu dois laissé écrit "attribute=userPassword" tel quel, sans remplacer userPassword par quoi que ce soit
en effet la chaine "userPassword" est le nom d'un attribut LDAP servant à stocker le mot de passe d'un utilisateur dans l'objet LDAP le représentant (dans un annuaire LDAP en règle générale, chaque utilisateur est lui-même représenté par un objet de l'annuaire).
cette règle d'accès te permet donc de dire que :
- l'administrateur a un accès en écriture sur l'attribut "userPassword" des objets de l'annuaire, c'est à dire qu'il peut changer le mot de passe des utilisateurs de l'annuaire,
- l'utilisateur anonyme peut utiliser le mot de passe à fin d'authentification,
- tout utilisateur peut changer son propre mot de passe,
- toute autre personne n'y a pas accès.
Merci d'avoir lu jusqu'ici, car ton problème n'a rien à voir avec ça :-)
néanmoins comme visiblement tu n'avais pas compris ce point il me semblait bon de te donner une petite explication.
Ton problème vient du fait qu'en t'authentifiant tu donnes le mot de passe crypté, ce qui est contraire au protocole LDAP. En effet l'authentification LDAP simple telle qu'utilisée par ldapadd -x nécessite impérativement le mot de passe en clair. Utilise donc le mot de passe en clair dans ta commande ldapadd, et ça marchera !
Pour information, le cryptage du mot de passe permet juste de ne pas avoir de mot de passe en clair stocké sur le disque dur du serveur, et pas du tout de protéger le mot de passe lors de son passage sur le réseau, ce qui n'aurait strictement aucune utilité avec un simple hash.
Si tu veux plus d'info, mon mail/jabber : francois.beretti@gmail.com
[^] # Re: Commande ldapadd
Posté par Nap . En réponse au message ldap_bind: Invalid credentials (49) avec openldap.. Évalué à 2.
tsuki, il faut utiliser le mot de passe en clair dans la commande ldapadd
de plus, où es-tu allé pêcher ta configuration slapd.conf ? je n'ai jamais vu de ligne comme celle-ci :
access to attribute={SSHA}9YBOFmYWGOcotlNXIwFSpf7BE2g7xemj
[^] # Re: Les hommes viennent ... du même endroit que les femmes
Posté par Nap . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 2.
[^] # Re: Homme presse
Posté par Nap . En réponse au journal La Maladie d'écrire. [Complètement à coté de la plaque]. Évalué à 4.
[^] # Re: Et pourquoi
Posté par Nap . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 1.
[^] # Re: Les hommes viennent ... du même endroit que les femmes
Posté par Nap . En réponse au journal Pourquoi aussi peu de femmes dans les métiers de l'informatique ?. Évalué à 2.
=> 50% de filles
[^] # Re: Salut bandes de tar
Posté par Nap . En réponse au journal Salut bandes de tar. Évalué à 2.
[^] # Re: Dans R
Posté par Nap . En réponse au journal enlightenmen DR17, la suite.. Évalué à 3.
[^] # Re: Terriblement distrayant
Posté par Nap . En réponse au journal [HS] GoogleEarth, Geoportail, Mappy et vie privée. Évalué à 2.
# Bon courage
Posté par Nap . En réponse au message Restauration dernière bonne config connue ?. Évalué à 3.
bon courage
# Normal
Posté par Nap . En réponse au message Linux/ldap/php. Évalué à 4.
A ce propos, un hash du mot de passe ne sert à rien au niveau client, car si le serveur attend ce hash, alors il suffit au pirate qui l'a sniffé de l'envoyer au serveur pour être authentifié.
Pour sécuriser une authentification LDAP il y a deux moyens possibles :
- chiffrement de l'ensemble de la connexion par SSL/TLS
- utilisation d'une méthode d'authentification sécurisée, comme DIGEST-MD5, Kerberos, ou un certificat client TLS, qui t'assure qu'aucun mot de passe en clair ne se ballade.
Je n'ai jamais utilisé la seconde solution en PHP.
Pour la première, regarde la doc de ldap_connect pour savoir comment faire :
http://fr3.php.net/manual/en/function.ldap-connect.php