Lorsqu'on parle contrôleur de domaine sous linux, on peut facilement se perdre dans la jungle Samba composée de solutions multiples et variées. Un bon choix professionnel reste le couple OpenLDAP / Samba, le seul à pouvoir faire de la réplication entre serveurs, adaptée aux grandes organisations, et qui reste relativement bien interopérable.

Cet article a pour but la mise en oeuvre d'un samba utilisant un backend OpenLDAP, le tout sécurisé par l'utilisation de TLS / SSL et facilement administrable par Webmin. Les tests ont été effectués sur CentOS 5.3 / 5.4 & 5.5. Bonne lecture.

NB: si vous effectuez cette opération sous Hyper-V, toutes les combinaisons de touches avec ALT-GR ne fonctionneront pas ce qui peut être génant concernant l'usage du caractère pipe qui se fera avec la combinaison ALT + 124.

NB: Badministrateur.com ne saurait être tenu responsable des éventuelles intoxications au café et destructions d'ordinateurs pouvant résulter de la lecture de ce tutoriel. Une pause est recommandée toutes les deux heures, et ne vous dégonflez pas.

Préconfiguration

 

Comme toujours, nous allons commencer par mettre à jour notre serveur:

$ yum update

Bien que cette technique ancestrale nous vient du monde Microsoft, un petit redémarrage s'impose pour profiter du nouveau kernel qui vient probablement d'être mis à jour:

$ shutdown -r now

L'étape de préparation la plus importante concerne la configuration du réseau. Notamment avec l'usage de SSL, il devient indispensable de faire coïncider le nom d'hôte avec celui de votre certificat de sécurité.

Cherchez le fichier suivant et modifiez le nom d'hôte en fonction de votre configuration (ex: monserveur.domaine.local). Pour ce howto, j'utiliserai le nom d'hôte fictif suivant: serveurdc.badministrateur.com

$ nano /etc/sysconfig/network

NETWORKING=yes

NETWORKING_IPV6=no

HOSTNAME=serveurdc.badministrateur.com

Nous allons également configurer une adresse IP fixe (remplaçez eth0 par le nom de votre interface, comme par ex seth0 dans le cas d'une installation Hyper-V avec les outils d'intégration)

$ nano /etc/sysconfig/networking/devices/ifcfg-eth0

DEVICE=eth0

BOOTPROTO=none

HWADDR=xx:xx:xx:xx:xx:xx

ONBOOT=yes

NETMASK=255.255.255.0

IPADDR=192.168.1.254

GATEWAY=192.168.1.1

TYPE=Ethernet

N'oubliez pas de configurer les resolutions DNS

$ nano /etc/resolv.conf

search badministrateur.com

nameserver 192.168.1.1

nameserver 80.10.246.130

Enfin il faut configurer le fichier hosts afin que le serveur puisse resoudre lui même son adresse

$ nano /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 serveurdc.badministrateur.com serveurdc localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

Validez tous ces changements en redémarrant le réseau

$ service network restart

Un petit

$ hostname

devrait retourner le nouveau nom de la machine comme dans notre exemple

serveurdc.badministrateur.com

Ne vous inquiétez pas si le nom d'hôte kernel (celui de la ligne de commande) n'a pas changé, il sera renouvelé au prochain redémarrage.

Installation

Une fois le réseau configuré correctement, nous allons procéder à l'installation proprement dite de notre serveur. Il existe quelques scripts nommées smbldap-tools développés à l'origine par IDEALX qui permettent de créer facilement le squelette d'une organisation LDAP compatible Microsoft. Malheureusement, ils ne sont pas intégrés d'office avec RedHat / CentOS, mais nous les téléchargerons par l'intermédiaire d'un dépôt nommé EPEL (Extra Packages for Enterprise Linux) faisant partie du projet Fedora.

Pour CentOS 5.3

$ cd /root

$ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

$ rpm -ivh ./epel-release-5-3.noarch.rpm

$ yum install smbldap-tools

 

Pour CentOS 5.4 et 5.5

$ cd/root

$ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

$ rpm -ivh ./epel-release-5-4.noarch.rpm

$ yum install smbldap-tools

Nous allons évidemment installer notre serveur OpenLDAP

$ yum install openldap-servers openldap-clients

Préparation du certificat SSL

Pour sécuriser les accès à notre annuaire OpenLDAP, nous allons utiliser SSL. Pour cela, il nous faudra un certificat de sécurité. Evidemment il sera toujours conseillé de passer par une autorité de certification (CA), mais l'utilisation d'un certificat autosigné reste possible. Cet article proposera les deux solutions:

 

En utilisant une autorité de certification:

Créons un dossier contenant les certificats et clés de chiffrement

$ mkdir /root/ldapssl

Puis demandons à openssl de générer une clé de sécurité RSA (1024bits, ou 2048bits si votre autorité de certification vous l'autorise)

$ openssl genrsa -out /root/ldapssl/servcert.key 1024

Enfin créons une demande de certificat (CSR) à partir de la clé.

Attention: lors du remplissage des champs demandés par openssl, veillez à mettre le FQDN de votre serveur (dans cet exemple serveurdc.badministrateur.com) dans le champ CN (common name) à défaut de quoi votre installation ne fonctionnera pas correctement.

$ openssl req -new -key /root/ldapssl/servcert.key -out /root/ldapssl/servcert.csr

Votre CA devrait vous retourner un certificat que nous renommerons en /root/ldapssl/servcert.crt

N'oubliez pas de récupérer le certificat intermédiaire de votre CA si celle-ci n'est pas une autorité racine et le copier dans /root/ldapssl/cacert.pem

Nous allons créer une chaine de certification incluant le certificat intermédiaire et le certificat qui vous a été délivré:

$ cat /root/ldapssl/cacert.pem > /root/ldapssl/servcert-chain.crt

$ cat /root/ldapssl/servcert.crt >> /root/ldapssl/servcert-chain.crt

 

En utilisant un certificat autosigné:

Créons un dossier contenant les certificats et clés de chiffrement

$ mkdir /root/ldapssl

Puis demandons à openssl de générer une clé de sécurité RSA

$ openssl genrsa -out /root/ldapssl/servcert.key 2048

Enfin créons un certificat autosigné (valable 3 ans dans l'exemple) à partir de notre clé:

$ openssl req -new -x509 -key /root/ldapssl/servcert.key -out /root/ldapssl/servcert.crt -days 1095

Attention: lors du remplissage des champs demandés par openssl, veillez à mettre le FQDN de votre serveur (dans cet exemple serveurdc.badministrateur.com) dans le champ CN (common name) à défaut de quoi votre installation ne fonctionnera pas correctement.

 

Dans les deux cas:

$ cp /root/ldapssl/servcert.key /etc/openldap/cacerts

$ cp /root/ldapssl/servcert.crt /etc/openldap/cacerts

Si vous avez utilisé une autorité de certification veuillez également copier les fichiers suivants

$ cp /root/ldapssl/servcert-chain.crt /etc/openldap/cacerts

$ cp /root/ldapssl/cacert.pem /etc/openldap/cacerts

 

N'oubliez pas de sécuriser l'accès à la clé privée et au certificat:

$ chown -R ldap /etc/openldap/cacerts

$ chmod -R 500 /etc/openldap/cacerts

 

Un petit mot sur la différence entre SSL et TLS

Par abus de language, nous faisons souvent un amalgame entre les protocoles SSL (Secure Socket Layer) et TLS (Transport Layer Security). Bien que TLS soit l'héritier direct d'SSL, il implémente un mode de fonctionnement différent dans lequel le chiffrement de la connexion intervient après connexion par demande du client.

Exemple avec le protocole LDAP:

Protocole LDAP

	LDAP Standard	LDAP / SSL (LDAPS)	LDAP / TLS
Port	389	636	389
Sécurité	Aucune	A l'établissement de la connexion	Après connexion avec start_tls

L'utilisation de TLS étant préferrée à celle de SSL pour des raisons de sécurité, les utilitaires de configuration automatisés sous linux proposeront exclusivement la configuration de TLS.

Néanmoins pour des raisons d'éducation, les deux modèles de sécurisation seront proposés durant ce tutoriel.

Lisez attentivement les commentaires des fichiers de configuration qui indiqueront quels paramètres correspondent à quel système de chiffrement.

 

Configuration de OpenLDAP

Une base de données LDAP utilise un schéma de nommage identifié par des domain components (dc) refletant souvent le protocole DNS (exemple badministrateur.com devient dc=badministrateur,dc=local). Les branches de la base sont la plupart du temps des unités organisationnelles (ou), et les éléments sont représentés par des user identifier (uid) pour les utilisateurs ou des common name (cn) pour les utilisateurs et objets. L'utilisation commune de ces valeurs pour nommer un objet se nomme le distinguished name (dn).

Exemple: le dn d'un utilisateur dans 'unité organisationnelle personnel de la base badministrateur:

dn: uid=Utilisateur,ou=Personnel,dc=badministrateur,dc=local

Afin que OpenLDAP puisse heberger une base de données de type Samba, il faut importer le schéma type d'une organisation Samba.

$ cp /usr/share/doc/samba-3.0.33/LDAP/samba.schema /etc/openldap/schema

Nous allons également créer une copie de sécurité du fichier de configuration du serveur OpenLDAP.

$ cp /etc/openldap/slapd.conf /etc/openldap/slapd.conf.original

Enfin, éditons le fichier de configuration

$ nano /etc/openldap/slapd.conf

Après les lignes include présentes, ajoutez la ligne suivante

include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Le schéma samba est obligatoire. Le schéma misc est optionnel mais permettra l'utilisation d'attributs supplémentaires comme les adresses e-mail ce qui peut être pratique dans le cas de l'utilisation d'un serveur de messagerie.

Cherchez les lignes suffix et rootdn et remplacez par les vos valeurs.

suffix est la base de recherche LDAP soit dans notre exemple dc=badministrateur,dc=local

rootdn: il s'agit du distinguished name du super utilisateur de la base de données LDAP (qui a tous les droits de lecture / écriture).

suffix "dc=badministrateur,dc=local"

rootdn "cn=Manager,dc=badministrateur,dc=local"

Enfin nous allons revenir en ligne de commandes pour créer le mot de passe associé au rootdn. Pour cela, tapez: 

$ slappasswd

Cette commande génère un hash crypté du mot de passe que vous entrez. Copiez ce hash dans le fichier /etc/openldap/slapd.conf à la ligne rootpw:

rootpw {SSHA}N0nZ3z1N3sTp4sUnM0td3P4553

Si vous utilisez une autorité de certification pour votre certificat SSL, éditez les lignes suivantes comme suit:

TLSCACertificateFile /etc/openldap/cacerts/cacert.pem

TLSCertificateFile /etc/openldap/cacerts/servcert.crt

TLSCertificateKeyFile /etc/openldap/cacerts/servcert.key

Sinon et si vous utilisez un certificat autosigné, éditez les lignes suivantes comme suit:

TLSCACertificateFile /etc/openldap/cacerts/servcert.crt

TLSCertificateFile /etc/openldap/cacerts/servcert.crt

TLSCertificateKeyFile /etc/openldap/cacerts/servcert.key

Enfin nous allons créer des règles d'accès (ACL) pour contrôler l'accès aux attributs de mot de passe de la base de données. Toujours dans le fichier /etc/openldap/slapd.conf ajoutez les lignes suivantes:

access to attrs=userPassword
by dn="cn=Manager,dc=badministrateur,dc=local" write
by self write
by anonymous auth
by * none

access to attrs=sambaLMPassword,sambaNTPassword
by dn="cn=Manager,dc=badministrateur,dc=local" write
by self write
by anonymous auth
by * none

access to *
by dn="cn=Manager,dc=badministrateur,dc=local" write
by * read
 

Les lignes en rouge sont optionnelles et seront utilisés dans le cas d'une réplication maitre / esclave.

Afin d'obtenir de meilleures performances, nous allons demander au moteur LDAP d'indexer quelques attributs utilisées par Samba.

index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq

A présent notre fichier /etc/openldap/slapd.conf devrait convenir pour un contrôleur de domaine.

A moins d'être un expert en la matière, nous allons garder la configuration par défaut du moteur de base de données LDAP et donc copier le fichier tout prêt. Il serait évidemment judicieux de l'ajuster selon la taille de votre organisation (voir article).

$ cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Le dossier /var/lib/ldap ne doit être accessible et modifiable qu'a l'utilisateur ldap. Par défaut il appartient à root donc OpenLDAP ne saura pas écrire de modifications dans ce fichier.

$ chown -R ldap /var/lib/ldap

$ chmod -R 700 /var/lib/ldap

Nous sommes maintenant prêts à démarrer pour la première fois notre serveur LDAP:

$ service ldap start

En cas de problèmes, nous pouvons commencer par tester l'exactitude du fichier de configuration avec la commande:

$ slaptest

Si tout s'est bien passé, nous allons tenter d'interroger notre base LDAP

$ ldapsearch -x -D "cn=Manager,dc=badministrateur,dc=local" -W

qui devrait retourner ceci:

# extended LDIF

#

# LDAPv3

# base <> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

 

# search result

search: 2

result: 32 No such object

 

# numResponses: 1

 

S'il s'agit d'un premier contrôleur de domaine (le maître), il nous faudra initialiser la base de données avec comme minimum d'informations le nom de l'organisation, et un compte d'administration. OpenLDAP comme la plupart des serveurs d'annuaires (y compris Active Directory) lit et écrit le format LDIF. Il s'agit de la version texte brut de la base de données.

Nous allons donc créer un fichier nommé badmin.ldif vierge et y insérer les lignes suivantes:

 

dn: dc=badministrateur,dc=local

objectclass: dcObject

objectclass: organization

o: Le site de Badministrateur

dc: badministrateur

 

dn: cn=Manager,dc=badministrateur,dc=local

objectclass: organizationalRole

cn: Manager

 

Ce fichier est en fait un dump d'une base de données LDAP au format LDIF. Nous allons donc l'importer dans notre base vierge à l'aide de la commande suivante:

$ ldapadd -x -D "cn=Manager,dc=badministrateur,dc=com" -W -f badmin.ldif

La commande nous demandera le mot de passe que nous avons encrypté dans le fichier slapd.conf, puis nous informera que deux entrées ont été ajoutées à la base de données.

Nous pourrons vérifier en utilisant la commande

$ slapcat

qui retournera l'intégralité de la base de données, y compris les mots de passe, même lorsque le serveur n'est pas lancé.

Ou alors la commande

$ ldapsearch -x -D "cn=Manager,dc=badministrateur,dc=local" -W

qui renvoie l'intégralité de la base LDAP en utilisant le serveur.

NB: La commande slapcat permet de faire des sauvegardes complètes de la base de données LDIF. Il est fortement conseillé de procéder à des sauvegardes régulières comme indiqué dans l'article Sauvegardes et restauration d'une base LDAP sous Linux.

Si tout va bien, pensez à ajouter le serveur ldap aux services qui démarrent de manière automatique

$ chkconfig --level 345 ldap on

 

Configuration du client LDAP

Nous allons à présent configurer le client LDAP de l'ordinateur. Pour cela, éditions le fichier suivant:

 

$ nano /etc/openldap/ldap.conf

Il faudra indiquer l'URI de notre serveur. Le port LDAP par défaut est le 389. Cependant, lors de l'utilisation de TLS, ce port devient 636. Notre fichier devrait ressembler à ceci:

 

# LDAP Defaults

#

 

# See ldap.conf(5) for details

# This file should be world readable but not world writable.

 

#BASE dc=example, dc=com

#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

 

#SIZELIMIT 12

#TIMELIMIT 15

#DEREF never

Utilisation de SSL

URI ldaps://serveurdc.badministrateur.com:636

BASE dc=badministrateur,dc=local

TLS_CACERTDIR /etc/openldap/cacerts

Utilisation de TLS

 

URI ldap://serveurdc.badministrateur.com

BASE dc=badministrateur,dc=local

TLS_CACERTDIR /etc/openldap/cacerts

 

Configuration de Samba

Pour commencer, nous allons créer une copie de sauvegarde du fichier de configuration samba:

 

$ cp /etc/samba/smb.conf /etc/samba/smb.conf.original

Puis nous allons changer la configuration samba:

$ nano /etc/samba/smb.conf

 

Voici ce à quoi doit ressembler un fichier smb.conf OpenLDAP

Toutes les lignes importantes sont commentées

            

[global]

# Nom du domaine au format NETBIOS
 workgroup = BADMIN

# Nom de votre serveur (%h = hostname)
server string = %h

netbios name = SERVEUR

# Interfaces sur lesquelles Samba écoute et plages d'IP sur lesquelles Samba repond
interfaces = lo eth0 192.168.1.254/24
hosts allow = 127. 192.168.1.

# fichiers Log Samba (taille max 50Ko)
log file = /var/log/samba/%m.log
max log size = 50
#log level = 2

security = user

 

##################### Choisir le modèle de chiffrement en commentant / décommentant

########## LDAP / SSL

# URI du serveur LDAP (LDAPS pour SSL) 

# passdb backend = ldapsam:ldaps://serveurdc.badministrateur.com:636

########## LDAP / TLS

ldap ssl = start tls

passdb backend = ldapsam:ldap://serveurdc.badministrateur.com

 

# Données de base pour LDAP

ldap admin dn = "cn=Manager,dc=badministrateur,dc=local"
ldap suffix = dc=badministrateur,dc=local
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap machine suffix = ou=Computers

ldap passwd sync = yes
encrypt passwords = yes

 

# Chemin d'accès aux scripts smbldap (%u = nom d'utilisateur, %g = nom du groupe)
add user script = /usr/sbin/smbldap-useradd -m "%u"
delete user script = /usr/sbin/smbldap-userdel "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
 

# Chemin d'accès aux profils itinérants (éffacer la ligne si vous ne souhaitez pas utiliser de profils itinérants)

# Dans l'exemple \\SERVEURDC\profiles\utilisateur

logon path = \\%L\profiles\%U

# Dossier personnel de l'utilisateur connecté par défaut en tant que lecteur réseau H:
logon drive = H:

# Chemin d'accès au dossier personnel de l'utilisateur
logon home = \\%L\%U

# Script logon (dans \\SERVEURDC\netlogon)
logon script = logon.bat

 

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

wins support = no
#name resolve order = wins lmhosts hosts bcast
#dns proxy = yes

# Compatibilité avec Windows
case sensitive = no
default case = lower
preserve case = yes
short preserve case = Yes

#client code page = 850
#character set = ISO8859-1
 

# Définit ce serveur comme maitre explorateur

domain master = yes
domain logons = yes
local master = yes
os level = 65
preferred master = yes
 

# Options du serveur d'impression

load printers = yes
cups options = raw
 

# Permet le comportement standard d'un serveur de fichiers Windows (utilisateur anonyme)

map to guest = Bad User

# Compatibilité DOS
map read only = yes
store dos attributes = yes
 

# Partage contenant le script de login

[netlogon]
path = /home/netlogon
writable = no
browseable = no
write list = Administrateur, root, badministrateur
 

# Partage des dossiers personnels des utilisateurs

[homes]
comment = Dossiers Personnels
browseable = no
writable = yes
 valid users = %U, BADMIN\%U
 

# Partage des profils utilisateurs

[profiles]
comment = Profils itinerants
path = /home/profiles
browseable = no
writable = yes
 valid users = %U, BADMIN\%U
hide files = /desktop.ini/ntuser.ini/NTUSER.*/Connect.log
create mask = 0700
directory mask = 0700
 

# Imprimantes CUPS

[printers]
comment = Imprimantes
path = /var/spool/samba
browseable = no
guest ok = no
writable = no
printable = yes
 

# Dossier accessible par tout le monde en écriture

[public]
comment = Dossier public
path = /home/data/public
public = yes
writable = yes
printable = no
 

# Dossier exemple accessible uniquement par le groupe root, l'utilisateur badministrateur et le groupe hardrockers

[dossier]
comment = Dossier

path = /home/data/secretariat
public = no
browseable = yes
writable = no
 valid users = +root, badministrateur, +hardrockers
 write list = +root, badministrateur, +hardrockers

 

Attention: Ne pas nommer le Workgroup (le nom de domaine) comme la deuxième partie du FQDN de votre machine.

Attention: S'il s'agit d'un contrôleur de domaine esclave, le Workgroup doit être le même que le maître.

 

Nous allons maintenant donner à Samba le mot de passe LDAP correspondant à l'utilisateur cn=Manager,dc=badministrateur,dc=local avec la commande suivante:

 

$ smbpasswd -W

qui stockera ce mot de passe dans le fichier /etc/samba/secrets.tdb

 

Configuration des smbldap-tools

Les smbldap-tools sont une collection de scripts faisant le lien entre OpenLDAP et Samba, permettant de créer les unités d'organisation principales, les utilisateurs spéciaux comme les administrateurs du domaine, et de manipuler les comptes d'utilisateurs, de machines et les groupes.

Afin de pouvoir correctement créer les entrées Samba, il va falloir obtenir l'identificateur du domaine comme suite

$ net getlocalsid

Copiez le résultat. Nous allons maintenant configurer les smbldap-tools. Editons le fichier /etc/smbldap-tools/smbldap.conf

Décommentez la ligne

#SID="S-1-5-21-2252255531-4061614174-2474224977"

et remplacez le SID par celui obtenu avec la dernière commande.

Décommentez également la ligne 

#sambaDomain="DOMSMB"

et remplaçez par votre nom de domaine samba que vous avez indiqué dans votre fichier smb.conf (valeur workgroup)

La configuration suivante établira les liens avec les serveurs Samba maitres et esclaves. Dans le cas d'un serveur unique, vous pouvez omettre de configurer les paramètres SLAVE.

 

Configuration dans le cas d'une connexion SSL

 

# Slave LDAP server
# Ex: slaveLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
slaveLDAP="127.0.0.1"

# Slave LDAP port
# If not defined, parameter is set to "389"
slavePort="636"

# Master LDAP server: needed for write operations
# Ex: masterLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
masterLDAP="serveurdc.badministrateur.com"

# Master LDAP port
# If not defined, parameter is set to "389"
masterPort="636"

# Use TLS for LDAP
# If set to 1, this option will use start_tls for connection
# (you should also used the port 389)
# If not defined, parameter is set to "1"
ldapSSL="1"

ldapTLS="0"

 

Configuration dans le cas d'une connexion TLS

 

# Slave LDAP server
# Ex: slaveLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
slaveLDAP="127.0.0.1"

# Slave LDAP port
# If not defined, parameter is set to "389"
slavePort="389"

# Master LDAP server: needed for write operations
# Ex: masterLDAP=127.0.0.1
# If not defined, parameter is set to "127.0.0.1"
masterLDAP="serveurdc.badministrateur.com"

# Master LDAP port
# If not defined, parameter is set to "389"
masterPort="389"

# Use TLS for LDAP
# If set to 1, this option will use start_tls for connection
# (you should also used the port 389)
# If not defined, parameter is set to "1"
ldapSSL="0"

ldapTLS="1"

 

 

Configuration commune

# How to verify the server's certificate (none, optional or require)
# see "man Net::LDAP" in start_tls section for more details
verify="none"

# CA certificate
# see "man Net::LDAP" in start_tls section for more details
cafile="/etc/openldap/cacerts/cacert.crt"

# certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientcert="/etc/openldap/cacerts/servcert.crt"

# key certificate to use to connect to the ldap server
# see "man Net::LDAP" in start_tls section for more details
clientkey="/etc/openldap/cacerts/servcert.key"

suffix="dc=badministrateur,dc=com"

userSmbHome="\\SERVEUR\%U"

userProfile="\\SERVEUR\profiles\%U"

 

Attention: Si smbldap-tools retourne Could not start_tls alors alors vous devriez probablement désactiver TLS et utiliser SSL comme suit : ldapSSL=''1'' et ldapTLS=''0''

 

Enfin il faudra également éditer le fichier /etc/smbldap-tools/smbldap_bind.conf

 

slaveDN="cn=Manager,dc=badministrateur,dc=com"

slavePw="secret"

masterDN="cn=Manager,dc=badministrateur,dc=com"

masterPw="secret"

 

ou "secret" est le mot de passe en clair que vous avez utilisé pour le fichier slapd.conf

Enfin changez les droits sur ces fichiers:

$ chmod 644 /etc/smbldap-tools/smbldap.conf

$ chmod 600 /etc/smbldap-tools/smbldap_bind.conf

 

S'il s'agit d'un premier serveur maitre, il va falloir initialiser la base de données LDAP avec les structures de base grâce aux scripts smbldap:

$ smbldap-populate

Si tout a bien marché, vous devriez obtenir deux utilisateurs (root et nobody) avec la commande

$ net sam list users

 

Si cette commande ne marche pas, verifiez sans la présence de SELinux en tapant

$ sestatus

Et si SELinux est activé, tenter de le désactiver

$ setenforce 0

puis reéssayez.

Tentez également une connexion directe au serveur samba en tant que root

$ smbclient -L localhost -U DOMAINE\root

 

Si tout s'est bien passé, nous allons pouvoir créer l'arboresence des dossiers mentionnés dans smb.conf

Le dossier netlogon contiendra le script éxécuté à l'ouverture de session d'un utilisateur

$ mkdir /home/netlogon

Le dossier profiles contiendra les profils itinérants d'un utilisateur

$ mkdir /home/profiles

Le dossier public sera accessible par tout le monde en écriture

$ mkdir /home/public

 

$ chown root:"Domain Users" /home/netlogon /home/profiles /home/public

$ chmod 770 /home/netlogon

$ chmod 710 /home/profiles

$ chmod 777 /home/public

 

Nous pouvons maintenant verifier que samba est correctement configuré avec la commande

$ testparm

Si testparm signale que le fichier smb.conf est bien structuré, alons nous allons démarrer samba:

$ service smb start

Enfin il ne faut pas oublier d'activer Samba au démarrage grâce à la commande

$ chkconfig --level 345 smb on

 

L'authentification

Une fois tout opérationnel, il sera judicieux de configurer l'authentification du système en utilisant LDAP. Si cette procédure n'est pas obligatoire, elle permettra d'unifier les utilisateurs samba avec ceux du système unix.

L'utilisateur final n'aurait donc plus qu'un seul couple login / mot de passe et pour son client windows, et pour d'éventuels services ftp / et ou mail.

Voici la ligne de commande permettant de mettre en place l'authentification LDAP:

$ authconfig --enableshadow --enablemd5 --enableldap --enableldapauth --ldapserver=ldap://serveurdc.badministrateur.com --ldapbasedn=dc=badministrateur,dc=local --enableldaptls –updateall –probe

 

Malheureusement, durant tous mes tests avec CentOS 5.3 / 5.4 et 5.5, cette commande n'a pas marché pour moi et j'ai été obligé de me rabattre sur la version GUI de cette commande (allez, on sauve l'honneur, ce n'est pas tout à fait la GUI vu que nous restons en mode console)

$ setup

La configuration de l'authentification reécrit le fichier /etc/nsswitch.conf et /etc/ldap.conf sur lequel s'appuyent les applications PAM-awares. Malheureusement l'ecriture automatique du fichier /etc/ldap.conf pose quelques problèmes:

- L'authentification SSL ne fonctionne pas correctement (TLS fonctionne)

- Les comptes machines windows sont assimilés à des comptes utilisateur sous windows, il faut les ajouter

A défaut de configurer correctement les comptes machines (ou=Computers,dc=badministrateur,dc=local), vous recevrez ce genre de message lors de la jonction de domaine:

UNE ERREUR S EST PRODUITE LORS DE LA TENTATIVE DE JONCTION AU DOMAINE BADMINISTRATEUR.COM LE NOM D'UTILISATEUR EST INTROUVABLE

Nous allons donc modifier le fichier /etc/ldap.conf (nss_ldap.conf pour certaines distributions).

Ouvrez le fichier /etc/ldap.conf et changez l'occurence de la ligne base en:

 

base dc=badministrateur,dc=local

De même pour la ligne suivante:

nss_base_passwd ou=People,dc=exemple,dc=local?one

changez dc=domaine,dc=example par dc=badministrateur,dc=local puis faites de meme pour les lignes nss_base_shadow et nss_base_group

 

Il faut également rajouter deux lignes nss_base_passwd et nss_base_shadow qui précisent de chercher dans l'OU Computers.

 

Le résultat final devrait ressembler à ceci

 

nss_base_passwd ou=People,dc=badministrateur,dc=local?one

nss_base_passwd ou=Computers,dc=badministrateur,dc=local?one

nss_base_shadow ou=People,dc=badministrateur,dc=local?one

nss_base_shadow ou=Computers,dc=badministrateur,dc=local?one

nss_base_group ou=Group,dc=badministrateur,dc=local?one

N'oubliez pas de décommenter ces lignes.

Afin d'etre authentifié en tant que cn=Manager,dc=badministrateur,dc=local lors de l'utilisation des commandes ldap*, nous allons décommenter la ligne rootbinddn et mettre à jour par notre superutilisateur:

rootbinddn cn=Manager,dc=badministrateur,dc=local

Enfin placez-vous à la fin du fichier et écrivez les lignes suivantes:

 

#### Utilisation de SSL

# uri ldaps://serveurdc.badministrateur.com:636

# ssl on

#### Utilisation de TLS

uri ldap://serveurdc.badministrateur.com

ssl start_tls

#### Chemins d'accès aux certificats

tls_cacert /etc/openldap/cacerts/cacert.pem

tls_cacertdir /etc/openldap/cacerts

tls_cacertfile /etc/openldap/cacerts/servcert.crt

pam_password md5

Enfin il faudra enregistrer le mot de passe maitre LDAP nécéssaire pour que la directive rootbinddn connaisse le mot de passe associé.

$ echo MOTDEPASSELDAP > /etc/ldap.secret

chmod 600 /etc/ldap.secret

 

Votre serveur est maintenant prêt à l'utilisation.

Attention: le service de cache d'authentification provoque des ralentissements au niveau des requêtes faisant appel aux entitées LDAP, notamment si vous faites un ls -l sur un dossier contenant des fichiers appartenant à un utilisateur ou groupe LDAP. Afin de ne pas perturber l'usage du serveur, pensez à desactiver le service nscd.

---

 

Synchronisation d'un serveur secondaire

 

Nous allons cependant penser plus loin et synchroniser ce serveur vers un serveur de secours. RedHat / CentOS 5.x sont fournis avec OpenLDAP 2.3.x permettant la réplication en lecture seule vers un et unique serveur secondaire. Nous allons donc utiliser cette architecture Maitre / Esclave. Si cependant vous souhaitez, une réplication multi-maitres, il va falloir passer à OpenLDAP 2.4.x qui ne fait pas officiellement parti des distributions RedHat / CentOS et ne fait donc pas parti de l'objectif de ce manuel.

L'architecture d'un serveur Maitre et d'un serveur Esclave se ressemble particulièrement beaucoup, à quelques exceptions près.

Il suffira donc de reproduire ce tutoriel afin de créer un serveur esclave, tout en modifiant certaines options des fichiers /etc/openldap/slapd.conf des ordinateurs maître et esclaves.

Evidemment, s'agissant d'une réplication de la base de données LDAP, celle-ci ne devra pas être initialisée par l'outil smbldap-populate.

Enfin pour des raisons évidentes, il faudra faire coincider le SID du domaine entre le serveur Maitre et le serveur Esclave.

Une fois votre fichier /etc/samba/smb.conf configuré comme vu dans ce tutoriel, il faudra remplacer le SID crée sur l'ordinateur esclave par celui de l'ordinateur maitre:

Sur l'ordinateur maître:

$ net getlocalsid

Sur l'ordinateur esclave:

$ net setlocalsid SID_RECUPERE_SUR_MAITRE

 

Il faudra également créer un utilisateur ayant tout droit de lecture sur la base de données OpenLDAP afin de procédér à la réplication:

$ smbldap-useradd SyncMaster

et lui attribuer un mot de passe

$ smbldap-passwd SyncMaster

 

 

Voici les modifications à apporter sur les fichiers /etc/openldap/slapd.conf

Pour le serveur Maitre, ajouter les lignes suivantes:

 

overlay syncprov

syncprov-checkpoint 1 10

syncprov-sessionlog 100

 

Le paramètre syncprov-checkpoint indique de faire une mise à jour des attributs de réplication (contextCSN) toutes les 1 opérations ou toutes les 10 minutes.

Le paremètre syncprov-sessionlog spécifie qu'il faut maintenir un journal des modifications avec l'attribut (entryUUID).

Pour des raisons de performances, nous allons également ajouter ces valeurs à l'indexation:

 

index entryCSN, entryUUID eq

Enfin il va falloir modifier les droits d'accès (ACL) aux attributs de la base de données (en vert les nouvelles valeurs):

access to attrs=userPassword
by dn="cn=Manager,dc=badministrateur,dc=local" write

by dn="uid=SyncMaster,ou=People,dc=badministrateur,dc=local" read

by self write
by anonymous auth
by * none

access to attrs=sambaLMPassword,sambaNTPassword
by dn="cn=Manager,dc=badministrateur,dc=local" write

by dn="uid=SyncMaster,ou=People,dc=badministrateur,dc=local" read
by self write
by anonymous auth
by * none

access to *
by dn="cn=Manager,dc=badministrateur,dc=local" write

by dn="uid=SyncMaster,ou=People,dc=badministrateur,dc=local" read
by * read

 

Sur le serveur Esclave, ajouter les lignes suivantes:

syncrepl rid=123
 provider=ldap://serveurdc.badministrateur.com:389
 type=refreshAndPersist
 interval=00:00:15:00
 searchbase="dc=badministrateur,dc=local"
filter="(objectClass=organizationalPerson)"
scope=sub
 attrs="*"
schemachecking=off
bindmethod=simple
 binddn="uid=SyncMaster,ou=People,dc=badministrateur,dc=local"
 credentials=MotDePasseSyncMaster

Le numéro RID à trois chiffres correspond à un numéro de client réplication unique. Dans notre cas n'importe quelle combinaison à 3 chiffres sera la bonne.

Le provider est evidemment l'URI LDAP de notre serveur maitre.

Le type de rafraichissement peut être refreshAndPersist qui établit une connexion permanente, ou alors refreshOnly qui va permettre une connexion tous les x minutes.

Interval sera l'intervalle entre deux connexions de type refreshOnly.

binndn sera le distinguished name de l'utilisateur utilisé pour lire la base de données LDAP du maitre (qui aura été autorisé à lire l'intégralité de la base par ACL).

credentials sera le mot de passe de l'utilisateur de la synchronisation.

 

Nous allons également rectifier les entrées SLAVE des fichiers /etc/smbldap-tools/smbldap.conf et /etc/smbldap-tools/smbldap_bind.conf des serveurs maitres et esclaves:

$ nano /etc/smbldap-tools/smbldap.conf

slaveLDAP="serveurbak.badministrateur.com"

slavePort="389" / slavePort="636"

$ nano /etc/smbldap-tools/smbldap_bind.conf

############################
# Credential Configuration #
############################
# Notes: you can specify two differents configuration if you use a
# master ldap for writing access and a slave ldap server for reading access
# By default, we will use the same DN (so it will work for standard Samba
# release)
slaveDN="cn=Manager,dc=badministrateur,dc=local"
slavePw="MotDePasseLDAP"
masterDN="cn=Manager,dc=badministrateur,dc=local"
masterPw="MotDePasseLDAP"

 

Gestion des utilisateurs par GUI - Webmin

 

Les scripts smbldap-tools sont éfficaces mais peu adaptés à un administrateur novice ou un responsable informatique devent gérér les utilisateurs et les groupes.

Nous allons donc configurer le plugin LDAP Users and Groups du célébre Webmin afin de rendre celui-ci compatible avec notre serveur LDAP / Samba.

 

Commençons par installer Webmin si ce n'est déjà fait. Entre la première et la dernière révision de ce tutoriel, j'ai eu l'occasion de mettre en oeuvre cette configuration avec Webmin 1.480 et 1.520.

 

$ cd /root

$ wget http://prdownloads.sourceforge.net/webadmin/webmin-1.520-1.noarch.rpm 

rpm -ivh webmin-1.520-1.noarch.rpm

Pensez à configurer votre parefeu pour laisser entrer les connexions sur le port 10000 puis rendez-vous à l'adresse https://serveurdc.badministrateur.com:10000

L'erreur de certificat est normale, vous aurez tout le loisir de changer celui-ci par notre certificat SSL par la suite.

Dans le ménu de gauche, séléctionnez Servers puis LDAP Server. Dans me module qui vient de s'afficher, séléctionnez Module Config. Dans le champ Password for LDAP Server entrez votre mot de passe Manager LDAP.

En effet Webmin ne sait décrypter le mot de passe du fichier /etc/openldap/slapd.conf, il faut donc lui indiquer. Ce module sera votre plus grand ami dans la recherche d'eventuelles erreurs de base, et la modification fine des utilisateurs.

 

Toujours dans le ménu de gauche séléctionnez LDAP Users and Groups et allez dans Module Config. Ce module est le module principal pour ajouter / modifier / supprimer les utilisateurs et les groupes. Cependant, il faut le configurer de manière adéquate à notre organisation Samba. Si vous avez bien configuré votre fichier /etc/ldap.conf avec le paramètre rootbinddn et le fichier /etc/ldap.secret, alors Webmin saura en lire les informations d'authentification nécéssaires. Voici les paramètres à modifier:

Propriété	Valeur à entrer
Other objectClasses to add to new users	top organizationalPerson inetOrgPerson
Other objectClasses to add to new groups	top
LDAP properties for all new users	sambaLogonScript: logon.bat sambaProfilePath: \\SERVEUR\profiles\${USER} sambaHomePath: \\SERVEUR\${USER} sambaHomeDrive: H: givenName: ${USER}
LDAP object class for Samba users	sambaSamAccount (Samba3)
Domain SID for Samba 3	(SID récupéré par la commande net getlocalsid)

Enfin il va falloir configurer quelques options dans le module Users and Groups du ménu System. Rendez-vous dans la partie Module Config et parametrez les valeurs suivantes:

Propriété	Valeur à entrer
Permissions on new home directories	700
Lowest UID for new users	1000
Lowest GID for new users	1000

Bien que le fait de restreindre les droits sur les dossiers home ne soit pas obligatoire, elle est tout de même très conseillée.

Concernant les userID et les groupID, Microsoft ne permet pas l'utilisation de valeurs en dessous de 1000.

Néanmoins je vous conseille de configurer également les droits d'accès aux des nouveaux répertoires personnels à 0700 ainsi que la complexité des mots de passe.

Voila, vous pouvez désormais gérer les utilisateurs et groupes Samba à partir de Webmin.

 

Si vous n'êtes pas encore au stade de la dépression nerveuse, voici quelques autres articles décrivant le serveur ultime:

 

Le serveur ultime sous Redhat / CentOS 5.x : les droits étendues, ACL

Le serveur ultime sous Redhat / CentOS 5.x : la gestion du parefeu

Le serveur ultime sous Redhat / CentOS 5.x: la solution softraid avec mdadm

Le serveur ultime sous Redhat / CentOS 5.x : Un serveur ftp sécurisé avec vsftpd

 

A bientôt.

[Edit 09/11/10] Correction d'une petite erreur (extension key à la place de pem) pour la demande de certificat