Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

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/07 17:29] – [Services] qduchemitechnique:adminsys:ldap:intro [2022/05/24 21:10] (Version actuelle) ppom
Ligne 3: Ligne 3:
 # Structure et clarification du LDAP # Structure et clarification du LDAP
  
-Cette page présente la structure de l'annuaire LDAP. Techniquement, cette structure se retrouve [ici](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-openldap/bootstrap).+Cette page présente la structure de l'annuaire LDAP. Techniquement, cette structure se retrouve [ici](https://gitlab.utc.fr/picasoft/projets/services/openldap/-/tree/master/bootstrap).
  
-Cette page tente d'expliquer le pourquoi du comment du LDAP. Pour créer des utilisateurs ou des services, consultez les sections dédiées du wiki.+Cette page tente d'expliquer le pourquoi du comment du LDAP. Pour créer des utilisateurs ou des services et avoir plus de détails, consultez les pages dédiées du wiki.
  
 ## Introduction ## Introduction
Ligne 21: Ligne 21:
 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'annuaire de regarder le bon attribut, de l'interpréter et de donner l'autorisation. 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'annuaire de regarder le bon attribut, de l'interpréter et de donner l'autorisation.
  
-En gros, l'ajout d'attributs dans le LDAP ne change rien si le client n'a pas été paramétré pour prendre en compte ces attributs. On pourra voir la page [[technique:adminsys:ldap:installation|authentification LDAP sur les machines]] ou [[technique:adminsys:wiki#changement_de_methode_d_authentification|authentification sur le Wiki avec LDAP]] pour un exemple.+En gros, l'ajout d'attributs dans le LDAP ne change rien si le client n'a pas été paramétré pour prendre en compte ces attributs. On pourra voir la page [[technique:adminsys:tips:auth_ldap|authentification LDAP sur les machines]] ou [[technique:adminserv:wiki#changement_de_methode_d_authentification|authentification sur le Wiki avec LDAP]] pour un exemple.
  
 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 : 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 :
Ligne 54: Ligne 54:
 * `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. * `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'association. Accès basique aux machines (pas de possibilité d'utiliser Docker, par exemple). Permet de se connecter aux services réservés aux membres (Cloud, édition du Wiki...). * `member` (`502`) : membre de l'association. Accès basique aux machines (pas de possibilité d'utiliser Docker, par exemple). Permet de se connecter aux services réservés aux membres (Cloud, édition du Wiki...).
-* `representant` (`503`) : indique les représentants de l'association, qui ont par exemple accès aux ressources privées du wiki. En pratique, ce groupe est peu utilisé, mais il existe au cas où. 
  
-Notez que les groupes `tech`, `admin` et `member` sont prévus pour être mutuellement exclusifs : on est l'un des trois. Par contre, `representant` est prévu pour être un groupe **secondaire** : on peut être `member` et, en plus,  `representant`.+<bootnote>`admin` est aussi utilisé pour les services avec authentification LDAP pour distribuer les droits d'administration.</bootnote>
  
-Pour l'entrée `representant`, on a un attribut supplémentaire `memberUid`, que l'on peut dupliquer autant de fois que de représentants, et qui liste les `UID` des membres du groupe.+Notez que les groupes `tech`, `admin` et `membersont prévus pour être mutuellement exclusifs : on est l'un des trois.
  
 ## People ## People
Ligne 103: Ligne 102:
 ### authorizedServiceObject ### authorizedServiceObject
  
-Permet d'utiliser l'attribut `authorizedService`, qui indique le ou les services réservés auxquels l'utilisateur peut accéder. Par exempleseules les personnes avec un `authorizedService` à `mail` peuvent utiliser leur adresse mail Picasoft.+Permet d'utiliser l'attribut `authorizedService`, qui indique le ou les services réservés auxquels l'utilisateur peut accéder. Cet attribut est peu utilisé en pratiquemais un service peut filtrer les utilisateurs qui peuvent l'utiliser (ce serait le cas pour le mail, par exemple).
  
 ## Services ## Services
Ligne 109: Ligne 108:
 Les entrées sous l'OU `Services` permettent de créer des comptes pour les services de Picasoft (e.g. Mattermost, Wekan, Wiki...) 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 trois types :+Elles sont de deux types :
  
 #### Pour interroger le LDAP #### Pour interroger le LDAP
Ligne 117: Ligne 116:
 Les classes de ce genre d'entrées sont `simpleSecurityObject`, pour pouvoir indiquer un mot de passe (`userPassword`), et `organizationRole`, pour pouvoir indiquer un `cn`. Les classes de ce genre d'entrées sont `simpleSecurityObject`, pour pouvoir indiquer un mot de passe (`userPassword`), et `organizationRole`, pour pouvoir indiquer un `cn`.
  
-#### Pour gérer les permissions sur les machines+#### Pour avoir un compte (permissions, mail)
  
-Un service qui ne tourne pas en tant que `root`, comme Mattermost, doit bien avoir un compte POSIX de créé pour créer des fichiers. C'est fait dans le LDAP, pour éviter de le faire sur chaque machine susceptible de faire tourner Mattermost.+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`, ce qui nous permet de spécifier l'UID et le GID. Le GID sera toujours celui du groupe `membre` (`502`), qui ne donne aucun accès particulier sur les machines. On utilise les classes `organizationRole` et `posixAccount`, ce qui nous permet de spécifier l'UID et le GID. Le GID sera toujours celui du groupe `membre` (`502`), qui ne donne aucun accès particulier sur les machines.
  
-#### Pour envoyer des mails +Aussicertains servicescomme le mail, imposent que chaque adresse mail (e.g. `mattermost@picasoft.net`) soit associé à un compte POSIX.
- +
-C'est la même logique que pour les permissions : il faut un compte POSIX pour envoyer et stocker les mails sur la machine. Il peut s'agir de mails de notificationsde confirmation d'inscriptionetc. +
- +
-On utilise les mêmes classes que pour les services ayant besoin de créer des fichiers, et on ajoute la classe `authorizedServiceObject` pour pouvoir mettre `authorizedService` à `mail`, ce qui donne l'autorisation d'envoyer des mails.+
  • technique/adminsys/ldap/intro.1599492570.txt.gz
  • de qduchemi