* Moi c'est ce 1.3.6.1.4.1.40098 dans ton schéma, j'aimerais savoir d'où il vient. C'est toi qui l'a inventé ?
Sinon je vais expliquer brièvement :
objectClass : Définit la classe d'un objet dans ton annuaire. La classe de l'objet permet d'avoir des attributs sur cette objet. Chaque objet peut avoir une et une seule classe _structurelle_ et autant de classes _auxiliaires_ que tu souhaites.
Quand tu créés un objet, tu lui donne une classe structurel (dans ton cas tes utilisateurs ont inetOrgPerson comme classe structurelle). Ensuite tu lui ajoutes une classe auxiliaire posixAccount pour avoir accès à de nouveaux attributs.
Chaque classe a des attributs obligatoires et des attributs facultatifs (must, may). Tous les attributs obligatoires doivent être renseignés.
Les classes supportent l'héritage. Toutes les classes descendent de la classe "top". inetOrgPerson hérite de organizationalPerson qui hérite de person qui hérite de top.
Lorsqu'une classe hérite d'une autre, elle a les attributs des classes parentes plus ses propres attributs.
Donc tu dois ajouter une classe à ton objet (mail=test@flo-debian.gescom,ou=Users,dc=flo-debian,dc=gescom) pour qu'il ait accès aux attributs de posixAccount. Ensuite tu peux renseigner les attributs nécessaires.
Ensuite le DN et le RDN. Le RDN c'est le DN relatif. Pour uid=ebagnoud,ou=users,o=iro (je prends un exemple plus court que tes DN), le RDN est uid=ebagnoud, le DN c'est le chemin complet (uid=ebagnoud,ou=users,o=iro). DN ça veut dire Distinguished Name (qui vient de "specified" donc spécifier, préciser. Donc le nom "précis" ou "spécifique"). RDN c'est Relative Distinguished Name.
Le DN te sert à identifier une entrée dans un annuaire uniquement (c'est un chemin comme "/home/ebagnoud/docs/ldap/export.ldif")
Les filtres de recherches LDAP sont prévus pour chercher sur tout les objets inclus par la zone de recherche (tu as trois niveaux de recherche : base, one, subtree) et tous les attributs des objets.
Si tu cherches (&(objectClass=inetOrgPerson)(uid=ebagnoud)) sur "ou=users,o=iro" avec un niveau "one", tu vas avoir tous les objets ayant l'uid ebagnoud et la classe inetOrgPerson dans le niveau directement au dessous (donc s'il y a un uid=ebagnoud,ou=it,ou=users,o=iro), celui-ci ne sera pas dans le résultat. Si tu changes le niveau en subtree, il sera dans le résultat. Base étant uniquement chercher dans l'objet spécifier.
Donc il faut :
1) Répondre à la question en début de commentaire, c'est super important
2) Un export de l'utilisateur
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Configuration ?
Posté par Etienne Bagnoud . En réponse au message Installation Dovecot Postfix. Évalué à 2.
Sinon je vais expliquer brièvement :
objectClass : Définit la classe d'un objet dans ton annuaire. La classe de l'objet permet d'avoir des attributs sur cette objet. Chaque objet peut avoir une et une seule classe _structurelle_ et autant de classes _auxiliaires_ que tu souhaites.
Quand tu créés un objet, tu lui donne une classe structurel (dans ton cas tes utilisateurs ont inetOrgPerson comme classe structurelle). Ensuite tu lui ajoutes une classe auxiliaire posixAccount pour avoir accès à de nouveaux attributs.
Chaque classe a des attributs obligatoires et des attributs facultatifs (must, may). Tous les attributs obligatoires doivent être renseignés.
Les classes supportent l'héritage. Toutes les classes descendent de la classe "top". inetOrgPerson hérite de organizationalPerson qui hérite de person qui hérite de top.
Lorsqu'une classe hérite d'une autre, elle a les attributs des classes parentes plus ses propres attributs.
Donc tu dois ajouter une classe à ton objet (mail=test@flo-debian.gescom,ou=Users,dc=flo-debian,dc=gescom) pour qu'il ait accès aux attributs de posixAccount. Ensuite tu peux renseigner les attributs nécessaires.
Ensuite le DN et le RDN. Le RDN c'est le DN relatif. Pour uid=ebagnoud,ou=users,o=iro (je prends un exemple plus court que tes DN), le RDN est uid=ebagnoud, le DN c'est le chemin complet (uid=ebagnoud,ou=users,o=iro). DN ça veut dire Distinguished Name (qui vient de "specified" donc spécifier, préciser. Donc le nom "précis" ou "spécifique"). RDN c'est Relative Distinguished Name.
Le DN te sert à identifier une entrée dans un annuaire uniquement (c'est un chemin comme "/home/ebagnoud/docs/ldap/export.ldif")
Les filtres de recherches LDAP sont prévus pour chercher sur tout les objets inclus par la zone de recherche (tu as trois niveaux de recherche : base, one, subtree) et tous les attributs des objets.
Si tu cherches (&(objectClass=inetOrgPerson)(uid=ebagnoud)) sur "ou=users,o=iro" avec un niveau "one", tu vas avoir tous les objets ayant l'uid ebagnoud et la classe inetOrgPerson dans le niveau directement au dessous (donc s'il y a un uid=ebagnoud,ou=it,ou=users,o=iro), celui-ci ne sera pas dans le résultat. Si tu changes le niveau en subtree, il sera dans le résultat. Base étant uniquement chercher dans l'objet spécifier.
Donc il faut :
1) Répondre à la question en début de commentaire, c'est super important
2) Un export de l'utilisateur
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell