administration des services réseaux: Configuration OpenLDAP sous Linux

OpenLDAP est un annuaire informatique qui fonctionne sur le modèle client/serveur (Comme AD sous windows), c'est une implémentation libre du protocole LDAP (LDAP = Lightweight Directory Access Protocol), il fonctionne avec 389/tcp. 

I- Installation et configuration de DNS : 

1- Installation des packages :
rpm -ivh --replacepkgs bind-9...
rpm -ivh --replacepkgs bind-chroot....
2- Configuration du fichier /etc/named.conf
-Création des zones : Zone directe et Zone inversé 

-Configuration des fichiers des zones
3- Configuration de fichier /etc/resolv.conf
Vim /etc/resolv.conf 

search abc.lan
nameserver 192.168.1.254 

4- Démarrage de service BIND
service named restart
 

II- Installation des packages nécessaires pour LDAP :
rpm -ivh ...
•Openldap-...
•Openldap-servers-...
•Openldap-clients-...
•Openldap-devel-...
•Cyrus-...
III- Fixer un mot de passe pour le root LDAP
slappasswd
copier : « {SSHA}.... »
IV- Editer le fichier /etc/openldap/slapd.conf 

vim /etc/openldap/slapd.conf 

suffix "dc=abc, dc=lan"
rootdn "cn=manager,dc=abc,dc=lan"
rootpw (Coller “{SSHA}...”)

V- Démarrer le service ldap
service slapd start
 

VI- Créer des utilisateurs (les informations des utilisateurs sont stocké dans un fichier .ldif (format texte clair):
useradd user1
passwd user1
grep user1 /etc/passwd
user1:x:501:501::/home/user1/:bin/bash
grep user1 /etc/passwd > users.passwd

VII- Utilisation du fichier "/usr/share/openldap/migration/migrate_passwd.p1" :
/usr/share/openldap/migration/migrate_passwd.p1 users.passwd users.ldif
On va changer le nom du domaine sur le fichier users.ldif :
vim users.ldif

dn: uid=user1,ou=People,dc=abc,dc=lan
uid: user1
cn: user1
ObjectClass: …  

VIII- Créer un autre fichier .ldif qui contient le domaine et les unités d'organisation :
vim abc.lan.ldif 

dn: dc=abc,dc=lan
dc: abc
objectClass: dcObject
objectClass: organizationalUnit
ou: rootobject

                         
dn: ou=People,dc=abc,dc=lan
ou: People
description: utilisateurs
objectClass: organizationalUnit

IX- Ajouter les informations sous les fichiers .ldif à la base de données LDAP
ldapadd -xW -D "cn=Manager,dc=abc,dc=lan" -f abc.lan.ldif
Entrer la mot de passe de ldap
ldapadd -xW -D "cn=Manager,dc=abc,dc=lan" -f users.ldif
Entrer la mot de passe de ldap

X- Partager /home avec tous les utilisateurs clients on utilisant NFS :
vim /etc/exports
 

/home 192.168.1.0/24(rw,sync) 

Taper la commande d’exportation : 

exportfs -a
 

XI- Démarrer les services nfs et portmap :
service portmap start
service nfs start
chkconfig portmap on
chkconfig nfs on
 
I- Installation des packages nécessaires pour LDAP :
rpm -ivh ...
•Openldap-...

•Openldap-clients-...
•Openldap-devel-...

II- Renommer le /home par /home.local (on va monter le /home du serveur donc il faut séparer les 2 homes)
mv /home /home.local
 

III- Créer un nouveau /home :
mkdir /home
 

IV- monter le home partagé :
mount 192.168.1.254:/home /home
 

V- Activer ldap : (on va rendre la machine membre au domaine)
 

authconfig --enableldap --enableldapauth --ldapserver=192.168.1.254 --ldapbasedn="dc=abc,dc=lan" --enablemd5 --enabeshadow
(MD5 est un algorithme de cryptage)
« On va obtenir une fenêtre bleue de configuration de l'authentification (dans cette fenêtre on va cocher : Utiliser LDAP + Utiliser les mots de passe MD5 + Utiliser les mots de passe masqués + Utiliser l'authentification LDAP + suivant + ok »
VI- Redémarrer la machine et ouvrir la session avec l'utilisateur user1 qu'on déjà créer sur le serveur.

Configuration du protocole SSH sous Linux

SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH.
On peut l'utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de
manière sécurisée ou pour créer des tunnels. Les tunnels permettent sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.
Le système de clés de SSH
Cryptographie asymétrique
SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.
Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.
Cryptographie symétrique
SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message
confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.
Toute autre personne en possession de la clé secrète peut décrypter le message.
La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie
asymétrique, mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé
par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour
que A et B puissent s'échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée
grâce à la cryptographie symétrique en utilisant la clé secrète échangée.
Configuration du serveur SSH
Pour manipuler le daemon (le lancer, l'arrêter, recharger la configuration...), on utilise la commande
/etc/init.d/ssh
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec /etc/ssh/ssh_config qui
est le fichier de configuration du client SSH.
Parmi les multiples options, on peut noter :
• Port 22: Signifie que le serveur SSH écoute sur le port 22, qui est le port normal de SSH. Il est possible de le faire écouter sur un autre port en changeant cette ligne.
• Protocol 2: Signifie que le serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Pour accepter les deux protocoles, change la ligne en : Protocol 2,1
• PermitRootLogin no: Signifie que l'on ne peux pas se logger en root par SSH. Pour logger en root, il suffit de se
logger en utilisateur normal et d'utiliser la commande su.
• X11Forwarding yes: Autorise le transfert par SSH de l'affichage graphique.
• LoginGraceTime 600: Temps de connexion maximum
• RSAAuthentication yes: Méthode d'authentification.
• AuthorizedKeysFile .ssh/authorized_keys fichier utilisé pour 'l'autologin'
• PermitEmptyPasswords no: permet ou non les mots de passe vide
Si le fichier de configuration du serveur a été modifié, il faut indiquer au démon sshd de relire son fichier de
configuration, avec la commande /etc/init.d/ssh restart.
Se logguer par SSH
Deux types d'authentification sont possibles : par mot de passe et par clé. Dans les deux cas on utilise une des commandes suivantes :
ssh -l <login> <adresse du serveur SSH>
ssh <login>@<adresse du serveur SSH>
Authentification par mot de passe
C'est la méthode la plus simple. Lors de la connexion, le client ssh demande le mot de passe du compte. Dans ce cas, ssh crypte le mot de passe ce qui évite de le voir circuler en clair sur le réseau.
Authentification par clé
Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH. La clé publique est placée sur le serveur dans le home du compte sur lequel on souhaite se connecter. La clé privée reste sur le poste client.
Dans ce cas, aucun mot de passe ne circule sur le réseau.
Générer une clé
Pour générer un couple de clés, on utilise la commande :
ssh-keygen -t dsa
Deux clés vont être générées, une clé publique (par défaut ~/.ssh/id_dsa.pub) et une clé privée (par défaut
~/.ssh/id_dsa). C'est la clé publique qu'il faudra copier sur le serveur.
Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.
La commande demande un nom de fichier pour sauvegarder la clé privée et un nom de fichier pour sauvegarder la clé publique. Par défaut, la clé privée est stockée dans le fichier $HOME/.ssh/id_dsa.
La clé privée est enregistrée avec les permissions 600. La clé publique porte le même nom de fichier suivi de ".pub", avec les permissions 644.
Lors de la création de la clé, l'utilitaire demande une pass phrase qui est un mot de passe pour protéger la clé privée (2eme protection). Cette pass phrase sert à crypter la clé privée. La pass phrase sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois (voir les docs).
Il est possible de changer la pass phrase qui protège la clé privée avec la commande ssh-keygen -p.
Autoriser sa clé publique
Pour autoriser une clé à se connecter à un compte, il faut placer sa partie publique dans le fichier
$HOME/.ssh/authorized_keys du compte en question, sur le serveur SSH. Si vous souhaitez vous connecter au serveur sur le compte sasa, le fichier est /home/sasa/.ssh/authorized_keys.
Pour transférer la clé publique, on peut utiliser ftp, scp (copie de fichier par ssh), ou un simple copier/coller entre deux terminaux (c'est simplement une longue ligne de caractères ASCII).
Chaque ligne du fichier authorized_keys correspond à une clé publique autorisée à se connecter. Il faut vérifier que chaque clé est bien sur une seule ligne, sinon ça ne fonctionne pas.
Le répertoire $HOME/.ssh' devrait être protégé en écriture, avec les permissions 755 (ou 705). De la même manière, le fichier authorized_keys ne doit pas être lisible par tous (600 par exemple).
Ensuite, pour se logger, il suffit de procéder comme précédemment.
Si la clé privée a été enregistré dans un autre fichier que $HOME/.ssh/id_dsa, il faut le préciser au client ssh :
ssh -i <nom du fichier contenant la clé privée> <login>@<serveur>
Agent SSH
Un agent SSH est un programme qui garde en mémoire des clés privées. Le principe est le suivant :
• on lance un agent
• on lui ajoute des clés (si les clés sont cryptées, elles sont décryptées avec la passphrase avant d'être ajoutées)
• à chaque connexion ssh, les clé de l'agent sont utilisées en priorité
Les avantages principaux sont :
• que la passphrase n'est demandée qu'une seule fois au moment où elle est ajoutée à l'agent,
• et que l'agent est capable de faire suivre la clé sur plusieurs connexions.
Pour lancer un agent on utilise généralement une commande qui ressemble à :
ssh-agent /bin/bash
L'agent SSH lance un nouveau shell ("/bin/bash") dans lequel il sera actif. Il ne sera utilisable qu'à partir de ce shell et dans les programmes qui y seront lancés.
Pour ajouter une clé on utilise
ssh-add [<fichier>]
Si on ne précise aucun fichier, il utilisera la clé par défaut ("~/.ssh/id_dsa" pour SSH 2).
Si la clé est crypté, la passphrase sera demandée et la clé décryptée sera ajoutée à l'agent.
Toutes les connexions SSH (avec ssh, scp...) lancées à partir de ce shell utiliseront l'agent et ne demanderont donc plus la passphrase.
Créer un "tunnel" crypté entre deux stations
SSH est également capable de fournir un encryptage à d'autres services (ftp par exemple) par le biais du port forwarding. 

(options -L et -R de la commande ssh), de la manière suivante:
Considérons deux stations HOST1 et HOST2. Supposons que sur la machine HOST1, vous utilisiez la commande :
ssh -L p1:HOST2:p2 HOST2
ou sur HOST2:
ssh -R p1:HOST2:p2 HOST1
alors vous obtenez un tunnel sécurisé dans lequel vous pouvez passer toute connexion, lesquelles seront
automatiquement cryptées.
Sur HOST1, ssh -L p1:HOST2:p2 HOST2 signifie, que lorsqu'on se connecte au port p1, les paquets sont retransmis vers le port p2 de la machine HOST2 via HOST2.

Administration des services Réseaux: Configuration du service SAMBA sous Linux

Samba est un service permettant de partager des répertoires et imprimantes entre des stations Linux et des stations Windows. 

Configuration du service Samba

Pour la configuration de ce service le principal fichier à modifier est smb.conf qui se trouve généralement dans /etc ou /etc/samba selon la distribution.

Il existe également des interfaces graphiques pour configurer Samba.

La section [global] contient les options communes à tous les répertoires partagés.

Voici quelques options utilisables :

workgroup

Le nom du groupe de travail. Les ordinateurs du même groupe de travail se retrouvent côte à côte dans le

voisinnage réseau de Windows.

server string

La description du serveur, qui apparaitra à coté de son nom dans l'explorateur Windows. Si la description

contient le terme %h, il sera remplacé par le nom d'hôte de la machine.

encrypt passwords

Détermine si les mots de passe doivent être cryptés avant d'être transmis. C'est fortement recommandé et tous

les systèmes Windows à partir de 98 et NT4 SP3 utilisent cette fonctionnalité par défaut.

log file

Le nom du fichier qui contiendra le journal des activités du serveur. On peut avoir un journal par machine

client en utilisant %m dans le nom du fichier. Le %m sera remplacé par le nom de la machine client.

max log size

Taille maximale du fichier journal, en Kio.

socket options

Indique les options à mettre sur les sockets comme par exemple TCP_NODELAY pour que le système envoi

immédiatement les petits paquets sans attendre d'en avoir plusieurs.

De nombreuses autres options sont disponibles. Elles sont détaillées dans la page de man de smb.conf [1]

Exemple

[global]

workgroup = maison

server string = Serveur Samba sur %h

encrypt passwords = true

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

max log size = 1000

socket options = TCP_NODELAY

Configuration du partage des répertoires

Les partages Samba sont décrits dans des sections ayant la forme suivante :

[<nom du partage>]

<option> = <valeur>

...

Les paramètres principaux sont les suivantes :

comment

La description du répertoire partagé.

path

Le chemin du répertoire partagé. C'est le contenu du répertoire indiqué qui sera partagé.

read only

Détermine si les clients pourront écrire ou non dans le répertoire partagé.

public

Autoriser ou non les connexions sans mot de passe.

valid users

Liste des seuls utilisateurs autorisés à se connecter séparés par des espaces. Si on veut autoriser tous les

utilisateurs il ne faut pas mettre cette option.

browseable

Détermine si le partage apparaitra dans la liste des partages du serveur.

La section [homes] est un partage particulier. Elle définit le partage des répertoires utilisateur des comptes unix de

la machine.

De nombreuses autres options sont disponibles. Elles sont détaillées dans la page de man de smb.conf [1]

Par défaut (version 3.5.6) vous pouvez accéder à samba de façon anonyme (smbclient //serveur/nom_du_partage -U

compte sans mot de passe). Pour effectuer un accès plus sécurisé (avec compte et mot de passe), vous devez

également ajouter un compte samba qui se référence à un compte linux existant: adduser compte (si ce

n'est pas fait) smbpasswd -a compte Les droits des répertoires et fichiers doivent être correct.

Exemple chmod u+rws,g+rx,o+rx .../dossier et/ou fichier

Exemples

[cdrom]

comment = Samba server's CD-ROM

read only = yes

locking = no

path = /cdrom

guest ok = yes

[partage]

path = /media/d/partage

available = yes

browsable = yes

public = yes

writable = yes

[zelinux]

comment = Site web

path = /myrep/zelinux

read only = no

Protéger les répertoires partagés

Il est possible de rendre privé un répertoire et d'autoriser ou non des utilisateurs à y accéder.

Pour cela, pour chaque répertoire partagé ajoutez les options:

public = no

valid users = <nom des utilisateurs autorisés à accéder aux répertoires>

Pour chaque nom que vous avez rentré, il faut ajouter l'utilisateur samba avec

smbpasswd -a <nom de l'utilisateur>

Un compte unix du même nom doit exister. Si ce n'est pas le cas, il faut le créer avec la commande adduser.

Lancement du service

Lancement :

/etc/init.d/samba start

Pour le stopper :

/etc/init.d/samba stop

Pour le relancer :

/etc/init.d/samba restart

Les modifications du fichier smb.conf sont prises en compte pour chaque nouvelle connexion. Pour les rendre

effectives sur les connexions déjà établies, il faut relancer Samba.

Accès aux répertoires

Pour accéder aux partage sous Windows, il suffit d'ouvrir le voisinage réseaux d'une station Windows et de vérifier

si la machine y est.

Pour se connecter en ligne de commande à un partage à partir de Linux, on peut utiliser la commande

smbclient //<nom du serveur>/<nom du partage> -U <utilisateur>

Il est également possible de monter un partage Samba avec

smbmount //<nom du serveur>/<nom du partage> <répertoire local>

Différentes options sont disponibles. On peut les consulter dans man smbclient et man smbmount.

Généralement, il est conseillé d'ajouter les options -o username=compte,password=??? pour se connecter.

Par exemple, pour monter un répertoire "public" il faut préciser qu'il faut se connecter en guest :

smbmount //serveur/partage /point_de_montage -o guest

Il faut également que votre compte utilisateur ait des droits sur le montage. Le compte root peut utiliser smbmount

sans trop de problème.

Autrement, plusieurs possibilités existent:

1. compléter le fichier /etc/fstab avec votre montage //<IP-ADRESS>/<folder_on share>

<your_local_mountpoint cifs

defaults,iocharset=utf8,codepage=cp850,uid=1000,gid=1000,noauto,user,credentials=~/.smbcredentials

0 0)

2. ajouter des droits dans sudoers. (par défaut sous ubuntu 10.10, sudo smbclient //<nom du

serveur>/<nom du partage> <répertoire local>-o username=compte,password=???

fonctionne bien).