Memoire stage d'application Mastere SIO 2003

Compte tenu de la mise en place d’un agent E-Sentry (cf. annexe ‎4.3 - ), le serveur Apache installé est le serveur fourni sur le CD-ROM d’installation du logiciel E-Sentry. La procédure d’installation consiste à :

8.2.8.B - Serveur Samba :

L’installation d’un serveur Samba (version 2.2.3a-12) permettant l’authentification via les modules PAM sur un serveur LDAP en mode sécurisé s’effectue de la manière suivante :

Le fichier de configuration du serveur Samba est constitué du fichier « /etc/samba/smb.conf ». Le fichier de configuration du serveur Colombe est donné ci-dessous :

# Emplacement : Maquette de test SGA

# Description : Fichier de configuration du serveur Samba

# Serveur : Colombe

# Copyright : marc.boget@gendarmerie.org

# Definition des parametres globaux au serveur

[global]

# Definition du domaine d'appartenance

workgroup = MAQUETTE

# chaine affichée dans le voisinage reseau comme description du serveur

server string = Serveur %h (Samba %v)

# Definition des utilisateurs n'ayant pas le droit de se connecter sur

# SAMBA

invalid users = root

# Definition des logs

log file = /var/log/samba/log.%m

max log size = 1000

syslog only = yes

# Definition du niveau de logs dans syslog

syslog = 0

# Security = share :

# Lorsque le mode de sécurité activé est share, un client doit

# s'authentifier séparément pour chaque share auquel il veut se

# connecter. Il va envoyer au moins un mot de passe avec chaque demande

# de connection. Il n'envoit pas de nom d'utilisateur parce qu'il

# s'attend à ce que le serveur aie un mot de passe associé à chaque share.

# C'est exactement le comportement standard de Windows95 et Windows98.

# Lorsque l'on partage un répertoire avec l'un d'eux, on peut y

# associer un mot de passe, identique pour toute personne voulant se

# connecter à ce répertoire.

# Le probleme est que Samba utilise le système d'authentification Unix,

# où une paire mot de passe / nom d'utilisateur est validée et non une

# paire mot de passe / nom de partage. Donc Samba doit être capable de

# trouvé quel nom d'utilisateur Unix est associé avec le mot de passe

# qu'il à reçu du client.

# La façon suivie par Samba pour trouver un nom d'utilisateur

# permettant de vérifier le mot de passe reçu est la suivante :

# Etape 0 : Si le service possède le paramètre guest only = yes,

# alors les étapes 1 à 5 sont ignorées et l'on passe

# directement à l'étape 6.

# Etape 1 : Si le client à quant même fourni une paire nom

# d'utilisateur/mot de passe et que cette paire est

# validée par le système d'authentification des mots de

# passe de Unix ou en vérifiant la liste des mots de

# passe encryptés (smbpasswd) alors la connection est

# faite avec ce nom d'utilisateur. Notez que ceci inclut

# la méthode \\serveur\partage%nom pour passer un nom

# d'utilisateur.

# Etape 2 : Si le client avait enregistré précédement un nom

# d'utilisateur et qu'il produit un mot de passe correct

# pour ce nom alors la connection est permise.

# Etape 3 : Le nom NetBIOS du client ainsi que tous les nom

# d'utilisateur utilisés précédement sont vérifiés avec

# le mot de passe fourni.

# Si le mot de passe correspond à l'un d'entre eux, alors

# la connection est autorisée à l'aide de l'utilisateur

# correspondant.

# Etape 4 : Si le client avait précédement validé une paire mot de

# passe/nom d'utilisateur avec le serveur et que le

# client fournit le jeton de validation correspondant,

# alors ce nom d'utilisateur est utilisé. Cette étape est

# ignorée si le paramètre revalidate = yes est utilisé

# avec ce service.

# Etape 5 : Si un paramètre user = ... est utilisé dans la

# définition du service et que le client fournit un mot

# de passe, et que ce mot de passe correspond (d'après la

# vérification de mot de passe du système Unix) avec un

# des noms d'utilisateur donnés au paramètre user, alors

# la connection est faites en utilisant ce nom

# d'utilisateur.

# Etape 6 : Si le service est marqué guest ok = yes ou/et guest

# only = yes (service anonyme), alors la connection est

# faite à l'aide de l'utilisateur donné au paramètre

# guest account = ... dans la configuration globale ou

# pour ce service, sans s'occuper du mot de passe fourni.

# Une conséquence directe de ce mode de sécurité est que

# vous n'êtes pas obligé de créer un utilisateur Unix

# pour chaque utilisateur Windows susceptible de se

# connecter au serveur Samba.

# Security = user : valeur par defaut du parametre

# Ce mode de sécurité est beaucoup plus simple que le précédent. Quans

# le serveur dit au client qu'il fonctionne en mode de sécurité

# utilisateur, alors le client envoit tout d'abord une commande

# contenant un nom d'utilisateur et un mot de passe. A ce moment de la

# connection, le serveur n'a aucune idée du service que le client veut

# accéder. Donc il doit baser sa procédure d'authentification

# uniquement sur ces deux éléments, le mot de passe et le nom

# d'utilisateur ou le nom de machine.

# Une fois que l'accès a été autorisé au client, alors celui-ci peut se

# connecter à n'importe quel partage sans pour autant devoir réenvoyer

# une nouvelle fois le mot de passe. Avec Windows NT, vous pouvez

# envoyer plus d'une paire mot de passe/nom d'utilisateur : vous devez

# remplir le champ "Connection en tant que :" présent dans chaque boîte

# de dialogue pour établir une connection réseau, alors vous pouvez

# envoyer une deuxième paire de mot de # passe / nom d'utilisateur.

# Pour valider la paire nom d'utilisateur / mot de passe, Samba va

# utiliser les mecanismes standard d'authentification de Unix

# (/etc/passwd, /etc/shadow ou n'importe quel autre système

# d'authentification activé sur votre serveur). Si vous exécutez Samba

# en mode mot de passe encryptés (encrypt password = yes), alors il va

# utiliser le fichier smbpasswd pour vérifier le nom d'utilisateur et

# le mot de passe, mais vous avez toujours besoin d'un compte Unix

# valide identique au nom d'utilisateur Windows. Ceci, pour permettre

# l'accès au système de fichier de Unix au client.

# Security = server :

# Lorsque le mode de sécurité est serveur, Samba continue malgré tout à

# dire aux clients qu'il fonctionne en mode utilisateur. Le client se

# connecte donc au serveur de la même façon qu'expliqué précédement

# (avec un mot de passe et # un nom d'utilisateur). La seule différence

# réside dans la façon de valider la paire mot de passe / nom

# d'utilisateur.

# Pour valider la connection, le serveur Samba va utiliser le nom

# d'utilisateur et le mot de passe pour se connecter à un serveur

# différent, appelé le serveur de mot de passe. Si la connection vers

# se serveur est réussie, alors le client est autorisé à ce connecté à

# Samba.

# Le serveur de mots de passe doit être une autre machine SMB qui

# fonctionne en mode de sécurité utilisateur. Il peut donc être un

# autre serveur Samba, un serveur Windows NT ou tout autre

# implementation du protocol SMB comme Pathworks, LanManager, ... Le

# serveur auquel Samba doit se connecter (le serveur de mots de passe)

# est défini à l'aide du paramètre global password server. Ce paramètre

# prendra comme valeur soit le nom NetBIOS du serveur, soit son adresse

# IP.

# Security = domain :

# Le mode de sécurité domaine est très similaire au mode de sécurité

# serveur.

# La différence réside dans les mécanismes utilisés pour valider le mot

# de passe et le nom d'utilisateur avec le serveur de mot de passe.

# Dans ce cas, Samba va utiliser plainement toutes les capacités

# offertes par un domaine NT.

# Le serveur Samba va donc se comporter comme tout autre serveur NT ou

# Windows 9x en participant aux relations de confiances (trust

# relationships) du domaine.

# Le serveur de mot de passe que l'on spécifie à l'aide du paramètre

# password server est donc le contrôleur du domaine et/ou ses backups.

# Un avantage de ce genre d'authentification est que Samba ne doit plus

# maintenir une connection vers le serveur faisant la validation des

# mots de passe plus longtemps que le temps nécessaire à cette

# validation. Ce n'était pas le cas en mode de sécurité serveur où la

# connection avec le serveur de mots de passe restait ouverte tant que

# l'instance du daemon smbd qui l'a ouverte reste active (autrement

# dit, tant que le client reste connecté à Samba). Ce qui pouvait

# conduire à un épuisement des ressources (licenses surtout) sur le

# serveur de mots de passe lorsque celui-ci est un NT.

# Permet a Samba d'utiliser les mots de passe cryptés : c'est indispensable !

encrypt passwords = true

; include = /home/samba/etc/smb.conf.%m

# Lorsqu'elle démarre, une machine SMB (Windows 9x, NT, Samba,

# LanManager, Pathworks, ... ) va tout d'abord annoncer sa présence sur

# le réseau. Si la machine connait l'adresse d'un serveur WINS, il va

# également s'enregistrer chez lui. En situation normale, cette annonce

# par diffusion (broadcast) est uniquement limitée au sous-réseau dans

# lequel elle est placée. Dans ce sous-réseau, on trouvera une machine

# appelée EML (Explorateur maître local - Local Master Browser). Cette

# machine, qui peut être un PC Windows 9x, NT, Samba, va recevoir

# toutes les annonces pour son sous-réseau et construire une liste

# comprenant toutes les machines qui se sont annoncées. Alors cette

# liste peut être exportée à toutes les machines du sous-réseau pour

# leur permettre de construire le contenu de la fenêtre Voisinage

# Réseau. Si, pour un sous-réseau donné, vous avez plus d'un groupe de

# travail, alors vous aurez un EML par groupe. Chacun d'entre eux

# exportera vers les autres EML sa propre liste.

# Pour construire la liste de toutes les machines du réseau, il en faut

# une et une seule qui doit recevoir les listes de chaques EML en vue

# de les concaténer en une liste complète qui sera à son tour exportée

# vers tous les EML. Cette machine, unique par groupe de travail ou

# domaine, est appelée le EMD (Explorateur Maître de Domaine - Domain

# Master Browser). Pour trouver le EMD, qui étant unique n'est pas

# forcément sur le même segment que le EML, vous avez besoin d'un

# serveur WINS (ou d'un fichier lmhosts si le EMD est aussi le

# contrôleur de domaine).

# Qui devient EML :

# Chaque machine sur le réseau à une chance de devenir le EML. Lors du

# démarrage d'une nouvelle machine, une élection à lieu pour choisir le

# EML.

# Cette élection utilise beaucoup de paramètres pour déterminer qui

# sera le EML. Samba peut-être configuré de telle sorte qu'il perdra ou

# gagnera toujours, ou que son démarrage ne forcera jamais une élection

# ou encore qu'il ne sera jamais le EML.

# Pour réaliser cela, les paramètres globaux suivants sont à definir :

# os level = <nombre> où <nombre> est une valeur comprise entre 0 et

# 255.

# Plus grande sera la valeur, plus grande sont les chances de

# Samba de gagner l'élection. Une valeur supérieure à 2 bat

# Windows for Workgroup et Windows 95. Une valeur supérieure à

# 32 bat n'importe quel NT Domaine Contrôleur.

# local master = yes | no : détermine si, oui ou non, Samba jourera

# le rôle d'un EML.

# preferred master = yes | no : détermine si, oui ou non, Samba

# forcera une élection à chaque démarrage.

; local master = yes

os level = 80

domain master = True

preferred master = False

# Indique si Samba doit jouer le role de Wins ou non

wins support = Yes

; wins server = w.x.y.z

# Si la résolution de nom NetBIOS n'est pas possible avec la base de

# données du serveur Samba/WINS, une tentative sera réalisée avec le

# serveur DNS. Cela suppose deux choses au choix :

# le nom NetBIOS des machines est identique au nom d'hôte,

# les enregistrements de ressources pour les noms d'hôtes ont des

# alias pour les noms NetBIOS.

dns proxy = no

; name resolve order = lmhosts host wins bcast

; preserve case = yes

; short preserve case = yes

# Les 3 variables suivantes permettent d'autoriser une synchronisation

# des mots de passe SMB avec ceux de la machine Unix. Attention, si

# vous désirez uniquement autoriser le changement de mot de passe SMB,

# vous n'avez pas besoin d'activer ces variables ! Un mauvais choix ici

# peut s'avérer catastrophique pour votre politique de sécurisation.

unix password sync = Yes

passwd program = /usr/sbin/gestion_ldap --pass %u

passwd chat = *ancien\smot\sde\spasse* %n\n *Retaper\sle\smot\sde\spasse* %n\n *effectue*

; pam password change = no

; message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &

# La directive suivante indique a Samba de se referer aux directives

# PAM pour gerer l'authentification des utilisateurs : c'est

# indispensable avec une authentification LDAP

obey pam restrictions = yes

; winbind uid = 10000-20000

; winbind gid = 10000-20000

; template shell = /bin/bash

# Declarations propres a SAMBA-LDAP

ldap suffix = ou=Maquette de test, o=sga

ldap admin dn= cn=admin,ou=Maquette de test,o=sga

ldap port = 389

ldap server = grandeourse.sga.def

ldap ssl = yes

add user script = /root/gestion_ldap -a -g 1000 %u

domain logons = yes

domain admin group = root Administrateur @"Administrateurs du domaine"

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# Definition des partages

[homes]

comment = Repertoire utilisateur

browseable = No

valid users = %S

path=/home/samba/%u

read only = No

writable = yes

create mask = 0700

directory mask = 0700

[netlogon]

comment = Network Logon Service

path = /home/samba/netlogon

guest ok = yes

writable = no

share modes = no

[printers]

comment = All Printers

browseable = no

path = /tmp

printable = yes

public = no

writable = no

create mode = 0700

# Un exemple de partage mis en commentaire

;[cdrom]

; comment = Samba server's CD-ROM

; writable = no

; locking = no

; path = /cdrom

; public = yes

; preexec = /bin/mount /cdrom

; postexec = /bin/umount /cdrom

NB : le mot de passe de l’administrateur LDAP défini dans le fichier « smb.conf » doit être défini dans la base de compte Samba (« /var/lib/secrets.tdb ») à l’aide de la commande suivante :

- smbpasswd –w « mot_passe »

NB : Il est à noter que l’utilisateur autorisé à ajouter des stations au domaine Samba doit voir son champ « uid » défini à la valeur « 0 ».

8.2.8.B.1 - Support des ACL sur le serveur Colombe :

De manière à se comporter exactement comme un serveur Windows, le serveur Samba se doit d’offrir la possibilité de proposer la mise en place de permissions sur les fichiers partagés.

- La mise à jour du noyau pour pouvoir supporter le type de système de fichiers XFS (système de fichiers journalisé hautes performances développé originellement pour la plateforme SGI IRIX) ;

- La modification des sources Samba pour ajout de l’option --with-acl-support ;

8.2.8.C - Serveur SSH :

8.2.8.D - Déport des logs :

Le paramétrage du déport des logs est décrit dans le paragraphe ‎8.2.3.C - .

8.2.8.E - Authentification des utilisateurs sur l’annuaire LDAP :

Le paramétrage de l’authentification des utilisateurs sur l’annuaire GrandeOurse est décrit au paragraphe ‎8.2.6.D - .

8.2.8 - Serveur Colombe :

8.2.8.A - Serveur Apache :

8.2.8.B - Serveur Samba :

8.2.8.B.1 - Support des ACL sur le serveur Colombe :

8.2.8.C - Serveur SSH :

8.2.8.D - Déport des logs :

8.2.8.E - Authentification des utilisateurs sur l’annuaire LDAP :