exchange-server-210_(extrait-du-livre)

Editions ENI

Exchange Server 2010

Conception de l’infrastructure, Implémentation, Administration

CollectionRessources Informatiques

Extrait

Windows PowerShell(versions 1 et 2)

Guide de référence pour l’administration système

CollectionExpert IT

Extrait

A. Introduction

La gestion des serveurs de l'organisation s'effectue à partir de la console MMC mais aussien PowerShell. Vous allez découvrir dans le chapitre sur PowerShell que certaines fonctionsdisponibles en ligne de commande ne le sont pas en mode graphique. Le nœud Configura-tion du serveur permet de gérer les rôles des serveurs suivants :- Les serveurs de boîtes aux lettres qui stockent les bases de données.- Les serveurs d'accès au client qui fournissent un accès pour les clients ActiveSync, les

clients OWA ou encore le client Outlook Anywhere.- Les serveurs de transport Hub qui gèrent l'ensemble des flux de messagerie au sein de

l'organisation.- Les serveurs de Messagerie Unifiée qui traitent l'ensemble des messages vocaux et des

fax pour l'organisation.

Vous allez dans cette partie étudier comment administrer et gérer au quotidien vosserveurs. Vous apprendrez notamment comment créer des filtres de recherche pour vosserveurs et comment vous familiariser rapidement avec ces nouvelles interfacesd'administration.

B. Administration des serveurs de boîtes aux lettres

Premier serveur de la liste, le serveur de boîtes aux lettres remplace le serveur principal desversions antérieures à 2007 (appelé aussi serveur dorsal). Le serveur de boîtes aux lettresfonctionne de la manière suivante :- Il accède aux informations des utilisateurs via Active Directory.- Il récupère toutes les informations concernant les destinataires mais surtout les

informations de la configuration Exchange 2010 de votre organisation.

Le serveur de transport Hub place les messages dans la boîte aux lettres appropriée.

Le serveur d'accès au client envoie les requêtes des clients au serveur de boîtes aux lettres,puis renvoie les données du serveur de boîtes aux lettres aux clients.

Les clients Outlook se trouvant dans le réseau interne peuvent accéder directement auserveur de boîtes aux lettres pour envoyer et récupérer les messages. Les clients Outlooksitués en dehors de l'organisation peuvent accéder à un serveur de boîtes aux lettres àl'aide d'un appel de procédure distante RPC sur HTTP (Outlook Anywhere).

Chapitre 6

324 Exchange Server 2010

Le serveur de boîtes aux lettres (serveur de BALS) stocke les informations des bases dedonnées des boîtes aux lettres de l'organisation. Comme dans les versions précédentes,vous allez retrouver les notions suivantes : groupes de stockage, banques d'informations etdossiers publics ; mais vous allez surtout découvrir les modes de récupérations des basesde données et comment mettre en place rapidement une politique de récupération efficaceet fiable en cas de crash.

Les serveurs de boîtes aux lettres ne transfèrent pas les mails entre eux mais passentobligatoirement par un serveur de transport Hub qui se charge de cette fonction.

Le serveur de boîtes aux lettres est géré à partir de la console Exchange ManagementConsole.

�Edit

ions

EN

I-

All

rights

rese

rved

Administration des serveurs

Conception de l'infrastructure, Implémentation, Administration 325

Un clic droit sur le serveur de boîtes aux lettres dans le volet Résultats vous permet d'accé-der aux propriétés du serveur. Vous y trouvez, entre autres, les informations relatives auserveur : sa version, l'édition, les rôles présents, l'ID de produit et la date d'installation.Vous trouvez également les serveurs contrôleurs de domaine et les catalogues globaux aux-quels il fait référence pour son fonctionnement dans l'onglet Paramètres système. Le troi-sième onglet vous permet de spécifier le planning de gestion des enregistrements de messa-gerie.

Chapitre 6


Toujours à partir de la console MMC, dans le volet Résultats, vous trouvez un bouton filtreen haut à gauche de la console vous permettant d'effectuer des requêtes précises sur lesserveurs présents dans l'organisation.

�Edit

ions

EN

I-

All

rights

rese

rved



1. Les bases de donnéesLes banques d'informations perdent leur nom depuis Exchange 2007 pour s'appeler doréna-vant bases de données.

Ces bases sont stockées par défaut sur le serveur Exchange à l'emplacement suivant :Installation Exchange\Mailbox\NomBase\NomBase.edb.

Les bases de données ne sont plus membres de groupes de stockage comme cela était lecas avant Exchange 2010.

Les bases de données sont catégorisées en deux types : les bases de boîtes aux lettres etles banques de dossiers publics. Tous deux sont stockés sur les serveurs de boîtes auxlettres.

Chapitre 6


Parmi les nouveautés relatives aux serveurs de boîtes aux lettres, retenez celles-ci :- Le fichier de base de données de transmission (.stm) a été supprimé depuis

Exchange 2007. Vous n'avez à présent qu'un seul fichier qui est *.edb.- Des noms de fichiers journaux plus longs sont utilisés. Ainsi, chaque groupe de stockage

peut générer 2 milliards de fichiers journaux avant que la réinitialisation de la générationdes fichiers journaux ne soit nécessaire.

- La taille de fichier du journal des transactions (Res1.log et Res2.log) a été réduite de5 Mo à 1 Mo (depuis Exchange 2007).

- Enfin, retenez que chaque base de données est portable sur un emplacement destockage de type NAS ou SAN. C'est d'ailleurs ce type de configuration qui est préconisé.Comme vous avez peut-être pu le constater pour les versions précédentes d'Exchange,Microsoft préconise la segmentation des groupes de stockage avec les bases de donnéesmais aussi avec les fichiers binaires du programme. L'architecture suivante vous permetd'exploiter au mieux le stockage des données.

- Les bases de données ne sont plus gérées plus depuis le serveur de boîtes aux lettresmais directement depuis l’organisation.

Placez les fichiers binaires de préférence sur une partition séparée de celle contenant lesdifférents groupes de stockage et bases de données associées. Optez de préférence pourune solution de Raid 1 pour le système d'exploitation.

Placez les fichiers de transactions des groupes de stockage si possible sur une partitionséparée disposant d'un espace disque conséquent. En effet, la génération des journauxproduits par le serveur Exchange est tellement importante que vous devez prévoir suffisam-ment de ressources sur vos disques. Microsoft conseille de placer ces groupes de stockagesur une configuration Raid 0.

Placez les fichiers des bases de données sur une partition séparée des deux précédentes.Prévoyez également un autre emplacement pour le stockage des bases de données enréplication continue. Vous pouvez toujours placer ces copies sur le Raid 0 contenant lesjournaux de transactions des groupes de stockage. Optez, dans la mesure du possible, pourune configuration en Raid 5 afin d'optimiser l'accès disque ainsi que l'ensemble deslectures/écritures sur vos bases de données.

�Edit

ions

EN

I-

All

rights

rese

rved



Exchange Server 2010

Conception de l’infrastructure, Implémentation, Administration

CollectionRessources Informatiques

Extrait

Editions ENI

Windows PowerShell(versions 1 et 2)

Guide de référence pour l’administration système

CollectionExpert IT

Extrait

Chapitre 5

La sécurité

1. La sécurité : pour qui ? Pourquoi ?

L'arrivée des réseaux locaux et d'Internet a changé beaucoup de choses dans lamanière de protéger son PC. Il ne suffit plus d'attacher son disque dur au radiateuret de fermer la porte du bureau le soir pour ne pas se faire voler ou pirater desdonnées. Maintenant, protéger son poste de travail est devenu essentiel pour nepas faire les frais d'intrusions ou de malversations.Mais alors contre qui se prémunir ? Hé bien, contre tout ce qui bouge… et mêmece qui ne bouge pas. En effet, que ce soit des programmes malveillants, des utilisa-teurs mal intentionnés, voire des utilisateurs inexpérimentés, tous peuvent êtreconsidérés comme une menace. C'est pour cela que vous devez verrouiller votresystème en établissant des règles de sécurité, en les appliquant et vous assurantque les autres en font autant.

2. Les risques liés au scripting

Vous allez vite deviner que ce qui fait la force du scripting, en fait aussi safaiblesse. La facilité avec laquelle vous pouvez tout faire, soit en cliquant sur unscript, soit en l'exécutant depuis la fenêtre de commande, peut vous mettre dansl'embarras si vous ne faites pas attention.

293

Imaginez un script de logon qui dès l'ouverture de la session la verrouille aussitôt !Alors, oui c'est sympa entre copains, mais en entreprise, nous doutons que celasoit de bon ton. Plus grave encore, un script provenant d'une personne mal inten-tionnée ou vraiment peu expérimentée en PowerShell (dans ce cas, nous vousconseillons de lui acheter un exemplaire de ce livre…) peut parfaitement vousbloquer des comptes utilisateurs dans Active Directory, vous formater un disque,vous faire rebooter sans cesse. Enfin, vous l'avez compris, un script peut tout faire.Car même si aujourd'hui des alertes sont remontées jusqu'à l'utilisateur pour leprévenir de l'exécution d'un script, elles ne sont pas capables de déterminer àl'avance si un script est nuisible au bon fonctionnement du système.Les risques liés au scripting se résument à une histoire de compromis, soit vousempêchez toute exécution de script, c'est-à-dire encourir le risque de vous pourrirla vie à faire et à refaire des tâches basiques et souvent ingrates. Soit vous choisis-sez d'ouvrir votre système au scripting, en prenant soin de prendre les précautionsqui s'imposent.Mais ne vous laissez pas démoraliser car même si l'exécution de scripts vousexpose à certains problèmes de sécurité, PowerShell se dote de nouveaux conceptsqui facilitent grandement cet aspect du scripting.

3. Optimiser la sécurité PowerShell

3.1 La sécurité PowerShell par défaut

Vous l'avez compris, la sécurité est une chose très importante, surtout dans ledomaine du scripting. C'est pour cela que les créateurs de PowerShell ont inclusdeux règles de sécurités par défaut.Des fichiers ps1 associés au bloc-notesL'extension « .ps1 » des scripts PowerShell, est par défaut associée à l'éditeur detexte bloc-notes (ou Notepad). Ce procédé permet d'éviter de lancer des scriptspotentiellement dangereux sur une mauvaise manipulation. Le bloc-notes estcertes un éditeur un peu classique, mais a le double avantage d'être inoffensif et dene pas bloquer l'exécution d'un script lorsque celui-ci est ouvert avec l'éditeur.

�Remarque

Ce type de sécurité n'était pas mis en place avec les scripts VBS dont l'ouverture était

directement associée au Windows Script Host. Que ceux n'ayant jamais double cliqué sur

un script VBS en voulant l'éditer nous jettent la pierre !

Windows PowerShell (v. 1 et 2)Guide de référence pour l’administration système

294

©Edit

ions

EN

I-

Toute

repro

ducti

on

inte

rdit

e

Une stratégie d'exécution restreinteLa seconde barrière de sécurité est l'application de stratégie d'exécution « restricted »par défaut (cf. stratégies d'exécution).Cette stratégie est la plus restrictive. C'est-à-dire qu'elle bloque systématiquementl'exécution de tout script. Seules les commandes tapées dans le shell seront exécu-tées. Pour remédier à l'inexécution de script, PowerShell requiert que l'utilisateurchange le mode d'exécution avec la commande Set-ExecutionPolicy <mode

d'exécution>.

�Remarque

Peut-être comprenez-vous mieux pourquoi le déploiement de PowerShell sur vos

machines ne constitue pas un accroissement des risques, dans la mesure où certaines

règles sont bien respectées.

3.2 Les stratégies d'exécution

PowerShell intègre un concept de sécurité que l'on appelle les stratégies d'exécu-tion (execution policies) pour qu'un script non autorisé ne puisse pas s'exécuter àl'insu de l'utilisateur. Il existe quatre configurations possibles : Restricted,RemoteSigned, AllSigned et unrestricted. Chacune d'elles correspond à unniveau d'autorisation d'exécution de scripts particulier, et vous pourrez êtreamenés à en changer en fonction de la stratégie que vous souhaitez appliquer.

3.2.1 Les différentes stratégies d'exécution

Restricted : c'est la stratégie la plus restrictive, et c'est aussi la stratégie pardéfaut. Elle ne permet pas l'exécution de script mais autorise uniquement lesinstructions en ligne de commande, c'est-à-dire uniquement dans le shell. Cettestratégie peut être considérée comme la plus radicale étant donné qu'elle protègel'exécution involontaire de fichiers « .ps1 ».Lors d'une tentative d'exécution de script avec cette stratégie, un message de cetype est affiché dans la console :

Impossible de charger le fichier C:\script.ps1,car l'exécution de scripts est désactivée sur ce système.

Comme cette stratégie est celle définie par défaut lors de l'installation dePowerShell, il vous faudra donc la changer pour l'exécution de votre premier script.

La sécuritéChapitre 5

295

AllSigned : c'est la stratégie permettant l'exécution de script la plus « sûre ». Elleautorise uniquement l'exécution des scripts signés. Un script signé est un scriptcomportant une signature numérique comme celle présentée sur la figure suivante.

Exemple de script signé

Avec la stratégie AllSigned, l'exécution de scripts signés nécessite que vous soyezen possession des certificats correspondants (cf. partie sur la signature des scripts).RemoteSigned : cette stratégie se rapporte à AllSigned à la différence près queseuls les scripts ayant une origine autre que locale nécessitent une signature. Parconséquent, cela signifie que tous vos scripts créés localement peuvent êtreexécutés sans être signés.Si vous essayez d'exécuter un script provenant d'Internet sans que celui-ci soitsigné, le message suivant sera affiché dans la console.

Impossible de charger le fichier C:\script.ps1.Le fichier C:\script.ps1 n'est pas signé numériquement.Le script ne sera pas exécuté sur le système.


296

©Edit

ions

EN

I-

Toute

repro

ducti

on

inte

rdit

e

�Remarque

Vous vous demandez sûrement comment PowerShell fait pour savoir que notre script

provient d'Internet ? Réponse : Grâce aux « Alternate Data Streams » qui sont implémen-

tés sous forme de flux cachés depuis des applications de communication telles que

Microsoft Outlook, Internet Explorer, Outlook Express et Windows Messenger (voir partie

traitant des Alternate Data Streams).

Unrestricted : c'est la stratégie la moins contraignante, et par conséquent lamoins sécurisée. Avec elle, tout script, peu importe son origine, peut être exécutésans demande de signature. C'est donc la stratégie où le risque d'exécuter desscripts malveillants est le plus élevée.Cette stratégie affiche tout de même un avertissement lorsqu'un script téléchargéd'Internet tente d'être exécuté.

PS > .\script.ps1

Avertissement de sécuritéN'exécutez que des scripts que vous approuvez. Bien que les scriptsen provenance d'Internet puissent être utiles, cescript est susceptible d'endommager votre ordinateur.Voulez-vous exécuter C:\script.ps1 ?[N] Ne pas exécuter [O] Exécuter une fois[S] Suspendre [?] Aide (la valeur par défaut est « N ») :

PowerShell v2 apporte deux stratégies d'exécution supplémentaires :Bypass : rien n'est bloqué et aucun message d'avertissement ne s'affiche.Undefined : pas de stratégie d'exécution définie dans l'étendue courante. Si toutesles stratégies d'exécution de toutes les étendues sont non définies alors la stratégieeffective appliquée sera la stratégie Restricted.

3.2.2 Les étendues des stratégies d'exécution

Cette partie ne s'applique qu'à PowerShell v2.PowerShell v2 apporte un niveau de granularité que PowerShell v1 n'avait pas dansla gestion des stratégies d'exécution. PowerShell v1 ne gérait la stratégie d'exécu-tion qu'au niveau de l'ordinateur autrement dit, PowerShell v1 n'était doté que del'étendue LocalMachine.En plus de l'étendue LocalMachine, PowerShell v2 apporte les deux nouvellesétendues suivantes : Process, et CurrentUser. Il est possible d'affecter une stratégied'exécution à chaque étendue si on le désire.

La sécuritéChapitre 5

297

La priorité d'application des stratégies est la suivante :- Etendue Process : la stratégie d'exécution n'affecte que la session courante

(processus Windows PowerShell). La valeur affectée à l'étendue Process eststockée en mémoire uniquement ; elle n'est donc pas conservée lors de lafermeture de la session PowerShell.

- Etendue CurrentUser : la stratégie d'exécution appliquée à l'étendueCurrentUser n'affecte que l'utilisateur courant. Le type de stratégie est stocké defaçon permanente dans la partie du registre HKEY_CURRENT_USER.

- Etendue LocalMachine : la stratégie d'exécution appliquée à l'étendueLocalMachine affecte tous les utilisateurs de la machine. Le type de stratégie eststocké de façon permanente dans la partie du registre HKEY_LOCAL_MACHINE.

La stratégie ayant une priorité 1 est plus propriétaire que celle ayant une priorité3. Par conséquent, si l'étendue LocalMachine est plus restrictive que l'étendueProcess, la stratégie qui s'appliquera sera quand même la stratégie de l'étendueProcess. À moins que cette dernière soit de type Undefined auquel cas PowerShellappliquera la stratégie de l'étendue CurrentUser, puis tentera d'appliquer lastratégie LocalMachine.À noter que l'étendue LocalMachine est celle par défaut lorsque l'on applique unestratégie d'exécution sans préciser d'étendue particulière.

3.2.3 Identifier la stratégie d'exécution courante

La stratégie d'exécution courante s'obtient avec la commandelette Get-Execution-Policy.

Exemple :

PS > Get-ExecutionPolicyRestricted

Avec PowerShell v1, ne se pose pas la question de savoir quelle est l'étendueconcernée par le mode retourné par cette commande. En effet, PowerShell v1 negère que l'étendue LocalMachine.Avec PowerShell v2, nous bénéficions du switch -List. Grâce à lui nous allonssavoir quelles stratégies s'appliquent à nos étendues.

Par exemple :

PS > Get-ExecutionPolicy -List

Scope ExecutionPolicy----- ---------------

MachinePolicy Undefined


298

©Edit

ions

EN

I-

Toute

repro

ducti

on

inte

rdit

e

exchange-server-210_(extrait-du-livre)

Documents