Refactorisation et ajout de contenus sur la configuration

+Un annuaire LDAP contiennent des branches, dans ces branches, on peut avoir des groupes `organizationalUnit`, puis finalement à la fin de la hiérarchie, on trouve des éléments `commonName`. Chaque élément est une instance d'une classe (`objectClass`) et ces objets contiennent des attributs.

+Pour son utilisation, le ResEl a défini quelques objets LDAP spécifiques, [vous pouvez les retrouver dans la configuration](https://git.resel.fr/confs/ldap/blob/master/schema/resel-14628.schema), voici une description :

+Classes définies :

+- *enstbPerson* : pesonne ayant un compte ecole (tt le monde sur l'annuaire)

+- *maiselPerson* : personne ayant une chambre a la maisel

+- *reselPerson* : personne ayant au moins une machine au resel

+- *mailPerson* : personne ayant un compte mail sur le resel

+- *aePerson* : personne membre de l'Association des Eleves

+- *club* : un club

+- *poste* : un poste dans un club

+- *machine* : une machine ayant une ip sur le resel

+- *administrateur* : personne ayant des droits d'administration sur le resel

+- *reselSwitch* : switch (contenant des ports comme fils)

+- *switchPort* : association port/(No de chambre ou autre switch ou rien)

+- *snmpType* : type de switch, ses fils d?crivent comment manipuler un switch

+- *mib* : reference vers une valeur lisible (voire modifiable) du switch

+- *mibValue* : valeur possible pour un mib donn?

+- *guestPerson* : personne residant a la MaisEl temporairement mais ne disposant pas de compte ecole

+L'utilitaire `slaptest` permet de tester la validité de la configuration du serveur.

+

+Le *daemon* est géré par un simple service SysVinit : ```service slapd (start|stop|restart|status)```

+**Important : Ne jamais lancer slapd en tant que root**

+

+Voici des éléments importants de la configuration du LDAP :

+Dans `master.cf`, on commence par définir divers paramètres de fonctionnement du serveur, on inclut les fichiers de configurations annexes, notemment les schémas LDAP.

+

+```ini

+include /etc/ldap/schema/resel-14628.schema

+include /etc/ldap/access-master.ldap

+```

+

+La première ligne inclut les schémas spécifiques au ResEl, la seconde inclut les règles d'accès aux éléments du LDAP en configurant les droits. Voir les parties suivantes pour plus de détails.

+

+Ensuite on configurer l'emplacement des certificats TLS.

+```ini

+TLSVerifyClient never

+TLSCertificateKeyFile /etc/ldap/tls/ldap-key.pem.nopass

+TLSCertificateFile /etc/ldap/tls/ldap-crt.pem

+TLSCACertificateFile /etc/ldap/tls/cacert.pem

+```

+

+Divers configurations pour les pid files et log files, certains paramètres de lancement définis dans le fichier `/var/run/slapd/slapd.args`.

+Puis des définitions des noms des modules noyaux qui vont être lancés par sladp.

+

+Enfin commence la configuration elle même des bases de données.

+

+On commence par indiquer que le backend est *bdb* : `backend bdb`.

+

+On déclare la branche ldap `maisel` avec :

+```ini

+database bdb

+

+suffix "dc=maisel,dc=enst-bretagne,dc=fr"

+```

+

+Puis la configuration de cette branche suit, on commence par définir le *DN root* et le *mot de passe root* contenus dans le fichier `include /etc/ldap/rootdn-master.ldap`. Puis le chemin de sauvegarde physique de la BDD `directory "/var/lib/ldap/maisel"` et finalement divers options d'*indexing* et d'activation de fonctionnalité comme `memberof`.

+

+Les lignes suivantes active la synchronisation de la branche.

+```ini

+overlay syncprov

+syncprov-checkpoint 100 10

+syncprov-sessionlog 100

+```

+

+Puis la configuration de la branche `resel` suit, configurée de la même manière.

+La configuration de schémas est incluses dans tout les fichiers `schema/*.schema`. Elle configure tout les *objectClass* et *attributeType* décrits dans la section [Mise en place](#mise-en-place_structure-de-l-arbre_description-des-objets-resel).

+

+Voici la syntaxe des fichiers de schéma.

+

+#### Création d'un attribut

+

+Syntaxe :

+```ini

+attributetype ( 1.3.6.1.4.1.14628.3.0 NAME 'firstName'

+ DESC 'Prénom'

+ EQUALITY caseIgnoreMatch

+ ORDERING caseIgnoreOrderingMatch

+ SUBSTR caseIgnoreSubstringsMatch

+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

+ SINGLE-VALUE )

+```

+

+Le numéro `1.3.6.1.4.1.14628.3.0` définit ??

+Le champ `syntaxe` ??

+

+#### Création d'un ObjectClass

+

+Syntaxe:

+```ini

+objectclass ( 1.3.6.1.4.1.14628.1.7 NAME 'reselMachine' STRUCTURAL

+ DESC 'Machine ayant une IP et une entrée dans le DNS'

+ MUST ( host $ uidProprio $ ipHostNumber $ macAddress $ zone )

+ MAY ( hostAlias $ lastDate $ ipv6HostNumber $ paramConn $ duidHostNumber $ ipv6HostPrefix $ description $ group ) )

+```

+

+Le champ `MUST` précise les attributs obligatoires à renseigner, `MAY` ceux optionnels.

+La configuration des droits est définie dans `acces-(slave|master).conf`

+

+À Brest, on définit globalement les règles suivantes :

+- Accès au CN *Monitor* par l'utilisateur `admin` (pas les admins en général).

+- Accès au CN *accesslog* par un *ldapadmin* (cn ayant le champ droit `ldapadmin`), l'admin et le *replicator*.

+- Accès au CN à divers élements (et le droit associé) aux admins ayant le droit en question. (Voir l'article [gestion des droits des admins](/)

+- Accès au mot de passe par l'utilisateur lui même, par un *ladpadmin*, par le *replicator* en lecture, par tout le monde en comparaison.

+- Accès à la clé privé d'un admin par lui même, ansible et le replicator en lecture

+- Accès au branche *organisation* et au *sites* par les membres qui sont dans le *memberUid* du site, ou les *reseladmin*.

+- Acces à tout par tout le monde en lecture.

+

+

+#### Explication de la syntaxe

+

+Voir la [documentation officielle](http://www.openldap.org/doc/admin24/access-control.html) pour plus de détails.

+

+La syntaxe est la suivante :

+```

+access to <champ>

+ by <regle dacces> <droit>

+```

+Globalement, on configure l'accès à un endroit précis du LDAP via le *champ*, cela peut être sous la forme d'un DN : `dn.subtree="cn=Monitor"``, ce DN va préciser le CN précise, ou tout une branche ou un groupe ; ou plus généralement avec des wildcars comme `*`.

+On peut un attribut avec `attrs=droit` ou plus spécifiquement l'attribut d'un objet précis avec `attrs=<attr> dn.subtree=<dn_voulu>`.

+

+Puis les règles d'accès consiste à vérifier comparer le CN de l'utilisateur qui accède (car tout les utilisateurs qui accèdent au LDAP se connectent avec un CN du LDAP). On peut donc vérifier que le cn vaut exactement quelque chose `by dn.exact="cn=admin,dc=maisel,dc=enst-bretagne,dc=fr"` ou être plus précis en vérifiant un attribut du CN : `set.exact="user/droit* & [ldapadmin]" write`.

+Dans cette règle d'accès, `this` pointe sur l'élément auquel on tente d'accéder, et `user` pointe sur l'utilisateur qui veut y accéder. On accède aux valeurs des attributs par le `/`. On précise une chaîne telle quelle entre `[ ]`

+Pour vérifier une égalité de champs, on peut utilise `set.exact="this/attr1 & user/attr2", ou `set.exact="user/attr & [foo]"

+

+Finalement le droit est soit *read* soit *write* ou *compare*. Le droit *compare* est par exemple utile pour vérifier si un mot de passe est le bon sans avoir à le lire.

+Les machines du ResEl (machines utilisateurs et serveur) sont enregistrées dans le ldap avec un type `reselmachine` qui contient un champ `lastdate`. Ce champ `lastdate` permet de mettre les machines en zone inactive lorsqu'elle ne sont pas vues sur le réseau depuis un certains temps.

+