Objectif:
Nous allons décrire la mise en place d'une double authentification LDAP et PostgreSQL sous apache sur une distribution CentOS dans sa version 5. Les applications installées seront au format RPM
Nous utiliserons les modules apache LDAP et DBD pour gérer ce système.
Note:
Toute les recompilations sont effectuées sous un utilisateur différent de root.
Installation:
Par défaut la version 2.2.3 d'HTTPD de la distribution CentOS 5 n'est pas pleinement compatible avec le mod_dbd. Nous utiliserons une version 2.2.8 que nous aurons recompillée.
Recompilation httpd 2.2.8:
Récupération du binaire:
Nous utiliserons la recompillation du fichier SRPM de la distribution Fedora dans sa version 7. Ce fichier est disponible sur : ftp://mirror.switch.ch/mirror/fedora/linux/updates/7/SRPMS/httpd-2.2.8-1.fc7.src.rpm
Sur un serveur CentOS 5:
# wget ftp://mirror.switch.ch/mirror/fedora/linux/updates/7/SRPMS/httpd-2.2.8-1.fc7.src.rpm
Recompilation du binaire:
Il y a deux possibilités: reconstruire directement le rpm ou l'adapter à la distribution CentOS (images, index.html, etc)
Façon basique:
# rpmbuild –rebuild httpd-2.2.8-1.fc7.src.rpm
Il faudra certainement satisfaire les dépendances pour la reconstruction
En l'adaptant à CentOS:
# rpm -Uvh httpd-2.2.8-1.fc7.src.rpm
# cd /usr/src/redhat/SPECS/
On édite le fichier httpd.spec et on remplace les champs Fedora par CentOS
# cd /usr/src/redhat/BUILD/
On remplace les fichiers powered_by_fedora.png par le fichier powered_by_rh.png et on remplace le fichier index.html par le fichier /var/www/error/noindex.html d'un CentOS classique.
# cd /usr/src/redhat/SPECS/
# rpmbuild -ba httpd.spec
Dans les deux cas nous obtenons 4 RPMS dans le répertoire /usr/src/redhat/RPMS/i386/:
httpd-2.2.8-1.i386.rpm
httpd-manual-2.2.8-1.i386.rpm
httpd-devel-2.2.8-1.i386.rpm
mod_ssl-2.2.8-1.i386.rpm
Installation des binaires:
En tant que root, sur le serveur destiné à être le frontal web:
# yum -y install apr-util
# rpm -Uvh /usr/src/redhat/RPMS/i386/httpd-2.2.8-1.i386.rpm
# yum -y install distcache
# rpm -Uvh /usr/src/redhat/RPMS/i386/mod_ssl-2.2.8-1.i386.rpm
Configuration:
Postgres:
Nous configurons le serveur de la façon suivante:
1 base de donnée spécifique au service (nommée htpasswd)
1 table contenant 2 colonnes: usernom et usermdp par virtualhost
en tant que postgres:
# createdb -E latin1 htpasswd
# psql -d htpasswd < mod_dbd.sql
Le fichier mod_dbd.sql est en annexe du document.
Httpd:
Par défaut les modules mod_dbd et mod_authn_dbd ne sont pas chargé dans httpd
On edite le fichier httpd.conf:
# vi /etc/httpd/conf/httpd.conf
on ajoute les lignes suivantes au niveau de la section « LoadModule »
LoadModule authn_dbd_module modules/mod_authn_dbd.so
LoadModule dbd_module modules/mod_dbd.so
A la fin du fichier nous précisons les directives mod_dbd:
# mod_dbd directives
DBDriver pgsql
DBDParams "dbname=htpasswd user=USER password=MDPUSER host=HOST.EXAMPLE.COM"
DBDMin 1
DBDKeep 2
DBDMax 10
DBDExptime 60
Nous créons un fichier httpd.virtualhost.conf dans le répertoire /etc/httpd/conf.d/
Ce fichier contiendra les déclarations de l'ensemble de nos VHOST
On édite le fichier:
# vi /etc/httpd/conf.d/httpd.virtualhost.conf
Et on ajoute la déclaration en s'inspirant de l'exemple en annexe
Conclusion:
Avec cette méthode nous pouvons déléguer une partie de l'authentification des partenaires aux développeur d'un projet. L'autre avantage est la centralisation des authentifications: nous interrogeons deux bases ce qui simplifie les reprises d'activités. Cette méthode nous ouvre une perspective simplifiée pour la mise en cluster de ce service Web avec une réplication simple des configurations.
ANNEXE:
mod_dbd.sql:
CREATE TABLE VHOST (
usernom character varying(128) NOT NULL,
usermdp character varying(128) NOT NULL
);
ALTER TABLE ONLY VHOST
ADD CONSTRAINT VHOST_pkey PRIMARY KEY (usernom);
Attention: VHOST doit être remplacé par le nom du virtualhost
exemple: pour le virtualhost devexample.com le fichier sera:
CREATE TABLE TOTO (
usernom character varying(128) NOT NULL,
usermdp character varying(128) NOT NULL
);
ALTER TABLE ONLY DEVEXAMPLE.COM
ADD CONSTRAINT DEVEXAMPLE.COM_pkey PRIMARY KEY (usernom);
httpd.virtualhost.conf:
ServerAdmin webmaster@example.com
ServerName www.example.com
ErrorLog /var/log/httpd/example.com/error_log
CustomLog /var/log/httpd/example.com/access_log combined
# On peut envoyer les logs sur un serveur de log via syslog
# CustomLog "| /usr/bin/logger -t 'example.comr' -p local3.info " combined
Redirect / https://devexample.com/
ProxyPass http://192.168.10.1/
ProxyPassReverse http://192.168.10.1/
ServerAdmin webmaster@example.com
ServerName www.example.com
ErrorLog /var/log/httpd/www.example.com/error_log
CustomLog /var/log/httpd/www.example.com/access_log combined
# On peut envoyer les logs sur un serveur de log via syslog
# CustomLog "| /usr/bin/logger -t 'www.example.com' -p local3.info " combined
SSLEngine on
SSLProxyEngine On
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
ProxyPass http://192.168.10.1/
ProxyPassReverse http://192.168.10.1/
AuthName "ACCES EXAMPLE.COM"
AuthType Basic
order allow,deny
deny from all
# Nous precisons la double authentification
AuthBasicProvider ldap dbd
# LDAP n'est pas la seule source d'authentification
AuthzLDAPAuthoritative off
# Nous authentifion 2 categories: les admin (service unique) et les membres du projet
AuthLDAPUrl "ldaps://ldap1.example.com/ou=People,dc=example,dc=com?uid??|(&(etat=actif)(allowedService=web-admin))(&(etat=actif)(allowedService=web-dev))"
AuthLDAPUrl "ldaps://ldap2.example.com/ou=People,dc=example,dc=com?uid??|(&(etat=actif)(allowedService=web-admin))(&(etat=actif)(allowedService=web-dev))"
# Nous authentifions sur la base postgres pour le vhost devppeao sur sa table correspondante
AuthDBDUserPWQuery "SELECT usermdp FROM devppeao WHERE usernom= %s"
# Nous retenons les utilisateurs repondant a nos criteres
Require valid-user
# Les deux methodes sont satisfaisantes
Satisfy any