Déploiement de Firefox en entreprise (partie 2 : aspects techniques)

Suite à la première partie, voici maintenant les aspects plus techniques du déploiement

Firefox


Principaux conseils

L’extension IETab

ie-tab-logo

Cette extension Firefox (qui existe aussi pour Chrome) a joué un rôle clé pour faciliter le déploiement de Firefox.

Elle permet (sous Windows uniquement) d’utiliser le moteur d’IE dans un onglet de Firefox. Et on peut la paramétrer pour s’activer automatiquement sur une liste d’URLs qu’on définit.
Quand un site ne fonctionne pas avec Firefox (une application Intranet, en général), on peut quand même y accéder sans quitter Firefox. On n’a donc pas besoin de jongler entre 2 navigateurs.

Paramétrage de Firefox

Quelques éléments de configuration ont été nécessaires pour adapter Firefox aux besoins de l’entreprise :

Surcharge de paramètres simples

Ex : page d’accueil, activation de l’authentification NTLM pour les sites intranet.

Ca se fait facilement dans le fichier « autoconfig », ou via CCK2.

Packaging d’une extension

(IETab, en l’occurrence). Il y a plusieurs manières de déployer une extension automatiquement : http://mike.kaply.com/2012/02/09/integrating-add-ons-into-firefox/

Dans notre cas, nous avons choisi le « scenario 1 » de l’article de Mike Kaply, en le mettant dans le répertoire distribution\bundles de Firefox. L’avantage de cette solution est que l’extension est automatiquement activée pour tous les profils du poste (ceux qui existaient déjà et les nouveaux qui seront créés).

Inconvénients de cette solution :

  • l’extension est supprimée par l’installeur de Firefox lors d’une upgrade (mais c’est uniquement dans le cas d’une upgrade via l’installeur : les upgrades automatiques de Firefox ne suppriment pas l’extension)
  • l’utilisateur peut installer lui-même cette extension dans son profil. Dans ce cas, sa version est prioritaire par rapport à la nôtre, ce qui peut être problématique

Dans le cas d’IETab, il y avait également un petit piège : cette extension intègre également un plugin (ne pas confondre les notions d’extension et de plugin dans Firefox. Cf https://fr.wikipedia.org/wiki/Extension_%28Mozilla%29). Et ce plugin ne fonctionne pas si on se contente de dézipper l’extension. Il faut d’abord installer IETab manuellement dans un Firefox, puis y récupérer l’extension dézippée. Cf https://mail.mozilla.org/private/enterprise/2014-August/004867.html

Configuration de l’extension IETab

La configuration d’IETab se fait de la même manière que les préférences de Firefox. Mais attention à supprimer dans le plugin les valeurs par défaut (dans le fichier defaults/preferences/ietab.js), pour qu’elles puissent être surchargées par de nouvelles valeurs par défaut dans l’autoconfig.

Il existe plusieurs manières de donner une valeur à une préférence :

  • defaultPref() qui change la valeur par défaut, et laisse l’utilisateur la surcharger s’il le souhaite
  • pref() qui renseigne la valeur, en écrasant celle que l’utilisateur avait pu mettre
  • lockPref() qui met une valeur par défaut, et empêche l’utilisateur de la changer

La plupart du temps, nous avons utilisé defaultPref().

Mais le choix a été plus difficile pour un paramètre particulier lié à IETab, qui contient la liste des URLs sur lesquelles on veut utiliser le moteur d’IE. En fait, on voulait le beurre et l’argent du beurre : déployer une valeur par défaut, laisser l’utilisateur la modifier ponctuellement (si on a oublié une URL, par exemple), mais pouvoir également écraser la valeur de l’utilisateur ponctuellement (quand on a une nouvelle liste d’URL à déployer).

On a finalement trouvé une solution en versionnant l’autoconfig, et en supprimant la valeur de l’utilisateur à certains moments (clearPref()) : https://mail.mozilla.org/private/enterprise/2014-August/004884.html

Ajout d’autorités de certification SSL

On peut ajouter un certificat dans le magasin de Firefox en utilisant certutil : ça fonctionne bien mais oblige à lancer des lignes de commandes sur chacun des profils des utilisateurs de la machine. Et on se retrouve à faire un script spécifique à l’OS.

Heureusement, il y a une autre solution, en utilisant simplement l’autoconfig. Source : http://xulfr.org/forums/read.php?1,8256

Il est également possible de le faire avec CCK2.

Déploiement du paramétrage

Vous noterez que tout cela se fait uniquement par des fichiers à déposer dans le répertoire d’installation de Firefox. Le déploiement est donc enfantin : il consiste uniquement à déposer ces fichiers/répertoires au bon endroit. De plus, cette méthode est multi-plateforme (sauf pour l’extension IETab)

Les plugins Flash, Java et Adobe Reader

Nécessaires ou non ?

Au début, j’ai plaidé le fait que les plugins sont en voie de disparition : à la fois Mozilla et Google poussent pour qu’ils soient progressivement remplacés par du HTML5.

En-dehors de Flash (qui reste aujourd’hui souvent nécessaire), j’aurais eu tendance à ne rien déployer par défaut. Et à n’ajouter que les plugins nécessaires aux personnes qui en ont besoin.

Mais bref, pour des raisons de compatibilité avec l’existant, les 3 plugins ont été déployés à tout le monde.

Quel lecteur PDF : pdf.js ou Adobe Reader ?

Avantages Inconvénients
pdf.js Inclus dans Firefox
Sécurisation facile car mis à jour en même temps que Firefox
Ne gère pas les formulaires PDF
Parfois des problèmes de mise en page
Adobe Reader Compatibilité avec tous les PDF existant
Même IHM que sous IE
Lent à démarrer
Mises à jour de sécurité à installer séparément de Firefox

Dans notre contexte, la compatibilité avec tous les PDFs a parue primordiale, donc le lecteur PDF interne a été désactivé, pour utiliser Adobe Reader à la place.

Cela dit, pdf.js s’améliore régulièrement : il serait pertinent de se poser à nouveau la question lors du passage à l’ESR 38.

Déploiement

Ces plugins étaient déjà déployés pour IE via l’outil de déploiement de l’entreprise. La méthode a donc été conservée.

Quel que soit l’outil utilisé : s’il s’appuie sur les installeurs de Flash et Java, ces outils installent automatiquement les plugins pour les différents navigateurs qu’ils trouvent sur la machine.

Deux petites pièges à éviter :

  • Sur l’ordre d’installation : si Flash/Java sont installés avant Firefox, ils ne le trouveront pas, et le plugin n’y sera pas installé. Il faut donc les installer après Firefox (ou les réinstaller sur les postes existant)
  • Firefox étant actuellement disponible uniquement en 32 bits sur Windows, c’est la version 32 bits de Java qu’il faut installer pour que le plugin soit reconnu par Firefox, même si l’OS est 64 bits.

Blocklist de Firefox et problématique de mise à jour des plugins

Firefox a une fonctionnalité de sécurité très intéressante : il prévient l’utilisateur s’il utilise un plugin connu pour avoir des failles de sécurité, et lui suggère de le mettre à jour dans ce cas. Il s’appuie pour cela sur une « blocklist » régulièrement mise à jour.

Problème : en entreprise, l’utilisateur n’a pas forcément les droits suffisants pour mettre à jour les plugins de son navigateur. Et les mises à jour déployées par l’entreprise ne sont pas toujours assez fréquentes.

Comment faire pour que l’utilisateur ne soit pas systématiquement perturbé par des alertes de sécurité sur les plugins ?

  • La meilleure solution : augmenter la fréquence de mise à jour des plugins. Mais ce n’est pas toujours aussi simple. Notamment pour Adobe Reader qui, semble-t-il, pose parfois des problèmes de conflit avec Adobe Writer, voire avec des drivers d’imprimante
  • Désactiver la blocklist : facile à faire mais c’est la pire des solutions. Puisque cette sécurité est alors désactivée pour tous les plugins et toutes les extensions
  • Désactiver la mise à jour automatique de la blocklist, et déployer un fichier blocklist.xml (maintenu par l’entreprise) en même temps que les nouvelles versions de Firefox, comme suggéré dans la mailing-list. Ca permet d’être sûrs que l’utilisateur n’aura pas d’avertissement, et garde une certaine sécurisation. Mais ça ne prémunit pas des failles de sécurité découvertes entre deux mises à jour de Firefox par l’entreprise, et fait un peu plus de travail d’administration (maintenance du fichier blocklist.xml). Je n’ai pas eu l’occasion de tester
  • Il semble possible de régler le niveau de blocage par Firefox, en fonction du niveau de criticité de la faille (paramètre extensions.blocklist.level). Mais, d’après mes tests rapides, ça ne va que dans le sens de verrouiller un peu + (par exemple empêcher complètement l’utilisation du plugin, sans laisser la possibilité à l’utilisateur de l’activer manuellement).

Le choix n’est pas encore tranché à ce jour. Je continue de plaider pour la première solution, qui sécurise en même temps les autres navigateurs.

Autres problèmes techniques rencontrés

  • Petite incompatibilité avec Firefox sur une page intranet basée sur des iframes et l’utilisation des ancres. Mozilla désactive l’utilisation les ancres dans certains cas, pour éviter de potentiels problèmes de sécurité : https://bugzilla.mozilla.org/show_bug.cgi?id=638598. Une petite modification de la page concernée a corrigé le soucis, en se basant sur http://matthewmanela.com/blog/making-linking-between-anchors-in-an-iframe-work-in-firefox-11-and-above/
  • Association des PDFs : il y avait un bug dans la version 31 de Firefox, qui pouvait dans certains cas s’associer aux fichiers PDFs (dans l’explorateur Windows), à la place du lecteur par défaut. C’est corrigé dans la version 31.2 (ESR), et dans la version 33
  • Nous sommes tombés sur un seul cas de site compatible IE qui ne fonctionne pas sous IETab. Symptôme : une page blanche lors de l’ouverture d’une nouvelle fenêtre par l’application. Cela sera résolu par une upgrade du site concerné.
  • Sur certains matériels, un driver de carte vidéo un peu ancien corrompait l’affichage de Firefox. Solution : soit upgrader le driver, soit désactiver l’accélération matérielle de Firefox sur ces machines
  • Certains utilisateurs avaient réussi à installer Firefox sans être administrateurs (en l’installant dans le « Documents And Settings » de l’utilisateur, plutôt que dans « Program Files », ou tout simplement en utilisant la version portable de Firefox). Ce n’est pas grave en soi, mais peut amener des dysfonctionnements (ex : 2 raccourcis qui pointent vers 2 versions différentes de Firefox, qui partagent le même profil). Il faut simplement savoir que ce cas peut arriver, et pouvoir accompagner l’utilisateur vers la version « officielle » de Firefox

5 réflexions au sujet de « Déploiement de Firefox en entreprise (partie 2 : aspects techniques) »

  1. Autre petit truc: Tournant en majorité sur du XP et ayant comme navigateur « officiel » IE8, J’ai du pour palier aux problèmes rencontrés par ce navigateur en installant firefox. Au départ, je me suis amusé à mettre les fichiers firefox sur un répertoire réseau accessible en seulement en lecture par les utilisateurs, j’ai ensuite peaufiné l’autoconfig aux petits oignons et au final je propose une solution simple :
    1) Lien Firefox sur le bureau (le lancement est bien plus lent que si le navigateur était installé directement sur le PC mais ensuite le surf est normal)
    2) 0 déploiement puisque tout est concentré dans le répertoire réseau.
    3) Profil stocké sur PC utilisateur

  2. Merci Netchaiev de la suggestion.

    Effectivement, ça peut être une idée quand tous les postes sont fixes, pour simplifier les problématiques de déploiement.
    Mais, dans le cas de figure que j’ai eu à traiter, il y a aussi des postes nomades (PC portables) qui ont besoin de Firefox quand ils ne sont pas branchés sur le réseau de l’entreprise.

  3. J’avais fait le déploiement de Thunderbird en entreprise il y a qques années, avec les mêmes questions et problématiques.
    Je suis consicnet que les problèmatiques diffèrent mais la démarche est je pense très proche.
    L’autoconfig est la clé du succès, et ensuite il faut bien profiler son parc et ses utilisateurs.
    J’avais opté pour le verrouillage des réglages et des extensions : installation globale hors profil, interdiction d’en ajouter. Mais cela nécessite une réactivité, voire une veille sur les besoins afin de pouvoir répondre vite et bien.
    Le fichier de pref est idéal pour la configuration et/ou surcharge des paramètres du navigateur mais aussi celle des extension.
    Avec un outil de déploiement performant, il est possible de faire de l’administration distante et globale sur tout le parc.
    Une politique stricte est plus facile à gérer avec des outils efficaces.
    J’avais l’espoir de construire un modèle de policy pour l’AD Win, mais le courage m’a manqué car l’outil de déploiement faisait le même travail. J’en avais trouvé 1 assez incomplet donc pas mis en oeuvre.
    Le retour des utilisateurs a été positif même si certains ont abandonné leur pratique ancestrale avec Outlook. Ceux avec Outlook Express ont vraiment apprécié le changement.

  4. Bonjour,

    je suis en train de mettre en place ce type de déploiement dans mon entreprise.
    il me reste un dernier problème à régler: autoriser les popups sur certains domaines particuliers.

    Avez vous une idée de comment on peut faire ceci ?

    merci d’avance.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *