Guide d`utilisation et de mise en oeuvre

Transcription

Guide d'utilisation
Version 2.51
Réf. : GZD2.51.Rev2
Reproduction et droits
Copyright © Prim'X Technologies 2004, 2005, 2006.
Toute reproduction, même partielle, du document est interdite sans autorisation écrite
préalable de la société Prim'X Technologies ou de l'un de ses représentants légaux. Toute
demande de publication, de quelque nature que ce soit, devra être accompagnée d'un
exemplaire de la publication envisagée. Prim'X Technologies se réserve le droit de refuser
toute proposition sans devoir justifier sa décision.
Tous droits réservés. L'utilisation du logiciel Zed! est soumise aux termes et conditions de
l'accord de licence conclu avec l'utilisateur ou son représentant légal.
Zed! est une marque déposée de Prim'X TECHNOLOGIES.
Siège : 10 Place Charles Béraudier 69428 Lyon Cedex 03 - Tél. : 33(0)4.26.68.70.02
Direction commerciale : 42 Avenue Montaigne 75008 Paris - Tél. : 33(0)1.72.74.11.59 - [email protected]
Guide Zed! - GZD2.51.Rev2 - © Prim'X Technologies 2003, 2006
1
Introduction
Zed! est un produit très simple permettant de fabriquer des conteneurs de fichiers
chiffrés (et compressés) destinés soit à être archivés soit à être échangés avec des
correspondants, en pièces jointes de messages électroniques ou sur des supports variés,
comme des clés mémoires USB.
L'utilisation des conteneurs chiffrés est très intuitive et tout à fait similaire à l'utilisation
des 'dossiers compressés' sous Windows XP.
La version complète permet de définir les clés d'accès à un conteneur chiffré, soit sous
forme de mots de passe "d'échange" convenus avec un correspondant, soit sous forme de
certificats RSA, pris dans des fichiers certificats ou recherchés sur un annuaire LDAP de
certificats.
Il y a plusieurs usages possibles des conteneurs Zed!, l'usage le plus fréquent étant de
préparer à l'avance et une fois pour toutes un conteneur pour chacun des quelques
correspondants, avec les accès (clés) préparés, puis de réutiliser ce conteneur par la suite
en changeant simplement les fichiers qu'il contient.
Les différents packages
Zed! est décliné en différents packages :

L'Edition Standard, qui contient le produit complet ;
L'Edition Limitée, gratuite, libre de distribution et d'usage, qui permet de lire le
contenu des conteneurs, et même de les modifier, mais qui ne permet pas de créer de
nouveaux conteneurs, ni de modifier les accès (clés, mots de passe) prévus par le
créateur original du conteneur. L'Edition Limitée existe sous deux formes :
Une forme installable (i.e. avec programme d'installation) et intégrée à
l'Explorateur Windows ;
Un simple exécutable, facile à transporter, et qui évite d'avoir à effectuer une
installation ;
Enfin, Zed! est également incorporé dans les différents produits de la gamme
ZoneCentral.
Installation
Vous devez disposer des droits suffisants sur l'ordinateur pour installer le produit
("administrateur" ou "powered user").
Pour installer le produit, exécuter le programme d'installation "Setup Zed!" qui vous a été
fourni. Cette installation est standard et rapide.
2
Utilisation
1 - Créer un conteneur :
Faites un click-droit dans le fond d'un dossier ou du bureau, déroulez le menu [Nouveau],
et sélectionnez [Conteneur chiffré]. Un fichier est créé avec un nom par défaut, il vous est
possible de changer son nom. Le
conteneur est créé, mais n'est pas
encore initialisé. Cela se fera
automatiquement dès que vous
l'ouvrirez.
L'extension des conteneurs chiffrés
est ".zed".
2 – A la toute première création d'un conteneur
Dès que vous ouvrez le conteneur créé plus haut, un Assistant va apparaitre pour vous
faire choisir votre clé d'accès personnelle. Cette clé sera par la suite automatiquement
intégrée dans chaque conteneur chiffré que vous créerez, ce qui vous permettra de les
ouvrir par la suite.
Cette clé personnelle peut être :

Un mot de passe, que vous choisissez ;
Une clé cryptographique RSA, associée à un certificat, et qui peut être hébergée dans
différents "porte-clés" :
Un fichier de clés (.pfx ou .p12, en général), protégé par mot de passe ;
Une carte à puce ou un token USB, de type RSA (la plupart des fabricants du
marché sont supportés), respectant la norme PKCS#11 ;
Un conteneur de clés accessibles par l'interface CRYPTOAPI de Windows, ce
conteneur pouvant être dans les magasins de votre profil utilisateur Windows
ou dans un magasin "tierce-partie" (parmi lesquels on peut retrouver aussi les
cartes à puce ou tokens USB RSA)
Note : le logiciel Zed! ne génère pas de clés RSA ni de certificats. Si vous souhaitez utiliser
des clés de ce type, vous devez utiliser les services d'une PKI (infrastructure de certificats)
d'entreprise, ou publique, ou commerciale.
Variantes : votre administrateur a pu configurer les politiques de sécurité du produit pour
modifier le comportement de cette étape :

Il peut retirer certaines possibilités (interdire les mots de passe, par exemple) ;
Il peut imposer une force minimale aux mots de passe ;
Dans le cas de clés RSA, il peut imposer certaines règles sur les certificats et clés
utilisables ;
Il a également pu faire en sorte d'imposer des jeux de clés RSA prédéfinis au sein du
domaine Windows et publiés sur le contrôleur de votre domaine : vous n'aurez pas le
choix de la clé à utiliser, il vous faudra fournir celle qui vous a été imposée (et remise
par ailleurs, ou que vous utilisez déjà depuis longtemps pour d'autres usages).
3
Dans la première étape, après l''écran d'accueil, vous allez donc choisir un type de clé
d'accès (ici, un mot de passe).
Dans la page suivante, vous devez choisir un identifiant d'utilisateur. Par défaut, le
produit vous propose votre nom d'utilisateur Windows, mais vous pouvez le changer. Ce
nom sera utile par la suite pour "vous reconnaitre" dans les différents accès prévus dans
un conteneur. Quand vous le verrez apparaitre, vous saurez que c'est votre mot de passe
qu'il faut fournir.
Î une bonne pratique, également, est de mettre son adresse email.
Il vous faut ensuite vous choisir un mot de passe personnel, que vous devrez fournir
deux fois, pour bien vous assurer de le connaitre. Dans la première saisie, la pastille reste
rouge tant que votre mot de passe n'a pas une "force" suffisante. Dans la seconde saisie,
la pastille est orange tant que vous ne faites pas d'erreur, devient verte dès que la saisie
est la même que la première, et rouge si vous faites une erreur.
Pour augmenter la "force" de votre mot de passe, une bonne pratique est de faire varier
les caractères : minuscules, majuscules, chiffres, caractères de ponctuation. En rendant
ainsi plus "large" l'espace des valeurs possibles pour un même caractère, vous augmentez
la force. Sinon, vous devez compenser par la longueur du mot de passe. C'est une question
d'équilibre entre "mot de passe court mais complexe" et "mot de passe long mais simple".
Note : votre administrateur a pu
imposer le niveau de force. Par
défaut, la configuration vous oblige
à mettre un mot de passe de force
raisonnable, un peu au dessus de
la moyenne.
4
Validez, et l'opération est
terminée. Elle ne sera plus à
faire ensuite.
L'opération pour des clés RSA est très similaire : vous êtes invité, en fonction des cas, à
choisir un fichier de clés, ou introduire votre carte ou token USB, ou encore à choisir votre
certificat, vous devrez fournir le code d'accès (du fichier, de la carte, …), et valider. S'il y a
plusieurs clés disponibles, le produit les étudie, élimine celles qui ne sont pas utilisables
dans son contexte, et vous laisse le choix.
Dès que cette opération est terminée, le conteneur dont vous aviez demandé l'ouverture
s'ouvre.
3 - Ouvrir un conteneur :
Il suffit de double-cliquer dessus ou d'utiliser le menu contextuel [ouvrir]. Le conteneur
s'affiche, avec les fichiers qu'il contient.
Le style et l'ergonomie de ce 'pseudo-dossier' sont très similaires à ceux des dossiers
compressés (.zip) natifs sous Windows XP. Toutes les opérations habituelles sur les fichiers
sont autorisées (glisser-déplacer, copier-coller, changement de nom, suppression, etc.).
Cependant, dès qu'une de ces opérations entraîne le chiffrement ou le déchiffrement d'un
fichier, la clé d'accès va être demandée (voir plus loin).
5
3 - A la première opération sur un fichier du conteneur,
...une clé d'accès va être demandée. Il peut s'agir d'un mot de passe convenu avec la
personne qui vous a expédié ce conteneur (ici, 'Xavier'), ou d'une clé RSA, que vous
détenez dans un fichier de clés (.pfx), une carte à mémoire, ou qui est hébergée dans un
magasin de clé de Windows (CSP).
Sélectionnez le pictogramme correspond au type de clé d'accès que vous possédez. Le
premier désigne des mots de
passe, le second des fichiers de
clés (.pfx), et le troisième une
carte à mémoire. Pour ces deux
derniers, il vous faudra saisir le
code confidentiel associé.
La clé d'accès fournie est ensuite
conservée en mémoire un certain
temps.
Le cas échéant, elle sera
redemandée lors d'une autre
opération si besoin est.
Notes :
Si votre clé d'accès est hébergée dans un magasin de clés Windows (CSP), et si elle peut
effectivement ouvrir le conteneur, alors cette fenêtre n'apparaît pas. Soit l'ouverture est
automatique, sans demande, soit c'est la fenêtre du CSP utilisé qui sera affichée (cela
dépend des dispositifs CSP additionnels éventuels installés sur votre poste) ;
Le logiciel Zed! est prévu pour reconnaître en standard un certain nombre de cartes à
mémoire RSA (ou tokens USB), notamment ceux des sociétés ActivCard, Aladdin, Rainbow,
Axalto et GemPlus. Si votre carte n'apparaît pas dans la liste, c'est certainement qu'elle
n'est pas d'un type préconfiguré. Dans ce cas, il est possible de contacter le support
technique qui vous indiquera la procédure technique pour configurer votre type de carte (si
elle est compatible).
6
4 - Ouvrir un fichier du conteneur
Cette opération demande une clé d'accès si elle n'a pas déjà été fournie précédemment.
Il suffit de sélectionner le fichier et de double-cliquer dessus, ou bien d'afficher le menu
contextuel (click droit) et de faire le choix [ouvrir]. Le fichier est extrait, déchiffré et
décompressé, et copié dans un fichier temporaire, puis l'application qui traite
habituellement ce type de fichier sur votre poste est activée et l'ouvre.
Si un fichier du même nom existe déjà dans l'emplacement temporaire, il vous sera
demandé si vous souhaitez le remplacer ou non.
5 - Extraire des fichiers du conteneur
L'extraction consiste à déchiffrer, décompresser et déposer à un emplacement désigné le
ou les fichiers sélectionnés.
Il y a plusieurs façons d'effectuer cette opération :

Faire un [copier] des fichiers dans le conteneur, suivi d'un [coller] à l'emplacement où
vous voulez que les fichiers soient déposés (sur le bureau, dans un autre dossier, etc.
(les accélérateurs clavier [Ctrl-C/Ctrl-V] fonctionnent également, de même que le
[couper/coller]) ;
Faire un [glisser/déplacer] des fichiers sélectionnés dans le conteneur vers
l'emplacement où vous voulez que les fichiers soient déposés ;
Utiliser le menu contextuel [Extraire] sur les fichiers du conteneur : dans ce cas, une
fenêtre apparaît pour que vous puissiez sélectionner l'emplacement cible ;
Utiliser le menu contextuel [Extraire tout] dans le 'fond' du conteneur : dans ce cas,
une fenêtre apparaît pour que vous puissiez sélectionner l'emplacement cible, et TOUS
les fichiers seront alors extraits.
S'il existe déjà un ou plusieurs fichiers de même nom dans l'emplacement cible, une
fenêtre vous demandera confirmation du remplacement.
6 - Changer le nom des fichiers dans le conteneur
Cette opération est possible et ne demande pas de clé d'accès. Utiliser le [click lent] sur le
fichier, ou la touche standard [F2], ou encore le menu contextuel [Renommer] et indiquez
le nouveau nom (qui doit respecter les contraintes habituelles sur les noms de fichiers).
7 - Supprimer des fichiers du conteneur
Cette opération est possible et ne demande pas de clé d'accès. Utiliser la touche [Suppr]
ou le menu contextuel [Supprimer] sur les fichiers sélectionnés.
Attention, il n'y a pas de mise en "Corbeille" des fichiers supprimés dans un conteneur.
8 - Ajouter des fichiers dans un conteneur
L'ajout consiste à copier le fichier source, compresser son contenu, et à le chiffrer dans le
conteneur.
Il y a plusieurs façons d'effectuer cette opération :

Faire un [copier] des fichiers 'source', suivi d'un [coller] dans le conteneur
(les accélérateurs clavier [Ctrl-C/Ctrl-V] fonctionnent également, de même que le
[couper/coller]) ;
Faire un [glisser/déplacer] des fichiers 'source' vers le conteneur ;
Utiliser le menu contextuel [Ajouter...] dans le 'fond' du conteneur : dans ce cas, une
fenêtre apparaît pour que vous puissiez sélectionner les fichiers 'source'.
7
Il n'est pas possible d'effectuer cette opération sur un dossier, ou sur une sélection
comportant un dossier.
9 - Modifier les clés d'accès du conteneur
Lorsqu'il est créé, un conteneur contient toujours votre accès personnel, avec votre clé
personnelle.
Remarque : si le conteneur a été créé par quelqu'un d'autre, et qu'il vous a été
envoyé, il ne contiendra pas forcément votre clé personnelle. Si vous avez une clé
RSA, ce sera généralement le cas puisque votre correspondant aura utilisé votre
certificat. Mais s'il s'agit d'un mot de passe, il est plus probable qu'il s'agira d'un mot
de passe convenu entre vous, qui ne sera pas forcément le même que votre mot de
passe habituel (sauf si vous avez convenu de celui-là).
Le conteneur peut aussi contenir d'autres accès, de type RSA, qui sont imposés par votre
administrateur dans la configuration du produit.
Si vous souhaitez qu'un conteneur serve de "valise diplomatique" d'échange avec une ou
plusieurs personnes, vous devez d'abord convenir d'un "secret" avec eux. Si votre
correspondant dispose d'une clé RSA et du certificat associé, vous pouvez utiliser
directement ce certificat. Sinon, vous pouvez convenir avec lui d'un mot de passe.
Pour accéder à la gestion des accès, vous pouvez au choix :

Utiliser le menu contextuel sur le fichier conteneur lui-même (click-droit sur le fichier,
option [Liste des accès] ;
Ouvrir le conteneur, et faire un click-droit dans le fond de la fenêtre, option [Liste des
accès].
La fenêtre qui apparait présente les accès
existants, et permet d'en ajouter ou d'en
retirer. Quand il s'agit d'accès par clé
RSA/Certificat, vous pouvez consulter le
certificat.
Noter le pictogramme qui diffère en fonction
type d'accès, et la bulle d'aide qui donne des
informations complémentaires.
du
10 – Retirer un accès
A partir de la fenêtre précédente, il suffit de sélectionner l'accès et d'utiliser le bouton
[Retirer] ou le menu contextuel [Supprimer]. Après confirmation, l'accès est retiré de la
fenêtre.
Lorsque toutes les modifications sur les accès sont terminées, vous pouvez utiliser le
bouton [Appliquer] pour les rendre opérationnelles, ou encore le bouton [OK] (qui, lui,
fermera aussi la fenêtre).
Noter que dès que les accès sont modifiés, mais pas enregistrés, le titre de la liste
("Accès") prend un astérisque ("Accès*").
8
11 – Changer un mot de passe
Toujours à partir de la fenêtre des accès,
sélectionner un accès de type mot de passe
utiliser le menu contextuel [Changer le mot de
passe].
Comme pour toute création de mot de passe,
il doit être saisi deux fois pour vérification, et
obéir aux contraintes de "force".
Note : si vous ne vous souvenez pas de l'ancien mot de passe, vous pouvez aussi
supprimer cet accès, et en créer un autre, de même nom, avec un nouveau mot de passe.
Vous ne perdrez que quelques informations de gestion (la date originale de création de
l'accès).
12 – Ajouter un accès par mot de passe
A partir de la fenêtre des
accès, cliquer sur le bouton
[Ajouter]. Une fenêtre
apparait avec plusieurs
onglets, dont notamment le
premier s'appelle [Mot de
passe partagé].
Sélectionnez-le, puis :

Choisissez un nom pour
cet accès. Ce nom peut
dépendre de la façon
dont il va être utilisé. S'il
s'agit simplement d'une
convention privée avec
un autre personne, vous pouvez entrer son adresse email, par exemple. S'il s'agit d'un
accès qui sera utilisé par plusieurs personnes, vous pouvez mettre le nom d'un groupe
de travail.
Cette information est libre, mais doit être claire, parce qu'elle apparait ensuite dans la
demande de clé quand on accède au contenu du conteneur.
Tapez le mot de passe convenu, ou choisissez-en un nouveau, que vous transmettrez
ensuite au(x) correspondant(s), par un canal secondaire.
Comme pour toute création de mot de passe, il doit être saisi deux fois pour vérification, et
obéir aux contraintes de "force".
13 – Ajouter un accès par certificat RSA
A partir de la même fenêtre, sélectionnez l'onglet [Certificats de correspondants] ou
l'onglet [Annuaires]. L'utilisation des annuaires est décrite au paragraphe suivant.
Localement, sur votre ordinateur, les certificats peuvent être trouvés dans :

Des fichiers de certificats. Il y a de multiples formats standards, la plupart sont
supportés (fichiers avec les extensions .cer, .p7b, etc.). Si vos correspondants vous
donnent leurs certificats sous forme de fichiers, vous les déposez habituellement dans
9

un dossier, et vous pouvez ici rechercher ces fichiers, en sélectionner plusieurs, et
vous pourrez voir les certificats qu'ils contiennent, et sélectionner ceux qui vous
intéressent.
Des magasins de certificats que gère votre système Windows, ce qui est une autre
manière de les enregistrer quelque part pour pouvoir les retrouver. Vous pouvez les
gérer avec l'Internet Explorer, menu [Outils], onglet [Contenu], bouton [Certificats].
C'est pourquoi, en appuyant sur le bouton qui reprend le pictogramme de Internet
Explorer, la fenêtre se remplit avec les certificats disponibles dans ces magasins.
Les certificats sont vérifiés en
temps réel dans cette fenêtre. En
fonction des résultats, ils ont un
pictogramme qui diffère.
Le pictogramme "sablier" indique
que la vérification est en cours.
Elle peut parfois prendre un peu de
temps, s'il faut télécharger des
listes de révocation (CRLs).
Î Penser à faire afficher la bulle d'aide pour connaitre la raison d'un status de vérification.
Î Noter également l'existence de menus contextuels, sur les certificats et dans le fond de
la liste, qui permettent :
-
d'afficher un certificat ;
de refaire une vérification sur un certificat ;
de tout décocher, tout cocher, et demander à ce que les certificats soient cochés
ou décochés par défaut quand ils sont affichés (s'ils sont utilisables).
14 – Utilisation d'un annuaire de certificats
Certaines entreprises mettent à disposition des annuaires (appelés "annuaires LDAP")
permettant de retrouver les certificats des personnes, à partir de leur nom ou d'une
adresse email. C'est souvent le cas également d'organismes de certification publics ou
commerciaux.
La recherche s'effectue en donnant l'adresse de l'annuaire, et le nom, partiel ou complet, à
rechercher. Elle demande évidemment une connexion disponible vers l'annuaire ciblé.
Si votre ordinateur fait partie d'un domaine Windows, qui, souvent, intègre un annuaire
LDAP, son adresse est détectée et proposée. Cela fonctionne si, en interne, il y a une PKI
(infrastructure de certificats) et que les certificats sont publiés à cet endroit.
Un exemple de serveur disponible
librement est
"directory.verisign.com", vous
pouvez essayer avec des noms
américains, comme "parker" ou
"johnson".
Dans cette fenêtre, on retrouve les
mêmes options dans les menus
contextuels que pour la précédente.
10
Administration
Le logiciel est prévu pour une utilisation en entreprise. Il est compatible avec les
logistiques les plus répandues, qui permettent notamment :

La télé-installation (par les GPO des serveurs Windows, ou par des produits
spécialisés, comme SMS, Tivoli, etc.) ;
La configuration d'options avec les "policies" (GPO), locales, ou de domaines, avec des
contrôleurs de domaine Windows ou Novell ;
L'utilisation de PKIs de toutes marques, des services associés, comme LDAP, et de la
politique interne en matière de gestion de clés (mots de passe, clés RSA, types de
porte-clés, marques de carte à puce, etc.) ;
Il peut s'accorder avec des environnements simples et autonomes (portables isolés, petits
bureaux) et des environnements avec une logistique plus riche.
Dans le cadre d'un environnement administré, les étapes consistent à :

Comprendre les différents paramètres des politiques de sécurité (GPOs), et définir sur
papier si nécessaire leurs valeurs ;
Décider de la façon dont ces policies vont être gérées : via le ou les contrôleurs de
domaines / domaines / forêts, ce qui est l'option recommandée dans un
environnement qui dispose de cette logistique, ou bien localement sur les postes
(policies locales). Dans ce dernier cas, vous pouvez opter pour une "masterisation" du
logiciel, pour que les policies soient transmises avec le package d'installation, quelle
que soit le moyen d'installation retenu.
Etablir un mode de diffusion du logiciel : comment va-t-il être installé, par qui ?
11
Configuration (policies/GPO)
Le système des GPOs de Windows est supposé connu et n'est pas décrit ici. Rappelons
simplement que, en local, il est accessible via [gpedit.msc], pour les policies locales, sur un
serveur Windows, il est accessible via [Utilisateurs et Ordinateurs ActiveDirectory]
(propriétés d'un domaine ou d'une unité organisationnelle) ou encore via [gpmc.msc] (sur
certains serveurs seulement).
Le modèle d'administration des policies s'appelle [zed_policies_fra.adm] (ou
[zed_policies_enu.adm] pour l'anglais) et il se trouve dans le dossier [Windows/Inf]. Pour
l'utiliser sur le contrôleur de domaine, il suffit de le recopier dans le même dossier sur le
serveur. Il faut le charger avec l'outil utilisé ([[GPEDIT], [GPMSC], …) dans les "modèles
d'administration" (menu contextuel [ajouter/supprimer des modèles]).
Toutes les policies du produit se trouvent dans la rubrique [Configuration Ordinateur].
Chaque politique porte un numéro, et un texte d'aide lui est associé. Pour configurer une
politique, il suffit de double-cliquer dessus.

Politique activée : l'action de la politique est active. Cette action peut être une
interdiction ou une autorisation. Quelques fois, il peut y avoir une valeur associée.
Quand une politique est activée à un certain niveau dans la hiérarchie
forêt/domaine/unité organisationnelle d'un réseau Windows, elle ne peut être modifiée
à un niveau inférieur, et a fortiori pas non plus sur les postes (policies locales).
Politique désactivée : l'action de la politique n'est pas active, c'est comme si elle n'est
pas configurée. Ce cas n'a de sens que sur un contrôleur de domaine (ou domaine,
foret, unité organisationnelle), car cela permet d'empêcher qu'un niveau hiérarchique
inférieur puisse l'activer.
Politique non configurée : l'action de la politique n'est pas active. Mais dans une
hiérarchie forêt/domaine/unité organisationnelle d'un réseau Windows, elle peut être
modifiée (activée ou désactivée) à un niveau inférieur.
12
P050 – Identification des policies
Î Valeur de type texte – Contenu libre
Cette politique n'a aucune influence sur le logiciel, et son contenu est libre. Cela peut être
un commentaire, une date, un numéro de version, … Elle vous permet d'identifier le "jeu
de policies" et, sur les postes, ensuite, de consulter cette information pour identifier
aisément d'emblée une version de configuration.
P102 – Interdire les accès par mots de passe
Î Valeur de type Oui/Non. Valeur par défaut : Non (non interdits, donc autorisés).
Permet d'interdire les accès de type "mot de passe" dans les conteneurs chiffrés. Activer
cette politique empêchera l'utilisateur de :

Choisir un mot de passe comme clé personnelle (à l'initialisation) ;
D'ajouter des accès par mots de passe dans des conteneurs ;
D'ouvrir un conteneur avec un accès par mot de passe, même si ce conteneur en
contient.
Le bouton-pictogramme [mots de passe] (le premier verticalement) dans les fenêtres de
demande de clé d'accès ne sera pas affiché. De même, l'onglet [Mots de passe partagés]
n'apparait pas dans la fenêtre d'ajout d'accès.
Cas d'usage : la politique interne est de ne pas utiliser d'accès par mot de passe, même
pour des conteneurs chiffrés. Il n'est pas très courant d'activer cette politique, car les mots
de passe sont bien pratiques pour les échanges avec des tiers extérieurs, même quand il
existe des PKIs.
Voir aussi : P107/P
P108 pour la force imposée des mots de passe.
104/1
105 pour autoriser et interdire les autres types d'accès.
Voir aussi : P103/1
P103 - Interdire l’utilisation de fichiers de clés PKCS#12
Permet d'interdire l'ouverture de conteneurs au moyen de clés d'accès de type 'clé RSA'
hébergés dans des porte-clés "fichiers" au format PKCS#12 (qui portent généralement
l'extension .p12 ou .pfx).
La conséquence directe de cette politique est que le bouton-pictogramme [fichier de clés]
(le deuxième verticalement) dans les fenêtres de demande de clé d'accès ne sera pas
affiché.
Cas d'usage : la politique interne est de ne pas utiliser de fichiers de clés, ou de ne pas
utiliser de clé RSA (absence de PKI). Pour ce dernier cas, configurer aussi P104 et P105.
Voir aussi : P102/1
104/1
P104 - Interdire l’utilisation de cartes/tokens PKCS#11
Permet d'interdire l'ouverture de conteneurs au moyen de clés d'accès de type 'clé RSA'
hébergés dans des porte-clés PKCS#11 (cartes à mémoire, tokens USB).
Attention, cette politique interdit en fait l'utilisation de l'interface PKCS#11 pour mettre en
œuvre ces porte-clés et clés. Mais il se peut qu'ils soient accessibles également au travers
d'une autre interface (CSP). Pour complètement les interdire, il faut également activer la
politique P105.
Cas d'usage : la politique interne est de ne pas utiliser de cartes ou tokens ou bien de ne
pas utiliser les interfaces PKCS#11 pour utiliser des porte-clés cartes à mémoire ou tokens
USB.
13
Zed! sait reconnaitre la plupart des bibliothèques PKCS#11 du marché. Cependant, les
noms de ces bibliothèques peuvent changer avec de nouvelles versions. La politique P296
permet d'étendre (ou de personnaliser) cette liste.
Les règles de gestion des 'middleware' PKCS#11 varient en fonction des constructeurs.
Quand on utilise des cartes ou tokens RSA, le choix entre l'interface PKCS#11 et l'interface CSP
est avant tout ergonomique. Ce n'est pas un choix de sécurité, car dans tous les cas la clé RSA
reste hébergée par la carte et les calculs associés sont effectués par la carte. La plupart des
fabricants de cartes/tokens fournissent les deux implémentations.
En mode PKCS#11, la fenêtre d'ouverture de Zed! apparaitra toujours.
En mode CSP, c'est la fenêtre du fabricant qui apparait.
Le 'single-login' complet avec le SmartCardLogin de Windows n'est possible normalement qu'en
mode CSP. Certains fabricants, cependant, savent réutiliser le contexte d'ouverture
CSP/SmartCardLogin pour l'étendre aux applications PKCS#11.
Restriction connue : certains fabricants ne supportent pas que la clé RSA hébergée dans la
carte/token chiffre des clés symétriques (DES, AES, …) de longueur supérieure à 128 bits.
Dans ce cas, il faut configurer la politique P290 pour limiter la taille des clés symétriques
utilisées par Zed!.
Voir aussi : P296 pour modifier la liste des PKCS#11 utilisés.
Voir aussi : P102/1
103/1
P105 - Interdire l’utilisation des fournisseurs CSP
Permet d'interdire l'ouverture de conteneurs au moyen de magasins de clés CSP (Microsoft
CryptoAPI). Ces magasins CSP peuvent être les magasins Windows standard ou bien des
magasins tierce-partie (la plupart des fabricants de cartes & tokens RSA proposent un runtime CSP).
Cas d'usage : la politique interne est de ne pas utiliser d'interfaces CSP (même tiercepartie).
Remarques :

l'utilisation des fournisseurs CSP, si elle est autorisée, est prioritaire sur les autres
types d'accès : en effet, ce standard demande que ce soit le CSP lui-même qui
effectue les interfaces graphiques de validation d'utilisation des clés (confirmation,
demande de code, etc.). Pour éviter de d'abord valider la fenêtre d'ouverture Zed!,
puis celle du CSP, c'est d'abord celle du CSP qui est présentée.
Un CSP n'est invoqué que s'il présente une solution de clé (certificat et clé privée RSA)
acceptable pour la cible à ouvrir (conteneur). En fonction de leur implémentation, leur
réaction ergonomique peut varier. Par exemple, certains peuvent afficher une
demande d'introduction de carte limitée à la clé demandée, d'autres peuvent accepter
toutes les cartes introduites.
Utilisation avec le SmartCardLogin de Windows : avec certains middleware 'CSP',
l'ouverture de la carte/token à l'ouverture de session Windows 'vaut' pour toutes les
applications de la session Windows ouverte. Dans ce cas, l'ouverture d'un conteneur
sera automatique et transparente, puisqu'une solution de clé est disponible et déjà
ouverte.
Voir aussi : P102/1
103/1
14
P107/P108 - Force requise des mots de passe
Î Valeur numérique pour la "force" (valeur par défaut à 40), et choix possible '1', '2' ou '3'
pour la complexité (valeur par défaut : 2).
La force (P
P107) d’un mot de passe est évaluée à partir de plusieurs facteurs dont la
longueur, le nombre de familles de caractères utilisées, et la répétition d’un même
caractère (liste non-exhaustive). De plus, la complexité (P
P108) représente la fréquence de
passage d’une famille de caractère à une autre. Un mot de passe court mais complexe peut
avoir une force équivalente à celle d’un mot de passe plus long, mais moins complexe.
La valeur par défaut de 40 pour la force représente un compromis entre la pénibilité de
saisie et la force du mot de passe. Augmenter la complexité requise permettra de réduire
la taille demandée des mots de passe, mais l'utilisateur devra utiliser des caractères moins
'habituels'. Baisser la complexité relaxe cette contrainte, mais oblige à avoir des mots de
passe plus longs.
Cette politique s'applique pour :

le choix initial de son mot de passe par l'utilisateur ;
tout ajout d'accès de type 'mot de passe' dans un conteneur ;
tout changement de mot de passe pour un accès de type 'mot de passe' existant dans
un conteneur.
Cas d'usage : fonction de la politique interne.
Modifier ces valeurs n'a pas d'effet rétroactif sur les mots de passe déjà configurés.
Voir aussi : P102 pour autoriser ou interdire les accès par mots de passe.
P129 – Utilisation du certificat personnel dans ActiveDirectory
Î Valeur de type numérique (0=désactivé, 1=si possible, 2=obligatoire).
Valeur par défaut : 0 (désactivé).
Cette option n'est possible que pour des clés d'accès RSA (nécessité d'une PKI).
Quand il est possible de le mettre en œuvre, ce mode est très pratique et simplifie
considérablement la tache de l'administrateur et celle de l'utilisateur. Il permet en effet de
déterminer simplement, sans ambigüité et sans poser de question la clé que doit présenter
l'utilisateur pour créer ses conteneurs chiffrés.
Il faut pour cela que la PKI publie les certificats des utilisateurs dans leurs profils
ActiveDirectory, dans le champ réservé et prévu à cet effet ([[UserCert]). La PKI peut être
n'importe quelle PKI pourvu qu'elle effectue cette publication.
Noter que cela ne signifie pas pour autant que le serveur LDAP de certificats (si serveur il y
a) soit ActiveDirectory, il peut très bien y avoir, par ailleurs, un autre serveur LDAP.
Simplement, via ActiveDirectory, il est aisé de faire une corrélation (mappage) entre
l'utilisateur (de domaine) courant, son profil ActiveDirectory, et le certificat de sa clé de
chiffrement.
Sur le serveur ActiveDirectory, en lançant [Utilisateurs et Ordinateurs ActiveDirectory], on
peut demander le détail des propriétés d'un utilisateur. Il faut au préalable avoir demandé
l'affichage "avancé" (Menu [Affichage] de la MMC). Il apparait alors un onglet [Certificats
Publiés]. Cela correspond au champ que Zed! va interroger quand cette politique est
configurée.
Quand cette publication est effectuée par la PKI, on constate généralement que ce champ
contient rapidement un certain nombre de certificats. Rares sont les PKI qui "dépublient'
les certificats périmés, révoqués, etc., et toutes utilisent ce même champ (multi-valué)
pour publier tous les certificats d'un utilisateur (authentification, signature, chiffrement, …).
Ce n'est pas un problème pour Zed!, qui fait le tri : il élimine les certificats qui ne sont pas
des certificats de chiffrement, les certificats périmés et ceux qui sont révoqués. Si plusieurs
certificats sont finalement éligibles, il prendra le plus récent (date de début de validité la
plus récente).
15
Quand il s'agira de déterminer la clé de l'utilisateur, au cours de la procédure initiale, ce
dernier n'aura pas le choix de sa clé, il devra présenter LE porte-clés correspondant
(fichier, carte).
Si la valeur de cette politique indique 'obligatoire', alors l'utilisateur devra obligatoirement
présenter la clé correspondant au certificat publié (ou annuler). S'il n'y a pas de certificat
publié, l'opération demandée sera refusée.
Noter que cela implique que pour la procédure d'initialisation, l'utilisateur soit raccordé à
son domaine (uniquement à ce moment). Sinon, il devra attendre de l'être pour effectuer
l'opération (qui a été refusée). Cela implique également que l'utilisateur dispose
effectivement d'une clé et d'un certificat, et que ce dernier soit obligatoirement publié dans
ActiveDirectory.
Si la valeur indique 'si possible', alors si un certificat est trouvé dans ActiveDirectory, il
sera utilisé (et imposé), l'utilisateur devra fournir la clé correspondante. Sinon, si
ActiveDirectory n'est pas joignable, ou s'il n'y a pas de certificat publié, alors l'Assistant
initial apparaitra, et l'utilisateur pourra lui-même choisir la clé qu'il utilise.
Cas d'usages : activer cette politique dès lors que la PKI publie les certificats dans
ActiveDirectory (recommandé).
P131 – Accès obligatoires
Î Valeur de type LISTE. Le 'nom de valeur' doit contenir un nom de fichier (avec le chemin
d'accès), et la 'valeur' doit contenir l'expression "hash=XX YY ZZ…", où XX YY ZZ… contient
l'empreinte numérique SHA1 du fichier désigné.
Il est possible de définir autant de fichiers dans la liste qu'on le souhaite. Ces fichiers
doivent être des fichiers certificats (.cer, codage Base64 ou binaire). Il n'est pas possible
de définir d'accès obligatoire par mot de passe.
Attention, il est fréquent de faire des erreurs dans la saisie du chemin d'accès du fichier.
Les accès réseau sont supportés (et fréquemment utilisés), il faut les mettre sous la forme
UNC (\\\Serveur\Partage). Si un emplacement local est désigné, alors il faut s'assurer que
ces fichiers existent bien à cet endroit, sinon la création de conteneurs sera rejetée.
Cette politique est très importante. Elle permet de définir un moyen de recouvrement, et
de faire en sorte qu'il s'applique automatiquement dans les conteneurs chiffrés.
Si cette politique mentionne un fichier qui ne peut être trouvé, ou qu'il ne correspond pas à
l'empreinte fournie, alors l'action de l'utilisateur est refusée.
Pour obtenir l'empreinte du fichier : le plus sûr est d'utiliser la commande "z
zedcmd
showhash". Il est déconseillé d'afficher le contenu du certificat et de se servir de
l'empreinte calculée par l'afficheur de certificats Windows. Non pas qu'il soit erroné, mais
son mode de calcul ne dépend pas du fichier certificat et de son format, mais de la valeur
du certificat. Or Zed! veut, lui, l'empreinte du fichier. Il y a aura une différence en fonction
de l'encodage du fichier (Base64 etc.).
Cas d'usages : quasi-systématique, et parmi les premières choses à faire. Le seul cas où
cette politique peut être ignorée est quand la PKI séquestre les valeurs des clés des
utilisateurs.
Voir aussi : l'outil [zedcmd], qui permet de calculer une empreinte sur un fichier
(commande [showhash]), et de masteriser le logiciel pour 'injecter' le ou les fichiers
certificats dans le programme d'installation pour qu'ils soient diffusés en local (commande
[master]).
16
P141 – Racines de certificats autorisées
Î Valeur de type LISTE. Le 'nom de valeur' contient un libellé libre ('My root' par
exemple), et la 'valeur' doit contenir l'expression "sha1=XX YY ZZ…", où XX YY ZZ…
contient l'empreinte numérique SHA1 du certificat désigné.
Cette politique permet de restreindre les clés RSA que les utilisateurs peuvent utiliser. Elle
s'applique uniquement à la sélection initiale de la clé, mais pas aux ajouts d'accès par
certificats.
L'objectif de cette politique est d'éviter que des utilisateurs utilisent des clés RSA qu'ils
auraient générées eux-mêmes avec quelque moyen que ce soit (Internet, outil
téléchargeable, clé personnelle, etc.), et de garantir qu'ils n'utilisent que des clés issues de
la PKI officielle. Le risque étant qu'ils chiffrent avec "n'importe quoi".
Cette politique est extrêmement importante dans un cas précis : la politique est de ne pas
appliquer de clé de recouvrement (ajout systématique d'une clé 'maison' à toute cible
chiffrée) (cf P131) parce que la PKI séquestre les clés RSA de chiffrement des utilisateurs.
Dans ce cas, il est bien évidemment très important de restreindre les clés utilisables aux
seules clés séquestrées, faute de quoi la fonction de recouvrement n'est pas assurée.
Il est possible de définir ici plusieurs certificats, et ces certificats peuvent ne pas être des
racines, mais des autorités intermédiaires (voire même des certificats finaux !). Attention
cependant, cette politique ne fournit pas les certificats eux-mêmes, qui doivent donc être
disponibles dans l'environnement PKI (magasins locaux, LDAP, joints aux porte-clés).
Mentionner ici un certificat [d'autorité] autorisé ne signifie pas que les contrôles de
certificats sont arrêtés à son niveau. Par exemple, si un certificat d'autorité intermédiaire
est mentionné, cela signifie qu'on a le droit d'utiliser les certificats qu'elle a émis, à
condition qu'ils soient valides, et que celui de l'autorité ici indiquée le soit aussi.
Cas d'usages : indispensable si la PKI séquestre les clés utilisateurs ; pour les autres cas, il
toujours sain de spécifier cette politique.
P142/P143 – Autoriser l'utilisation en dehors des dates de validité (et
délai de prolongation)
Î Valeur de type Oui/Non. Valeur par défaut : Non (contrôle complet).
Î Pour le délai, valeur numérique (en jours). Minimum: 0, Maximum: 365
Valeur par défaut : 90 jours
Cette politique P142 permet de continuer à utiliser un certificat (en réalité, la clé de
l'utilisateur) quelques temps après qu'il soit périmé. La politique P143 permet de définir ce
délai.
En effet, il arrive fréquemment que, malgré tous les rappels à l'ordre, les utilisateurs
n'effectuent pas la procédure demandée par la PKI pour renouveler leurs certificats ou
leurs clés. Dans ce cas, ils se retrouvent bloqués avec l'impossibilité d'ouvrir leurs
conteneurs.
Cette politique permet de leur accorder un délai de grâce supplémentaire : pendant ce laps
de temps, Zed! acceptera l'ouverture de conteneurs avec leur clé et leur certificat périmés.
Cette politique s'applique pour la sélection de clé initiale, l'ouverture de conteneur au
moyen de la clé et aux certificats tiers ajoutés dans un conteneur.
Quand ce délai est dépassé, ou quand cette politique n'est pas configurée, l'ouverture est
refusée avec un message explicite.
Cas d'usages : libre
17
P146 – Relaxer le contrôle d'usage de clé
Î Valeur de type Oui/Non. Valeur par défaut : Non (contrôle complet).
Normalement, le logiciel Zed!, en tant qu'application de chiffrement, refuse d'utiliser la clé
associée à un certificat qui n'autorise pas explicitement le chiffrement ('KeyUsage' au sens
X509).
Cette politique permet de relaxer ce contrôle et d'utiliser une clé et un certificat pour du
chiffrement quelle que soit la limitation imposée par le certificat.
Cette politique s'applique pour la sélection de clé initiale, l'ouverture de conteneur au
moyen de la clé et aux certificats tiers ajoutés dans un conteneur.
Cas d'usages : rares. Cette politique ne doit être utilisée que temporairement quand il n'y a
pas moyen de faire autrement (parc de certificats existants n'ayant pas prévu l'usage de
chiffrement).
P147 – 'Extended key usages' autorisés
Î Valeur de type LISTE. Le 'nom de valeur' doit contenir l'OID (Object Identifier
normalisé) de l'usage (exemple : 1.3.6.1.5.5.7.3.4 pour la messagerie électronique
sécurisée), la 'valeur' elle-même étant libre (il est possible de mettre un commentaire ou
un libellé plus explicite).
Cette politique s'applique dans un environnement où les utilisateurs disposent de plusieurs
clés (certificats) de chiffrement, et que l'on souhaite en compartimenter les utilisations
(chiffrement de mails, de fichiers, de réseau…). Elle permet de spécifier pour Zed! le ou les
types de certificats que l'utilisateur peut sélectionner, et leur éviter ainsi de se tromper.
Cette politique ne s'applique que pour la sélection de clé initiale, elle ne s'applique pas aux
certificats tiers ajoutés dans un conteneur.
Cas d'usages : plusieurs clés de chiffrement par utilisateur
P195 – Serveurs LDAP prédéfinis
Î Valeur de type LISTE. Le 'nom de valeur' correspond à un commentaire (libre), la
'valeur' contient la définition technique du serveur LDAP.
Cette politique permet de pré-configurer le ou les serveurs LDAP qui sont disponibles pour
les utilisateurs, quand ils ajoutent des accès à des conteneurs chiffrés et qu'ils interrogent
des annuaires LDAP pour retrouver les certificats.
Note : la configuration LDAP par défaut permet en général d'adresser des serveurs
courants, comme ADSI ou des annuaires publics, et l'utilisateur pourra toujours fournir un
"host-name" pour utiliser ces serveurs, avec la configuration par défaut.
La configuration technique est sous la forme suivante:
Label=label;Name=dnsaddress;Port=portno;SSL=y/n;BaseDN=baseDN;CertAttr=
attributeAddAttr=additional attributes;Filter=filter
Chaque couple Item=Valeur est séparé des autres par un point-virgule. Si une valeur doit
contenir un point-virgule, alors il faut mettre un anti-slash devant
(exemple: userCertificate\;binary).
Si un champ est vide, mettre champ=;champ suivant.

Le label désigne un nom libre, qui apparait à l'utilisateur.
Le name désigne l'adresse DNS du serveur LDAP (exemple : myldapserver.primx.eu).
Le port désigne le numéro de port LDAP de serveur (en général 389).
Le champ SSL indique si la communication doit s'effectuer en SSL ou non. Le produit
ne supporte pas le SSL avec authentification du client par certificat. Valeur y pour oui
et n pour non.
18

Le champ BaseDN est le Distinguished Name de base des recherches. Consulter
l'administrateur du serveur pour connaitre la valeur si elle est nécessaire (souvent, les
serveurs acceptent qu'elle ne soit pas spécifiée.
Le champ CertAttr désigne le nom de l'attribut, au sens LDAP, contenant le certificat.
La plupart du temps, il s'agit de userCertificate\;binary.
Le champ AddAttr désigne des attributs complémentaires qui seront demandés, pour
affichage à l'utilisateur. S'il y en a plusieurs, il faut les séparer par des virgules.
Exemple courant : cn,email (nom convivial et adresse de courrier).
Le champ Filter est très important et désigne le filtre de la recherche demandée. Ce
champ respecte les différentes normes RFC sur le sujet, et peut permettre des
syntaxes très complexes. La plupart du temps, la valeur (cn\=*%USER%*) suffit. Elle
signifie de rechercher les entrées de l'annuaire dont le nom convivial (Common Name)
contient le critère saisi par l'utilisateur, représenté par le mot-clé %USER%.
Î Voici la configuration par défaut utilisée par le produit lorsqu'on saisit une adresse
d'annuaire 'myldapserver.primx.eu' :
Label=;Name=myldapserver.primx.eu;Port=389;SSL=n;BaseDN=;CertAttr=userC
ertificate\;binary;AddAttr=cn;Filter=(cn\=*%USER%*)
Cas d'usages : quand la configuration technique par défaut utilisée ne fonctionne pas, ou
bien pour établir à l'avance pour les utilisateurs une liste d'annuaires préconfigurés.
P290/P291 – Algorithme cryptographique utilisé pour chiffrer les
conteneurs
Î Choix possibles : AES, DES ou RC2, avec longueurs de clés de 128, 192 ou 256 bits.
Valeur par défaut : AES 256 bits.
Cette politique indique l'algorithme de chiffrement à utiliser et la longueur de clé associée
pour les conteneurs.
Toutes les combinaisons d'algorithmes et de longueurs de clés ne sont pas valides. L'AES
(Advanced Encryption Standard) peut utiliser des clés de 128, 192 ou 256 bits. Le DES
(Data Encryption Standard) peut utiliser des clés 128 ou 192 bits (dont 112 ou 168 bits
utiles seulement), le RC2 peut utiliser des clés de 128, 192 ou 256 bits.
P296 – Cartes et tokens supportés/autorisés (PKCS#11)
Î Valeur de type LISTE "liste de noms/valeurs". Le 'nom de valeur' correspond au nom
publié du driver, la 'valeur' n'est pas utilisée et peut servir à mettre un commentaire.
Cette politique permet d'indiquer une extension PKCS#11 (ou plusieurs) non supportée par
défaut et donc d'utiliser un autre modèle de carte à mémoire ou de token USB.
Par défaut, Zed! recherche certaines versions des extensions PKCS#11 des constructeurs
ActivCard, Aladdin, Axalto, GemPlus, Rainbow.
Il faut indiquer le nom du module PKCS#11 du fournisseur (nom de DLL), sans le chemin
d'accès si ce module est installé dans un répertoire standard du système, ou avec le
chemin d'accès.
Le fait qu'une extension PKCS#11 soit déclarée et ne soit pas présente sur le poste n'est
pas considéré comme une erreur. Simplement, elle ne sera pas opérationnelle. Cela permet
éventuellement de prédéfinir plusieurs "fournisseurs" externes, qu'ils soient installés ou
non.
Cas d'usage : utilisation d'extensions PKCS#11 spécifiques
19
L'outil zedcmd
Cet outil en ligne de commande est installé dans le dossier d'installation du logiciel.
Il offre quelques fonctionnalités pratiques pour l'administrateur :

about)
Afficher la version du système (a
Afficher les policies, telles qu'elles sont 'vues' et résolues coté application (ce qui
parfois différer du paramétrage, quand par exemples de nouvelles valeurs ne sont pas
encore descendues du serveur) (s
showpolicies)
Modifier les policies locales (m
modifypolicies)
Exporter les policies locales dans un fichier texte (e
exportpolicies)
Importer un jeu de policies depuis un fichier texte (iimportpolicies)
Appliquer un "transform" de langue à un package d'installation .msi (ttransform)
Masteriser (préparer) un package d'installation (m
master)
Cet outil s'utilise comme tout programme en ligne de commande.
Î Pour afficher la liste des commandes disponibles, utiliser zedcmd /?.
Î Pour afficher l'aide d'une commande précise, utiliser zedcmd commande /?.
20
Installation & masterisation
Langues
Langue installée et langue de fonctionnement
Le logiciel est disponible en anglais et en français et est compatible "MUI", ce qui signifie
que toutes les langues sont installées, et que les interfaces du produit s'affichent dans la
langue de l'utilisateur ('UI language') et non pas dans la langue du poste.
Sur des systèmes 2000 ou XP de base, la langue de l'utilisateur est toujours celle du poste,
et cela ne fait pas de différence, mais sur des systèmes XP "MUI" (Multiple User Interface),
chaque utilisateur peut avoir sa langue et les interfaces graphiques du système et des
logiciels (compatibles MUI) s'affichent dans sa propre langue.
Langue de l'installation
Il faut distinguer la langue dans laquelle opère le logiciel pour l'utilisateur et la langue du
programme d'installation lui-même (celle de ses écrans éventuels).

Si le programme d'installation est le package "s
setup.exe", alors ce programme
détermine la langue du poste, et exécute l'installation dans la langue du poste. Même
sur des systèmes MUI, c'est une limitation à l'heure actuelle du système d'installation.
Zed! étant MUI, cela ne change en rien le fait que ce qui est installé soit multilangues. La limitation ne concerne que la langue des écrans de l'installation.
Si le programme d'installation est un package "..msi", alors il est mono-langue. C'est
aussi une limitation de Windows Installer. Mais son contenu à installer demeure MUI. Il
est possible de modifier la langue du package en appliquant un "transform" de langue.
Appliquer un "transform" de langue
Cette opération est nécessaire dès lors qu'on cible une installation à partir d'un package
"..msi".
La plupart des outils de téléinstallation (GPO, SMS, etc.) permettent d'appliquer
directement un transform au cours de l'installation. Dans ce cas, il suffit de le configurer
dans cet outil. Mais, si le transform à appliquer est uniquement un "transform de langue",
c'est inutile si l'installation prévue est totalement silencieuse : inutile de traduire des
écrans qui ne s'affichent pas !
L'application d'un transform est une opération standard qui peut être effectuée avec bon
nombre d'outils, gratuits ou payants, du marché. Pour que cette opération soit
immédiatement disponible, elle a été intégrée dans le programme "z
zedcmd.exe" :
zedcmd.exe transform <fichier msi> -t <fichier .mst>
La manière d'obtenir le package .msi et le transform .mst est décrite au paragraphe
suivant.
Packages
Package Setup Zed! […].exe
Le package standard fourni est sous la forme d'un programme "S
Setup Zed!.exe" (le nom
peut varier en fonction de la version).
Ce programme est un exécutable qui enchaine les opérations suivantes :

Détermination de la langue du poste
Extraction du package .msi et des transforms de langue .mst qu'il contient
Ces deux fichiers sont ensuite mis dans un emplacement donné, indiqué plus loin.
21

Le .msi standard extrait est en anglais : si la langue du poste est différente, il applique
automatiquement le transform de langue pour que l'installation s'exécute dans la
langue du poste;
Il exécute l'installation du résultat.
Package Zed! […].msi
Pour obtenir ce package, il suffit d'exécuter une fois l'installation à partir du setup […].exe.
Le package .msi, et les transforms de langue .mst, se trouveront ensuite sous
Windows\DownloadedInstallations.
Sous ce dossier figure un sous-dossier par produit installé (et utilisant cette technologie).
Malheureusement, les noms de ces dossiers ne sont pas très … confortables. Ce sont en
réalité les "Package Codes" (GUID) des [versions de] produits.
Comment reconnaitre celui de Zed! ?

Son nom est toujours sous la forme {xxxxxxxx-xxxx-6CA8-8868-36F59DEFD14D},
les xxx pouvant varier et contenant le numéro de build et de version.
A l'intérieur du dossier, le fichier .msi s'appelle toujours Zed! […].msi, […] pouvant
contenir le numéro de build (génération) de la version.
Dans le même dossier, vous trouverez aussi le transform de langue, sous le nom 1036.mst
ou plus rarement 1033.mst. Le nombre 1036 désigne en codification internationale la
langue française et 1033 la langue anglaise. 1036.mst est donc le fichier qui permet de
"traduire" le programme d'installation .msi en français, ce dernier étant toujours en
anglais.
Installation
Utilisation de "Setup Zed!.exe"
Le programme Setup.exe s'utilise comme la plupart des programmes de ce type du
marché. Il contient et exécute un fichier Microsoft Installer "Z
Zed!.msi", et applique
éventuellement un "transform" de langue si la langue retenue pour l'installation est le
français.
Î Pour passer des directives de type "M
MSIEXEC" au programme "S
SETUP", utiliser la
syntaxe suivante :
Setup xxx.exe /V"instructions msiexec"
Î Pour forcer l'exécution dans une langue donnée, utiliser l'argument /L1036 (français) ou
/L1033 (anglais)
Setup xxx.exe /L1036
Î La version "administrée/installation en réseau" peut être préparée avec la directive /A
et, optionnellement, le dossier cible :
Setup xxx.exe /A [TARGETDIR=…]
Attention cependant, ce mode recèle quelques pièges. Le fichier .msi qu'il extrait et met à
disposition ne contient que la procédure d'installation, sans les fichiers programmes,
puisque, par définition, ils sont "éclatés" dans le dossier cible, qui, du coup, doit
impérativement être disponible pour réaliser des installations sur le poste cible.
De plus, et même si les fichiers "éclatés" dans le dossier le sont sous forme multi-langues,
la procédure d'installation (z
zed!.msi), elle, est toujours en anglais car c'est la langue par
défaut du produit. Et ce MEME si on spécifié une langue lors de l'exécution de la commande
setup /a : cette langue ne concernait que la commande elle-même, et pas son résultat.
Pour obtenir un setup "administré" (installation en réseau) en français, il faut donc
appliquer le "transform de langue" comme indiqué plus haut sur le fichier zed!.msi extrait.
C'est important, car cela ne concerne pas que la langue de l'installation (qui peut être sans
22
importance pour une installation silencieuse) mais aussi quelques textes qui sont installés
ensuite sur les postes utilisateurs (notamment les éléments du menu Démarrer).
Utilisation de "Zed!.msi"
Comme indiqué dans les paragraphes précédents, ce fichier peut exister sous deux
formes :

Complet, avec les fichiers programmes, s'il a été récupéré après une première
installation dans

Partiel, avec uniquement la procédure d'installation, s'il est obtenu à la suite d'une
préparation pour 'Installation en réseau' (s
setup.exe /A ou msiexec /A sur un fichier
complet).
Windows\Downloaded Installations\{xxxxxxxx-xxxx-6CA8-8868-36F59DEFD14D}
Dans les deux cas, il sera toujours en anglais, et il faut le transformer en français comme
indiqué précédemment.
Ce fichier .msi s'utilise ensuite comme tous les fichiers de ce type, avec MSIEXEC et les
outils de télé-diffusion.
Options spécifiques d'installation

Il n'y a pas de demande de numéro de série ou autre instrument de contrôle de
licence ;
Le dossier cible d'installation par défaut est <Program Files>\PrimX\Zed!. La propriété
TARGETDIR peut être spécifiée en ligne de commande de l'installation pour changer
cette option :
Msiexec /i zed!.msi TARGETDIR=C:\Zed!
Setup zed!.exe /V"TARGETDIR=C:\Zed!"

ou
L'installation silencieuse /qn[+] /qb[+] est possible.
La propriété ZC_HIDELICENCEPAGE=1 permet de ne pas afficher la page de licence ;
La propriété ZC_POLICIES=<nom de fichier> permet d'installer des policies sur le
poste cible. Le fichier de policies doit être disponible au moment de l'installation, et
doit avoir été préparé avec la commande zedcmd exportpolicies ;
Certaines de ces options peuvent être pré-spécifiées via la masterisation.
Masterisation
Il n'est pas possible de masteriser un programme setup.exe, mais uniquement un fichier
.msi que l'on aura extrait et localisé (langue) comme indiqué plus haut.
La masterisation permet de figer certaines options à l'intérieur du .msi (et donc en avance)
et non pas depuis l'extérieur (ligne de commande) au moment de l'exécution de
l'installation :
zedcmd.exe master zed!.msi [options]
Le programme ZEDCMD.EXE est installé avec le produit. Le "préparateur" peut donc utiliser
cet outil avec une première installation isolée.
Les options possibles sont :

Spécifier un fichier logo, qui se met en incrustation dans les fenêtres d'ouverture de
conteneur. Ce fichier doit être au format BMP WINDOWS, et doit avoir une dimension
de 398 * 60 pour une incrustation totale ou inférieure ou égale à 314*56
(recommandé : 150*50) pour une incrustation partielle. Le fichier spécifié sera ajouté
dans la procédure zed!.msi et installé sur les postes cibles ;
Spécifier un fichier de policies à appliquer automatiquement sur les postes cibles ; ce
fichier est ajouté dans la procédure zed!.msi et doit avoir été préparé avec la
commande zedcmd exportpolicies ;
23

Spécifier un certificat à ajouter comme "accès obligatoire" (supplémentaire) à tout
conteneur chiffré. Pour être effectivement opérationnel, ce fichier doit être référencé
dans les policies (P
P131). Cette option n'a d'intérêt que si vous n'avez pas fait le choix
de référencer dans cette politique un chemin vers un partage réseau, et qu'il faut donc
installer localement ce fichier.
Ne pas afficher la page de licence ;
Cas des policies
Le Responsable de la Sécurité "prépare" les policies qu'il souhaite voir appliquées sur un
poste isolé. Il utilise pour cela l'outil standard Windows GPEDIT.msc.
Il utilise ensuite la commande suivante :
zedcmd.exe exportpolicies –f <fichier policies.ini>
C'est ce fichier qui doit ensuite être utilisé pour l'application sur les postes cibles, soit par
masterisation, soit par directive lors de l'installation.
Attention cependant :

Si les postes cibles sont membres d'un domaine Windows, ce n'est peut-être pas la
meilleure méthode : il est préférable, et plus simple, d'utiliser la logistique standard de
gestion des policies que ce dernier offre : il suffit de les configurer sur le contrôleur de
domaine (ou le domaine, ou la forêt) pour que les postes en héritent
automatiquement ;
Si un poste cible est membre d'un domaine, et que l'installation est exécutée alors
qu'il n'est pas raccordé au domaine, les policies masterisées ou passées en directive
ne seront pas installées car Windows le refusera.
Donc, en résumé :

Si les postes cibles ne sont pas membres d'un domaine, la seule solution pour installer
des policies préconfigurées est de les masteriser ;
Si les postes cibles sont membres d'un domaine, il faut soit passer par le domaine et
ne pas masteriser les policies, soit s'assurer que les postes sont connectés au domaine
lors de l'installation (ce qui est évidemment le cas en cas de télé-installation).
Mises à jour
L'installation de Zed! détecte et traite les versions antérieures éventuellement installées.
L'opération est toujours un "major upgrade", qui consiste –en une seule fois - à désinstaller
et réinstaller, sans perdre, toutefois, les policies installées et les préférences utilisateur.
Cependant, si l'installation a été masterisée, il convient de la remasteriser avant diffusion
d'une nouvelle version.
En règle générale, et sauf indication explicite contraire, il n'y a jamais d'opération
particulière "de migration ou de maintien de compatibilité" lors de l'installation d'une
version suivante.
Désinstallation
La désinstallation complète du produit :

Efface les policies existantes sur le poste, si possible (i.e. sauf appartenance à un
domaine) ;
N'efface pas les préférences utilisateur en Registry (car difficile voire impossible
d'énumérer tous les profils ayant existé) ;
NE DECHIFFRE PAS (et ne cherche pas à déchiffrer) les conteneurs existants.
Pour ne pas désinstaller les policies (en vue d'une réinstallation ultérieure), il est possible
de spécifier la propriété ZC_KEEP_POLICIES=1 dans la désinstallation (avec msiexec.exe).
24
Notes
25