Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10 Configuration multi-sites avec redondance du coeur du réseau
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Migrer et installer une architecture
SAMBA/LDAP avec Ubuntu 10
Configuration multi-sites avec
redondance du coeur du réseau
Version 1.2 du 13/09/2012
Copyright (c) 2010, 2011, 2012 Éric Quinton.
Permission est accordée de copier, distribuer et/ou modifier ce document selon les termes de la
Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.1 ou toute
version ultérieure publiée par la Free Software Foundation ; sans section invariable. Une copie de
la présente Licence est incluse dans la section intitulée « Licence de Documentation Libre
GNU »
Rédaction : - 17/11/2010
Dernière modification : - 22/08/2011 - révision 77Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
Liste des modifications
Version Date Modifications apportées
1.0 Décembre 2010 Rédaction initiale
1.1 22/08/2011 Rajout de l'extraction du fichier slapd.conf depuis smbldap-tools
1.2 13 septembre 2012 Correction de la configuration des annuaire LDAP – rajout de consignes de
sécurité, traçage des blocages de mots de passe
2Table des matières
I. Introduction................................................................................................................................ 3
A. Les objectifs retenus........................................................................................................... 3
B. Le choix de la plate-forme................................................................................................... 4
C. Les différents serveurs déployés.........................................................................................4
D. Quelques remarques........................................................................................................... 4
E. Si vous souhaitez réaliser vous même une telle migration..................................................5
F. Documentation.................................................................................................................... 5
II. Avant de commencer................................................................................................................ 7
A. Récupérer les informations issues de la plate-forme à migrer............................................7
III. Installer Ubuntu........................................................................................................................ 9
A. Installation initiale................................................................................................................ 9
B. Installer le service ntp.......................................................................................................... 9
C. Configurer un sous-réseau de test......................................................................................9
D. Installer les paquets spécifiques nécessaires...................................................................10
IV. Gestion de la sécurité – mettre en place d'une couche TLS..................................................13
A. Documentation.................................................................................................................. 13
B. Rappel sur le cryptage SSL............................................................................................... 13
C. Les différents types de certificats......................................................................................14
D. Générer les certificats....................................................................................................... 14
E. Intégrer les certificats dans ldap........................................................................................ 16
F. Intégrer les certificats dans webmin..................................................................................16
G. Intégrer les certificats dans Apache..................................................................................16
H. Une alternative : stocker les clés privées et publiques à un seul endroit...........................17
I. Si vous avez besoin de générer plusieurs certificats..........................................................17
V. Configurer l'annuaire LDAP.................................................................................................... 19
A. Préambule......................................................................................................................... 19
B. Récupération du fichier LDIF contenant l'ensemble de l'annuaire.....................................19
C. Configuration de base....................................................................................................... 19
D. Configuration spécifique aux serveurs maîtres.................................................................22
E. Configuration spécifique des serveurs secondaires..........................................................24
F. Configurer ldap-account-manager - LAM..........................................................................24
G. En cas de problème avec un compte................................................................................26
H. Sécuriser l'annuaire LDAP................................................................................................ 27
I. Quelques commandes utiles pour manipuler un annuaire LDAP........................................29
VI. Configurer samba.................................................................................................................. 31
A. Configuration commune à tous les serveurs.....................................................................31
B. Configurer le fichier smb.conf pour les serveurs maîtres..................................................33
C. Configurer le fichier smb.conf pour les serveurs secondaires...........................................35
D. Configurer le fichier smb.conf pour des machines membres du domaine.........................37
E. Désactiver le démarrage automatique de samba..............................................................38
VII. Intégrer des machines dans le domaine...............................................................................39
A. Intégrer une machine Linux............................................................................................... 39
B. Intégrer une machine SEVEN........................................................................................... 39
VIII. Quelques tests... non exhaustifs......................................................................................... 41
IX. Sauvegarde des serveurs...................................................................................................... 43
A. Création d'un script de sauvegarde...................................................................................43
B. Préparer la recopie des données......................................................................................44
C. Recopier les données....................................................................................................... 44
X. Outils complémentaires.......................................................................................................... 45
A. Messagerie système......................................................................................................... 45
B. Superviser le serveur avec Nagios et NRPE.....................................................................45
C. Installer le client OCS-NG................................................................................................. 45
D. Installer webmin................................................................................................................ 46
XI. Récapitulatif des opérations à effectuer................................................................................47
A. Opérations sur les serveurs du nouveau domaine............................................................47
B. Opérations connexes dans les autres serveurs par site....................................................49
XII. Que faire en cas d'incident ?................................................................................................ 51Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
I. Licence de Documentation Libre GNU (GNU Free Documentation License)..........................53
2Configuration multi-sites avec redondance du coeur du réseau
I. Introduction
La DRAAF Aquitaine fonctionne avec une architecture Samba/Ldap depuis plusieurs
années, qui a été configurée initialement avec la distribution Mandriva Corporate Server
3, puis complétée avec des serveurs en Mandriva Corporate Server 4.
Cette structure administrative est répartie sur plusieurs sites. L'organisation mise en
place permet de s'affranchir, autant que faire se peut, de l'éclatement en plusieurs sites :
tout personnel peut s'identifier sur un micro (Windows essentiellement) avec son login,
quel que soit le site sur lequel il travaille.
L'architecture mise en place donne satisfaction. Néanmoins, l'arrivée de Windows 7
nous oblige à revoir complètement notre architecture, les versions de Samba disponibles
pour les serveurs actuels étant trop anciennes pour supporter l'identification des
nouvelles stations installées avec Windows 7.
La refonte de l'architecture est l'occasion de redéfinir un certain nombre d'objectifs :
A. Les objectifs retenus
1. Redondance du cœur de réseau
L'architecture doit permettre un fonctionnement sans interruption perceptible, si :
– un serveur maître s'arrête
– la connexion au réseau étendu d'un site, y compris du site principal, se rompt.
De plus, si un site voit sa connexion au réseau étendu tomber, les utilisateurs doivent
pouvoir continuer à travailler localement. Simplement, certaines opérations, comme la
modification du mot de passe de session, peuvent être interrompues (tolérance
acceptée).
Pour arriver à cette redondance, deux serveurs maîtres samba/ldap vont être installés,
dans deux sites distincts. Ils disposeront chacun d'une base LDAP, qui se synchronisera
en mode miroir.
Dans chaque site, un serveur secondaire va être installé. Il aura pour rôle :
– d'assurer l'identification locale des personnels ;
– fournir un annuaire ldap local utilisé par les serveurs ou matériels locaux
(serveurs bureautiques et photocopieurs principalement).
2. Sécurisation des échanges
Les communications entre les serveurs fonctionneront en mode crypté, via le protocole
SSL.
3. Rapidité de mise en œuvre
Avec les serveurs récents, les performances ne justifient plus d'installer une machine
physique par fonction.
Les serveurs déployés dans le cadre de ce projet sont virtualisés. Le choix a été fait de
les déployer sous Vmware Server, en raison de la simplicité d'installation et de gestion.
Deux types de serveurs sont donc déployés :
– les serveur maîtres, dont les configurations sont identiques à quelques détails
près ;
– les serveurs secondaires, tous identiques, hormis leur nom, leur certificat de
cryptage, et bien évidemment, leur adresse réseau. Ils sont construits à partir
d'une image unique.
3Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
B. Le choix de la plate-forme
Nous avons décidé de déployer notre projet en utilisant Ubuntu 10.04 Server. Le choix
n'a pas été simple, mais il a été fait en raison des points suivants :
– Ubuntu s'engage à fournir les mises à jour de sécurité et de correction de bogues
pour 5 ans
– La version Samba fournie est directement compatible avec Windows Seven (ce
n'est pas le cas avec d'autres distributions)
– Debian Lenny ne dispose pas nativement d'une version samba suffisamment
récente : il faut utiliser les dépôts backport. Néanmoins, des problèmes
techniques lors de l'intégration des machines dans le domaine nous ont fait
abandonner les tests sous cet OS
– RedHat est payant... Idem pour Mandriva Server
– et puis, on ne peut pas tout tester !
C. Les différents serveurs déployés
En tout, 3 types de serveurs vont être déployés :
– le serveur maître principal, qui va être utilisé pour réaliser les mises à jour
manuelles de l'annuaire LDAP, et servira de serveur Wins principal. Dans notre
document, il s'agit de GIRONDETEST2
– Le serveur maître secondaire, en mode miroir du serveur maitre principal. Il
prendra le relais en cas de panne ou d'indisponibilité du serveur maitre principal.
Dans notre document, il s'agit de GIRONDETEST3
– Des serveurs secondaires, tous configurés de la même façon. Ils sont bâtis à
partir de l'image du serveur SVGIRSEC
D. Quelques remarques
1. Ce document, une fiche de procédure (how to), un cours ?
Un peu tout ça, mais...
Si vous trouverez un certain nombre d'explications dans ce document,, n'hésitez-pas à
prendre du temps pour comprendre le fonctionnement intrinsèque des différents services
déployés en recherchant sur le net des explications plus complètes.
J'ai essayé de décrire toutes les opérations pour réaliser l'opération. Ce qui m'a pris
plusieurs semaines de travail (à temps partiel, tout de même), avec des essais, des
échecs, des changements dans l'approche générale... Tout est retranscrit ici. Néanmoins,
il est fort probable que j'ai omis certains aspects...
Vos remarques, commentaires, suggestions... seront les bienvenues.
2. Comment a été réalisé ce document ?
Ce document a été élaboré pendant la réalisation de la plate-forme de test. Les deux
serveurs maîtres ont ensuite été déployés en production, le serveur secondaire a été
utilisé pour créer les images des autres serveurs.
Le document est diffusé et corrigé après la mise en production effective : il ne s'agit
donc pas (que) d'une plate-forme de test ou d'un exercice !
3. La plate-forme de test
Elle a été élaborée en créant un sous-réseau spécifique, pour éviter que les
identifications Windows se télescopent avec la base en production.
L'annuaire de test a été créé à partir d'une extraction de l'annuaire en production.
4Configuration multi-sites avec redondance du coeur du réseau
Les tests ont été réalisés principalement par le rédacteur du document, mais pas que...
Merci aux collègues qui y ont participé ou ont assumé les tâches ingrates quotidiennes
pendant que je faisais « joujou »...
4. Les conventions de nommage utilisées
Le document est basé sur la migration d'une configuration réelle, dont voici les
informations essentielles :
– nom du domaine : GIRONDE
– base de recherche de l'annuaire LDAP : ou=agriculture,o=gouv,c=fr
Il va de soi que les informations plus précises (SID du domaine, mots de passe...) ont été
maquillées.
E. Si vous souhaitez réaliser vous même une telle migration...
Un seul conseil : montez une plate-forme de test ! Ce n'est pas parce que ce document a
été réalisé lors de la mise en place d'une migration réelle que certaines coquilles ne
puissent subsister ! Et puis, je ne suis pas un spécialiste de toutes les technologies
présentées...
Ne venez pas vous plaindre, après avoir migré votre plate-forme, que celle-ci présente
des dysfonctionnements, si vous n'avez pas réalisé les tests adéquats ! Vous êtes
prévenus !
F. Documentation
La configuration a été mise au point à partir de l'excellent travail publié ici :
http://damstux.free.fr/wiki/index.php?title=PDC_Samba_LDAP pour ce qui concerne la
création du domaine samba,
http://www.zytrax.com/books/ldap/ch7 pour les aspects synchronisation LDAP, ainsi que la
doc officielle Openldap : http://www.openldap.org/doc/admin24/replication.html
N'hésitez-pas non plus à consulter les documentations Apache, Samba (la doc
concernant le fichier smb.conf est particulièrement riche).
5Configuration multi-sites avec redondance du coeur du réseau
II. Avant de commencer
A. Récupérer les informations issues de la plate-forme à migrer
Un certain nombre d'informations, issues de l'annuaire LDAP à migrer, sont à consigner
avant de commencer. Vous pouvez toutes les consulter depuis l'interface du logiciel
ldap-account-manager (si vous l'utilisez), dans la vue arborescence. Voici les
informations à noter :
– la racine de l'annuaire (ou=agriculture,o=gouv,c=fr)
– la racine des groupes (ou=group)
– la racine des machines (ou=hosts)
– la racine des comptes utilisateurs (ou=people)
– le SID du domaine (sambaDomainName=NomDomaine, attribut : sambaSID
– le mot de passe du compte Manager, qui est utilisé pour gérer l'annuaire. Ca,
vous devez le connaître...
7Configuration multi-sites avec redondance du coeur du réseau
III. Installer Ubuntu
A. Installation initiale
L'installation est réalisée de façon classique, depuis une image ISO. Taille de la partition
unique : 8 Go.
Pour pouvoir traverser le serveur Proxy, les sources de la distribution
(/etc/apt/sources.list) sont modifiées en changeant les http en ftp. Voici un exemple :
cat /etc/apt/sources.list|grep ^[^#]
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid main restricted
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid main restricted
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid universe
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid universe
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid multiverse
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid multiverse
deb ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb-src ftp://fr.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb ftp://security.ubuntu.com/ubuntu lucid-security main restricted
deb-src ftp://security.ubuntu.com/ubuntu lucid-security main restricted
deb ftp://security.ubuntu.com/ubuntu lucid-security universe
deb-src ftp://security.ubuntu.com/ubuntu lucid-security universe
deb ftp://security.ubuntu.com/ubuntu lucid-security multiverse
deb-src ftp://security.ubuntu.com/ubuntu lucid-security multiverse
Après l'installation, faites une mise à jour :
apt-get update
apt-get upgrade
puis installez les paquets complémentaires suivants :
sysv-rc-conf
nscd
B. Installer le service ntp
La synchronisation entre les serveurs impose que ceux-ci disposent de la même heure.
Nous allons installer le service ntp :
apt-get install ntp
Editez ensuite le fichier /etc/ntp.conf, et vérifiez la ligne server, qui doit correspondre à
votre serveur de temps (il peut y en avoir plusieurs, une ligne par serveur).
Mettez manuellement à l'heure votre machine :
service ntp stop
ntpdate monServeurDeTemps
service ntp start
C. Configurer un sous-réseau de test
Avant de mettre en production, il est important de tester que tout fonctionne
correctement. Comme le domaine à migrer a le même nom et les mêmes identifiants
SID, il faut impérativement cloisonner les tests dans un sous-réseau non visible du
réseau en production.
9Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
La solution la plus simple consiste à créer une interface réseau secondaire sur le serveur,
et limiter le fonctionnement de Samba à cette interface.
Pour activer ce sous-réseau, éditez le fichier /etc/network/interfaces :
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 10.33.33.20
netmask 255.255.248.0
gateway 10.33.32.1
auto eth0:0
iface eth0:0 inet static
address 192.168.1.1
netmask 255.255.255.0
Le cas échéant, vérifier que ce n'est pas eth1 qui est reconnu : si c'est le cas, adaptez en
conséquence...
Pour visualiser les interfaces réseau reconnues dans votre machine :
ifconfig -a
Pour activer directement l'interface eth0:0 :
ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0
Nous avons ainsi défini une nouvelle adresse réseau différente du réseau de production :
192.168.1.1. Samba sera configuré pour utiliser uniquement cette adresse, et donc ce
sous-réseau.
D. Installer les paquets spécifiques nécessaires
1. Pour tous les serveurs
apt-get install samba smbclient samba-doc smbldap-tools winbind
apt-get install slapd ldap-utils libnss-ldap ssl-cert
Arrêter immédiatement les services qui ont pu se lancer automatiquement :
service samba stop
service winbind stop
service slapd stop
Supprimez le démarrage automatique de winbind (nous n'avons pas besoin que le
service fonctionne)1, à partir de l'interface :
sysv-rc-conf
2. Pour les serveurs maîtres
Nous devons installer Apache pour faire fonctionner Ldap Account Manager :
apt-get install apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-
common libapache2-mod-php5 php5-ldap
1 Winbind est utilisé pour faire la correspondance entre les identifiants des comptes Windows et les comptes Linux.
Dans une architecture répartie, il est fortement conseillé que les identifiants des comptes soient identiques sur tous
les serveurs, ce que ne permet winbind qu'à condition de le configurer pour qu'il stocke les identifiants dans un
annuaire ldap... Comme nous disposons déjà d'un annuaire ldap, il semble plus cohérent de se passer de winbind
et de travailler directement à partir de notre annuaire d'identification.
Par contre, il faut quand même installer le paquet winbind qui contient des outils dont nous aurons besoin par la
suite.
10Configuration multi-sites avec redondance du coeur du réseau
11Configuration multi-sites avec redondance du coeur du réseau
IV. Gestion de la sécurité – mettre en place d'une couche
TLS
Pour éviter que le dialogue entre les serveurs LDAP puisse être capté, et notamment lors
des phases de changement de mot de passe, il est conseillé de crypter les échanges entre
le serveur maître et les serveurs esclaves.
Pour cela, nous allons mettre en place la couche TLS en utilisant OpenSSL.
A. Documentation
Quelques liens qui m'ont permis de mettre au point la configuration :
http://www-lor.int-evry.fr/~michel/LDAP/SASL/TLS-SSL.html
mais également sur la documentation officielle openldap :
http://www.openldap.org/doc/admin24/
Et sur le cryptage SSL :
http://www.commentcamarche.net/contents/crypto/certificat.php3
http://fr.wikipedia.org/wiki/X.509
http://fr.wikipedia.org/wiki/Certificat_électronique
http://fr.wikipedia.org/wiki/Cryptographie_asymétrique
http://www.frpki.org/index.php?/openssl_base.html
B. Rappel sur le cryptage SSL
Le cryptage SSL (remplacé depuis par TLS) est basé sur l'utilisation du cryptage
asymétrique. Le cryptage asymétrique est basé sur des théorèmes mathématiques qui
stipulent qu'il est impossible de factoriser le produit de deux nombres premiers, c'est à
dire de retrouver par le calcul la valeur des deux nombres premiers utilisés pour faire
une multiplication : seuls les essais successifs permettent d'obtenir le résultat. Plus les
nombres premiers utilisés sont grands, plus le calcul prend de temps...
Le cryptage asymétrique est basé sur deux clés : tout message codé avec une des deux
clés ne peut être déchiffré qu'avec l'autre. Ces clés sont générées ensemble.
Une des clés doit être impérativement conservée par son propriétaire : c'est la clé privée.
L'autre sera fournie à tous les correspondants qui la veulent : c'est la clé publique.
Deux types d'utilisations principales sont faites avec ces clés, la signature, et le cryptage.
Voici le mécanisme utilisé pour la signature :
– Jean veut signer un message. Il calcule une empreinte de son message, qu'il
crypte avec sa clé privée. Il envoie son message, l'empreinte cryptée et sa clé
publique à Paul.
– Paul décrypte l'empreinte avec la clé publique, puis vérifie que le message n'a
pas été modifié : il peut ainsi s'assurer que c'est bien Jean qui lui a envoyé.
Et, pour le cryptage :
– Paul veut envoyer un message crypté à Jean. Jean lui fournit au préalable sa clé
publique. Paul crypte alors le message avec la clé publique de Jean, puis le lui
transmet.
– Jean reçoit le message, et le décrypte avec sa clé privée : il est le seul à pouvoir
le décrypter, étant le seul à détenir la clé privée.
Ces échanges ne peuvent fonctionner que si Paul a une entière confiance dans la clé
publique de Jean, sinon n'importe qui peut se faire passer pour Jean... Pour cela, Jean va
demander à un tiers de confiance, appelé également « autorité de certification », de
13Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
valider sa clé publique. Le tiers de confiance (des sociétés qui jouent ce rôle, mais
également l'Etat français pour ses fonctionnaires) va signer la clé publique de Jean, en
en cryptant l'empreinte avec sa clé privée. Ainsi, Paul pourra ainsi vérifier la clé
publique de Jean, en décryptant l'empreinte de celle-ci avec la clé publique du tiers de
confiance (en principe, présente dans tous les navigateurs commerciaux pour les grandes
sociétés de certification).
L'ensemble de ces mécanismes sont décrits dans une norme, la norme X.509.
Pour résumer :
– une clé privée, associée à une clé publique, est créée dans chaque machine. Elle
ne doit jamais être transmis à quiconque ;
– la clé publique est intégrée dans une demande de signature, envoyée à l'autorité
de certification ;
– L'autorité de certification crée le certificat à partir de la clé publique et des
informations transmises lors de la demande, puis calcule l'empreinte du
certificat, et crypte cette empreinte avec sa clé privée. Cette empreinte cryptée
est rajoutée au certificat, qui est transmis à l'ensemble des personnes ou
machines qui en ont besoin ;
– l'autorité de certification transmet sa clé publique (en général appelée CAkey),
qui va servir à décrypter la signature du certificat.
Nous avons donc besoin de quatre objets :
– la clé privée de l'autorité racine, qui va être utilisée pour signer les clés publiques
des serveurs ;
– le certificat de l'autorité de certification, qui contient la clé publique de l'autorité
racine, et qui va être utilisée pour décrypter les signatures des certificats ;
– la clé privée du serveur, qui est unique et conservée uniquement sur le serveur ;
– le certificat du serveur, qui comprend la clé publique, et qui est signé par
l'autorité racine.
C. Les différents types de certificats
Les clés publiques, privées, certificats sont fournis selon différents formats. Voici les
principaux :
– DER : Utilisé pour encoder des certificats X509 en notation ASN.1 Extensions
usuelles : .der, .cer, .crt, .cert
– PEM - Privacy Enhanced Mail. C'est du DER encodé en base64 auquel sont
ajoutées des en-têtes en ASCII. Extensions usuelles : .pem, .cer, .crt, .cert
– PKCS#12 - Personnal Information Exchange Syntax Standard. C'est un standard
pour stocker des clés privées, des clés publiques et des certificats en les
protégeant en général par mot de passe. Les données sont stockées en format
binaire. Extension : .p12, .pfx (pour Microsoft).
Les certificats personnels sont en format p12. Ils contiennent à la fois la clé privée et la
clé publique, et doivent donc être protégés avec un mot de passe.
D. Générer les certificats
Deux possibilités s'offrent à nous : soit nous signons nous-mêmes nos clés publiques,
soit nous faisons appel à une autorité de certification pour réaliser cette signature.
Pour commencer, nous allons signer nous-mêmes nos clés publiques. C'est la seule
solution si vous n'avez pas accès à une autorité de certification.
1. Créer le certificat racine
Créons la clé privée de l'autorité de certification racine :
openssl req -new -x509 -keyout cacert.pem -out cacert.pem -days 3650
14Configuration multi-sites avec redondance du coeur du réseau
Lors de la procédure, le programme demande un mot de passe : c'est celui qui devra être
fourni à chaque demande de signature d'un certificat.
Nous allons maintenant générer le certificat de l'autorité de certification, qui va être
utilisé pour valider les certificats des serveurs ; ce certificat contient donc la clé
publique de l'autorité de certification :
openssl x509 -in cacert.pem -out cacert.crt
2. Créer la clé privée
Nous allons générer la clé privée du serveur :
openssl genrsa -out server.key 1024
Puis nous la protégeons pour éviter que quiconque, à part root ou les process autorisés,
puissent y accéder :
chmod 600 server.key
3. Créer la requête de certificat qui sera validée par l'autorité racine
A partir de la clé privée, nous allons préparer une requête qui sera transmise à l'autorité
de certification. Cette requête contient non seulement la clé publique, mais également un
certain nombre d'informations, dont le nom du serveur.
openssl req -new -key server.key -out server.csr
Une fois la commande lancée, un certain nombre de champs vont devoir être renseignés.
Les champs laissés à vide doivent comporter un point (.).
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MA SOCIETE
Organizational Unit Name (eg, section) []: .
Common Name (eg, YOUR name) []:girondetest2
Email Address []: .
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Les deux derniers champs sont laissés à vide.
Attention : le Common Name doit impérativement correspondre au nom du serveur qui
va être utilisé dans les requêtes. Si vous utilisez un serveur DNS, vous devrez donner le
nom complet. Sinon, indiquez uniquement le nom de la machine (et renseignez, sur les
clients, le fichier hosts pour faire la correspondance). De nombreux soucis de
fonctionnement de la couche TLS sont liés à une gestion des noms erronée...
4. Signer le certificat localement
Si vous n'utilisez pas les services d'une autorité d'enregistrement, vous devez générer
vous même le certificat :
openssl x509 -req -days 3650 -in server.csr -CA cacert.pem -out server.crt
Si vous avez un message d'erreur du type :
cacert.srl: No such file or directory
il faut rajouter l'option suivante : -CAcreateserial, qui va créer le fichier contenant le
numéro de série. La commande devient donc :
15Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
openssl x509 -req -in server.csr -CA cacert.pem -CAkey cacert.pem -out server.crt
-Cacreateserial
Ne lancez cette commande qu'une seule fois...
5. Faire signer le certificat par une autorité d'enregistrement
Si vous disposez d'une autorité de certification, envoyez le fichier qui vient d'être généré
(server.csr) pour recevoir, en retour, la clé publique. En général, les champs
Organization Name et Organizational unit name vous sont imposés : consultez votre
autorité de certification pour connaître les bonnes informations à fournir.
Il vous faut également récupérer le certificat racine (équivalent du cacert.crt, la clé
publique de l'autorité de certification) qui permettra de vérifier la validité du certificat
qui vous sera fourni par l'autorité de certification.
6. Quelques commandes pour consulter les clés et les certificats
Pour visualiser le contenu d'une clé privée :
openssl rsa -in server.key -text
Pour visualiser la clé publique associée :
openssl rsa -in server.key -pubout
Pour visualiser un certificat :
openssl x509 -in server.crt -text -noout
Pour vérifier la validité du certificat :
openssl verify -CAfile cacert.crt server.crt
E. Intégrer les certificats dans ldap
Recopiez la clé publique (server.crt), la clé privée (server.key) et le certificat racine
(cacert.crt) dans le dossier /etc/ldap/. Modifiez les droits pour que :
– openldap puisse accéder aux certificats ;
– la clé privée soit en mode 600.
Editez le fichier /etc/ldap/ldap.conf, et rajoutez la ligne (ou modifiez-là) :
TLS_CACERT /etc/ldap/cacert.crt
qui va permettre à tous les processus LDAP de vérifier les clés à partir du certificat
racine.
F. Intégrer les certificats dans webmin
Par défaut, webmin génère ses propres certificats. Il est possible de lui faire utiliser les
certificats que nous venons de générer.
Pour cela :
– connectez-vous à webmin (https://serveur:10000)
– Choisissez webmin > webmin Configuration
– choisissez SSL Encryption, puis positionnez-vous dans l'onglet SSL
Settings(l'onglet par défaut)
– Sélectionnez sur le serveur l'emplacement de votre clé privée, puis cochez
Certificate file : separate file, et indiquez l'emplacement de votre clé publique
– Validez : le nouveau certificat va être utilisé à la place de l'ancien.
G. Intégrer les certificats dans Apache
Pour que les accès à l'annuaire LDAP à partir de Ldap Account Manager soient
protégés, nous aurons besoin de basculer la liaison en mode SSL. Là aussi, nous
pouvons intégrer les certificats que nous venons de générer dans Apache.
16Configuration multi-sites avec redondance du coeur du réseau
Recopiez les certificats dans le dossier /etc/apache2, puis éditez le fichier
/etc/apache2/sites-available/default-ssl :
SSLCertificateFile /etc/apache2/server.crt
SSLCertificateKeyFile /etc/apache2/server.key
Activez le support ssl dans Apache :
a2enmod ssl
a2ensite default-ssl
Redémarrez ensuite le service apache :
service apache2 restart
H. Une alternative : stocker les clés privées et publiques à un seul
endroit
Les certificats sont utilisés par de nombreux processus, et leur emplacement décrit dans
de nombreux fichiers.
Plutôt que de recopier les certificats dans chaque dossier spécifique d'un service, il peut
être judicieux de les stocker à un seul endroit.
Pour cela, recopiez la clé primaire dans le dossier /etc/ssl/private, et donnez lui les
droits suivants :
chmod 640 /etc/ssl/private/server.key
chown root:ssl-cert /etc/ssl/private/server.key
Recopiez la clé publique et le certificat racine dans /etc/ssl/certs, et vérifiez que les
fichiers sont bien en mode 644.
Nous allons créer un lien vers la valeur de hachage du fichier cacert.crt (la clé racine) :
cd /etc/ssl/certs
ln -s cacert.crt `openssl x509 -hash -in cacert.crt -noout`.0
Ce lien va permettre de retrouver très rapidement la clé de l'autorité de certification pour
pouvoir vérifier la clé publique. L'empreinte est calculée à partir de la valeur Subject du
certificat, qui figure dans notre certificat public et dans le certificat de l'autorité de
certification.
Notre clé privée n'est accessible qu'au compte root et au groupe ssl-cert. Pour que le
service Ldap puisse accéder à cette clé, nous allons intégrer le compte openldap dans le
groupe ssl-cert :
usermod -a -G ssl-cert openldap
Il ne reste plus qu'à modifier les chemins vers les certificats, par exemple, dans le fichier
/etc/ldap/slapd.conf :
TLSCertificateFile /etc/ssl/certs/server.crt
TLSCertificateKeyFile /etc/ssl/private/server.key
TLSCACertificateFile /etc/ssl/certs/cacert.crt
I. Si vous avez besoin de générer plusieurs certificats
Il est fortement conseillé de n'avoir qu'un seul certificat racine : cela simplifie
grandement la configuration des clients.
De fait, l'étape de génération du certificat racine (paragraphe 1 Créer le certificat racine,
page 14) n'est à réaliser qu'une seule fois.
Sur les autres serveurs, après avoir généré la clé privée et la demande de clé publique, il
faut :
– recopier le fichier .csr (la demande de clé publique) sur le premier serveur
17Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
– générer le certificat à partir de ce fichier .csr sur ce serveur
– recopier le certificat généré (fichier .crt) sur le serveur pour lequel nous générons
une nouvelle clé.
Ainsi, le même certificat racine sera utilisé pour valider l'ensemble des certificats de
votre infrastructure.
18Configuration multi-sites avec redondance du coeur du réseau
V. Configurer l'annuaire LDAP
A. Préambule
Nous allons configurer notre annuaire LDAP en respectant quelques points :
– la configuration est décrite dans le fichier slapd.conf, et non pas dans le dossier
slapd.d, qui semble être la nouvelle méthode de configuration, depuis la version
2.4. Cette approche a l'avantage de la continuité par rapport aux anciennes
configurations, et est plus simple à mettre en place. Elle présente toutefois
l'inconvénient de nécessiter un redémarrage du service à chaque modification.
– La réplication vers les annuaires clients est réalisée par l'intermédiaire d'un
compte dédié à cet usage, ici cn=Replicator,ou=agriculture,o=gouv,c=fr. Le
mot de passe de ce compte est défini et doit être différent du mot de passe du
compte manager.
B. Récupération du fichier LDIF contenant l'ensemble de l'annuaire
Sur un des serveurs LDAP en production (de préférence en version CS4, que le serveur
soit maître ou non), lancez la commande suivante :
slapcat -l /root/prod.ldif
Recopiez ce fichier sur le serveur maître.
C. Configuration de base
Cette partie de la configuration est valable pour tous les serveurs LDAP.
1. Modifier les paramètres de lancement de openldap
Editez le fichier /etc/default/slapd, et modifiez les entrées suivantes :
SLAPD_CONF=/etc/ldap/slapd.conf
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldapi:/// ldaps:///"
2. Configurer le fichier slapd.conf
Supprimez (renommez) le dossier suivant :
mv /etc/ldap/slapd.d /etc/ldap/slapd.d.ori
a. Récupérer une version de base du fichier slapd.conf
Comme Openldap travaille maintenant à partir des informations intégrées dans le
dossier slapd.d, le fichier slapd.conf n'est plus installé par défaut. Nous allons donc le
récupérer (il figure dans le paquetage smbldap-tools) :
gunzip -c /usr/share/doc/smbldap-tools/examples/slapd.conf.gz > /etc/slapd.conf
b. Rajouter le schéma samba.schema
Il faut récupérer le schéma Samba pour l'intégrer dans l'annuaire LDAP :
gunzip -c /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz >
/etc/ldap/schema/samba.schema
c. Modifier le fichier slapd.conf
Nous allons d'abord crypter la clé utilisée pour le compte Manager. Pour cela, tapez la
commande suivante :
slappasswd -h {SSHA}
New password:
Re-enter new password:
19Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
{SSHA}Qhxxxxx
Tapez alors le mot de passe, puis récupérez la valeur fournie par le programme. Cette
clé va être insérée dans le fichier slapd.conf.
Editez le fichier /etc/ldap/slapd.conf (en gras, les modifications liée à l'implémentation)
:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
moduleload back_hdb
sizelimit 500
tool-threads 1
TLSCertificateFile /etc/ldap/server.crt
TLSCertificateKeyFile /etc/ldap/server.key
TLSCACertificateFile /etc/ldap/cacert.crt
backend hdb
database hdb
suffix "ou=agriculture,o=gouv,c=fr"
rootdn "cn=Manager,ou=agriculture,o=gouv,c=fr"
rootpw {SSHA}motDePasseCode
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
index sambaSID eq
index sambaDomainName eq
index sambaPrimaryGroupSID eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index uniqueMember eq
index sambaGroupType eq
index sambaSIDList eq
index displayName pres,sub,eq
index entryCSN eq
index entryUUID eq
lastmod on
checkpoint 512 30
access to
attrs=userPassword,shadowLastChange,sambaNTPassword,SambaLMPassword,
sambaPasswordHistory
by dn="cn=Manager,ou=agricuture,o=gouv,c=fr" write
by dn.base="cn=Replicator,ou=agriculture,o=gouv,c=fr" read
by anonymous auth
by self write
by * none
20Configuration multi-sites avec redondance du coeur du réseau
access to dn.base="" by * read
access to *
by dn="cn=Manager,ou=agriculture,o=gouv,c=fr" write
by dn.base="cn=Replicator,ou=agriculture,o=gouv,c=fr" read
by * read
limits dn.exact="cn=Replicator,ou=agriculture,o=gouv,c=fr"
time.soft=unlimited time.hard=unlimited size.soft=unlimited
size.hard=unlimited
Vérifiez les droits d'accès au fichier :
chmod 640 /etc/ldap/slapd.conf
chown openldap:openldap /etc/ldap/slapd.conf
d. Supprimer la base ldap existante
Au cas où, il faut supprimer toute trace d'enregistrements dans la base ldap pré-existante
:
cd /var/lib/ldap
rm -f *
3. Configurer Linux pour qu'il puisse utiliser les comptes Ldap
La couche NSSWITCH permet de rendre accessibles les comptes de l'annuaire LDAP
dans le serveur. Pour cela :
Editez le fichier /etc/nsswitch.conf1 :
passwd: compat ldap
group: compat ldap
shadow: compat
hosts: files dns wins
Editez le fichier /etc/ldap.conf :
base ou=agriculture,o=gouv,c=fr
uri ldaps:///girondetest2.agriculture.gouv.fr
ssl start_tls
ssl on
tls_checkpeer yes
tls_cacertfile /etc/ldap/cacert.crt
Pour vérifier que la couche NSS fonctionne, lancez les commandes :
getent passwd
getent group
qui doivent vous afficher d'abord les comptes de l'annuaire LDAP, puis les groupes.
Remarque : deux fichiers ldap.conf existent sur le système :
– le fichier /etc/ldap.conf est utilisé par la couche NSS pour gérer l'appariement
des comptes ldap avec les comptes linux
– le fichier /etc/ldap/ldap.conf est utilisé par toutes les commandes ldap, par
exemple ldapsearch.
Leur configuration (syntaxe) est différente, et leur usage aussi...
1 Attention : toute modification de nsswitch.conf peut entraîner de grands moments de solitude... En effet, si la
configuration est erronée, vous n'aurez plus la possibilité de vous connecter au serveur. Avant toute opération,
assurez-vous d'avoir au moins 2 consoles ouvertes en parallèle, une vous permettant de revenir à la configuration
initiale en cas de problème. Pensez également, le cas échéant, à faire une sauvegarde des fichiers de
configuration...
21Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
D. Configuration spécifique aux serveurs maîtres
1. Intégrer l'export du ldap CS3-CS4
Cette opération n'est à faire que sur un seul serveur, le serveur maître principal. Les
autres serveurs récupèreront l'annuaire automatiquement par l'intermédiaire de syncrepl.
Intégrons le fichier ldif généré précédemment. Pour cela :
cd /var/lib/ldap
rm -f *
slapadd -l /root/prod.ldif
chown -R openldap:openldap .
Pour vérifier que l'import s'est bien déroulé, vous pouvez lancer la commande :
ls -l
total 20716
-rw-r--r-- 1 openldap openldap 2048 oct 26 14:34 alock
-rw------- 1 openldap openldap 430080 oct 26 14:39 cn.bdb
-rw------- 1 openldap openldap 8192 oct 26 14:44 __db.001
-rw------- 1 openldap openldap 2629632 oct 26 14:44 __db.002
-rw------- 1 openldap openldap 98304 oct 26 14:39 __db.003
-rw------- 1 openldap openldap 565248 oct 26 14:44 __db.004
-rw------- 1 openldap openldap 24576 oct 26 14:39 __db.005
-rw-r--r-- 1 openldap openldap 96 oct 25 16:16 DB_CONFIG
-rw------- 1 openldap openldap 167936 oct 26 14:39 dn2id.bdb
-rw------- 1 openldap openldap 24576 oct 26 12:57 gidNumber.bdb
-rw------- 1 openldap openldap 114688 oct 26 11:17 givenName.bdb
-rw------- 1 openldap openldap 2326528 oct 26 14:39 id2entry.bdb
-rw------- 1 openldap openldap 10485749 oct 25 16:17 log.0000000001
-rw------- 1 openldap openldap 3682705 oct 26 14:39 log.0000000002
-rw------- 1 openldap openldap 249856 oct 26 11:17 mail.bdb
-rw------- 1 openldap openldap 28672 oct 26 11:56 memberUid.bdb
-rw------- 1 openldap openldap 131072 oct 26 14:39 objectClass.bdb
-rw------- 1 openldap openldap 40960 oct 26 14:38 sambaSID.bdb
-rw------- 1 openldap openldap 282624 oct 26 14:39 sn.bdb
-rw------- 1 openldap openldap 40960 oct 26 12:57 uid.bdb
-rw------- 1 openldap openldap 45056 oct 26 12:57 uidNumber.bdb
-rw------- 1 openldap openldap 8192 oct 26 11:56 uniqueMember.bdb
et visualiser que l'import s'est bien déroulé. Vérifiez également les droits sur le fichiers,
qui doivent être en mode 600 et détenus par le compte openldap.
Vous pouvez maintenant démarrer le serveur ldap, puis vérifier qu'il fonctionne bien :
/etc/init.d/slapd start
ps -ef|grep slapd
openldap 29195 1 0 14:34 ? 00:00:02 /usr/sbin/slapd -g openldap -u
openldap -f /etc/ldap/slapd.conf
Vérifiez que le service slapd répond bien en mode ldap et ldaps :
netstat -antu|grep 389
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:389 192.168.1.11:35324 ESTABLISHED
tcp6 0 0 :::389 :::* LISTEN
netstat -antu|grep 636
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN
tcp6 0 0 :::636 :::* LISTEN
Lancez la recherche en mode non crypté :
ldapsearch -x -b "ou=agriculture,o=gouv,c=fr" "(objectclass=*)" -H ldap://localhost
22Configuration multi-sites avec redondance du coeur du réseau
puis en mode crypté :
ldapsearch -x -b "ou=agriculture,o=gouv,c=fr" "(objectclass=*)" -H ldaps://localhost
Si, en mode crypté, la commande ne répond pas correctement, essayez avec le nom du
serveur (p. e., girondetest2) avant de vous affoler : le certificat que nous avons généré
l'est au nom du serveur et non pas localhost, et le certificat est vérifié en comparant le
nom présenté par rapport au nom du serveur interrogé...
Dans les deux cas, vous devez récupérer les 500 premiers enregistrements de l'annuaire.
2. Configuration de la réplication en mode miroir
Les deux serveurs maîtres vont fonctionner en mode miroir : toute modification
apportée à l'un des serveurs doit être répliquée sur le second.
Le fichier /etc/ldap/slapd.conf est modifié, en rajoutant les lignes suivantes :
Avant la ligne :
database hdb
Rajouter :
ServerID 2
Le ServerID doit être unique pour votre réseau ! Le serveur maître principal aura donc le
numéro 1, le maître secondaire le numéro 2.
Puis, en fin de fichier :
syncrepl rid=001
provider=ldaps://girondetest2
tls_cacert=/etc/ldap/cacert.crt
type=refreshAndPersist
retry="60 5 300 +"
searchbase="ou=agriculture,o=gouv,c=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=Replicator,ou=agriculture,o=gouv,c=fr"
credentials="motDePasseReplicator"
mirrormode true
moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Quelques explications :
– provider : le nom de l'autre serveur maître (identique à la valeur présente dans le
certificat numérique)
– tls_cacert : le chemin vers le certificat racine, qui va permettre de valider le
certificat présenté par le serveur distant. Ce paramètre n'est pas forcément
nécessaire ici, s'il a été renseigné dans le fichier /etc/ldap/ldap.conf
– type : refreshOnly : la mise à jour est réalisée à intervalle régulier (champ
interval à insérer). RefreshAndPersist : la connexion est maintenue avec le
serveur maître, les réplications sont réalisées au fil de l'eau. Le champ retry
permet de définir ce qu'il faut faire quand la connexion est rompue. Ici, un essai
toutes les 60 secondes pendant 5 fois, puis toutes les 300 secondes jusqu'à la
reprise de la connexion
– schemachecking : si à on, le programme vérifie avant la réplication que le
schéma répliqué depuis le maître existe bien sur l'esclave
23Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10
– binddn : le compte utilisé pour la réplication. Le mot de passe est défini en clair 1
dans le champ credentials.
– mirrormode : le paramètre doit impérativement être à true pour que le serveur
puisse réaliser des modifications.
Si vous ne disposez pas d'un serveur DNS, il est possible que vous soyez obligés de
modifier le fichier /etc/hosts, pour que le nom du serveur distant soit associé à son
adresse IP.
Faites la modification sur les deux serveurs. Relancez le serveur maître principal, puis
lancez le maître secondaire : si tout se passe bien, l'annuaire va être recopié.
Sur chaque serveur maitre, la commande suivante vous permet de vérifier que la
connexion syncrepl est bien active en mode ldaps :
netstat -antu|grep 636
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:636 192.168.1.11:46851 ESTABLISHED
E. Configuration spécifique des serveurs secondaires
Nous allons simplement rajouter les commandes permettant de récupérer les données
depuis les deux serveurs maîtres. Attention : ce n'est pas parce que les deux maîtres sont
en miroir qu'il ne faut pas configurer la synchronisation vers les deux maîtres : en effet,
un maître ne distribue que les modifications dont il est l'auteur.
Nous rajoutons donc en fin du fichier /etc/ldap/slapd.conf les commandes suivantes :
syncrepl rid=001
provider=ldaps://girondetest1.local.draf-aquitaine.agri
tls_cacert=/etc/ssl/certs/igca-racine-serveur.crt
type=refreshAndPersist
retry="60 5 300 +"
searchbase="ou=agriculture,o=gouv,c=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=Replicator,ou=agriculture,o=gouv,c=fr"
credentials="motdepasseReplicator"
syncrepl rid=002
provider=ldaps://girondetest2.local.draf-aquitaine.agri
tls_cacert=/etc/ldap/cacert.crt
type=refreshAndPersist
retry="60 5 300 +"
searchbase="ou=agriculture,o=gouv,c=fr"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=Replicator,ou=agriculture,o=gouv,c=fr"
credentials="motdepasseReplicator"
F. Configurer ldap-account-manager - LAM
Ldap-account-manager (LAM) est un outil préconisé par le projet SAMBA pour gérer
les comptes LDAP du domaine. Un paquetage DEB est fourni par Ubuntu, mais je vous
déconseille de l'utiliser, j'ai rencontré des problèmes dans son utilisation. De plus, la
version disponible sur le site est plus récente que celle fournie par Ubuntu.
1 Syncrepl ne supporte malheureusement pas le stockage crypté du mot de passe : vous ne pouvez pas utiliser la
syntaxe {SSH1}xxxx, le mot de passe doit rester en clair
24Vous pouvez aussi lire
