Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
technique:adminsys:ldap:intro [2020/09/09 02:53] – qduchemi | technique:adminsys:ldap:intro [2022/05/24 21:10] (Version actuelle) – ppom | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | {{indexmenu_n> | ||
+ | # Structure et clarification du LDAP | ||
+ | |||
+ | Cette page présente la structure de l' | ||
+ | |||
+ | Cette page tente d' | ||
+ | |||
+ | ## Introduction | ||
+ | |||
+ | Une des difficultés de LDAP, à mon sens, est de comprendre ce qu'il fait et ne fait pas. | ||
+ | |||
+ | LDAP est basiquement un **annuaire arborescent d' | ||
+ | |||
+ | Chaque entrée se compose d' | ||
+ | |||
+ | Les attributs sont regroupés au sein de classes. Les entrées ont donc des classes, qui indiquent les attributs qu' | ||
+ | |||
+ | Chaque entrée a un DN (`Distinguished Name`) qui permet de l' | ||
+ | |||
+ | Pris dans son ensemble, un annuaire LDAP **ne fait rien**. Ce n'est pas parce qu'on indique avec des attributs LDAP qu'un utilisateur a le droit de se connecter à `pica02` qu'il pourra le faire. C'est ensuite aux **clients** de l' | ||
+ | |||
+ | En gros, l' | ||
+ | |||
+ | Cette page donne donc la structure qu'on a choisie pour les besoins de Picasoft, mais ce n'est qu'une description sémantique : un annuaire LDAP avec cette structure ne fera **rien** sans paramétrage des clients. Quand on dit : | ||
+ | |||
+ | *Toute personne ayant tel groupe peut faire ceci* | ||
+ | |||
+ | C'est **faux** tant que ça n'a pas été configuré comme tel. | ||
+ | |||
+ | ## Général | ||
+ | |||
+ | Toutes les entrées doivent avoir un attribut `cn` (Common Name) ou `ou` (Organizational Unit). Cet attribut constitue le RDN (analogie à un nom de fichier ou de répertoire). | ||
+ | |||
+ | Pour les OU elles-mêmes, | ||
+ | |||
+ | ## Organizational Units | ||
+ | |||
+ | Les **OU** sont des entrées qui servent essentiellement à classer leurs entrées enfants, et permettent de filtrer les recherches. On peut les voir comme des **dossiers**. | ||
+ | |||
+ | On utilise trois OU : | ||
+ | |||
+ | * `People`, pour stocker les comptes d' | ||
+ | * `Groups`, pour stocker les groupes d' | ||
+ | * `Services` pour stocker les comptes des services eux-mêmes | ||
+ | |||
+ | ## Groups | ||
+ | |||
+ | Les entrées stockées dans l'OU `Groups` représentent des groupes sur Linux. Chaque utilisateur de l'OU `People` est associé à au moins un groupe, qui sera utilisé pour donner des permissions spécifiques sur les machines ou les services. | ||
+ | |||
+ | Tous les groupes ont pour classe `posixGroup`, | ||
+ | |||
+ | * `tech` (`500`) : ce groupe sera mappé sur le groupe `docker` des machines. Il permet donc d' | ||
+ | * `admin` (`501`) : ce groupe sera mappé sur le groupe `sudo` des machines. Tout compte de `People` ayant un GID de `501` sera donc `sudoer` sur les machines auxquelles il a accès. | ||
+ | * `member` (`502`) : membre de l' | ||
+ | |||
+ | < | ||
+ | |||
+ | Notez que les groupes `tech`, `admin` et `member` sont prévus pour être mutuellement exclusifs : on est l'un des trois. | ||
+ | |||
+ | ## People | ||
+ | |||
+ | Les entrées stockées dans l'OU `People` permettent de créer des comptes d' | ||
+ | |||
+ | Détaillons les classes utilisées par toutes les entrées de `People` : | ||
+ | |||
+ | ### hostObject | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | Il peut être dupliqué autant de fois que nécessaire, | ||
+ | |||
+ | ### inetOrgPerson | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | `inetOrgPerson` propose énormément d' | ||
+ | |||
+ | ### ldapPublicKey | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | Laisser cet attribut vide interdira l' | ||
+ | |||
+ | ### posixAccount | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | * `loginShell` : Chemin du shell lors de la connexion | ||
+ | * `homeDirectory` : Chemin du `$HOME` de l' | ||
+ | * `uid` : Nom d' | ||
+ | * `uidNumber` : UID sur la machine, nombre unique. Par convention, il commence par `2000`. | ||
+ | * `gidNumber` GID sur la machine, c' | ||
+ | * `userPassword` : Mot de passe du compte. | ||
+ | |||
+ | ### shadowAccount | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | Si `shadowExpire` vaut `-1`, l' | ||
+ | |||
+ | ### authorizedServiceObject | ||
+ | |||
+ | Permet d' | ||
+ | |||
+ | ## Services | ||
+ | |||
+ | Les entrées sous l'OU `Services` permettent de créer des comptes pour les services de Picasoft (e.g. Mattermost, Wekan, Wiki...) | ||
+ | |||
+ | Elles sont de deux types : | ||
+ | |||
+ | #### Pour interroger le LDAP | ||
+ | |||
+ | Il s'agit d' | ||
+ | |||
+ | Les classes de ce genre d' | ||
+ | |||
+ | #### Pour avoir un compte (permissions, | ||
+ | |||
+ | Un service qui ne tourne pas en tant que `root`, comme Mattermost, doit bien avoir un compte POSIX disponible pour créer des fichiers. C'est fait dans le LDAP, pour éviter de le faire sur chaque machine susceptible de faire tourner Mattermost. | ||
+ | |||
+ | On utilise les classes `organizationRole` et `posixAccount`, | ||
+ | |||
+ | Aussi, certains services, comme le mail, imposent que chaque adresse mail (e.g. `mattermost@picasoft.net`) soit associé à un compte POSIX. |