• Aucun résultat trouvé

Création d un contrôleur de domaine sous Linux

N/A
N/A
Protected

Academic year: 2022

Partager "Création d un contrôleur de domaine sous Linux"

Copied!
28
0
0

Texte intégral

(1)

Année 2012-2013

Création

d’un contrôleur de domaine sous

Linux

(2)

Sommaire

1. Les grandes étapes de la mise en place du contrôleur de domaine ... 3

1.1. Création de l’espace de travail ... 3

1.2. Installation d’OpenLDAP (version2.4.23) ... 4

1.2.1. Les paquets ... 4

1.2.2. Configuration de base du serveur LDAP ... 5

1.3. Rendre OpenLDAP compatible à Samba ... 7

1.4. Installation de Samba (version3.5.6) ... 11

1.5. Configuration de Smbldap-tools ... 15

1.6. Création de l’arbre LDAP ... 16

1.7. Gestion des profils itinérants en Français ... 16

1.7.1. Création d’un groupe ... 17

1.7.2. Création d’un utilisateur ... 17

1.7.2.1. Vérification de la bonne création ... 17

1.7.3. Création des lecteurs réseaux ... 18

1.8. Configuration des clients LDAP ... 19

1.8.1. Clients GNU/Linux ... 19

1.8.2. Clients Windows ... 20

1.9. Installation de Phpldapadmin ... 22

2. En résumé ... 23

Annexes ... 24

(3)

1. Les grandes étapes de la mise en place du contrôleur de domaine

1.1. Création de l’espace de travail

Avant de se lancer dans la configuration d’un contrôleur de domaine, il faut commencer par avoir un système d’exploitation sur lequel installer les composants nécessaires à la réalisation du projet.

Mon tuteur m’a donc proposé de me créer une machine virtuelle (VM) d’une Debian Squeeze (distribution libre GNU/Linux) sur Proxmox (virtualiseur sous GNU/Linux utilisé dans l’entreprise) avec pour seul configuration :

Le nom de la VM (son nom NetBIOS) : LDAP1 La configuration réseau :

o IP : 192.168.5.149/24 o DNS : 192.168.5.100 o Passerelle : 192.168.5.1 Un accès root (super utilisateur)

Me voila donc avec un système et un accès réseaux, nous allons maintenant mettre à jours la Debian afin de profiter des dernier packages disponibles, pour cela il faut tout d’abord ce connecter à la VM en SSH (Secure Shell) à l’aide d’un émulateur de terminal comme Putty.

De plus, pour effectuer toutes les opérations qui suivront, nous serons logué avec le super utilisateur root.

Sous GNU/Linux la commande à effectuer est assez simple pour mettre à jour un système, il suffit de taper :

root@LDAP1:~#apt-get update && apt-get upgrade Nous voici donc avec un système d’exploitation sein et fonctionnel.

Il reste seulement un petit pré-requis avant de commencer l’installation d’OpenLDAP et de Samba, il faudra juste rajouter une ligne au fichier hosts (fichier permettant la résolution de nom).

Nous allons donc ouvrir ce fichier grâce à l’éditeur vi (on aurait aussi pu choisir gedit ou nano) :

root@LDAP1:~#vi /etc/hosts

Et nous rajoutons une ligne à son contenu : 192.168.5.149 LDAP1.clin LDAP1

Cette ligne indique à notre serveur que l’adresse IP 192.168.5.149 correspond à LDAP1.clin ou à LDAP1 (clin est le nom de notre futur domaine), il ne sera donc pas perdu et saura que c’est de lui qu’il s’agit si dans certains fichiers de configuration nous notons son nom ou son adresse IP (au lieu de 127.0.0.1 qui signifie lui-même).

(4)

Modifier debconf :

root@CI_LDAP1:~#dpkg-reconfigure debconf Sélectionner Dialogue puis Intermédiaire.

Nous pouvons donc débuter et allons commencer par installer et configurer OpenLDAP qui fournira le système de base pour l'authentification des utilisateurs. Ensuite, on configurera le système pour qu'il s'appuie intégralement sur OpenLDAP, et on installera Samba pour pouvoir partager des fichiers. Il y aura un disque réseau par utilisateur, et un disque partagé entre tous les utilisateurs.

1.2. Installation d’OpenLDAP

(version2.4.23)

1.2.1. Les paquets

Commençons par installer les paquets nécessaires :

root@LDAP1:~#apt-get install slapd ldap-utils

Répondre aux questions suivantes :

Faut-il omettre la configuration d'OpenLDAP ? Non Nom de domaine : clin

Nom de votre organisation : clin.local Mot de passe administrateur : tototata

Faut-il autoriser le protocole LDAPv2 : Non

Note importante : le mot de passe entré ici correspond à l'utilisateur cn=admin,dc=clininfo,dc=local (il s’agit de la notation utilisé par OpenLDAP pour définir notre annuaire, dont la racine est local et la sous racine clin). Cet utilisateur (Administrateur de l’arbre LDAP) est différent du super utilisateur (le compte root du serveur) qui sera déclaré plus tard. Cependant pour éviter les confusions, on veillera à prendre toujours le même mot de passe (donc le mot de passe du super utilisateur root du serveur Debian).

Vérifions que la configuration de base a bien été prise en compte :

root@LDAP1:~#ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

#Commande : ldapsearch (effectue une recherche dans l’arbre ldap) –LLL (sans les informations inutiles) -Y EXTERNAL (sans authentification) –H ldapi:/// (spécifiant l’url ldap, ici en partant de la racine de l’arbre) –b cn=config dn (retournant les informations contenant cn=config et dn ()

Résultat renvoyé par la commande précédente, nous devons obtenir ceci :

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0

dn: cn=config

dn: cn=module{0},cn=config dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config

dn: cn={3}inetorgperson,cn=schema,cn=config

(5)

dn: olcBackend={0}hdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}hdb,cn=config

Afin de mieux comprendre, voici à quoi correspondent les attributs utilisé par le protocole LDAP :

« dn » distinguished name.

« cn » common name.

« gn » given name c'est à dire le prénom.

« sn » surname.

« l » locality name.

« st » state or province name.

« ou » organisational unit.

« dc » domain component.

« o » organization name.

Attention, nom de domaine et nom d’organisation (arbre LDAP) sont 2 choses différentes, voici à quoi correspondra à la fin de la mise en place, notre arbre LDAP :

dc=local | dc=clin

/ / \ \ ou=Computers ou=groups ou=Idmap ou=Users

(C’est pour cela que nous avons mis clin.local au dessus)

1.2.2. Configuration de base du serveur LDAP

Nous allons maintenant, pour plus de sécurité, recréer le mot de passe de l’administrateur de l’arbre LDAP renseigné précédemment mais chiffré cette fois ci (car le mot de passe apparaitra en clair dans les fichiers de configurations) :

root@LDAP1:~#slappasswd New password : tototata

Re-enter new password : tototata

Nous obtenons notre mot de passe sous la forme suivante : {SSHA}Y4m58WY9h057RZ2UbcAbW1wsT0C84jG4

(Notons-le !)

Nous modifions ensuite l’arbre afin de lui indiquer notre nouveau mot de passe chiffré : root@LDAP1:~#ldapmodify -Y EXTERNAL -H ldapi:///

#Commande : Sous LDAP, ldapmodify permet de modifier une entrée (ici à la racine comme tout à l’heure)

(6)

Nous obtenons ceci :

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0

Il suffit de rajouter à la suite (puis « Ctrl + D » pour quitter) : dn: olcDatabase={0}config,cn=config

add: olcRootPW

olcRootPW: {SSHA}Y4m58WY9h057RZ2UbcAbW1wsT0C84jG4

olcRootPW correspond à l’administrateur de l’arbre (dont nous avons pu créer un mot de passe chiffré précédemment grâce à la comment slappasswd).

Nous allons ensuite créer un fichier.ldif (les fichiers avec l’extension ldif permettent de modifier l’arbre LDAP sans avoir à relancer le démon) afin d’ajouter des restrictions d’accès à l’arbre.

Créons donc le fichier config.ldif (que nous plaçons dans /etc/ldap (répertoire d’OpenLDAP créé automatiquement à son installation) par exemple):

root@LDAP1:~# vi /etc/ldap/config.ldif

Et ajouter dedans :

dn: olcDatabase={1}hdb,cn=config changetype: modify

replace: olcAccess

olcAccess: to attrs=userPassword by

dn="cn=admin,dc=clin,dc=local" write by anonymous auth by self write by * none

olcAccess: to attrs=shadowLastChange by self write by * read olcAccess: to dn.base="" by * read

olcAccess: to * by dn="cn=admin,dc=clin,dc=local" write by * read

#Commande :

dn: olcDatabase={1}hdb,cn=config : Nous voulons changer la configuration de base

changetype: modify : On effectue une modification

replace: olcAccess : On veut remplacer les « olcAccess » (restriction d’accès ou encore appelé « ACL »)

olcAccess: to attrs=userPassword by

dn="cn=admin,dc=clin,dc=local" write by anonymous auth by self write by * none

olcAccess: to attrs=shadowLastChange by self write by * read

olcAccess: to dn.base="" by * read

olcAccess: to * by dn="cn=admin,dc=clin,dc=local" write by

* read

On indique ici que l’administrateur de l’arbre a tous les droits (lecture et écriture sur l’arbre) et les que les autres utilisateurs ou anonymes n’ont que le droit de lecture de l’arbre.

(7)

Il faut maintenant rendre ce fichier config.ldif effectif :

root@LDAP1:~#ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ldap/config.ldif

Cette commande nous renvoie:

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0

modifying entry "olcDatabase={1}hdb,cn=config"

Apparemment ça a fonctionné : modifying entry "olcDatabase={1}hdb,cn=config"

Nous vérifions quand même avec :

root@LDAP1:~#ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb

Résultat:

dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcLastMod: TRUE

olcRootPW: {SSHA}XXXXXXXXXXZZZZZZZZZZZZZZZ olcDbCheckpoint: 512 30

olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq

olcSuffix: dc=clin,dc=local

olcRootDN: cn=admin,dc=clin,dc=local

olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=clin,dc=local" write by anonymous auth by self write by * none

olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read

olcAccess: {3}to * by dn="cn=admin,dc=clin,dc=local" write by * read

Notre configuration est donc à jour !

1.3. Rendre OpenLDAP compatible à Samba

Pour son fonctionnement, OpenLDAP utilise des schémas (définition d’attributs comme ceux vu plus haut (dn, given name…)), nous devons donc inclure le schéma de Samba (afin d’inclure ses attributs à OpenLDAP).

Obtenir le schéma de Samba :

Installer le package de documentation de Samba (qui contient le schéma) : root@LDAP1:~#apt-get install samba-doc

(8)

Copier ce qui nous intéresse (le schéma) dans le répertoire d’OpenLDAP contenant les schémas:

root@LDAP1:~#cp /usr/share/doc/samba-

doc/examples/LDAP/samba.schema.gz /etc/ldap/schema/

Dé-zipper l’archive :

root@LDAP1:~#gzip -d /etc/ldap/schema/samba.schema.gz

Nous allons créer un fichier où nous allons inclure tous les schémas déjà présents sur OpenLDAP sans oublier de rajouter celui de Samba :

root@LDAP1:~#vi schema_convert.conf

Copier dedans ce qui suit :

include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema

include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/samba.schema

Grâce à la commande qui va suivre, nous allons prendre toutes les lignes du ficher schema_convert.conf afin de créer un fichier de configuration des attributs de Samba pour OpenLDAP :

root@LDAP1:~#mkdir /etc/ldap/ldif_output

root@LDAP1:~#slapcat -f schema_convert.conf -F /etc/ldap/ldif_output -n0 -s

"cn={12}samba,cn=schema,cn=config" > /etc/ldap/cn=samba.ldif

Ceci nous a donc créé le fichier de configuration nommé cn=samba.ldif, nous devons effectuer tout de même quelques modifications :

root@LDAP1:~#vi /etc/ldap/cn=samba.ldif

Dans les première lignes du fichier il faut effacer les « {12} » afin d’obtenir ceci : dn: cn=samba,cn=schema,cn=config

objectClass: olcSchemaConfig cn: samba

(9)

Et supprimer les lignes suivantes placées tout en bas du fichier : structuralObjectClass: olcSchemaConfig

entryUUID: bd8a7a82-3cb8-102f-8d5f-070b4e5d16f8 creatorsName: cn=config

createTimestamp: 20104714525953Z

entryCSN: 20100815125153.192505Z#000000#000#000000 modifiersName: cn=config

modifyTimestamp: 20100815122153Z

Il suffit maintenant de rendre ce fichier effectif :

root@LDAP1:~#ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/cn=samba.ldif

#Commande : ldapadd permet d’ajouter une entrée à l’arbre LDAP (tout à l’heure nous modifions l’entrée avec ldapmodify mais ici c’est une nouvelle entrée (un nouveau schéma)).

Résultat :

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0

adding new entry "cn=samba,cn=schema,cn=config"

La définition du schéma étant faite, il ne reste plus qu’à créer les indexes (ce sont des sortes d’attributs que Samba utilise pour, par exemple, associer un utilisateur à un groupe) utilisés pas Samba.

Pour ce faire, nous créons comme d’habitude un fichier.ldif nommé samba_indexes.ldif : root@LDAP1:~#vi /etc/ldap/samba_indexes.ldif

On y copie dedans tous les indexes utilisés par Samba :

dn: olcDatabase={1}hdb,cn=config changetype: modify

add: olcDbIndex

olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: loginShell eq olcDbIndex: uid eq,pres,sub

olcDbIndex: memberUid eq,pres,sub olcDbIndex: uniqueMember eq,pres olcDbIndex: sambaSID eq

olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaGroupType eq olcDbIndex: sambaSIDList eq olcDbIndex: sambaDomainName eq olcDbIndex: default sub

(10)

Et on rend le fichier effectif :

root@LDAP1:~#ldapmodify -Y EXTERNAL -H ldapi:/// -f samba_indexes.ldif

Résultat:

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0

modifying entry "olcDatabase={1}hdb,cn=config"

Afin d’être sûr qu’OpenLDAP a bien pris en considération toutes nos modifications (et malgré le faite que les fichiers.ldif sont la pour ça), nous redémarrons tout de même le démon :

root@LDAP1:~#/etc/init.d/slapd restart Stopping OpenLDAP: slapd.

Starting OpenLDAP: slapd.

À partir de la, je suis allé vérifier les logs afin de savoir si il y avait présence d’erreurs. Pour se faire utiliser la commande suivante :

root@LDAP1:~#vi + /var/log/syslog

#Commande : vi est un éditeur de texte, + permet d’aller directement à la fin du fichier et /var/log/syslog est le chemin pour accéder aux logs d’OpenLDAP (et de Samba).

En scrutant le fichier, je me suis rendu compte qu’il manquait des olcDbIndex, nous allons donc les rajouter en utilisant une autre méthode que l’injection de fichiers.ldif (moins conseillée car plus propice aux erreurs) afin de montrer cette autre possibilité (comme ce n’est pas un fichier.ldif, il n’y aura donc pas son avantage principal qui est la modification instantané de la configuration LDAP, il nous faudra donc arrêter le démon pour effectuer la modification).

On commence par arrêter le démon OpenLDAP : root@LDAP1:~#service slapd stop

On ouvre le fichier de configuration de la base LDAP (ce fichier ce nomme olcDatabase\=\{1}hdb.ldif) qui est lui-même un fichier.ldif :

root@LDAP1:~#vi

/etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1}hdb.ldif

On parcourt ensuite ce fichier jusqu’à trouver les lignes débutants par olcDbIndex (elles se trouvent sous les lignes olcDbConfig), il suffit de les supprimer et de copier les lignes ci- dessous (contenants tous les types d’olcDbIndex possibles dont nous pourrions avoir besoin) : olcDbIndex: objectClass eq,pres

olcDbIndex: ou,cn,sn,mail,givenname eq,pres,sub olcDbIndex: uidNumber,gidNumber,memberUid eq,pres olcDbIndex: loginShell eq,pres

olcDbIndex: uniqueMember eq,pres

(11)

olcDbIndex: uid pres,sub,eq

olcDbIndex: displayName pres,sub,eq olcDbIndex: sambaSID eq

olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaDomainName eq

olcDbIndex: sambaGroupType eq olcDbIndex: sambaSIDList eq olcDbIndex: default sub

Une fois fait, il suffit de sauvegarder et fermer le fichier et d’exécuter la commande suivante afin que la nouvelle configuration soit mise à jours (rien n’est dynamique avec les fichier.ldif, il faut toujours les rendre effectifs) :

root@LDAP1:~#slapindex

Autre petite erreur que j’ai pu faire ici : exécuter la commande slapindex avec le super utilisateur root. En effet, OpenLDAP fonctionne avec l’utilisateur openldap qui fait parti du groupe openldap, or le fait d’avoir exécuté cette commande avec root va changer les droits groupe et l’utilisateur de certains fichiers qui passeront de openldap à root (OpenLDAP ne pourra donc plus les lire ou exécuter ce qui provoquera de nombreuse erreurs).

Afin de réattribuer les bons droits utilisateur/groupe aux fichiers il suffit de ce placer dans les bons répertoires et d’exécuter la commande ls –l (qui liste les fichiers en affichant aussi les droits), puis de redonner les bon droits :

root@LDAP1:~#cd /var/lib/ldap root@LDAP1:~#ls –l

root@LDAP1:~#chown openldap:openldap * root@LDAP1:~#cd /etc/ldap/slapd.d/cn\=config/

root@LDAP1:~#ls -l

root@LDAP1:~#chown openldap:openldap *

#Commande : cd pour se placer dans le répertoire, ls –l pour lister et chown pour changer le groupe et l’utilisateur du fichier.

Tout est donc opérationnel pour passer à l’installation de Samba !

1.4. Installation de Samba

(version3.5.6)

Nous allons configurer Samba de telle sorte qu’il soit contrôleur de domaine, mais aussi en tant que serveur de fichiers (partage de fichiers ou sauvegarde de données via un disque réseau). Pour ce faire, nous allons installer Samba, puis nous créerons des zones de stockages privées et publiques.

Commençons par installer les paquets :

root@LDAP1:~#aptitude -y install smbldap-tools samba smbclient smbfs

(12)

Répondre aux questions suivantes :

Nom du domaine ou groupe de travail : clin Voulez vous chiffrer les mots de passe : Oui

Modifier smb.conf pour utiliser les paramètres WINS fournis par DHCP : Non

Comment voulez-vous lancer Samba : Démon

Faut-il créer une base de données /var/lib/samba/passdb.tdb : Non (voir remarque ci-dessous)

Remarque : si on répond « Oui » à la dernière question, le programme d'installation de Samba va importer tous les comptes. Ça inclut les comptes comme root, daemon, nobody, www-data, game, etc. Sur un serveur fraichement installé, il vaut mieux répondre « Non ». On pourra les rajouter à la main plus tard en cas de besoin.

Une fois l’installation terminée, on arrête Samba afin de terminer sa configuration : root@LDAP1:~#/etc/init.d/samba stop

Il faut maintenant configurer Samba pour qu'il intègre LDAP et les outils SMBLDAP que l'on installera dans la foulée. Un fichier de configuration /etc/samba/smb.conf est déjà présent, nous modifions sont nom en smb.conf.back afin d’avoir une sauvegarde la configuration originel au cas où :

root@LDAP1:~#mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

Nous allons maintenant aller chercher un exemple de configuration de smb.conf (ceci permet d’avoir un fichier sans le grand nombre de commentaire qui le rende illisible), cet exemple de configuration est disponible dans les fichiers créés par l’installation précédente du package smbldap-tools) :

root@LDAP1:~#cp /usr/share/doc/smbldap-tools/examples/smb.conf /etc/samba/smb.conf

Il ne reste plus qu’à le modifier afin d’avoir la configuration souhaitée : root@LDAP1:~#vi /etc/samba/smb.conf

Nous obtenons le fichier de configuration suivant (explication en vert) :

[global] #Définition des paramètres globaux du serveur

workgroup = clin #Nom du domaine (pour les clients Windows) netbios name = ldap1 #Nom du serveur LDAP qui l’identifie sur le réseau security = user #Force Samba à authentifier les connexions clients server string = Samba Server %v #Commentaire affiché dans le voisinage réseau

(Samba transcrit « %v » par sa propre version) encrypt passwords = Yes #Utilisation des mots de passe encryptés

ldap passwd sync = yes #Synchronise les mots de passe LDAP et Samba

###Commande qui permet de changer le mot de passe de l’utilisateur (à faire sous Samba)###

passwd program = /usr/sbin/smbldap-passwd -u "%u"

passwd chat = "Changing *\nNew password*" %n\n "*Retype new password*" %n\n"

(13)

log level = 3 #Niveau de log Samba

syslog = 3 #Niveau de log Samba + LDAP

log file = /var/log/samba/log.%U #Répertoire des log de Samba max log size = 100000 #Taille maximal du fichier de log time server = Yes #Samba est aussi serveur de temps

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 #Optimization pour le protocol TCP/IP Dos charset = CP932 #Utilise l’encodage CP932 sous Windows

Unix charset = UTF-8 #Utilise l’encodage UTF-8 sous Linux domain logons = Yes #Active le service de contrôleur de domaine domain master = Yes #Le serveur est le maitre du domaine local master = Yes #Le serveur est aussi maitre du réseau local logon home = \\ldap1\%U #Chemin du répertoire personnel de l’utilisateur

authentifié (voir [home] plus bas)

logon path = \\ldap1\profiles\%U #Chemin qui indique aux clients Windows où stocker leurs profils itinérants

logon script = logon.bat #Nom du script à exécuter à l’ouverture d’une session (voir [netlogon] plus bas)

logon drive = H: #Lettre du lecteur réseau qui mène à l’espace personnel de l’utilisateur (voir [home] plus bas)

os level = 65 #un « os level » de 65 permet au serveur Samba

d’être forcément le contrôleur de domaine face à un serveur Windows (dans le cas où 2 contrôleurs de domaine se trouvent sur le même réseau)

preferred master = Yes #Indique que ce serveur sera choisi en cas d’élection d’un contrôleur de domaine (si 2 serveurs sont en

« preferred master = yes » alors celui qui a le plus haut « os level » gagne l’élection)

dns proxy = no #Sans passer par un DNS pour résoudre le domaine

wins support = yes #Samba devient aussi serveur Wins (résolution de nom Netbios)

passdb backend = ldapsam:ldap://192.168.5.149/ #Indique à Samba que les comptes utilisateurs sont stockés sous LDAP

###Définition de l’organisation de l’arbre LDAP###

ldap admin dn = cn=admin,dc=clin,dc=local ldap suffix = dc=clin,dc=local

ldap group suffix = ou=Groups ldap user suffix = ou=Users

ldap machine suffix = ou=Computers

###Définition des scripts (voir plus bas dans la partie Smbldap-tools)###

add user script = /usr/sbin/smbldap-useradd -m "%u"

delete user script = /usr/sbin/smbldap-userdel "%u"

add machine script = /usr/sbin/smbldap-useradd -t 0 -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'

(14)

ldap ssl = no #Indique que la communication avec OpenLDAP

n’est pas chiffrée

create mask = 0640 #Tout fichiers créés dans les différents répertoires (sauf indication contraire (voir plus bas)) ont les droits 640

directory mask = 0750 #Tout dossiers créés dans les différents répertoires (sauf indication contraire (voir plus bas)) ont les droits 750

guest account = nobody #Les compte invité (utilisateurs qui parcours les dos- siers publiques de Samba ont le droit de l’utilisateur

« nobody ») map to guest = Bad User

###Définition des partages###

[homes] #Répertoire personnel des utilisateurs

comment = Dossiers personnels #Commentaire

browseable = no #Invisible dans le voisinage réseau

writable = yes #Accessible en écriture

guest ok = no #Les utilisateurs invité n’y ont pas accès

valid users = %U, clin\%U #Seul l’utilisateur authentifié à droit de voir son réper- toire personnel (« %U » est l’utilisateur authentifié)

[netlogon] #Répertoire où sont stockés les scripts exécutés par

Les clients Windows lors de leurs connexions path = /home/netlogon/%G #Chemin du répertoire (où « %G » est le groupe

primaire de l’utilisateur)

browseable = No #Invisible dans le voisinage réseau

read only = yes #Accessible en lecture seul

guest ok = no #Les utilisateurs invité n’y ont pas accès

[profiles] #Répertoire où sont stocké les profiles itinérants

comment = profils itinerants #Commentaire

path = /home/profiles #Chemin du répertoire où stocker le profile itinérant browseable = no #Invisible dans le voisinage réseau

writable = yes #Accessible en écriture

guest ok = no #Les utilisateurs invité n’y ont pas accès

create mask = 0700 #Les fichiers dans profiles sont créés avec le droit 700 directory mask = 0700 #Les dossiers dans profiles sont créés avec le droit

700

valid users = %U, clin\%U #Seul l’utilisateur authentifié à droit de voir son réper- toire personnel (« %U » est l’utilisateur authentifié)

[public] #Répertoire accessible à tout le monde

comment = Dossier public #Commentaire

path = /home/public #Chemin du répertoire

writable = yes #Accessible en écriture

public = yes #Accessible à tout le monde

create mask = 0777 #Tout le monde à tous les droits sur les fichiers directory mask = 0777 Tout le monde à tous les droits sur les dossiers

(15)

Nous avons donc configuré le fichier de configuration de Samba et avons donné des chemins vers des répertoires (netlogon, public, profiles et home), il nous faut donc créer les dossiers (en leur attribuant les bon droits) au bon endroit afin que ces chemins pointent vers leur bonne destinations :

root@LDAP1:~#mkdir /home/netlogon root@LDAP1:~#chmod 775 /home/netlogon root@LDAP1:~#mkdir /home/profiles root@LDAP1:~#chmod 773 /home/profiles root@LDAP1:~#mkdir /home/public root@LDAP1:~#chmod 777 /home/public

Remarque : Nous n’avons pas créé le répertoire « home » car il s’agit d’un répertoire automatiquement créé qui pointe vers le répertoire personnel de l’utilisateur authentifié (ce répertoire est automatiquement créé à la création d’un utilisateur).

Nous redémarrons le démon Samba afin de prendre en compte notre configuration : root@LDAP1:~#/etc/init.d/samba restart

Stopping Samba daemons: nmbd smbd.

Starting Samba daemons: nmbd smbd.

Samba doit connaître le mot de passe administrateur du serveur OpenLDAP pour l’administration LDAP. Ca lui donnera l'autorisation de créer, supprimer, modifier des entrées pour les comptes utilisateurs, groupes et machines.

La commande suivante permet de le faire:

root@LDAP1:~#smbpasswd -W

Setting stored password for "cn=admin,dc=clin,dc=local" in secrets.tdb New SMB password: tototata

Retype new SMB password: tototata

Ceci créer un fichier « secret.tdb » se trouvant dans le répertoire /var/lib/samba que seul le super utilisateur (root) peut lire.

1.5. Configuration de Smbldap-tools

Ces outils sont des scripts perl22 qui permettront de créer les utilisateurs Samba et LDAP de manière automatisée. Par exemple, nous pourrions dorénavant utiliser la commande smbldap- useradd (voir plus bas dans création d’un utilisateur), qui grâce à ces outils permettra de créer en même temps, le compte de l’utilisateur LDAP, Samba et Linux (avec création du répertoire personnel). Ceci nous facilite grandement la vie, car sans lui nous devrions créer un compte sur Samba (avec appartenance à un groupe etc etc…), le même sur OpenLDAP et le même sur Linux (avec création du répertoire privé).

(16)

Nous avions installé ces outils avec Samba afin de récupérer un exemple de fichier de configuration smb.conf, passons maintenant à leurs configurations :

root@LDAP1:~#gzip -d /usr/share/doc/smbldap- tools/configure.pl.gz

root@LDAP1:~#perl /usr/share/doc/smbldap-tools/configure.pl

Un écran s’affiche et si le smb.conf est bien configuré (ce qui est notre cas), il suffit d’appuyer sur la touche « ENTRER » car le script de configuration va pré-remplir les champs (par exemple le nom du domaine) grâce aux mêmes champs que sur le smb.conf.

Attention toutefois à ne pas allé trop vite car il faudra tout de même saisir à la main le mot de passe de l’administrateur LDAP (« tototata ») et le type d’encryption des mots de passe des utilisateurs linux (« l’encryption of the unix password »), pour ce dernier taper « MD5 ».

Toutes ces informations seront modifiables dans les fichiers smbldap.conf et smbldap_bind.conf situés dans le dossier /etc/smbldap-tools (notre smbldap.conf est disponible en annexe).

1.6. Création de l’arbre LDAP

Il est maintenant temps d’initialiser la base de données LDAP de base pour Samba. On va le faire en utilisant la commande smbldap-populate :

root@LDAP1:~#smbldap-populate

Vous devez saisir deux fois votre mot de passe root (« tototata »). Cette commande créée:

Les différentes OU (Organisation Unit) qui contiendront vos Machines, Users et Groups,

Deux UID : root (super utilisateur) et nobody (utilisateur avec peu de droits que prenne les invités) qui seront dans OU = Users,

Plusieurs CN (Common Name): Les groupes qui seront dans OU = Groups.

1.7. Gestion des profils itinérants en Français

Il faut configurer ce qui suit afin de notre PDC puisse stocker les profiles itinérants en

Français, sinon les utilisateurs auront leur dossiers en Anglais (« Images » se transformera en

« Pictures » par exemple), pour ce faire :

root@CI_LDAP1:~#apt-get install attr

root@CI_LDAP1:~#mount /home –o remount,user_xattr Ajouter user_xattr à fstab afin que l’option reste même après un redémarrage.

(17)

1.7.1. Création d’un groupe

Nous allons maintenant créer un groupe d’utilisateurs (par exemple, ici le groupe « Atelier de saisie ») et nous verrons par la suite comment l’exploiter.

Pour ce faire nous allons utiliser l’une des commandes de la suite smbldap-tools : root@LDAP1:~#smbldap-groupadd -a 'Groupe test'

#Commande : -a permet l’auto-mappage à la création du groupe (création de l’identifiant de sécurité et de groupe (SID et GID))

1.7.2. Création d’un utilisateur

Pour la création d’un utilisateur (par exemple l’utilisateur « Pierre Dupont » faisant partie du groupe « Atelier de saisie »), nous utiliserons également smbldap-tools :

root@LDAP1:~#smbldap-useradd -a -c "Pierre Dupont" -m -P -g

"Groupe test" pdupont

#Commande : -a désigne un utilisateur, -c pour donner le nom entier de l’utilisateur (information Gecos), -m créer le répertoire personnel (sous Linux), -P demande la création du mot de passe et pdupont est l’identifiant de l’utilisateur (uid)

Pour le supprimer, utiliser la commande smbldap-userdel pdupont.

1.7.2.1. Vérification de la bonne création

Commande permettant de vérifier que l’utilisateur à bien pris en compte les paramètres Samba (smb.conf) lors de sa création:

root@LDAP1:~#pdbedit –v pdupont

Attention : Durant un débogage et modification du fichier smb.conf (Samba), il se peut que les comptes utilisateurs prennent en compte le fichier smbldap.conf (Smbldap-tools), le modifier si nécessaire et bien penser à mettre à jours les comptes utilisateurs précédemment créés.

Par exemple : si on modifie dans smbldap.conf les chemins pour le home directory et login path il faudra effectuer la commande :

pdbedit –p "" –h "" –u pdupont

(18)

1.7.3. Création des lecteurs réseaux

Nous poursuivons par la définition des scripts qui permettront de créer les différents lecteurs réseaux des utilisateurs en fonction de leur groupe. Mais avant, nous allons nous intéresser à la logique de la configuration permettant la création des lecteurs réseaux en finalité.

Dans notre smb.conf nous avions mis plusieurs informations très importantes :

logon script = logon.bat #Nom du script à exécuter à l’ouverture d’une session (voir [netlogon] plus bas)

[netlogon] #Répertoire où sont stockés les scripts exécutés par

Les clients Windows lors de leurs connexions path = /home/netlogon/%G #Chemin du répertoire (où « %G » est le groupe

primaire de l’utilisateur)

browseable = No #Invisible dans le voisinage réseau

read only = yes #Accessible en lecture seul

guest ok = no #Les utilisateurs invité n’y ont pas accès

D’après les informations ci-dessus, on peut donc en déduire qu’il faut créer un dossier portant le nom de chaque groupe d’utilisateurs dans le dossier /home/netlogon.

De plus, il faudra dans chacun de ces dossiers créer un script nommé logon.bat.

(Attention de bien mettre les bon droits spécifiés plus haut, à la création du dossier /home/netlogon)

Exemple de script logon.bat permettant d’accéder au dossier public ([public] dans smb.conf) : net use p: \\ldap1\public

Pour reprendre notre exemple de l’utilisateur pdupont membre du groupe Atelier de saisie, il faut donc se placer dans /hom/netlogon et créer un dossier Atelier de saisie, puis dans ce dossier Atelier de saisie, il faudra créer le fichier logon.bat (en créant les bons scripts pour les lecteurs réseaux) :

root@LDAP1:~#cd /home/netlogon

#Aller dans le dossier « /home/netlogon#

root@LDAP1:/home/netlogon#mkdir "Groupe test"

#Créer le dossier « Groupe test »

root@LDAP1:/home/netlogon#cd Atelier de saisie

#Aller dans le dossier « /home/netlogon/Groupe test » root@LDAP1:/home/netlogon/Groupe test#vi logon.bat

#Créer le fichier « logon.bat »

#Copier dedans « net use p: \\ldap1\public »

(19)

1.8. Configuration des clients LDAP 1.8.1. Clients GNU/Linux

L'idée est d'utiliser l’annuaire LDAP pour authentifier les utilisateurs qui se connecteront sur la machine Linux. L'approche classique sur des systèmes Unix pour avoir une base centrale d'utilisateurs est d'utiliser NIS23. Nous allons voir comment utiliser une base LDAP pour faire le même travail.

Pour changer le processus d'authentification classique, il faut installer PAM (Pluggable Authentification Module). C'est une bibliothèque qui permet de remplacer la source d'authentification par à peu près n'importe quoi (LDAP, SQL, fichier à plat, NIS…), ceci sera couplé à NSS (Name Service Switch) qui permettra le changement du service à utiliser pour la connexion.

Nous allons maintenant installer et configurer la librairie qui permet d’utiliser l’annuaire (libnss-ldap) et la librairie qui permet de s’authentifier sous unix (libpam-ldap) :

root@LDAP1:~#apt-get install libnss-ldap libpam-ldap

Lors de l’installation un certain nombre de question seront posées :

Identifiant uniforme de ressource (« URI ») du serveur LDAP : ldap ://192.168.5.149 Nom distinctif (DN) de la base de recherche : dc=clin,dc=local

Version de LDAP utilisé : 3

Compte LDAP pour le superutilisateur (« root ») : cn=admin,dc=clin,dc=local Mot de passe du compte du superutilisateur LDAP : tototata

Donner les priviéges de superutilisateur local au compte administrateur LDAP ? oui La base LDAP demande-t-elle une identification : non

Compte LDAP pour le superutilisateur (« root ») : cn=admin,dc=clin,dc=local Mot de passe du compte du superutilisateur LDAP : tototata

Algorithme de chiffrement à utiliser localement pour les mots de passe : chiffré

Maintenant que les librairies sont configurées, on doit activer la recherche LDAP en modifiant le fichier de configuration /etc/nsswitch.conf. Pour cela il faut simplement ajouter ldap à passwd, group et shadow :

root@LDAP1:~#vi /etc/nsswitch.conf

# Modifier les lignes suivantes en rajoutant « ldap » passwd: compat ldap

group: compat ldap shadow: compat ldap

(20)

Il faut aussi modifier le fichier /etc/pam.d/common-password qui permet de gérer le changement de mot de passe :

root@LDAP1:~#vi /etc/pam.d/common-password

#Sur la ligne suivante, il faut retirer ('user_unknown=ignore')

password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass

Et pour finir, modifier le fichier /etc/pam.d/common-session qui gère l’ouverture de la session de l’utilisateur :

root@LDAP1:~#vi /etc/pam.d/common-session

# ajouter tout à la fin du fichier (créer la directory dans /home automatiquement) session optional pam_mkhomedir.so skel=/etc/skel umask=077

On redémarre ensuite le serveur afin d’être sur que toutes les configurations soient prises en compte :

root@LDAP1:~#reboot

1.8.2. Clients Windows

Chez Windows la marche à suivre est différente, il ne suffit pas simplement de lui indiquer d’aller s’authentifier sur le serveur LDAP mais il faut le faire appartenir au domaine (notre domaine est clininfo).

Il faut d’abord ajouter le serveur Samba en tant que serveur WINS afin de pouvoir résoudre le nom de domaine, pour ce faire, il faut aller dans Panneau de configuration/Réseau et Internet/Connexions réseaux et suivre ci-dessous :

Procédure de déclaration du serveur WINS

(21)

Puis pour appartenir au domaine, appuyer sur les touches Windows+Pause et cliquer sur Modifier les paramètres puis suivre ci-dessous :

Procédure d’apartenance au domaine

Après avoir cliqué sur « OK », il vous faudra renseigner le compte root (administrateur du domaine) afin de valider la jonction au domaine.

Attention : il existe un bug, une fois le compte root saisit, il se peut que le pc ne soit pas ajouté au domaine. Dans ce cas, retenter la jonction au domaine, si échec relancer les services Samba et OpenLDAP (service samba restart et service slapd restart) et retenter.

Une fois le client Windows sur le domaine, il suffit de le redémarrer l’ordinateur, et, arrivé à l’interface de connexion, cliquer sur « Autre utilisateur » et dans le champ « Identifiant », entrer l’utilisateur de la façon suivante : domaine\utilisateur.

Pour l’exemple, avec l’utilisateur pdupont, on entre clininfo\pdupont (puis le mot de passe de pdupont) et nous voila connecté au domaine.

Sur le serveur Samba, dans le dossier /home/profiles sera automatiquement créé un dossier nommé pdupont.v2 contenant le profile (fond d’écran, préférences, raccourcis…) de l’utilisateur pdupont. Si jamais l’utilisateur pdupont essai de se connecter sur un autre ordinateur, Samba ira voir dan le dossier /home/profiles si un dossier pdupont.v2 s’y trouve, comme il s’y trouve il exportera directement le profile sur le nouvel ordinateur (au lieu de créer le profile et d’importer les préférences comme précédemment).

(22)

1.9. Installation de Phpldapadmin

PhpLDAPadmin est une interface écrite en php qui permet de visualiser et de modifier facilement (via une interface Web) un annuaire LDAP (OpenLDAP principalement), sur le même principe que phpMyAdmin pour les bases de données MySQL.

Personnellement, je n’ai utilisé phpldapadmin seulement pour visualiser mon arbre et non pour le modifier, je préférais effectuer les modifications en lignes de commandes ce qui permettait un « auto mappage » de certaines caractéristiques (comme le SID de Samba) qui n’était pas faisable via phpldapadmin.

Pour l’installer, il n’y a qu’une chose à faire :

root@LDAP1:~#apt-get install phpldapadmin

Remarque : Comme cet outil n’est accessible que par navigateur, il tourne donc grâce à un serveur Apache qui était disponible de base sur ma Debian Squeeze.

Pour accéder à phpldapadmin, il suffit simplement d’ouvrir votre navigateur favori et d’entrer comme URL : adresseIpDuServeur/phpldapadmin, donc, dans notre cas,

192.168.5.149/phpldapadmin.

Après authentification avec le mot de passe root (« tototata »), vous pourrez voir une interface avec un arbre semblable à celui la, avec la racine (dc=clin,dc=local), l’administrateur (cn=admin), les unités organisationnels (Computers, Groups…) et le nom de domaine Samba (clin) :

Interface LDAP sous Phpldapadmin

(23)

2. En résumé

Pour résumer la marche à suivre afin de mettre en place un contrôleur de domaine authentifiant ses utilisateurs sur un annuaire informatique il faut :

1. Installer OpenLDAP qui permet la création de l’annuaire informatique, 2. Le rendre compatible avec Samba (problème de schéma),

3. Installer/configurer Samba en tant que contrôleur de domaine,

4. Installer/Configurer Smbldap-tools (pour plus de simplicité dans l’administration du contrôleur de domaine),

5. Créer l’arbre LDAP,

6. Créer les scripts d’autocréation des lecteurs réseaux, 7. Créer les groupes/utilisateurs,

8. Configurer les clients Windows/Linux.

(24)

Annexes

Fichier de configuration smbldap.conf :

###########################################################################

###

#

# LDAP Configuration

#

###########################################################################

###

# Notes: to use to dual ldap servers backend for Samba, you must patch

# Samba with the dual-head patch from IDEALX. If not using this patch

# just use the same server for slaveLDAP and masterLDAP.

# Those two servers declarations can also be used when you have

# . one master LDAP server where all writing operations must be done

# . one slave LDAP server where all reading operations must be done

# (typically a replication directory)

# Slave LDAP server

# Ex: slaveLDAP=127.0.0.1

# If not defined, parameter is set to "127.0.0.1"

slaveLDAP="192.168.5.149"

# 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="192.168.5.149"

# 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"

(25)

ldapTLS="0"

# How to verify the server's certificate (none, optional or require)

# see "man Net::LDAP" in start_tls section for more details verify=""

# CA certificate

# see "man Net::LDAP" in start_tls section for more details cafile=""

# certificate to use to connect to the ldap server

# see "man Net::LDAP" in start_tls section for more details clientcert=""

# key certificate to use to connect to the ldap server

# see "man Net::LDAP" in start_tls section for more details clientkey=""

# LDAP Suffix

# Ex: suffix=dc=IDEALX,dc=ORG suffix="dc=clininfo,dc=local"

# Where are stored Users

# Ex: usersdn="ou=Users,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for usersdn usersdn="ou=Users,${suffix}"

# Where are stored Computers

# Ex: computersdn="ou=Computers,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for computersdn computersdn="ou=Computers,${suffix}"

# Where are stored Groups

# Ex: groupsdn="ou=Groups,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for groupsdn groupsdn="ou=Groups,${suffix}"

# Where are stored Idmap entries (used if samba is a domain member server)

# Ex: groupsdn="ou=Idmap,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for idmapdn idmapdn="ou=Idmap,${suffix}"

# Where to store next uidNumber and gidNumber available for new users and groups

# If not defined, entries are stored in sambaDomainName object.

# Ex: sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"

# Ex: sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"

(26)

sambaUnixIdPooldn="sambaDomainName=clininfo,${suffix}"

# Default scope Used scope="sub"

# Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT) hash_encrypt="MD5"

# if hash_encrypt is set to CRYPT, you may set a salt format.

# default is "%s", but many systems will generate MD5 hashed

# passwords if you use "$1$%.8s". This parameter is optional!

crypt_salt_format=""

###########################################################################

###

#

# Unix Accounts Configuration

#

###########################################################################

###

# Login defs

# Default Login Shell

# Ex: userLoginShell="/bin/bash"

userLoginShell="/bin/bash"

# Home directory

# Ex: userHome="/home/%U"

userHome="/home/%U"

# Default mode used for user homeDirectory userHomeDirectoryMode="700"

# Gecos

userGecos="System User"

# Default User (POSIX and Samba) GID defaultUserGid="513"

# Default Computer (Samba) GID defaultComputerGid="515"

# Skel dir

skeletonDir="/etc/skel"

# Default password validation time (time in days) Comment the next line if

(27)

# you don't want password to be enable for defaultMaxPasswordAge days (be

# careful to the sambaPwdMustChange attribute's value) defaultMaxPasswordAge="45"

###########################################################################

###

#

# SAMBA Configuration

#

###########################################################################

###

# The UNC path to home drives location (%U username substitution)

# Just set it to a null string if you want to use the smb.conf 'logon home'

# directive and/or disable roaming profiles

# Ex: userSmbHome="\\PDC-SMB3\%U"

userSmbHome="\\ci-ldap1\%U"

# The UNC path to profiles locations (%U username substitution)

# Just set it to a null string if you want to use the smb.conf 'logon path'

# directive and/or disable roaming profiles

# Ex: userProfile="\\PDC-SMB3\profiles\%U"

userProfile="\\ci-ldap1\profiles\%U"

# The default Home Drive Letter mapping

# (will be automatically mapped at logon time if home directory exist) # Ex: userHomeDrive="H:"

userHomeDrive="H:"

# The default user netlogon script name (%U username substitution)

# if not used, will be automatically username.cmd

# make sure script file is edited under dos

# Ex: userScript="startup.cmd" # make sure script file is edited under dos userScript=

# Domain appended to the users "mail"-attribute

# when smbldap-useradd -M is used

# Ex: mailDomain="idealx.com"

mailDomain=""

###########################################################################

###

#

# SMBLDAP-TOOLS Configuration (default are ok for a RedHat)

#

(28)

###########################################################################

###

# Allows not to use smbpasswd (if with_smbpasswd == 0 in smbldap_conf.pm) but

# prefer Crypt::SmbHash library with_smbpasswd="0"

smbpasswd="/usr/bin/smbpasswd"

# Allows not to use slappasswd (if with_slappasswd == 0 in smbldap_conf.pm)

# but prefer Crypt:: libraries with_slappasswd="0"

slappasswd="/usr/sbin/slappasswd"

# comment out the following line to get rid of the default banner

# no_banner="1"

Références

Documents relatifs

• Modifiez le script testfic de façon à ce qu'il permette de tester l'existence de plusieurs fichiers ou répertoires (nombre indéfini de paramètres) en utilisant la commande shift

Attention que ceci est irréversible et donc si vous vous rendez compte par la suite que vous auriez besoin d’un DC 2003, et que vous êtes en niveau fonctionnel 2008, cela sera

w Article 5 : Rupture du contrat de mise à disposition à durée indéterminée sans faute L’adhérent utilisateur, dans le cadre d’un contrat de mise à disposition à

Pour créer un nouvel utilisateur dans le logiciel et lui affecter des droits, vous devez tout d’abord vous connecter à l’aide d’un compte disposant des

• Round Robin (tourniquet) : lorsqu'une tâche sous ordonnancement « Round Robin » est activée, on lui accorde un délai au bout duquel elle sera préemptée pour laisser passer

Pour ces situations, on préférera un ordonnancement « Round Robin », où une tâche peut s'exécuter pendant une tranche de temps au bout de laquelle elle est préemptée et placée

Si vous avez préalablement créé un compte utilisateur auquel la licence a été associée via la console de gestion, sélectionnez simplement le compte produit que vous désirez lier

Lancement des questions (en salle de cours, rythme imposé par l’enseignant) 1) Le jour J, se connecter à https://app.wooclap.com/auth/login avec les