==== LDAP-FusionDirectory ==== ====== Préambule ====== Installation de OpenLDAP + FusionDirectory sur une debian fraîchement installée.\\ Apache et PHP5 sont déjà installés. ===== Délégation d'administration ===== 2018-09-30 by thomas Objectif: permettre à un utilisateur de gérer son organisation et ses utilisateurs via FD Fait: - création d'une organisation de test (wildmyrtille) - affectation d'une ACL : turlux et thomas //admin// de la branche - recopie du modèle "utilisateur hadoly" dans la branche - connexion en tant que "thomas" sur FD: - on ne voit que la branche wildmyrtille (impossible de remonter dans l'arborescence, impossible de voir les autres utilisateurs / domaines) - on peut créer un compte utilisateur fonctionnel en utilisant le modèle Conclusion: il est possible de déléguer l'administration d'une branche à un utilisateur. ===== Configurer une nouvelle application ===== :!: **attention de ne pas exposer le nom / prénom de l'adhérent via ldap: les champs sn et cn ne doivent pas être récupérés par LDAP, lui préférer l'attribut __displayName__ qui doit normalement correspondre au pseudo** En règle général, l'accès à un service (application) est basé sur l'appartenance du compte qui se connecte au groupe correspondant. Créer un groupe d'accès à l'application, à la racine, nommé //application_group// (voir par exemple le groupe //mail_group// ) Créer un compte ldap lecteur dédié à l'application. (voir par exemple le compte //doku-account// dans la branche service) Configurer l'application avec les informations suivantes: * adresse du serveur: ldaps:/ /leodagan.hadoly.fr * port: 636 (pas d'accès en clair) * base de recherche: dc=hadoly,dc=fr * filtre de recherche. Celui-ci doit vérifier que le compte est bien membre du groupe permettant l'accès à l'application. Par exemple: (&(|(objectclass=gosaMailAccount))(|(memberof=cn=cloud_group,ou=groups,dc=hadoly,dc=fr))) Ce filtre vérifie: - le compte est du type gosaMailAccount (càd un utilisateur) - le compte est membre du groupe cloud_group ===== Authentification des utilisateurs ===== 2017-02-20: by thomas, tentative de mise en œuvre sur guetenoch doc de référence: https:%%//%%documentation.fusiondirectory.org/en/documentation/plugin/ssh_plugin/how_to_setup_ssh_plugin * leodagan: installation du plugin fusiondirectory-plugin-ssh * leodagan: installation et activation du schéma adhoc : * leodagan: activation du schéma fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/openssh-lpk.schema * Après s'être déconnecté reconnecté sur fusion directory, dans la gestion des utilisateurs apparaît un nouvel onglet "SSH" permettant de créer puis enregistrer les infos ssh Sur chaque machine: ==== Configurer auth ldap: ==== apt-get install ldap-auth-client nscd auth-client-config -t nss -p lac_ldap ==== Configurer ssh pour qu'il recherche les clé publiques dans ldap: ==== déployer le script suivant: cat /usr/local/bin/ldap_fetch_authorizedkeys.sh #! /bin/bash ldapsearch -xLLL '(&(objectClass=posixAccount)(uid='"$1"'))' 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/\n *//g;s/sshPublicKey: //gp' Ce script doit appartenir à root et être exécutable par n'importe qui (au moins par nobody) Rajouter les directives suivantes dans la configuration ssh: AuthorizedKeysCommandUser nobody AuthorizedKeysCommand /usr/local/bin/ldap_fetch_authorizedkeys.sh J'ai rajouté une tâche //auth_ldap.yml// au rôle ansible //base// qui réalise les 2 manips décrites ci-dessus. Je n'ai pas testé. # Authentification chez Hadoly ===== Implémentation retenue ===== * chacun des membres a un compte utilisateur (centralisé dans un annuaire) * la gestion des autorisations d'accès se fait en se basant sur des groupes LDAP (compte d'admin par exemple) * tous les flux sont chiffrés * certains membres (comme un asso) peuvent avoir plusieurs utilisateurs (qui leur sont spécifiques) * seuls les comptes Hadoly sont pris en compte pour la gestion des moyens communs: pas question qu'un compte d'association * interface web de gestion des comptes avec des modèles. * stockage des clefs SSH dans le comptes utilisateurs (XXX préciser l'utilisation exacte) * systeme cible: OpenLDAP dans container LXC Debian * prevoir le cas: autres (sous-)organisation que Hadoly (asso par exemple) ===== Organisation Schéma LDAP ===== * XXX preciser les schema employes, notamment les **types d'objets.** * XXX contraintes sur les uid/gid: [500..800] pour LDAP && hadoly, > 2000 si asso ? * XXX groupes: par membres sur les utilisateurs ou referals dans les groupes ? Organisation de l'annuaire: on reste en "''%%dc=,dc=%%''" pour se faciliter la vie (et la config du paquet Debian).\\ On utilise l'organisation suivante: + dc=hadoly,dc=fr # le Root DN | +-- cn=admin # OpenLDAP superuser | +-- ou=people # compte utilisateurs Hadoly (contient les admin des applis et des infras) | | | +-- cn=pierre # exemple: compte utilisateur du petit Pierre | +-- ou=groups # les groupes Hadoly | +-- ou=service # comptes/groupes pour les applis pour binder LDAP | | | +-- ou=account # les comptes | | | | | +-- cn=owncloud-nginx # exemple: compte pour l'appli owncloud (frontal nginx) | | | +-- ou=roles # groupes pour définir les droits LDAP des "account" sur l'annuaire | | | +-- cn=ldap-ro-people-cn-and-sshpubkey-only # exemple | +-- cn=ldap-ro-people-cn-and-passwd # exemple | +-- ou=dns # objets pour le DNS (nécessaire ?) | +-- ou=subent # les entites membres d'Hadoly (association) avec plusieurs utilisateurs/groupes | | | +-- cn=asso1 # association "asso1" | +-- ou=people # comptes utilisateurs de | +-- ou=groups # groupe de ====== OpenLDAP ====== ===== Fichiers et répertoires ===== Description des fichiers et répertoires contenant le stockage (backend) de OpenLDAP * service d'arrêt/démarrage de service: ''%%/etc/init.d/slapd%%'', paramétré par le contenu du fichier ''%%/etc/default/slapd%%'', * fichiers de configuration: dans le répertoire `/etc/ldap/slapd.d/' * PAS de fichier de configuration initiale de slapd (comme ''%%/etc/ldap/slapd.conf%%'') : * tout est dans le baseDN ''%%cn=config%%'' pour permettre des modification de configuration sans arrêt du service. * En fait, des fichiers sont auto-générés pour le (re)démarrage du service:\\ cf ''%%/etc/ldap/slapd.d/cn\=config.ldif%%'',\\ cf répertoire ''%%/etc/ldap/slapd.d/cn\=config/%%'' XXX fichiers de bases de données (à sauvegarder). ===== Installation (initiale) ===== Puisqu'on l'installe dans un environnement Debian, on commence par suivre le guide d'installation Debian:\\ https://wiki.debian.org/LDAP/OpenLDAPSetup Note: à ce stade, on suppose juste que l'on a un shell root dans un environnement "quelconque" sous Debian: * on suppose juste que l'on est sous Debian Jessie (8.3) * soit dans une VM, soit dans un conteneur LXC * AUCUNE hypothèse sur l'environnement réseau (hostanme, addresse IP et son entrée DNS associée) Installation du paquet contenant le serveur OpenLDAP et des outils clients LDAP (''%%ldapadd%%'', ''%%ldapmodify%%'').\\ L'installation du paquet permet de définir le mot de passe administrateur LDAP (''%%cn=admin,dc=nodomain%%'' à cet instant): $ sudo aptitude install slapd ldap-utils [...] Setting up slapd (2.4.40+dfsg-1+deb8u2) ... Setting up ldap-utils (2.4.40+dfsg-1+deb8u2) ... Le service est alors opérationnel: On reconfigure alors le paquet Debian du LDAP pour Hadoly avec le paramétrage suivant (cas où le système n'a pas encore une config "hadoldy"): $ sudo dpkg-reconfigure slapd * Omit OpenLDAP server configuration? NO * DNS domain name: hadoly.fr * Organization name: Hadoly * administrator password: ********** (compte `cn=admin,dc=hadoly,dc=fr`) * Database backend to use: [mdb] (choix par défaut) * Do you want the database to be removed when slapd is purged? YES * Move old database? YES * Allow LDAPv2 protocol? NO ===== Tests basiques ===== ===== Index sur les objets LDAP ===== Comme indiqué dans la doc Debian, on rajoute des index supplémentaires pour avoir un service plus rapide. Pour déterminer les index à rajouter, rechercher //candidates// dans les logs ldap: sudo journalctl -x --unit slapd| awk '/indexed/{print $7, $8}' | sort | uniq -c si un attribut apparaît fréquemment, rajouter un index. De mon (thomas) point de vue les index de type **eq** sont contre performants. Par **défaut**, on a les index suivants: $ ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase={1}mdb)" olcDbIndex SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (olcDatabase={1}mdb) # requesting: olcDbIndex # # {1}mdb, config dn: olcDatabase={1}mdb,cn=config olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On créer un fichier LDIF contenant les index supplémentaires à créer (basé sur la page Debian et adapté): $ cat olcDbIndex.ldif dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcDbIndex olcDbIndex: cn,uid eq - add: olcDbIndex olcDbIndex: cn pres,sub,eq - add: olcDbIndex olcDbIndex: sn pres,sub,eq - add: olcDbIndex olcDbIndex: uid pres,sub,eq - add: olcDbIndex olcDbIndex: displayName pres,sub,eq - add: olcDbIndex olcDbIndex: default sub - add: olcDbIndex olcDbIndex: mail,givenName eq,subinitial - add: olcDbIndex olcDbIndex: dc eq Fichier que l'on applique au serveur: $ ldapmodify -Y EXTERNAL -H ldapi:/// -f ./olcDbIndex.ldif Vérifions que les nouveaux index sont en place: $ ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase={1}mdb)" olcDbIndex SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (olcDatabase={1}mdb) # requesting: olcDbIndex # # {1}mdb, config dn: olcDatabase={1}mdb,cn=config olcDbIndex: objectClass eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: cn pres,sub,eq olcDbIndex: sn pres,sub,eq olcDbIndex: uid pres,sub,eq olcDbIndex: displayName pres,sub,eq olcDbIndex: default sub olcDbIndex: mail,givenName eq,subinitial olcDbIndex: dc eq # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ===== Injection des subdivisions pour Hadoly ===== Rajoutons les quelques objets manquants en utilisant ''%%ldapadd%%'' (ce qui permet de vérifier l'accès au LDAP en mode client/serveur): # ldapadd -x -D "cn=admin,dc=hadoly,dc=fr" -W -f ./hadoly.ldif adding new entry "ou=people,dc=hadoly,dc=fr" adding new entry "ou=groups,dc=hadoly,dc=fr" adding new entry "ou=subent,dc=hadoly,dc=fr" [...] Le fichier ''%%.ldif%%'' pour les ajouts contient ceci (avec une ligne vide à la fin !!): # cat hadoly.ldif dn: ou=people,dc=hadoly,dc=fr objectClass: organizationalUnit ou: people dn: ou=groups,dc=hadoly,dc=fr objectClass: organizationalUnit ou: groups dn: ou=subent,dc=hadoly,dc=fr objectClass: organizationalUnit ou: subent dn: ou=service,dc=hadoly,dc=fr objectClass: organizationalUnit ou: service dn: ou=account,ou=service,dc=hadoly,dc=fr objectClass: organizationalUnit ou: account dn: ou=roles,ou=service,dc=hadoly,dc=fr objectClass: organizationalUnit ou: roles ===== (WIP) Sauvegarde et restauration des données ===== Sauvegarde au format LDIF: # slapcat -s dc=hadoly,dc=fr | gzip > /path/to/backup.hadoly.ldif.gz # slapcat -s cn=config | gzip > /path/to/backup.config.ldif.gz Procédures de backup/restauration (à tester et valider) : * https:%%//%%help.ubuntu.com/12.04/serverguide/openldap-server.html#ldap-backup * http:%%//%%blog.panek.work/2015/08/29/openldap_backup_restore.html ===== (todo) Securisation et durcissement LDAP ===== Le service LDAP n'a pas vocation a être utilisée publiquement, mais uniquement de fournir un service d'authentification et d'autorisation à d'autres services Hadoly (front-end web par exemple). Il convient de le fiabiliser et le sécuriser autant que possible. * XXX filtrage réseau sur toute cette machine: uniquement depuis notre sous-réseau public * XXX sans doute laisser passer l'interface d'administratation (HTTPS) ? * XXX uniquement du LDAPS ===== (todo) LDAP à LDPAS ===== ldaps en place avec certificat auto signé. serveur accessible uniquement en ldaps et socket. ===== (todo) Groupes LDAP ===== * XXX gestion des appartenances par référal, ça semble plus souple ? * XXX pas de contraintes pour les applications ? elles savent gerer les referals ? * XXX mécanisme type memberOf au niveau LDAP ? Utilisation de l'overlay //memberof// qui permet de récupérer (via l'attribut //memberof//) la liste des attributs auxquels appartient un utilisateur. Cela permet des requètes du style: ldapsearch uid=test1 memberof ldapsearch memberof=cn=cloud_group,ou=groups,dc=hadoly,dc=fr ===== (todo) contraintes diverses, templates ===== en vrac: * XXX restrictions d'accès ? * XXX contraintes sur les uid ? * XXX contraintes sur les mots de passe ? * XXX quel frontal utiliser ? ===== (todo) OpenSSH et LDAP ===== XXX Pas encore mis en place Notre but est : * de stocker les clefs publiques de chaque utilisateur dans l'annuaire LDAP * d'utiliser ces clefs publiques stockées dans le LDAP à être utilisé par OpenSSH. Par contre, les docs existantes indiquent comment faire pour que ça fonctionne en se logguant en tant que utilisateur ''%%X%%'' sur le système distant, et non pas ''%%Y@local%%'' vers ''%%root@distant%%'' ... va falloir tweaker un peu la conf, genre faire renvoyer l'équivalent d'un cat de toutes les clefs publiques pour tous les utilisateurs (que l'on filtrera sans doute suivant une contrainte particulière, genre appartenance à un groupe particulier). * XXX plusieurs pubkey SSH possibles par utilisateur ? * XXX autre solution: autoriser le login en tant que ''%%X@distant%%'' et autoriser ''%%sudo%%'' pour l'utilisateur ''%%X%%'' sur le système ''%%distant%%'' ? Documentation, pointeurs: * http://pig.made-it.com/ldap-openssh.html * "AuthorizedKeysCommand" of OpenSSH ?\\ https://imil.net/blog/2013/04/29/debian-backport-of-openssh-6-2/\\ http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-161/AuthorizedKeysCommand-quand-OpenSSH-devient-CloudSSH.-Nan-j-deconne * [old] OpenSSH PLK patch: "permits the use of an OpenLDAP server as an SSH public key provider":\\ http://code.google.com/p/openssh-lpk/ * CentOS/RedHat:\\ http://itdavid.blogspot.fr/2013/11/howto-configure-openssh-to-fetch-public.html ===== (todo) configuration Ansible ===== * XXX détailler (exemple) la configuration ansible pour déployer un tel service ===== (todo) maintenance courante ===== * XXX ajout/suppression d'utilisateurs * XXX interface de gestion: phpldapadmin ? FusionDirectory ? * XXX restriction d'accès à l'interface de gestion ? ===== (todo) Configuration des applis clientes LDAP ===== * XXX bind anonyme ou pas pour les applicatifs ? * XXX config nginx * XXX config Apache HTTP server * XXX config OpenSSH * XXX config owncloud * XXX config SMTP server: postfix * XXX config IMAP server ===== (todo) divers ===== * XXX réplication multi-master * XXX Délégation d'authentification (Google, ConnectFrance, OpenID ... ) ? * XXX SSO * XXX OTP ===== Outil server: ldapsearch (via LDAPI) ===== Exemple: recherche de tout les noms des objets présents dans l'annuaire:\\ (juste leur entrées, on ne voit pas leur(s) attribut(s)) # ldapsearch -Y EXTERNAL -H ldapi:/// -b "dc=hadoly,dc=fr" dn SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree filter: (objectclass=*) # requesting: dn # # hadoly.fr dn: dc=hadoly,dc=fr # admin, hadoly.fr dn: cn=admin,dc=hadoly,dc=fr # people, hadoly.fr dn: ou=people,dc=hadoly,dc=fr [...] ===== Outil server: slapcat (via LDAPI) ===== Permet de récupérer des "dump" des données LDAP (pas au format LDIF par contre).\\ ''%%slapcat%%'' est un outil "serveur": n'utilise pas le mode client/server, mais un accès via socket unix (ldapi), donc doit être exécuté sur le même hôte que le service LDAP. thomas: non, les commandes slapcat, slapadd, slapindex et slaptest n'accèdent pas au serveur via le socket, mais va taper directement dans les fichiers de bdd. Ça marche même quand le serveur est down. D'ailleurs, il vaut mieux éviter d'utiliser ces commandes si le serveur est en cours de fonctionnement (sauf slapcat). Exemple: listons rapidement tous les dn (//Distinguished Name//) présents dans ''%%cn=config%%'':\\ (juste leur entrées, on ne voit pas leur(s) attribut(s)) # slapcat -s cn=config | grep ^dn dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config ===== Outil client: ldapvi ===== ldapvi est un éditeur en mode texte spécialisé pour l'édition d'un annuaire LDAP. Installation sous Debian: $ apt-get install ldapvi Exemple d'utilisation: $ ldapvi --user "cn=admin,dc=hadoly,dc=fr" -b "dc=hadoly,dc=fr" Pour éditer l'entrée "''%%cn=config%%''" , il faut passer par une socket unix (ldapi): $ ldapvi -h ldapi:/// -Y EXTERNAL -b cn=config L'installation par défaut ne permet pas d'accéder à la branche cn=config via le réseau. Découverte et quelques tips d'utilisation: Références: * http://www.lichteblau.com/ldapvi/ * Un bon tutoriel sur l'utilisation de ldapvi:\\ http://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-104/ldapvi-un-editeur-LDAP-pour-les-barbus ====== FusionDirectory (FD) ====== Suite à l'installation de OpenLDAP, on installe FusionDirectory pour réaliser les opérations courantes de maintenance à l'aide d'une interface web.\\ FusionDirectory permet également de mettre en place des ACLs et des rôles dans l'annuaire LDAP. Apache et php5 sont déjà installés. Je me suis basé sur la doc de FusionDirectory : https://documentation.fusiondirectory.org/en/documentation_admin Enfin, basé... Je l'ai suivi à la lettre. ===== Installation de FusionDirectory ===== On utilise le dépôt officiel de FusionDirectory pour Debian pour les paquets binaires (plutôt que de l'installer et de le maintenir "à la main"). ==== Mise en place du dépôt des paquets binaires ==== Récupération de la clef GPG du dépôt de FusionDirectory. Le serveur GNUPG défini dans la doc de Fusion Directory est en erreur et ne permet pas de récupérer la clé. On peut utiliser le serveur hébergé chez Ubuntu : $ sudo gpg --keyserver keyserver.ubuntu.com --recv-key 62B4981F $ sudo gpg --export -a "Fusiondirectory Archive Manager " > FD-archive-key $ sudo apt-key add FD-archive-key On ajoute (on déclare) les dépôts de Fusion Directory comme source de paquets: $ sudo cp -p /etc/apt/sources.list /etc/apt/sources.list.old $ sudo echo 'deb http://repos.fusiondirectory.org/debian-jessie jessie main' >> /etc/apt/sources.list $ sudo apt-get update ==== FusionDirectory et ses schémas LDAP ==== On commence par installer le gestionnaire des schémas LDAP de Fusion Directory: $ sudo apt-get install fusiondirectory-schema Et on lance son initialisation, ce qui a pour effet de référencer lesdits schémas dans le serveur OpenLDAP: $ sudo fusiondirectory-insert-schema [...] executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/fusiondirectory/core-fd.ldif' adding new entry "cn=core-fd,cn=schema,cn=config" [...] executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/fusiondirectory/core-fd-conf.ldif' adding new entry "cn=core-fd-conf,cn=schema,cn=config" [...] executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/fusiondirectory/ldapns.ldif' adding new entry "cn=ldapns,cn=schema,cn=config" [...] executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/fusiondirectory/template-fd.ldif' adding new entry "cn=template-fd,cn=schema,cn=config" On peut alors installer le paquet FusionDirectory, ce qui amène environ 140 paquets en dépendance (Apache HTTP, PHP, openssl, etc): $ sudo apt-get install fusiondirectory Liste des schémas FusionDirectory installés à ce stade: $ sudo fusiondirectory-insert-schema -l core cosine nis inetorgperson core-fd core-fd-conf ldapns template-fd ==== les plugins de FusionDirectory ==== FusionDirectory est architecturé à l'aide de plugins, permettant de n'ajouter que les fonctionnalités dont on a besoin. L'installation des plugins se fait toujours suivant la même séquence: $ sudo apt-get install fusiondirectory-plugin- $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/.schema Il existe de nombreux plugins, ils sont listé dans la doc de FD que j'ai posté plus haut. Rappel: liste des schémas FusionDirectory installés: $ sudo fusiondirectory-insert-schema -l ==== Plugin "Systems" ==== XXX quelle utilité ? $ sudo apt-get install fusiondirectory-plugin-systems $ sudo apt-get install fusiondirectory-plugin-systems-schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/service-fd.schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/systems-fd-conf.schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/systems-fd.schema ==== Plugin "Mail" ==== NB: le plugin "Mail" dépend du plugin "Systems". XXX quelle utilité ?\\ On pourra créer des serveurs postfix et imap/pop $ sudo apt-get install fusiondirectory-plugin-mail $ sudo apt-get install fusiondirectory-plugin-mail-schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/mail-fd.schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/mail-fd-conf.schema ==== Plugin "dovecot" ==== Le plugin "dovecot" dépend du plugin "Mail" On pourra créer des serveurs dovecot $ sudo apt-get install fusiondirectory-plugin-dovecot $ sudo apt-get install fusiondirectory-plugin-dovecot-schema $ sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/dovecot-fd.schema ===== Mise à jour ===== 2017-02-26 Symptôme: lors d'une connexion sur FD, on obtient un message d'erreur concernant un attribut indéfini. C'est lié à une mise à jour, qui nécessite apparemment une réinstallation manuelle des nouveaux schémas ldap: for i in /etc/ldap/schema/fusion-directory/* ; do fusiondirectory-insert-schema -m $i ; done ===== Paramétrage initial à l'aide du webinstaller ===== Une fois les paquets installés pour FusionDirectory, on peut démarrer sa configuration via son interface web. Sous Debian, l'interface web est à l'adresse http://your-web-server/fusiondirectory L'installeur commence par demander une confirmation que l'on est bien admin du système sur lequel il se trouve via une ligne de commande du style: $ sudo echo -n TrucBidule13546 > /var/cache/fusiondirectory/fusiondirectory.auth La suite de l'installation se décompose en vérifications (modules PHP nécessaires) et en configurations diverses détaillées ci-dessous. ==== Vérification de l'installation PHP ==== * Language Setup : [automatic] * Vérification de l'installation de PHP: * vérifie que tous les modules PHP requis sont bien installés : support de LDAP, gettext, curl, iconv, IMAP, etc. * que la configuration de PHP est OK :\\ PHP version,\\ register_globals = off, session.gc_maxlifetime >= 86400, session.auto_start = Off,\\ memory_limit >= 128, implicit_flush = Off, max_execution_time >= 30\\ expose_php = Off, zend.ze1_compatibility_mode = Off => Rien eu à modifier, tout est OK avec les configuration par défaut Debian. ==== Configuration de la connexion au serveur LDAP ==== * LDAP connection setup: * location name: default * connection URI: ldaps:%%//%%leodagan.hadoly.fr/dc=hadoly,dc=fr * Base DN: **''%%dc=hadoly,dc=fr%%''** * admin DN: **''%%cn=admin%%''** (relatif à ''%%,dc=hadoly,dc=fr%%'') * Admin password: ''%%*********%%'' A ce point de la configuration, la connexion à OpenLDAP se fait en tant que ''%%cn=admin,dc=hadoly,dc=fr%%''. ==== Configuration de FusionDirectory ==== Pas grand-chose à dire: beaucoup de paramètres, on fait donc des choix plutôt guidés par les valeurs par défaut pour le moment. XXX documenter ''%%ou=aclroles%%'' dans le schema general. ==== (ongo) Vérification de la compatibilité des entrées LDAP avec FusionDirectory ==== XXX ''%%ou=aclroles%%'' contient quoi ? XXX quel est le ''%%dn%%'' de l'utilisateur ''%%fd-admin%%'' ? XXX on peut faire du CAS aussi (désactivé par defaut) ==== (todo) Génération du fichier de config ==== Le webinstaller propose de générer un fichier ''%%fusiondirectory.conf%%''.\\ On le télécharge et on le sauvegarde en tant que fichier ''%%/etc/fusiondirectory/fusiondirectory.conf%%'' Pour vérifier que les permissions et le contenu du fichier ''%%/etc/fusiondirectory/fusiondirectory.conf%%'' sont corrects: $ sudo fusiondirectory-setup --check-config XXX ou sont stockes tous les settings que l'on a fait ? dans ''%%cn=config%%'' ? XXX le fichier /etc/fusiondirectory/fusiondirectory.conf ne contient que peu de choses ===== (todo) La suite ===== J'ai eu un petit bug lors de mes test du plugin Systems. Il n'avait pas d'encodage défini et faisait une erreur lorsqu'on essaye de créer un System Allez dans Configuration puis dans l'onglet Systèmes. Dans "divers" fixez un encodage. Au hasard UTF-8 ? Et voilà ! Il reste à voir commment Kerkeros s'interface avec mais je pense pas qu'il y ai de soucis. Pour le moment je ne suis pas du tout à l'aise avec LDAP et ses dénominations ce qui va me ralentire pour interfacer Postfix et Dovecot avec LDAP. ====== Self Service Password (SSP) ====== Self Service Password est une application développée par Clément Oudot permettant à un utilisateur de modifier/réinitialiser son mot de passe. Le service est accessible à l'adresse http(s):%%//%%mdp.hadoly.fr. ===== Installation ===== $ sudo vim /etc/apt/sources.list.d/ltb-project.list Ajouter deb http://ltb-project.org/debian/jessie jessie main et sauvegarder $ wget -O - http://ltb-project.org/wiki/lib/RPM-GPG-KEY-LTB-project | sudo apt-key add - $ apt update && apt install self-service-password ===== Configuration ===== La configuration se fait dans le fichier /usr/share/self-service-password/conf/config.inc.php ==== /usr/share/self-service-password/conf/config.inc.php ====