Vous n'êtes pas identifié(e).
Bonjour,
Nous souhaitons exporter / synchroniser notre base d'utilisateurs django périodiquement pour nourrir une base ldap. Le but étant de pouvoir refabriquer une base ldap à 100% à partir des utilisateurs django.
Nous avons un problème au niveau des mots de passe des utilisateurs dans la base ldap.
Apparemment django stocke par défaut les mots de passes en SHA1 et utilise le caractère "$" comme séparateur de champs entre algorithme, salt et mot de passe crypté, or ce caractère
est utilisé dans les mots de passes MD5.
Bref, est ce que certains d'entre vous ont un retour d'expérience sur ce type d'utilisation avec une base ldap ? Ou éventuellement sur le type de cryptage à utiliser (md5, sha1, ssha) ?
Cordialement
Hors ligne
Bonjour,
Moi ce que j'avais fait c'était l'inverse.
On détecte si l'utilisateur est dans la base Django, s'il n'est pas
dedans ou si le mot de passe est erroné, on essaye de le connecter avec
son compte LDAP et si ça fonctionne on crée/modifie l'utilisateur Django
à partir de la base LDAP.
ça à un double avantage qu'il est possible de créer des utilisateurs
temporaires qui sont sur l'application mais ne sont pas dans l'annuaire.
Par contre j'ai du mal à comprendre pourquoi tu dois pouvoir génerer
l'annuaire à partir de la base Django.
C'est plutôt l'inverse qui me semble logique car un annuaire permet de
se connecter sur plusieurs applications.
Or tu veux qu'une application génère l'annuaire pour toute les autres ?
Il vaut mieux que l'annuaire génère la base de toutes les applications.
Tu pourras ainsi ajouter des champs spécifique à telles ou telles
application qui ne seront pas écrasé par la suite.
Pour répondre à ta question sur le cryptage, les HASH (md5, sha1, ...)
ne permettent pas de trouver le mot de passe à partir du HASH.
Donc il va falloir attendre que l'utilisateur te le donne pour vérifier
que c'est bien celui qui corresponds au hash et éventuellement générer
un nouveau hash.
Concernant les hash, ce sont des HASH Hexadécimaux, donc le $ n'est pas
dedans. Il n'y a que le 5 qui peut éventuellement ressembler à ce
caractère.
Je ne suis pas sur que ça réponde à ta question, mais j'espère faire
avancer ta recherche.
Cordialement,
Rémy Hubscher
Le mercredi 03 novembre 2010 à 17:16 +0000, S. Bonnegent a écrit :
> Bonjour,
>
> Nous souhaitons exporter / synchroniser notre base d'utilisateurs django
> périodiquement pour nourrir une base ldap. Le but étant de pouvoir
> refabriquer une base ldap à 100% à partir des utilisateurs django.
>
> Nous avons un problème au niveau des mots de passe des utilisateurs dans
> la base ldap.
> Apparemment django stocke par défaut les mots de passes en SHA1 et
> utilise le caractère "$" comme séparateur de champs entre algorithme,
> salt et mot de passe crypté, or ce caractère
> est utilisé dans les mots de passes MD5.
>
> Bref, est ce que certains d'entre vous ont un retour d'expérience sur ce
> type d'utilisation avec une base ldap ? Ou éventuellement sur le type de
> cryptage à utiliser (md5, sha1, ssha) ?
>
>
> Cordialement
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
Hors ligne
Bonsoir,
À noter qu'il y a également la possibilité d'utiliser le backend d'authentification RemoteUser qui permet de se logger sur un annuaire LDAP par exemple :
http://docs.djangoproject.com/en/dev/howto/auth-remote-user/
Je le mentionne car je l'ai découvert récemment, si certains d'entre vous l'ont déjà essayé je veux bien des retours :-).
Bonne soirée,
David
Le 3 nov. 2010 à 18:47, Rémy Hubscher a écrit :
> Bonjour,
>
> Moi ce que j'avais fait c'était l'inverse.
> On détecte si l'utilisateur est dans la base Django, s'il n'est pas
> dedans ou si le mot de passe est erroné, on essaye de le connecter avec
> son compte LDAP et si ça fonctionne on crée/modifie l'utilisateur Django
> à partir de la base LDAP.
>
> ça à un double avantage qu'il est possible de créer des utilisateurs
> temporaires qui sont sur l'application mais ne sont pas dans l'annuaire.
>
> Par contre j'ai du mal à comprendre pourquoi tu dois pouvoir génerer
> l'annuaire à partir de la base Django.
>
> C'est plutôt l'inverse qui me semble logique car un annuaire permet de
> se connecter sur plusieurs applications.
>
> Or tu veux qu'une application génère l'annuaire pour toute les autres ?
> Il vaut mieux que l'annuaire génère la base de toutes les applications.
>
> Tu pourras ainsi ajouter des champs spécifique à telles ou telles
> application qui ne seront pas écrasé par la suite.
>
> Pour répondre à ta question sur le cryptage, les HASH (md5, sha1, ...)
> ne permettent pas de trouver le mot de passe à partir du HASH.
>
> Donc il va falloir attendre que l'utilisateur te le donne pour vérifier
> que c'est bien celui qui corresponds au hash et éventuellement générer
> un nouveau hash.
>
> Concernant les hash, ce sont des HASH Hexadécimaux, donc le $ n'est pas
> dedans. Il n'y a que le 5 qui peut éventuellement ressembler à ce
> caractère.
>
> Je ne suis pas sur que ça réponde à ta question, mais j'espère faire
> avancer ta recherche.
>
> Cordialement,
>
> Rémy Hubscher
>
> Le mercredi 03 novembre 2010 à 17:16 +0000, S. Bonnegent a écrit :
>> Bonjour,
>>
>> Nous souhaitons exporter / synchroniser notre base d'utilisateurs django
>> périodiquement pour nourrir une base ldap. Le but étant de pouvoir
>> refabriquer une base ldap à 100% à partir des utilisateurs django.
>>
>> Nous avons un problème au niveau des mots de passe des utilisateurs dans
>> la base ldap.
>> Apparemment django stocke par défaut les mots de passes en SHA1 et
>> utilise le caractère "$" comme séparateur de champs entre algorithme,
>> salt et mot de passe crypté, or ce caractère
>> est utilisé dans les mots de passes MD5.
>>
>> Bref, est ce que certains d'entre vous ont un retour d'expérience sur ce
>> type d'utilisation avec une base ldap ? Ou éventuellement sur le type de
>> cryptage à utiliser (md5, sha1, ssha) ?
>>
>>
>> Cordialement
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
Hors ligne
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
J'avais rapidement testé, ca fonctionne correctement sur un opends, c'est plus délicat sur les bind avec un ldap sun (v6.x). Avec un active directory il m'a été dit que cela pouvait fonctionner, j'ai pas testé personnellement. Attention le bind en ssl c'est pas toujours évident dans tous les cas (donc python >= 2.6 recommandé).
Serait-ce une application de type RH pour les entrées / sorties de personnel qui pilote l'annuaire ldap qui est en réalisation ? (j'aime bien ce concept autour de django )
++
Le 3 nov. 2010 à 19:10, David Larlet a écrit :
> Bonsoir,
>
> À noter qu'il y a également la possibilité d'utiliser le backend d'authentification RemoteUser qui permet de se logger sur un annuaire LDAP par exemple :
> http://docs.djangoproject.com/en/dev/howto/auth-remote-user/
> Je le mentionne car je l'ai découvert récemment, si certains d'entre vous l'ont déjà essayé je veux bien des retours :-).
>
> Bonne soirée,
> David
>
> Le 3 nov. 2010 à 18:47, Rémy Hubscher a écrit :
>
>> Bonjour,
>>
>> Moi ce que j'avais fait c'était l'inverse.
>> On détecte si l'utilisateur est dans la base Django, s'il n'est pas
>> dedans ou si le mot de passe est erroné, on essaye de le connecter avec
>> son compte LDAP et si ça fonctionne on crée/modifie l'utilisateur Django
>> à partir de la base LDAP.
>>
>> ça à un double avantage qu'il est possible de créer des utilisateurs
>> temporaires qui sont sur l'application mais ne sont pas dans l'annuaire.
>>
>> Par contre j'ai du mal à comprendre pourquoi tu dois pouvoir génerer
>> l'annuaire à partir de la base Django.
>>
>> C'est plutôt l'inverse qui me semble logique car un annuaire permet de
>> se connecter sur plusieurs applications.
>>
>> Or tu veux qu'une application génère l'annuaire pour toute les autres ?
>> Il vaut mieux que l'annuaire génère la base de toutes les applications.
>>
>> Tu pourras ainsi ajouter des champs spécifique à telles ou telles
>> application qui ne seront pas écrasé par la suite.
>>
>> Pour répondre à ta question sur le cryptage, les HASH (md5, sha1, ...)
>> ne permettent pas de trouver le mot de passe à partir du HASH.
>>
>> Donc il va falloir attendre que l'utilisateur te le donne pour vérifier
>> que c'est bien celui qui corresponds au hash et éventuellement générer
>> un nouveau hash.
>>
>> Concernant les hash, ce sont des HASH Hexadécimaux, donc le $ n'est pas
>> dedans. Il n'y a que le 5 qui peut éventuellement ressembler à ce
>> caractère.
>>
>> Je ne suis pas sur que ça réponde à ta question, mais j'espère faire
>> avancer ta recherche.
>>
>> Cordialement,
>>
>> Rémy Hubscher
>>
>> Le mercredi 03 novembre 2010 à 17:16 +0000, S. Bonnegent a écrit :
>>> Bonjour,
>>>
>>> Nous souhaitons exporter / synchroniser notre base d'utilisateurs django
>>> périodiquement pour nourrir une base ldap. Le but étant de pouvoir
>>> refabriquer une base ldap à 100% à partir des utilisateurs django.
>>>
>>> Nous avons un problème au niveau des mots de passe des utilisateurs dans
>>> la base ldap.
>>> Apparemment django stocke par défaut les mots de passes en SHA1 et
>>> utilise le caractère "$" comme séparateur de champs entre algorithme,
>>> salt et mot de passe crypté, or ce caractère
>>> est utilisé dans les mots de passes MD5.
>>>
>>> Bref, est ce que certains d'entre vous ont un retour d'expérience sur ce
>>> type d'utilisation avec une base ldap ? Ou éventuellement sur le type de
>>> cryptage à utiliser (md5, sha1, ssha) ?
>>>
>>>
>>> Cordialement
>>> _______________________________________________
>>> django mailing list
>>> django _AT_ lists.afpy.org
>>> http://lists.afpy.org/mailman/listinfo/django
>>
>>
>> _______________________________________________
>> django mailing list
>> django _AT_ lists.afpy.org
>> http://lists.afpy.org/mailman/listinfo/django
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
iF4EAREIAAYFAkzRxfsACgkQk+uq5YLlwVRBqQD+J0LVRt6RcoQG42VZSCEib/8D
wmpVQTBorax4r1OIK1QA/ipuoDLJdeA67PAIYRvjc3tUYqiCAEjbJeFhgh3iS5q3
=K6Zw
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
iF4EAREIAAYFAkzRxgAACgkQk+uq5YLlwVRABgEAr7FYzt6ZUzmbsIeZANktV97J
zikZ4OTvNvU8U8b3Iv4A/1j1t9n4iCyxrmVfK03ckyMwMfDnROdIRM6jd6/W/igg
=tAEZ
-----END PGP SIGNATURE-----
Hors ligne
Le 3 novembre 2010 19:10, David Larlet <larlet _AT_ gmail.com> a écrit :
> Bonsoir,
>
> À noter qu'il y a également la possibilité d'utiliser le backend d'authentification RemoteUser qui permet de se logger sur un annuaire LDAP par exemple :
> http://docs.djangoproject.com/en/dev/howto/auth-remote-user/
> Je le mentionne car je l'ai découvert récemment, si certains d'entre vous l'ont déjà essayé je veux bien des retours :-).
Cela fonctionne parfaitement bien... en utilisant la bonne incantation
avec Apache, en l'occurrence celle-ci fonctionne pour moi :
WSGIScriptAlias /mon_emplacement /mon_chemein_vers/django.wsgi
<Location /mon_emplacement >
Order allow,deny
Allow from all
AuthType Basic
AuthName "Nom"
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL
ldap://ldap.domaine.com/ou=utilisateur,o=domaine.com?uid??(title=*R*)
require valid-user
RewriteEngine on
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule .* - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e
</Location>
Mais ne me demandez pas pourquoi cela fonctionne, je n'avouerais même
pas combien de poulets j'ai écorché.
Hors ligne
Pour expliquer un peu notre architecture, nous avons d'un côté un SI (qui gére tous les personnels) que nous synchronisons avec notre Django (c'est lui contient pour nous tous les utilisateurs, groupes, ...).
Et c'est ce django qui nous sert à alimenter nos bases ldap qui servent aux différentes applications.
Du coup, c'est le mot de passe django que j'ai besoin d'exporter dans les bases ldap lorsqu'un utilisateur
change son mot de passe. Le django héberge aussi certaines applications qui doivent fonctionner même si les bases ldap ne répondent plus.
Hors ligne
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 4 nov. 2010 à 09:37, S. Bonnegent a écrit :
> Pour expliquer un peu notre architecture, nous avons d'un côté un SI (qui
> gére tous les personnels) que nous synchronisons avec notre Django (c'est
> lui contient pour nous tous les utilisateurs, groupes, ...).
> Et c'est ce django qui nous sert à alimenter nos bases ldap qui servent
> aux différentes applications.
>
> Du coup, c'est le mot de passe django que j'ai besoin d'exporter dans les
> bases ldap lorsqu'un utilisateur
> change son mot de passe. Le django héberge aussi certaines applications
> qui doivent fonctionner même si les bases ldap ne répondent plus.
J'ai oublié de répondre a la question originale, sic.
Il me semble me souvenir dans mes expérimentations que le mot de passe était plutôt ssha que sha1 ou autre, par défaut sur opends/sun directory server. J'ai pas testé openldap.
La syntaxe visible dont je me souviennes étant du type {SSHA}<crypted_password>.
++ Aymeric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
iF4EAREIAAYFAkzSdW4ACgkQk+uq5YLlwVQl5wEA3zN2noRKLYz+j7UtYtcBojLG
oPCJq9m8LxcmahQYSb4A/ibZo3CFuiXRctWQvAK7+YlbHKFLx23J6AYi5wYCTLei
=VX/u
-----END PGP SIGNATURE-----
Hors ligne
Le 4 nov. 2010 à 08:32, Olivier Collioud a écrit :
> Le 3 novembre 2010 19:10, David Larlet <larlet _AT_ gmail.com> a écrit :
>> Bonsoir,
>>
>> À noter qu'il y a également la possibilité d'utiliser le backend d'authentification RemoteUser qui permet de se logger sur un annuaire LDAP par exemple :
>> http://docs.djangoproject.com/en/dev/howto/auth-remote-user/
>> Je le mentionne car je l'ai découvert récemment, si certains d'entre vous l'ont déjà essayé je veux bien des retours :-).
>
> Cela fonctionne parfaitement bien... en utilisant la bonne incantation
> avec Apache, en l'occurrence celle-ci fonctionne pour moi :
>
> WSGIScriptAlias /mon_emplacement /mon_chemein_vers/django.wsgi
> <Location /mon_emplacement >
> Order allow,deny
> Allow from all
> AuthType Basic
> AuthName "Nom"
> AuthBasicProvider ldap
> AuthzLDAPAuthoritative off
>
> AuthLDAPURL
> ldap://ldap.domaine.com/ou=utilisateur,o=domaine.com?uid??(title=*R*)
> require valid-user
> RewriteEngine on
> RewriteCond %{LA-U:REMOTE_USER} (.+)
> RewriteRule .* - [E=RU:%1]
> RequestHeader set REMOTE_USER %{RU}e
> </Location>
>
> Mais ne me demandez pas pourquoi cela fonctionne, je n'avouerais même
> pas combien de poulets j'ai écorché.
Merci beaucoup, j'espère que ça m'évitera d'écorcher du volatile
Bonne journée,
David
Hors ligne
pour ajouter mes 2 centimes, il existe également django-auth-ldap
http://pypi.python.org/pypi/django-auth-ldap/ qui marche très bien pour
utiliser l'authentification LDAP (j'utilise plus particulièrement Active
Directory) pour se connecter sur une appli Django, avec possibilité de faire
des restrictions du genre "il faut appartenir à tel groupe LDAP pour avoir
le droit de se logger" et d'autres fonctionnalités bien sympathiques.
2010/11/8 David Larlet <larlet _AT_ gmail.com>
>
> Le 4 nov. 2010 à 08:32, Olivier Collioud a écrit :
>
> > Le 3 novembre 2010 19:10, David Larlet <larlet _AT_ gmail.com> a écrit :
> >> Bonsoir,
> >>
> >> À noter qu'il y a également la possibilité d'utiliser le backend
> d'authentification RemoteUser qui permet de se logger sur un annuaire LDAP
> par exemple :
> >> http://docs.djangoproject.com/en/dev/howto/auth-remote-user/
> >> Je le mentionne car je l'ai découvert récemment, si certains d'entre
> vous l'ont déjà essayé je veux bien des retours :-).
> >
> > Cela fonctionne parfaitement bien... en utilisant la bonne incantation
> > avec Apache, en l'occurrence celle-ci fonctionne pour moi :
> >
> > WSGIScriptAlias /mon_emplacement /mon_chemein_vers/django.wsgi
> > <Location /mon_emplacement >
> > Order allow,deny
> > Allow from all
> > AuthType Basic
> > AuthName "Nom"
> > AuthBasicProvider ldap
> > AuthzLDAPAuthoritative off
> >
> > AuthLDAPURL
> > ldap://ldap.domaine.com/ou=utilisateur,o=domaine.com?uid??(title=*R*)
> > require valid-user
> > RewriteEngine on
> > RewriteCond %{LA-U:REMOTE_USER} (.+)
> > RewriteRule .* - [E=RU:%1]
> > RequestHeader set REMOTE_USER %{RU}e
> > </Location>
> >
> > Mais ne me demandez pas pourquoi cela fonctionne, je n'avouerais même
> > pas combien de poulets j'ai écorché.
>
> Merci beaucoup, j'espère que ça m'évitera d'écorcher du volatile
>
> Bonne journée,
> David
>
> _______________________________________________
> django mailing list
> django _AT_ lists.afpy.org
> http://lists.afpy.org/mailman/listinfo/django
>
Hors ligne