Mise en place d'un domaine Samba 2.2 LDAP.

Transcription

1 EDF R&D D ÉP A R T E M E N T S IN ETIC S G R O U P E IN F R AS T R U C T U R E S D E C O M M U N IC A T IO N ET S E C U R IT E 1, AV E N U E D U GÉN É R A L D E GAU LLE F C LA M A R T C ED E X T EL : F AX : Janvier 2004 GANAËL LAPLANCHE (GENESTA), DAVID LACOSTE (EDF R&D) Mise en place d'un domaine Samba 2.2 LDAP. V1.1 Licence de ce document : Copyright (c) , EDF Work by Ganaël Laplanche at EDF R&D's Clamart research center. Author's website : ganael.laplanche@martymac.com. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is d in the section entitled "GNU Free Documentation License". Accessibilité : Selon licence ci-dessus EDF 2004 Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 1/30

2 Sommaire Avant-propos...3 I) Introduction...3 II) Contexte, pré-requis...3 a) Contexte...3 b) Pré-requis...3 III) Installation et configuration du serveur Openldap (Serveur 1, ldap1.martymac.com)...4 a) Installation...4 b) Configuration...4 c) Premiers tests...4 d) Configuration avancée de LDAP...5 IV) Installation de Samba (Serveur 2, pdc.martymac.com)...5 V) Préparation du système pour l'authentification via LDAP (Serveur 2, pdc.martymac.com)...6 a) Installation des outils nécessaires à la redirection des comptes...7 b) Insertion de l'arborescence de base pour samba dans l'annuaire LDAP...7 c) Configuration des méthodes d'authentification du Système...8 1) Configuration de Nsswitch...8 2) Configuration de Pam...9 3) Configuration générale des librairies libpam-ldap et libnss-ldap...9 d) Outils supplémentaires : smbldap-tools...10 e) Premiers tests de connexion...10 VI) Configuration de Samba (Serveur 2, pdc.martymac.com)...11 a) Configurer Samba...11 b) L'Impression...12 c) Test : Joindre une machine au domaine...12 d) Test : Se connecter au domaine avec un utilisateur...13 e) Test : Imprimer...13 VII) Mise en place d'un BDC (Serveur 3, bdc.martymac.com)...14 a) Processus de montage du répertoire Home d'un utilisateur...14 b) Configurons notre BDC...14 c) Test : le BDC prend-il correctement le relai en cas de panne du PDC?...16 VIII) La gestion des ACLs...17 a) Les ACLs au niveau du système de fichier...17 b) Les ACLs au niveau de l'environnement...17 c) Les ACLs au niveau de Samba...18 d) Tests et limites...18 IX) La réplication LDAP (Serveur 4, ldap2.martymac.com)...18 a) Configuration côté maître (Serveur 1, ldap1.martymac.com)...19 b) Configuration côté esclave (Serveur 4, ldap2.martymac.com)...19 c) Remarques...20 d) Tolérance de panne (failover) ) La théorie ) La pratique...21 X) Communication TLS avec notre serveur LDAP...22 a) TLS : Pourquoi?...22 b) Les clefs et les certificats...22 c) La pratique ) Génération des clefs et du certificat ) Mise en place côté serveur ) Mise en place côté client ) Testons notre connexion sécurisée ) Mise en place pour Samba...24 XI) Conclusion...25 XII) Glossaire...26 XIII) Liens / Bibliographie...27 XIV) Remerciements...27 GNU Free Documentation License...28 Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 2/30

3 Avant-propos Ce document a été réalisé durant mon stage de fin d'études à EDF R&D à Clamart. Il a pour but de présenter les différentes étapes de l'installation de samba et OpenLDAP en émulant un domaine windows au sein d'un réseau. Il est principalement basé sur celui d'idealx, ceux de linux mag' (numéros 40 et 46), et ma propre expérience. Il aborde le côté "pratique", plus que théorique, et peut offrir une approche différente des documents déjà existants pour ceux qui sont un peu perdus. Il suppose également que vous ayiez des connaissances de bases sous GNU/Linux... Bonne lecture! I) Introduction Vous le savez, Samba est un outil qui permet de gérer un domaine Windows sans machine Windows! Il est ainsi possible de partager des ressources Unix pour y accéder depuis une machine Windows (partage de répertoire, d'imprimante) et de gérer les logons sur un domaine. Depuis peu, Samba permet de stocker ses utilisateurs dans un annuaire LDAP. Ceci offre un intérêt majeur : une gestion simplifiée et centralisée des comptes Samba. Ainsi, le fichier smbpasswd, dans lequel sont habituellement stockés les comptes utilisateurs, est complètement remplacé par des accès à l'annuaire LDAP (sauf pour le stockage du mot de passe du serveur LDAP qui se fait toujours dans ce fichier). Les avantages d'une telle architecture sont nombreux : robustesse accrue, souplesse d'utilisation, grande disponibilité (possibilité de remanier le pool d'utilisateurs même lorsque le PDC est en panne), etc... Nous aurons l'occasion d'y revenir tout au long de ce document. La version présentée, Samba 2.2.8a, est, à l'heure de l'écriture de ces lignes, la version "stable" de Samba. La version 3 est en cours de finalisation et devrait être disponible très prochainement. Nous allons voir dans un premier temps comment installer et configurer LDAP, puis Samba 2.2 en tant que PDC. Nous verrons ensuite comment ajouter un BDC à notre domaine et enfin comment sécuriser de différentes manières l'architecture mise en place. II) Contexte, pré-requis a) Contexte Les serveurs utilisés fonctionnent tous sous GNU/Linux Debian (3.0r1). Cette distribution a été retenue car elle est à la fois très stable et facilement administrable. Nous installerons chaque service sur des ordinateurs différents, quatre au total : Samba-PDC, Samba-BDC, LDAP et LDAP secondaire. En effet, l'intérêt de l'utilisation de LDAP avec Samba consiste en une décentralisation totale de l'architecture classique. Les machines utilisées sont de puissance moyenne : pour information, un serveur Samba fonctionne très correctement sur un pentium 120 Mhz avec 32 Mo de RAM. Il faudra tout de même des machines plus puissantes si l'on désire monter en charge : j'ai utilisé, dans le cadre de ce mémoire, des Pentium III de 450 à 750 Mhz, disposant de 64 Mo à 256 Mo de RAM. Nous utiliserons également un autre ordinateur, qui nous permettra de tester notre domaine en s'y connectant. Cet ordinateur dispose de Windows XP professionnel. Voici les serveurs dont nous aurons besoin et les différents services que nous allons installer (dans l'ordre) : 1) Serveur 1 : Serveur LDAP : OpenLDAP, nom dns : ldap1.martymac.com, ip : ) Serveur 2 : PDC Samba, nom dns : pdc.martymac.com, nom netbios : MARTYMAC-PDC, ip : ) Serveur 3 : BDC Samba, nom dns : bdc.martymac.com, nom netbios : MARTYMAC-BDC, ip : ) Serveur 4 : Serveur LDAP secondaire, nom dns : ldap2.martymac.com, ip : La station de travail : 5) Client 1 : Client Windows XP, nom dns : xp.martymac.com, nom netbios : XP-CLIENT, ip : b) Pré-requis Il faut un minimum de connaissances concernant GNU/Linux pour comprendre ce document ; cependant nous progressons pas à pas et chaque étape est décrite de manière simple, ce qui devrait permettre à quelqu'un qui débute d'arriver au résultat attendu. Il est également nécessaire de disposer d'installations "propres" et fonctionnelles du système d'exploitation GNU/Linux (Debian 3.0r1) afin de mettre en oeuvre ce qui est décrit dans ce document. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 3/30

4 III) Installation et configuration du serveur Openldap (Serveur 1, ldap1.martymac.com) a) Installation Commençons par l'installation du serveur LDAP et sa configuration. Le serveur LDAP permettra de fournir à Samba les informations concernant les comptes utilisateurs du domaine. Nous allons avoir besoin de plusieurs composants : - les librairies LDAP compilées, - les sources de ces librairies (pour des compilations futures), - les utilitaires d'interrogation d'annuaire, - le serveur LDAP (slapd) L'installation de tout ceci se fait de manière très simple sous Debian, via apt : - apt-get install libldap2 libldap2-dev ldap-utils slapd Le serveur est désormais installé, nous allons voir comment le configurer... b) Configuration - Editer le fichier le fichier /etc/ldap/slapd.conf pour configurer OpenLDAP : pidfile argsfile database suffix rootdn rootpw directory index cn eq /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/nis.schema /var/run/slapd.pid /var/run/slapd.args ldbm "dc=martymac,dc=com" "cn=manager,dc=martymac,dc=com" secret /var/lib/ldap Le "rootdn" représente le compte autorisé à modifier la base LDAP. Le "rootpw" représente son mot de passe. Attention, il est stocké en clair dans le fichier... - Nous disposons maintenant d'une configuration suffisante pour démarrer le serveur : /etc/init.d/ldap start c) Premiers tests Nous allons essayer d'insérer, depuis l'hôte local, quelques enregistrements dans notre base LDAP, afin de tester notre serveur : - Créer un fichier test.ldiff source : dn: dc=martymac,dc=com objectclass: dcobject dc: martymac objectclass: organization o: martymac dn: ou=personnes,dc=martymac,dc=com objectclass: top objectclass: organizationalunit ou: personnes description: Branche personnes Il faut ensuite insérer les données du fichier : - ldapadd -W -D 'cn=manager,dc=martymac,dc=com' -f test.ldiff Pour rechercher (dumper la base, a partir de 'dc=martymac,dc=com') : - ldapsearch -W -D 'cn=manager,dc=martymac,dc=com' -b 'dc=martymac,dc=com' - ou : ldapsearch -b 'dc=martymac,dc=com' (car dans notre cas, pas besoin d'authentification pour les recherches) Pour effacer les données (afin de laisser une base propre pour la suite) : - ldapdelete -W -D 'cn=manager,dc=martymac,dc=com' 'ou=personnes,dc=martymac,dc=com' Maintenant que notre serveur LDAP fonctionne, configurons-le pour qu'il puisse recevoir nos futurs comptes Samba. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 4/30

5 d) Configuration avancée de LDAP Nous allons configurer LDAP pour qu'il nous fournisse un accès à des comptes Samba. Il faut tout d'abord spécifier quel schema (structure de comptes) utiliser. La distribution de Samba en fournit un (dans le répertoire examples/ des sources). - Récupérer les sources de Samba ( - Les décompresser : tar xvzf samba_2.2.8a-0.1.tar.gz - Copier le fichier examples/samba.schema dans /etc/ldap/schema/ Il faut ensuite inclure ce nouveau schéma dans le fichier slapd.conf. - Edition du fichier /etc/ldap/slapd.conf pour obtenir ceci : pidfile argsfile database suffix rootdn rootpw directory /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/samba.schema /var/run/slapd.pid /var/run/slapd.args ldbm "dc=martymac,dc=com" "cn=manager,dc=martymac,dc=com" secret /var/lib/ldap index objectclass,rid,uid,uidnumber,gidnumber,memberuid eq index cn,mail,surname,givenname eq,subinitial Le serveur est désormais configuré et prêt à stocker les comptes Samba. Il nous reste à configurer les clients LDAP (locaux) : ldapsearch, ldapdelete... Ceci se fait par l'édition du fichier ldap.conf : - Edition du fichier /etc/ldap/ldap.conf : base dc=martymac,dc=com host On peut désormais redémarrer notre serveur LDAP : /etc/init.d/ldap restart Il sera prêt à être interrogé par Samba, une fois que nous l'aurons peuplé. Passons désormais au second serveur, le serveur Samba. IV) Installation de Samba (Serveur 2, pdc.martymac.com) Pour Samba, nous ne pouvons pas installer directement les packages via apt-get car nous allons avoir besoin de certaines options non compilées par défaut. Nous allons donc recréer notre propre package Debian. Auparavant, il est nécessaire d'installer sur ce serveur l'environnement LDAP complet : - apt-get install libldap2 libldap2-dev ldap-utils - Récupérer à nouveau les sources de Samba ( - Les décompresser : tar xvzf samba_2.2.8a-0.1.tar.gz Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 5/30

6 Modifier les sources Samba afin de créer un package Debian à notre convenance : - Modifier le fichier debian/rules : Lignes 61 et + (concernant les options du./configure), supprimer toutes les références à pam (2), pour obtenir ceci : 60 [ -f source/makefile ] (cd source &&./configure \ 61 --host=$(deb_host_gnu_type) \ 62 --build=$(deb_build_gnu_type) \ 63 --with-fhs \ 64 --prefix=/usr \ 65 --sysconfdir=/etc \ 66 --with-privatedir=/etc/samba \ 67 --localstatedir=/var \ 68 --with-netatalk \ 69 --with-smbmount \ 70 --with-syslog \ 71 --with-sambabook \ 72 --with-utmp \ 73 --with-readline \ 74 --with-libsmbclient \ 75 --with-winbind \ 76 --with-msdfs \ 77 --with-automount \ 78 --with-acl-support \ 79 --with-profile \ 80 --disable-static \ 81 --with-ldapsam) Lignes 130/131, commenter la référence à pam : 130 #install -m 0644 source/nsswitch/pam_winbind.so \ 131 # $(DESTDIR)/lib/security/ Ligne 141, idem : 141 #mv $(DESTDIR)/usr/bin/pam_smbpass.so $(DESTDIR)/lib/security/ Ligne 181 également : 181 #cp debian/samba.pamd $(DESTDIR)/etc/pam.d/samba - Modifier ensuite le fichier debian/libpam-smbpass.files et supprimer la ligne concernant pam_smbpass.so (le fichier est alors vide) - Modifier le fichier debian/samba-common.conffiles et supprimer la ligne /etc/pam.d/samba (le fichier est alors vide) - Modifier enfin le fichier debian/winbind.files et supprimer la ligne concernant pam_winbind.so Les sources sont prêtes pour créer les packages debian : - Exécuter : dpkg-buildpackage dans le répertoire principal. Les packages sont compilés et copiés dans../ - Installer les packages : dpkg -i samba-common_2.2.8a-0.1_i386.deb libsmbclient_2.2.8a-0.1_i386.deb samba_2.2.8a- 0.1_i386.deb smbclient_2.2.8a-0.1_i386.deb smbfs_2.2.8a-0.1_i386.deb swat_2.2.8a-0.1_i386.deb winbind_2.2.8a- 0.1_i386.deb Samba est maintenant installé, nous allons préparer l'environnement système afin de pouvoir s'authentifier sous debian via le serveur LDAP. V) Préparation du système pour l'authentification via LDAP (Serveur 2, pdc.martymac.com) Samba nécessite deux types de comptes : un compte Système, pour pouvoir identifier les utilisateurs, et un compte interne, pour pouvoir les authentifier et disposer d'informations propres au domaine (répertoire home, profils, etc...) qui ne sont pas stockées dans le compte système. Par défaut, sur GNU/Linux, les comptes systèmes utilisés par Samba sont situés dans /etc/passwd et /etc/group. Puisque ceci nous obligerait à avoir deux enregistrements pour un seul utilisateur : un dans /etc/passwd et un dans LDAP, nous allons rediriger les appels systèmes vers notre serveur LDAP. Cette redirection se fait via nsswitch. Ainsi, Samba fera toujours deux appels : un appel système (redirigé vers LDAP) et un appel interne (vers les comptes Samba stockés sous LDAP). Cependant, ceci se fera de manière totalement transparente ; nous ne stockons qu'un seul compte pour chaque utilisateur dans notre annuaire LDAP. Nous allons également utiliser pam, puisque l'on veut que nos utilisateurs puissent s'authentifier avec leur compte LDAP sous GNU/Linux. Pam va permettre la même redirection que nsswitch, mais cette fois-ci pour l'authentification (nsswitch concerne pour l'identification). Bien entendu, ces redirections nécessitent l'utilisation d'outils particuliers et une configuration préalable du système, ce que nous allons voir... Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 6/30

7 a) Installation des outils nécessaires à la redirection des comptes Installation de nscd : Name service cache daemon, fournit un cache pour les requêtes de noms LDAP. - apt-get install nscd Installation de libnss-ldap : Permet d'ajouter la gestion de LDAP à nsswitch. Nsswitch sert d'interface pour la résolution de noms de plusieurs services (les groupes utilisateurs, les noms de machines, etc...). Il permet d'indiquer au système où chercher les informations. Il faut ici le configurer afin d'indiquer à la machine que les utilisateurs et groupes peuvent être situés sur l'annuaire LDAP. Ceci sera utile notamment pour pouvoir effectuer des modifications de droits avec des groupes ou utilisateurs présents dans l'annuaire LDAP (en complétant le pool d'utilisateurs et de groupes déjà présents dans les fichiers /etc/passwd et /etc/group lors d'un chown, chmod, chgrp, getent...). - apt-get install libnss-ldap Installation de libpam-ldap : Modules LDAP pour pam Pam sert à l'authentification des utilisateurs. Il offre aux applications une couche transparente qui permet de gérer, via des modules, n'importe quelle méthode d'authentification (de la carte à puce, aux fichiers passwd, en passant par la biométrie...). Il faut lui indiquer, dans notre cas, d'utiliser l'annuaire LDAP pour s'authentifier sur le système GNU/Linux. Ceci n'est nécessaire que si l'on souhaite pouvoir s'authentifier sur le système GNU/Linux avec les comptes LDAP. - apt-get install libpam-ldap b) Insertion de l'arborescence de base pour samba dans l'annuaire LDAP Notre domaine va nécessiter une arborescence de base qui va permettre d'organiser les différents comptes, créons la. - Création d'un fichier base.ldiff temporaire : dn: dc=martymac,dc=com objectclass: domain dc: martymac dn: ou=groups,dc=martymac,dc=com objectclass: top objectclass: organizationalunit ou: Groups description: System Groups dn: ou=users,dc=martymac,dc=com objectclass: top objectclass: organizationalunit ou: Users description: Users of the Organization dn: ou=computers,dc=martymac,dc=com objectclass: top objectclass: organizationalunit ou: Computers description: Windows Domain Computers dn: cn=domain Admins,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 200 cn: Domain Admins memberuid: administrator description: Windows Domain Users dn: cn=domain Users,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 201 cn: Domain Users description: Windows Domain Users dn: cn=domain Guests,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 202 cn: Domain Guests description: Windows Domain Guests Users dn: cn=administrators,ou=groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 220 cn: Administrators description: Members can fully administer the computer/domain dn: cn=users,ou=groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 221 cn: Users description: Ordinary users Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 7/30

8 dn: cn=guests,ou=groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 222 cn: Guests memberuid: nobody description: Users granted guest access to the computer/domain dn: cn=power Users,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 223 cn: Power Users description: Members can share directories and printers dn: cn=account Operators,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 224 cn: Account Operators description: Windows Domain Users to manipulate users accounts dn: cn=server Operators,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 225 cn: Server Operators description: Windows Domain Server Operators dn: cn=print Operators,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 226 cn: Print Operators description: Windows Domain Print Operators dn: cn=backup Operators,ou=Groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 227 cn: Backup Operators description: Windows Domain Members can bypass file security to back up files dn: cn=replicator,ou=groups,dc=martymac,dc=com objectclass: posixgroup gidnumber: 228 cn: Replicator description: Supports file replication in a domain - Insertion de cet arbre dans l'annuaire LDAP du Serveur 1 : ldapadd -W -D 'cn=manager,dc=martymac,dc=com' -f base.ldiff -xh ldap1.martymac.com LDAP est maintenant prêt à recevoir nos utilisateurs, aussi bien GNU/Linux que Samba. On remarque que l'arbre comprend 3 branches principales : Groups, Users, et Computers, destinées à stocker, respectivement : les Groupes d'utilisateurs, les Utilisateurs (reliés aux groupes via le gid) et les Ordinateurs. Nous avons également quelques groupes standards de domaine à disposition (Domain Users, Domain Guests), bien que Samba ne les exploite pas tous. Nous allons bientôt pouvoir nous identifier via LDAP : il reste maintenant à configurer notre système pour qu'il utilise notre serveur pour l'authentification. c) Configuration des méthodes d'authentification du Système 1) Configuration de Nsswitch - La configuration générale de libnss-ldap se fait via le fichier /etc/ldap/ldap.conf (cf ci-après) - Il faut tout d'abord modifier le fichier /etc/nsswitch.conf pour qu'il fasse appel à LDAP. (Un exemple est disponible dans /usr/share/doc/libnss-ldap/examples/nsswitch.ldap) passwd: group: shadow: hosts: files ldap files ldap files ldap files dns services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files netmasks: files bootparams: files publickey: files automount: files aliases: netgroup: files files nis Attention pour "hosts" : si vous ajoutez l'annuaire LDAP comme source de données, vous avez de grande chance de tomber sur un problème de récursivité, où le système essaiera de résoudre le nom du serveur LDAP via le serveur LDAP... dont il n'a pas résolu le nom! Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 8/30

9 2) Configuration de Pam - La configuration générale de libpam-ldap se fait via le fichier /etc/ldap/ldap.conf (cf ci-après) - Modification de /etc/pam.d/system-auth (cf /usr/share/doc/libpam-ldap/examples/pam.conf) : auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so account sufficient /lib/security/pam_ldap.so password required /lib/security/pam_cracklib.so retry=3 type= password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/pam_ldap.so use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so - Modification de chaque fichier nécessaire (suivant les besoins) dans /etc/pam.d pour ajouter LDAP à pam (pam_ldap.so). A chaque fichier correspond un service. Exemple avec /etc/pam.d/ssh : auth sufficient pam_ldap.so auth required pam_nologin.so auth required pam_unix.so auth required pam_env.so # [1] account sufficient pam_ldap.so account required pam_unix.so session sufficient pam_ldap.so session required pam_unix.so session optional pam_lastlog.so # [1] session optional pam_motd.so # [1] session optional pam_mail.so standard noenv # [1] session required pam_limits.so password sufficient pam_ldap.so password required pam_unix.so - Installation du module pam_cracklib.so (si manquant) : apt-get install libpam-cracklib 3) Configuration générale des librairies libpam-ldap et libnss-ldap Nsswitch et Pam fon appel à ces deux librairies, il va maintenant falloir les configurer. Le paramétrage se fait via la configuration des outils Ldap, dans le fichier ldap.conf. - Modification de /etc/ldap/ldap.conf (cf /usr/share/doc/libpam-ldap/examples/ldap.conf) : BASE dc=martymac,dc=com HOST ldap1.martymac.com ldap_version 3 nss_base_passwd nss_base_shadow nss_base_group rootbinddn cn=manager,dc=martymac,dc=com pam_password md5 ssl no dc=martymac,dc=com?sub dc=martymac,dc=com?sub ou=groups,dc=martymac,dc=com?one - Il faut également créer un fichier /etc/ldap.secret : echo "secret" > /etc/ldap.secret, contenant le mot de passe du rootbinddn pour les mises à jour de la base. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 9/30

10 d) Outils supplémentaires : smbldap-tools Les smbldap-tools sont des outils développés par idealx permettant de gérer des comptes Samba de manière très simple en lignes de commandes. Nous les utiliserons dans le fichier smb.conf pour ajouter certains comptes automatiquement, mais ils facilitent également le travail quotidien de l'administrateur système. Installation de smbldap-tools : - Télécharger smbldap-tools sur idealx ( - Décompresser le tarball : tar xvzf smbldap-tools-0.7.tgz - Copie des *.pl ds /usr/local/sbin - Copie des *.pm ds /usr/share/perl/5.6.1 (à modifier suivant votre version de Perl) - Extraction de mkntpwd - Editer le Makefile et ajouter au début du fichier : PREFIX=/usr/local (Pour que l'installation se fasse dans $PREFIX/sbin) - Compilation de mkntpwd : make && make install Configuration de smbldap-tools : - Editer le fichier /usr/share/perl/5.6.1/smbldap_conf.pm et spécifier chaque option (n'en oubliez pas!!!) Modification des smbldap-tools (0.7) : Il semblerait qu'openldap, dans les versions récentes, vérifie de manière plus approfondie la hiérarchie des objets utilisés. Lorsqu'on désire ajouter un compte machine (cf. plus loin), smbldap-tools utilise un objet posixaccount, qui n'est pas un objet Structurel ('parent') : il s'agit d'un objet de type Auxiliaire ('fils'), ce qu'il signifie qu'il dépend d'une autre classe qui est ici account. smbldap-tools utilise, dans ses fonctions d'ajout de comptes machines, l'objet posixaccount sans l'objet account, ce qui a pour effet le refus de la part du serveur LDAP d'ajouter l'enregistrement à la base (cf rfc ceci ne devait pas poser problème avec les versions antérieures de LDAP). Il faut pour ceci modifier les smbldap-tools : Editez /usr/share/perl/5.6.1/smbldap-tools.pm et ajoutez account avant toute utilisation de posixaccount (2 fois dans le fichier). e) Premiers tests de connexion - Création d'un utilisateur avec smbldap-tools : smbldap-useradd.pl -m testuser1 - Modification de son mot de passe : smbldap-passwd testuser1 - On peut voir si cet utilisateur est bien connu du système : getent passwd - Test de connexion avec cet utilisateur depuis la machine GNU/Linux : ssh -l testuser1 localhost. (Si vous obtenez un message d'erreur du type : 'Authentication service cannot retrieve authentication info', cela provient certainement de la configuration des fichiers dans /etc/pam.d. Ré-éditez ces fichiers pour ajouter le module pam_ldap.so). - Listing de l'utilisateur : ldapsearch -b 'dc=martymac,dc=com' -xh ldap1.martymac.com - Suppression du user : smbldap-userdel testuser1 et effacement de son répertoire home créé sur le disque A ce stade, nous pouvons nous authentifier sur le système via LDAP, il nous reste à configurer Samba. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 10/30

11 VI) Configuration de Samba (Serveur 2, pdc.martymac.com) a) Configurer Samba La configuration de Samba se fait via le fichier smb.conf. Celui-ci comporte une description du comportement général du serveur (section [global]), ainsi qu'une énumération des partages qui seront créés sur la machine (les autres sections). Le PDC offira le partage netlogon, que l'on ne peut pas déporter sur le BDC, ainsi que le partage d'une imprimante. Le BDC, quant à lui, offrira les autres partages de données (répertoire home, profils, et autres partages divers). - Edition du fichier /etc/samba/smb.conf : [global] ; le nom de notre domaine workgroup = MARTYMAC ; notre nom de machine netbios netbios name = MARTYMAC-PDC ; le nom complet server string = Martymac PDC Server encrypt passwords = Yes ; Synchro pass Unix passwd program = /usr/local/sbin/smbldap-passwd.pl -o %u passwd chat = *new*password* %n\n *new*password* %n\n *successfully* unix password sync = Yes ; Ajout de machine via smbldap-tools add user script = /usr/local/sbin/smbldap-useradd.pl -w %u domain admin group = Admins" " ; Logs log file = /var/log/samba/%m.log log level = 2 max log size = 5000 ; Quelques options réseau socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 ; On contrôle les logons, on est DC domain logons = Yes ; Master browser, browser pour le domaine (un seul par domaine) domain master = Yes ; Force élections en tant que master browser + donne un avantage preferred master = Yes ; Poids lors des élections de master browser os level = 65 ; Local master browser (browser pour le sous réseau) local master = Yes dns proxy = No ; Serveur Wins actif (un seul par reseau) wins support = Yes security = user ; LDAP ldap suffix = dc=martymac,dc=com ldap admin dn = cn=manager,dc=martymac,dc=com ldap port = 389 ldap server = ldap1.martymac.com ldap ssl = No ; Impression load printers = yes printing = cups printcap name = cups ; Prise en charge du francais character set = iso ; Répertoire scripts [netlogon] comment = Network Logon Service path = /export/samba/netlogon guest ok = Yes ; Partage d'imprimantes [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No writable = no guest ok = yes public = yes printer admin = printadmin ; Partage des drivers d'imprimantes [print$] comment = Printer Drivers path = /etc/samba/drivers browseable = yes guest ok = no read only = yes write list = printadmin Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 11/30

12 Il ne faut pas oublier de créer les répertoires partagés : - Création du répertoire /export/samba/netlogon pour le stockage des scripts de connexion. - De /var/spool/samba : répertoire de spool, qui contiendra les données en cours d'impression (Gestion des droits sur ce répertoire : chmod 775 /var/spool/samba) - Création enfin de /etc/samba/drivers qui contiendra nos drivers d'imprimante (partagés par print$) (y copier les drivers de l'imprimante) - Enfin, il reste à à indiquer à Samba le mot de passe de l'administrateur LDAP (rootdn) : smbpasswd -w secret Samba va créer le fichier /var/lib/samba/secrets.tdb. Attention, ce fichier n'est pas chiffré! Notre PDC dispose désormais de 3 partages : netlogon, printers et print$ et est prêt à authentifier nos utilisateurs sur le domaine. Le partage netlogon contiendra les scripts de connexion des utilisateurs (scripts batch exécutés au logon de l'utilisateur), le partage printers contient les imprimantes, tandis que le partage print$ va contenir leurs drivers. b) L'Impression Pour pouvoir imprimer depuis notre serveur GNU/Linux, nous allons utiliser CUPS (Common Unix Printing System). Samba va utiliser ces outils pour rediriger les requêtes d'impression vers l'imprimante. - Installation de CUPS : apt-get install cupsys cupsys-client cupsys-bsd cupsomatic-ppd cupsys-driver-gimpprint - Configuration de CUPS (édition de /etc/cups/printers.conf ou via Nous allons utiliser samba comme un serveur de spool uniquement, ce qui signifie qu'il ne fera aucune conversion de données, il n'agira que comme une mémoire tampon d'impression/gestionnaire de file d'attente. En d'autres termes, il faudra que chaque client envoie le type de données attendues par l'imprimante, et donc, dispose du driver approprié. Celui-ci sera disposé dans le partage samba print$. - Modification de /etc/cups/mimes.types et /etc/cups/mimes.convs pour décommenter les lignes application/octet-stream en fin de fichier. Ceci va permettre à cups de gérer l'impression 'brute' que l'on va utiliser. - Tester enfin cups pour voir si l'impression fonctionne ; ceci peut se faire via le web : Samba devrait désormais pouvoir imprimer. Testons la mise au domaine d'une machine... c) Test : Joindre une machine au domaine Nous disposons maintenant d'un domaine complet, sur lequel nous allons joindre une machine, préalable nécessaire à la connexion d'un utilisateur depuis cette machine. Nous allons utiliser ici notre client Windows XP. Note : Pour pouvoir contacter le contrôleur de domaine, la station a trois possibilités (dans l'ordre) : - Elle contacte le serveur Wins indiqué dans les propriétés Tcp/Ip pour obtenir des informations sur le contrôleur de domaine - Elle recherche les informations dans le fichiers lmhosts local (C:\winnt\system32\drivers\etc\lmhosts) - Elle broadcast sa demande Pour effectuer la jonctions au domaine, vous avez donc le choix. Pour éviter les problèmes, je vous conseille plutôt d'utiliser une station Windows sur le même réseau IP que le PDC (afin d'utiliser la méthode du broadcast), cependant, vous pouvez aussi indiquer le serveur Wins (non testé! - ici notre serveur Samba) en le configurant dans les propriétés Tcp/Ip du poste, ou bien encore la méthode du fichier statique, dont voici un exemple : #Fichier lmhosts MARTYMAC-PDC #PRE #DOM:MARTYMAC "MARTYMAC-PDC \0x1C" #PRE "MARTYMAC-PDC \0x1B" #PRE Attention, le nom netbios précédant "\0x1C" ou "\0x1B" doit faire exactement 15 caractères... ("\0x1B" déclare un PDC, et "\0x1C" un contrôleur de domaine). Pour recharger le cache netbios de notre machine Windows, il suffit ensuite d'exécuter la commande nbtstat -R, puis pour vérifier le cache : nbtstat -c. Avant de joindre la machine au domaine, vérifions une dernière fois la conformité de notre configuration : - Redémarrage de samba : /etc/init.d/samba restart - Exécution de 'testparm' pour tester le fichier smb.conf - Test du serveur samba : 'nmblookup MARTYMAC-PDC' et 'smbclient -N -L MARTYMAC-PDC', le nom netbios est normalement trouvé et les partages affichés. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 12/30

13 Pour joindre le domaine, il faut disposer d'un compte machine autorisé dans LDAP, si toutefois ceci n'était pas le cas, samba l'ajouterait automatiquement grâce à l'option : add user script = /usr/local/sbin/smbldap-useradd.pl -w %u du fichier smb.conf. Cependant l'ajout automatique peut poser problème dans certains cas, provocant des erreurs côté Windows. J'ai en effet été confronté à ce problème : lors de la jonction au domaine, la machine est correctement créée, mais une erreur survient ; il faut alors à nouveau rejoindre le domaine avec le compte machine créé pour que tout fonctionne correctement. Mieux vaut ajouter manuellement la machine : - smbldap-useradd.pl -w XP-CLIENT$ XP-CLIENT correspond au nom netbios de la machine Windows, le $ ajouté en fin de nom signifie que cet "utilisateur" est une machine. Si cette commande pose problème, peut-être avez-vous oublié de modifier les smbldap-tools ou de les configurer? (voir précédemment). A ce stade, il n'est pas encore possible de rattacher la machine au domaine, car on ne dispose pas d'un utilisateur ayant ce droit (uid=0, gid=0). Nous allons le créer. - Ajout d'un utilisateur 'rootadmin' pour ajouter une machine au domaine : - smbldap-useradd.pl -a -m -g 200 rootadmin - smbldap-usermod.pl -u 0 -g 0 rootadmin - smbldap-passwd.pl rootadmin Attention à ne pas créer un utilisateur nommé 'root', pour éviter conflits avec le vrai root local!!! La machine peut maintenant rejoindre le domaine grâce à l'utilisateur rootadmin. d) Test : Se connecter au domaine avec un utilisateur Cette fois, la machine fait partie du domaine, nous allons avoir besoin d'un compte utilisateur pour se connecter. Nous ajoutons un utilisateur au domaine : - smbldap-useradd.pl -a -m -g 221 utilisateur - smbldap-passwd.pl utilisateur Cet utilisateur pourra se "logger" avec son compte sous GNU/Linux ET Windows ; si l'on veut qu'il ne puisse pas se "logger" sous GNU/Linux, il faut préciser un home "/dev/null" et un shell "/bin/false", en le créant ainsi : smbldapuseradd.pl -d /dev/null -s /bin/false -a -m -g 221 utilisateur, ou bien tout simplement ne pas installer la gestion de LDAP pour pam sur la machine GNU/Linux. Remarquez que, par défaut, l'utilisateur créé dispose du répertoire "home" et "profile" spécifiés dans la configuration des smbladp-tools. Pour l'instant, nous ne gérons pas ces deux partages (quasiment indispensables). C'est notre BDC qui va les prendre en charge (voir ci-dessous). Vérifier que l'utilisateur n'ait pas trop de droits sur /export/samba/netlogon : - chmod 550 /export/samba/netlogon et chmod 400 sur chaque script du répertoire (si vous en avez). On peut désormais se "logger" avec cet utilisateur sur le domaine depuis notre machine Windows XP. Il n'aura pas encore accès à son répertoire home, ni à son profil. e) Test : Imprimer - Connectez-vous sur le poste client Windows en administrateur local et ajoutez l'imprimante partagée - Vous pouvez maintenant imprimer à partir de n'importe quel utilisateur du domaine Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 13/30

14 VII) Mise en place d'un BDC (Serveur 3, bdc.martymac.com) La mise en place d'un BDC dans notre réseau va permettre de séparer la fonction d'authentification de celle du partage de fichiers. Nous allons pouvoir ajouter sur notre domaine la gestion des répertoires "homes" et "profiles" des utilisateurs, habituellement situés sur le PDC. Cette décentralisation permet de supprimer les points sensibles sur notre réseau et de limiter les goulets d'étranglement. Comme vous avez pu le constater, le partage netlogon est inséparable du PDC (il est impossible de passer un chemin UNC au niveau du fichier smb.conf ou de l'annuaire LDAP) ; la même restriction existe au niveau de Windows NT4... nous le laisserons donc sur celui-ci, ce qui ne pose pas de problème majeur : seuls les scripts ne seront pas accessibles en cas de panne du PDC. Note : Pour remédier à cela, plusieurs solutions pourraient être envisagées (que l'on ne va pas mettre en oeuvre car leur intérêt n'est pas primordial) : avoir deux partages netlogon : sur le BDC et le PDC, et monter, via NFS par exemple, les scripts du BDC sur le PDC ; seconde solution : avoir deux partages netlogon : sur le BDC et le PDC, et synchroniser les scripts via rsync ou rcp entre le PDC et le BDC... a) Processus de montage du répertoire Home d'un utilisateur Voici l'architecture à laquelle nous allons aboutir après avoir mis en place notre BDC. BDC [homes] [profiles] bis PDC [netlogon] 4 1 Utilisateur Windows XP bis Annuaire Ldap Le BDC assure le partage des fichiers de l'utilisateur 1 : L'utilisateur demande l'authentification sur le domaine auprès du PDC 2 : Le PDC se connecte au serveur LDAP pour vérifier la validité du compte utilisateur [2 bis] : Le BDC (si le PDC est en panne) se connecte au serveur LDAP pour vérifier la validité du compte utilisateur 3 : L'annuaire LDAP répond au PDC [3 bis] : L'annuaire LDAP répond au BDC (si le PDC est en panne) 4 : Il autorise (ou non) l'utilisateur à accéder aux ressources du domaine 5 : Si l'utilisateur est autentifié, il peut accéder au BDC, et demander l'accès à une ressource (son répertoire Home) 6 : Le BDC lui fournit cet accès b) Configurons notre BDC La configuration du BDC se fait de la même manière que celle du PDC, à la différence des options d'élections présentes dans le fichier smb.conf qu'il faut modifier (baisser) et les partages qui seront différents. Le BDC doit, lui aussi, disposer d'un nsswitch modifié, ainsi que de la librairie libnss-ldap (et éventuellement libpam-ldap). Il faudra également installer la base ldap-client et les smbldap-tools. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 14/30

15 Notre BDC a pour nom netbios MARTYMAC-BDC, voici sa configuration samba (/etc/samba/smb.conf) : [global] ; le nom de notre domaine workgroup = MARTYMAC ; notre nom de machine netbios netbios name = MARTYMAC-BDC ; le nom complet server string = Martymac BDC Server encrypt passwords = Yes ; Synchro pass Unix passwd program = /usr/local/sbin/smbldap-passwd.pl -o %u passwd chat = *new*password* %n\n *new*password* %n\n *successfully* unix password sync = Yes ; Ajout de machine via smbldap-tools add user script = /usr/local/sbin/smbldap-useradd.pl -w %u domain admin group = Admins" " ; Logs log file = /var/log/samba/%m.log log level = 2 max log size = 5000 ; Quelques options réseau socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 ; On contrôle les logons, on est DC domain logons = Yes ; Master browser, browser pour le domaine (un seul par domaine) domain master = No ; Force élections en tant que master browser + donne un avantage preferred master = No ; Poids lors des élections de master browser os level = 48 ; Local master browser (browser pour le sous réseau) local master = No dns proxy = No ; Serveur Wins actif (un seul par reseau) wins support = No security = user ; LDAP ldap suffix = dc=martymac,dc=com ldap admin dn = cn=manager,dc=martymac,dc=com ldap port = 389 ldap server = ldap1.martymac.com ldap ssl = No ; Impression load printers = yes printing = cups printcap name = cups ; Prise en charge du francais character set = iso ; Répertoires homes, à mapper via \\SERVEUR\utilisateur [homes] path=/export/samba/home/%u comment = Home Directories valid users = %S read only = No create mask = 0664 directory mask = 0775 browseable = No ; Répertoires profiles, à mapper via \\SERVEUR\profiles\utilisateur [profiles] path = /export/samba/profiles writeable = yes browseable = no create mode = 0644 directory mode = 0755 guest ok = yes [tmp] comment = Temporary file space path = /tmp read only = No guest ok = Yes Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 15/30

16 Le BDC offre désormais les partages auparavant assurés par le PDC. Il va donc falloir y créer les répertoires partagés génériques, (ici /export/samba/home et /export/samba/profiles), ainsi que le répertoire home de chaque utilisateur : Exemple pour l'utilisateur 'utilisateur' : - mkdir /export/samba/home/utilisateur - chown utilisateur:users /export/samba/home/utilisateur - chmod 755 /export/samba/home/utilisateur Il faut aussi régler les droits du répertoire profiles de la même manière que pour le PDC : - chown :Users /export/samba/profiles - chmod 775 /export/samba/profiles Enfin, il faut modifier le chemin des répertoires 'home' et 'profile' de notre utilisateur au sein de LDAP. Nous allons indiquer ceux que l'on vient de partager : - smbldap-usermod.pl -C \\\\MARTYMAC-BDC\\utilisateur -F \\\\MARTYMAC-BDC\\profiles\\utilisateur utilisateur Ainsi,notre utilisateur y aura enfin accès. Ne pas oublier d'initialiser le password samba LDAP : - smbpasswd -w secret Enfin, il ne faut pas oublier de synchroniser le SID du BDC avec celui du PDC. Le SID sera stocké dans le fichier secrets.tdb, le même qui stocke le mot de passe LDAP. Sur le BDC (le PDC doit être joignable) : - smbpasswd -S -r MARTYMAC-PDC Voilà, si on démarre le PDC et le BDC, la station s'authentifiera sur le PDC et montera les partages du BDC. Si le PDC tombe en panne, la station devrait s'authentifier sur le BDC. Effectuons quelques tests pour confirmer ceci... c) Test : le BDC prend-il correctement le relai en cas de panne du PDC? Nous allons effectuer ces tests avec un client Windows XP, appelé XP-CLIENT. Le problème majeur pour tester la validité de notre configuration est que notre machine Windows peut authentifier ellemême un utilisateur s'il s'est déjà connecté sur le domaine à partir de celle-ci. Pour être plus clair, voici un exemple : on crée un utilisateur sous LDAP, le PDC et le BDC sont en marche. Si on se "log" à partir de notre station Windows, tout fonctionne normalement. Eteignons maintenant le PDC et le BDC. Normalement, nous n'avons plus de DC pour nous authentifier sur le domaine... Cependant, notre station va quand même le faire : elle a gardé l'utilisateur en cache. Ceci offre un avantage : si le PDC et le BDC tombent en panne en même temps sur un réseau (peu probable), nous avons quand même la possibilité d'utiliser la station. L'inconvénient est que des problèmes de sécurité peuvent se poser... Quels sont-ils? Tout simplement la non-concordance des bases d'utilisateurs. Imaginons qu'un utilisateur soit supprimé de la base LDAP après que le PDC et le BDC soient tombés en panne, l'utilisateur peut toujours se connecter à la station tandis qu'il a normalement été rayé de la liste des utilisateurs valides! Testons un peu notre configuration... - PDC et BDC démarrés - Création d'un utilisateur sous LDAP - On peut se connecter avec l'utilisateur, on dispose des scripts netlogon (ceci est normal, ils sont sur le PDC) - Extinction du PDC - On peut toujours se connecter avec l'utilisateur, on ne dispose plus des scripts netlogon (ceci est normal, il n'y en a pas sur le BDC) Problème : a-t-on bien été identifiés pas le BDC? Ne serait-ce pas la machine Windows qui l'aurait fait (car si on éteint le BDC, on observe ici le même résultat)? - Supprimons l'utilisateur sous LDAP - On ne peut plus se connecter avec l'utilisateur... C'est bien le BDC qui nous a authentifié Si cela n'est pas le cas, c'est que c'est votre machine Windows qui vous a authentifié, on en revient au problème cité cidessus : elle n'est pas synchronisée avec LDAP et ne sait donc pas que l'utilisateur a été supprimé. Par contre, le BDC, lui, interroge constamment l'annuaire, donc si votre machine passe par lui pour l'authentification, vous êtes refusé, ce qui se passe ici. La suppression d'un utilisateur permet de manière flagrante de savoir si la machine Windows fait appel ou non à un contrôleur de domaine pour s'authentifier. Dès qu'un contôleur de domaine est en marche, tous les problèmes d'incohérence concernant les utilisateurs disparaissent. Si on les éteint puis que l'on supprime ou que l'on ajoute des utilisateurs, la machine reste autonome et conserve ses anciennes données pour l'authentification. D'où une impossibilité de se connecter alors qu'un utilisateur existe et inversement. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 16/30

17 Le BDC a bien pris le relai du PDC tombé en panne... Mais lors de la reprise de celui-ci, que se passe-t-il? - Le PDC est toujours éteint et le BDC allumé - Création d'un utilisateur sous LDAP - On peut se connecter avec l'utilisateur, mais pas de scripts netlogon (ce qui correspond bien à notre BDC) - Démarrage du PDC - On peut se connecter avec l'utilisateur, avec scripts netlogon, le PDC a bien pris le dessus sur notre BDC La présence ou non de scripts netlogon nous permet de savoir ici quel est le DC qui nous a authentifié. Ceci est valable dans notre cas car seul le PDC possède le partage netlogon... En cas de panique, si rien ne fonctionne, n'oubliez pas que les logs sont une source d'information très importante (d'après notre configuration dans /var/log/samba), n'hésitez pas à les consulter! Les tests que je vous présente ici permettent de se faire rapidement une idée de ce qui se passe mais ne remplacent pas les informations détaillées contenues dans ces précieux fichiers!!! Pensez également à vous assurer que les SID de domaines sont bien synchronisés entre le PDC et le BDC avec la commande smbpasswd -S -r MARTYMAC-PDC (à exécuter sur le BDC), si ce n'est pas le cas, vous risquez de vous arracher les cheveux, le BDC refusant de prendre le relai du PDC, mais recevant quand même la demande de la machine Windows... attendez vous à des heures de recherche! VIII) La gestion des ACLs Cette partie est assez généraliste et peut concerner indifféremment le PDC, le BDC ou les deux...! A vous de voir, selon vos besoins... Dans mon cas, les deux serveurs en ont bénéficié! Les ACLs offrent une grande souplesse dans la gestion des droits des utilisateurs. Alors que les droits POSIX (droits GNU/Linux standards) définissent une liste de 3 acteurs : User/Group/Others (utilisateur/groupe/tous les autres) intéragissant avec le système de fichier, les ACLs permettent d'en ajouter à son gré parmi la liste des utilisateurs/groupes existants. On ne va pas revenir sur le débat "ACLs vs POSIX", mais sachez qu'il est vrai que l'on peut gérer des droits très fins en ayant pour sa disposition les droits POSIX (en jouant avec la création de groupes), comme il est vrai que cela peut être au prix d'une perte certaine de vos attributs capillaires! Intégrer les ACLs se fait à trois niveaux : au niveau du système de fichier, tout d'abord, ensuite à celui de l'environnement, enfin au niveau de Samba. Nous allons procéder par étapes pour obtenir, au final, un environnement plus proche d'un domaine NT classique. a) Les ACLs au niveau du système de fichier Il convient tout d'abord de bien choisir son système de fichier. Il faut qu'il supporte les ACLs, évidemment. Parmi les systèmes de fichiers, nous avons à notre disposition XFS, EXT2 (patch kernel), EXT3 (patch kernel)... Pour ma part, j'ai choisi d'utiliser XFS, car c'est le seul à supporter les ACLs en natif et il offre de très bonnes performances. Il faut généralement recompiler le noyau de la ditribution GNU/Linux pour bénéficier du support d'un nouveau système de fichier et des ACLs, je vous passe les détails de cette opération, ceci étant une autre histoire... Note : Les ACLs pour XFS ont été oubliées pour le noyau de la Mandrake 9.1, cf. : Une fois votre noyau recompilé et votre machine redémarrée, vous allez pouvoir créer une nouvelle partition utilisant votre nouveau système de fichiers. Utilisez pour ceci fdisk et newfs. Attention aux pertes de données... C'est sur cette nouvelle partition que vous devrez placer tous vos partages Samba qui bénéficieront ainsi des ACLs. b) Les ACLs au niveau de l'environnement Il faut ensuite que les binaires utilisés "quotidiennement" supportent les ACLs et que notre machine soit prête à compiler des applications supportant les acls, il faut donc encore installer quelques packages... libacl1, libacl1-dev, acl, libattr1, libattr1-dev, attr, libxfs1, xfslibs-dev, xfsdump et xfsprogs. En utilisant apt, cela se fait très rapidement. Une fois tout ceci effectué (noyau, packages...), nous allons tester si le FS supporte les acls : - touch document.txt - setfacl -m u:utilisateur:rw document.txt (il faut évidemment que l'utilisateur 'utilisateur' existe) - getfacl document.txt Si vous n'avez pas eu de message d'erreur comme 'Operation not supported' lors du setfacl et si vous retrouvez bien votre ACL lors du getfacl, c'est que tout est correctement installé et fonctionne, passons maintenant à la partie Samba... Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 17/30

18 c) Les ACLs au niveau de Samba Votre FS supporte les ACLs, votre système aussi... Il reste à demander à Samba de les gérer... Si vous avez compilé Samba avec les options décrites dans ce document, vous avez intégré les ACLs. Sinon, il faut recommencer... L'option intéressante ici est '--with-acl-support'. La deuxième (et dernière chose) à effectuer pour le support des ACLs sous Samba est de mettre 'nt acl support' à 'Yes' dans la section [global] ou celle du partage dans le fichier smb.conf. Notez que cette option est par défaut à Yes, mais par souci de propreté, mieux vaut la spécifier... Déplacez enfin tous vos partages sur la(les) partition(s) nouvellement créées supportant les ACLs. d) Tests et limites Notez que les ACLs GNU/Linux sont bien moins efficaces que celles proposées par NTFS. Nous serons donc limités dans le choix des droits que nous pourrons attribuer (mais les droits NTFS étendus sont-ils bien utiles?). Je ne vais pas détailler toutes les procédures de tests, elles sont relativement simples. Vous pouvez, pour vous faire rapidement une idée du bon fonctionnement de votre configuration, créer deux utilisateurs et vous amuser à changer leurs droits. J'ai effectué pour ma part quelques tests plus approfondis et ai remarqué quelques détails : - Les ACLs se limitent aux droits POSIX seulement (rwx) - Seul le propriétaire peut modifier les droits du fichier - Les refus explicites ne sont pas gérés - Si un utilisateur n'a pas le droit d'écriture sur un fichier, il peut tout de même en changer le nom ou le supprimer (!!!) - Comme d'habitude, les droits de l'utilisateur prévalent sur les droits du groupe IX) La réplication LDAP (Serveur 4, ldap2.martymac.com) Prise de relai si Pdc en panne BDC [homes] [profiles] PDC [netlogon] Utilisateur Windows XP Gestion Failover Annuaire Ldap Maître Annuaire Ldap Esclave Réplication Un second annuaire LDAP prend le relai si le premier tombé en panne On remarque une chose importante dans notre architecture : la gestion du failover se fait au niveau des PDC/BDC : si le PDC tombe en panne, le BDC prend correctement le relai. Cependant, que se passe-t-il si c'est le serveur LDAP qui tombe en panne? Là se situe un gros problème : nous n'avons plus accès à notre base d'utilisateurs, personne ne peut plus s'authentifier... Nous allons voir comment mettre en place un système de réplication qui permettrait la redondance d'information en cas de panne du serveur LDAP. La mise en place d'un tel système est très simple : le serveur maître va se mettre à l'écoute de chaque modification apportée à la base et les renvoyer au serveur LDAP esclave qui mettra la sienne à jour, afin de la garder "up-to-date". Ceci se fait grâce au démon slurpd, côté maître : c'est lui qui se connectera au démon slapd de l'escalve pour mettre la base de ce dernier à jour. Je passe l'installation d'openldap côté esclave, elle se fait de la même manière que pour le serveur maître... Passons directement à sa configuration! Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 18/30

19 a) Configuration côté maître (Serveur 1, ldap1.martymac.com) Il suffit de déclarer le réplica, le nouveau serveur que nous appellerons ldap2.martymac.com et le fichier "replog" dans lequel les changements à la base seront répertoriés. Ce fichier sera lu par slurpd qui se connectera au serveur LDAP esclave pour modifier sa base. Modification du fichier slapd.conf de ldap1.martymac.com : pidfile argsfile database suffix rootdn rootpw directory /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/samba.schema /var/run/slapd.pid /var/run/slapd.args ldbm "dc=martymac,dc=com" "cn=manager,dc=martymac,dc=com" secret /var/lib/ldap index objectclass,rid,uid,uidnumber,gidnumber,memberuid eq index cn,mail,surname,givenname eq,subinitial replogfile /var/lib/ldap/replog replica host=ldap2.martymac.com:389 binddn="cn=manager,dc=martymac,dc=com" bindmethod=simple credentials="secret" b) Configuration côté esclave (Serveur 4, ldap2.martymac.com) Déclaration du DN autorisé à répliquer sa base et du serveur maître auquel se reporter en cas de demande de modification des données. Ceci se fait via le fichier slapd.conf du serveur esclave ldap2.martymac.com : pidfile argsfile database suffix rootdn rootpw directory /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/samba.schema /var/run/slapd.pid /var/run/slapd.args ldbm "dc=martymac,dc=com" "cn=manager,dc=martymac,dc=com" secret /var/lib/ldap index objectclass,rid,uid,uidnumber,gidnumber,memberuid eq index cn,mail,surname,givenname eq,subinitial updatedn "cn=manager,dc=martymac,dc=com" updateref "ldap://ldap1.martymac.com" Note : Pour des raisons de clarté, nous avons utilisé ici le rootdn du serveur esclave pour effectuer les mises à jour, mais il est normalement conseillé d'utiliser un autre dn créé spécialement pour l'opération, disposant de droits spéciaux. (Cf. Il reste à démarrer les démons slapd et slurpd sur le serveur maître et le démon slapd sur le serveur esclave. Les deux serveurs sont désormais prêts à se répliquer. Cependant, comment interroger l'un ou l'autre en fonction de leur état de fonctionnement? Nous allons avoir besoin d'un mécanisme de failover... Le mécanisme d'ip virtuelle peut facilement s'en charger, approfondissons un peu le sujet après quelques remarques... Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 19/30

20 c) Remarques Les explications ci-dessus sont valables pour une base vierge, car slurpd n'envoie au serveur LDAP esclave que les modifications apportées à la base. Si votre base contient déjà des informations, suivez cette manipulation sur le serveur maître : - Dumpez la base dans un fichier : ldapsearch -b 'dc=martymac,dc=com' -xh ldap1.martymac.com > dump.ldiff - Supprimez dans ce fichier les quelques lignes de fin contenant les informations globales sur la recherche - Eteignez slapd et slurpd - "Backupez" vos fichiers de base situeés dans /var/lib/ldap : tar cvzf /tmp/ldap.back.tgz /var/lib/ldap - Supprimez les fichiers de la base : rm -rf /var/lib/ldap/* - Démarrez les démons slapd et slurpd - Enfin, insérez le contenu du fichier de dump : ldapadd -W -D 'cn=manager,dc=martymac,dc=com' -xh localhost -f dump.ldiff - Vous devriez retrouver votre base initiale sur le serveur maître ET sur le serveur esclave qui aura reçu les mises à jour. Note : Nous avons ici dumpé la base avec ldap-search, mais il est également possible d'utiliser slapcat, ou de simplement copier les fichiers de données situés dans /var/lib/ldap. d) Tolérance de panne (failover) 1) La théorie Nous avons vu comment implémenter des serveurs LDAP redondants, mais comment faire pour interroger l'un ou l'autre en fonction de leur état? Avoir des serveurs disposant des même informations mais ne pas pouvoir interroger le serveur B si le serveur A tombe en panne ne serait d'aucune utilité : il faut mettre en place un système de tolérance de panne. La méthode que nous allons étudier est très simple : elle consiste à passer par une addresse IP virtuelle. Chaque serveur LDAP possède sa propre adresse IP, mais en possède aussi une seconde qui sera commune à tous les serveurs redondants (un "alias"). Les serveurs demeurent acessibles via leur "vraie" adresse IP, mais le sont désormais aussi par leur nouvelle adresse. Côté client (Samba), nous interrogerons la base LDAP via l'adresse IP virtuelle commune (et non la "vraie" adresse). Le passage d'un serveur à l'autre se fera par une modification de la table de routage du poste client, ceci de manière totalement transparente pour l'application : si le premier serveur tombe en panne, les données sont immédiatement redirigées vers le second. Nous abordons là la partie la plus difficile du sujet : la détection de la panne et la remontée d'information. Ceci peut se faire via un protocole de routage mais nous nous contenterons ici d'un script qui testera en permanence l'état des serveurs et qui modifiera la table de routage, méthode simple à mettre en place et facilement contrôlable. Il existe bien d'autres méthodes de tolérance de panne, notamment NAT (Network Address Translation) ou le routage dynamique (via l'utilisation d'un protocole de routage), mais elles impliquent souvent un matériel intermédiaire (routeur ou ordinateur). Le principe général reste cependant le même que celui que nous allons appliquer ici : rendre la panne transparente au client par un mécanisme de sélection du chemin. La solution que nous avons choisie est peu onéreuse : aucun matériel supplémentaire n'est nécessaire ; elle n'est cependant pas conseillée dans un environnement de production! Quelques concepts : - Il faut forcer le client à consulter sa table de routage pour sélectionner le chemin que les packets doivent prendre. En d'autres termes, l'adresse IP virtuelle ne doit pas être sur le même (sous-)réseau IP que le client. En effet, si le serveur distant est sur le même (sous-)réseau que le client, les packets pourront être acheminés sans passer par une "machine" tierce (routeur, mais en fait notre vraie IP), ce qui, dans notre cas, ne nous intéresse pas. Pour sélectionner notre chemin, nous allons donc indiquer au client que l'adresse IP virtuelle (non joignale) peut être contactée en utilisant une passerelle qui n'est autre que la "vraie" adresse IP du serveur LDAP à contacter. Celui-ci se chargera de la transmission des packets à son interface virtuelle. Voilà comment nous allons sélectionner nous même le "bon" serveur LDAP. - L'utilisation de nos serveurs LDAP comme gateways implique aussi que leurs vraies IP soient dans le même (sous-) réseau IP que le client. Ganaël Laplanche - Mise en place d'un domaine Samba LDAP - Page 20/30