Que nous réserve la LDAPCon 2017 ?

La LDAPCon est une conférence internationale autour de la technologie LDAP et des enjeux de gestion des identités, d’authentification et d’habilitation.

L’événement qui se déroulera cette année à Bruxelles du 19 au 20 octobre, se tient tous les deux ans dans un pays différent :

Savoir-faire Linux, déjà commanditaire en 2015 (consultez notre retour sur cette édition) renouvelle avec plaisir son soutien à cette communauté en étant une nouvelle fois partenaire de l’édition 2017.

2 jours et 19 conférences, un programme riche et rythmé

Le programme de cette édition promet des interventions intéressantes, parmi lesquelles :

  • ReOpenLDAP : Modification d’OpenLDAP pour une utilisation intensive chez un opérateur de télécommunications
  • OpenLDAP pour Samba 4 : Point sur l’intégration d’OpenLDAP dans Samba 4 en lieu et place de l’annuaire natif codé par l’équipe Samba
  • PHP-LDAP : Des nouvelles de l’évolution de l’API LDAP dans PHP, délaissée depuis plusieurs années et que les développements reprennent
  • OpenLDAP : Des nouvelles du projet OpenLDAP par Howard Chu, le développeur principal

Les sujets afférents à LDAP comme la gestion des identités dans le Cloud, les habilitations/autorisations, l’authentification unique ou encore la supervision seront abordés dans les différentes présentations.

Savoir-faire Linux fera le point sur les différents protocoles de SSO (CAS, SAML et OpenID Connect) dans une intervention donnée vendredi après-midi, juste avant la présentation du logiciel FusionDirectory, le logiciel d’administration des données d’un annuaire LDAP, utilisé dans notre infrastructure interne et chez certains de nos clients.

Si cette conférence vous intéresse, vous pouvez réserver vos billets en ligne sur le site de la conférence.

Des nouvelles du projet LDAP Tool Box, la boîte à outils pour les annuaires LDAP

Le projet LDAP Tool Box rassemble différents outils pour aider les administrateurs LDAP, que ce soit des paquets OpenLDAP, des scripts de supervision ou encore des applications Web. L’objectif est de simplifier la vie des administrateurs LDAP, car comme l’indique la description du projet :

Même les administrateurs LDAP ont besoin d’aide

Tous les outils proposés sont sous licence libre et disponibles sur GitHub.

Supervision

Des greffons de supervision sont fournis pour Nagios (ou tout autre logiciel compatible) et Cacti. Ils permettent par exemple de vérifier le statut de la réplication OpenLDAP, de collecter les statistiques sur les opérations LDAP ou encore surveiller le taux de remplissage d’une base MDB.

16c97f6538278bee29e8b9de1aac3516-media-593x381

Des configurations sont également disponibles pour la pile logicielle ELK (ElasticSearch, Logstash, Kibana) afin de tracer en temps réel l’utilisation des annuaires OpenLDAP.

openldap-elk-ldap-operations

Paquets OpenLDAP

OpenLDAP est le serveur LDAP le plus répandu, très proche du standard et offrant d’excellentes performances. Il est présent dans la plupart des distributions GNU/Linux mais celles-ci font souvent des choix de compilations non avalisées par les développeurs du projet, l’exemple le plus représentatif étant la bibliothèque SSL/TLS.

Le projet LDAP Tool Box fournit des paquets pour les environnements Debian/Ubuntu et Red Hat/CentOS. Ils sont compilés avec OpenSSL et embarquent les overlays officiels ainsi que certains overlays contribués comme « lastbind » et « smbk5pwd ».

Ils offrent également des modules spécifiques de gestion de la qualité des mots de passe comme check_password et ppm. Un script de gestion du service est installé par défaut, permettant les sauvegardes/restaurations des données et de la configuration.

Interface de gestion du mot de passe

L’application Self Service Password permet de fournir aux utilisateurs une interface simple pour changer son mot de passe, ou le réinitialiser quand celui-ci est perdu (ou expiré). Cette réinitialisation peut se faire :

  • Par un lien envoyé par mail
  • Par un code envoyé par SMS
  • Par la réponse à une question

Cette interface est compatible avec différents annuaires LDAP dont Active Directory et Samba 4.

ssp_1_0_change_password

La version 1.0 de ce logiciel est sortie en octobre 2016 (voir l’article sur LinuxFR).

Interface de consultation des données

L’application White Pages est une interface de consultation des données d’un annuaire LDAP, avec les fonctionnalités suivantes :

  • Recherche rapide : une invite de recherche dans le menu permet de retrouver directement des entrées à partir du nom, du prénom, du mail ou de l’identifiant
  • Recherche avancée : un formulaire liste les différents attributs sur lesquels une recherche peut être faite
  • Trombinoscope : toutes les entrées de l’annuaire sont affichées avec leur photo

Ces fonctions peuvent être activées/désactivées et les attributs cherchés ou affichés sont configurables. L’interface peut donc être utilisée avec n’importe quel annuaire LDAP.

wp_0_1_full_display

La version 0.1 de ce logiciel est sortie en novembre 2016 (voir l’article sur LinuxFR).

Relier son application à FranceConnect avec le logiciel libre LemonLDAP::NG

Développé depuis 2014 sous l’égide de la DINSIC, FranceConnect est la nouvelle plate-forme d’authentification à destination des citoyens français pour simplifier l’accès à l’administration en ligne.

Annoncé officiellement il y a quelques jours par le secrétaire d’État chargé de la réforme de l’État et de la simplification, FranceConnect est déjà utilisé par de nombreuses administrations.

Le protocole OpenID Connect

C’est le protocole OpenID Connect qui a été retenu pour FranceConnect, choix risqué en 2014 car le standard n’en était qu’à ses débuts, mais il a depuis fait ses preuves, comme en témoigne son adoption par Google.

J’ai eu l’occasion de présenter ce protocole dans différentes conférences, comme à la LDAPCon en novembre dernier :

LDAPCon2015_OpenIDConnect-Diapos

L’avantage d’avoir opté pour un standard comme OpenID Connect, c’est que cela permet d’utiliser n’importe quel logiciel ayant implémenté ce standard pour se relier à FranceConnect.

lemonldap-ng-france-connect

Depuis la version 1.9 de LemonLDAP::NG, on peut utiliser OpenID Connect, soit comme client (Relying Party), soit comme fournisseur (OpenID Provider).  Une application compatible avec LemonLDAP::NG peut donc alors très facilement récupérer une identité via FranceConnect sans développement supplémentaire !

Configuration de LemonLDAP::NG

Nous allons configurer LemonLDAP::NG comme client OpenID Connect. Pour cela il faut tout d’abord paramétrer le service OpenID Connect :

  • Gérer les règle de redirections (Apache ou Nginx) pour le chemin /oauth2/
  • Choisir « OpenID Connect » comme module d’authentification
  • Définir l’identifiant de l’entité (par défaut l’URL du portail)
  • Laisser les valeurs par défaut pour les points d’accès OAuth2
  • La configuration d’une clé de signature n’est pas nécessaire

Il reste ensuite à inscrire FranceConnect comme fournisseur OpenID Connect :

  • Créer les métadonnées JSON (non fournies par FranceConnect), par exemple (valeurs de la plate-forme de développement) :
{
"issuer": "https://fcp.integ01.dev-franceconnect.fr",
"authorization_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/authorize",
"token_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/token",
"userinfo_endpoint": "https://fcp.integ01.dev-franceconnect.fr/api/v1/userinfo",
"end_session_endpoint":"https://fcp.integ01.dev-franceconnect.fr/api/v1/logout"
}
  • Déclarer les attributs de l’identité pivot à collecter, par exemple : given_name, family_name, birthdate
  • Dans les options, renseigner le client_id et client_secret fourni par FranceConnect (voir l’étape suivante), et le scope lié aux attributs demandés, par exemple : openid email profile birth

Enregistrement auprès de FranceConnect

Pour que votre instance de LemonLDAP::NG puisse être reliée à FranceConnect, il faut formuler une demande officielle via ce formulaire.

Il est important de fournir l’URL de callback, qui par défaut dans LemonLDAP::NG est http://auth.example.com/?openidcallback=1. Mais vous devrez adapter cette URL avec votre propre nom de domaine, et si besoin d’autres paramètres en fonction des modules utilisés dans LemonLDAP::NG.

FranceConnect vous fournira alors les valeurs de client_id et client_secret dont vous avez besoin dans la configuration de LemonLDAP::NG.

C’est terminé !

LemonLDAP::NG est désormais configuré pour s’authentifier sur FranceConnect. Si certaines choses ne fonctionnent pas, référez-vous à la documentation technique disponible sur le site.

Les attributs collectés lors de l’authentification sont disponibles dans la session SSO et peuvent être transmis par LemonLDAP::NG aux applications de différentes façons : en-têtes HTTP, CAS, OpenID Connect ou SAML.

À vous de jouer !

Utilisation de Keepalived pour la haute-disponibilité LDAP et HTTP

Nous déployons régulièrement des infrastructures LDAP et WebSSO chez nos clients, et se pose toujours la question de la haute-disponibilité : la plate-forme d’authentification devenant centrale, il est indispensable de se prémunir d’un arrêt de service, que ce soit de l’annuaire LDAP ou du portail d’authentification Web. Nous allons voir comment le logiciel Keepalived peut nous aider à répondre à ce besoin.

ka-header

Des logiciels d’infrastructure adaptés

Avant d’envisager la mise en place d’outils de haute-disponibilité, il faut s’assurer que les logiciels principaux de l’infrastructure sauront fonctionner dans ce mode, c’est-à-dire qu’ils peuvent être installés sur plusieurs nœuds (serveurs physiques, virtuels ou conteneurs) et opérer de la même façon quelque soit le nœud actif.

Dans notre cas, nous utiliserons les logiciels suivants :

  • OpenLDAP : serveur d’annuaire compatible LDAPv3
  • LemonLDAP::NG : produit de WebSSO compatible CAS, SAML et OpenID Connect

OpenLDAP-logo

OpenLDAP sait fonctionner en mode multi-maîtres depuis plusieurs années, via le protocole SyncRepl. Le mode « miroir » (mirror mode) est particulièrement pertinent dans une architecture à deux nœuds où un seul d’entre eux sera contacté par les clients (l’important ici est d’éviter que des opérations d’écriture soient faites simultanément sur les deux nœuds). La configuration de ce mode est détaillée dans le guide d’administration d’OpenLDAP.

LemonLDAP::NG

LemonLDAP::NG pour sa part a été conçu dès le départ pour pouvoir utiliser des bases externes pour la gestion de ses données (configuration et sessions). Ainsi il est possible de déployer autant de nœuds que nécessaire en partageant les données entre les nœuds. Pour ma part, j’utilise régulièrement l’annuaire OpenLDAP comme stockage de la configuration et des sessions : l’annuaire étant déjà redondé, pas besoin de travail supplémentaire pour le WebSSO. Mais vous pouvez également utiliser des bases de données SQL (MySQL, PostGreSQL) ou NoSQL (MongoDB, Redis, Cassandra) pour assurer ce service.

Utilisation d’une adresse virtuelle

Une fois les deux nœuds installés, chacun possède son adresse IP propre et il faut trouver un moyen d’indiquer aux applications clientes quel nœud utiliser.

Une première solution est le Round-Robin DNS : au nom DNS ldap.example.com ou auth.example.com on associe les deux adresses IP, et charge aux clients de se débrouiller avec ça. Dans le cas de HTTP, la plupart des clients sauront rejouer les requêtes sur la seconde IP si la première ne fonctionne pas, mais ce n’est pas aussi évident pour les clients LDAP.

L’autre solution est d’utiliser une adresse IP virtuelle qui sera associée au nœud principal. Le nœud secondaire est opérationnel mais ne sera pas associé à l’adresse IP virtuelle, jusqu’à ce que celle-ci bascule en cas de problème du nœud principal. Dans cette situation, la haute-disponibilité est bien gérée du côté des serveurs, et non du côté des clients qui ne contacte qu’une seule adresse, l’adresse IP virtuelle.

Utilisation de Keepalived

Le logiciel Keepalived permet de gérer une IP virtuelle qui sera associée au nœud principal tant que celui-ci est opérationnel. Le protocole VRRP est utilisé entre les nœuds pour gérer cette adresse IP virtuelle.

Sa configuration est assez simple :

vrrp_instance VI_SFL {
  state MASTER
  priority 150
  nopreempt
  interface eth0
  virtual_router_id 69
  advert_int 5
  authentication {
     auth_type PASS
     auth_pass KEEPALIVED_PASSWORD
  }
  virtual_ipaddress {
    10.10.0.10/22 brd 10.10.0.255 dev eth0 scope global
  }
}

Il est intéressant de paramétrer la partie « authentication » pour éviter que les ordres VRRP soient pris en compte par d’autres routeurs non associés à la grappe de serveurs. Seuls les serveurs disposant du même mot de passe consommeront les requêtes.

Le paramètre « priority » permet d’indiquer le nœud principal. Le ou les nœuds secondaires auront une priorité plus faible (par exemple 100).

Script de surveillance

Cette configuration initiale n’est pas suffisante pour palier à des problèmes applicatifs : l’adresse IP virtuelle basculera si le nœud principal ne répond plus au protocole VRRP, mais rien n’est fait pour surveiller l’annuaire LDAP ou le serveur HTTP.

Keepalived permet d’utiliser un « track_script » dans lequel nous sommes libres de lancer les commandes que nous souhaitons. Si ce script s’exécute sans erreurs, alors le nœud est considéré comme opérationnel, sinon il est mis en quarantaine.

L’appel au script se configure simplement :

vrrp_script check_server_health {
  script "/usr/local/bin/check_server_health.sh"
  interval 2
  fall 2
  rise 2
}

vrrp_instance VI_SFL {
  ...
  track_script {
    check_server_health
  }
}

Voici un exemple de script :

#!/bin/bash

# Script that do several checks to verify LDAP/SSO service is up
#
# Returns 0 if all is fine
#
# Copyright (c) 2016 Clement Oudot @ Savoir-faire Linux


# Disks

rootuse=$(df -H / | grep -v 'Filesystem' | awk '{ print $5 }' | cut -d'%' -f1)

if [ $rootuse -ge 95 ]; then
        echo "Partition / is full ($rootuse%)"
        exit 1
else
        echo "Partition / is OK ($rootuse%)"
fi

# Process
            
openldapprocess=$(/bin/pidof slapd)
apacheprocess=$(/bin/pidof apache2)

/usr/local/openldap/bin/ldapsearch -x -H ldap://localhost -b '' -s base -l 3 > /dev/null 2>&1
ldapresponse=$?

if [ -z "$openldapprocess" ]; then  
        echo "OpenLDAP is not running"
        exit 1
else
        echo "OpenLDAP is running (PID $openldapprocess)"
fi

if [ "$ldapresponse" -gt 0 ]; then
        echo "OpenLDAP is not anwering on RootDSE"
        exit 1
else
        echo "OpenLDAP is answering on RootDSE"
fi

if [ -z "$apacheprocess" ]; then
        echo "Apache is not running"
        exit 1
else
        echo "Apache is running (PID $apacheprocess)"
fi

# Exit without problem
exit 0

J’utilise plusieurs type de vérifications dans ce script :

  • Contrôle de l’espace disque
  • Contrôle des démons lancés
  • Réponse à une requête LDAP

Bien entendu, charge à vous d’y mettre les vérifications qui vous semblent pertinentes.

Découverte d’OpenStack à l’OpenStack Workshop Lyon

La communauté OpenStack FR a organisé le 15 juin 2016 une journée sur Lyon dédié à OpenStack : OpenStack Workshop Lyon (ou OWL pour les intimes).

OpenStack FR

J’ai participé à cet atelier pour découvrir un peu mieux OpenStack et rencontrer les membres influents de sa communauté en France.

La journée est introduite par Adrien Cunin de chez Osones qui présente les différents ateliers de la journée : introduction à OpenStack, déploiement, contribution.

20160615_094813 Pour ma part, bien qu’ayant déjà touché à OpenStack, je choisi l’atelier introduction animé par Christophe Sauthier d’Objectif Libre.

20160615_110128

Après une présentation théorique d’OpenStack et de ses différents composants, nous passons à la pratique en utilisant un compte OVH (qui dispose de sa propre offre OpenStack).

Notre première étape est le démarrage d’une instance basée sur une image fournie par Christophe, image qui n’est autre qu’une installation d’OpenStack : nous voici alors avec un serveur OpenStack maison installé sur une instance OpenStack d’OVH (qui a dit Inception ?).

Grâce à ce serveur, nous pouvons découvrir les outils d’administration d’OpenStack et dans un « tenant » de démonstration créer nos premières instances. Toujours via l’interface d’administration (module horizon) nous paramétrons le réseau, les règles de sécurité, les clés SSH, etc. Nous obtenons rapidement un environnement fonctionnel.

Le reste de la journée est consacré à quelques détails sur les différents modules :

  • neutron pour la partie réseau
  • cinder pour la gestion des volumes
  • swift pour le stockage objet
  • heat pour l’orchestration
  • et bien entendu nova pour le déploiement des instances

Nous apprenons à nous servir de la ligne de commande (et par un hasard fortuit également comment analyser les messages d’erreur d’OpenStack). On conclut cette journée en déployant une instance avec la ligne de commande nova, ce qui nous laisse entrevoir toutes les possibilités d’automatisation de déploiement, mais cela sera pour un prochain atelier.

Un grand merci aux organisateurs et aux sponsors qui ont permis la tenue de cet événement :

sponsorfinal2