12. Les applications et l'annuaire

12.1. Authentification sur l'Intranet

Nous utilisons un serveur Apache. Nous avons configuré ce serveur pour qu'il demande une authentification sur la base OpenLDAP, en utilisant mod_perl et une version modifiée du module Perl module AuthNetLDAP. Ce module Perl a été modifié pour gérer en plus d'une authentification standard :


 - L'indisponibilité d'un serveur LDAP, permettant de tenter un "bind" sur d'autres serveurs.
 - Gérer les particularités de la structure des objets LDAP SAMSE (*).
 - Autoriser la connection à certains groupes d'utilisateurs.
 - Pouvoir retourner des variables d'environnement Apache utilisées dans les applications.
 - Gérer un cache pour éviter de se ré-authentifier à chaque page demandée au serveur.

(*) L'identifiant unique pour un utilisateur est son numéro d'employé plutôt que l'habituel UID pour permettre une gestion plus aisée des entrées dans la base du personnel. Ceci permet notament le changement des logins en cas de mariage ou divorce sans avoir a supprimer puis recréer l'entrée. L'utilisateur donne son login (uid) pour s'authentifier mais l'appartenance à un groupe d'utilisateur est déterminée à partir du numéro d'employé.

Figure 5. Authentification serveurs Apache

Voici un extrait du fichier de configuration httpd.conf :


    <Directory "/home/intranet/cgi-bin">
	# Paramétrage du cache
        PerlModule Apache::SamseAuthenCache		# Chargement du module
        PerlSetVar AuthenCache_CacheTime     "900"	# Delai d'expiration du cache
        PerlSetVar AuthenCache_CaseSensitive "On"	# Gestion de la casse
        PerlSetVar AuthenCache_Encrypted     "Off"	# Encryptage du cache
        PerlSetVar AuthenCache_NoPasswd      "Off"	# Activation / desactivation de la validation du mot de passe
	# Variable d'environnement devant être définies par Apache et
	# dont la valeur est extraite des attributs de la base LDAP
        PerlSetVar AuthenCache_EnvRestore    "REMOTE_EMPLOYEENUMBER;REMOTE_GROUP;REMOTE_DEPARTMENTNUMBER"

        # Paramétrage de l'authentification
        AuthName "Authentification Intranet"
        AuthType Basic
        PerlSetVar BindDN "cn=root,dc=samse,dc=fr"	# Utilisateur autorisé à consulter l'arborescence
        PerlSetVar BindPWD "secret"			# Mot de passe de cet utilisateur
        PerlSetVar BaseDN "ou=people,dc=samse,dc=fr"	# Base de recherche des informations sur l'authentication
        PerlSetVar LDAPServer "localhost;ldapmaster.samse.fr"	# Serveurs LDAP à contacter
        PerlSetVar LDAPPort "389"			# Port du service LDAP
        PerlSetVar UIDAttr "uid"			# Attribut dont la valeur correspond au login de l'utilisateur
        PerlSetVar BaseGroupDN "ou=group,dc=samse,dc=fr"	# Base de recherche des groupes de l'utilisateur
        PerlSetVar GRPAttr "memberUid"			# Attribut spécifiant l'appartenance de l'utilisateur à un groupe
        PerlSetVar LinkAttr "employeeNumber"	# Attribut servant à établir la correspondance entre la personne et le groupe
        PerlSetVar ExtraAttr "departmentNumber" # Autre attribut devant être retourné comme variable Apache lors de la recherche
        PerlSetVar AllowGroup "intranet"	# Groupe auquel doit appartenir l'utilisateur pour être duement authentifié
        require valid-user
        PerlAuthenHandler Apache::SamseAuthenCache Apache::SamseAuthenLDAP Apache::SamseAuthenCache::manage_cache
        Options ExecCGI
    </Directory>

Suite à une authentification réussie le serveur Apache positionne en plus par défaut les variables d'environnement suivantes:


 - REMOTE_EMPLOYEENUMBER   : numéro d'employé unique.
 - REMOTE_GROUP		   : Liste des groupes auquels appartient l'utilisateur séparés par un point-virgule.
 - REMOTE_DEPARTMENTNUMBER : Numéro d'agence auquel l'utilisateur est affilié.

Ces variables sont ensuite utilisées par les applications Perl pour permettre une gestion des accès plus fine au niveau des fonctionnalités de ces applications.

L'accès a l'intranet permet de consulter les pages blanches, correspondant aux renseignements d'un salarié (N° de téléphone, adresse de messagerie électronique, fonction). Nous pouvons accéder aussi aux pages jaunes SAMSE, répertoriant les sociétés ou agences du groupe, le nom du responsable, adresse, téléphone, SIRET, et dans le futur aux plan d'accès des points de vente. Les accès aux différentes parties de l'Intranet regroupant des documents et scripts publiés sur l'Intranet se font aussi par ce biais.

12.2. Authentification sur le proxy

Nous utilisons le proxy Opensource Squid pour nos accès à Internet. Notre politique interne n'est pas d'en bloquer la consultation. Tout salarié du groupe a la possibilité de surfer sur Internet, cet usage étant limité au domaine professionnel.

L'utilisation de "black list" ou de contrôle sur le type de fichier a été rapidement abandonnée car cela recquiers un surplus d'administration qui de plus est très facilement contournable par des utilisateurs avertis. Nous avons préféré responsabiliser nos utilisateurs. Pour cela, nous demandons une authentification lors des demandes de connexions sur des serveurs Internet. Cette authentification est réalisée à l'aide de squid_ldap_auth un programme en C appelé en interne par le serveur Squid lors de chaque demande de consultation de l'Internet. Ce programme écrit par Glen Newton et inclu dans la distribution Squid à été modifié pour ajouter l'autorisation par groupe, ici le groupe 'internet'.

Figure 6. Authentification Proxy Internet

Pour allez plus loin dans la surveillance des accès et la responsabilisation par utilisateur, nous avons écrit un outil d'analyse des logs de squid, permettant de connaître tous les sites consultés par utilisateur et par réseau, ainsi que les statistiques horaires d'utilisation. Ce script est écrit en PERL http://www.samse.fr/GPL/SquidAnalyzer

L'accès à L'internet est limité au personne appartenant au groupe 'internet', tous les utilisateurs en font partis par défaut et en cas d'abus il nous suffit de supprimer un utilisateur de ce groupe pour lui en supprimer l'accès.

12.3. Gestion des droits pour les applications de gestion commerciale

Au sein d'une application, tous les utilisateurs n'ont pas accès à toutes les fonctions. Pour tenir compte de ces différents cas, nous avons préféré ne gérer dans notre annuaire que l'accès à l'application elle-même, les droits propres à l'application étant gérés par l'application elle-même en utilisant les variables d'environnement retournées par les serveurs Apache vues ci-dessus.

12.4. Authentification sur les serveurs VNC

Nos applications sont de plus en plus accessibles à travers un navigateur. Nous avons retenu aujourd'hui Netscape et Mozilla.

Pour des questions de simplicité d'administration, nous ne désirons pas déployer un nombre trop important de PC sous Windows. Nous avons cherché une solution plus simple et moins onéreuse.

Nous avons retenu la technologie développée par AXEL. Elle s'appuie sur le protocole VNC. L'utilisateur a un environnement de travail graphique, incluant Mozilla et divers outils (Bureautique, dessein...). Elle nécessite l'installation d'au moins un serveur Linux VNC par agence. L'authenfication de l'utilisateur nécessite la présence d'un compte sur le serveur. Ne souhaitant pas créer des comptes sur chaque serveur, nous utilisons le module PAM_LDAP et NSS_LDAP. Un shell a été écrit pour remplacer le module mk_homedir.so qui n'est pas utilisable pour l'ouverture de session graphique. Les platines graphiques VNC utilisent le module de login GDM de Gnome qui via Pam_LDAP authentifie l'utilisateur. C'est dans les fichiers d'initilisation de la session X (en réalité Xvnc) qu'est exécuté, lors de la première connexion de l'utilisateur sur ce serveur, le script pour créer son répertoire personnel et inclure tous les fichiers de configuration de son environnement.

Figure 7. Authentification serveurs VNC

Pour fiabiliser le service d'authentification, nous répliquons la base LDAP sur les serveurs principaux de chaque agence, ainsi, en cas de problème réseau, les utilisateurs peuvent continuer à travailler sur leur réseaux locaux.

12.5. Authentification pour le monde Microsoft

Nous avons aujourd'hui un PDC (controleur principal de domaine, gérant la base de comptes) et un certain nombre de BDC (controleur de domaine secondaire). Pour homogénéiser les comptes utilisateurs, nous souhaitons que cette authentification soit faites sur LDAP. Nous travaillons actuellement sur la solution SAMBA et LDAP. L'objectif est de remplacer nos PDC et BDC par des serveurs SAMBA. La première évaluation de cette solution semble très viable et devrait être mise en oeuvre dans le courant de l'année 2002.

Figure 8. Authentification Samba/LDAP/PDC

La mise en oeuvre peut se faire à posteriori sans aucun problème puisqu'il suffit simplement d'ajouter le schema de definition de la classe d'objet 'sambaAccount' à l'objet personnel.


attributetype ( 1.3.6.1.4.1.7165.2.1.1 NAME 'lmPassword'
	DESC 'LanManager Passwd'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.2 NAME 'ntPassword'
	DESC 'NT Passwd'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.3 NAME 'pwdLastSet'
	DESC 'NT pwdLastSet'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.4 NAME 'acctFlags'
	DESC 'Account Flags'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{16} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.5 NAME 'logonTime'
	DESC 'NT logonTime'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.6 NAME 'logoffTime'
	DESC 'NT logoffTime'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.7 NAME 'kickoffTime'
	DESC 'NT kickoffTime'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.8 NAME 'pwdCanChange'
	DESC 'NT pwdCanChange'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.9 NAME 'pwdMustChange'
	DESC 'NT pwdMustChange'
	EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.10 NAME 'homeDrive'
	DESC 'NT homeDrive'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{4} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.11 NAME 'scriptPath'
	DESC 'NT scriptPath'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.12 NAME 'profilePath'
	DESC 'NT profilePath'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.13 NAME 'userWorkstations'
	DESC 'userWorkstations'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.14 NAME 'rid'
	DESC 'NT rid'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.15 NAME 'primaryGroupID'
	DESC 'NT Group RID'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

#attributetype ( 1.3.6.1.4.1.7165.2.1.16 NAME 'displayName'
#	DESC 'Friendly User Name'
#	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.17 NAME 'smbHome'
	DESC 'smbHome'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
	DESC 'Samba Account'
	MUST ( uid $ uidNumber ) 
	MAY  ( cn $ gidNumber $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
               logoffTime $ kickoffTime $ pwdCanChange $ pwdMustChange $ acctFlags $ 
               displayName $ smbHome $ homeDrive $ scriptPath $ profilePath $
               description $ userWorkstations $ rid $ primaryGroupID ))

12.6. Backend PostgreSQL

Nous développons actuellement un webmail. Les fonctionnalités demandées dans ce cadre nécessitent de très bonnes performances notement pour l'acccès au carnet d'adresses et une convivialité (taper les premières lettres du nom pour obtenir le nom complet dans le carnet d'adresse, par exemple) qu'il n'est pas réaliste de mettre en oeuvre à partir de requêtes LDAP. En effet si LDAP est tres performant pour l'authentification ou des recherches, sortir la liste complête des adresses email des utilisateur est infaisable en terme de performance. Nous avons donc pensé à utiliser une base de données pour stocker ces informations et obtenir des temps de réponse acceptable. L'utilisation de plusieurs base de référence suivant les besoins de l'application utilisée reviens à mettre en cause l'architecture centralisée permise par LDAP. Heureusement OpenLDAP permet de remplacer le backend ldbm par un autre système de base de données. Les SGBD actuellement supporté sont Oracle, MySQL et MSQL. Notre choix de PostgreSQL nous à donc naturellement amené à mettre en oeuvre le backend PostgreSQL pour OpenLDAP. C'est aujourd'hui chose faite.

Suite à cette mise en oeuvre des patches ont été adressés aux développeurs d'OpenLDAP afin qu'ils soient intégrés à la distribution actuelle (2.0.18). De plus nous avons mis à disposition sur Internet un HOWTO expliquant cette mise en oeuvre.

Le backend PostgreSQL pourra aussi être extrêmement utile si nous décidons un jour de centraliser dans une seule base de données toutes les informations utilisées au sein du service informatique SAMSE.

12.7. Messagerie

La messagerie mise en oeuvre au sein du groupe SAMSE en remplacement d'un serveur MS-Exchange se compose de :


 - un MTA Sendmail,
 - de Cyrus Imapd pour l'accès et la gestion des boites aux lettres,
 - de Sieve pour la gestion de filtres sur les boites aux lettres,
 - de Majordomo pour les mailings listes,
 - de PostgreSQL pour la gestion du carnet d'adresses.
 - une interface client developpée en Perl s'appuyant sur Apache et mod_perl.

La liaison avec LDAP se fait au niveau du service Imap via PAM_LDAP, ceci évite d'avoir à créer l'ensemble des compte utilisateurs sur le système. Sendmail est configuré pour distribuer tous les mails à destination du domaine samse.fr en local directement à Cyrus.

Comme nous l'avons vu ci-dessus le carnet d'adresse s'appui sur une base PostgreSQL servant de backend au serveur LDAP répliqué, où les requêtes sont réalisées directement en SQL.

Figure 9. Architecture de la messagerie