Sommaire - FTP Directory Listing

Transcription

Mise en place d'un domaine Samba 2.2 avec LDAP
Ganaël LAPLANCHE - EDF R&D
V1.12, 30/04/2003 – 01-07-2003
http://www.martymac.com
Copyright (c) 2003, Ganaël LAPLANCHE - Organisation : EDF R&D
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 included in the section entitled "GNU
Free Documentation License".
Mise en place d'un domaine Samba 2.2 avec LDAP - Ganaël Laplanche - EDF R&D - http://www.martymac.com
Page 1/30
Sommaire
Avant-propos...............................................................................................................................................................3
I) Introduction.............................................................................................................................................................3
II) Etape 1 : Installation d'OpenLDAP...................................................................................................................4
III) Configuration de base et Test du serveur LDAP............................................................................................4
a) Configuration............................................................................................................................................................................................4
b) Premiers tests............................................................................................................................................................................................4
IV) Installation de Samba..........................................................................................................................................5
V) Préparation du système pour l'authentification via LDAP............................................................................6
a) Outils nécessaires/supplémentaires.........................................................................................................................................................6
b) Configuration avancée de LDAP............................................................................................................................................................6
c) Insertion de l'arborescence de base pour samba dans l'annuaire LDAP...............................................................................................7
d) Configuration des méthodes d'authentification du Système.................................................................................................................8
1) Configuration de Nsswitch.........................................................................................................................................................................................................................8
2) Configuration de Pam.................................................................................................................................................................................................................................8
3) Configuration générale des librairies libpam-ldap et libnss-ldap............................................................................................................................................................9
4) Configuration de smbldap-tools.................................................................................................................................................................................................................9
e) Premiers tests de connexion.....................................................................................................................................................................9
VI) Configuration de Samba...................................................................................................................................10
a) L'Impression............................................................................................................................................................................................10
b) Configurer Samba..................................................................................................................................................................................10
c) Revenons à l'impression.........................................................................................................................................................................11
d) Test : Joindre une machine au domaine................................................................................................................................................12
e) Test : Se connecter au domaine avec un utilisateur.............................................................................................................................12
f) Test : Imprimer........................................................................................................................................................................................13
VII) Etape 2 : Cas d'un serveur LDAP distant....................................................................................................14
VIII) Etape 3 : Mise en place d'un BDC...............................................................................................................15
a) Processus de montage du répertoire Home d'un utilisateur.................................................................................................................15
b) Configurons notre BDC.........................................................................................................................................................................15
c) Test : le BDC prend-il correctement le relai en cas de panne du PDC ?............................................................................................18
IX) Plus loin : La gestion des ACLs.......................................................................................................................18
a) Les ACLs au niveau du système de fichier..........................................................................................................................................19
b) Les ACLs au niveau de l'environnement..............................................................................................................................................19
c) Les ACLs au niveau de Samba..............................................................................................................................................................19
d) Tests et limites........................................................................................................................................................................................19
X) Etape 4 : Encore plus loin avec la réplication LDAP.....................................................................................20
a) Configuration côté maître......................................................................................................................................................................20
b) Configuration côté esclave....................................................................................................................................................................20
c) Quelques remarques...............................................................................................................................................................................21
d) Tolérance de panne (failover)................................................................................................................................................................21
1) La théorie..................................................................................................................................................................................................................................................21
2) La pratique................................................................................................................................................................................................................................................22
XI) Toujours plus loin : communication SSL avec notre serveur LDAP.........................................................23
a) TLS : Pourquoi ?.....................................................................................................................................................................................23
b) Les clefs et les certificats.......................................................................................................................................................................23
c) La pratique..............................................................................................................................................................................................23
1) Génération des clefs et du certificat........................................................................................................................................................................................................23
2) Mise en place côté serveur.......................................................................................................................................................................................................................24
3) Mise en place côté client..........................................................................................................................................................................................................................24
4) Testons notre connexion sécurisée..........................................................................................................................................................................................................25
5) Mise en place pour Samba.......................................................................................................................................................................................................................25
XII) Conclusion.........................................................................................................................................................26
XIII) Outils................................................................................................................................................................26
XIV) Liens / Bibliographie......................................................................................................................................26
XV) Remerciements.................................................................................................................................................26
XVI) Annexes............................................................................................................................................................27
A1) Exemple d'architecture avancée........................................................................................................................................................27
GNU Free Documentation License........................................................................................................................28
Page 2/30
Avant-propos
Ce document a été réalisé durant mon stage de fins 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 (http://samba.idealx.org/dist/samba-ldap-howto.pdf), 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 par rapport aux documents déjà existants pour
ceux qui sont un peu perdus. Comme tout Howto, il n'est pas exhaustif et peut contenir quelques erreurs. Il suppose également que
vous ayiez quelques connaissances de base sous Unix... Bonne lecture !
I) Introduction
Vousd 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.
Nous allons voir dans un premier temps comment installer Samba 2.2 et LDAP sur la même machine, puis, par la suite, comment
décentraliser cette architecture (cf à partir de VII).
Contexte :
Nous allons passer par 4 étapes. L'étape principale est l'étape 1 et peut se suffire à elle-même. Elle sert de base aux étapes
suivantes, plus courtes, qui complètent notre étude. Voici le programme :
Etape 1 : Installation d'un PDC et d'un serveur LDAP sur la même machine
- Plateforme de test : PIII 733 Mhz, 128Mo de Ram, Debian 3.0r1, noyau 2.4.18
- Jusqu'au chapitre VII), cette machine s'appelle redpdc.martymac.com pour se nommer par la suite blueldap.martymac.com.
- Notre domaine Windows s'appelle RED
- Le nom netbios de notre machine est RED-PDC
Etape 2 : Le PDC devient machine à part et interroge notre serveur LDAP
- Plateforme LDAP : On conserve la machine de l'étape 1, cette machine s'appelle désormais blueldap.martymac.com
- Plateforme PDC : PIII 1,2 Ghz, 256Mo de Ram., Debian 3.0r1, noyau 2.4.18, cette machine s'appelle bluepdc1.martymac.com
- Notre domaine Windows s'appelle BLUE
- Le nom netbios de notre PDC est BLUE_PDC
Etape 3 : Ajout d'un BDC à notre infrastructure
- Plateforme LDAP : On conserve la machine de l'étape 1
- Plateforme PDC : On conserve la machine de l'étape 2
- Plateforme BDC : PIII 450 Ghz, 128Mo de Ram., Mandrake 9.1, noyau 2.4.21, cette machine s'appelle bluebdc1.martymac.com
- Notre domaine Windows s'appelle BLUE
- Le nom netbios de notre PDC est BLUE_BDC
Etape 4 : Ajout d'un second serveur LDAP, réplica du premier
- Ce serveur offrira une solution de secours si le premier serveur LDAP tombe en panne
Le contexte général :
- Le binddn (compte ayant le droit d'écriture) du serveur LDAP est : 'cn=Manager,dc=martymac,dc=com' et son password : 'secret'
- La base de notre arbre LDAP est 'dc=martymac,dc=com'
Nota : Nous nous intéresserons plus à la configuration des différents services qu'à leur compilation ! C'est pour ceci que, pour une
question de facilité, nous utiliserons souvent apt qui, sous GNU/Linux Debian permet d'installer rapidement les applications
voulues... Si vous utilisez les sources des programmes, il y a de fortes chances pour que les fichiers de configuration ne se trouvent
pas au même endroit ! Un “find” sera alors le bienvenu...
Essayez de lire ce document dans sa continuité, chaque étape prépare à la suivante, puisqu'on conserve certaines configurations
précédentes.
Page 3/30
Etape 1 : Installation d'un PDC et d'un serveur LDAP sur la même machine
II) Etape 1 : Installation d'OpenLDAP
Utilisateur
Annuaire
Ldap
+
PDC
[homes]
[profiles]
[netlogon]
Loopback
Le PDC et l'annuaire LDAP ne font qu'un
Nous allons avoir besoin de plusieurs composants :
- des librairies LDAP compilées,
- des sources de ces librairies (pour des compilations futures),
- des utilitaires d'interrogation d'annuaire
- du 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...
III) Configuration de base et Test du serveur LDAP
a) Configuration
- Editer le fichier le fichier /etc/ldap/slapd.conf pour configurer OpenLDAP :
include
include
include
include
/etc/ldap/schema/core.schema
/etc/ldap/schema/cosine.schema
/etc/ldap/schema/inetorgperson.schema
/etc/ldap/schema/nis.schema
pidfile
argsfile
/usr/local/var/slapd.pid
/usr/local/var/slapd.args
database
suffix
rootdn
rootpw
directory
ldbm
"dc=martymac,dc=com"
"cn=Manager,dc=martymac,dc=com"
secret
/var/lib/ldap
index cn
eq
Nous disposons maintenant d'une configuration suffisante pour démarrer le serveur :
- /etc/init.d/ldap start, tout devrait bien se passer...
b) Premiers tests
Nous allons essayer d'insérer quelques enregistrements dans notre base LDAP, afin de voir si tout fonctionne :
- Créer un fichier test.ldiff source :
dn: dc=martymac,dc=com
objectclass: dcObject
dc: martymac
objectclass: organization
o: martymac
Page 4/30
dn: ou=personnes,dc=martymac,dc=com
objectclass: top
objectclass: organizationalUnit
ou: personnes
description: Branche personnes
Pour 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 martymac.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'
Si tout ceci fonctionne, passons à l'installation de Samba ! Nous reviendrons plus tard à LDAP...
IV) Installation de Samba
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.
- Récupérer les sources pour debian sur samba.org
(http://de.samba.org/samba/ftp/Binary_Packages/Debian/dists/stable/main/source/samba_2.2.8a-0.1.tar.gz)
- Décompresser les sources : tar xvzf samba_2.2.8a-0.1.tar.gz
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
[ -f source/Makefile ] || (cd source && ./configure \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--with-fhs \
--prefix=/usr \
--sysconfdir=/etc \
--with-privatedir=/etc/samba \
--localstatedir=/var \
--with-netatalk \
--with-smbmount \
--with-syslog \
--with-sambabook \
--with-utmp \
--with-readline \
--with-libsmbclient \
--with-winbind \
--with-msdfs \
--with-automount \
--with-acl-support \
--with-profile \
--disable-static \
--with-ldapsam)
Lignes 130/131, commenter la référence à pam :
130
131
#install -m 0644 source/nsswitch/pam_winbind.so \
#
$(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
Page 5/30
Samba est maintenant installé, nous allons maintenant pouvoir configurer LDAP de manière plus approfondie afin de pouvoir
s'authentifier sous debian via le serveur.
V) Préparation du système pour l'authentification via LDAP
a) Outils nécessaires/supplémentaires
Il faut installer plusieurs librairies et outils pour permettre l'auhtentifiation via LDAP :
Installation de nscd : Name service cache daemon, fournit un cache pour différentes requêtes de noms, accélère les requêtes.
- 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/password 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 password, 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 unix. Ceci n'est nécessaire que si l'on souhaite
pouvoir s'authentifier sur le système Unix avec les comptes LDAP. Nous allons tout de même traiter le sujet.
- apt-get install libpam-ldap
Installation de smbldap-tools : Ensemble d'outils de gestion de comptes samba sur LDAP développé par idealx
- Télécharger smbldap-tools sur idealx (http://samba.idealx.org/dist/smbldap-tools-0.7.tgz)
- 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)
Puis,
- 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 : make && make install
Nous configurerons smbldap-tools plus tard...
b) Configuration avancée de LDAP
- Copie du fichier samba.schema (provenant du répertoire examples/ des sources de samba) dans /etc/ldap/schema/
- Edition du fichier /etc/ldap/slapd.conf et inclure ce nouveau schéma (qui apporte le support des comptes samba) pour avoir ceci :
include
include
include
include
include
/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
pidfile
argsfile
/usr/local/var/slapd.pid
/usr/local/var/slapd.args
database
suffix
rootdn
rootpw
directory
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
- Edition du fichier /etc/ldap/ldap.conf, fichier servant à toutes sortes de clients utilisant LDAP, pour avoir ceci :
base dc=martymac,dc=com
host 127.0.0.1
- Redémarrage de LDAP /etc/init.d/ldap restart
Page 6/30
c) Insertion de l'arborescence de base pour samba dans l'annuaire LDAP
- Création d'un fichier base.ldiff qui contient l'arborescence de base, nous ajouterons ces données à l'annuaire LDAP :
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
ou: Users
description: Users of the Organization
dn: ou=Computers,dc=martymac,dc=com
objectClass: top
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
gidNumber: 201
cn: Domain Users
description: Windows Domain Users
dn: cn=Domain Guests,ou=Groups,dc=martymac,dc=com
gidNumber: 202
cn: Domain Guests
description: Windows Domain Guests Users
dn: cn=Administrators,ou=Groups,dc=martymac,dc=com
description: Members can fully administer the computer/domain
gidNumber: 220
cn: Administrators
description: Windows Domain Members can fully administer the computer/domain
dn: cn=Users,ou=Groups,dc=martymac,dc=com
description: Ordinary users
gidNumber: 221
cn: Users
description: Windows Domain Ordinary users
dn: cn=Guests,ou=Groups,dc=martymac,dc=com
description: Users granted guest access to the computer/domain
gidNumber: 222
cn: Guests
memberUid: nobody
description: Windows Domain Users granted guest access to the computer/domain
dn: cn=Power Users,ou=Groups,dc=martymac,dc=com
description: Members can share directories and printers
gidNumber: 223
cn: Power Users
description: Windows Domain Members can share directories and printers
dn: cn=Account Operators,ou=Groups,dc=martymac,dc=com
gidNumber: 224
cn: Account Operators
description: Windows Domain Users to manipulate users accounts
dn: cn=Server Operators,ou=Groups,dc=martymac,dc=com
gidNumber: 225
cn: Server Operators
description: Windows Domain Server Operators
Page 7/30
dn: cn=Print Operators,ou=Groups,dc=martymac,dc=com
gidNumber: 226
cn: Print Operators
description: Windows Domain Print Operators
dn: cn=Backup Operators,ou=Groups,dc=martymac,dc=com
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
description: Supports file replication in a domain
gidNumber: 228
cn: Replicator
description: Windows Domain Supports file replication in a domain
- Insertion de cet arbre dans l'annuaire LDAP : ldapadd -W -D 'cn=Manager,dc=martymac,dc=com' -f base.ldiff
LDAP est maintenant prêt à recevoir nos utilisateurs, aussi bien Unix 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 allons bientôt pouvoir nous identifier via LDAP : il reste maintenant à configurer notre système pour qu'il utilise notre serveur
pour l'authentification.
d) 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)
Copie de /usr/share/doc/libnss-ldap/examples/nsswitch.ldap vers /etc/nsswitch.conf et modification :
passwd:
group:
shadow:
files ldap
files ldap
files ldap
hosts:
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: files
netgroup: 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 !
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
Page 8/30
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
auth
auth
auth
sufficient
required
required
required
pam_ldap.so
pam_nologin.so
pam_unix.so
pam_env.so # [1]
account sufficient pam_ldap.so
account required pam_unix.so
session
session
session
session
session
session
sufficient
required
optional
optional
optional
required
pam_ldap.so
pam_unix.so
pam_lastlog.so # [1]
pam_motd.so # [1]
pam_mail.so standard noenv # [1]
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
Modification de /etc/ldap/ldap.conf (cf /usr/share/doc/libpam-ldap/examples/ldap.conf) :
BASE dc=martymac,dc=com
HOST 127.0.0.1
ldap_version 3
nss_base_passwd
nss_base_shadow
nss_base_group
dc=martymac,dc=com?sub
dc=martymac,dc=com?sub
ou=Groups,dc=martymac,dc=com?one
rootbinddn cn=Manager,dc=martymac,dc=com
pam_password md5
ssl no
- Création du fichier /etc/ldap.secret : echo "secret" > /etc/ldap.secret, contenant le mot de passe du rootbinddn pour les mises à jour
de la base.
4) 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 rfc2307 - ceci ne devait pas poser problème avec les versions
antérieures de LDAP). Il faut pour ceci modifier les smbldap-tools.
- Editer /usr/share/perl/5.6.1/smbldap-tools.pm et ajouter 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 Unix : ssh -l testuser1 localhost. Normalement, tout est Ok
(Si vous êtes confronté à un problème comme : '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 du user : ldapsearch -b 'dc=martymac,dc=com'
- Suppression du user : smbldap-userdel testuser1 et effacement de son home 'bidon' sur le disque
A ce stade, nous pouvons nous authentifier sur le système via LDAP, il nous reste à installer samba et à le configurer...
Page 9/30
VI) Configuration de Samba
a) L'Impression
- Installation de CUPS : Common Unix Printing System
(apt-get install cupsys cupsys-client cupsys-bsd cupsomatic-ppd cupsys-driver-gimpprint)
- Configuration de CUPS (édition de /etc/cups/printers.conf ou via http://localhost:631/admin)
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 un partage
samba appelé 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 cups pour voir si l'impression fonctionne.
b) Configurer Samba
- Modification du fichier /etc/samba/smb.conf :
[global]
; le nom de notre domaine
workgroup = RED
; notre nom de machine netbios
netbios name = RED-PDC
; le nom complet
server string = RED 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
; Logs
log file = /var/log/samba/%m.log
log level = 2
max log size = 5000
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
; Infos Domaine
; Win9x + NT PDC
domain logons = Yes
os level = 65
; Force election master browser + avantage :)
preferred master = Yes
; Master browser
domain master = Yes
; Participer aux election du local master browser
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 = 127.0.0.1
ldap ssl = No
; Impression
load printers = yes
printing = cups
printcap name = cups
; Prise en charge du francais
character set = iso8859-1
; Ajout de machine via smbldap-tools
add user script = /usr/local/sbin/smbldap-useradd.pl -w %u
domain admin group = " @"Domain Admins" "
Page 10/30
; Répertoire homes
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
browseable = No
; Répertoire scripts
[netlogon]
comment = Network Logon Service
path = /opt/samba/netlogon
guest ok = Yes
; Répertoire de profils
[profiles]
path = /opt/samba/profiles
writeable = yes
browseable = no
create mode = 0644
directory mode = 0755
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
; Un partage...
[tmp]
comment = Temporary file space
path = /tmp
read only = No
guest ok = Yes
; Un autre partage...
[doc]
path = /usr/share/doc
public = yes
writable = no
read only = no
create mask = 0750
guest ok = yes
- Création du répertoire /opt/samba/profiles : pour le stockage des profils
- Création du répertoire /opt/samba/netlogon : pour le stockage des scripts de connexion
- Le partage [homes] est mappé sur /home par défaut
- Changement du mot de passe de l'admin LDAP (rootdn) pour samba : smbpasswd -w secret
(création de /var/lib/samba/secrets.tdb, attention à la sécurité : fichier non chiffré !)
- Création du compte administrateur de domaine : smbldap-useradd.pl -a -m -g 200 administrator
- Mot de passe : smbldap-passwd administrator
c) Revenons à l'impression
Finissons la configuration de l'impression :
- Création du répertoire /var/spool/samba : répertoire de spool d'impression, contiendra les données en cours d'impression
- Gestion des droits sur ce répertoire : chmod 775 /var/spool/samba
- Création de /etc/samba/drivers qui contiendra nos drivers d'imprimante (partagés par print$), y copier les fichiers nécessaires
Page 11/30
Créer l'utilisateur printadmin, qui sera l'administrateur du système d'impression :
- smbldap-useradd.pl -a -m -g 226 printadmin
- smbldap-passwd.pl printadmin
d) Test : Joindre une machine au domaine
- Redémarrage de samba : /etc/init.d/samba restart
- Exécution de 'testparm' pour vérifier la configuration de samba : ok
- Test du serveur samba : 'nmblookup RED-PDC' et 'smbclient -N -L RED-PDC',
Le nom netbios est normalement trouvé et les partages affichés.
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 conseillerais 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
192.168.1.10 RED-PDC
#PRE #DOM:RED
192.168.1.10 "RED
\0x1C" #PRE
192.168.1.10 "RED
\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.
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 ceci peut poser problème dans certains cas, provocant des erreurs du côté de la machine Windows. J'ai en effet été
confronté à un problème étrange : lors de la jonction au domaine, la machine est créée automatiquement, mais une erreur survient ; il
faut alors à nouveau rejoindre le domaine avec le compte machine créé pour que tout fonctionne correctement. Si l'on veut ajouter
manuellement une machine :
- smbldap-useradd.pl -w RED-CLIENT$
Si cette commande pose problème, peut-être avez-vous oublié de modifier smbldap-tools ? (cf. plus haut)
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.
e) Test : Se connecter au domaine avec un utilisateur
Si l'on ouvre une session avec 'administrator' sur le domaine, windows ne trouve pas son profil itinérant. Il s'agit d'un problème de
droits sur le répertoire /opt/samba/profiles : le groupe de l'utilisateur administrator n'a pas le droit d'écriture sur ce répertoire. Cela ne
pose pas de problème en soi, car l'administrateur de domaine ne nécessite pas de profil itinérant.
Nous allons maintenant ajouter 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 Unix ET Windows ; si l'on veut qu'il ne puisse pas se "logger" sous Unix, il
faut préciser un home "/dev/null" et un shell "/bin/false", en le créant ainsi : smbldap-useradd.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 Unix.
Vérifier que son groupe ait bien le droit d'écriture sur /opt/samba/profiles :
- chown :Users /opt/samba/profiles
- chmod 775 /opt/samba/profiles (ce qui équivaut normalement à un chmod g+w /opt/samba/profiles)
Vérifier également qu'il n'ait pas trop de droits sur /opt/samba/netlogon :
- chmod 555 /opt/samba/profiles et chmod 400 sur chaque script du répertoire
Page 12/30
On peut désormais se "logger" avec cet utilisateur sur le domaine :)
Note : l'utilisateur 'rootadmin' peut, lui aussi, bénéficier d'un profil car il dispose de tous les droits...
f) 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.
Page 13/30
Etape 2 : Le PDC devient machine à part et interroge notre serveur LDAP
VII) Etape 2 : Cas d'un serveur LDAP distant
Utilisateur
PDC
[homes]
[profiles]
[netlogon]
Annuaire
Ldap
L'annuaire LDAP est maintenant externalisé
Nous avons vu le cas d'un serveur Samba disposant de l'annuaire LDAP localement et bouclant sur lui même. Ceci n'étant pas le but
d'un serveur LDAP (de tourner localement), oublions notre machine autonome (redpdc.martymac.com) pour la laisser en serveur
LDAP, renommons-la par la même occasion blueldap.martymac.com. Introduisons une nouvelle machine à notre réseau :
bluepdc1.martymac.com. Voici donc un résumé des étapes à suivre si l'on désire installer un PDC samba et utiliser un serveur LDAP
non plus local, mais distant. Je ne détaille pas ici les différentes étapes, elles sont identiques aux étapes décrites précédemment dans
ce document. Voici les étapes à accomplir, dans le cas d'un poste vierge, nous changeons ici le nom du domaine pour l'appeler BLUE
:
Sur la première machine (Serveur LDAP, appelé "blueldap.martymac.com") :
- Installation d'OpenLDAP (processus identique à celui déjà décrit - on peut conserver notre configuration)
Sur la deuxième machine (PDC, appelé "bluepdc1.martymac.com" - domaine : BLUE, nom netbios : BLUE_PDC) :
- Installer ldap-utils
- Installer Samba et le configurer
- Installer Smbldap-tools et les configurer
- Installer libpam-ldap (facultatif)
- Installer libnss-ldap et le configurer, ainsi que /etc/nsswitch
- Installer nscd, le démarrer
- Initialiser le password samba LDAP avec 'smbpasswd -w secret' et démarrer samba.
- Créer le user avec uid 0 et gid 0 pour l'inscription au domaine. Attention un seul utilisateur de ce type est autorisé
(à cause de l'uid ; de plus, un utilisateur ayant le gid à 0 ne peut pas joindre un domaine).
- Régler les droits sur les répertoires profiles, home et netlogon. En cas de problème lors chown/chgrp/chmod, vérifier que le système
a bien accès aux comptes LDAP. Parfois, un simple redémarrage de nscd suffit ; penser à revoir également la configuration de
nsswitch et de libnss-ldap.
Les configurations diffèrent évidemment à chaque étape au niveau des informations concernant le serveur LDAP, puisqu'il est
maintenant distant... Il est possible d'interroger l'intégralité de notre arbre LDAP (donc de tester l'accès à notre serveur) avec la
commande : ldapsearch -b 'dc=martymac,dc=com' -xh blueldap.martymac.com. Si vous avez conservé la machine de l'étape 1,
pensez à stopper Samba, afin de ne pas avoir deux PDC sur le même réseau !
Page 14/30
Etape 3 : Ajout d'un BDC à notre infrastructure
VIII) Etape 3 : Mise en place d'un BDC
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,
jusqu'alors assurée par le même poste.
Nous allons donc avoir trois serveurs distincts :
- Le serveur LDAP, qui fournira des informations sur les comptes utilisateurs,
- Le PDC, qui permettra l'authentification des utilisateurs (via des requêtes auprès du serveur LDAP) et le partage des scripts
netlogon,
- Le BDC, qui assurera deux tâches : le partage de fichiers principaux (homes, profiles) et l'authentification des utilisateurs si le PDC
tombe en panne.
Cette décentralisation permet de supprimer les points sensibles sur notre réseau, de limiter les goulets d'étranglement, et d'éviter la
synchronisation des fichiers smbpasswd entre le PDC et le BDC. Il serait même ici vivement conseillé de mettre en place un second
serveur LDAP - synchronisé avec le premier - qui prendrait le relai du premier en cas de défaillance ; mais rassurez-vous, chaque
chose en son temps, nous aborderons ce point plus loin ! Nous allons pour l'instant laisser notre serveur LDAP seul, affronter sa
destinée. Autre détail : 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)... 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. 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...
Voici un schéma récapitulatif de tout ceci ; laissons le partage netlogon au PDC.
a) Processus de montage du répertoire Home d'un utilisateur
2 bis
BDC
[homes]
[profiles]
3 bis
PDC
[netlogon]
4
1
2
3
Annuaire
Ldap
6
5
Utilisateur
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 Home)
6 : Le BDC lui fournit cet accès
b) Configurons notre BDC
La configuration du BDC se fait à peu près de la même manière que le PDC, à la différence des options d'élections présentes dans le
fichier smb.conf qu'il faut modifier. Le BDC doit, lui aussi, disposer d'un nsswitch modifié, ainsi que de la librairie libnss-ldap. La
base ldap-client (ldapsearch, ldapadd, etc...) peut être un plus, tout comme les smbldap-tools. Enfin, puisque l'un des buts du BDC
est de fournir les partages réseaux, on va pouvoir supprimer quasiment tous les partages au niveau du PDC pour ne laisser que la
section [global] et [netlogon]. En ce qui concerne l'authentification, nous n'aurons pas besoin de répliquer les comptes utilisateurs
puisqu'ils sont centralisés sur notre annuaire LDAP (qui contient les entrées normalement stockées dans le fichier smbpasswd).
Page 15/30
Notre PDC a pour nom netbios BLUE_PDC, voici sa configuration samba (/etc/samba/smb.conf) :
[global]
workgroup = BLUE
netbios name = BLUE_PDC
server string = BLUE PDC Server
; Synchro pass Unix
; Logs
log level = 2
max log size = 5000
; Domaine
; Win9x + NT PDC
domain logons = Yes
os level = 65
preferred master = Yes
; Master browser
domain master = Yes
local master = Yes
; Serveur Wins active (un seul par reseau)
wins support = Yes
security = user
; SAMBA-LDAP declarations
ldap port = 389
ldap server = blueldap.martymac.com
ldap ssl = No
; Deactivate opportunistic locks (wised)
; opLocks = False
; encoding to french
; using smbldap-tools to add machines
; Partages netlogon obligatoires en local
[netlogon]
path = /export/samba-test/netlogon
comment = Network Logon Service
guest ok = Yes
Voici la configuration de notre BDC, BLUE_BDC :
[global]
workgroup = BLUE
netbios name = BLUE_BDC
server string = BLUE BDC Server
; Synchro pass Unix
; Logs
log level = 2
max log size = 5000
; Domaine
; Win9x + NT PDC
domain logons = Yes
os level = 48
preferred master = No
Page 16/30
; Master browser
domain master = No
local master = No
; Serveur Wins active (un seul par reseau)
wins support = No
security = user
ldap port = 389
ldap ssl = No
; Deactivate opportunistic locks (wised)
; opLocks = False
; encoding to french
; using smbldap-tools to add machines
; Répertoires homes, à mapper via \\SERVEUR\utilisateur
[homes]
path=/export/samba-test/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-test/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
[doc]
path = /usr/share/doc
public = yes
writable = no
read only = no
create mask = 0750
guest ok = yes
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-test/home et /export/samba-test/profiles), ainsi que le répertoire home de chaque utilisateur :
Exemple pour l'utilisateur blueuser :
- mkdir /export/samba-test/home/blueuser
- chown blueuser:Users /export/samba-test/home/blueuser
- chmod 755 /export/samba-test/home/blueuser
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-test/profiles
- chmod 775 /export/samba-test/profiles
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 BLUE_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...
Page 17/30
c) Test : le BDC prend-il correctement le relai en cas de panne du PDC ?
Nous allons effectuer ces tests avec un client WinXP, appelé BLUEWKS (Blue Workstation).
Le problème majeur pour tester la validité de notre configuration est que notre machine Windows peut authentifier elle-mê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. Coupons
maintenant le PDC et le BDC. Normalement, nous n'avons plus de DC pour nous authentifier sur le domaine... Erreur : 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 !
Maintenant que nous savons à quoi nous en tenir, 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 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 : je vous assure que c'est bluffant) ? Voyons ceci, continuons...
- 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é ci-dessus : 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 en "solo" et
conserve ses anciennes données pour l'authentification. D'où une impossibilité de se connecter alors qu'un utilisateur existe et
inversement.
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 ? Continuons notre test...
- 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 (généralement 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 BLUE_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 (je suis passé par là...) !
IX) Plus loin : 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 bénéficient !
Les ACLs offrent une grande souplesse dans la gestion des droits des utilisateurs. Alors que les droits POSIX 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...
Page 18/30
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 bonnes performances. Il faut généralement recompiler le noyau de la
ditribution GNU/Linux pour bénéficier 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. : http://qa.mandrakesoft.com/show_bug.cgi?id=3615
b) Les ACLs au niveau de l'environnement
Il faut aussi 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/modules, 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 vous avez bien tout installé et que ça marche, passons maintenant à la partie Samba...
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 le IV) de 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) Tests et limites
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
Page 19/30
Etape 4 : Ajout d'un second serveur LDAP, réplica du premier
X) Etape 4 : Encore plus loin avec la réplication LDAP
Prise de relai si Pdc
en panne
PDC
[netlogon]
BDC
[homes]
[profiles]
Gestion
Failover
Utilisateur
Annuaire
Ldap
Maître
Réplication
Annuaire
Ldap
Esclave
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, vous devez commencer à connaître... Passons directement à la configuration !
a) Configuration côté maître
Il suffit de déclarer le réplica, un nouveau poste que nous appellerons blueldap_backup.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 :
replogfile /var/lib/ldap/replog
replica host=blueldap_backup.martymac.com:389
binddn="cn=Manager,dc=martymac,dc=com"
bindmethod=simple
credentials="secret"
b) Configuration côté esclave
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 blueldap_backup.martymac.com :
updatedn "cn=Manager,dc=martymac,dc=com"
updateref "ldap://blueldap.martymac.com"
C'est tout ce qu'il y a à faire concernant la configuration de nos serveurs LDAP. Il reste à lancer le démon slurpd sur le serveur maître
(en plus du démon slapd, évidemment...). Il faudra ajouter à ceci un mécanisme de failover (ou de partage de charges, ou les deux,
suivant les besoins) ! Un mécanisme d'IP virtuelle pourrait facilement s'en charger, approfondissons un peu le sujet après quelques
remarques...
Page 20/30
c) Quelques 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 blueldap.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' -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.
Notes :
- Il est possible d'ajouter/supprimer un enregistrement dans une base esclave, cependant, cet événement ne sera pas toujours reporté
dans la base maître. Ceci dépend de la directive updateref qui redirige les requêtes de modification vers le serveur LDAP maître.
Attention, donc, aux incohérences dans le cas d'une mauvaise configuration...
- 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 le 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 à respecter :
- 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), 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 interfaces soit dans le même sous-réseau IP que le
client.
En résumé :
Sur le PDC samba :
- Configuration de Samba et des services clients LDAP pour interroger le serveur LDAP via son adresse IP virtuelle
- Sa table de routage lui indiquera par où passer pour atteindre l'adresse IP virtuelle du serveur LDAP.
- Modification dynamique de sa table de routage, via un script, en fonction de l'état des serveurs
Sur les serveurs LDAP :
- Adresse IP dans le même sous-réseau que le client (pour servir de gateway)
- Ajout d'une interface virtuelle ayant une adresse IP commune à tous les serveurs redondants, mais appartenant à un sous-réseau
différent (pour forcer le routage)
- Réplication des données de l'annuaire
Page 21/30
2) La pratique
Script shell
Scrute l'état des serveurs
Modifie
Serveurs Ok ?
LDAP 1
(maître)
IP : 192.168.1.10/24
VIP : 192.168.2.1/24
PDC
Samba
IP : 192.168.1.5/24
Table de routage du PDC Samba :
"Pour atteindre 192.168.2.1/24,
passe par 192.168.1.10/24"
Réplication
Connexion
vers LDAP1
ou LDAP2
LDAP 2
(esclave)
IP : 192.168.1.15/24
VIP : 192.168.2.1/24
Schéma d'une connexion à l'aide d'une méthode de tolérance de panne (V.IP.)
Configuration des serveurs LDAP :
- On considère que les problèmes de réplication sont déjà réglés (cf. précédemment dans ce document).
- Ajouter une adresse IP virtuelle à chacun des répliquas : ifconfig eth0:1 192.168.2.1 netmask 255.255.255.0
Configuration du client Samba (PDC, BDC) :
- Configurer Samba et les clients LDAP (libnss, libpam, ...) pour qu'ils interrogent le serveur LDAP via l'adresse IP virtuelle.
Si vous passez par un nom de machine, ceci revient juste à changer l'adresse IP associée au nom d'hôte (au niveau du serveur DNS
ou du fichier hosts), sinon, changez l'adresse IP directement.
- Créer et exécuter le script de scrutage des serveurs qui modifiera la table de routage : voici un exemple de script :
#!/bin/sh
# Script scrutant IP1 et IP2, et modifiant la table de routage
# en fonction de l'état des machines. Necessite nmap.
# Ganaël LAPLANCHE
# IP virtuelle du groupe de serveurs
VIP="192.168.2.1"
# Interface de sortie de notre client
IFACE="eth0"
# Premier serveur
IP1="192.168.1.10"
METRIC1="0"
# Deuxième serveur
IP2=" 192.168.1.15"
METRIC2="5"
# Tests a effectuer
# Port distant
TESTPORT="389"
# Nom du service
TESTSERV="ldap"
# Protocole
TESTPROTO="tcp"
# Attente entre chaque boucle
WAIT="5"
while true; do
echo "[Test de ${IP1}]"
nmap -sT ${IP1} -p ${TESTPORT} | grep "${TESTPORT}/${TESTPROTO}[ ]*open[ ]*${TESTSERV}"> /dev/null
if [ $? -eq 0 ]; then
route add -host ${VIP} metric ${METRIC1} gw ${IP1} dev ${IFACE} > /dev/null
echo "${IP1} -- Ok : routage pour ${VIP}, metrique ${METRIC1}"
else
route del -host ${VIP} metric ${METRIC1} gw ${IP1} dev ${IFACE} > /dev/null
echo "${IP1} !Ok : stop routage"
fi
echo "[Test de ${IP2}]"
nmap -sT ${IP2} -p ${TESTPORT} | grep "${TESTPORT}/${TESTPROTO}[ ]*open[ ]*${TESTSERV}"> /dev/null
if [ $? -eq 0 ]; then
route add -host ${VIP} metric ${METRIC2} gw ${IP2} dev ${IFACE} > /dev/null
echo "${IP2} -- Ok : routage pour ${VIP}, metrique ${METRIC2}"
else
route del -host ${VIP} metric ${METRIC2} gw ${IP2} dev ${IFACE} > /dev/null
echo "${IP2} !Ok : stop routage"
fi
Page 22/30
sleep ${WAIT}
echo "-------------------------"
done
exit 0
Ce script très simple utilise nmap pour tester si le port 389 (LDAP) des serveurs est bien à l'écoute. Si c'est le cas, il inscrit les deux
routes, mais avec des métriques différentes ; celle qui a la plus petite métrique est alors utilisée. Si l'un ou l'autre des serveurs vient à
tomber en panne (réseau ou serveur LDAP), la route est supprimée, ce qui a pour effet de rendre l'autre route active : l'autre serveur
prend le relais.
XI) Toujours plus loin : communication SSL avec notre serveur LDAP
a) TLS : Pourquoi ?
Vous le savez peut-être, mais par défaut, les communications avec notre serveur LDAP se font en clair. Il suffit de "sniffer" le réseau
(non switché) pour s'en rendre compte. Une personne mal intentionnée pourrait donc intercepter toutes les informations qu'il désire, y
compris les mots de passe de nos utilisateurs (même chiffrés, ceux-ci sont précieux... On trouve de nombreux outils pour les
"casser"...) ! Une manière simple de sécuriser nos transactions est de passer par TLS (Transport Layer Security, anciennement
SSLv3.0, renommé et normalisé par l'IETF, cf. RFC2246), qui assurera le chiffrement des données.
Je ne vais pas rentrer dans les détails d'une communication via TLS, ceci dépasserait le cadre du sujet. Sachez simplement que TLS
repose sur la couche 4 (Transport) du modèle OSI, ce qui lui permet de sécuriser les communications réseau de manière transparente
pour les applications. Il repose sur l'utilisation de clefs symétriques et asymétriques, et introduit la notion de certificat délivré par un
tiers, qui assure alors l'authenticité des clefs. Je vous vois soupirer, allez, encore une dernière explication avant la pratique...
b) Les clefs et les certificats
Vous le savez sans doute, une paire de clefs est composée d'une clef privée et d'une clef publique. Elles ont la particularité d'être
inséparables, car ce que chiffre l'une, l'autre peut la déchiffrer. Voilà pourquoi on parle de clefs asymétriques. La clef privée est
destinée à être gardée précieusement par son propriétaire, alors que la clef publique pourra être diffusée. Le principe général consiste
alors à chiffrer les données avec la clef publique du destinataire afin qu'il puisse la déchiffrer avec sa clef privée et être ainsi le seul à
pouvoir comprendre le message.
Le certificat vient juste introduire la notion d'authenticité des clefs. Comment être sûr qu'une clef publique est bien celle de la
personne à qui l'on veut envoyer des données ? Le certificat nous offre une réponse : une société tierce (de confiance, une autorité de
certification : CA) va certifier que la clef publique appartient bien à cette personne. Ainsi, plus de doute, la clef est la bonne... nous
évitons ainsi de nous faire piéger par une personne qui voudrait intercepter nos données (le fameux "homme du milieu")...
c) La pratique
Nous allons implémenter TLS sur notre serveur LDAP maître. Ne vous inquiétez pas, l'implémentation de TLS ajoute juste une
commande de type STARTTLS qui permet, si on le désire, de démarrer une transaction sécurisée sur le port standard LDAP. Il
restera toujours possible de communiquer "en clair" avec notre serveur. OpenLDAP doit être compilé avec l'option --with-tls et
OpenSSL doit être installé.
Dans la pratique, la mise en place de TLS se traduit par trois étapes :
- La génération des clefs/certificats côté serveur
- La mise en place de TLS côté serveur
- La mise en place de TLS côté client
1) Génération des clefs et du certificat
Nous allons dans cette étape préparer notre serveur à l'utilisation de TLS. Il va falloir générer notre paire de clefs et faire signer notre
clef publique par une Autorité de Certification. Vous devez disposer d'OpenSSL.
Dans le répertoire /etc/ldap, créer un répertoire 'cert' qui contiendra les clefs et le certificat :
mkdir /etc/ldap/cert
Dans ce répertoire, générez la clef privée du serveur :
openssl genrsa -out serverkey.pem 1024
Puis la clef publique et la demande de certificat (dans cert.req) :
openssl req -new -key serverkey.pem -out servercert.req
Complétez correctement les informations qui vous sont demandées. Pensez à bien renseigner le CN (Common Name) par le FQDN
(nom dns) de votre serveur, celui qui sera utilisé lors de l'interrogation de la base LDAP par les clients.
Page 23/30
Pour l'étape suivante, vous avez le choix, soit vous envoyez la demande de certificat à une CA reconnue qui vous enverra le
certificat, soit vous certifiez vous-même votre clef en vous faisant passer pour une CA. Nous allons voir comment faire...
Mettons nous dans le peau d'une CA. Générez la clef privée de la CA :
openssl genrsa -out cakey.pem 1024
Puis son certificat propre (qui est alors autocertifié : on ne fait pas appel à une autre CA) :
openssl req -new -x509 -key cakey.pem -out cacert.pem -days 365
La encore, complétez correctement les champs demandés. N'oubliez pas que vous êtes la CA...
Enfin, signature par la CA de la clef publique de notre serveur :
openssl x509 -req -in servercert.req -out servercert.pem -CA cacert.pem -CAkey cakey.pem -days 365 -CAcreateserial
Suppression des fichiers temporaires :
rm *.req
rm *.srl
Suppression de la clef privée de la CA :
rm cakey.pem
Réglage des droits :
La clef privée ne doit pouvoir être lue que par root :
chown root:root serverkey.pem ; chmod 400 serverkey.pem
Voilà, vous disposez désormais des fichiers nécessaires pour mettre en place TLS sur le serveur. Nous allons voir les modifications à
apporter dans le fichier slapd.conf...
2) Mise en place côté serveur
Modifier /etc/ldap/slapd.conf et ajouter les chemins vers les différentes clefs et le certificat :
# TLS
# Chemin vers le certificat du serveur LDAP
TLSCertificateFile
/etc/ldap/cert/servercert.pem
# Chemin vers la clef privée du serveur LDAP
TLSCertificateKeyFile /etc/ldap/cert/serverkey.pem
# Chemin vers le certificat de la CA
TLSCACertificateFile /etc/ldap/cert/cacert.pem
Attention de bien ajouter ceci dans la section globale.
Si vous redémarrez votre serveur LDAP, il devrait désormais être de capable de communiquer avec TLS. Cette communication se
fera sur le port 389 (standard, port LDAP) via la commande starttls qui activera la transaction sécurisée. Attention, ceci est différent
d'une communication "purement" SSL, qui pourrait être mise en place sur le port LDAPS (636) via un tunnel SSL.
3) Mise en place côté client
Nous allons mettre en place TLS au niveau du PDC. Inspirez-vous de cet exemple pour le BDC, il s'agit de la même démarche...
La configuration des outils LDAP, de libnss-ldap et de libpam-ldap se fait, comme d'habitude, via le fichier ldap.conf. N'hésitez pas,
pour libnss-ldap et libpam-ldap, à consulter le fichier exemple fourni dans les tarball disponibles sur le site http://www.padl.com.
Pour autoriser les communications TLS, il faut modifier le fichier ldap.conf. Deux types de directives existent : les directives
OpenLDAP pures et les directives ajoutées par libpam_ldap et libnss_ldap. Elles sont supplémentaires, l'oubli de l'une ou l'autre fera
que l'application qui l'utilise ne fonctionnera pas. Ceci peut conduire à des erreurs difficiles à diagnostiquer ! Ajoutez ceci au fichier
ldap.conf du PDC :
#Directive SSL OpenSSL (pour ldapsearch notamment)
TLS_CACERT /etc/ldap/cert/cacert.pem
#Directives SSL libnss et libpam
# Activation SSL brute (port 636)
# ssl yes
# Acivation SSL via commande starttls (port standard 389)
ssl start_tls
#Verifie certificat serveur
tls_checkpeer yes
# Emplacement certificat CA
tls_cacertfile /etc/ldap/cert/cacert.pem
Le fichier 'cacert' doit être présent sur notre disque. Il s'agit du certificat de la CA. Il convient de le copier au bon endroit (ici
/etc/ldap/cert/) depuis notre serveur LDAP.
Page 24/30
4) Testons notre connexion sécurisée
Testons d'abord si les outils clients OpenLDAP fonctionnent :
ldapsearch -b 'dc=martymac,dc=com' -ZZ -xh blueldap.martymac.com
L'ajout de -ZZ force la communication en TLS. Vous devriez voir apparaître l'arborescence que nous avions déjà auparavant. Si vous
avez une erreur, vérifiez bien que le nom du serveur utilisé pour la requête est bien le nom passé dans le CN lors de la demande de
certificat du serveur !
Testons ensuite la bonne configuration de libnss-ldap : exécutons 'getent passwd' et voir si nos utilisateurs LDAP sont bien listés...
Si tout cela fonctionne, c'est déjà un bon point, cependant, est-ce bien chiffré ? Pour s'en assurer, nous allons sniffer (écouter) le
réseau avec tcpdump :
Sur le serveur LDAP, on écoute les connexions provenant de notre PDC :
tcpdump -s0 -xX ip host bluepdc1.martymac.com and host blueldap.martymac.com
Sur le BDC, on rapatrie les entrées utilisateurs avec :
getent passwd ou ldapsearch -b 'dc=martymac,dc=com' -ZZ -xh blueldap.martymac.com
Le PDC va contacter le serveur LDAP pour y lire les informations nécessaires. On voit alors plusieurs segments TCP affichés avec
tcpdump, mais rien n'est compréhensible... Si l'on réitère l'opération en commentant les lignes concernant la configurationn SSL, on
pourra distinguer les informations rapatriées par notre PDC, la preuve que le flux de données est bien chiffré !
5) Mise en place pour Samba
Le but de tout ceci étant de pouvoir intégrer TLS aux communications entre Samba et notre serveur LDAP, terminons ce chapitre en
voyant comment modifier le fichier smb.conf du PDC :
; Attention ! Comme d'habitude, il faut utiliser le nom de serveur donné en tant que CN pour le certificat
; ldap ssl = No
ldap ssl = start_tls
ldap port = 389
Il suffit de rajouter une ligne à notre configuration précédente : 'ldap ssl = start_tls'. N'oubliez également pas de préciser le port sur
lequel samba devra se connecter. Ici, le port est le port 389, puisque l'on utilisera la commande 'starttls' sur une connexion LDAP
standard. Notez qu'il s'agit du port par défaut pour une connexion de type 'starttls', mais autant le spécifier pour en être sûr. Vérifiez
enfin que le nom de serveur passé pour la directive 'ldap server' correspond bien au CN utilisé lors de la génération du certificat du
serveur LDAP ! Si vous oubliez ce petit détail, samba ne pourra pas établir la connexion TLS et votre fichier de "log" vous indiquera
: "TLS: can't connect", message qui n'est pas très explicite, vous êtes prévenus...
Pour vérifier que ceci fonctionne, "loggez" vous à partir de votre machine cliente Windows et, au choix : sniffez les connexions entre
le serveur LDAP et le PDC (cf. ci-avant), ou bien examinez le fichier de log concernant la machine cliente généré par Samba, vous
pourrez lire, si tout se passe bien : "StartTLS issued: using a TLS connection" !
N'hésitez pas à configurer tous vos clients/serveurs pour passer par TLS... Cela permet de manière simple de sécuriser (un peu) vos
communications.
Page 25/30
XII) Conclusion
Ce document touche à sa fin. J'espère qu'il vous a éclairé sur les différentes étapes à suivre pour installer et configurer Samba 2.2 +
LDAP.
Il n'a pas la vocation (ni la prétention !) d'etre exhaustif... donc si vous avez des questions, des commentaires, des informations
supplémentaires ou si vous avez remarqué des erreurs, n'hésitez pas à me contacter à [email protected] !
Merci d'avoir parcouru ce Howto et Bonne chance !
XIII) Outils
Voici une petite liste d'outils très utiles :
Outils pour administrer LDAP :
- directory-administrator, basé sur qt
- gq, basé sur gtk
Outils pour administrer samba/ldap :
- smbldap-tools d'idealx, scripts Perl permettant d'administrer en ligne de commande des comptes Samba stockés sur LDAP
- idxldapaccounts d'idealx, module permettant d'administrer, via webmin, des comptes Samba stockés sur LDAP
XIV) Liens / Bibliographie
Softs :
http://www.openldap.org
http://www.samba.org
http://www.padl.com
Utilitaires :
http://samba.idealx.org
http://webmin.idealx.org
Howtos :
http://samba.idealx.org/dist/samba-ldap-howto.pdf
http://de.samba.org/samba/docs/Samba-HOWTO-Collection.pdf
http://us3.samba.org/samba/ftp/docs/htmldocs/Samba-LDAP-HOWTO.html
http://us3.samba.org/samba/ftp/docs/htmldocs/Samba-BDC-HOWTO.html
http://www.unav.es/cti/ldap-smb/ldap-smb-2_2-howto.html
http://www.linuxmafia.com/~rick/lecture-notes/ldap
Tldp :
http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/
Livres :
Linux mag' numéro 40 (p.37) et 46 (p.32)
Liste de diffusion Samba-fr :
http://listes.ujf-grenoble.fr/wws/info/samba-fr
XV) Remerciements
Ce document a été régidé au sein d'EDF R&D à Clamart. Merci à toute l'équipe et tout particulièrement à Vincent Gayrard, David
Lacoste, et Xavier Lemesle pour leur soutien et l'aide qu'ils ont su m'apporter !
Page 26/30
XVI) Annexes
A1) Exemple d'architecture avancée
Voici un exemple d'architecture intégrant les différentes technologies que nous avons étudiées :
Ldap
Maître
Ldap
Esclave
1
Réplication
+ Tls
Wan
Pdc 3
[netlogon]
Réplication
+ Tls
Gestion
Failover
(V.IP)
Pdc 1
[netlogon]
Pdc 2
[netlogon]
Bdc 1
[homes]
[profiles]
Bdc 2
[homes]
[profiles]
Domaine 1
Ldap
Esclave
2
Réplication
+ Tls
Loopback ou distant
+ Tls
Ldap
Esclave
3
Ldap
Esclave
4
Loopback ou distant
+ Tls
Bdc 3
[homes]
[profiles]
suivant
utilisateur
Domaine 2
Site physique 1
Loopback ou distant
+ Tls
Bdc 4
[homes]
[netlogon]
suivant
utilisateur
Domaine 3
Site physique 2
Machines utilisées dans le cas des tests efectués :
PDC 1 : PIII 1.2 Ghz, 256 Mo Ram, GNU/Linux Debian 3.0r1, noyau 2.4.18
BDC 1 : PIII 450 Mhz, 128 Mo Ram, GNU/Linux Mandrake 9.1, noyau 2.4.21
PDC 2 : PIII 733 Mhz, 128 Mo Ram, SCO Linux Server 4.0, noyau 2.4.19
BDC 2 : PIII 733 Mhz, 128 Mo Ram, SCO Linux Server 4.0, noyau 2.4.19
LDAP maître : PIII 733 Mhz, 128 Mo Ram, GNU/Linux Debian 3.0r1, noyau 2.4.18
LDAP esclave 1 : Machine similaire
LDAP esclave 2 : PIII 733 Mhz, 128 Mo Ram, GNU/Linux Mandrake 9.0
PDC 3 : Même machine physique (loopback)
BDC 3 : Même machine physique (loopback)
BDC 4 : Même machine physique (loopback)
Notes :
- On distingue 3 domaines principaux. Ces domaines sont des (sous-)réseaux IP différents.
- On distingue 2 sites, reliés par une liaison WAN.
- Seul le serveur LDAP maître autorise la modification de ses données par une personne physique (binddn).
- Les autres doivent limiter l'écriture par des Acls LDAP pour n'autoriser les mises à jour que par réplication (slurpd).
- Dans le 3è domaine, les serveurs LDAP sont présents sur la même machine physique que le serveur Samba
(interrogation par loopback), mais il est tout à fait possible d'introduire une machine tierce dans chaque cas.
Page 27/30
GNU Free Documentation License
Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective
freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and
publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General
Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with
manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of
subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of
this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below,
refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work
in a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into
another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the
Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in
part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or
with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is
released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain
zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under
this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for
revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an
otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not
Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly
available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF
and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in
the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates
XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".)
To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered
to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has
no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license
notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not
use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for
copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice
requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover
Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words
of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the
title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
Page 28/30
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the
rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each
Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using publicstandard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year
after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you
with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under
precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever
possesses a copy of it. In addition, you must do these things in the Modified Version:
* A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any,
be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
* B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least
five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
* C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
* D. Preserve all the copyright notices of the Document.
* E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
* F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the
form shown in the Addendum below.
* G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
* H. Include an unaltered copy of this License.
* I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as
given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given
on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
* J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in
the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published
at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
* K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of
the contributor acknowledgements and/or dedications given therein.
* L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the
section titles.
* M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.
* N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.
* O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you
may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of
peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the
Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the
Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not
add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any
Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you
include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its
license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple
Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the
original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license
notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any
sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various
documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all
other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted
document, and follow this License in all other respects regarding verbatim copying of that document.
Page 29/30
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is
called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works
permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the
Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the
Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic
form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with
translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original
versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided
that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the
translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically
require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or
distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit
to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version"
applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by
the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free
Software Foundation.
How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title
page:
Copyright (c) YEAR YOUR NAME.
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 included in the section entitled "GNU
Free Documentation License".
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as
the GNU General Public License, to permit their use in free software.
Page 30/30

Sommaire - FTP Directory Listing

Transcription

Documents pareils

TP Java EE

à l`université du Havre

fiche de poste - cat a - L`Université Paris Descartes

LDAP SAVOIR DUREE : 2 JOURS INTRODUCTION A LDAP

Formation - AIO Solutions

ENIB - Déploiement de l`ENT

Gestion des mots de passe Gestion des photos

Cours de Samba - Association Gingando

Le RESEAU EM@ Espace Multimédia de l

LX04 : Annuaires LDAP et OpenLDAP - LibrA