===== Structure de l'annuaire LDAP Anarcha =====
Ceci contiens la description des principales structures utilisée par le [[ldap]] d'Anarcha.
Nous afficherons ici les champs obligatoire, et les liens entre les objets et leurs parents.

Pour plus d'information sur les schema, et notamment pour trouver les attributs de tel ou tel objet, il y a la une liste des attributs sur le site de [[http://www.zytrax.com/books/ldap/ape/|Zabix]]

Notre top dn est dn: ''dc=anarcha,dc=pink'' et sera abrégé par **TOPDN** dans la suite du document.

=== dn: ou=Users,TOPDN ===
<code|ldif>
objectClass: organizationalUnit
ou: Users
</code>
Cette OU a vocation à recevoir l'ensemble des utilisatrices du système, et correspond donc aux personnes voulant s'en servir.

== dn: uid=<username>, ou=Users, TOPDN ==
<code|ldif>
uid: <username>
cn: <username>
sn: <username>
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ldapPublicKey
loginShell: /bin/bash
homeDirectory: /home/<username>
uidNumber: <uid>
gidNumber: <gid>
sshPublicKey: <.ssh/id_rsa.pub>
</code>

Ceci correspond aux comptes ayant besoin d'obtenir un shell sur le système, et reçoivent donc les objectClass ''posixAccount'' et ''shadowAccount''. Si la personne possède déjà un compte unix, on peut récupérer ses uid et gid. Sinon il faut faire attention à assigner des uid/gid qui n'existent pas ailleurs.

posixAccount et shadowAccount sont des classes Auxiliaires, qui ont donc besoin d'une classe Structurelle (ici person).

On ajoute aussi la classe ldapPublicKey permettant de stocker les clefs [[ldap-ssh|ssh]] des utilisateurs devant se connecter à la machine

== dn: cn=<username>,ou=Users,TOPDN ==
<code|ldif>
cn: <username>
sn: <username>
objectClass: top
objectClass: inetOrgPerson
mail: <email addresse>
</code>
Ceci correspond à une personne disposant d'une adresse mail. Comme inetOrgPerson est une classe structurelle, il est possible de l'ajouter aux classes posixAccount et shadowAccount afin d'avoir un utilisateur disposant à la fois d'un compte shell ET d'une bôite mail.

=== dn: ou=Groups,TOPDN ===
== dn: cn=<group>,ou=Groups,TOPDN ==
<code|ldif>
objectClass: top
objectClass: posixGroup
objectClass: groupOfNames
cn: <group>
gidNumber: <gid>
member: uid=nobody,ou=System,TOPDN
</code>

Cet objet correspond à un groupe Posix permettant de gérer les droits utilisateurs sur les machines. Comme nous utilisons le schéma rfc2307bis, la classe posixGroup est une classe accessoire, qui va avec une classe groupOfNames afin de permettre le fonctionnement de [[ldapo-memberof|memberOf]].

== dn: cn=<group>,ou=Groups,TOPDN ==
<code|ldif>
objectClass: top
objectClass: groupOfNames
member: uid=nobody,ou=System,TOPDN
</code>

Cet objet est utilisé pour les groupes applicatifs, ne disposant pas de login sur un système (listes de diffusion, etc).

=== dn: ou=System,TOPDN ===
== dn: uid=nobody,ou=System,TOPDN ==
<code|ldif>
dn: uid=nobody,ou=System,dc=anarcha,dc=pink
uid: nobody
cn: nobody
sn: nobody
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/nologin
homeDirectory: /nonexistent
uidNumber: 65534
gidNumber: 65534
</code>

Cet utilisateur permet de créer des groupes vides. Il ne dispose d'aucun droits tels que spécifier dans les [[ldap-acl|ACL]] LDAP.

== cn=system,ou=System,dc=anarcha,dc=pink ==
<code|ldif>
cn: system
sn: system
objectClass: top
objectClass: person
</code>

Cet utilisateur pas les droits en lecture sur la base et sert aux applications n'ayant pas à écrire de pouvoir accéder au contenu de l'arbre. Certaines applications peuvent ne pas savoir faire de bind anonymous, ou l'utilisateur anonyme peut ne pas avoir accès en lecture aux bases