Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10 CONFIGURATION MULTI-SITES AVEC REDONDANCE DU COEUR DU RESEAU ERIC QUINTON

Transcription

1 2013 Migrer et installer une architecture SAMBA/LDAP avec Ubuntu 10 CONFIGURATION MULTI-SITES AVEC REDONDANCE DU COEUR DU RESEAU ERIC QUINTON Copyright (c) 2010 Eric 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» Par respect pour le rédacteur initial, et en accord avec les termes de la licence GNU, j ai repris ce document, dont j ai juste modifié la mise en page propre au site.

2 Table des matières Signalétique Introduction Avant de commencer Installation de Ubuntu Gestion de la sécurité mise en place d'une couche TLS Configurer l'annuaire LDAP Configuration de samba Intégrer des machines dans le domaine Quelques tests... non exhaustifs Sauvegarde des serveurs Outils complémentaires Récapitulatif des opérations à effectuer Que faire en cas d'incident? I. Licence de Documentation Libre GNU (GNU Free Documentation License) E. Quinton & D. Olivier 2

3 Signalétique Commande UNIX # /tomcat5.5/bin/startup.sh Chemin de fichier, dossier, emplacement sur le disque Fichier web.xml Exemple de contenu de document <Host name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" /> Autre contenu de fichier : <role rolename="ruserhelloworld"/> E. Quinton & D. Olivier 3

4 1 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 : 1.1 Les objectifs retenus 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). Sécurisation des échanges Les communications entre les serveurs fonctionneront en mode crypté, via le protocole SSL. 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 serveurs 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. E. Quinton & D. Olivier 4

5 1.2 Le choix de la plate-forme Nous avons décidé de déployer notre projet en utilisant Ubuntu 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 Sept (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! 1.3 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 1.4 Quelques remarques 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 passé omis certains aspects... Vos remarques, commentaires, suggestions... seront les bienvenues. 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! 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. E. Quinton & D. Olivier 5

6 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. 1.5 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 : il est possible, voire probable, que vous arriviez à faire mieux... 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! 1.6 Documentation La configuration a été mise au point à partir de l'excellent travail publié ici : pour ce qui concerne la création du domaine samba, pour les aspects synchronisation LDAP, ainsi que la doc officielle Openldap : N'hésitez-pas non plus à consulter les documentations Apache, Samba (la doc concernant le fichier smb.conf est particulièrement riche). 2 Avant de commencer 2.1 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... E. Quinton & D. Olivier 6

7 3 Installation de Ubuntu 3.1 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 3.2 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 E. Quinton & D. Olivier 7

8 3.3 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. 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 netmask gateway auto eth0:0 iface eth0:0 inet static address netmask 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: netmask Nous avons ainsi défini une nouvelle adresse réseau différente du réseau de production : Samba sera configuré pour utiliser uniquement cette adresse, et donc ce sous-réseau. 3.4 Installation des paquets spécifiques nécessaires 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 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. E. Quinton & D. Olivier 8

9 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 4 Gestion de la sécurité mise 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. 4.1 Documentation Quelques liens qui m'ont permis de mettre au point la configuration : mais également sur la documentation officielle openldap : Et sur le cryptage SSL : Rappel sur le cryptage SSL Le cryptage SSL (remplacé depuis par TLS) est basé sur l'utilisation du cryptage asymétrique. Son principe est le suivant. Deux clés sont générées. Un message crypté avec une des deux clés peut être déchiffré avec l'autre. Il suffit de transmettre une des deux clés à son correspondant pour que celui-ci puisse, non seulement décrypter le message que nous venons de lui envoyer, mais également crypter un message que nous pourrons décrypter. Dans la pratique, une seule des deux clés est transmise à l'ensemble des correspondants, la clé publique. L'autre clé est conservée précieusement et ne doit jamais être transmise, la clé privée. Dans un échange, il est important de pouvoir s'assurer que le correspondant est bien celui qu'il dit être. Pour cela, la clé publique est signée par une autorité reconnue, en qui on peut faire confiance : le tiers de confiance. La clé publique est ainsi transmise à l'intérieur d'un certificat, qui contient non seulement la clé publique, mais également le nom du serveur à laquelle elle se réfère (pour une clé correspondant à un serveur), le nom de l'autorité qui a signé le certificat et la signature du certificat. La signature du certificat fonctionne ainsi : l'ensemble des informations du certificat est haché (compressé en une empreinte unique). Cette empreinte est cryptée avec la clé privée du certificateur, et est ensuite rajoutée dans le certificat. Pour s'assurer de la validité de la clé publique, il faut donc extraire l'empreinte cryptée, la déchiffrer avec la clé publique du certificateur, puis la comparer avec l'empreinte que nous pouvons calculer. E. Quinton & D. Olivier 9

10 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 sur 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. 4.3 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 ne disposez pas d'une autorité de certification. 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 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 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 E. Quinton & D. Olivier 10

11 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 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... 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 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 : # openssl x509 -req -in server.csr -CA cacert.pem -CAkey cacert.pem -out server.crt - Cacreateserial Ne lancez cette commande qu'une seule fois... 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. E. Quinton & D. Olivier 11

12 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 4.4 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. 4.5 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 ( 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. 4.6 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. Recopiez les certificats dans le dossier /etc/apache2, puis éditez le fichier /etc/apache2/sitesavailable/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 E. Quinton & D. Olivier 12

13 4.7 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 4.8 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 10) 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 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. E. Quinton & D. Olivier 13

14 5 Configurer l'annuaire LDAP 5.1 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. 5.2 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. 5.3 Configuration de base Cette partie de la configuration est valable pour tous les serveurs LDAP. 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:// :389/ ldapi:/// ldaps:///" Configurer le fichier slapd.conf Supprimez (renommez) le dossier suivant : # mv /etc/ldap/slapd.d /etc/ldap/slapd.d.ori 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 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: {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. E. Quinton & D. Olivier 14

15 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 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectclass,entrycsn,entryuuid eq index sambasid eq index sambadomainname eq index sambaprimarygroupsid eq index cn,sn,uid pres,sub,eq index uidnumber,gidnumber,memberuid pres,eq index uniquemember eq index sambagrouptype eq index sambasidlist eq lastmod on checkpoint access to attrs=userpassword,shadowlastchange by dn="cn=manager,ou=agricuture,o=gouv,c=fr" write by anonymous auth by self write by * none 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" write 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 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 * 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 : E. Quinton & D. Olivier 15

16 Editez le fichier /etc/nsswitch.conf 1 : passwd: group: shadow: hosts: compat ldap compat ldap compat 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... E. Quinton & D. Olivier 16

17 5.4 Configuration spécifique aux serveurs maîtres 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 rw-r--r-- 1 openldap openldap 2048 oct 26 14:34 alock -rw openldap openldap oct 26 14:39 cn.bdb -rw openldap openldap 8192 oct 26 14:44 db.001 -rw openldap openldap oct 26 14:44 db.002 -rw openldap openldap oct 26 14:39 db.003 -rw openldap openldap oct 26 14:44 db.004 -rw openldap openldap oct 26 14:39 db.005 -rw-r--r-- 1 openldap openldap 96 oct 25 16:16 DB_CONFIG -rw openldap openldap oct 26 14:39 dn2id.bdb -rw openldap openldap oct 26 12:57 gidnumber.bdb -rw openldap openldap oct 26 11:17 givenname.bdb -rw openldap openldap oct 26 14:39 id2entry.bdb -rw openldap openldap oct 25 16:17 log rw openldap openldap oct 26 14:39 log rw openldap openldap oct 26 11:17 mail.bdb -rw openldap openldap oct 26 11:56 memberuid.bdb -rw openldap openldap oct 26 14:39 objectclass.bdb -rw openldap openldap oct 26 14:38 sambasid.bdb -rw openldap openldap oct 26 14:39 sn.bdb -rw openldap openldap oct 26 12:57 uid.bdb -rw openldap openldap oct 26 12:57 uidnumber.bdb -rw 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 les 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 :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 : :* LISTEN tcp : :35324 ESTABLISHED tcp6 0 0 :::389 :::* LISTEN # netstat -antu grep 636 tcp : :* 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 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 E. Quinton & D. Olivier 17

18 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. 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 Rajouter : hdb ServerID 2 Le ServerID doit être unique pour votre réseau! Le serveur maitre principal aura donc le numéro 1, le maitre 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=" " 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 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 binddn : le compte utilisé pour la réplication. Le mot de passe est défini en clair 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é. E. Quinton & D. Olivier 18

19 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 : :* LISTEN tcp : :46851 ESTABLISHED 5.5 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=" " 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=" " searchbase="ou=agriculture,o=gouv,c=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=replicator,ou=agriculture,o=gouv,c=fr" credentials="motdepassereplicator" 5.6 Quelques commandes utiles pour manipuler un annuaire LDAP... Afficher un enregistrement # ldapsearch -x -b "ou=agriculture,o=gouv,c=fr" "(uid=test4)" -H ldaps://girondetest2 Modifier un enregistrement créez un fichier modif.ldif : dn: uid=test3,ou=people,ou=agriculture,o=gouv,c=fr changetype: modify replace: givenname givenname: tito Lancez ensuite la commande : # ldapmodify -f /root/modif.ldif -D cn=manager,ou=agriculture,o=gouv,c=fr -W Le programme demandera le mot de passe manager (option -W), puis réalisera l'opération. Ces deux commandes sont très utiles pour vérifier que les synchronisations/réplications fonctionnent correctement... N'hésitez pas à tester dans tous les sens. E. Quinton & D. Olivier 19

20 Supprimer un enregistrement # ldapdelete "cn=domain Users,ou=group,ou=agriculture,o=gouv,c=fr" -H ldap://localhost -D cn=manager,ou=agriculture,o=gouv,c=fr -W Cette commande va supprimer l'enregistrement «Domain Users» dans la branche group. 5.7 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. Récupérer et installer LAM Depuis le site téléchargez le fichier tar.gz (source code). Décompressez-le dans le dossier /var/www/ Créez ensuite un lien symbolique : # cd /var/www/ # ln -s ldap-account-manager-3.2.0/ lam Modifiez ensuite les droits : # chmod -R o-r,o-w,o-x dap-account-manager # chown -R www-data dap-account-manager Dans un navigateur, testez le fonctionnement : Vous devez arriver à la page de login. Activer le mode SSL pour l'accès à LAM Nous allons rediriger tout le trafic web vers le mode SSL, pour que les modifications, et notamment de mot de passe, ne puissent être captées. Il existe de nombreuses méthodes. Voici celle qui permet de rediriger tout le trafic web en mode SSL. Vérifiez que vous avez bien intégré les certificats Apache, comme décrit dans le paragraphe F Intégrer les certificats dans Apache, page 12. Modifiez le fichier /etc/apache2/sites-available/default, et rajoutez les lignes suivantes dans la section <VirtualHost> : RewriteEngine on RewriteCond %{SERVER_PORT} ^80$ RewriteRule ^(.*)$ [L,R] Redémarrez ou rechargez Apache pour que les nouveaux paramètres soient pris en compte : # service apache2 restart Maintenant, l'ensemble des flux http sera redirigé en https. Récupérer la configuration de LAM Depuis l'ancien serveur hébergeant LdapAccountManager, récupérez le fichier contenant la configuration de lam, dans le dossier lam/config (en principe, nom_du_domaine.conf). Recopiez-le dans le dossier config, et donnez-lui les droits : # chown www-data domaine.conf Récupérez également le fichier config.cfg. E. Quinton & D. Olivier 20

21 Vérifier la configuration du fichier domaine.conf Editez le fichier récupéré. Vérifiez au moins les informations suivantes : serverurl: ldap://localhost admins: cn=manager,ou=agriculture,o=gouv,c=fr passwd: {SSHA}mpcI9EM treesuffix: ou=agriculture,o=gouv,c=fr defaultlanguage: fr_fr.utf8:utf-8:français (France) activetypes: user,group,host,smbdomain Editer ensuite le fichier config.cfg, et mettez par défaut le domaine que l'on vient de rajouter : default: gironde Configurer LAM Connectez-vous au profil serveur, puis : Editer le profil par défaut Cliquez sur le bouton Outils (en haut à droite), puis Editeur de profils. Modifiez le profil par défaut des utilisateurs : groupe primaire : sambausers groupes supplémentaires : draf répertoire utilisateur /home/$user Groupe Samba3 : automatically add this extension : coché date expiration du compte : 1/1/2030 script de connexion : draf.bat groupe windows : Utilisateurs du domaine Editer les paramètres généraux du domaine Connectez-vous à l'interface, choisissez Domaines Samba, modifier le domaine, et indiquez au moins les informations suivantes : longueur de mot de passe minimum : 8 longueur de l'historique des mots de passe : 15 longévité de mot de passe minimum : 0 (les utilisateurs peuvent changer immédiatement leur mot de passe) longévité de mot de passe maximum : , ce qui correspond à 180 jours (exprimé en secondes) durée de blocage : 10 raz du temps après blocage : 5 Et pour travailler sur les deux serveurs maîtres... Si vous disposez d'un serveur web «central», vous pouvez installer le programme LAM sur ce serveur, et créer deux profils serveurs différents : l'un pointant vers le premier serveur, l'autre vers le second. Ainsi, en cas de panne du serveur primaire, vous pourrez continuer à gérer votre annuaire en sélectionnant le second profil. Pour cela, recopiez le fichier domaine.conf en domaine-2.conf, et éditez le second fichier en modifiant l'adresse du serveur LDAP. E. Quinton & D. Olivier 21

22 5.8 En cas de problème avec un compte... Si vous avez intégré un annuaire LDAP un peu ancien, il est possible que certains comptes de login ne fonctionnent plus correctement (impossibilité de se connecter, de changer le mot de passe...). Il va falloir le recréer : mais si vous ne faites pas attention, l'utilisateur va se retrouver avec un nouveau compte, et va devoir reconfigurer sa session Windows : pas sûr qu'il soit très content... Nous allons donc recréer son compte à l'identique. Pour cela, connectez-vous à LAM, puis notez l'ensemble des informations de l'utilisateur, et en particulier: onglet Personnel : toutes les informations... onglet Unix : nom d'utilisateur, nom courant, et surtout UID Editez les groupes, et notez les groupes complémentaires où l'utilisateur est présent onglet samba : date d'expiration du compte, script de connexion, voire d'autres informations si vous les utilisez habituellement (machines de connexion, heures...). Attention : l'export PDF, proposé par LAM, ne suffit pas! Il ne comprend notamment pas l'uid, qui est indispensable... Vous pouvez maintenant supprimer le compte, puis le recréer. L'information essentielle, vous l'avez compris, c'est L'UID : en remettant le même, les machines Windows ne se rendront pas compte que le login a été recréé... 6 Configuration de samba Nous avons deux types de serveurs : les serveurs maîtres, et les serveurs secondaires. Les serveurs maîtres sont tous les deux contrôleurs principaux du domaine et serveurs wins : en cas de panne du premier, le second prend le relais, et reconstruit au besoin sa base wins. Les serveurs secondaires Samba vont utiliser par défaut l'annuaire LDAP des maîtres, pour que les modifications des mots de passe puissent être prises en compte : dans la configuration LDAP que nous avons mise en place, les serveurs secondaires LDAP ne sont pas capables de modifier une information. L'annuaire LDAP installé sur ces serveurs va être utilisé en lecture par les serveurs bureautiques locaux pour la gestion des accès aux ressources, et servira de secours en cas de panne du réseau étendu. E. Quinton & D. Olivier 22

23 6.1 Configuration commune à tous les serveurs Configuration des smbldap-tools Les smbldap-tools sont des scripts mis au point par IDEALX, qui permettent de réaliser des opérations dans l'annuaire LDAP depuis la ligne de commande, mais surtout depuis samba. Pour pouvoir les utiliser, il convient auparavant de les paramétrer. Créez le fichier /etc/smbldaptools/smbldap.conf par la commande suivante : # gunzip /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz -c > /etc/smbldaptools/smbldap.conf puis adaptez les informations suivantes (en gras) : SID="S " sambadomain="gironde" slaveldap=" " slaveport="389" masterldap=" " masterport="389" ldaptls="0" verify="require" cafile="/etc/smbldap-tools/ca.pem" clientcert="/etc/smbldap-tools/smbldap-tools.pem" clientkey="/etc/smbldap-tools/smbldap-tools.key" suffix="ou=agriculture,o=gouv,c=fr" dn="cn=manager,ou=agriculture,o=gouv,c=fr" usersdn="ou=people,${suffix}" computersdn="ou=hosts,${suffix}" groupsdn="ou=group,${suffix}" idmapdn="ou=idmap,${suffix}" sambaunixidpooldn="sambadomainname=${sambadomain},${suffix}" scope="sub" hash_encrypt="ssha" crypt_salt_format="%s" userloginshell="/bin/bash" userhome="/home/%u" userhomedirectorymode="700" usergecos="system User" defaultusergid="513" defaultcomputergid="515" skeletondir="/etc/skel" defaultmaxpasswordage="180" usersmbhome= userprofile= userhomedrive="l:" userscript="logon.bat" maildomain="idealx.com" with_smbpasswd="0" smbpasswd="/usr/bin/smbpasswd" with_slappasswd="0" slappasswd="/usr/sbin/slappasswd" Editez ensuite le fichier /etc/smbldap-tools/smbldap_bind.conf : slavedn="cn=manager,ou=agriculture,o=gouv,c=fr" slavepw="motdepasse" masterdn="cn=manager,ou=agriculture,o=gouv,c=fr" masterpw="motdepasse" Et protégez le fichier (le mot de passe est en clair) : # chmod 600 /etc/smbldap-tools/smbldap_bind.conf E. Quinton & D. Olivier 23

24 Reconfigurer le ldap pour qu'il soit pleinement compatible avec la version courante En raison des modifications liées à la structure de l'annuaire LDAP, il n'est pas impossible que certaines informations manquent dans l'annuaire LDAP pour que samba et les outils SMBLDAP fonctionnent correctement. Pour cela, nous allons lancer la commande : # smbldap-populate qui va réaliser un certain nombre de modifications dans l'annuaire LDAP, à partir des informations présentes dans le fichier smbldap.conf. Indiquez le mot de passe de root, qui sera utilisé comme compte de base système. Vérifier la structure du ldap Après exécution de smbldap-populate, vérifiez la structure de votre annuaire ldap grâce à la vue arborescence de LAM. Vérifiez également que le SID du domaine est correct : s'il y a un problème, vous n'arriverez jamais à vous connecter à une machine. Supprimer les groupes redondants La commande smbldap-populate crée les groupes avec un nom anglais, et certains vont être redondants avec ceux de votre annuaire (même GID). Pour éviter les problèmes, il vaut mieux supprimer ceux qui sont en double. Dans LAM, vue arborescence, supprimez le groupe Domain Admins, puis rajoutez, dans le groupe Admins du domaine, le compte root dans l'attribut memberuid. Supprimez de la même façon les groupes suivants (s'ils sont en double, bien sûr vérifiez avec le GID) : Domain guest Domain Users Administrators Account Operators Print Operators Backup Operators Replicators Créer les dossiers partagés Créez les dossiers qui seront accessibles en partage samba : # mkdir /opt/share_netlogon # mkdir /opt/share_profiles # mkdir /opt/donnees Insérez un fichier dans le partage donnees, pour pouvoir réaliser des tests : # cat /etc/issue > /opt/donnees/test.txt Et modifiez les droits pour /opt/donnees : # chmod -R 770 /opt/donnees # chgrp draf /opt/donnees (le groupe draf correspond au groupe général des utilisateurs du domaine). E. Quinton & D. Olivier 24