ORappel

L’objectif de cette série d’articles est de bâtir un cloud privé depuis le début.

Nous avons abordé l’architecture de référence Open Stack, l’architecture technique et l’architecture réseau.

Nous allons rajouter dans cette architecture réseau, les services minimums :

– annuaire des utilisateurs

– serveur de temps

– serveur dhcp

– serveur dns

 

La finalité est que les problèmes liés à l’infrastructure ne soit pas dans les root case des incidents de notre plateforme. De plus, ces services sont indispensable lors des mitigations de sécurité.

 

En résumé, nous allons mettre un serveur central (qui pourra être redondé, cela fera partie d’un article complémentaire) et une gestion d’un template de service qui contient l’inclusion et la déclaration client de ces services.

Serveur LDAP

Le service LDAP va héberger les fonctions d’authentification, les zones dns et la configuration dhcp. Cela apporte à ces services une gestion dynamic (sans redémarrage) et une réactivité aux changements de configuration de la plateforme.

 

Les étapes de la configuration de ce serveur que nous appellerons annuaire :

– installation d’une VM Debian 10

– installation de Openldap et sécurisation des flux avec TLS

– installation et configuration de Fusiondirectory, une application centralisée qui gère les utilisateurs, les zones dns, les configurations dhcp

– déclaration d’utilisateur dans l’annuaire

– intégration de l’authentification système (OS) avec comme fournisseur d’identité LDAP

– gestion des clés SSH depuis l’annuaire

– gestion de SUDO depuis l’annuaire

– configuration du service DHCP avec LDAP

– configuration du service DNS avec LDAP

 

Installation d’une VM debian 10

 

La VM annuaire fonctionnera sur le réseau admin et uniquement celui-ci. On installe donc celui-ci avec la commande suivante

virt-install --name annuaire \
 --ram 2048 --vcpus 2 \
 --disk path=/var/lib/libvirt/images/annuaire.qcow2,size=20 \
 --os-type linux --os-variant debian10 \
 --network network=admin,model=virtio --graphics vnc \
 --console pty,target_type=serial \
 --location 'http://ftp.debian.org/debian/dists/stable/main/installer-amd64/' \
 --extra-args 'console=ttyS0,115200n8 serial'

 

Choisissez une installation de base avec service ssh.

Après l’installation de l’OS, nous pouvons procéder à la configuration de système. C’est à dire définir statiquement l’adresse ip et son hostname:

ip : 192.168.200.10/24

gateway : 192.168.200.1

dns : 192.168.200.1

hostname : annuaire.lab.ezydata.fr

Le DNS sera changé au moment de l’installation de bind9. Ces configurations s’effectuent dans le fichier de configuration /etc/network/interfaces

 

 

OpenLDAP avec certificat public/privé

 

La nouvelle  procédure d’installation OpenLDAP récupère les informations du FQDN saisie lors de l’installation OS. Dans notre cas, la base dc=lab,dc=ezyddata,dc=fr nous convient. Si vous devez le changer, alors saisissez dpkg-reconfigure slapd.

 

sudo apt -y slapd ldap-utils

création d’un certificat pour le serveur annuaire

Nous allons sécurisé les flux réseaux par le chiffrement TLS avec l’utilisation de certificats. Par conséquent la création de certificat ne diffère pas de ceux pour le VPN.

 

Remarque : la deuxième commande sert à enlever le mot de passe du certificat.

Remarque : ce certificat sera aussi utilisé par Apache. Nous nous attarderons à gérer des certificats avec un SAN (subject Alternative Name) dans un autre article.

jph@ezydata:~/jphCA$ OPENSSL_CONFIG="-config ./openssl.cnf" ./CA.pl -newreq
...
Common Name (e.g. server FQDN or YOUR name) []:annuaire.lab.ezydata.fr
...

jph@ezydata:~/jphCA$ OPENSSL_CONFIG="-config ./openssl.cnf" ./CA.pl -sign
...
jph@ezydata:~/jphCA$ mv newkey.pem jphCA/private/annuaire.lab.ezydata.fr.key
jph@ezydata:~/jphCA$ mv newcert.pem jphCA/certs/annuaire.lab.ezydata.fr.pem

jph@ezydata:~/jphCA$ scp jphCA/private/annuaire.lab.ezydata.fr.key \
 jphCA/certs/annuaire.lab.ezydata.fr.pem \
 jphCA/cacert.pem \
 secours@192.168.200.10:/home/secours

 

Déclaration de l’autorité de certification

Il est important que l’autorité de certification soit intégré dans l’OS afin que les commandes ou services reposant sur OpenSSL reconnaisse notre certificat comme valide.

C’est de cette façon que les certificats tel verisign et consort sont intégré au système et qui nous permet de visiter des sites dont les certicats sont émis par eux d’être considérés comme valide.

Cela nous permet surtout de ne plus nous soucier d’inclure l’autorité de certification dans tous les services avec SSL/TLS.

root@annuaire:~# cp /home/secours/cacert.pem /usr/local/share/ca-certificates/ezydata.crt
root@annuaire:~# update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

#verifier que le certificat root a été bien installé dans le système

root@annuaire:~# openssl verify /home/secours/annuaire.lab.ezydata.fr.pem
/home/secours/annuaire.lab.ezydata.fr.pem: OK

root@annuaire:~# mkdir /etc/ssl/openldap

Configuration de OpenLDAP pour la prise en charge de SSL/TLS

Si vous avez déjà utilisé OpenLDAP dans les versions précédentes, la configuration de celui-ci pouvait être par fichier de configuration ou directement via la base config.

Par défaut dans les versions de Debian 10, c’est la configuration par database qui est défini. C’est pourquoi, il faut utiliser des commandes de type ldapmodify et des fichiers ldif ayant une structure particulière. Ce fichier est structuré de la manière suivante :

– première ligne le noeud sur lequel nous voulons intervenir

– deuxième ligne : le type d’action que l’on souhaite parmis modify, delete(suppression du noeud), modrdn

– troisième ligne et les suivantes (sauf pour delete) : les informations sur l’objet de l’action

– pour modrdn : le nouveau dn: …

– pour modify, le type de modification parmis replace, add, delete. Ces types de modification porte sur les attributs du noeud.

Ce que nous souhaitons faire est de rajouter des attributs aux noeuds cn=config (c’est la portée globales de paramètre de configuration). Ces attributs sont TLSCACertificate, TLSCertificateKeyFile et TLSCertificateFile qui respectivement servent à définir l’autorité de certification servant à signer le certificat public, la clé privé et le certificat public.

Si vous ne partez pas de zéro, il se peut que ces informations soient présents alors l’instruction n’est plus add mais replace.

Remarque 1:  OpenLDAP dans cette version ne prend pas en charge les liens symboliques comme cible de ces options.

Remarque 2: si vous avez des erreurs, il se peut que vous ayez des problèmes de droit de lecture par l’utilisateur exécutant slapd. Effectuez un test su – openldap file /etc/ssl/openldap/certificat pour savoir si l’utilisateur peut lire ce fichier.

root@annuaire:~# cat ldap-tls.ldif
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/openldap/ezydata.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.key
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.pem

root@annuaire:~# ldapmodify -vvvvv -Y EXTERNAL -H ldapi:/// -f ldap-tls.ldif

Vérification de la configuration

Afin déviter des diagnostiques complémentaire, nous allons vérifier la configuration par deux actions simples. L’un consiste à s’assurer que les attributs soient les bons avec les bonnes valeurs et l’autre est de demander à ldap de vérifier la validité de la configuration.

 

root@annuaire:~# slapcat -b "cn=config" | grep -E "olcTLS"
olcTLSCACertificateFile: /etc/ssl/openldap/ezydata.crt
olcTLSCertificateKeyFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.key
olcTLSCertificateFile: /etc/ssl/openldap/annuaire.lab.ezydata.fr.pem

root@annuaire:~# slaptest -u
config file testing succeeded

redémarrage de Openldap

Si vous redémarrer le daemon slapd tel quel, vous n’aurez pas une sécurisation de flux (à moins de demander start tls par le client) car celui-ci n’écoute pas sur le port 636 (port ldaps). Pour cela, nous devons modifier le fichier de configuration se trouvant /etc/default/slapd.

sudo sed -i 's/\(^SLAPD_SERVICES=\)\(.*\)/\1"ldap:\/\/\/ ldaps:\/\/\/ ldapi:\/\/\/"/' /etc/default/slapd
sudo systemctl restart slapd

Gestionnaire utilisateur et service réseau : FusionDirectory

A moins d’être un pur défense de la ligne de commande, je vous propose d’utiliser un front end qui aura comme fonction de gérer les utilisateurs systèmes (créer, supprimer, modifier), la configuration dhcp, les zones dns, la configuration sudo, les attributs SSH des utilisateurs.

C’est une alternative à FreeIPA ou d’autre produit commerciaux.

Il repose sur PHP et un serveur web (par default Apache) et se marie très bien avec OpenLDAP.

Son installation va ramener toutes les dépendances dont il a besoin. L’architecture de FusionDirectory repose entièrement sur un annuaire ldap. Toutes sa configuration est portée par l’annuaire hormis les déclarations d’accès à ce même annuaire.

Tout installation les modules (ou plugin) et core repose à l’installation des fichiers php et l’inclusion des schémas dans l’annuaire.

installation du noyau FusionDirectory

Comme évoquer précédemment, l’installation de celui-ci nécessite l’utilisation du gestionnaire de package et de l’utilitaire d’insertion de schéma propre à fusiondirectory.

sudo apt-get install fusiondirectory fusiondirectory-schema

#insertion du schema fusiondirectory
sudo fusiondirectory-insert-schema

sécurisation de flux http

Comme l’annuaire va servir à gérer les utilisateurs systèmes. Les flux réseaux comportent des données sensibles. Nous allons activé TLS sur le serveur Apache en réutilisant le certificat utilisé pour OpenLDAP; le FQDN est le même.

Il faut activer le module ssl et le site ssl par défaut. Copier les certifcats aux bon endroits.

Après cela un redémarrage du serveur Apache est nécessaire.

root@annuaire:/etc/apache2# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  systemctl restart apache2
root@annuaire:/etc/apache2# a2ensite default-ssl
...
root@annuaire:/etc/apache2# cp /etc/ssl/openldap/annuaire.lab.ezydata.fr.* /etc/ssl/apache/
root@annuaire:/etc/apache2# chown -R www-data: /etc/ssl/apache
root@annuaire:~# grep -vE '^#|^ *$|^[[:space:]]*#' /etc/apache2/sites-enabled/default-ssl.conf 
<IfModule mod_ssl.c>
	<VirtualHost _default_:443>
		ServerAdmin webmaster@ezydata.fr
                ServerName annuaire.lab.ezydata.fr
		DocumentRoot /var/www/html
		ErrorLog ${APACHE_LOG_DIR}/error.log
		CustomLog ${APACHE_LOG_DIR}/access.log combined
		SSLEngine on
                SSLProtocol -all +TLSv1.2 +TLSv1.3
		SSLCertificateFile	/etc/ssl/apache/annuaire.lab.ezydata.fr.pem
		SSLCertificateKeyFile /etc/ssl/apache/annuaire.lab.ezydata.fr.key
		<FilesMatch "\.(cgi|shtml|phtml|php)$">
				SSLOptions +StdEnvVars
		</FilesMatch>
		<Directory /usr/lib/cgi-bin>
				SSLOptions +StdEnvVars
		</Directory>
	</VirtualHost>
</IfModule>

root@annuaire:/etc/apache2# systemctl restart apache2
root@annuaire:/etc/apache2# netstat -nap | grep apache
tcp6       0      0 :::80                   :::*                    LISTEN      17474/apache2
tcp6       0      0 :::443                  :::*                    LISTEN      17474/apache2

Base des utilisateurs système

L’objectif premier d’un annuaire d’entreprise est de gérer les utilisateurs systèmes. Aussi, ce chapitre aborde ce sujet  avec comme critère la simplicité et la périnité de la solution.

Il existe à l’heure actuelle deux façon d’intégrer un système linux avec une authentification via un annuaire :

– ldap/nss

– sssd

Malgré son lien fort avec FreeIPA, la solution sssd est la nouvelle génération d’outil client pour gérer les fournisseurs d’identité. Il a en autre une option d’intégration avec un annuaire Microsoft. Ce qui sera un bon candidat si dans votre entreprise vous avez ce fournisseur d’identité.

Notre choix se porte donc sur SSSD en tant que client système pour l’intégration aux fournisseurs d’identité LDAP.

root@annuaire:/etc/apache2# apt-get install sssd-ldap sssd-tools

De base, l’installation ne créer pas de fichier de configuration. Il est nécessaire d’en créer un à partir de rien. La documentation (man sssd.conf) contient toutes les informations importantes sur les directives globaux et celui de sssd-ldap plus particulièrement pour les fournisseurs de type annuaire.

Voici le fichier de configuration /etc/sssd/sssd.conf

[sssd]
services = nss, pam
config_file_version = 2
domains = ezydata

[nss]

[pam]

[domain/ezydata]
id_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=lab,dc=ezydata,dc=fr
auth_provider = ldap
cache_credentials = true

A ce stade, vous devez avoir les utilisateurs de l’annuaire présent dans la base système (command getent). Comme, nous n’avons pas encore créer d’utilisateur, c’est normal qu’il soit vide. Par défaut, à l’installation de sssd, le packageur Debian est inclus les directives dans les fichiers de configuration de nsswitch et pam.d les informations nécessaire à l’utilisation de sssd comme fournisseur d’identité.

Cependant, il manque encore l’automatisation de la création du répertoire home de l’utilisateur. En soit, c’est un choix qui s’appuie sur le retour d’expérience de grand déploiement qui héberge les homedirectory dans des points de montage. Dans notre cas, nous préférons un homedirectory local. Pour ce faire, il faut rajouter dans le fichier /etc/pam.d/common-session la directive

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

juste après pam_sss.so

Création du premier utilisateur

Avec l’interface graphique FusionDirectory, nous allons créer un utilisateur pour notre plateforme cloud.

Par la même occasion, nous allons créer une OU spéciale pour ce service que nous nommerons cloud.

Pour que l’utilisateur puisse avoir des attributs AccountPosix, il faut renseigner l’onglet Unix. FusionDirectory créera automatiquement le groupe associé à l’utilisateur.

Si tout se passe bien, vous pouvez voir l’utilisateur depuis votre serveur annuaire avec la commande suivante

id jph

Et vous pourrez alors, vous connecter avec ce même compte.

Sudo-ldap & clé SSH sur ldap

Avoir un annuaire pour gérer les utilisateurs c’est bien, mais aussi pouvoir y configurer certaines autorisations certralisées, c’est encore mieux.

Prenons le cas de sudo et des clés ssh. Il est fastidieux de créer ces configurations et à chaque fois de devoir le spécifier la clé ssh et la configuration sudo pour chaque nouveau serveur. Certains argueront qu’avec l’utilisation d’outil de configuration management tel puppet, chef et consort, il est facile d’arriver à ce même but. Cependant, tous les utilisateurs ne sont pas admin ni ont les compétences pour gérer ces outils. Aussi, avoir un outil graphique permet une adoption plus importante et donc une sécurité accrue.

Sudo-ldap

L’installation de sudo-ldap va désactiver le module sudo de votre système. Pour des raisons de perte d’acces, je vous conseille d’avoir un terminal connecter en tant que root en cas de problème.

Déploiement du module sudo et activation de celui dans fusiondirectory.

apt-get install fusiondirectory-plugin-sudo fusiondirectory-plugin-sudo-schema
fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/sudo*
L’installation de l’application sudo-ldap nécessite la désinstallation de sudo. Il faut renseigner dans les variables d’environnement SUDO_FORCE_REMOVE=yes. Sans cette instruction, l’installation échouera et vous demandera de le mettre pour confirmer le choix.
SUDO_FORCE_REMOVE=yes apt-get install sudo-ldap

Si tout s’est bien passé, le support ldap de sudo a été installé. Pour l’activer, deux points importans sont à vérifier:

– le fichier de configuration d’accès à l’annuaire renseigner avec la bonne uri;

– inclure une directive spéciale pour sudo-ldap.

Si on pousse la sécurité à l’extrème, des informations sensibles tel quel groupe à droit à faire quoi dans quel système, nous pouvons restreindre l’accès à l’ou suoders de l’annuaire qu’à un utilisateur spécifique ou un group spécifique. Cela sort du cadre de nos articles mais c’est une bonne pratique à considerer dans des environnements multi-tenants.

fichier /etc/sudo-ldap.conf

 

jph@annuaire:~$ cat /etc/ldap/ldap.conf 
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE	dc=lab,dc=ezydata,dc=fr
URI	ldap://localhost

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF		never

# TLS certificates (needed for GnuTLS)
TLS_CACERT	/etc/ssl/certs/ca-certificates.crt

# pour sudo
sudoers_base    ou=sudoers,ou=cloud,dc=lab,dc=ezydata,dc=fr
Si vous avez des problèmes, vous pouvez activer le mode débuggage dans le fichier de configuration /etc/sudo.conf avec les directives suivantes :
Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug

Création d’une règle sudo

Maintenant que les outils ont été configuré, nous allons créer une règle sudo depuis l’interface d’adminsitration de fusiondirectory.

La règle est la suivante : tous les utilisateurs du groupe sudo-ldap auront tous les droits sans avoir besoin de saisir son mot de passe.

création du group sudo-ldap

La règle sudo repose sur un group système or celui-ci n’est pas encore créer. Nous pouvons le faire à travers FusionDirectory. Attention à utiliser un groupposix comme source de group, sans quoi vous n’aurez pas les bons attributs.

clé SSH

Il est possible d’étendre les fonctionnalités d’openSSH pour rajouter d’autre méthode de fourniture de clé ssh. Cela se fait par la directive

AuthorizedKeysCommand

AuthorizedKeysCommandUser

Cette directive va permettre de rajouter d’autre source de clé public autorisé que celui par fichier. Le retour de la commande doit se faire par le STDOUT avec pour chaque ligne la clé publique ssh autorisé à se connecter à ce compte. En argument, ssh passe le nom de l’utilisateur.

La commande peut être écrite en n’importe quel langage pourvu qu’elle respecte ces conditions. Voici ce qui est fait dans notre infrastructure.

jph@annuaire:~$ cat /usr/local/bin/recupere_cle_ldap_ssh
#!/bin/sh
set -eu
log() {
	logger -s -t sshd -p "auth.$1" "$2"
}

uid="$1"

if ! expr "$uid" : '[a-zA-Z0-9._-]*$' 1>/dev/null; then
	log err "caractere interdit dans le nom d'utilisateur : $uid"
	exit 2
fi

keys=$(ldapsearch -x -LLL -o ldif-wrap=no "(&(uid=$uid)(sshPublicKey=*))" \
	'sshPublicKey' | sed -n 's/^sshPublicKey:\s*\(.*\)$/\1/p')

echo "$keys"

installation du module ssh dans fusiondirectory

Le daemon va effectuer dans l’ordre, une vérification locale et puis une vérification avec la directive keycommand. Pour renseigner ces attributs, nous allons installer le module ssh de fusiondirectory.

 

sudo apt-get install fusiondirectory-plugin-ssh \
 fusiondirectory-plugin-ssh-schema
sudo fusiondirectory-insert-schema /etc/ldap/schema/fusiondirectory/openssh-lpk.schema

Déclaration de clé ssh pour l’utilisateur

Chaque utilisateur peut désormais déclarer sa clé publique afin de se connecter sur les serveurs cloud sans rentrer de mot de passe. S’il fait partie de sudo, il peut aussi exécuter des commandes à la place de quelqu’un d’autre.

Fin de la partie 1/2

Dans cette article, nous avons déployer un annuaire centralisé pour l’identification des utilisateurs de notre cloud. Il permet d’avoir une gestion centralisée des comptes ainsi qu’une partie des autorisations.

La deuxième partie va s’intéresser à la gestion centraliser des systèmes :

DNS

DHCP

NTP