 TechNet Magazine July 2007

TechNet Magazine July 2007

Communications: Protection des données et récupération après incident pour Exchange Server 2007

Exchange Server 2007 inclue une panoplie d’options pour la prise en charge de la haute disponibilité et de la récupération après incident. Explorez les alternatives offertes par Exchange et planifiez la solution de récupération idéale pour votre organisation.

Lee Benjamin Communications: Améliorer la sécurité avec Windows Mobile 6

Bien que les smartphones et les assistants numériques personnels offrent l’accès au réseau depuis l’extérieur du bureau, ils peuvent également exposer le réseau à de nouvelles vulnérabilités. Voici un guide décrivant comment Windows Mobile 6 et Exchange Server peuvent contribuer à protéger les périphériques mobiles et l’infrastructure de votre entreprise.

Matt Fontaine Communications: Une alternative puissante aux dossiers publics

MOSS 2007 fournit une solution beaucoup plus puissante que les dossiers publics Exchange pour le partage de données, tout en offrant des fonctionnalités améliorées et une administration simplifiée. Découvrez comment vous pouvez utiliser SharePoint pour partager des calendriers, des contacts et des documents.

Alan Maddison Communications: Connexion à Outlook Web Access avec cartes à puce

L’un des liens les plus vulnérables dans la chaîne de sécurité a trait aux mots de passe faibles, pouvant être facilement compromis. Découvrez comment améliorer la sécurité de messagerie électronique en mettant en place l’authentification par deux facteurs avec carte à puce pour vos utilisateurs mobiles.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Administration de Windows: Le service d’installation ActiveX dans Windows Vista

Comment protéger le bureau contre les contrôles ActiveX malveillants sans limiter la compatibilité des applications ? Nous vous présentons le service d’installation ActiveX (AxIS) dans Windows Vista qui traite ce problème avec une nouvelle façon de gérer les contrôles ActiveX.

Rob Campbell and Joel Yoker Le mot du rédacteur en chef: Six degrés de séparation

Joshua Trupin Boîte à outils: Nouveaux produits pour les professionnels de l’informatique

Greg Steen Forum aux questions sur SQL: Au cœur de la mise en clusters, des mises en suspens mystérieuses, du compte administrateur système et plus encore

Edited by Nancy Michell Coup de projecteur sur les utilitaires: SMSMap

Jeff Tondt Comment ça marche: Dépannage d’erreurs RPC

Zubair Alexander Le petit câbleur: Trafic IPv6 sur les connexions VPN

Joseph Davies Windows PowerShell: Restructuration du pipeline

Don Jones Hé, vous le scripteur !: Dans les scripts comme dans la vie, le look est important

The Microsoft Scripting Guys Questions et réponses sur la file d'attente Exchange: Rôles de transport Hub et Edge, machines virtuelles, et plus encore

KC Lemson and Nino Bilic Vigilance sécurité: Outils de gestion des ACL

Jesper M. Johansson Histoires de Bureau: Microsoft Desktop Optimization Pack

Wes Miller La vie secrète de Windows: Pouvoirs réparateurs du mode Sans échec

Raymond Chen


 Communications: Protection des donn&#233;es et r&#233;cup&#233;ration apr&#232;s incident pour Exchange Server&#160;2007
Communications Lee Benjamin

Protection des données et récupération après incident pour Exchange Server 2007
Vue d'ensemble:
  • Sauvegarde et restauration de base
  • Continuité des données
  • Technologies de réplication
  • Solutions alternatives

Microsoft Exchange Server a été conçu en gardant à l’esprit la sauvegarde. Les organisations doivent sauvegarder leurs données de messagerie et pouvoir également restaurer ces informations. Pour répondre à ces besoins, Microsoft a créé une gamme complète d’options de protection des informations, de la
sauvegarde et la restauration traditionnelle au bas de l’échelle, en passant par la continuité opérationnelle, jusqu’aux véritables solutions de continuité d’entreprise qui fournissent les niveaux les plus élevés de disponibilité et de récupération après incident. Dans cet article, je décrirai ces options et vous aiderai à décider comment implémenter la meilleure solution de récupération d’Exchange pour votre organisation.

NIVEAU 1 : SAUVEGARDE ET RESTAURATION DE BASE
Vous pouvez sauvegarder les fichiers Exchange en mettant ses bases de données hors ligne, mais également les sauvegarder pendant qu’elles s’exécutent. En fait, cette dernière option est souvent la méthode recommandée pour sauvegarder Exchange. Mais Exchange est plus qu’un ensemble de fichiers. C’est une banque d’informations avec de gros fichiers de base de données et journaux de transactions. Les messages envoyés à Exchange sont immédiatement enregistrés dans les journaux de transactions et lorsque le système dispose de quelques cycles disponibles (habituellement juste quelques millisecondes plus tard), les messages sont copiés dans la base de données. En plaçant les informations sur disque aussi rapidement que possible, Exchange fournit un niveau très élevé de récupérabilité. La disponibilité des deux ensembles d’informations est essentielle à la restauration d’Exchange. En cas d’échec de votre système, c’est la combinaison d’une sauvegarde précédente, avec toutes les transactions depuis ce point, qui vous permet de restaurer Exchange avec les informations les plus récentes. Notez que, en cas de nécessité, Exchange réexécute automatiquement les transactions d’une base de données restaurée.
Les programmes de sauvegarde accèdent aux informations de la base de données Exchange par le biais de l’API de sauvegarde du moteur de stockage extensible (ESE) ou des dernières solutions de VSS, dont je parlerai plus tard. Lorsqu’une sauvegarde ESE est mise en route, Exchange interrompt temporairement toutes les écritures dans ses bases de données. Tandis qu’ESE place temporairement la base de données en mode de lecture seule, ce qui lui donne la possibilité d’être copié dans une sauvegarde complète, il utilise également une base de données temporaire pour le stockage des nouvelles transactions qui surviennent pendant la sauvegarde. Lorsque la sauvegarde est terminée, ESE remet la base de données en mode de lecture/écriture normal et applique les transactions accumulées dans sa base de données temporaire. La sauvegarde purge également les vieux journaux de transactions à la fin d’un processus de sauvegarde réussi.
Bien que ce processus de sauvegarde soit direct et transparent pour les utilisateurs qui ouvrent une session au milieu de la nuit pendant la progression de la sauvegarde, l’exécution d’ESE peut nécessiter une durée très longue, en particulier parce que la taille des bases de données Exchange peut s’échelonner de quelques gigaoctets, jusqu’à 30 à 50, ou même encore 100 Go, ce qui devient quasi impossible à sauvegarder pendant la nuit en utilisant des technologies standard. Pour avoir une idée des options disponibles lors de l’utilisation de NTBackup.exe, examinez la figure 1.
Figure 1 Utilisation de l’utilitaire NTBackup
Figure 1 Utilisation de l’utilitaire NTBackup

Meilleures pratiques pour Exchange
Si vous voulez pouvoir rapidement effectuer une récupération après les échecs système et matériels courants, des sauvegardes complètes d’Exchange doivent être effectuées chaque nuit. Pour améliorer la performance et la récupérabilité lorsqu’un serveur Exchange utilise des disques locaux, il est important que vous utilisiez des baies RAID distinctes pour enregistrer les bases de données d’Exchange et les journaux de transactions d’Exchange. Ainsi, si un contrôleur de baie RAID tombe en panne, ou si plus d’un disque de la baie tombe en panne et que par conséquent les disques restants ne peuvent plus reconstruire les données agrégées, vous pourrez tout de même effectuer la récupération. Si vous perdez vos journaux de transactions, vous aurez toujours des bases de données Exchange à jour sur les autres lecteurs, qui vous permettront de poursuivre des activités normales avec de nouveaux journaux de transactions. Si vous perdez les lecteurs de base de données, votre stratégie de récupération consiste à revenir à votre sauvegarde complète de la nuit précédente pour les bases de données Exchange et d’appliquer ensuite les journaux de transactions du jour pour les mettre à jour.
Il est important que vous limitiez la taille de vos bases de données Exchange pour que chacune puisse être sauvegardée (et plus important encore, restaurée) en un temps raisonnable. Pour la plupart des organisations, cela signifie conserver une taille de bases de données comprise entre 30 et 50 Go. Lorsqu’une base de données croît au-delà de cette taille, il est conseillé de la fractionner en bases de données multiples pour que la restauration puisse être gérable.

Continuum de sauvegarde et restauration
Le placement des bases de données et des journaux de transactions est très important, non seulement pour les performances de la sauvegarde, mais également pour la vitesse de récupération. Aujourd’hui, tous les serveurs prennent en charge divers niveaux de redondance de lecteur de disque, ce qui porte le nom de RAID. RAID permet essentiellement la défaillance d’un lecteur de disque sans arrêt du système, bien que les performances du système soient plus réduites jusqu’à ce que le disque ait été remplacé et reconstruit. Jusqu’à ce stade, le contrôleur de baie doit reconstruire les données à partir des disques restants « à la volée », pour chaque requête d’accès disque. Pour plus d’informations sur la conception du stockage de serveur de boîtes aux lettres, voir l’article Microsoft IT Showcase « Passage aux 64 bits avec Exchange Server 2007 ».
L’une des fonctionnalités essentielles d’Exchange est sa conception de base de données à instance unique. Ceci signifie que dans une base de données Exchange, seule une copie d’un message spécifique est enregistrée, avec une seule pièce jointe (si elle existe). Si le message a été envoyé à plusieurs destinataires de la même banque d’informations, des pointeurs supplémentaires vers les objets (message, pièce jointe) sont créés, mais les objets ne sont pas dupliqués. C’est non seulement un grand avantage d’efficacité de remise, mais également une grande économie d’espace pour Exchange, sur disque comme sur bande.
Bien qu’Exchange soit doué pour la récupération de la base de données entière, la restauration des boîtes aux lettres individuelles, des dossiers ou des messages nécessite de récupérer d’abord la bande entière. Il n’est pas surprenant que les utilisateurs aient exigé des capacités de restauration plus détaillées. L’instance unique sur bande complique énormément ceci. Les fournisseurs de sauvegardes ont répondu à ce besoin avec la « Sauvegarde de niveau brique » (que je ne recommande pas). Après avoir terminé une sauvegarde complète de la base de données Exchange en utilisant l’API de sauvegarde ESE approuvée, les produits de sauvegarde ajoutent ensuite chaque boîte aux lettres à la bande de sauvegarde. Puisque l’API de sauvegarde ne fournit pas de méthode d’extraction des données des boîtes aux lettres individuelles, MAPI est utilisé. Par conséquent, la bande de sauvegarde est considérablement plus longue car vous dupliquez tous ces messages et pièces jointes.
Microsoft a apporté quelques améliorations qui répondent partiellement à ce problème. Par exemple, la corbeille à papier (ou Benne) conserve les éléments pendant une certaine période après leur suppression par les utilisateurs, au cas où ils seraient nécessaires. En outre, il n’est plus nécessaire de garder un serveur disponible comme forêt de récupération Exchange. Les groupes de stockage de récupération permettent à un administrateur de monter partiellement les bases de données restaurées qui ont été récupérées à partir de la bande et de copier ou fusionner des données au niveau des boîtes aux lettres.

Essayer pour réussir
De nombreuses organisations découvrent, lorsqu’il est trop tard, que quel que soit le niveau de sauvegarde et de récupération qu’elles ont décidé d’adopter, les procédures de support de sauvegarde et de récupération doivent être régulièrement testées. Trop d’administrateurs déterminent uniquement après une urgence si leur technologie de sauvegarde et les procédures de restauration fonctionnent réellement ou non. Le meilleur moment pour le test est le lendemain de la mise en place et de la configuration de votre tout nouveau serveur, lorsqu’il est opérationnel dans votre organisation Exchange mais seulement utilisé par quelques utilisateurs. Vous devriez alors exécuter une sauvegarde complète d’Exchange, une sauvegarde ordinaire de vos lecteurs et capturer l’état du Système, qui inclut les fichiers critiques sur votre disque système ainsi que la métabase IIS (où se situe la configuration de routage d’Exchange). Ensuite, reformatez calmement le nouveau serveur et recommencez, en mettant à jour les notes que vous avez prises lorsque vous avez initialement mis en place le serveur. Vous devriez pouvoir restaurer des paramètres de l’état du système, mais également disposer d’une documentation suffisante pour remettre en œuvre manuellement les paramètres de configuration du système.
Le temps que vous passerez sur cet exercice réduira de manière significative votre temps de récupération à l’avenir. Répétez régulièrement ce processus. Pendant que vous y êtes, chronométrez le temps nécessaire à la récupération des bandes hors site. Ceux qui ont eu à souffrir de cette attente paraissant interminable commencent alors souvent à réfléchir plus sérieusement à l’importance des sauvegardes disque vers disque pour leur stratégie de sauvegarde et restauration, même si le stockage sur bande hors site continue à constituer leur solution ultime pour la récupération après incident.

Défis de la sauvegarde de bande
La restauration à partir d’une bande est trop longue. Exchange est aujourd’hui si essentiel aux organisations qu’utilisateurs et administrateurs s’attendent à ce qu’il soit disponible en permanence. Lorsqu’un problème sérieux survient, la plupart des organisations sont prises au dépourvu. Personne n’est prêt à entendre qu’il faudra huit heures pour restaurer 75 Go de base de données d’une bande (et cela n’inclut même pas le temps nécessaire pour obtenir les bandes depuis l’installation de stockage hors site ou la réinstallation du système d’exploitation).
Qui plus est, la récupération de la base de données correcte depuis la bande constitue en soi un défi. Au cours des 10 années écoulées depuis la première version d’Exchange, le coût du stockage sur disque et des réseaux étendus a considérablement chuté. Par conséquent, de nombreuses organisations peuvent se permettre des méthodes de sauvegarde et de restauration plus rapides. Il est possible pour ces organisations de profiter de technologies qui leur permettent de bénéficier de continuité opérationnelle et de récupération après incident pour leur infrastructure Exchange.

NIVEAU 2 : CONTINUITÉ OPÉRATIONNELLE
La continuité opérationnelle est un ensemble de processus et de technologies ayant pour but la récupération, aussi rapide que possible, pour réduire au minimum le temps d’indisponibilité inattendue. La continuité opérationnelle offre un RTO (Objectif de temps de récupération) et un RPO (Objectif de point de récupération) améliorés par rapport à la bande, pour la récupération locale. Elle s’efforce d’éliminer, dans la mesure du possible, le temps nécessaire pour remettre les bandes en ligne. Examinez la figure 2 pour comparer la continuité fonctionnelle pour la sauvegarde et la restauration et la récupération après incident.
Figure 2 Continuum de récupération
Figure 2 Continuum de récupération
Ce diagramme illustre le continuum de récupération et de disponibilité depuis lent et bon marché dans le coin inférieur gauche jusqu’à rapide et onéreux dans le coin supérieur droit, avec une transition floue délibérée entre la continuité opérationnelle et les solutions de récupération après incident.
Le graphique vous donne une idée des compromis entre coûts, temps de récupération et disponibilité au travers de ces approches. Dans cet article, j’effectue volontairement une distinction nette entre les processus de continuité locaux et la récupération après incident. La récupération après incident est toujours indiquée comme distante, l’objectif principal étant l’obtention des données hors site. La distance introduit des obstacles supplémentaires et est généralement beaucoup plus coûteuse mais, pour la récupération après incident, la poursuite des activités après urgence est l’objectif principal. Je couvrirai ceci avec plus de détails plus tard.

Un peu d’histoire
Lorsque Exchange est devenu un élément encore plus vital de l’infrastructure et que davantage d’informations ont commencé à être enregistrées dans ses bases de données, il est devenu évident que les temps de sauvegarde et de restauration nécessitaient d’être réduits. En collaboration avec Microsoft, certaines grandes organisations ont proposé une approche offrant un retour au fonctionnement partiel nettement amélioré. Si une organisation pouvait recevoir et envoyer de nouveaux messages électroniques depuis et vers le monde extérieur, il semblerait que rien ne s’est passé. Après tout, l’apparence a de l’importance.
Pour implémenter cette restauration de la « tonalité d’appel » pour Exchange, une nouvelle base de données vide était mise en place en remplacement de celle endommagée. Exchange et Active Directory® créaient alors de nouvelles boîtes aux lettres avec les autorisations appropriées et les utilisateurs pouvaient envoyer et recevoir. Une fois la bande de sauvegarde obtenue et les données récupérées, elle pouvait être montée de manière administrative. L’administrateur Exchange fusionnait alors les boîtes aux lettres restaurées aux boîtes aux lettres de « tonalité d’appel ». La priorité des boîtes aux lettres pouvait être décidée en fonction des nécessités. Bien que constituant une amélioration, cette procédure complexe et longue utilisait à l’origine EXMERGE et a ensuite été adaptée aux groupes de stockage de récupération. Notez toutefois que la restauration complète des données après un scénario de récupération de « tonalité d’appel » peut constituer une tâche ardue et compliquée (surtout si l’on considère que jusqu’à 50 groupes de stockage peuvent être disponibles dans Exchange 2007). Si vous envisagez d’implémenter un scénario de récupération de type tonalité d’appel, veillez à vous assurer que les avantages surpasseront l’effort requis.

Services Cliché instantané des volumes
Pour profiter des disques moins onéreux et supprimer la surcharge pour le processeur des serveurs Exchange de production, une nouvelle API de sauvegarde a été développée pour Microsoft® Windows Server® 2003 et Exchange. Le service Cliché instantané des volumes (VSS) a été créé pour faire une copie cohérente des données à un point déterminé dans le temps. Ces instantanés sont des copies rapides en lecture seule des données d’Exchange incluant uniquement les données modifiées successivement. Les copies pointent habituellement vers un autre serveur avec espace disque disponible ou vers un réseau de stockage SAN. Plusieurs instantanés peuvent être conservés, des sauvegardes étant effectuées sur bande. Par conséquent, le serveur Exchange de production n’a plus à souffrir de l’impact sur les performances du logiciel de sauvegarde et de la surcharge due à la copie de la bande.
Il y a plusieurs avantages à l’utilisation de VSS pour la protection des données d’Exchange. Tout d’abord, la charge sur les performances des opérations de sauvegarde de bande peut être supprimée de votre serveur Exchange. Bien que la sauvegarde sur bande doive toujours être effectuée, elle peut utiliser une copie des données d’Exchange et n’influe pas sur les performances de l’utilisateur. Deuxièmement, il devient possible d’effectuer des instantanés plus fréquemment qu’une fois par nuit. Et, qui plus est, vous pouvez conserver plusieurs instantanés sur le serveur secondaire ou un autre stockage local.
Il existe sur le marché plusieurs produits de sociétés tierces capables de tirer parti des capacités d’instantanés de VSS. Certains réduisent simplement le temps nécessaire pour la sauvegarde et la restauration des bases de données Exchange, tandis que d’autres ajoutent des capacités de récupération plus détaillées que celles incluses de manière native par Exchange, afin que vous puissiez effectuer une restauration au niveau des boîtes aux lettres. Bien que personne n’apprécie de telles sauvegardes de « briques », nous souhaitons tous avoir la possibilité de restaurer des dossiers spécifiques ou même certains messages particuliers.

Technologies de réplication
Le basculement d’Exchange géré par logiciel est une option proposée par certains fournisseurs de solutions de réplication. Cette option fait en sorte qu’un serveur Exchange en mode d’attente devienne actif et indique ensuite à Active Directory que toutes les boîtes aux lettres des utilisateurs ont été déplacées. Il existe deux façons d’accomplir ceci, qui nécessitent toutes deux certaines personnalisations des environnements Exchange et Windows. La première oblige à jouer quelques tours au serveur DNS pour que le serveur en mode d’attente s’approprie le nom et l’adresse IP du serveur ayant échoué. Cette approche a l’avantage d’être facile sur les postes de travail clients puisque Outlook® pense qu’il utilise toujours le même serveur.
La deuxième approche utilise un serveur en mode d’attente exécutant Exchange et qui contient les copies des bases de données mais sur lequel rien n’a été monté. En cas de défaillance, le serveur en mode d’attente informe Active Directory que toutes les boîtes aux lettres d’utilisateurs ont été transférées vers lui. Un script est ensuite exécuté ou une stratégie de groupe distribuée, indiquant aux clients qu’ils sont sur un serveur de messagerie différent. Outlook 2007 fonctionne avec Active Directory, ce qui rend le processus plus facile car il effectuera automatiquement ces mappages par lui-même.

Mise en clusters locale avec MSCS
Microsoft Cluster Services (MSCS) se situe à un niveau plus élevé dans le continuum de disponibilité. Exchange est une application qui fonctionne avec les clusters. La mise en clusters partage les informations entre deux ordinateurs ou plus afin que, si l’un de ceux-ci échoue, les autres prennent le relais. De nos jours, la plupart des clusters Exchange se composent de deux ou quatre nœuds, alors que jusqu’à huit nœuds peuvent être utilisés. Un nœud est toujours désigné comme passif (fonctionnel, avec Windows Server en cours d’exécution et Exchange Server installé, mais sans qu’aucune boîte aux lettres ne soit active). Il était possible d’utiliser un cluster à deux nœuds actif/actif dans Exchange 2003, mais en raison de surcharges des performances, cette solution est maintenant déconseillée et ne sera pas prise en charge avec Exchange 2007.
Comme avec la configuration de clusters pour Exchange 2003, les clusters Exchange 2007 qui incluent un nœud passif peuvent toujours utiliser une baie de stockage partagée unique. Bien que le stockage de niveau de qualité de cluster comporte habituellement plusieurs fonctionnalités de redondance pour résister à de nombreux types de défaillances, il fournit toujours uniquement une copie des données, ce qui laisse une opportunité de vulnérabilité. C’est pourquoi ces clusters portent le nom de clusters à copie unique (SCC), pour les distinguer de l’étape suivante de protection des données qui comporte des clusters à copie multiple (MCC) dans Exchange 2007. Nous aborderons les MCC plus en détail lorsque nous examinerons la récupération après incident.

Réplication continue locale
La réplication continue locale (LCR) est une nouvelle fonctionnalité d’Exchange 2007 fournissant une méthode améliorée pour le maintien d’une deuxième copie des bases de données et des journaux de transactions Exchange sur un même serveur. Celle-ci ajoute une couche de redondance à la pratique recommandée consistant à disposer de la base de données Exchange sur une baie RAID et des journaux de transactions sur une autre : la LCR donne la possibilité d’enregistrer une copie secondaire des journaux sur la baie qui abrite la copie principale de la base de données et d’enregistrer ensuite une copie secondaire de la base de données sur la baie qui abrite la copie principale des journaux (voir la figure 3). En cas de défaillance du contrôleur RAID ou de la baie, vous disposez toujours de votre base de données et des journaux de transactions sur l’autre baie. Ainsi, votre installation peut continuer à fonctionner (bien qu’avec un peu d’hésitation et des performances affaiblies), jusqu’à ce que vous puissiez reconstruire la baie en panne.
Figure 3 Configuration de LCR
Figure 3 Configuration de LCR
LCR est une solution de continuité opérationnelle locale, non une solution de sauvegarde, et vous aurez donc toujours besoin d’une stratégie de sauvegarde complète. Avec LCR, les performances sont également affectées, car votre serveur effectue deux copies de la base de données et des journaux de transactions. De plus, dans une mise en œuvre d’Exchange 2007, il existe certaines restrictions qui font que LCR est uniquement adapté aux organisations de petite taille en raison de sa prise en charge d’une seule base de données dans un groupe de stockage et d’une seule base de données de dossier public dans une organisation.
Le basculement avec une récupération LCR n’est pas instantané, un informaticien professionnel expérimenté devra exécuter des scripts pour qu’Exchange soit à nouveau opérationnel. Le processus nécessite l’exécution de commandes d’Exchange Management Shell, opération effectuée hors de la console de gestion Exchange.
Alors qu’Exchange Server 2003 Enterprise Edition permettait à une organisation d’utiliser jusqu’à 20 bases de données Exchange (quatre groupes de stockage possédant jusqu’à cinq bases de données chacun), Exchange 2007 Enterprise Edition permet jusqu’à 50 groupes de stockage, chacun possédant sa propre base de données. Les journaux des transactions ont été également réduits en taille, de 5 Mo dans Exchange 2003 à 1 Mo dans Exchange 2007. Ces deux modifications sont prévues pour prendre en charge LCR, ainsi que la réplication continue en cluster (CCR), qui sera abordée sous peu.
Petites et moyennes entreprises utiliseront la LCR afin d’améliorer la protection des données pour leur exploitation d’Exchange. La LCR est facile à implémenter mais implique tout de même une intervention manuelle. En tant que solution « même serveur/disque local », la LCR est seulement la première étape vers une continuité opérationnelle améliorée. Bien qu’elle assure la protection contre les défaillances d’une baie RAID et de contrôleurs RAID, les incidents de disque ou défaillances de contrôleur RAID multiples et simultanées sont relativement rares. La plupart du temps, les scénarios de défaillance impliquent l’écroulement du serveur entier, ce qui nous mène à l’étape suivante de la protection d’Exchange.

Réplication locale hors hôte de fournisseur tiers
Pour accroître les capacités de récupération d’Exchange, des fournisseurs tiers ont développé des produits qui tirent parti de la réplication « hors hôte » utilisant les fichiers journaux d’Exchange pour conserver une copie en mode d’attente de la base de données Exchange sur un autre ordinateur. Dans ce cas, la solution de protection ou d’archivage des informations exécute une sauvegarde ESE complète d’Exchange sur un ordinateur différent et extrait ensuite les journaux de transactions dès qu’Exchange les ferme. Elle insère ces transactions dans sa copie de base de données Exchange afin qu’elle soit toujours à jour. Comme je l’ai fait remarquer, ces journaux sont de taille relativement réduite (5 Mo dans Exchange 2003 et 1 Mo dans Exchange 2007) de sorte qu’une fois la sauvegarde complète effectuée, il n’y a presque pas de surcharge sur le serveur Exchange lors de la copie des fichiers journaux vers le serveur hors hôte.

NIVEAU 3 : RÉCUPÉRATION APRÈS INCIDENT ET HAUTE DISPONIBILITÉ
La récupération après incident est la capacité à revenir en mode d’exploitation lorsque le centre de données majeur devient indisponible. Exchange mérite de disposer de la récupération après incident car les fonctions de messagerie électronique et de calendrier sont aujourd’hui la force vitale de nombreuses organisations.
Certaines entreprises s’imaginent que leurs bandes de sauvegarde traditionnelles enregistrées hors site constituent une forme de récupération après incident mais, si votre centre de données unique est détruit par le feu ou une inondation, vos bobines de bande n’auront que peu d’intérêt. La récupération après incident implique nécessairement le déplacement de vos données vers un autre emplacement, mais également la technologie et les processus qui permettront à l’application de redevenir opérationnelle. Pour être efficace, la récupération après incident repose sur la séparation des systèmes primaires et secondaires par une certaine distance. L’éloignement des sites dépend de la magnitude du désastre que vous avez pour objectif de surmonter. Si vous vous souciez des incendies, peut-être qu’un autre bâtiment sur votre campus offrira un éloignement suffisant. Cependant, les désastres d’infrastructure impliquant trains ou avions peuvent affecter un rayon d’un kilomètre et demi, voire davantage. De nombreux désastres sont régionaux : inondations, orages de grêle, tremblements de terre et même pannes de courant. Les communications peuvent devoir faire face à leurs propres calamités, qu’il s’agisse d’une pelleteuse coupant le lien qui vous relie à votre fournisseur d’accès à Internet, d’attaques de déni de service ou d’attaques de déni de service Internet visant le commerce en général.
D’un point de vue pratique, si votre organisation dispose de plus d’un site avec personnel informatique, l’un de ces sites pourrait répondre à vos critères de continuité opérationnelle à distance, en fonction des types de désastres contre lesquels vous vous défendez. L’utilisation de vos propres équipements et de votre propre personnel sera nettement moins onéreuse que la sous-traitance auprès d’un fournisseur de récupération après incident ou la location d’espace à un nouvel emplacement.
En fin de compte, la récupération après incident est une question d’apparence : donner aux clients la confirmation que vous êtes toujours en activité. Les gens font preuve de compréhension lorsqu’un désastre frappe une ville ou une région, mais si votre entreprise n’est pas en ligne au bout de quelques jours voire une semaine, il est probable que clients et fournisseurs craindront le pire ; de nombreuses entreprises échouent pour cette raison. Pour le client, votre installation doit avoir l’air de récupérer afin de l’assurer que vos activités se poursuivent. L’avis des clients diffèrera en ce qui concerne le délai de récupération : ils sont, et c’est compréhensible, naturellement moins patients en ce qui concerne les pannes de courant des sociétés qui assurent leurs services financiers qu’avec, par exemple, les pannes de courant subies par leurs fournisseurs de meubles de bureau.

Exigences de la récupération après incident
Le retour en ligne d’Exchange après une urgence requiert la réplication de ses données sur le site secondaire et l’utilisation de technologies de réplication prêtes à présenter les données à un serveur Exchange en cours d’exécution et prêtes à s’exécuter avec celles-ci, pour ensuite notifier les clients Outlook que leurs boîtes aux lettres ont été déplacées.
Exchange est une application exigeante en ce qui concerne la réplication, en particulier sur de longues distances. En tant que véritable base de données transactionnelle, l’ordre de chaque écriture est d’une importance suprême. Pour compliquer cette tâche, le protocole de transport qu’Exchange utilise pour communiquer toutes les transactions et informations système entre les serveurs est SMTP, un protocole connu pour sa gourmandise en termes de bande passante. Qui plus est, avec les clusters Exchange, une pulsation doit être maintenue entre systèmes toutes les 500 millisecondes. Si un nœud secondaire ne reçoit pas cette pulsation, il peut déclencher le démarrage d’un basculement.
La complexité de gestion de tels défis peut constituer la raison pour laquelle Microsoft effectue seulement maintenant son entrée dans ce domaine, avec Exchange 2007. En l’absence de Microsoft, plusieurs solutions de fournisseurs tiers ont été développées pour répliquer les données à l’aide d’une réplication basée sur l’hôte ou sur la baie.
Les fournisseurs se sont rendu compte qu’ils pourraient étendre un cluster en dispersant des nœuds à des emplacements différents. On appelle ces clusters des « clusters distants ». Aujourd’hui, la méthode la plus courante pour la mise en œuvre de clusters distants consiste à utiliser les produits polyvalents de réplication de données de fournisseurs tiers ou ceux s’adressant plus particulièrement à l’extension de nœuds Exchange. Vous pouvez effectuer ceci avec MSCS, mais les exigences en termes de sous-réseau posent un défi sur un réseau étendu. L’utilisation de clusters et les complexités de fourniture d’une connectivité haute bande passante fiable aux centres de données distants augmentent le coût et l’effectif nécessaire pour la mise en place, la maintenance et le test périodique du système de récupération après incident.

Réplication continue en cluster
Microsoft a étendu sa prise en charge des clusters avec la réplication continue en cluster dans Exchange 2007. CCR étend la capacité de LCR à maintenir deux copies d’une base de données et des journaux de transactions Exchange pour mettre en application la même idée sur deux nœuds de cluster. La récupération après incident implique la séparation géographique des systèmes primaire et secondaire, et les clusters multicopies Microsoft (MCC) ne pourront pas couvrir de distances significatives avant que Windows Server 2008, d’ancien nom de code « Longhorn », ne rende possibles les clusters distants.
La technologie qui permet aux nœuds MCC de disposer de copies séparées des données porte le nom de jeu de nœuds majoritaire (MNS), qui fait référence au processus d’élection mené par deux nœuds ou plus pour déterminer celui abritant la copie directe des données. Lorsqu’une défaillance survient, les nœuds restants organisent une nouvelle élection pour déterminer celui qui prendra le relais en tant que nouveau serveur principal de traitement/données. Cette démocratie technique s’appuie sur CCR, qui s’assure que chaque nœud dispose d’une base de données à jour. Les clusters Exchange 2007 utilisant CCR sont limités à deux nœuds seulement.
Dans les plus grandes configurations, les serveurs Exchange configurent généralement le disque système local sur le serveur même et se connectent ensuite à la base de données Exchange sur un réseau de zone de stockage avec baies de disques SCSI, fibre optique ou iSCSI. Avec un cluster MCC/MNS, il est intéressant de se demander si le stockage Exchange haut de gamme reviendra à l’utilisation de baies RAID locales pour chaque nœud. Si le but d’un cluster MNS est de permettre à chaque nœud d’avoir son propre stockage séparé, est-il toujours judicieux de faire pointer chaque nœud vers un réseau de zone de stockage dont le but principal est de fournir un stockage commun ?
Un scénario de cluster MCC/MNS modéré consisterait en un nœud principal avec stockage sur le réseau de zone de stockage et un nœud de cluster secondaire avec des disques locaux ou un réseau de zone de stockage iSCSI à moindre coût. Ce nœud secondaire pourrait être distant par rapport au centre de données principal, dans un emplacement ne disposant pas d’infrastructure de réseau de zone de stockage.
Quel qu’en soit le résultat, MCC utilisant MNS et CCR constitue une étape positive dans la hiérarchie de redondance et améliore la disponibilité car plusieurs ordinateurs sont capables d’effectuer le basculement et les données sont répliquées sur des éléments de stockage séparés. Ceci se limite toutefois toujours à un centre de données unique, jusqu’à ce que Windows Server 2008 soit disponible. Windows Server 2008 prendra en charge de manière native les clusters distants, permettant ainsi aux nœuds d’un cluster MNS d’être aussi géographiquement éloignés que voulu, pourvu que la latence entre les nœuds soit fiable et inférieure à 500 ms. Jusque là (et également après), la technologie de cluster de fournisseurs tiers peut s’ajouter à Microsoft MNS et CCR pour fournir la séparation géographique nécessaire aux clusters distants pour constituer une solution de récupération après incident efficace.
La mise en clusters se situe en fin de processus de récupération après incident. La réplication continue en cluster devient alors une fonctionnalité haute disponibilité d’Exchange. Et bien que cette combinaison induise un supplément en matière de coût comme d’effectif, elle promet d’être une solution haut de gamme intéressante pour les clients qui veulent travailler dans un environnement Microsoft homogène.

Continuité fonctionnelle distante de fournisseurs tiers
Il ne fait aucun doute que la solution de Microsoft et les extensions des fournisseurs tiers occuperont l’extrémité du continuum de récupération lorsqu’elle sera disponible. Un basculement automatique en quelques secondes : il est difficile d’obtenir mieux. Pourtant, toutes les entreprises ne nécessitent pas un tel niveau de disponibilité et de continuité commerciale, et ne sont pas non plus prêtes à investir les centaines de milliers d’euros nécessaires à leur mise en place. Pour beaucoup d’entreprises, une solution fiable restaurant complètement Exchange en quelques minutes offrira toute la continuité fonctionnelle qu’elles nécessitent.
Par exemple, Mimosa Systems, Inc. étend la continuité opérationnelle dans un centre de données unique à la continuité à distance. Dans un emplacement distant, la récupération après incident de Mimosa abrite une copie d’Exchange, la conserve à jour avec les journaux de transactions envoyés par le serveur Exchange principal et est toujours prêt à mettre cette copie directe à la disposition de votre serveur Exchange en mode d’attente. Le serveur Exchange distant utilise un matériel de serveur standard et, tout comme pour la mise en œuvre avec centre de données unique, vous le conservez toujours en cours d’exécution et prêt à être activé en cas d’urgence. En cas d’urgence, un opérateur du site distant démarre le basculement et l’exécute, y compris en montant les fichiers de base de données en mode d’attente et en remappant les boîtes aux lettres et profils Outlook. Il est toutefois à noter que de telles solutions de fournisseurs tiers sont soumise aux limites de support décrites dans l’article de la base de connaissances ayant trait à la stratégie de support de Microsoft pour les produits modifiant ou extrayant le contenu des bases de données Exchange.

Conclusion
La protection des informations d’Exchange est disponible sous la forme d’un continuum de technologies et de procédures qui peut être découpé en trois niveaux en fonction du coût et des capacités. Lorsque vous commencez à réfléchir à leurs exigences pour la protection des informations d’Exchange, vous devez prendre en compte le temps d’inactivité que vos preneurs de décisions sont capables de tolérer. De meilleures performances et une récupération plus rapide auront un coût plus élevé, les options haut de gamme s’élevant à plusieurs centaines de milliers d’euro. Des solutions plus abordables existent qui approchent les plus hauts niveaux de disponibilité sans les atteindre tout à fait. Les choix que vous effectuez doivent refléter les besoins véritables de votre organisation.
Service Pack 1 pour Exchange 2007
Actuellement soumis à des tests bêta, le Service Pack 1 (SP1) pour Exchange 2007 est prévu pour inclure plusieurs fonctionnalités qui manquaient aux administrateurs, dont des améliorations d’OWA, des capacités d’interface utilisateur graphique supplémentaires dans la Console et bien plus encore.
Revêtant un intérêt particulier pour les administrateurs planifiant les solutions de récupération, Exchange 2007 SP1 inclut également une troisième solution de disponibilité pour accompagner LCR et CCR : la réplication continue secondaire (SCR). Il s’agit d’une approche intermédiaire et Microsoft s’attaque avec celle-ci au sujet épineux de la récupérabilité importante, sans la complexité de la "haute disponibilité" complète.
La SCR permettra la réplication de la base de données Exchange et de ses journaux des transactions sur un serveur Exchange différent de celui sur lequel vos boîtes aux lettres résident habituellement. La cible de SCR peut être locale ou distante et peut être un serveur Exchange placé en attente ou un cluster. Cependant, SCR ne nécessite pas de cluster à l’un de ces emplacements et diffère de CCR en ceci que la cible est un environnement placé en mode d’attente et que le basculement est un processus manuel. Notez que vous devez toujours transférer une première copie de taille importante sur le réseau : pour simplifier, une sauvegarde complète. Vous pouvez avoir besoin d’effectuer cette réplication conséquente de temps à autres et devez être conscient de l’impact sur votre réseau, comme avec les solutions CCR et de fournisseurs tiers. Je pense que SCR et CCR seront adoptés par une grande majorité, tout comme les produits complémentaires offrant des capacités similaires et parfois supérieures.

Lee Benjamin dirige ExchangeGuy Consulting Services. Il travaille directement avec les clients et conseille les partenaires Microsoft. Lee est président du plus grand groupe d’utilisateurs d’Exchange au monde, ExchangeServerBoston, et l’un des directeurs du BostonUserGroups. Lee est également MVP Exchange, Microsoft Certified Trainer et orateur régulier aux conférences de l’industrie.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 Communications: Am&#233;liorer la s&#233;curit&#233; avec Windows Mobile&#160;6
Communications Matt Fontaine

Améliorer la sécurité avec Windows Mobile 6
Vue d'ensemble:
  • Sécurité sur périphérique
  • Sécurité d’Exchange Server
  • Sécurité réseau

Les périphériques mobiles améliorent la productivité des professionnels du monde entier, leur donnant accès aux informations d’entreprise et leur permettant de rester connectés même lorsqu’ils sont
physiquement absents du bureau. Les améliorations de la productivité sont réelles : allumez simplement votre périphérique mobile et vous pouvez commencer à travailler.
Le revers de la médaille est la tâche difficile des informaticiens qui doivent garantir la sécurité et la stabilité du bureau virtuel. De leur point de vue, chaque périphérique mobile est une fuite de sécurité réseau potentielle à boucher et un risque éventuel de vol de données. Le mise en place d’un déploiement plus sécurisé des périphériques mobiles est cruciale, mais elle doit également être ajustée pour offrir un environnement intuitif et transparent.
Microsoft® Windows Mobile® 6 et son prédécesseur, Windows Mobile 5.0 avec la mise à jour MSFP (pack de fonctionnalités messagerie et sécurité) incluent de nombreuses fonctionnalités vous aidant à sécuriser l’infrastructure d’entreprise avec une difficulté minimale, et un désagrément négligeable pour vos utilisateurs. L’utilisation de Microsoft Exchange Server comme plate-forme de messagerie augmente les options de sécurité disponibles. Dans cet article, je démontrerai comment vous pouvez utiliser Windows Mobile, Exchange Server et certaines meilleures pratiques de sécurité réseau comme fondation pour la protection des périphériques mobiles de votre entreprise.

Architecture mobile de communication
Il existe trois couches à considérer pour la planification ou la mise à niveau d’un déploiement mobile : le périphérique, le serveur de messagerie et le réseau (voir la figure 1). Au niveau du périphérique, les défis principaux sont d’accepter exclusivement les accès autorisés au périphérique et d’empêcher l’exécution d’applications non autorisées sur ce dernier. Windows Mobile empêche l’accès non autorisé au périphérique par authentification par numéro d’identification personnel et la protection par mot de passe, le verrouillage après délai d’attente et la capacité d’effacer la mémoire du périphérique localement ou à distance s’il est perdu ou volé. Le chiffrement de données du canal de communications et du stockage amovible est pris en charge. Il est également essentiel d’empêcher les applications non autorisées telles que les virus ou les logiciels espions d’être installés ou d’accéder à des parties critiques du périphérique. La définition de rôle de gestion, les niveaux d’accès aux niveaux d’accès d’application, les paramètres de signature de code, les paramètres de sécurité et les certificats de sécurité sont combinés pour contribuer à atteindre une protection de niveau périphérique.
Figure 1 Couches de communication mobile
Figure 1 Couches de communication mobile
La couche de sécurité suivante est le serveur de messagerie, tel qu’Exchange Server 2003 avec Service Pack 2 (SP2) ou Exchange Server 2007. Cette couche inclut la sécurité de message (la technologie par laquelle les messages sont transmis de manière sécurisée depuis et à destination de périphériques) tout comme l’interaction entre le serveur de messagerie électronique et le périphérique mobile à l’aide d’Exchange ActiveSync®. Exchange Server n’est pas requis pour l’utilisation des périphériques Windows Mobile, mais l’utilisation d’Exchange offre des avantages en termes de coût, d’évolutivité, de performances et d’administration.
De bonnes pratiques de sécurité de niveau périphérique et sécurité de serveur de messagerie sont essentielles, mais la protection de la couche réseau est également critique. En configurant votre réseau d’entreprise conformément aux meilleures pratiques et en implémentant des protocoles de sécurité forts, vous pouvez contribuer à éviter au réseau de subir des dommages, même si un ou plusieurs périphériques mobiles sont compromis.

Stratégies de sécurité sur périphérique
La première ligne de défense contre les violations de sécurité est le périphérique s’appuyant sur Windows Mobile. Le système d’exploitation Windows Mobile fournit des services de sécurité de niveau périphérique complets prenant en charge authentification, chiffrement de carte de stockage, réseau virtuel privé (VPN), chiffrement Wi-Fi et services SSL (Secure Sockets Layer). La sécurité de niveau périphérique implique la gestion des utilisateurs ayant accès à un périphérique et à ses données, le contrôle des applications pouvant s’exécuter sur le périphérique et la définition de la manière dont les données sont transmises depuis et à destination du périphérique. En général, les administrateurs disposent d’une grande flexibilité dans la définition et l’application des stratégies de sécurité sur Windows Mobile 5.0 avec MSFP et Windows Mobile 6.
L’accès utilisateur est géré par le biais d’une authentification par numéro d’identification personnel ou mot de passe. Un périphérique peut être défini pour se verrouiller automatiquement après une période d’inactivité ou après avoir été éteint, nécessitant qu’un utilisateur le déverrouille pour l’utiliser (voir la figure 2). Les détails spécifiques du contrôle d’accès d’utilisateur sont définis par les stratégies de sécurité, qui peuvent être modifiées en fonction du rôle de sécurité de l’administrateur.
Figure 2 Définition des stratégies de mot de passe
Figure 2 Définition des stratégies de mot de passe
Les stratégies de sécurité définissent des niveaux globaux de sécurité pour le périphérique mobile (voir la figure 3). Les rôles de sécurité déterminent qui peut définir et modifier ces stratégies de sécurité. Le rôle de Gestionnaire, habituellement réservé aux opérateurs mobiles, offre un contrôle intégral des paramètres de stratégie de sécurité. Le rôle d’Entreprise est utilisé par Exchange pour gérer certaines stratégies de périphérique, qui sont configurées par l’administrateur Exchange. En fonction de votre accord avec le fournisseur du périphérique, vous pouvez avoir la possibilité de personnaliser les stratégies de sécurité pour votre entreprise.
Figure 3 Stratégies de sécurité pour les périphériques mobiles (Close Figure 3)

Stratégie Périphérique mobile
Blocage de l’intrusion non autorisée dans le périphérique

Windows Mobile 5.0 avec MSFP

Spécifier que l’utilisateur doit toujours s’authentifier sur le périphérique pour le déverrouiller ou autoriser l’utilisateur à entrer un numéro d’identification personnel sur le bureau.
Rôle par défaut : Gestionnaire, Entreprise.

Windows Mobile 6

Accorder ou refuser à l’utilisateur l’autorisation de modifier les paramètres de chiffrement mobiles pour le média de stockage amovible.
Rôle par défaut : Gestionnaire, Entreprise.
Spécifier si l’utilisateur doit s’authentifier sur le périphérique lorsqu’il est connecté, si le verrouillage de périphérique est actif. Rôle par défaut : Gestionnaire, Entreprise.
Protéger les données sensibles en cas de vol ou de perte de périphérique

Windows Mobile 5.0 avec MSFP

Spécifier que l’utilisateur doit toujours s’authentifier sur le périphérique pour le déverrouiller ou autoriser l’utilisateur à entrer un numéro d’identification personnel sur le bureau.
Rôle par défaut : Gestionnaire, Entreprise.

Windows Mobile 5.0 avec MSFP et Windows Mobile 6

Spécifier si un mot de passe doit être configuré sur le périphérique. Configurer les paramètres d’effacement local et à distance du périphérique.
Rôle par défaut : Gestionnaire, Entreprise.
Les méthodes d’authentification personnalisables utilisées par Windows Mobile sont contrôlées par les plug-ins d’authentification locale (LAP), qui agissent en interaction avec le sous-système d’authentification local (LASS). Cette technologie permet à Exchange Server de contrôler la configuration au niveau granulaire, en appliquant par exemple des exigences de longueur de mot de passe et en forçant ou en activant l’authentification par simple numéro d’identification personnel.
Windows Mobile 6 possède un ensemble étendu de fonctions LAP configurées à l’aide d’Exchange Server 2007. Vous pouvez activer la reconnaissance de modèle de numéro d’identification personnel (pour par exemple refuser l’utilisation de modèles simples tels que « 1111 » ou « 1234 »), configurer les délais d’expiration de mot de passe ou de numéro d’identification personnel, autoriser des utilisateurs à demander une réinitialisation de numéro d’identification personnel en fonction de certaines conditions ou conserver un historique des numéros d’identification personnel/mots de passe pour empêcher les utilisateurs de réutiliser d’anciens numéros d’identification personnel ou mots de passe lorsqu’il leur est demandé d’en créer un nouveau.

Protection des données sur les périphériques
Dans l’éventualité où un numéro d’identification personnel ou un mot de passe inexacts serait entré un nombre de fois supérieur à la limite définie par l’administrateur, la fonction locale d’effacement du périphérique effectue une réinitialisation du périphérique en effaçant sa mémoire (informations d’authentification d’utilisateur incluses). La limite est définie dans le cadre des stratégies de sécurité dans Exchange Server. Après chaque série de deux entrées inexactes, le périphérique invite l’utilisateur à entrer une chaîne de clé structurée pour continuer (voir la figure 4). Ceci empêche le périphérique d’être accidentellement effacé par l’appui aléatoire sur des touches. L’effacement à distance de la carte de stockage est également possible avec Windows Mobile 6 et Exchange Server 2007.
Figure 4 Exigence de numéro d’identification personnel et mot de passe
Figure 4 Exigence de numéro d’identification personnel et mot de passe
Le verrouillage d’un périphérique ne sert pas à grand chose si une carte de stockage de 2 Go remplie de données d’entreprise sensibles est oubliée dans un taxi. Heureusement, vous pouvez également utiliser Windows Mobile 6 pour gérer ce problème. Il peut chiffrer les données de la carte de stockage pour que seul le périphérique qui a écrit sur la carte de stockage puisse la lire. Comme avec beaucoup d’autres fonctionnalités de sécurité améliorées de Windows Mobile 6, Exchange Server 2007 peut être utilisé pour offrir cette fonctionnalité de sécurité sur les ondes. Le chiffrement de carte de stockage est dans l’ensemble transparent pour l’utilisateur. Exchange Server 2007 laisse l’administrateur choisir si les utilisateurs peuvent modifier leurs paramètres de chiffrement de carte de stockage.
Trois niveaux d’autorisation permettent de décider si les applications peuvent s’exécuter sur un périphérique exécutant Windows Mobile : privilégié, normal et bloqué. Les applications de niveau privilégié (signées par un certificat dans le magasin de certificats Privilégié) peuvent écrire dans le registre et les fichiers système, mais également installer des certificats. Comme avec un PC de bureau ou un serveur, plus le nombre d’applications pouvant modifier l’environnement de système d’exploitation est important et plus grand sera le risque de compromettre cet environnement. La réduction du nombre d’applications avec accès Privilégié est généralement une bonne pratique. La plupart des applications nécessitent seulement de s’exécuter au niveau Normal (applications signées par un certificat dans le magasin de certificats Unpriv ou applications non signées que l’utilisateur a consenti à exécuter), ce qui les autorise à s’exécuter mais empêche l’accès aux fichiers système. Les applications bloquées correspondent à leur nom : elles ne peuvent pas s’exécuter en cas de signature ou d’action de l’utilisateur inexactes.
Les périphériques peuvent posséder un ou deux niveaux de configuration d’accès à la sécurité. Avec une configuration à un niveau, les applications non signées sont exécutées avec l’accès privilégié ou sont bloquées et ne peuvent simplement pas s’exécuter. Une configuration d’accès à deux niveaux exécutera les applications non signées au niveau normal si la stratégie est vérifiée avec succès ou si l’utilisateur autorise l’application à s’exécuter. En fonction des paramètres de périphérique, l’utilisateur peut être invité à accepter ou non d’exécuter une application non signée.
Les certificats numériques (l’une des formes d’authentification personnelle, de périphérique et d’application les plus habituellement utilisées) est un élément crucial de la sécurité Windows Mobile au niveau périphérique, serveur et réseau. Le système d’exploitation Windows Mobile enregistre plusieurs types de certificats dans les différents magasins de certificats du périphérique. Pour ce qui est des applications, les certificats déterminent celles qui peuvent être installées et exécutées. Pour qu’une application puisse s’exécuter sur un périphérique Windows Mobile sans que l’utilisateur y soit invité, elle doit être signée avec un certificat prouvant qu’elle a été acceptée par le programme Microsoft Mobile2Mobile. Les niveaux d’autorisation sont accordés aux applications en fonction des certificats qui leur sont associés.
Pour l’authentification réseau, chaque périphérique mobile est livré avec plusieurs certificats racine commerciaux approuvés émis par une autorité de certification (CA) comme indiqué à la figure 5. Le serveur de messagerie (par exemple, Exchange Server) vérifie l’authenticité d’un certificat racine de périphérique avant d’établir une connexion SSL avec ce périphérique. Si votre entreprise utilise des certificats personnalisés, vous pourrez avoir la possibilité de les installer sur les périphériques Windows Mobile que vous achetez, ou avoir à créer de nouveaux certificats. J’aborderai ceci plus loin dans la section sécurité réseau de cet article.
Figure 5 Administration des certificats numériques
Figure 5 Administration des certificats numériques
ActiveSync et Internet Explorer® Mobile peuvent utiliser SSL pour contribuer à sécuriser la transmission de données sécurisées entre le périphérique et un serveur Web d’entreprise. C’est vrai que la connexion existe pour la synchronisation des données Microsoft Exchange, la configuration du périphérique ou le téléchargement d’applications. SSL chiffre le canal de communication avec des chiffrements 128 bits RC4 ou 3DES afin que les données ne puissent pas être lues par des parties externes. Windows Mobile prend également en charge les réseaux privés virtuels, qui utilisent le chiffrement de paquets pour fournir une sécurité similaire à une ligne dédiée pendant l’accès à un serveur sur Internet.

Sécurité d’Exchange Server
Bien que les périphériques Windows Mobile ne nécessitent pas Exchange Server pour fonctionner, ces deux systèmes ont été conçus pour travailler étroitement ensemble et présenter une solution de bout en bout de messagerie et productivité mobile robuste. Depuis la sortie de Windows Mobile 5.0 avec MSFP, ActiveSync a été amélioré pour permettre la gestion à distance des paramètres de périphériques Windows Mobile. Il fournit des méthodes faciles mais puissantes pour la propagation et l’application de paramètres de sécurité globaux sur la plupart des périphériques Windows Mobile.
ActiveSync s’exécute sur IIS, le composant application/serveur Web de Microsoft Windows Server 2003. IIS fournit une sécurité intégrée qui contribue à protéger ActiveSync des attaques provenant du réseau. Microsoft Office Outlook® Web Access (OWA) étant également basé sur IIS, vous pouvez utiliser les mêmes certificats de sécurité pour ActiveSync et OWA.
Lorsqu'ActiveSync est utilisé pour propager une stratégie d’entreprise, cette stratégie est remise aux périphériques lors de leur synchronisation avec Exchange Server. Les utilisateurs doivent accepter les modifications, faute de quoi ils ne sont pas autorisés à se connecter au serveur. De nombreux réseaux sont utilisés par une grande variété de périphériques, y compris des périphériques anciens incapables d’accepter les stratégies de sécurité sophistiquées. Si nécessaire, vous pouvez exempter certains périphériques (tels que le matériel ancien) des exigences de stratégie de sécurité afin qu’ils puissent continuer à se connecter.
Exchange Server 2003 SP2 et Exchange Server 2007 possèdent des capacités de contrôle de stratégie de sécurité quelque peu différentes. Exchange Server 2003 SP2 peut être utilisé pour spécifier une longueur minimale de mot de passe de 4 à 18 caractères, exiger l’utilisation de chiffres et de lettres dans un mot de passe et définir la période d’inactivité autorisée avant le verrouillage d’un périphérique. Cette version d’Exchange Server peut également définir avec quelle fréquence les paramètres de sécurité sont envoyés aux périphériques, ainsi qu’autoriser les exemptions mentionnées ci-dessus pour les périphériques anciens.
Avec la sortie d’Exchange Server 2007, les capacités de gestion de périphériques mobiles d’ActiveSync ont été améliorées pour inclure toutes les capacités d’Exchange Server 2003 SP2, ainsi que les suivantes :
  • Autoriser ou rejeter les mots de passe simples (tels que « 1234 » ou « 1111 »).
  • Activer ou désactiver les téléchargements de pièces jointes.
  • Exiger le chiffrement de carte de stockage.
  • Déterminer la taille maximale de pièce jointe.
  • Permettre la récupération d’un mot de passe de périphérique par l’utilisateur à l’aide d’OWA.
  • Permettre l’accès aux fichiers UNC (Universal Naming Convention) et Microsoft Windows Sharepoint® (WSS).
Avec Exchange Server 2007, les informaticiens professionnels ont la possibilité d’adapter des stratégies à chaque utilisateur ou périphérique, de gérer des stratégies pour des groupes d’utilisateurs, ainsi que d’exempter entièrement certains utilisateurs spécifiques des stratégies de sécurité.

Effacement par accès à distance
Outre l’effacement local du périphérique décrit précédemment, vous pouvez effacer un périphérique exécutant Windows Mobile à distance en utilisant Exchange Server 2003 SP2, Exchange Server 2007 ou OWA. Les effacements à distance, qui ont lieu à la synchronisation, peuvent être exécutés même si vous n’utilisez pas les stratégies de sécurité d’ActiveSync. Un effacement matériel à distance ne peut pas être arrêté depuis le périphérique. Les données, les paramètres et les clés de sécurité sont remplacé par des zéros répétitifs, ce qui rend extrêmement difficile la récupération de toute donnée ne faisant pas partie du noyau du système d’exploitation.

Sécurité réseau
La sécurité réseau est tout aussi importante pour la sécurité mobile que le périphérique et les composants de serveur de messagerie. Elle fait également partie de l’infrastructure mobile qui est la plus clairement sous votre contrôle. Même si un ou plusieurs périphériques mobiles viennent à être compromis, la configuration de votre réseau d’entreprise conformément aux meilleures pratiques et l’implémentation des protocoles de sécurité adéquats contribueront à empêcher le réseau de subir des dommages.
Windows Mobile fonctionne bien avec un ensemble de types de réseau. En utilisant les protocoles de sécurité et les pare-feux standard d’Internet, vous pouvez concevoir une solution qui convient à vos besoins en termes de performances, de stabilité et de sécurité.
Lorsque les serveurs de messagerie sont sur le réseau de l’entreprise, ils peuvent être protégés par un pare-feu de périmètre servant de tampon entre Internet et les serveurs d’entreprise. Microsoft Internet Security and Acceleration (ISA) Server 2004 ou ISA Server 2006 disposant tous deux de fonctionnalités conçues à cet effet, ils inspectent tous les paquets entrants pour déterminer leur identité avant de les passer aux serveurs Exchange et renvoient ensuite les informations en sortie aux clients via Internet.
La configuration d’ISA Server nécessite que vous activiez le chiffrement SSL et désigniez le port 443 comme port d’écoute Web SSL pour le trafic Exchange Server. Ceci réduit l’exposition à Internet en la limitant à un seul port. En outre, il doit être exigé de tous les clients qu’ils établissement une liaison SSL avant de se connecter avec ActiveSync.
ISA Server peut authentifier au préalable les utilisateurs d’applications Web telles qu’OWA pour contribuer à empêcher les utilisateurs non authentifiés d’atteindre les serveurs d’applications. ISA Server 2006 améliore le modèle de pont SSL d’ISA Server 2004 en agissant en tant que port de terminaison SSL pour les périphériques exécutant Windows Mobile. Ceci permet aux périphériques exécutant Windows Mobile de s’authentifier auprès du serveur Exchange, sans jamais effectuer de connexion directe avec celui-ci, plutôt que de s’appuyer sur ISA Server 2006 pour passer le trafic dans un sens comme dans l’autre. Puisque l’emplacement recommandé pour ISA Server 2006 est le réseau de périmètre, ceci permet la mise en place d’une couche supplémentaire de sécurité entre la partie publique d’Internet et le serveur frontal Exchange.

Authentification
Il existe deux types d’authentification fondamentaux pouvant être choisis : authentification de base et authentification basée sur les certificats. L’authentification de base fait référence à une connexion standard basée sur SSL avec nom d’utilisateur et mot de passe entre le client Windows Mobile et le serveur frontal Exchange. Elle nécessite toujours un certificat car Exchange Server recherche un certificat racine correspondant sur le périphérique avant l’authentification. Windows Mobile et IIS vous permettent d’utiliser la vaste panoplie de méthodologies de chiffrement associées à SSL.
L’authentification basée sur les certificats, disponible dans Windows Mobile 5.0 avec MSFP et Windows Mobile 6, utilise Transport Layer Security (TLS) au lieu de l’authentification SSL de base. Outre le certificat racine, TLS nécessite que chaque utilisateur dispose d’un certificat avec clés publique et privée. Puisque TLS utilise une clé de chiffrement (jusqu’à 2 048 bits) au lieu d’un mot de passe, ce protocole offre une authentification plus forte.
Avec Windows Mobile 6, l’inscription d’un certificat d’utilisateur avec Desktop Enroll nécessite que le périphérique soit ancré dans un bureau situé dans le même domaine que le serveur d’inscription du certificat. L’utilisateur authentifie l’inscription à l’aide d’un mot de passe, d’une carte à puce ou d’une autre méthode, et connecte ensuite le périphérique à un PC de bureau. L’utilisateur accède ensuite au système du certificat par le biais du bureau qui, à son tour, installe le certificat sur le périphérique mobile. Desktop Enroll peut répondre à une variété de fonctions de sécurité de Windows Mobile, y compris le renouvellement de certificat, ainsi que la distribution de certificats d’authentification ActiveSync, de certificats d’authentification SSL/TLS, de certificats Wi-Fi 802.1x ou de certificats de signature numérique S/MIME.
Les protocoles de sécurité tels que SSL protègent les données des messages pendant leur transit, mais ne les chiffrent pas une fois qu’ils atterrissent sur le périphérique exécutant Windows Mobile ou le serveur Exchange. S/MIME est une forme sécurisée de la norme de message électronique MIME courante qui prend en charge la messagerie électronique chiffrée et/ou avec signature numérique. Ceci fournit une couche supplémentaire de protection, outre le chiffrement de couche de transport SSL, au-dessus de celui-ci.

Conclusion
La création d’une infrastructure suffisamment sécurisée nécessite de prendre en compte chacune des nombreuses couches qui forment une solution. Windows Mobile, Exchange Server et les produits de sécurité de réseau de Microsoft tels qu’ISA Server fonctionnent en collaboration pour supprimer une bonne partie fastidieuse de la gestion de l’infrastructure mobile. Ceci contribue à alléger la pression sur les services informatiques, en leur évitant de se concentrer sur les défis que les périphériques mobiles posent pour la sécurité et de profiter des accroissements de productivité qu’ils génèrent.

Remerciements à Kathy Esser, Katharine Holdsworth, Sarah Norton et Chip Vollers pour leur assistance dans la rédaction de cet article.

Matt Fontaine est rédacteur technologique de la société BuzzBee.


 Communications: Une alternative puissante aux dossiers publics
Communications Alan Maddison

Une alternative puissante aux dossiers publics
Vue d'ensemble:
  • Partage des calendriers et des contacts
  • Communications par le biais de blogs et de wikis
  • Partage et gestion de documents

Les dossiers publics existent depuis la première version de Microsoft Exchange ; à l’origine, leur objectif était de fournir une plate-forme fondamentale pour le partage de documents, l’archivage des listes de distribution et le développement personnalisé d’applications. Cependant, depuis le début
quasiment, les administrateurs ont du mal à gérer et utiliser ce qui est devenu une partie de plus en plus complexe dans les environnements Exchange. Bien qu’Exchange Server 2007 ait introduit des améliorations significatives dans la gestion des dossiers publics, le défi demeure. Les dossiers publics ne fournissent tout simplement pas la collaboration et la plate-forme de gestion des documents robustes dont les entreprises ont besoin de nos jours.
Microsoft a annoncé qu’Exchange Server 2007 était sans doute la dernière version du produit à prendre en charge les dossiers publics. Même s’ils sont entièrement pris en charge et qu’ils continueront à l’être pendant les 10 années suivant le lancement d’Exchange Server 2007, c’est l’occasion d’envisager une alternative.
Heureusement, Microsoft a fourni une option intéressante avec le lancement de Microsoft® Office SharePoint® Server (MOSS) 2007. MOSS 2007 offre la plate-forme dont les administrateurs informatiques et les entreprises ont besoin pour remplacer et dépasser les capacités offertes par les dossiers publics. Dans cet article, je démontre comment MOSS présente une infrastructure robuste et puissante qui peut offrir beaucoup plus de fonctionnalités que les dossiers publics Exchange. Je me concentrerai en particulier sur l’utilisation de SharePoint pour des tâches pour lesquels les dossiers publics sont habituellement utilisés, telles que le partage de calendriers, de contacts et de documents.
N’oubliez pas que vous continuerez à avoir besoin de dossiers publics au moins jusqu’à ce que vous mettiez vos clients à jour. Les clients Microsoft Outlook® d’Outlook 97 à Outlook 2003 nécessitent des dossiers publics pour plusieurs raisons, y compris des carnets d’adresses hors connexion, la Bibliothèque de formulaires de l’organisation et des recherches de disponibilité. Lorsque vous passez à Outlook 2007 et Exchange Server 2007, vous pouvez arrêter d’utiliser les dossiers publics pour de bon dès que vous êtes prêt.

Calendriers SharePoint
Les calendriers partagés sont une utilisation courante des dossiers publics et SharePoint simplifie énormément le remplacement d’un calendrier de dossier public par un calendrier SharePoint. Bien qu’une installation par défaut d’un site SharePoint comprenne un calendrier, vous devrez probablement créer plusieurs calendriers pour répondre aux besoins de votre organisation. Pour démontrer cela, je vous décrirai étape par étape la création d’un calendrier partagé pour une équipe des ressources humaines. La première étape consiste à sélectionner Afficher tout le contenu du site ; cette option figure généralement dans le coin supérieur gauche du site SharePoint (voir la figure 1).
Figure 1 Création d’un nouveau contenu de site
Figure 1 Création d’un nouveau contenu de site
Après avoir sélectionné Afficher tout le contenu du site, cliquez sur le bouton Créer (qui apparaît également à la figure 1). Une fois la page Créer chargée, vous verrez les options de type de contenu par défaut (comme illustré à la figure 2). Pour créer un calendrier, vous devez sélectionner Calendrier dans la colonne Suivi. Vous devez ensuite remplir les champs de nom et description et choisir d’inclure ou non le calendrier dans la section Liens rapides.
Figure 2 La page Créer affiche de nombreuses options par défaut
Figure 2 La page Créer affiche de nombreuses options par défaut
À ce stade, le calendrier est créé. L’utilisateur a la possibilité d’afficher le calendrier partagé via le site SharePoint ou directement dans Outlook. Pour la deuxième option, l’utilisateur doit juste se connecter au calendrier à l’aide du navigateur Web, puis ouvrir le menu Actions et sélectionner l’option Connexion à Outlook.
Lorsque la connexion est établie pour la première fois, Outlook affiche un avertissement de sécurité pour rappeler aux utilisateurs qu’ils doivent se connecter uniquement à des sources connues et fiables. Après sélection du Oui, le calendrier sera connecté à Outlook. La figure 3 montre l’affichage par défaut, qui affiche le calendrier SharePoint et le calendrier Outlook côte à côte.
Figure 3 Affichage du calendrier SharePoint et du calendrier Outlook côte à côte
Figure 3 Affichage du calendrier SharePoint et du calendrier Outlook côte à côte
Une fois le calendrier connecté à Outlook, une synchronisation bidirectionnelle peut survenir. Tous les événements entrés via Outlook sont synchronisés avec SharePoint et tous les utilisateurs qui affichent le calendrier verront les entrées mises à jour. De plus, si vous avez activé la prise en charge SMTP dans SharePoint, les événements peuvent être envoyés directement au calendrier par courrier électronique et SharePoint ajoutera ces entrées.

Contacts SharePoint
Des contacts partagés, qui utilisent également des dossiers publics, sont utilisés par un grand nombre d’organisations. Ici aussi, SharePoint fournit une alternative plus robuste, en simplifiant la création et la gestion des listes de contacts. Pour rester avec le même exemple, je vais maintenant vous montrer comment créer une liste de contacts partagée pour le service des ressources humaines de notre exemple.
Comme plus haut, sélectionnez Afficher tout le contenu du site et cliquez sur le bouton Créer. À présent, sélectionnez le lien Contacts dans la colonne Communications. Vous verrez apparaître un écran dans lequel vous fournissez des informations concernant le Nom, la Description, et la configuration de lien rapide (voir la figure 4). Une fois ces informations complétées, il vous suffit de cliquer sur le bouton Créer et la nouvelle liste de contacts est créée.
Figure 4 Remplissage des champs Nom, Description et Configuration de lien rapide
Figure 4 Remplissage des champs Nom, Description et Configuration de lien rapide

Communication entre utilisateurs
Vous pouvez également utiliser SharePoint pour créer un forum de discussion (appelé également liste de discussion). Comme avec les Calendriers et les Contacts, le processus de création est très simple : sélectionnez Afficher tout le contenu du site, cliquez sur le bouton Créer et sélectionnez le lien Forum de discussion dans la colonne Communications. Comme précédemment, fournissez les informations appropriées pour le Nom, la Description et la Configuration de lien rapide, puis cliquez sur le bouton Créer. La figure 5 montre un forum de discussion avec des exemples de messages.
Figure 5 Exemple de forum de discussion avec quelques messages
Figure 5 Exemple de forum de discussion avec quelques messages
En plus des forums de discussion, SharePoint Server prend maintenant en charge deux outils de communication très courants : les blogs et les wikis. Non disponibles avec les dossiers publics, les blogs et les wikis font leur première apparition dans SharePoint Server 2007 et ces outils fournissent des fonctions intéressantes et utiles à l’ensemble des fonctionnalités.
Les blogs fournissent un forum interactif où un blogueur peut facilement partager des réflexions et idées en les publiant sur un site Web. Généralement, ces messages sont classés pour que les lecteurs trouvent plus facilement les messages susceptibles de les intéresser. Les lecteurs peuvent apporter des réponses aux commentaires d’un blogueur. Des membres de la haute direction d’une entreprise, par exemple, peuvent avoir un blog. Il peut représenter un outil puissant pour communiquer avec les employés et il fournit un moyen pour les membres du personnel de partager des idées et de faire en sorte que la communication se maintienne à tous les niveaux.
Il est très facile de créer un blog dans SharePoint. La première étape consiste à sélectionner Afficher tout le contenu du site, cliquer sur le bouton Créer, puis cliquer sur Sites et espaces de travail sous la colonne Pages Web. Ceci vous amène à la page du nouveau site SharePoint, où vous devez fournir le Titre, le Nom et l’URL du site. Vous choisissez ensuite un modèle pour le site ; dans ce cas, choisissez le modèle Blog. Les trois dernières options de configuration concernent les autorisations, la navigation et la liste des répertoires du site. Après avoir complété toutes les options requises, appuyez sur le bouton Créer. Ceci crée en fait un sous-site dans votre site de niveau supérieur et le sous-site contient des bibliothèques et des listes qui fournissent les capacités de blog. Une fois le processus terminé, vous accédez au nouveau blog.
Un wiki est un autre outil intéressant conçu pour une création encore plus en collaboration. Les utilisateurs peuvent ajouter, supprimer et modifier le contenu du site ou encore relier de nombreuses pages. La méthode la plus simple pour créer un wiki consiste à sélectionner Afficher tout le contenu du site, cliquer sur le lien Créer, puis sélectionner Bibliothèque de pages Wiki, qui figure dans la colonne Bibliothèques. Après avoir complété les champs Nom, Description et Configuration de la navigation requis, appuyez sur le bouton Créer et le tour est joué. Pour plus d’informations sur l’utilisation des wikis dans SharePoint, voir l’article « Travailler en Wiki » dans le numéro de janvier 2007 de TechNet Magazine.

Bibliothèques SharePoint
Les dossiers publics sont en effet devenus des référentiels de documents, fournissant un emplacement central où les utilisateurs peuvent accéder à et partager facilement des documents. Comme les administrateurs Exchange l’ont remarqué au fil des années, il s’agit de l’une des principales utilisations à avoir rendu les dossiers publics si encombrants. Non seulement ceci entraîne une augmentation des E/S d’Exchange pour la base de données des dossiers publics, mais il y a également un impact sur la réplication à travers l’infrastructure Exchange. Les bibliothèques SharePoint fournissent une alternative excellente, en déchargeant Exchange et ses ressources.
Une bibliothèque SharePoint est un emplacement dans un site SharePoint qui vous permet de stocker et gérer des fichiers. On distingue plusieurs types de bibliothèques, notamment pour les images, les pages Wiki, les formulaires et les documents. Si vous recherchez une solution de remplacement pour les dossiers publics, la bibliothèque de documents est le choix le plus approprié. Une bibliothèque de documents prend en charge le stockage, la gestion et, dans certains cas, la création de documents dans le site SharePoint.
De nombreux types différents de fichiers peuvent être stockés dans une bibliothèque de documents, mais certains types de fichiers (notamment les fichiers exécutables et les scripts) sont restreints par défaut pour des raisons de sécurité. Cependant, ces restrictions peuvent être configurées à l’aide de la section Opérations du site d’administration centrale de SharePoint.
L’installation par défaut de MOSS comprend une bibliothèque de documents qui peut être personnalisée. La plupart des organisations souhaiteront créer plusieurs bibliothèques pour prendre en charge les différentes divisions de l’organisation. Il est facile d’y arriver en utilisant les outils fournis par SharePoint. Par exemple, pour déployer une bibliothèque de documents pour les Ressources Humaines, sélectionnez Afficher tout le contenu du site, cliquez sur le lien Créer, puis choisissez l’option Bibliothèque de documents, répertoriée dans la colonne Bibliothèques. Vous verrez ensuite un certain nombre de paramètres que vous devez configurer : fournissez un nom et une description pour la bibliothèque, spécifiez si vous souhaitez inclure la bibliothèque dans la section Liens rapides, choisissez l’activation ou non du contrôle de version et sélectionnez un format par défaut pour les nouveaux documents créés directement dans la bibliothèque.
Accordez une attention particulière à l’option Historique des versions du document. Par défaut, cette option est désactivée. Cependant, le contrôle de version peut être utile et adapté dans de nombreux environnements. En plus de stocker des copies historiques de documents, cette fonctionnalité effectue le suivi des modifications et de leurs auteurs et fournit également la capacité d’afficher et de restaurer des versions précédentes.
La figure 6 montre la bibliothèque de documents qui vient d’être créée avec certains documents téléchargés. Une fois que vous avez créé vos bibliothèques de documents, vous pouvez rendre ces référentiels accessibles via Microsoft Outlook et l’Explorateur Windows®. Outlook vous permet de prendre le contenu d’une bibliothèque de documents hors ligne et de fournir une copie en lecture seule aux utilisateurs qui n’ont pas accès au réseau. L’accès par l’Explorateur Windows utilise les Favoris réseau. En entrant l’URL de la bibliothèque de documents, vous pouvez fournir un accès à vos utilisateurs. Dans les plus grands environnements, vous pouvez utiliser la Stratégie de groupe pour déployer ces Favoris réseau.
Figure 6 Bibliothèque de documents, qui contient des documents téléchargés
Figure 6 Bibliothèque de documents, qui contient des documents téléchargés

Au delà des principes fondamentaux
SharePoint offre un ensemble de fonctionnalités qui dépasse indéniablement les capacités fournies par les dossiers publics. En plus de vous apporter certaines des fonctionnalités courantes offertes par les dossiers publics, SharePoint Server fournit également des capacités plus puissantes qui peuvent étendre le pouvoir de ces utilisations courantes. Voici quelques-unes des capacités améliorées :
  • Historique des versions
  • Contrôle d’approbation
  • Procédures de validation
  • Contrôle du flux de travail
  • Stratégies de rétention des documents
  • Audit
  • RSS
Ces types de fonctionnalités sont essentiels à toute plate-forme de gestion de contenu d’entreprise et SharePoint fournit une infrastructure robuste que les administrateurs peuvent utiliser aisément. Ces fonctionnalités améliorées peuvent être activées pour un grand nombre des fonctions SharePoint, y compris les Calendriers, les Tâches, les Forums de discussion et les Bibliothèques de documents.
Pour configurer ces fonctionnalités, sélectionnez le menu Paramètres, puis choisissez l’option de paramètres ; par exemple, l’option Paramètres de la bibliothèque de documents, comme illustré à la figure 7. Vous accédez ainsi à la page Paramètres, où vous pouvez voir toutes les options de configuration et de personnalisation disponibles. Le lien Paramètres de contrôle de version sous la colonne Paramètres généraux, par exemple, vous permet de configurer l’historique des versions.
Figure 7 Sélection de l’option de paramètres pour configurer les fonctionnalités améliorées
Figure 7 Sélection de l’option de paramètres pour configurer les fonctionnalités améliorées
Comme je l’ai déjà dit, ces fonctionnalités fournissent un enregistrement des modifications du document, y compris l’identité de l’auteur des modifications et leurs dates, et permet à l’utilisateur d’afficher et de restaurer des versions précédentes si nécessaire. Il est également possible de contrôler le nombre de versions stockées par SharePoint. Une fois cette limite atteinte, les éléments sont supprimés sans être envoyés dans la Corbeille SharePoint.
La section Contrôle de version vous permet également de configurer les conditions d’approbation et de validation de contenu dont vous avez besoin. Lorsque l’option Approbation de contenu est activée, les éléments soumis doivent être approuvés avant d’être mis à la disposition d’autres utilisateurs. Les éléments qui n’ont pas été approuvés restent en état d’attente. Le processus de validation fournit un contrôle de contenu en interdisant à plusieurs utilisateurs de travailler sur un fichier en même temps.
Les flux de travail sont une autre fonctionnalité utile offerte par SharePoint qui n’est pas disponible avec les dossiers publics. En gros, les flux de travail offrent une approche structurée aux processus métier qui peuvent aider à optimiser les activités de votre entreprise. Implémentés dans SharePoint, les flux de travail sont une série de tâches prédéfinies qui automatisent le mouvement d’un document dans le processus désigné. Le processus peut être itératif, ce qui nécessite que chaque étape soit complétée avant de passer à l’étape suivante, ou le processus peut être parallèle, ce qui permet à une tâche donnée d’être complétée à n’importe quel moment. Les flux de travail par défaut inclus avec SharePoint sont :
  • Approbation
  • Recueillir les commentaires
  • Recueillir les signatures
  • Approbation de destruction
Des stratégies de gestion des informations sont utilisées pour appliquer la conformité aux règlements et aux besoins de l’entreprise. Une stratégie consiste en une série de règles liées à la gestion et au contrôle de documents. SharePoint Server prend en charge des règles personnalisées, mais il inclut des règles par défaut pratiques, telles que :
  • Audit
  • Expiration
  • Étiquettes
  • Codes-barres
Les audits permettent de consigner les événements en fonction d’une série d’actions que vous définissez dans les paramètres du site. Vous pouvez effectuer le suivi d’actions telles que l’ouverture d’un document, le téléchargement ou l’affichage d’un élément ou de ses propriétés, la modification d’un document, la vérification d’un document, le déplacement ou la copie d’éléments et la suppression ou la restauration d’éléments.
L’expiration du contenu vous permet de supprimer des contenus pour maintenir la conformité avec les stratégies de rétention des données de votre organisation. Cette expiration des données peut survenir à une date précise ou sur une période fixe après un certain événement, tel que la création de documents.
Les étiquettes sont utilisées en conjonction avec l’impression, elles permettent d’ajouter du texte à l’élément imprimé. Dans la pratique, cette stratégie peut avoir plusieurs utilisations. Par exemple, vous pourriez avoir besoin que tous les documents de la bibliothèque de documents partagée par les ressources humaines contiennent un avertissement de confidentialité pour être en conformité avec les règlements de votre service juridique.
Les codes-barres fournissent une méthode de suivi formelle pour les documents en ligne et imprimés. SharePoint créera un identifiant unique pour chaque document, puis les utilisateurs ont la possibilité d’insérer une image du code-barres dans leur document.
Autre amélioration significative offerte par SharePoint : son intégration avec les flux RSS. Les calendriers, contacts, bibliothèques de documents et forums de discussion fournissent tous un flux RSS auquel un utilisateur peut s’abonner. Vos utilisateurs peuvent recevoir des mises à jour automatiques pour aider à effectuer le suivi de leurs responsabilités quotidiennes, et tout ce dont ils ont besoin est un lecteur RSS, tel qu’Outlook 2007.

Conclusion
Microsoft Office SharePoint Server 2007 fournit des fonctionnalités d’entreprise et offre une alternative plus puissante aux dossiers publics Exchange. Une infrastructure administrative robuste simplifie l’implémentation d’une solution pour le partage de calendriers, de contacts et de documents. Vous pouvez également créer une variété de méthodes de communication, notamment des forums de discussion, des blogs et des wikis.

Alan Maddison est consultant senior dans le département de technologie Microsoft chez MTI Technology Corporation. Ses domaines de spécialisation sont Active Directory, Exchange Server et la virtualisation.


 Communications: Connexion &#224; Outlook Web Access avec cartes &#224; puce
Communications Victor Akinnagbe and Ted Dressel and Jason Opdycke

Connexion à Outlook Web Access avec cartes à puce
Vue d'ensemble:
  • Authentification à deux facteurs
  • Délégation contrainte du protocole Kerberos
  • Configuration d’ISA Server et d’Exchange

Les employés mobiles présentent un défi de sécurité unique pour les organisations informatiques. Les utilisateurs distants nécessitent l’accès sécurisé aux données et aux services tels que la messagerie électronique. La tragique réalité est cependant que les
liens les plus vulnérables de la chaîne de sécurité impliquent des mots de passe faibles, des logiciels malveillants (tels que les enregistreurs de frappe) et des virus sur les ordinateurs distants qui accèdent aux ressources internes de votre organisation.
La suppression d’un de ces maillons faibles constitue une méthode d’amélioration de la sécurité dans cet environnement mobile. Il s’agit des mots de passe (bien que l’idée de l’autorisation d’accès à un compte sans mot de passe pour l’authentification puisse paraître déroutante). Une technique principale pour l’élimination des problèmes associés aux mots de passe est connue comme l’authentification à deux facteurs (ou parfois authentification multifacteur). Plutôt que de se fier à une seule méthode (un mot de passe) pour autoriser l’accès, l’authentification à deux facteurs oblige l’utilisation de méthodes d’authentification supplémentaires, y compris une combinaison de nom d’utilisateur et mot de passe, un périphérique physique tel qu’une carte à puce ou un identificateur biométrique tel qu’une empreinte digitale.
Si vous avez des utilisateurs distants, vous êtes généralement obligé d’ouvrir votre pare-feu dans une certaine mesure pour permettre l’accès au réseau de l’entreprise. Un pare-feu standard vous offre une atténuation de risque de base avec l’isolation au niveau du réseau entre réseaux interne et externe (voir la figure 1). Pour renforcer la sécurité, les ports sont simplement fermés et, si la communication doit se produire sur un périphérique sur le réseau interne, les ports sont ensuite transférés vers l’emplacement approprié. Ces techniques assurent une protection conséquente au niveau du réseau, mais plusieurs couches de sécurité réseau sont maintenant devenues nécessaires en raison de la sophistication toujours croissante des attaques.
Figure 1 Pare-feu standard avec ports bloqués ou transférés
Figure 1 Pare-feu standard avec ports bloqués ou transférés
Puisque les services d’entreprise les plus courants que les employés vont probablement utiliser sont la messagerie électronique et la messagerie instantanée, la configuration de votre infrastructure Exchange revêt plus d’importance que jamais. Offrir l’accès à vos utilisateurs à la messagerie électronique au travers d’Outlook® Web Access (OWA) est une méthode permettant de fournir des services sécurisés aux employés mobiles. La mise en place de l’authentification à deux facteurs pour OWA à l’aide de cartes à puce est une autre étape essentielle. Dans cet article, nous examinerons de plus près les problèmes de configuration et d’installation dont vous devez être conscient avant de mettre en place votre propre déploiement d’OWA avec cartes à puce.

Mieux qu’un pare-feu
L’utilisation de Microsoft® Internet Security and Acceleration (ISA) Server 2006 sur votre réseau peut simplifier la tâche d’ouverture de votre réseau aux utilisateurs distants d’une manière plus sécurisée. ISA Server 2006 inclut des fonctionnalités d’amélioration de la sécurité telles que les réseaux privés virtuels (VPN), l’authentification au protocole LDAP (Lightweight Directory Access Protocol) auprès d’Active Directory® et la délégation contrainte du protocole Kerberos avec prise en charge de cartes à puce. ISA Server est quelque peu différent de ce que vous pourriez traditionnellement penser d’un pare-feu. Il fournit des couches multiples de sécurité non seulement en fonctionnant au niveau de la couche de réseau (ce qu’il peut effectuer à la place de votre pare-feu matériel standard ou en conjonction avec celui-ci), mais également en fournissant des composants de sécurité supplémentaires généralement non pris en charge dans les pare-feux traditionnels, tels que les filtres d’application. Vous ne souhaitez pas que quelqu’un puisse utiliser la méthode HTTP POST sur un site Web hébergé particulier ? Vous voulez forcer la conformité RFC sur les messages SMTP avant qu’ils n’atteignent votre serveur Exchange ? Vous désirez inspecter les paquets HTTP chiffrés au protocole SSL (Secure Sockets Layer) avant qu’ils arrivent sur le réseau ? ISA Server peut gérer toutes ces tâches et davantage pour s’assurer que seul le trafic propre, filtré, est transféré vers votre zone DMZ ou votre réseau interne.
Les sessions SSL constituent un peu un problème pour les pare-feux standard. Lorsque les paquets passent au travers du pare-feu, ils restent chiffrés (ce qui signifie que SSL fonctionne correctement). Ainsi, si une application telle qu’OWA est publiée au travers d’un pare-feu matériel ou logiciel utilisant SSL, il n’existe véritablement aucun type d’inspection acceptable pouvant être effectuée par le pare-feu standard, mis à part une inspection de paquets complète. L’ouverture et la fermeture de ports peuvent provoquer l’exposition d’une zone de surface d’attaque conséquente. Puisque aucune véritable inspection n’a lieu à la périphérie, les paquets non inspectés et non authentifiés peuvent être routés dans votre réseau interne.
ISA Server 2006 peut servir de point SSL final pour les clients HTTP, s’assurant que seul le trafic authentifié atteint le serveur Exchange publié. ISA Server prend également en charge une fonctionnalité pratique, le pont SSL. Habituellement, un paquet est chiffré par un client qui communique à l’aide d’une session SSL standard avec ISA Server. Avec le pont SSL, ISA Server peut mettre fin au chiffrage SSL localement, inspecter le paquet maintenant déchiffré, authentifier l’utilisateur auprès d’Active Directory (si nécessaire), rechiffrer le paquet avec SSL et passer le paquet chiffré au serveur Exchange approprié (voir la figure 2). À l’aide de cette technique, le pont SSL atténue les attaques masquées dans les sessions SSL qui auraient simplement l’air de morceaux de données chiffrées pour un pare-feu incapable de gérer les applications.
Figure 2 ISA Server observe le trafic du point de vue de la couche d’application
Figure 2 ISA Server observe le trafic du point de vue de la couche d’application
Le trafic authentifié au préalable qui atteint le serveur est un point important à noter concernant la délégation contrainte du protocole Kerberos. Dans un pare-feu standard, les ports sont simplement transférés vers le serveur Exchange et le serveur frontal est lui-même responsable de l’exécution des tâches d’authentification à l’encontre de ce qui pourrait être des utilisateurs malveillants. Lorsque l’authentification est requise, ISA Server peut contacter directement Active Directory et faire la demande des informations d’authentification de la part de l’utilisateur. Si l’utilisateur est authentifié avec succès, ISA Server transférera le message au serveur frontal Exchange. Le serveur frontal n’a plus à authentifier de demandes d’utilisateurs inconnus aléatoires et peut être uniquement utilisé pour les requêtes de proxy des serveurs principaux. ISA Server 2006 peut également utiliser la délégation contrainte du protocole Kerberos pour permettre l’accès à base de certificat aux technologies telles que Windows SharePoint Services et Exchange ActiveSync.
Exchange Server 2003 inclut la prise en charge de l’authentification basée sur Kerberos entre les serveurs frontaux et principaux pour les connexions d’OWA. (Vous utilisez bien IPSec pour protéger ce trafic client, n’est-ce pas ?) Exchange Server prend également en charge l’authentification Kerberos auprès des serveurs de boîtes aux lettres en cluster.

Permettre l’authentification avec carte à puce
La mise en place de l’authentification par carte à puce pour OWA constitue un défi. Cependant, une solution a été développée sur la base de la fonctionnalité de délégation contrainte du protocole Kerberos désormais disponible dans ISA Server 2006. La solution permet à un utilisateur de soumettre des informations d’authentification à l’aide d’un certificat afin de réussir à s’authentifier auprès d’OWA. La délégation contrainte du protocole Kerberos est une amélioration bienvenue de la prise en charge de la délégation de Kerberos dans Windows® 2000, qui utilisait une délégation sans contraintes. La fonction de contrainte de Kerberos est plus sécurisée et limite le risque potentiel d’attaques sophistiquées utilisant l’usurpation d’identité.
Dans le scénario avec carte à puce, ISA Server 2006 contacte Active Directory pour authentifier l’utilisateur, puisque l’utilisateur n’a pas d’accès routable à un centre de distribution de clés du réseau externe. ISA Server fait appel au mappage certificat-utilisateur d’Active Directory pour authentifier l’utilisateur et acquiert ensuite les tickets Kerberos respectifs en fonction du nom utilisateur principal (UPN). Dans ce cas, ISA Server fournit la fonctionnalité de délégation contrainte du protocole Kerberos à un serveur frontal Exchange via le filtrage au niveau de l’application et les services de proxy inversé. Si la délégation est tentée sans proxy inverse, le risque d’exploits accru pourrait affecter l’intégrité du réseau ou du domaine Active Directory.
Exchange Server 2003 et Exchange Server 2007 permettent tous deux l’authentification de base et intégrée. Cependant, vous devez appliquer une mise à jour logicielle à Exchange Server 2003 pour que l’authentification avec carte à puce auprès d’OWA puisse fonctionner. (Pour plus d’informations, consultez l’article ayant trait à la « Description de la nouvelle fonctionnalité d’Exchange Server 2003 prenant en charge l’authentification avec carte à puce auprès d’Outlook Web Access ».) Vous devez posséder un domaine en mode fonctionnel natif Windows Server® 2003, tous les serveurs Exchange Server 2003 impliqués doivent avoir le Service Pack SP2 (ou ultérieur) installé et vous avez besoin d’un serveur ISA Server 2006 agissant en tant que proxy inverse pour le site OWA.
Après avoir installé la mise à jour logicielle et configuré vos serveurs ISA et Exchange, les utilisateurs peuvent authentifier une session OWA à l’aide d’une carte à puce. La figure 3 illustre le flux d’événements requis pour l’authentification avec carte à puce. Un utilisateur commence en ouvrant le site OWA dans Internet Explorer® (1). En fait, l’utilisateur se connecte à ISA Server et est invité à présenter un certificat au lieu d’un nom d’utilisateur et d’un mot de passe pour démarrer la session OWA. Le certificat approprié est enregistré sur la carte à puce, pour laquelle l’utilisateur nécessite un numéro d’identification personnel.
Figure 3 Authentification OWA avec carte à puce
Figure 3 Authentification OWA avec carte à puce
La validation de certificat (2) est gérée à l’aide d’une liste de révocation des certificats (CRL) ou une requête au protocole OCSP (Online Certificate Status Protocol), en fonction de la configuration d’ISA Server et des autres logiciels installés. ISA Server effectue une requête au contrôleur de domaine (DC) afin de vérifier les informations d’authentification de l’utilisateur. Si la requête échoue, ISA Server affiche une page d’erreur à l’utilisateur et aucune requête n’atteint le serveur frontal Exchange.
Une fois les informations d’identification vérifiées, le ticket Kerberos est généré et la requête est passée au serveur frontal Exchange à l’aide de l’authentification intégrée (3). Lorsque le serveur frontal Exchange reçoit la requête, il valide le ticket Kerberos et recherche le serveur de boîtes aux lettres principal de l’utilisateur (4).
Le serveur frontal demande un ticket Kerberos pour le serveur principal approprié à l’aide de la délégation contrainte de Kerberos et transfère la requête de boîte aux lettres au serveur principal en utilisant l’authentification intégrée (5). La requête est traitée par le serveur principal (6) et les données de boîte aux lettres sont renvoyées au serveur frontal Exchange (7). Les données HTML pour la page OWA sont passées au ISA Server (8), qui les repasse ensuite à l’ordinateur client (9).

Configuration de l’environnement Exchange
L’article de la base de connaissances mentionné plus haut décrit la mise à jour logicielle pour Exchange Server 2003 et inclut des informations qui contribueront à vous guider au travers du processus d’activation de la délégation contrainte Kerberos avec ISA Server 2006 et Exchange Server 2003.
L’action principale de la mise à jour logicielle est l’automatisation du processus de délégation contrainte Kerberos depuis le serveur frontal Exchange vers les serveurs principaux respectifs. La mise à jour n’automatisera pas le processus de délégation contrainte Kerberos depuis ISA Server vers le serveur frontal, car ISA Server ne fait pas la partie de l’organisation Exchange. Cette délégation devra être activée manuellement depuis chaque instance d’ISA Server vers chaque serveur frontal Exchange.
La mise à jour logicielle ajoute un nouvel onglet dans le Gestionnaire du système Exchange (ESM) vous permettant de désigner un serveur Exchange frontal comme KCD-FE (voir la figure 4), qui permet ensuite à ce serveur d’être inscrit dans l’onglet de délégation des serveurs principaux Exchange.
Figure 4 Activation de la délégation contrainte de Kerberos
Figure 4 Activation de la délégation contrainte de Kerberos
La nouvelle interface utilisateur vous permet également de spécifier dans les propriétés du groupe administratif les informations d’authentification à utiliser pour renseigner l’attribut msDS-AllowedToDelegateTo (A2D2), comme indiqué à la figure 5. C’est l’attribut qui est responsable de la délégation contrainte de Kerberos.
Figure 5 Définition du compte qui contrôle la délégation
Figure 5 Définition du compte qui contrôle la délégation
En respectant le principe de moindre privilège, vous pouvez utiliser un compte utilisateur standard et lui accorder la capacité de déléguer des utilisateurs et des ordinateurs à l’aide d’un Objet de stratégie de groupe (GPO). Une fois que le compte s’est vu accorder cette autorisation élevée, il peut être utilisé comme compte de service pour automatiser le processus de délégation contrainte Kerberos pour le groupe administratif respectif.
Veillez à suivre les étapes appropriées pour vous assurer que les utilisateurs malveillants ne pourront pas compromettre le compte de service de la délégation contrainte Kerberos. Même si le compte n’est pas administrateur de domaine, l’accès à celui-ci pourrait permettre des attaques sophistiquées en profitant de la délégation Kerberos. Puisque le compte aura la capacité d’établir de nouvelles associations Kerberos, il devra être utilisé avec précaution. Prenez les précautions nécessaires afin d’assurer la sécurité et l’intégrité de ce compte : un mot de passe long et complexe, un audit accru, des techniques de désactivation de compte et ainsi de suite.
La mise à jour logicielle d’Exchange apporte également une modification très importante à l’interface du Gestionnaire du système Exchange en ce qui concerne l’authentification intégrée. Auparavant, dans Exchange Server 2003, lorsqu’un serveur était désigné comme serveur frontal, l’option d’activation de l’authentification Windows intégrée pour les annuaires virtuels HTTP (sous Serveur virtuel HTTP) était grisée (voir la figure 6).
Figure 6a La mise à jour permet l’authentification intégrée
Figure 6a La mise à jour permet l’authentification intégrée
Figure 6b La mise à jour permet l’authentification intégrée
Figure 6b La mise à jour permet l’authentification intégrée
Ceci est survenu car l’authentification intégrée n’était pas prise en charge sur les serveurs frontaux Exchange en raison de problèmes techniques tels que le fait que les serveurs proxy interrompaient les sessions NTLM, les utilisateurs employant l’authentification Kerberos nécessitaient une connexion à Active Directory et les utilisateurs d’Internet ne faisaient habituellement pas partie du domaine. La mise à jour décrite dans l’article de la base de connaissances mentionné ci-dessus supprime ces restrictions. Avec la mise à jour installée, vous pouvez simplement accéder à l’annuaire virtuel et activer la case à cocher correspondant à l’authentification Windows intégrée comme mécanisme de vérification des informations d’authentification de l’utilisateur. Lorsque celle-ci est activée, un attribut nommé msexchAuthenticationFlags est défini sur l’objet d’annuaire virtuel dans Active Directory (vous pouvez le voir en utilisant le composant logiciel enfichable Adsiedit.msc dans Microsoft Management Console).
Les utilisateurs vérifiant leur messagerie électronique par le biais d’OWA peuvent connaître le nom de leurs serveurs principaux Exchange et se connecter à ceux-ci à l’aide de l’authentification intégrée lorsqu’ils sont sur l’intranet de l’entreprise. La différence dans l’environnement de l’utilisateur avec l’authentification intégrée est que, puisque vous êtes connecté sur le réseau, vous n’êtes pas invité à entrer un nom d’utilisateur et un mot de passe parce qu’Internet Explorer vous authentifiera automatiquement auprès du site Web. C’est idéal pour les utilisateurs qui sont sur le réseau de l’entreprise, mais les utilisateurs externes (et les utilisateurs d’OWA sont de manière plus générale externes) ne sont habituellement pas connectés à un domaine lorsqu’ils proviennent de l’extérieur du réseau à destination d’un serveur frontal Exchange. (Ce processus est expliqué en détail dans l’article de la base de connaissances « Comment IIS authentifie les clients Navigateur ».)
Dans Exchange Server, la mise à jour remplit l’onglet Délégation pour l’utilisation de l’attribut A2D2 plutôt que l’attribut Nom du service principal (SPN) dans Active Directory. En examinant l’objet ordinateur Exchange avec Adsiedit.msc, vous remarquerez deux attributs distincts : L’attribut A2D2, qui est la liste de délégation contrainte Kerberos et l’attribut SPN, qui sert de localisateur Kerberos et de point de spécification de compte. Bien qu’il soit vrai que les deux attributs travaillent conjointement pour que la délégation contrainte Kerberos fonctionne, vous devez seulement modifier l’attribut A2D2 par le biais de l’interface graphique.
Windows peut utiliser l’alias SPN HÔTE intégré comme alias pour la localisation d’autres services. Ceci signifie que setspn.exe ne nécessite pas d’être utilisé pour que la délégation contrainte Kerberos fonctionne avec la délégation de serveur frontal vers serveur principal Exchange. (Même si l’utilisation de HTTP/Nomserveur dans la liste d’attributs SPN fonctionne avec cette solution, elle peut être source d’un plus grand nombre d’erreurs pour l’administrateur et n’est pas nécessaire pour que la délégation contrainte Kerberos fonctionne.) La délégation contrainte Kerberos recherche l’attribut A2D2 dans Active Directory. Lorsque cet attribut n’est pas renseigné (ou affecté d’une valeur de SPN incorrecte), la délégation contrainte Kerberos ne fonctionne pas entre les serveurs respectifs. Sur un cluster Exchange, cependant, l’attribut A2D2 du serveur frontal nécessite uniquement de pointer sur le compte d’ordinateur de nœud de cluster pour fonctionner convenablement.
Comme indiqué précédemment, un domaine Windows Server 2003 contenant des serveurs Exchange 2003 doit être en mode fonctionnel natif Windows Server 2003. La délégation contrainte Kerberos nécessite ce niveau de fonctionnalité de domaine pour pouvoir être utilisée. Si votre domaine est toujours en mode mixte et que vous installez la mise à jour logicielle décrite précédemment, il semblera fonctionner, mais les inscriptions SPN échoueront. La délégation contrainte Kerberos est également une fonction de domaine et non de niveau forêt. Ceci signifie que pour Exchange Server 2003, ISA Server et les serveurs frontaux et principaux Exchange doivent être membres du même domaine (bien que les utilisateurs de domaines différents puissent toujours s’authentifier avec la délégation contrainte Kerberos). Une instance ISA Server qui n’est pas membre d’un domaine ou qui est membre d’un domaine différent ne fonctionnera pas dans le cadre de cette solution.

Configuration du site OWA
Le programme d’administration IIS ne doit pas être utilisé pour les modifications d’authentification avec OWA, quelles qu’elles soient. Bien qu’OWA s’exécute sous IIS et réponde aux modifications de la métabase comme tout autre site Web, Exchange apporte un brin de complexité au processus DS2MB (Directory Services to Metabase). Le processus DS2MB répliquera les modifications d’Active Directory à la métabase IIS dans un processus unilatéral qui écrasera toute modification apportée directement à IIS. L’impact de ce processus est que si un administrateur accède directement à la métabase IIS pour y effectuer une modification (telle que la définition de l’authentification intégrée), la solution semblera fonctionner, jusqu’au cycle de réplication DS2MB suivant.
L’option d’activation de l’Authentification Windows intégrée pour les répertoires virtuels HTTP a été mise en place dans ESM car ESM effectue ses modifications directement dans Active Directory, ce qui provoque ensuite la réplication des modifications dans la métabase IIS. Gardez à l’esprit que bien que l’arrêt du service Surveillance système arrête également le processus DS2MB (ce qui vous permet d’apporter des modifications à la métabase IIS et de faire en sorte que celles-ci ne soient pas écrasées), cette solution n’est pas recommandée. Au démarrage suivant du service Surveillance système, celui-ci recherchera les modifications provenant d’Active Directory et la solution sera ensuite automatiquement désactivée.
L’onglet Délégation contient les options Utiliser uniquement Kerberos et Utiliser tout protocole d’authentification. La logique évidente serait de sélectionner Utiliser uniquement Kerberos puisque la solution que nous décrivons utilise la délégation contrainte Kerberos, mais nous avons ici affaire à l’une de ces situations courantes en informatique pour laquelle la logique habituelle ne s’applique pas. Sélectionnez donc plutôt l’option Utiliser tout protocole d’authentification (comme illustré à la figure 7) car la requête ne provient pas d’une requête Kerberos. Elle provient plutôt d’une requête HTTP avec un certificat correspondant mappé à un compte d’Active Directory.
Figure 7 Correction des paramètres d’authentification pour les cartes à puce
Figure 7 Correction des paramètres d’authentification pour les cartes à puce
Dans ce cas, ISA Server demande le certificat utilisateur PKI sur SSL. La requête entrante n’est pas un ticket Kerberos, et une transition doit survenir pour que la délégation contrainte Kerberos fonctionne convenablement. Par conséquent, en spécifiant Utiliser uniquement Kerberos, la chaîne de communication au ISA Server est interrompue. Remarquez cependant que l’option Utiliser uniquement Kerberos fonctionnera avec la délégation de serveur frontal vers serveur principal Exchange puisque le serveur frontal recevra uniquement les tickets Kerberos d’ISA Server.
Les répertoires virtuels \Exchange et \Public sont les seuls emplacements qui doivent contenir des informations privées sur l’utilisateur et de dossier public. La configuration SSL dans Exchange n’est pas une nouveauté de la délégation contrainte ou de l’authentification avec deux facteurs, mais un portage de l’activation standard de SSL pour OWA avec les informations d’authentification de base. Vous devez suivre les méthodes décrites pour activer SSL avec OWA, car forcer SSL de manière inadéquate peut empêcher le fonctionnement d’OWA et provoquer également des problèmes avec le Gestionnaire du système Exchange.

Détails de configuration supplémentaires
Pour la mise en œuvre de cette solution, il est beaucoup plus facile de déployer au préalable ISA Server et Exchange de manière standard. Ne plongez pas dans la solution complète de délégation contrainte Kerberos avec tous les paramètres configurés (surtout si ISA Server ne figurait pas précédemment dans votre déploiement). Ceci peut compliquer le processus de dépannage en cas d’échec d’un composant ou d’une étape du processus. Il est beaucoup plus facile de déployer ISA Server et Exchange de manière standard (avec nom d’utilisateur et mot de passe, mais sans l’authentification basée sur les formulaires), de s’assurer que l’installation fonctionne et d’effectuer ensuite la transition vers la délégation contrainte Kerberos et l’authentification de certificat.
Généralement, l’authentification basée sur les formulaires ne peut pas être utilisée avec OWA en conjonction avec les cartes à puce. L’authentification basée sur les formulaires indique qu’un utilisateur dispose d’un nom d’utilisateur et d’un mot de passe à soumettre par le bais du formulaire Outlook standard. Cependant, avec l’authentification par carte à puce à deux facteurs, l’utilisateur disposera uniquement d’une carte à puce et non d’un mot de passe. Par conséquent, l’authentification basée sur les formulaires n’aura pas de possibilité d’accepter ou de soumettre uniquement le certificat pour authentification. L’utilisation de l’authentification basée sur les formulaires à un emplacement quelconque de la chaîne (par exemple, sur un serveur frontal derrière ISA Server) provoquera l’échec de la configuration d’OWA avec carte à puce. Si vous activez l’authentification basée sur les formulaires, le répertoire virtuel Exchange sera défini de force pour l’authentification de base et, par conséquent, la métabase IIS utilisera également l’authentification de base.
Si vous disposez d’un mélange d’utilisateurs possédant mots de passe/noms d’utilisateur et cartes à puce, vous pouvez activer le basculement d’authentification sur le port d’écoute Web ISA et, lorsqu’un utilisateur appuiera sur la touche Échap après avoir été invité à entrer ses informations d’authentification à base de certificat, il sera invité à entrer ses informations d’authentification standard (nom d’utilisateur et mot de passe) même si authentification Intégrée est activée derrière ISA Server sur le serveur Exchange. En outre, ISA Server peut affecter la session SSL d’un délai d’attente, pour un fonctionnement similaire à celui de l’authentification basée sur les formulaires.

Conclusion
La prise en charge des cartes à puce pour l’authentification auprès d’OWA est un ajout opportun à Exchange Server 2003 et Exchange Server 2007. Avec la capacité de se connecter à OWA en utilisant un certificat, un utilisateur n’a plus besoin de se soucier de se rappeler de mots de passe longs et complexes, et les administrateurs ont maintenant un outil efficace contre les enregistreurs de frappe et autres formes de logiciels malveillants qui peuvent renifler les informations d’authentification de l’utilisateur d’un système infecté. Reportez-vous à la barre latérale « Ressources » pour plus d’informations.
La configuration correcte d’ISA Server pour l’authentification à deux facteurs avec cartes à puce améliore encore davantage la sécurité globale en effectuant un filtrage au niveau de l’application sur une application OWA publiée. En outre, ISA Server 2006 dispose d’une prise en charge intégrée pour Exchange Server 2003 et Exchange Server 2007 par le biais d’Assistants de publication simples, et donc ISA Server demeure un investissement solide pour les organisations effectuant la transition vers Exchange Server 2007.
Ressources
  • Comment partager les fichiers supprimés par la fonctionnalité de filtrage "Safe HTML" dans Outlook Web Access for Exchange Server 2003
  • Dépannage de la délégation Kerberos
  • Service de mise à jour de métabase
  • Authentification dans ISA Server 2006
  • Transition vers le protocole Kerberos et la délégation contrainte
  • Webcast TechNet : Implémentation de l’authentification multifacteur avec cartes à puce

Victor Akinnagbeest ingénieur de terrain principal chez Microsoft dans la région de Washington D.C. Ses activités principales sont la sécurité, l’infrastructure et la messagerie.
Ted Dresselest consultant chez Microsoft dans la région de Washington D.C. Ses activités principales sont la sécurité et l’infrastructure.
Jason Opdycke est ingénieur de terrain principal chez Microsoft et travaille dans la région de Charlotte. Ses activités principales sont la sécurité et l’infrastructure.


 Administration de Windows: Le service d’installation ActiveX dans Windows&#160;Vista
Administration de Windows Rob Campbell and Joel Yoker

Le service d’installation ActiveX dans Windows Vista
Vue d'ensemble:
  • Problèmes courants avec les contrôles ActiveX
  • Installation des contrôles ActiveX
  • Autorisations dangereuses
  • Un processus plus sûr dans Windows Vista

C’est toujours la même histoire. Pour améliorer sensiblement votre sécurité, vous devez renoncer à une certaine liberté ou une certaine flexibilité. Si votre environnement est comme la plupart des organisations, vous souhaitez vivement renforcer le système d’exploitation du bureau dans le but de fournir un environnement informatique plus sécurisé
à vos utilisateurs finaux. Les administrateurs informatiques abordent généralement la tâche de protection de bureau en utilisant une combinaison de paramètres de stratégie de sécurité, les autorisations utilisateur, les listes de contrôle d’accès aux fichiers et aux registres (les ACL) et les restrictions de services système.
Une difficulté courante dans le développement d’un environnement de poste de travail sécurisé est comment adoucir les menaces entourant les contrôles ActiveX® malveillants tout en fournissant toujours un niveau approprié de compatibilité des applications dans votre environnement. Cela a été un problème avec les systèmes d’exploitation de bureau pendant de nombreuses années. Heureusement, le nouveau service d’installation ActiveX (AxIS) dans Windows Vista™ répond aux problèmes spécifiques de la gestion des contrôles ActiveX dans les environnements d’entreprise. AxIS fournit une façon simple et maniable pour les utilisateurs standard, qui ne seraient pas normalement autorisés à installer des contrôles ActiveX, de les installer à partir de sites Web approuvés. Le contrôle de la Stratégie de groupe sur AxIS permet aux administrateurs informatiques de déterminer quels contrôles les utilisateurs peuvent installer, quelles que soient les autorisations qu’ils possèdent.
Dans cet article, nous examinons les défis administratifs entourant les contrôles ActiveX, comment ces problèmes ont été résolus dans les versions précédentes de Windows® et comment AxIS dans Windows Vista fournit une façon unique et efficace de gérer l’installation des contrôles ActiveX.

Qu’est-ce qu’un contrôle ActiveX ?
Un contrôle ActiveX est un morceau de code exécutable (généralement un fichier OCX emballé dans un fichier .cab) installé et invoqué par l’utilisateur via Internet Explorer®. Les développeurs Web créent des contrôles ActiveX pour ajouter des fonctionnalités à leurs applications Web qu’ils ne peuvent pas réaliser facilement avec le HTML standard ou un script simple.
Une fonctionnalité clé des contrôles ActiveX est la simplicité de leur modèle de déploiement « télécharger et exécuter ». Les contrôles ActiveX sont installés et invoqués à l’aide de la balise d’objet HTML, qui possède un attribut appelé CODEBASE qui indique à Internet Explorer (via une adresse URL) où obtenir le contrôle s’il n’est pas déjà installé sur la machine de l’utilisateur. Dans ce cas, Internet Explorer télécharge le package d’installation associé, réalise la vérification de confiance sur l’objet et demande à l’utilisateur l’autorisation d’installation à l’aide de la barre d’information d’Internet Explorer (illustrée à la figure 1). Pendant l’installation, le contrôle est enregistré et invoqué par le rendu de la page. Une fois installé, le contrôle peut être invoqué par tout utilisateur standard. Ce mécanisme simple de distribution et d’exécution est destiné à offrir aux développeurs une manière simple de distribuer leurs composants aux utilisateurs de leur application Web. Le problème avec cette méthode de distribution est que les utilisateurs standard ne peuvent pas installer directement les contrôles ActiveX parce que les privilèges d’administrateur sont nécessaires pour terminer l’installation.
Figure 1 Barre d’information d’installation de contrôle ActiveX
Figure 1 Barre d’information d’installation de contrôle ActiveX
Lorsque les contrôles ActiveX ont été introduits pour la première fois dans Internet Explorer 4.0, Internet est apparu comme un endroit beaucoup plus convivial. Aujourd’hui, le code exécutable distribué sur le Web peut représenter une menace significative, donc Windows autorise seulement les utilisateurs possédant des droits d’administrateur locaux à installer des contrôles ActiveX, et seulement si l’installation est approuvée selon les paramètres de stratégie. Une fois qu’un contrôle ActiveX est installé par un administrateur, tout utilisateur du système peut l’invoquer. Ce comportement est facilité par une série d’ACL de fichiers et de registres dans Windows. Si cela empêche les utilisateurs standard d’installer des contrôles ActiveX, cela ne réduit pas les risques pour les administrateurs locaux et les utilisateurs standard (les autorisations par défaut étant modifiées) qui les installent.
Si la protection par défaut dans Windows (autorisant seulement ceux qui possèdent des privilèges d’administrateur à exécuter l’installation) s’adresse aux contrôles ActiveX au niveau individuel, elle n’explique pas comment gérer ceux-ci à travers une grande organisation. Un problème courant dans les environnements d’entreprise est comment permettre l’utilisation de contrôles ActiveX approuvés par l’organisation informatique en réduisant les menaces potentielles dirigées via des contrôles externes, non approuvés. Au bout du compte, la décision d’installer un contrôle ActiveX particulier, bon ou mauvais, est souvent laissée aux utilisateurs individuels, en fonction de leurs droits. Pour neutraliser les menaces, certaines organisations bloquent tous les contrôles ActiveX, alors que d’autres autorisent l’installation des utilisateurs finaux mais tentent de gérer tout logiciel malveillant installé.
Une autre façon d’empêcher l’installation de mauvais contrôles est d’appliquer les droits restreints de l’utilisateur standard et de demander à l’administrateur informatique de pré-installer tous les contrôles requis sur la plate-forme de bureau. Ceci est efficace si les contrôles ActiveX utilisés sont relativement statiques par nature, s’ils sont modifiés en utilisant un processus de version planifié conjointement avec les mises à jour de bureau, ou si l’organisation utilise un mécanisme de distribution de logiciel tel que Systems Management Server. Cependant, la gestion continue, les besoins toujours changeants des développeurs d’applications internes et les dépendances vis-à-vis des contrôles externes continueront à être un problème avec ces approches.
Lorsque les utilisateurs possèdent des privilèges d’administrateur, le problème est différent : il implique d’empêcher ces utilisateurs d’installer des contrôles non approuvés. Dans ce cas, le droit de l’utilisateur final d'installer des contrôles ActiveX est supposé, puisque l’utilisateur possède des privilèges d’administrateur. (Notez que lorsque les utilisateurs finaux s’exécutent en tant qu’administrateurs locaux, c’est une attitude qui représente un risque élevé pour l’organisation et qui n’est pas recommandée pour la plupart des environnements d’entreprise.)
Une solution consiste à posséder un serveur de téléchargement de composant Internet interne qui héberge les contrôles approuvés. Cette solution nécessite la modification de la chaîne CodeBaseSearchPath dans le registre du client. Normalement, lorsqu’une balise d’objet contenant l’attribut CODEBASE est recherchée dans la page HTML demandée, les clients Windows sont dirigés vers les emplacements spécifiés dans les données CodeBaseSearchPath. Par défaut, cette chaîne de registre contient le mot clé CODEBASE et les URL Internet pour la galerie de contrôles ActiveX. Pour implémenter un Serveur de Téléchargement de Composant Internet, vous devez remplacer les données par défaut dans CodeBaseSearchPath avec l’URL du serveur interne où vous hébergerez des contrôles approuvés par votre organisation. Comme dans l’approche précédente, cette solution nécessite une gestion continue et supporte le coût et la complexité d’héberger un serveur interne pour les contrôles ActiveX.
Il existe d’autres solutions, telles que la modification des URLActions de la zone Internet Explorer, la spécification des contrôles approuvés par l’administrateur via la Stratégie de groupe et le blocage de l’installation de tous les contrôles au périmètre via les règles de pare-feu. Mais, comme vous pouvez le constater, toutes ces approches présentent des problèmes et beaucoup sont finalement abandonnées en raison du manque de flexibilité. Pire, certaines de ces solutions nécessitent encore que l’utilisateur possède des droits administratifs. Finalement, ces modifications tentent de résoudre des parties du problème, par exemple contrôler (ou bloquer) d’où viennent les contrôles ActiveX, d’où ils peuvent être invoqués, etc. Cependant, ces solutions ne résolvent pas le problème fondamental : les utilisateurs sans droits d’administrateur ne peuvent pas installer les contrôles ActiveX.

Comment AxIS peut vous aider ?
AxIS dans Windows Vista permet à l’administrateur d’entreprise de gérer des contrôles ActiveX tout en maintenant une méthode de sécurité renforcée en ayant des utilisateurs qui s’exécutent comme des utilisateurs standard avec des paramètres de système de fichiers par défaut. AxIS fournit les options de Stratégie de groupe pour configurer des sources fiables de contrôles ActiveX et un processus broker pour installer des contrôles à partir de ces sources approuvées au nom des utilisateurs standard. L’avantage principal est que vous pouvez maintenir une méthode de sécurité non administrative sur les postes de travail d’utilisateur avec un contrôle administratif centralisé. AxIS s’appuie sur l’administrateur informatique pour identifier des sources fiables (généralement des URLS Internet ou intranet) de contrôles ActiveX. Lorsqu’une balise d’objet indique à Internet Explorer d’invoquer un contrôle, AxIS procède de la façon suivante :
  1. Il vérifie que le contrôle est installé. Sinon, il doit être installé avant l’utilisation.
  2. Il inspecte le paramètre de stratégie AxIS pour vérifier si le contrôle provient d’une source fiable. La vérification spécifique correspond au nom d’hôte de l’URL spécifiée dans l’attribut CODEBASE de la balise d’objet par rapport à la liste d’emplacements fiables spécifiés dans la stratégie.
  3. Il télécharge et installe le contrôle au nom de l’utilisateur.
Si le nom d’hôte de l’URL de source n’est pas répertorié dans le paramètre de stratégie AxIS, l’invite du contrôle du compte utilisateur normal (UAC) sera invoquée, nécessitant des droits administratifs pour terminer l’installation. De plus, AxIS enregistrera un événement portant l’ID 4097 dans le journal des événements d’applications à partir de la source AxInstallService décrivant la tentative d’installation de contrôle ActiveX, ainsi que le chemin de téléchargement spécifique vers le contrôle. Un exemple de l’événement 4097 est illustré à la figure 2. Les données de cette entrée de journal des événements peuvent être utilisées par l’administrateur d’entreprise pour modifier la stratégie de groupe, permettant d’installer le contrôle par le biais d’AxIS lors des visites suivantes du site Web.
Figure 2 Événement 4097 AxInstallService
Figure 2 Événement 4097 AxInstallService
AxIS est un composant facultatif qui est fourni avec les versions Business, Enterprise et Édition Intégrale de Windows Vista, et qui peut être activé via une option sans assistance ou la boîte de dialogue du panneau de configuration (Programmes | Programmes et fonctionnalités | Activez ou désactivez les fonctionnalités Windows), comme illustré à la figure 3. Une fois activé, AxIS parcourt les étapes présentées ci-dessus chaque fois qu’un contrôle est demandé par Internet Explorer.
Figure 3 Activation d’AxIS dans le panneau de configuration
Figure 3 Activation d’AxIS dans le panneau de configuration
La possibilité de joindre des tâches aux événements dans Windows Vista est un moyen simple pour un administrateur de recevoir une notification du service AxIS, par exemple lorsque l’installation d’un contrôle ActiveX est bloquée. Il est important de noter que le contrôle ActiveX n’est pas toujours censé être installé à partir du même nom d’hôte d’URL auquel l’utilisateur final accède à partir de son site Web. Pour cette raison, les informations fournies par l’événement 4097 AxInstallService (tentative d’installation) peuvent se révéler extrêmement utiles pour identifier l’hôte à partir duquel la tentative d’installation du contrôle est effectuée.
Avec les informations que vous obtenez à partir de l’événement, vous pouvez configurer l’emplacement approuvé dans la stratégie de groupe. Les paramètres AxIS dans la stratégie locale ou la stratégie de groupe se trouvent dans les paramètres de configuration de l’ordinateur (comme illustré à la figure 4). Les sites d’installation approuvés pour le paramètre de stratégie de contrôles ActiveX vous permet de spécifier des URL d’hôte des emplacements approuvés (voir la figure 5). Le paramètre du site approuvé nécessite deux informations, l’emplacement où le contrôle ActiveX peut être installé et le comportement de l’installation.
Figure 4 Paramètres de l’éditeur d’objets de stratégie de groupe
Figure 4 Paramètres de l’éditeur d’objets de stratégie de groupe
Figure 5 Sites d’installation AxIS-approved
Figure 5 Sites d’installation AxIS-approved
D’abord, comme indiqué auparavant, une URL d’hôte est nécessaire pour indiquer l’emplacement approuvé du contrôle. Contrairement aux solutions précédentes, qui nécessitaient le CLSID du contrôle (qui change souvent lorsque les contrôles sont révisés par leurs développeurs), AxIS permet d’installer des contrôles à partir de l’emplacement approuvé, tout en réduisant le fardeau administratif général. La deuxième information est une chaîne de quatre valeurs délimitées par des virgules, chacune dictant le comportement de l’expérience de téléchargement de contrôles ActiveX. Les valeurs spécifient quatre propriétés : TPSSignedControl, SignedControl, UnsignedControl et ServerCertificatePolicy. Les deux premières propriétés (TPSSignedControl et SignedControl) peuvent avoir une valeur parmi trois : 0, 1 ou 2. Ces valeurs sont similaires aux valeurs trouvées dans les paramètres URLAction. La valeur 0 empêche le contrôle de s’installer, avec la valeur 1 l’utilisateur est invité à fournir l’autorisation d’installation et la valeur 2 entraîne l’installation silencieuse de la part de l’utilisateur. Les contrôles non signés ne peuvent pas être installés silencieusement et donc la valeur de UnsignedControl ne peut être que 0 ou 1. Notez que si aucune stratégie n’est spécifiée, les valeurs par défaut 2, 1 et 0 sont utilisées.
La propriété finale spécifie le comportement de l’installation basé sur les paramètres de certificat du contrôle des paramètres signés. Comme la plupart des sites SSL, le certificat doit réussir une série de tests de sécurité pour s’assurer qu’il est valide. Les propriétés de certificat non valides sont parfois la concrétisation de l’implémentation de contrôle ActiveX signé réel. Via sa configuration, AxIS permet aux administrateurs de limiter les informations non valides qui sont parfois présentées par les certificats URL par URL. La propriété finale est représentée comme une combinaison à masque de bits des valeurs illustrées à la figure 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Valeur | Définition
0x00001000 | Ignorer un nom canonique non valide (CN) dans le certificat.
0x00000100 | Ignorer les autorités de certification inconnues.
0x00002000 | Ignorer une date de certificat non valide.
0x00000200 | Ignorer l’utilisation incorrecte du certificat
Le paramètre par défaut est 0, ce qui signifie que toutes les vérifications de sécurité doivent réussir avant qu'AxIS termine l’installation. La combinaison du paramètre d’hôte et de ces quatre valeurs est spécifiée dans le paramètre de stratégie, comme illustré à la figure 7.
Figure 7 URL d’hôte AxIS approuvées
Figure 7 URL d’hôte AxIS approuvées

Conclusion
AxIS vous permet de configurer la stratégie de groupe pour contrôler quels contrôles ActiveX les utilisateurs peuvent installer sans nécessiter de privilèges d’administrateur ou de configurations complexes. Le contrôle à ce niveau pouvait représenter un véritable défi dans les versions précédentes de Windows et des solutions disponibles précédemment ont souvent été fournies avec des restrictions sérieuses ou des frais de gestion augmentés. AxIS offre aux organisations un autre outil pour une approche de moindre privilège des droits d’utilisateur final sur les systèmes de bureau, autorisant la mise en œuvre d’un modèle d’utilisateur standard où les utilisateurs finaux ne nécessitent pas de privilège d’administrateur. Windows Vista replace l’administrateur informatique aux commandes, car il choisit des contrôles ActiveX approuvés dans l’environnement d’entreprise déterminé par l’organisation, pas par l’utilisateur final.

Rob Campbell est spécialiste technique senior dans l’équipe Microsoft Federal. Rob s’emploie à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.
Joel Yoker est consultant senior dans l’équipe Microsoft Federal. Joel s’emploie à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.


 Le mot du r&#233;dacteur en chef: Six degr&#233;s de s&#233;paration
Le mot du rédacteur en chef
Six degrés de séparation
Joshua Trupin

Vous êtes-vous déjà senti un peu déconnecté ? Vous êtes-vous déjà assis seul dans votre bureau, les yeux dans le vide, vous demandant s’il existait une autre vie intelligente quelque part ? S’il y a, en fait, ne serait-ce que quelqu’un quelque part ? Peut-être pas. Surtout si votre boîte de réception est perpétuellement remplie de messages comme l’est la mienne.
Cependant, j’ai récemment éprouvé ces affres et j’ai décidé que je devais être connecté. Je me suis inscrit à un de ces sites de mise en relation de professionnels et j’ai commencé à ajouter des contacts (toutes les personnes avec lesquelles j’ai travaillé, celles dont j’ai lu un article ou entendu parlé lors d’une conférence). En une semaine, j’avais 58 contacts sur ma liste. Génial !
Mais ce n’était que le premier niveau. Au deuxième niveau (les connaissances de connaissances), je suis passé à plus de 3 500 amis. Et étant donné que ces 3 500 contacts avaient eux-mêmes leurs propres contacts, j’avais en très peu de temps, 277 000 contacts du troisième degré. Un calcul rapide dans un tableur Excel : Supposons que chaque personne a en moyenne 50 contacts : je connais alors 34 milliards de personnes en tant que contacts du degré six. Du balai, Kevin Bacon ! Je connais plus de gens qu’il en existe sur la planète Terre. Soudain l’abîme se resserre.
Mais un nouveau problème est apparu. Comment puis-je traiter toutes ces relations ? Je suis ouvert à toutes suggestions. Utilisez-vous à l’heure actuelle un site de mise en relation de professionnels ? Comment faites-vous le tri entre les personnes avec lesquelles vous souhaitez converser et celles à éviter ? Consultez le blog de TechNet Magazine blog et laissez-nous vos réflexions sur ce problème épineux.
Si ce type de site de mise en relation Web 2.0 n’est pas votre truc, ne vous inquiétez pas. Le numéro de ce mois-ci de TechNet Magazine vous aide à améliorer vos communications en utilisant au mieux Exchange Server. Il y a cinq articles vous offrant les informations dont vous avez besoin pour étendre la portée de la messagerie de votre organisation.
L’utilisation de l’authentification de carte à puce avec Outlook Web Access est l’un de nos sujets présentés ce mois-ci. C’est toujours une bonne idée de demander un formulaire d’authentification physique avant d’accorder l’accès aux ressources de votre entreprise. Les cartes à puce permettent cette opération de n’importe quel endroit. Nous examinons également la récupération après incident avec Exchange Server, comment remplacer des dossiers publics avec SharePoint dans Exchange Server 2007, et comment améliorer la sécurité mobile avec Windows Mobile 6. Bien sûr, nous avons Questions et réponses sur la file d'attente Exhange, qui devrait être votre rubrique préférée si vous avez une quelconque relation avec la messagerie. Tiens, encore trois personnes qui viennent d’apparaître sur mon réseau. Je ferais mieux d’aller voir si je dois les saluer ou faire semblant de dormir.
—Joshua Trupin

Remerciements aux experts techniques Microsoft suivants : Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster et Jim Truher.


 Bo&#238;te &#224; outils: Nouveaux produits pour les professionnels de l’informatique
Boîte à outils
Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Surveillance des connexions à distance
RecordTS
www.tsfactory.com
N’avez-vous jamais souhaité garder un œil sur vos sessions Terminal Server ou Bureau à distance ? Vous souhaitez peut-être savoir ce qui se passait avant que votre session Bureau à distance ait semblé bloquer votre site Web. Peut-être existe-t-il un problème avec votre serveur Terminal Server que vous n’arrivez pas à reproduire. Peut-être vous préoccupez-vous de la sécurité de la propriété intellectuelle. Ou peut-être que vous devez faire un compte-rendu ou une présentation rapide de la manière dont vous avez configuré votre serveur SharePoint® dans un environnement de test. Si l’un de ces scénarios vous semble familier, consultez sans hésiter RecordTS de TSFactory (TSFactory a été fondé par Cláudio Rodrigues, Microsoft MVP des services Terminal Server).
RecordTS est disponible dans deux éditions : Terminal Server et Bureau à distance. L’édition appropriée pour vos besoins dépendra des types de connexions que vous voulez surveiller. Comme l’indique le site Web du produit, RecordTS sert de « caméra de surveillance » des sessions Terminal Server ou Bureau à distance. Le logiciel agit fondamentalement comme proxy entre Terminal Services et la session de l’utilisateur final, lui permettant d’enregistrer tout mouvement ou action entrepris au cours d’une session.
L’installation intuitive utilise un Assistant simple dans lequel vous pointez l’application sur le répertoire de données dans lequel vous aimeriez sauvegarder les sessions enregistrées. L’application installe un composant logiciel enfichable MMC (qui vous permet de configurer le service), le service RecordTS et un utilitaire de lecture de session pour regarder les sessions enregistrées. Après avoir ouvert le composant logiciel enfichable MMC, cliquez avec le bouton droit sur le dossier du service pour afficher un écran de propriétés dans lequel vous pouvez configurer des paramètres tels que le port sur lequel vous souhaitez que le service soit exécuté (ce paramètre particulier est utile si vous avez déplacé vos sessions de services Terminal Server vers un port non standard). Sur l’onglet Storage (Stockage), vous pouvez définir le dossier de sauvegarde par défaut (Default Storage Folder) sur un dossier local ou un chemin UNC.
Vous pouvez également configurer la structure de répertoire des sessions enregistrées. Par exemple, vous pourriez utiliser le domaine, l’utilisateur ainsi que la date et l’heure pour organiser les données enregistrées. En outre, et il s’agit là peut-être du paramètre le plus important si vous enregistrez des sessions sur un disque local, vous pouvez indiquer au service ce qu’il doit effectuer si le disque manque d’espace. Vous pouvez choisir de ne pas autoriser de nouvelles connexions et de déconnecter les sessions en cours (un choix réservé à ceux qui se soucient de la sécurité), ou vous pouvez choisir de désactiver l’enregistrement de session (une option souhaitable si vous ne voulez pas affecter la productivité).
Sous l’onglet Security (Sécurité), vous pouvez spécifier si vous voulez signer numériquement toutes les sessions enregistrées en sélectionnant un certificat existant ou en créant un certificat signé automatiquement. Cette opération peut en valoir la peine si vous prévoyez d’utiliser l’outil pour des audits ou pour déterminer les responsabilités. Sur l’onglet Users (Utilisateurs), vous pouvez spécifier les utilisateurs dont les sessions doivent être enregistrées ou non.
En gros, RecordTS peut être un outil appréciable pour la sécurité et l’audit, et ses utilisations peuvent être beaucoup plus vastes, telles que l’enregistrement d’une présentation de procédure. En ce qui me concerne, il constitue un élément pratique de ma boîte à outils.

Prix : RecordTS Remote Desktop Edition disponible à partir de 495$, RecordTS Terminal Services à partir de 995$.

Surveillance d’hôte
Advanced Host Monitor
www.ks-soft.net
Si vous devez un jour assurer le support d’exploitation d’une infrastructure vitale, il existe un remède contre les insomnies dont vous ne pourrez pas vous passer : une bonne surveillance d’hôte fiable. Même si vous disposez d’un ensemble matériel à toute épreuve et d’une pile d’applications fiable et stable sans point de défaillance singulier, il est toujours souhaitable de disposer d’une surveillance d’hôte complète qui vous avertira dès que votre système redondant devra entrer en jeu.
Advanced Host Monitor de KS-Soft se targue de disposer de 58 méthodes de test et de 30 méthodes d’alerte différentes. Vous pouvez vérifier des éléments tels que les informations de processus, les sessions utilisateur, la charge moyenne, la mémoire et ainsi de suite. L’application comporte des tests spécifiques à Windows®, Linux/UNIX et des vérifications indépendantes de la plate-forme. Contrairement aux tests Windows, les tests Linux/UNIX nécessitent l’installation d’un agent de surveillance à distance sur le client.
Il existe également un test de surveillance de Windows Management Instrumentation (WMI). Vous pouvez rechercher la requête appropriée avec l’explorateur intégré WMI Explorer, qui vous permet de naviguer facilement jusqu’à l’élément adéquat et de le choisir, de même qu’exécuter la requête qui vérifiera qu’il obtiendra les données dont vous avez besoin.
Advanced Host Monitor dispose également de plusieurs tests liés aux bases de données tels que les tests de requêtes ODBC, qui vérifient la disponibilité d’une source de données ODBC, exécutent une requête et comparent le résultat à une valeur connue. Vous pouvez également vérifier la capacité de l’hôte à accepter des sessions entrantes pour les serveurs de base de données SQL Server™, MySQL, Oracle, Postgres, Sybase et Interbase.
Plusieurs tests liés aux disques et aux fichiers sont disponibles pour vous aider à garde un œil sur l’espace libre, les quotas, la disponibilité des dossiers ou des fichiers ainsi que la disponibilité des partages UNC. En outre, vous disposerez des tests réseau standard : les vérifications générales TCP/UDP, les tests de messagerie électronique (pour SMTP, POP3 et IMAP), les vérifications de relais de messagerie électronique, les tests de contenu et de chronométrage HTTP, etc. Vous pouvez créer des interdépendances de tests de surveillance pour enchaîner vos tests de vérification, ce qui est une option utile. Les tests peuvent également être programmés selon des plannings qualifiés de régulier et irrégulier, vous offrant ainsi un niveau de granularité important pour vos modèles de tests.
Certaines méthodes d’alerte incluent l’envoi de messages à SMS, ICQ, la messagerie électronique, un journal d’événements ou une fenêtre contextuelle. Elles peuvent également déclencher d’autres événements, tels que le démarrage ou l’arrêt de services, le redémarrage de l’ordinateur ou l’exécution d’un programme externe.
Avec les versions Professional et Enterprise d’Advanced Host Monitor, vous pourrez profiter de KS-Soft IP-tools, un ensemble de 19 utilitaires réseau TCP/IP incluant des analyseurs de port/protocole et un observateur d’interruption SNMP qui vous permet de recevoir et de traiter les messages d’interruption de SNMP. De plus, les deux versions disposent d’un composant d’analyse de journal et de création de rapports qui vous permet de faire le suivi des tendances des données d’historique d’analyse pour vos rapports d’analyse de la disponibilité et des performances.
L’interface offre quant à elle un moyen pratique d’obtenir simultanément un aperçu rapide de plusieurs tests. Avec elle, vous pourrez facilement rechercher les problèmes sur vos hôtes surveillés.
Prix : 599$ pour l’édition Enterprise. 275$ pour l’édition Professional.

Disk Cleanup
WinDirStat
www.windirstat.info
À l’image de votre maison ou de votre appartement, les emplacements de stockage de fichiers ont tendance à être progressivement encombrés par du matériel qui avait une utilité à un certain moment, mais qui ne fait à présent qu’occuper un espace précieux. Un petit nettoyage de printemps peut faire beaucoup de bien, mais, contrairement à votre maison, une arborescence de répertoires ne vous donne pas d’indices visuels évidents pour déterminer où commencer à nettoyer le désordre. Heureusement, il existe un excellent outil de visualisation qui peut vous aider à voir les fichiers qui prennent de l’espace dans votre environnement.
Le programme WinDirStat (sous licence GPL) est un outil Windows qui s’inspire de la commande kdirstat de Linux KDE et affiche les fichiers du lecteur sélectionné sous la forme d’un ensemble de carrés de couleurs différentes. La taille des carrés représente la taille des fichiers, ce qui vous permet de repérer facilement les mastodontes que sont les fichiers ISO ou zip inutiles.
Après avoir sélectionné votre lecteur local (ou un ensemble de lecteurs locaux), le programme analyse l’arborescence et crée un mappage en mémoire des fichiers. Il affiche ensuite la visualisation dans le volet inférieur de l’interface utilisateur graphique. Cliquez sur un carré coloré du volet inférieur pour faire naviguer le volet supérieur, semblable à l’Explorateur Windows, jusqu’à l’emplacement du fichier. Ce volet supérieur vous donne des statistiques utiles telles que la taille d’un fichier, la date de la dernière modification de ce fichier et d’autres attributs. De plus, vous pouvez voir quel pourcentage de la sous-arborescence est utilisé par ce fichier.
Une touche très réussie : les couleurs sont spécifiques aux types de fichiers et le clic sur un type de fichier détecté dans le volet supérieur droit mettra en évidence tous les fichiers de ce type dans le volet inférieur. C’est pratique, lorsque vous avez par exemple besoin d’identifier tous les MP3 masqués dont vos utilisateurs disposent sur le serveur de fichiers. Vous pouvez également voir le pourcentage d’octets que ces fichiers occupent sur la partition.
Prix : Téléchargement gratuit.

Critique
Enemy at the Water Cooler
syngress.oreilly.com
Presque toutes les entreprises ont besoin d’être connectées à Internet et la plupart sont conscientes des dangers présentés par les tentatives presque constantes, depuis l’extérieur, de compromettre les points de connexion qui séparent l’"extérieur" de l’ "intérieur" de leur infrastructure d’information. Cependant, de nombreuses entreprises négligent une menace potentiellement plus dévastatrice qui existe au sein d’une organisation. Le pouvoir de ce qu’on appelle les menaces d’initiés est bien illustré dans Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures de Brian Contos (Syngress, 2006).
Contos propose des récits d’attaques réelles passées et l’impact qu’elles ont eu sur les entreprises impliquées. Il estime que la sécurité est un processus continu qui consiste en une "fusion de personnes, de processus et de technologies". Avec ce livre, il essaie d’illustrer le pouvoir potentiel des solutions logicielles d’ESM (Enterprise Security Management, Gestion de la sécurité d’Entreprise) pour atténuer les risques liés aux menaces d’initiés.
En tant que directeur en chef de la sécurité d’ArcSight, Contos s’appuie de manière conséquente sur la présentation de la propre solution ESM de son entreprise, mais cela ne nuit pas à la valeur générale. Le livre manque de détails techniques poussés, mais vous obtiendrez une bonne idée des emplacements auxquels améliorer le processus de sécurité de votre propre organisation en voyant où les autres organisations ont échoué et en comprenant ce qu’une solution ESM mise en œuvre avec efficacité peut faire pour réduire l’exposition aux attaques d’initiés.
Dans le chapitre "Cyber Crime and Cyber Criminals 101", Contos offre un aperçu général de différents types d’attaquants à connaître, ainsi que leurs motivations. Vous obtiendrez également un bref synopsis de certaines de leurs techniques, telles que les saturations de mémoire tampon, le « code-packing » et les menaces Warhol.
Le chapitre suivant est consacré aux détails de menaces d’initiés, y compris les méthodes par lesquelles un initié peut endommager une entreprise, le concept de gestion des risques et les façons de répondre aux menaces d’un point de vue technique. Le point de vue technique donne un bref aperçu général du moindre privilège, de l’authentification forte, du contrôle d’accès et de la détection et la gestion d’incident. Ceci ouvre la voie à une discussion sur les solutions logicielles d’ESM. Encore une fois, le livre a tendance à aborder uniquement le produit ArcSight, mais le détail des fonctionnalités peut s’appliquer à tout système.
Le livre fournit plusieurs scénarios de cas d’une gamme représentative d’industries et d’environnements, en détaillant les différents types de menaces d’initiés et la manière dont elles ont été détectées (et parfois atténuées). Ces études de cas peuvent vous éclairer dans certaines de vos propres pratiques d’entreprise et peut-être offrir des solutions pour la réduction du risque d’attaques d’initiés dans votre environnement.
Prix : $49.95.

Écrire à Boîte à outils
Si vous souhaitez voir votre outil ou utilitaire préféré figurer dans l’un de nos articles, veuillez écrire à l’auteur à l’adresse tntools@microsoft.com.

Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste. Il est constamment à la recherche de méthodes et d’outils innovants destinés à faciliter les opérations et le développement pour les professionnels de l’informatique.


 Forum aux questions sur SQL: Au cœur de la mise en clusters, des mises en suspens myst&#233;rieuses, du compte administrateur syst&#232;me et plus encore
Forum aux questions sur SQL
Au cœur de la mise en clusters, des mises en suspens mystérieuses, du compte administrateur système et plus encore
Par Nancy Michell

Q : J’ai besoin de mieux comprendre le fonctionnement des clusters. Notre environnement comprendra Windows Server® 2003 64 bits exécutant SQL Server™ 2005, un groupe de serveurs SSRS (SQL Server Reporting Services) autrement dit un déploiement horizontal de serveurs de rapports, un serveur de catalogue TempDB SSRS et SQL Server qui extrait des données d’une base de données tierce à l’aide d’un serveur lié et enregistre les données pour SSRS.
Nous souhaitons un cluster à 3 nœuds actif/actif/passif. Le nœud Node1 serait actif et stockerait les données extraites de la base de données tierce. Le nœud Node2 serait actif et stockerait le catalogue SSRS. Le nœud Node3 serait passif et servirait de basculement pour l’un des deux autres nœuds. Avez-vous des conseils ?

R : Malheureusement, les termes actif/actif et actif/passif en référence aux clusters SQL Server sont trompeurs pour beaucoup de personnes. Elles pensent que les clusters SQL prendront en charge l’évolution d’une base de données ou de l’instance SQL sur plusieurs serveurs. Ce n’est pas le cas. Sur SQL Server, il n’y a pas de bases de données ou d’instances actives/actives. Une « instance » est une installation de SQL Server avec des bases de données correspondantes. Notre mise en clusters par instance de SQL Server est toujours active (1) à passive (n) ; notez que la valeur de n est comprise entre 1 et 7 en fonction de votre version de SQL Server. C’est pour cette raison que l’on parle de clusters de basculement.
Une fois cela compris, les gens peuvent commencer à envisager l’installation de plusieurs instances de clusters de basculement sur une série de nœuds. Ainsi, trois serveurs physiques utilisant tous des disques partagés pourraient avoir une instance active par défaut sur le nœud 1 et une seconde instance active par défaut sur le nœud 2 et tous deux peuvent basculer sur le nœud 3. Les instances sont complètement distinctes ; elles ne partagent pas de données et ne sont pas actives/actives. Elles sont toutes les deux actives/passives et ont la même instance de basculement. Si les deux instances basculent sur le nœud 3, le problème sera de savoir si ce nœud sera à la hauteur. Le basculement a été conçu pour s’appuyer sur une puissance de traitement égale pour le basculement. Si la charge maximale requière deux nœuds pour un traitement en fonctionnement normal, il est peu probable que le nœud 3 supporte la charge maximale attribuée normalement à deux nœuds.
Ceci dit, étant donné le coût relatif du matériel capable d’exécuter un cluster, nous comprenons que les gens se disent que la probabilité que les deux nœuds principaux tombent en panne simultanément et forcent la charge entière à passer à un nœud est faible. Forts de cela, ils peuvent choisir de courir le risque plutôt que d’acheter une capacité de basculement à 100 %.
Heureusement, voici la bonne nouvelle : SQL Server 2005 offre beaucoup plus d’options pour la haute disponibilité, notamment des alternatives qui peuvent basculer plus vite qu’un cluster et peuvent même signifier une duplication des données (la mise en clusters s’appuie sur un seul réseau SAN). Les options incluent la mise en miroir, la réplication égal à égal et plus encore. Avec ces nouvelles alternatives, nous avons beaucoup plus d’options pour répondre à toutes sortes de besoins, y compris ceux combinant un certains nombres de fonctionnalités haute disponibilité.
L’Assistant Microsoft® Cluster Configuration Validation (ClusPrep), désormais disponible au téléchargement, remplace ce qui était le test de la Liste de certification matérielle (HCL), qui pouvait prendre des mois pour valider une configuration complète pour l’estimer comme « pouvant être prise en charge » en présence de clusters. Ceci met l’outil de validation de matériel entre les mains de l’administrateur de base de données et permet d’économiser (du temps et de l’argent) pour mettre en place le matériel certifié. Il peut même être possible de valider et déployer un matériel hétérogène dans un groupe de nœuds de cluster.

Q : Une procédure de suppression sur l’un de mes ordinateurs a l’air de se mettre en suspens au bout de 12 heures. Elle n’est pas bloquée. En observant le plan de requête le plus lent, on constate qu’un déclencheur s’exécute pendant 87 327 secondes, ce qui laisse supposer que la procédure est mise en suspens dans ce déclencheur. Comment savoir exactement quelle instruction est mise en suspens ?

R : Il est tout à fait possible qu’une boucle au sein du déclencheur ne se ferme pas pour un tas de raisons. Si vous êtes mis en suspens pendant un bon moment et que vous souhaitez savoir quelle instruction s’exécute, exécutez le code de la figure 1. Il vous dira quelle instruction est en cours d’exécution et il devrait s’agir de celle qui entraîne la mise en suspens de votre ordinateur.
Figure 1 Rechercher l’instruction en cours d’exécution (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

Q : J’ai besoin de prendre en charge la réplication transactionnelle par le biais d’un pare-feu. L’éditeur et le distributeur sont à l’extérieur du pare-feu et l’abonné se trouve à l’intérieur. L’écoute de l’abonné est définie sur 1433 et voici les noms de mes ordinateurs : Éditeur : PUBMACHINE, Distributeur : DISTMACHINE, Abonné : SUBMACHINE. Quels ports dois-je ouvrir pour faire en sorte que la capture instantanée initiale et l’émission de données de la publication réussissent ?

R : Si vous utilisez un abonnement par émission de données, l’ouverture du port SQL Server (1433 dans votre cas) devrait suffire comme l’agent de distribution s’exécutera sur l’ordinateur du distributeur (à l’extérieur du pare-feu) et aura probablement un accès local aux fichiers de captures instantanées générées par l’agent de capture instantanée. En revanche, si vous utilisez un abonnement par extraction de données, l’agent de distribution exécuté sur l’ordinateur de l’abonné devra trouver un moyen de franchir le pare-feu pour accéder aux fichiers d’instantanés. Voici les options que vous pouvez envisager.
Si l’on présume que les fichiers de captures instantanées sont déjà accessibles depuis un partage de fichiers à l’extérieur du pare-feu, vous pouvez ouvrir le(s) port(s) de partage de fichiers Windows® via le pare-feu pour que l’agent de distribution s’exécutant à l’intérieur du pare-feu puisse accéder aux fichiers d’instantanés situés à l’extérieur (méfiez-vous toutefois des implications de sécurité que ceci peut avoir pour d’autres parties de votre infrastructure). Notez que si vous avez configuré un chemin local comme emplacement par défaut des captures instantanées (SSMS par défaut), vous devrez peut-être utiliser l’option /AltSnapshotFolder de l’agent de distribution pour remplacer l’emplacement de collecte des fichiers de captures instantanées.
Vous pouvez également configurer la réplication pour utiliser FTP pour le transfert de fichiers de captures instantanées (vous devrez dans ce cas ouvrir le port 21).

Q : J’aimerais savoir s’il y a des inconvénients à désactiver le compte administrateur système dans SQL Server 2005 et si la désactivation de l’administrateur système ajoute une véritable valeur de sécurité. Un livre blanc a-t-il été consacré à ce sujet ?

R : Sur une nouvelle installation de SQL Server 2005, lorsque le mode mixte n’est pas activé, le compte administrateur système est désactivé par défaut et un mot de passe aléatoire est généré pour lui. Vous pouvez également le désactiver vous-même. Aucun livre blanc n’est paru à ce sujet, mais la désactivation et les affectations de nouveaux noms aux ouvertures de sessions sont abordées dans un document recensant les méthodes recommandées.
Si vous voulez vous protéger contre les tentatives de violation du compte administrateur système, vous pouvez aussi le renommer. N’oubliez pas cependant que, si vous activez un compte désactivé, il est recommandé de définir un nouveau mot de passe pour ce compte.
Pour répondre à votre question en ce qui concerne la sécurité, souvenez-vous que la sécurité complémentaire qu’apporte la désactivation du compte provient du fait qu’il serait vain d’essayer de deviner le mot de passe lorsque le compte est désactivé. Quel que soit le délai dont dispose un pirate ou un virus informatique, une attaque en force contre un compte verrouillé ne réussira pas. Le fait de donner un nouveau nom ou de désactiver l’administrateur système endommagera des applications dont la connectivité dépend de l’utilisation du compte administrateur système. Il est toujours essentiel de trouver et réparer ou éliminer ces applications. Comme mentionné précédemment, le compte ne peut pas être utilisé pour se connecter à la base de données tant qu’il n’a pas été réactivé. De plus, comme le processus d’authentification échoue plus tôt, une tentative échouée aura moins de conséquences sur le système attaqué.

Q : L’une des mes plus grandes bases de données OLTP (traitement des transactions en ligne) a un fichier journal qui fait deux fois la taille du fichier de données. J’ai essayé d’utiliser les commandes suivantes pour réduire la taille du fichier journal, mais il doit encore être réduit :
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R : Vous devez modifier votre base de données de sauvegarde en une instruction de journal de sauvegarde. Vous pouvez aussi placer votre base de données dans le mode de récupération simple et émettre l’instruction shrinkfile. Une fois le journal réduit, configurez la base de données sur son modèle de récupération précédent et sauvegardez-la. S’il ne réduit toujours pas, assurez-vous qu’aucune transaction n’est ouverte (utilisez dbcc opentran). L’article de la base de connaissances suivant fournit plus d’informations : support.microsoft.com/kb/907511.

Q : Si le basculement survient pendant une tâche de l’agent SQL Server planifiée, qu’arrive-t-il à cette tâche après le basculement ? Dois-je la relancer manuellement ?

R : Oui, il vous faudra la relancer manuellement si vous n’avez pas un autre processus en place. Si vous ne voulez pas avoir à relancer des tâches manuellement, vous pourriez écrire un script qui mette à jour une table une fois la tâche achevée. Si la valeur est égale à 1, la tâche a été exécutée ; toute autre valeur indique que la tâche n’a pas été exécutée et une deuxième tâche sera exécutée ultérieurement et lancera la commande de démarrage. Donc, si la tâche doit être réexécutée dans l’éventualité d’un basculement survenant pendant son exécution, en écrivant un script, vous pouvez atténuer une part de l’inquiétude concernant ces tâches nocturnes essentielles qui doivent absolument être exécutées avant la prochaine journée de travail.
Conseil : Mise à niveau et DBCC UPDATEUSAGE
Réalisez-vous une mise à niveau à partir de SQL Server 2000 vers SQL Server 2005 ?
Si c’est le cas, veillez à exécuter DBCC UPDATEUSAGE juste après la mise à niveau de vos bases de données.
DBCC UPDATEUSAGE signale et corrige les pages et les inexactitudes dans les nombres de lignes dans les affichages du catalogue. Ces inexactitudes doivent être corrigées parce qu’elles peuvent entraîner des erreurs dans les rapports d’utilisation de l’espace renvoyés par la procédure sp_spaceused stockée sur le système. Dans SQL Server 2005, ces valeurs sont toujours gérées correctement, donc ces bases de données ne doivent jamais faire l’objet d’erreurs de nombres. Cependant, les bases de données mises à niveau vers SQL Server 2005 peuvent contenir des nombres non valides, c’est pourquoi il est nécessaire d’exécuter DBCC UPDATEUSAGE après la mise à niveau.
Voici comment fonctionne la commande DBCC UPDATEUSAGE. Elle corrige les lignes, les pages utilisées, les pages réservées, les pages feuilles et les nombres de pages de données pour chaque partition dans une table ou un index. S’il n’y a pas d’inexactitudes dans les tables système, DBCC UPDATEUSAGE ne renvoie aucune donnée. Si des inexactitudes sont trouvées et corrigées et que vous n’avez pas utilisé WITH NO_INFOMSGS, DBCC UPDATEUSAGE renvoie les lignes et les colonnes mises à jour dans les tables système.
La commande DBCC UPDATEUSAGE peut également être utilisée pour synchroniser des compteurs d’utilisation de l’espace. Étant donné que l’exécution de la commande DBCC UPDATEUSAGE peut prendre un certain temps sur de grandes tables ou bases de données, il est recommandé de l’utiliser uniquement lorsque vous suspectez que des valeurs inexactes sont renvoyées par sp_spaceused. Notez que sp_spaceused accepte un paramètre facultatif pour exécuter DBCC UPDATEUSAGE avant de renvoyer des informations sur l’espace pour la table ou l’index.
DBCC CHECKDB a été amélioré dans SQL Server 2005 pour détecter le moment où le nombre de pages ou de lignes devient négatif. Lorsqu’une valeur négative est détectée, DBCC CHECKDB émettra un avertissement et une recommandation d’exécution de DBCC UPDATEUSAGE pour résoudre le problème. Bien qu’il puisse sembler que la mise à niveau de la base de données vers SQL Server 2005 soit à l’origine de ce problème, soyez assuré que les nombres non valides existaient avant la procédure de mise à niveau.
À titre d’exemple, voici comment mettre à jour les nombres de pages ou de lignes ou les deux pour tous les objets de la base de données actuelle. La commande suivante spécifie 0 pour le nom de la base de données et DBCC UPDATEUSAGE renvoie des informations mises à jour pour la base de données actuelle :
DBCC UPDATEUSAGE (0);
GO
Pour mettre à jour les nombres de pages ou de lignes ou les deux pour, disons, AdventureWorks, et également pour éliminer des messages d’information, vous exécuteriez une commande similaire à la suivante, qui spécifie AdventureWorks comme nom de la base de données et élimine ensuite tous les messages d’information :
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Pour plus d’informations, recherchez DBCC UpdateUsage dans la documentation en ligne de SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Coup de projecteur sur les utilitaires: SMSMap
Coup de projecteur sur les utilitaires
SMSMap
Jeff Tondt
Télécharger le code de cet article: UtilitySpotlight2007_07.exe (2477KB)

Un dessin vaut mille mots. Ce proverbe se réfère à l’idée que des explications complexes peuvent être résumées en une seule image, ou qu’une image peut avoir une plus grande influence qu’une quantité substantielle de texte. Il caractérise également avec justesse les objectifs de visualisation, où de grandes quantités de données doivent être rapidement absorbées.
Pour un novice de System Management Server (SMS) comme moi, le fait de visualiser la totalité de la hiérarchie SMS en une seule image me permet de comprendre l’architecture de mon infrastructure. Vous pourriez utiliser une telle image, par exemple, pour montrer l’avant et l’après d’un plan de migration SMS à votre direction. Dans certains cas de dépannage, un tel diagramme pourrait s’avérer très utile lors de la recherche d’une solution ou au moins pour obtenir de l’aide d’autres personnes. Et, bien sûr, en tant qu’un administrateur responsable de SMS, vous devrez décrire la hiérarchie de votre système pour toutes sortes de raisons.

Vous voyez le tableau ?
Ce n’est pas que vous ne puissiez pas dessiner un tel diagramme vous-même. Vous pouvez certainement remonter vos manches, dessiner manuellement la hiérarchie du SMS et décrire les paramètres du site manuellement. Si Microsoft® Operations Manager (MOM) surveille les serveurs de votre SMS, vous pouvez obtenir le diagramme de votre hiérarchie, bien que je dois admettre que MOM n’est pas l’idéal pour être traduit en images et il ne décrit certainement pas les paramètres de votre site. Il existe peut-être d’autres méthodes ou des outils pratiques, mais je n’ai jamais rencontré quoi que ce soit qui crée de manière adéquate de belles images et permette de décrire les paramètres de site (en tout cas, pas à mon goût).
J’ai donc décidé de m’y atteler. Voilà comment est né SMSMap 1.0. SMSMap est une application Visual Basic® .NET qui utilise les bibliothèques gérées par SMS dans le kit de développement SMS et automatise Microsoft Visio® à l’aide de COM. L’utilitaire interroge un serveur de site SMS ciblé puis crée un diagramme Visio visuellement attrayant et exporte les paramètres de site dans un fichier XML. XML était sélectionné étant donné qu’il est la manière la plus compatible de décrire les paramètres de site. J’ai choisi d’afficher les rôles de SMS, et pas simplement les serveurs physiques apparentés aux autres serveurs de SMS. Ceci permet de remanier le diagramme à l’aide des couches Visio pour observer la hiérarchie de SMS à partir de plusieurs points de vue.
Figure 1 Format radial
Figure 1 Format radial
Actuellement, le programme vous permet de sélectionner six formats différents pour le diagramme Visio. Par exemple, la figure 1 affiche une hiérarchie de SMS très simple à l’aide du format radial, tandis que la figure 2 affiche la même hiérarchie à l’aide du format d’ordinogramme. L’utilitaire fonctionne correctement sur des hiérarchies beaucoup plus grandes mais je souhaite faire simple ici.
Figure 2 Format d’ordinogramme
Figure 2 Format d’ordinogramme
À un moment donné, SMSMap évoluera probablement pour décrire tous les paramètres de site. Actuellement, il décrit uniquement les rôles de site SMS et toutes les limites. Sans beaucoup d’effort, de nombreux paramètres de site pourraient être exportés dans le fichier XML.

Utilisation de SMSMap
Le code source et les fichiers d’installation pour SMSMap sont disponibles sur le de TechNet Magazine à l’adresse http://www.technetmagazine.com/code07.aspx. Pour l’installer, il vous suffit d’exécuter SMSMapSetup.msi, qui vous guide lors de l’installation. N’oubliez pas que SMSMap utilise Visio. Il doit donc déjà être installé. Après l’installation, exécutez C:\Program Files\Microsoft\smsmap\smsmap.exe (sauf si vous l’avez installé à un emplacement différent de l’emplacement par défaut).
Vous pouvez exécuter SMSMap depuis n’importe quelle machine. Vous n’avez pas besoin de l’exécuter à partir du serveur de site (et il est peu probable que de nombreux serveurs de site SMS aient Visio déjà installé). Entrez le nom du serveur de site SMS à partir duquel vous souhaitez que la requête provienne. Il peut s’agir du site central si vous souhaitez interroger toute la hiérarchie ou de tout serveur de site primaire enfant, mais dans ce cas, vous n’aurez que la hiérarchie de ce site primaire enfant. Entrez ensuite le compte avec l’autorisation d’interroger SMS à l’aide du domaine domain\username, puis entrez le mot de passe de ce compte. (Le mot de passe ne s’affichera pas. Vous pouvez donc effectuer cette opération en présence d’autres personnes.)
Six boutons radio vous permettent de sélectionner la disposition, et de choisir d’autoriser ou d’empêcher les rôles SMS d’apparaître sur le dessin. Ces cases à cocher sont situées sous l’onglet Options. Le fait d’appuyer sur le bouton Draw lance l’utilitaire. Il vérifie également pour voir si Visio est disponible, interroge ensuite le serveur de site SMS primaire spécifié et ajoute les objets au diagramme Visio. Le diagramme Visio peut paraître laid lorsque SMSMap décharge les objets, mais à la fin, l’utilitaire organise ces derniers au format spécifié au début.
Approfondissez vos connaissances
Vous savez désormais pourquoi et comment décrire votre hiérarchie SMS à l’aide de SMSMap. Pour ceux qui souhaitent poursuivre les efforts de développeur, penchons-nous davantage sur le fonctionnement de l’utilitaire.
SMSMap utilise les interfaces de serveur de site SMS gérées pour rassembler des informations SMS et les assemblys Visio Primary Interop pour produire un diagramme Visio mettant en page toutes les formes nécessaires. La version 3.1 du kit de développement logiciel SMS 2003 contient la dernière version des interfaces de serveur de site SMS gérées. Cette série d’interfaces gérées vous permet de vous connecter et de configurer un serveur de site SMS via n’importe quelle application ou n’importe quel langage Microsoft .NET Framework.
Ces interfaces utilisent l’espace de noms System.Management pour interagir avec un fournisseur de SMS via Windows® Management Instrumentation (WMI). Pour utiliser les interfaces, vous devez développer votre application avec un langage .NET compatible (par exemple, C#, Visual Basic. NET et ainsi de suite) et référer Microsoft.SystemsManagementServer.Automation.dll à l’assembly .NET fourni avec le kit de développement logiciel SMS.
Les classes .NET Management nettoient de nombreuses idiosyncrasies du modèle objet de WMI pour présenter un modèle cohérent et orienté objets. Les tâches de base de connexion WMI, d’énumération d’objet, d’exécution de méthode, de suppression d’objet, de récupération d’objet et d’événement peuvent toutes être effectuées via les classes .NET Management.

Assemblys Primary Interop Visio
Un assembly Primary Interop vous permet d’utiliser le code géré pour contrôler les applications COM, telles que Visio, par programmation. Les assemblys Primary Interop Visio vous autorisent à intégrer et étendre la fonctionnalité Visio dans des applications gérées.
Si vous avez déjà installé .NET Framework sur votre ordinateur, lorsque vous installez par la suite Visio, le programme d’installation ajoute les assemblys Primary Interop Visio au cache d’assembly global (GAC, Global Assembly Cache) sur votre ordinateur. Vous pouvez ajouter une référence aux assemblys Primary Interop Visio à partir de vos applications gérées.
Après avoir ajouté la référence au projet, vous pouvez commencer à travailler avec les objets Visio à partir de votre application gérée. Visio dispose d’un modèle objet complet qui fournit une série de classes, d’interfaces et d’énumérations pour que vous puissiez créer des diagrammes par programmation.

Flux de programmes
Maintenant que j’ai décrit les interfaces de composant principales pour Visio et SMS, je vais expliquer le flux de l’utilitaire lui-même.
Lors de l’utilisation d’interfaces gérées, la première étape consiste à se connecter au fournisseur SMS. Ceci peut être accompli en créant une nouvelle instance de la classe SMSProvider. En interne, cette classe recherche le fournisseur SMS pour le serveur de site spécifié et se connecte à ce fournisseur avec une série d’informations d’authentification donnée. Si le fournisseur se trouve sur l’ordinateur local, les informations d’authentification actuelles seront utilisées à la place de celles fournies lors de la connexion au fournisseur. Bien que vous puissiez exécuter SMSMap sur le serveur SMS, je vous recommande de l’exécuter sur un poste de travail séparé sur lequel Visio est installé. La plupart des serveurs de site SMS n’ont pas Visio installé pour des raisons évidentes.
Lorsque vous accédez aux données d’accès sur le site SMS via la classe SMSProvider, les droits de sécurité sont traités comme si vous utilisiez la console Administrateur SMS. Ceci signifie, par exemple, que si vous tentez de configurer les paramètres pour un serveur de site par un SMSProvider, le compte avec lequel vous vous connectez au fournisseur doit avoir la même série de droits que si vous utilisiez la console de l’administrateur.
La classe SMSProvider fournit une méthode GetSiteSettings qui vous permet d’obtenir les paramètres de site pour le site actuel (auquel le fournisseur appartient) ou pour tout site avec un code de site spécifique. Les extraits de code à la figure 3 affichent la manière dont SMSMap se connecte au fournisseur pour le serveur de site ciblé. Les informations d’authentification de l’utilisateur vont être transférées au format Domain\User. Vous pouvez également spécifier "." pour indiquer la machine actuelle. La figure 3 inclut également le code qui permet d’afficher les résultats de l’interface utilisateur et les informations de connexion.
Figure 3 Extraits de GetSiteSettings (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
L’étape suivante consiste à arrêter le fichier XML pour rassembler et enregistrer les informations SMS pour le serveur de site ciblé, comme illustré à la figure 4.
Figure 4 Création du fichier XML (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Ensuite, le site ciblé doit être dessiné dans le diagramme Visio et mis à jour dans l’interface utilisateur et le journal, comme vous pouvez le voir à la figure 5.
Figure 5 Création du site dans Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Pour passer toute la hiérarchie sous le site ciblé, le même code de base décrit ci-dessus qui interroge SMS et dessine dans Visio est exécuté. Il s’agit d’une fonction nommée Niveau qui est appelée de manière récursive pour s’assurer que tous les sites enfants sont interrogés quelle que soit la grandeur de la hiérarchie. Le niveau rassemble les informations de site SMS et les enregistre dans XML, l’interface utilisateur et le journal pour chaque site enfant sous le site ciblé. Enfin, la figure 6 affiche comment le diagramme Visio est mis à jours à l’aide du format sélectionné lorsque l’utilitaire démarre. Ensuite, les fichiers XML et journal sont fermés.
Figure 6 Finalisation (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Ce n’est qu’un début
Bien sûr, ceci n’est qu’un début et des améliorations sont possibles. Les points de gestion des appareils doivent être examinés étant donné que je ne les vois pas dans le kit de développement logiciel. Plusieurs paramètres de site supplémentaires pourraient être ajoutés pour décrire un site de manière exhaustive. Un travail supplémentaire est peut-être nécessaire sur l’ajout d’une grande gamme de paramètres de disposition Visio afin d’améliorer l’aspect des petites et grandes hiérarchies. Chaque type de disposition a ses propres difficultés en tentant de créer des affichages efficaces. Et, bien sûr, l’ajout de la prise en charge du System Center Configuration Manager 2007 est la prochaine étape très importante. Mais même cette première version de SMSMap peut aider les administrateurs SMS à afficher un aperçu général et essayer des scénarios « et si » avec les couches et la transparence Visio.
Si vous téléchargez le code source, vous pouvez étendre l’utilitaire pour répondre à vos besoins. J’ai testé SMSMap sur Windows XP SP2 avec Visio 2003 et Windows Vista™ Enterprise avec Visio 2007. Si vous avez des suggestions sur la manière d’améliorer cet utilitaire, envoyez-nous un message électronique à jeff.tondt@microsoft.com.

Jeff Tondt est un consultant senior pour Microsoft Consulting Services. Il se concentre sur les zones de gestion des systèmes, l’automatisation et la gestion des correctifs. Il est expert technique des SMS. Vous pouvez lui écrire à l’adresse jeff.tondt@microsoft.com.


 Comment &#231;a marche: D&#233;pannage d’erreurs RPC
Comment ça marche
Dépannage d’erreurs RPC
Zubair Alexander

Si vous avez déjà eu l’occasion de travailler avec des plates-formes Windows Server, vous avez sans doute eu l’occasion de voir des erreurs d’appel de procédure distante (RPC) à un moment ou un autre. Ces erreurs vous informent que le serveur RPC est indisponible ou qu’il n’y a plus de points de terminaison disponibles, à moins qu’ils ne fournissent un autre avertissement énigmatique. Si ces messages vous déroutent, cet article vous intéressera. Je vais
examiner des erreurs courantes, diverses techniques utilisables pour identifier les erreurs RPC que vous voyez et aborder certaines solutions pour résoudre des problèmes spécifiques. Mais avant que je ne parle des erreurs RPC et de solutions spécifiques, étudions les bases terminologiques de RPC.

Qu’est-ce que RPC ?
RPC est une méthode de communication interprocessus (IPC) utilisée par des clients et des serveurs pour communiquer ensemble. Plus simplement RPC est utilisé par des programmes, généralement sur un ordinateur client, pour exécuter un programme sur un serveur. Par exemple, des clients Microsoft® Outlook® communiquent avec Microsoft Exchange Server à l’aide de RPC. L’ordinateur client envoie un message au serveur avec certains arguments. Le serveur répond au client avec un message qui contient les résultats du programme exécuté.
Le point de terminaison fait partie intégrante de ce processus : le nom, le port ou le groupe de ports sur un ordinateur contrôlé par un serveur pour les requêtes client entrantes. Plus précisément, il s’agit d’une adresse spécifique au réseau d’un processus de serveur qui est utilisé pour les RPC.
L’Endpoint Mapper, qui fait partie du sous-système RPC, est chargé de répondre aux requêtes des clients pour résoudre des points de terminaison dynamiques. Dans certaines situations, l’Endpoint Mapper est également chargé d’attribuer des points de terminaison aux serveurs de façon dynamique.
Le service Localisateur est un autre composant important de RPC. Il gère une liste de services et serveurs RPC sur le réseau. Un client Windows® se connecte au contrôleur de domaine sur les ports Server Message Block (SMB) (TCP 139 et 445) et recherche des services ou serveurs RPC par le biais du service Localisateur.
La plupart des services Windows intégrés communiquent entre eux via RPC. Par exemple, les services de certificats, DCOM, FRS, MSMQ, MAPI et le service de réplication Active Directory® se servent de RPC pour la communication. Donc, si le service RPC ne fonctionne pas convenablement sur un réseau, il se peut que vous rencontriez un certain nombre de problèmes de communication.

Erreurs RPC
Examinons à présent certaines des erreurs que vous pouvez rencontrer en cas de panne du service RPC. (Cette liste n’est en aucun cas exhaustive.)
Lorsque le service de réplication de fichier (FRS) tombe en panne, il peut s’agir d’une erreur redoutée d’indisponibilité de RPC. Si vous essayez de mapper un lecteur, vous pouvez obtenir une erreur d’accès refusé. Lorsque vous utilisez Utilisateurs et ordinateurs Active Directory, vous pouvez voir l’erreur indiquant que le domaine spécifié n’existe pas ou n’a pu être contacté. En vous connectant au domaine, vous pouvez obtenir une erreur indiquant que le système ne peut pas vous connecter à ce domaine parce que le compte d’ordinateur système dans son domaine principal est manquant ou le mot de passe sur ce compte est inexact.
Lorsque le client Microsoft Outlook essaye de communiquer avec Exchange Server, les défaillances RPC peuvent indiquer au client une erreur trompeuse, en lui signalant par exemple que ses informations de connexion sont inexactes ou qu’Outlook n’a pas pu ouvrir de session.
En plus de ces erreurs, lorsque le service RPC n’est pas disponible, vous pouvez rencontrer d’autres problèmes. Par exemple, il se peut que vous ne puissiez pas accéder au domaine dans Favoris réseau ou ouvrir le composant logiciel enfichable Stratégie de groupe.
Il s’agit là de quelques exemples de situations dans lesquelles vous ne vous attendiez sans doute pas à ce que RPC crée des problèmes. Il y a de nombreux autres exemples et, dès que vous travaillez avec des processus à distance, les problèmes de RPC peuvent être la cause initiale de vos difficultés. Donc comment s’en assurer et, surtout, comment dépister l’erreur précise ? Voyons cela.

Dépannage
Si vous pensez que le service RPC entraîne des problèmes, il y a plusieurs outils que vous pouvez utiliser pour diagnostiquer les problèmes.
Repadmin est l’un de ces outils. Ce programme est habituellement utilisé pour contrôler et dépanner des problèmes de réplication d’Active Directory, mais il peut également être utilisé pour dépanner des problèmes d’Endpoint Mapper RPC. Pour l’exécuter, à l’invite de commande, tapez repadmin /bind. Si vous avez des problèmes de RPC, vous risquez de voir s’afficher un message vous signalant qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper. Il s’agit là d’un premier indice que le problème est lié à RPC.
Vous pouvez aussi utiliser l’outil de diagnostic du contrôleur de domaine (DCDiag), un programme de ligne de commande qui permet de diagnostiquer les problèmes de contrôleurs de domaines. Si vous voyez une erreur indiquant un état 1722 qui signifie que le serveur RPC est indisponible, vous savez que vous avez un problème de RPC que l’outil de diagnostic du contrôleur de domaine vient juste de dévoiler.
Parfois, lorsque vous utilisez Ntdsutil (un outil de ligne de commande qui sert à gérer Active Directory et à exécuter de nombreuses tâches de maintenance), vous pouvez rencontrer des erreurs RPC si vous essayez de vous connecter au serveur. L’une des erreurs les plus courantes se traduit généralement par un message vous informant qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper. Ceci est un nouvel indice que le service RPC rencontre sans doute des problèmes. Avec l’outil Gpotool, qui vérifie la cohérence des objets de la stratégie de groupe sur les contrôleurs de domaines, vous obtiendrez des erreurs similaires si RPC est responsable.
Le fichier Dcpromo.log qui est généré lorsque vous promouvez un serveur Windows 2000 Server ou Windows Server® 2003 en tant que contrôleur de domaine à l’aide de l’outil Dcpromo peut également révéler des problèmes de RPC. Par exemple, si la promotion échoue, examinez le journal. Il se trouve dans le dossier %windir%\debug. Les erreurs répertoriées vous indiqueront que le service d’annuaire n’a pas répliqué la partition ou créé l’objet. Un code d’erreur se trouvera à la fin du message. Voici un exemple du type de message d’erreur que vous pourriez voir dans le fichier Dcpromo.log :

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Notez le code d’erreur 1722, qui survient quatre fois dans ce message et indique que le serveur RPC est indisponible. La figure 1 répertorie certains codes d’erreurs et leurs descriptions, mais vous en trouverez plusieurs autres à l’adresse msdn2.microsoft.com/ms681386.
Figure 1 Codes d’erreur et leurs descriptions (Close Figure 1)

Code d’erreur | Description
58 | Le serveur spécifié ne peut pas exécuter l’opération demandée.
1721 | Ressources insuffisantes pour accomplir cette opération.
1722 | Le serveur RPC n’est pas disponible.
1723 | Le serveur RPC est trop occupé pour terminer cette opération.
1727 | L’appel de procédure distante a échoué et ne s’est pas exécuté.
1753 | L'Endpoint Mapper n’a plus de point final disponible.

Résolution des erreurs RPC
À présent que vous avez vu comment détecter certaines des erreurs RPC, examinons quelques solutions.
Les clients Microsoft se connectent à l’Endpoint Mapper RPC sur le port 135. Ensuite, l’Endpoint Mapper indique au client le port d’écoute pour le service demandé. Les numéros de ports sont attribués de façon dynamique et sont compris entre 1024 et 65 535. Lorsque vous voyez des erreurs, par exemple 1753, cela vous indique qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper, ce qui signifie que l’Endpoint Mapper RPC n’a pas pu utiliser un port supérieur à 1024 pour un service. J’explorerai ce sujet plus profondément un peu plus tard.
La première chose à faire est de vérifier l’état du service RPC sur le serveur. En fonction du type de rôle du serveur, le RPC et le service Localisateur RPC doivent avoir l’état répertorié à la figure 2. Si l’un des deux services n’est pas configuré comme illustré dans la figure, essayez d’ajuster l’état, redémarrez votre serveur, puis faites un test pour voir si votre problème est résolu.
Figure 2 État du service RPC (Close Figure 2)

Rôle serveur | Service RPC | Service Localisateur RPC
Windows Server 2003—Contrôleur de domaine | Démarré, Automatique | Arrêté, Manuel
Windows Server 2003—Serveur membre | Démarré, Automatique | Arrêté, Manuel
Windows Server 2003—Serveur autonome | Démarré, Automatique | Arrêté, Manuel
Windows 2000 Server—Contrôleur de domaine | Démarré, Automatique | Arrêté, Automatique
Windows 2000 Server—Serveur membre | Démarré, Automatique | Démarré, Manuel
Windows 2000 Server—Serveur Autonome | Démarré, Automatique | Arrêté, Manuel
Assurez-vous que votre client peut envoyer une requête ping au serveur qui rencontre des problèmes de connectivité. Par exemple, si vous avez du mal à communiquer avec un serveur appelé DC1 dont l’adresse IP est 192.168.1.200, utilisez la commande suivante à l’invite de commande pour vérifier que le DNS résout correctement l’hôte DC1 :
Ping –a 192.168.1.200
Veillez à utiliser le commutateur -a avec l’adresse IP et non le nom d’hôte.
Si tout fonctionne, vous devriez obtenir une réponse de DC1 ressemblant à la réponse ping de la figure 3. Notez qu’au lieu de résoudre simplement l’adresse IP 192.168.1.200, la commande ping a également résolu le nom d’hôte dc1.contoso.com. Ceci confirme que la résolution de nom DNS fonctionne correctement et que la résolution de l’hôte dc1.contoso.com se fait exactement comme prévu.
Figure 3 Réponse ping (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
Assurez-vous également que le registre sur votre client Windows XP ou Windows 2000 contient au moins les quatre ClientProtocols répertoriés dans le volet de droite de la figure 4.
Figure 4 ClientProtocols RPC répertoriés dans le registre
Figure 4 ClientProtocols RPC répertoriés dans le registre
Si certaines entrées sont manquantes, ajoutez une nouvelle valeur de chaîne avec le nom et le type de données illustrés à la figure 4. Il y a, par défaut, une cinquième entrée appelée ncacn_nb_tcp, qui est utilisée pour identifier NetBIOS sur TCP comme famille de protocole pour le point de terminaison. En fonction de votre configuration, il se peut que cette entrée ne soit pas répertoriée sous ClientProtocols, auquel cas vous pouvez l’ajouter manuellement pour voir si elle résout les erreurs RPC.
Notez les clés répertoriées sous le dossier Rpc dans le volet gauche de la figure, à savoir ClientProtocols, NameService, NetBios et SecurityService. Si vous voyez une clé appelée Internet qui n’a pas de valeur, essayez de la supprimer et redémarrez votre ordinateur. Ceci aidera peut être à résoudre votre problème. Comme toujours, cependant, faites preuve de prudence lorsque vous modifiez le registre Windows.
Comme mentionné plus haut, RPC peut utiliser des ports compris entre 1024 et 65 535, donc vous devez vous assurer que ces ports ne sont pas bloqués par un pare-feu. La façon la plus simple de vous assurer qu’un port est ouvert consiste à utiliser l’outil Port Query. Il y a deux versions de cet outil : Une version ligne de commande (PortQry) et une version interface graphique (PortQueryUI).
PortQry peut être téléchargé dans le centre de téléchargement Microsoft. Pour plus d’informations, consultez l’article « Description de l’utilitaire de ligne de commande Portqry.exe ». Vous y trouverez de brèves descriptions de rapports d’états et d’exemples de commandes de PortQry à utiliser pour résoudre des problèmes. N’oubliez pas que vous pouvez aussi utiliser la version interface graphique, qui est beaucoup plus simple et peut être téléchargée à l’adresse go.microsoft.com/fwlink/?LinkId=73740.
Si vous utilisez Port Query, veillez à l’exécuter sur un ordinateur qui ne rencontre pas d’erreurs RPC et exécutez-le sur un ordinateur qui a des problèmes de RPC. Ainsi, si vous souhaitez vérifier que le port 135 (utilisé par le RPC Endpoint Mapper) est ouvert, utilisez PortQry à l’invite de commande comme ceci :
portqry -n [servername] -e 135
Que vous ayez utilisé PortQuery ou PortQueryUI, vous obtiendriez les résultats, comme ceci :
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
La dernière ligne montre que le port 135 est ouvert. Autrement, la dernière ligne aurait indiqué NOT LISTENING.
Pour vérifier une plage de ports, entrez la plage de numéros de port séparés par des virgules, comme ceci : « 135,1024-5000 ».

Autres solutions
Si vous avez testé toutes les astuces citées jusqu’à présent et que le problème n’est toujours pas résolu, il existe d’autres options. En fonction des problèmes spécifiques de votre environnement, vous pouvez essayer une des modifications du registre suivantes. (Attendez ! Avant de modifier le registre, vous devez vous assurer que vous avez sauvegardé votre système, en particulier le registre, pour que vous puissiez rétablir votre ordinateur à son état précédent si les choses tournent mal.)
L’une de ces options consiste à ajuster MaxUserPort pour spécifier le numéro de port le plus élevé que TCP peut attribuer lorsqu’une application demande un port d’utilisateur disponible au système. Par défaut, Windows Server 2003 définit la valeur MaxUserPort sur 5 000, ce qui signifie qu’il utilise 5 000 comme le numéro de port le plus élevé, même si l’entrée n’existe pas. En fonction de votre configuration, il se peut que cette entrée ne figure pas dans le registre, auquel cas vous pouvez l’ajouter dans l’emplacement indiqué à la figure 5.
Figure 5 Paramètre MaxUserPort dans le registre
Figure 5 Paramètre MaxUserPort dans le registre
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
Lorsque vous modifiez le registre, vous devez être conscient des autres effets secondaires potentiels, ce qui n’est pas toujours facile. La modification de cette entrée peut avoir un effet sur Microsoft Exchange Server si la valeur est définie en dessous de 50 000. Si Exchange Server Best Practices Analyzer (BPA) se rend compte que la valeur de la clé de registre MaxUserPort est inférieure à 50 000, il affiche un avertissement. Microsoft vous recommande de définir la valeur sur 60 000 pour éviter d’obtenir des avertissements de proxy NSPI (Name Service Provider Interface), tels que l’événement 9040. Pour plus d’informations, consultez le document Microsoft « La valeur MaxUserPort est trop faible ».
Vous pouvez également ajuster TcpMaxDataRetransmissions. Les paquets TCP attendent un accusé de réception de la part de la cible. Si aucun accusé ne leur parvient avant l’expiration du minuteur, les paquets sont retransmis, jusqu’aux heures de TcpMaxDataRetransmissions. La valeur par défaut pour ce paramètre est de 5 mais vous pouvez essayer une valeur de 4, ou même 3. N’utilisez pas une valeur inférieure à 3.
Si l’entrée de registre TcpMaxDataRetransmissions n’existe pas, vous pouvez l’ajouter au registre dans l’emplacement suivant, comme ceci :
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Pour plus d’informations sur TcpMaxDataRetransmissions, consultez l’article 170359 de la base de connaissances Microsoft, « Comment modifier le délai TCP/IP de retransmission maximale ».
TcpTimedWaitDelay est une autre valeur de registre avec laquelle vous pouvez aussi faire des essais. Si un client utilise trop de ports, il est tout à fait possible qu’il vienne à manquer de ports avant que TCP/IP ne libère des connexions fermées. C’est parce que TCP/IP ne libère pas la connexion avant que deux MSL (Maximum Segment Lives) ne passent (c’est ce qu’on appelle un état Time-Wait). De plus, puisque chaque MSL est définie sur 120 secondes et que TCP/IP ne libère pas la connexion tant que deux MSL ne sont pas passés, il faut au moins 240 secondes (4 minutes) pour que TCP/IP libère une connexion fermée. Notez que ce problème connu dans Windows NT® a été corrigé avec un Service Pack ; par conséquent, il y a peu de chance que vous rencontriez ce problème maintenant. Cependant, Microsoft recommande d’ajuster ce paramètre comme l’une des solutions possibles pour résoudre les erreurs de RFC Endpoint Mapper, comme expliqué dans l’article de la base de connaissances « Comment faire pour corriger les erreurs du mappeur de point final RPC ».
TcpTimedWaitDelay est ajouté au registre dans l’emplacement suivant :
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Pour plus d’informations sur TcpTimedWaitDelay, consultez l’article de la base de connaissances « Clients Windows NT à court de ports ». Bien que l’article ne recommande pas de nombres spécifiques, vous pourriez essayer de réduire TcpTimedWaitDelay à 60 (secondes) en décimal, ce qui correspond à 3c en hexadécimal.

Conclusion
Les erreurs RPC peuvent être la cause initiale de nombreuses erreurs de communication sur votre réseau. Heureusement, il existe plusieurs façons créatives de résoudre ces problèmes insaisissables. Certains des outils que j’ai suggérés ici sont intégrés, les autres sont disponibles dans le Kit de ressources Windows Server. Un grand nombre de ces outils sont répertoriés à la figure 6. Vous pouvez utiliser ces outils pour détecter la cause et l’emplacement des erreurs RPC, puis utiliser une des techniques répertoriées dans cet article pour résoudre les erreurs.
Figure 6 Outils de dépannage RPC (Close Figure 6)

Outil | Description
DCDiag | Analyse l’état des contrôleurs de domaine.
Observateur d’événements | Affiche les événements consignés.
Gpotool | Détermine si les stratégies sont valides et cohérentes.
NetDiag | Utilisé pour tester la connectivité réseau.
Moniteur réseau | Surveille et capture le trafic réseau.
Ntdsutil | Fournit des installations de gestion pour Active Directory.
PortQry, PortQueryUI | Utilisé pour tester la connectivité TCP/IP.
Repadmin | Diagnostique les problèmes de réplication entre des contrôleurs de domaine Windows.
RPCDump | Généralement utilisé avec le Moniteur réseau.
RPCPing | Utilisé pour confirmer la connectivité RPC.

Zubair Alexander, MCSE, MCT et Microsoft MVP, possède SeattlePro Enterprises, une entreprise de formation et de consultation informatiques. Son expérience l’a amené à toucher à tous les aspects de l’éducation informatique : auteur, professeur d’université, consultant, ingénieur réseau, orateur public, architecte de sécurité, administrateur systèmes, éditeur technique et formateur. Vous pouvez contacter Zubair à l’adresse alexander@techgalaxy.net.


 Le petit c&#226;bleur: Trafic IPv6 sur les connexions VPN
Le petit câbleur
Trafic IPv6 sur les connexions VPN
Joseph Davies

Comme vous commencez à évaluer le rôle d’Internet Protocol version 6 (IPv6) sur votre intranet et commencez à planifier son déploiement, vous devez comprendre comment le trafic IPv6 est pris en charge sur les connexions du réseau privé virtuel (VPN) dans Windows. Avec les connexions VPN, vous pouvez étendre votre réseau pour inclure des liens sur les
réseaux publics tels qu’Internet. Les connexions VPN sont protégées par des protocoles d’authentification renforcés pour valider les informations d’identification de l’utilisateur qui se connecte et les méthodes de cryptage pour assurer la confidentialité des données.
Windows® XP et Windows Server® 2003 incluent une pile de protocoles IPv6, mais beaucoup de services de base et de composants réseau ne prennent pas en charge IPv6. Windows Vista™ et Windows Server 2008, ancien nom de code « Longhorn », disposent d’une prise en charge complète pour IPv6, qui est installée et activée par défaut. En fait, presque toutes les applications réseau et les services inclus dans Windows Vista et Windows Server 2008 prennent en charge IPv6. Ce mois-ci, j’examine la prise en charge dans Windows Vista, Windows Server 2008, Windows XP et Windows Server 2003 pour le trafic IPv6 envoyé sur les connexions VPN qui sont établies sur Internet Protocol version 4 (IPv4) et Internet IPv6.

Connexions VPN sur Internet IPv4
Pour la plupart des intranets d’aujourd’hui, les connexions VPN sont créées sur Internet IPv4. La figure 1 affiche des composants Windows pour les connexions VPN de ce type. Ces composants comprennent les éléments suivants :
Figure 1 Composants Windows pour les connexions VPN sur Internet IPv4
Figure 1 Composants Windows pour les connexions VPN sur Internet IPv4
Client VPN C’est un ordinateur qui établit une connexion VPN d’accès distant à un serveur VPN et communique avec les ressources intranet. Une connexion VPN d’accès distant autorise le client VPN à agir comme s’il était directement connecté à l’intranet. Un client VPN peut exécuter les versions client ou serveur de Windows.
Serveur VPN Cet ordinateur écoute les tentatives de connexion VPN distantes, applique les exigences d’authentification et de connexion, et achemine des paquets entre les clients VPN et les ressources intranet. Un serveur VPN exécute généralement une version serveur de Windows avec le Routage et les Services d’accès distant.
Routeur VPN Un routeur VPN est un ordinateur qui établit ou écoute les tentatives de connexion VPN site à site. Une connexion VPN site à site connecte deux parties d’un intranet. Un routeur VPN exécute une version serveur de Windows ainsi que le Routage et les Services d’accès distant.
Connexion VPN Une connexion VPN est le lien logique entre le client VPN et le serveur VPN ou entre les routeurs VPN comme défini par l’encapsulation d’un protocole VPN.
Intranet compatible IPv6 Cet intranet peut transférer le trafic IPv6 en mode natif ou par tunnel comme paquets IPv4.
Hôte IPv6/IPv4 Ce nœud d’intranet envoie et reçoit le trafic IPv6 en mode natif ou par tunnel comme paquets IPv4.
Les clients VPN basés sur Windows, les serveurs et les routeurs peuvent utiliser les protocoles VPN suivants pour encapsuler les paquets envoyés sur la connexion VPN : Le protocole PPTP (Point-to-Point Tunneling Protocol), le protocole L2TP/IPsec (Layer Two Tunneling Protocol avec Internet Protocol security) et le protocole SSTP (Secure Socket Tunneling Protocol). SSTP est pris en charge uniquement par Windows Vista avec Service Pack 1 (SP1, en phase de test bêta) et Windows Server 2008.
Pour les connexions VPN sur Internet IPv4, deux méthodes sont utilisées pour envoyer IPv6 : Les paquets IPv6 sont transférés par tunnel comme paquets IPv4, ci-après appelés trafic IPv6 sur IPv4 et trafic IPv6 natif.
Dans cet article, la prise en charge du trafic IPv6 sur les connexions VPN est décrite en termes de protocoles VPN et versions de Windows. Pour les connexions VPN d’accès distant, une combinaison donnée de protocole VPN et la version de Windows implique la prise en charge par le client d’accès distant et les composants de serveur d’accès distant de Windows.

Trafic IPv6 sur IPv4
Dans cette méthode, un client d’accès distant ou un hôte IPv6/IPv4 sur l’intranet encapsule les paquets IPv6 avec un en-tête IPv4 et envoie le résultat comme un paquet IPv4. Pour les intranets, la technologie de transition IPv6 (RFC 4214) du protocole ISATAP (IntraSite Automatic Tunnel Addressing Protocol) permet aux nœuds IPv6/IPv4 un échange de trafic IPv6 sur un intranet IPv4 uniquement. Avec ISATAP, vous pouvez activer la connectivité IPv6 sur votre intranet IPv4 uniquement sans avoir à configurer ou mettre à niveau vos routeurs existants pour prendre en charge l’adressage et le transfert IPv6 natif. Pour plus d’informations sur ISATAP, voir « Technologies de transition IPv6 » à l’adresse microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
La figure 2 affiche la structure de paquet générale pour le trafic VPN lors de l’envoi d’un paquet IPv4 utilisant une connexion VPN sur Internet IPv4. Le paquet IPv4 est encapsulé par le protocole VPN avec un en-tête et, en fonction du protocole VPN, un code de fin. Le résultat est encapsulé avec un en-tête IPv4 qui permet le transfert sur Internet IPv4.
Figure 2 Paquets IPv4 utilisant une connexion VPN sur Internet IPv4.
Figure 2 Paquets IPv4 utilisant une connexion VPN sur Internet IPv4.
Pour le trafic IPv6 sur IPv4, la charge utile du paquet IPv4 envoyé sur la connexion VPN est un paquet IPv6. La figure 3 affiche la structure de paquet générale pour le trafic VPN lors de l’envoi d’un paquet IPv6 sur IPv4 utilisant une connexion VPN sur Internet IPv4.
Figure 3 Paquets IPv6 sur IPv4 utilisant une connexion VPN sur Internet IPv4
Figure 3 Paquets IPv6 sur IPv4 utilisant une connexion VPN sur Internet IPv4
Pour les connexions VPN d’accès distant, le trafic IPv6 sur IPv4 via Internet IPv4 est pris en charge par PPTP et L2TP/IPsec dans Windows Vista, Windows Server 2008, Windows XP SP1 ou supérieur et Windows Server 2003 et par SSTP dans Windows Vista SP1 et Windows Server 2008. Pour les connexions VPN site à site, le trafic IPv6 sur IPv4 via Internet IPv4 est pris en charge par PPTP et L2TP/IPsec dans Windows Server 2008 et Windows Server 2003.

Trafic IPv6 natif
Pour le trafic IPv6 natif, le client, le serveur ou le routeur VPN envoie les paquets IPv6 sur l’ensemble de la connexion VPN sans l’encapsulation IPv4 initiale. Cela est valable pour les intranets qui possèdent la connectivité IPv6 native et nécessite que les clients, les serveurs et les routeurs VPN prennent en charge le Protocole de contrôle IPv6 (IPV6CP), RFC 2472, qui définit comment les nœuds IPv6 négocient les options de configuration IPv6 pour les connexions basées sur PPP (Point-to-Point Protocol). Windows Vista et Windows Server 2008 prennent en charge IPV6CP alors que Windows XP et Windows Server 2003 ne le prennent pas en charge. La figure 4 affiche la structure de paquet générale pour le trafic VPN lors de l’envoi d’un paquet IPv6 natif utilisant une connexion VPN sur Internet IPv4.
Figure 4 Paquets IPv6 natifs utilisant une connexion VPN sur Internet IPv4
Figure 4 Paquets IPv6 natifs utilisant une connexion VPN sur Internet IPv4
Pour les connexions VPN d’accès distant, le trafic IPv6 natif sur Internet IPv4 est pris en charge par PPTP et L2TP/IPsec dans Windows Vista et Windows Server 2008 et par SSTP dans Windows Vista SP1 et Windows Server 2008. Pour les connexions VPN site à site, le trafic IPv6 natif qui transite sur Internet IPv4 est pris en charge par PPTP et L2TP/IPsec dans Windows Server 2008.

Connexions VPN sur Internet IPv6
Vous pouvez également établir des connexions VPN sur Internet IPv6. Ces connexions VPN sont rares maintenant, mais deviendront plus courantes à mesure que plus de fournisseurs de services Internet offrent IPv6 à leurs clients et plus d’organisations incluent la connectivité Internet IPv6 dans leurs réseaux de bord intranet.
Afin de prendre en charge les connexions VPN sur Internet IPv6, les protocoles VPN qui sont utilisés doivent prendre en charge des connexions sur IPv6. Dans Windows Vista et Windows Server 2008, les protocoles VPN de L2TP/IPsec et de SSTP prennent en charge les connexions VPN d’accès distant sur IPv6. Dans Windows Server 2008, L2TP/IPsec prend en charge des connexions site à site sur IPv6. Les connexions VPN sur Internet IPv6 utilisent la même série de composants que ceux des connexions VPN sur Internet IPv4 pour les connexions VPN d’accès distant et site à site.
Il y a également deux manières d’envoyer les paquets IPv6 sur Internet IPv6 : TraficIPv6 sur IPv4 et trafic IPv6 natif. La figure 5 illustre la structure générale des paquets IPv6 sur IPv4 lorsqu’ils sont envoyés sur une connexion VPN via Internet IPv6.
Figure 5 Paquets IPv6 sur IPv4 natifs utilisant une connexion VPN sur Internet IPv6
Figure 5 Paquets IPv6 sur IPv4 natifs utilisant une connexion VPN sur Internet IPv6
Pour les connexions VPN d’accès distant, le trafic IPv6 sur IPv4 via Internet IPv6 est pris en charge par L2TP/IPsec dans Windows Vista et Windows Server 2008 et par SSTP dans Windows Vista SP1 et Windows Server 2008. Pour les connexions VPN de site à site, le trafic IPv6 sur IPv4 via Internet IPv6 est pris en charge par L2TP/IPsec dans Windows Server 2008. Tout comme pour le trafic IPv6 sur IPv4 via Internet IPv4, le trafic IPv6 sur IPv4 via Internet IPv6 nécessite le déploiement d’une technologie de transition IPv6 telle qu'ISATAP sur votre intranet.
La figure 6 affiche la structure générale des paquets IPv6 natifs lorsqu’ils sont envoyés sur une connexion VPN via Internet IPv6. Tout comme pour le trafic natif IPv6 sur Internet IPv4, le trafic IPv6 natif sur Internet IPv6 nécessite la prise en charge IPV6CP et le déploiement de la connectivité IPv6 native sur votre intranet.
Figure 6 Paquets IPv6 natifs utilisant une connexion VPN sur Internet IPv6
Figure 6 Paquets IPv6 natifs utilisant une connexion VPN sur Internet IPv6
Pour les connexions VPN d’accès distant, le trafic Pv6 natif sur Internet IPv6 est pris en charge par L2TP/IPsec dans Windows Vista et Windows Server 2008 et par SSTP dans Windows Vista SP1 et Windows Server 2008. Pour les connexions VPN site à site, le trafic IPv6 natif sur Internet IPv6 est pris en charge par L2TP/IPsec dans Windows Server 2008.

Conclusion
La figure 7 affiche les quatre méthodes pour envoyer le trafic IPv6 sur les connexions VPN et la prise en charge dans Windows pour les deux différents types de connexions VPN. En quelques mots, si vous utilisez une technologie de transition IPv6 telle que ISATAP sur votre intranet, vous pouvez envoyer le trafic IPv6 sur IPv4 via les connexions VPN sur Internet IPv4 et IPv6. Si votre intranet prend en charge la connectivité IPv6 native, vous pouvez envoyer le trafic IPv6 natif sur les connexions VPN sur Internet IPv4 et IPv6 avec Windows Vista et Windows Server 2008.
Figure 7 Prise en charge du trafic IPv6 sur les connexions VPN dans Windows (Close Figure 7)

Méthode d’envoi du trafic IPv6 | Connexions VPN d’accès distant | Connexions VPN de site à site
Trafic IPv6 sur IPv4 via Internet IPv4 | PPTP et L2TP/IPsec dans Windows Vista, Windows Server 2008, Windows XP SP1 ou supérieur et Windows Server 2003 SSTP dans Windows Vista SP1 et Windows Server 2008 | PPTP et L2TP/IPsec dans Windows Server 2008 et Windows Server 2003
Trafic IPv6 natif sur Internet IPv4 | PPTP et L2TP/IPsec dans Windows Vista et Windows Server 2008 SSTP dans Windows Vista SP1 et Windows Server 2008 | PPTP et L2TP/IPsec dans Windows Server 2008
Trafic IPv6 sur IPv4 via Internet IPv4 | L2TP/IPsec dans Windows Vista et Windows Server 2008 SSTP dans Windows Vista SP1 et Windows Server 2008 | L2TP/IPsec dans Windows Server 2008
Trafic IPv6 natif sur Internet IPv6 | L2TP/IPsec dans Windows Vista et Windows Server 2008 SSTP dans Windows Vista SP1 et Windows Server 2008 | L2TP/IPsec dans Windows Server 2008

Joseph Davies est rédacteur technique chez Microsoft et il enseigne et écrit sur le réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et on lui doit la chronique en ligne mensuelle Le petit câbleur de TechNet.


 Windows&#160;PowerShell: Restructuration du pipeline
Windows PowerShell
Restructuration du pipeline
Don Jones

On a beaucoup dit à quel point Windows PowerShell est différent, nouveau et passionnant, bien qu’il soit basé sur les concepts d’interface de ligne de commande qui existent depuis des décennies, principalement sur les systèmes d’exploitation basés sur UNIX et Linux. Mais la terminologie que Windows PowerShell partage avec ses prédécesseurs fait facilement
ignorer la véritable flexibilité et le caractère unique de Windows PowerShell™, ainsi qu’à quel point il est idéal pour l’environnement Windows®.
L’une des fonctionnalités les plus discutées de Windows PowerShell est son pipeline, mais il s’agit également, malheureusement, de l’une de ses fonctionnalités les plus mal comprises. Ceci s’explique par le fait qu’elle repose sur une terminologie qui a été définie au début des années 1970 et qui représentait autrefois une fonctionnalité très différente et beaucoup moins puissante.

L’origine des canaux
L’un des premiers shells UNIX créés était le shell Thompson, très primitif et comportant uniquement les éléments de langage de script les plus simples, sans aucune variable. Le noyau possédait une conception délibérément modeste car son seul but véritable était d’exécuter des programmes. Il a cependant introduit un concept essentiel amélioré par rapport aux autres shells de l’époque : les canaux. En utilisant les symboles < et >, il était possible d’indiquer au shell de rediriger entrée et sortie en provenance et à destination de commandes différentes. Un utilisateur était alors capable, par exemple, de rediriger la sortie d’une commande vers un fichier.
Cette syntaxe a plus tard évolué afin que la sortie d’une commande puisse également être redirigée vers l’entrée d’une autre commande, permettant à de longues séquences de commandes d’être mises bout à bout afin d’accomplir des tâches plus compliquées. Pour la version 4 du shell, le caractère de ligne verticale | a été adopté pour la redirection de canal et porte par conséquent depuis le nom de caractère « Pipe » (canal en anglais). Même les versions les plus anciennes de MS-DOS® utilisaient une redirection élémentaire par le bais de ce caractère, permettant par exemple à un utilisateur de rediriger la sortie de la commande type vers l’entrée d’une commande more pour créer un affichage page par page des fichiers texte longs.
Bien que le shell Thompson ait été largement considéré comme inadéquat à la date de la sortie d’UNIX version 6 en 1975, le concept de canaux était bien assimilé par les développeurs de shell et adapté dans plusieurs technologies utilisées de nos jours.

Redirection de texte
L’une des restrictions des shells est leur nature textuelle. Dans les systèmes d’exploitation basés sur UNIX, ce n’est en fait pas une restriction, mais plutôt le reflet du fonctionnement intrinsèque du système d’exploitation. Dans UNIX, presque toutes les ressources peuvent être représentées comme fichier d’un certain type, ce qui signifie que la possibilité de rediriger du texte d’une commande à une autre confère puissance et flexibilité importantes.
Le texte, toutefois, est définitivement restrictif lorsqu’il est question d’informations de gestion. Par exemple, si je vous présentais une liste des services s’exécutant sur un ordinateur Windows, vous pourriez certainement arriver à la déchiffrer. Je pourrais par exemple placer le nom du service dans la première colonne et son mode de démarrage dans la seconde. Votre cerveau humain puissant effectuerait de manière transparente et instantanée l’analyse, ou la traduction, de l’affichage de texte en informations pertinentes que vous pourriez utiliser. Les ordinateurs, cependant, sont loin d’être aussi intelligents : pour qu’un ordinateur puisse tirer quelque chose de significatif de cette liste, il serait peut-être nécessaire de lui indiquer que la première colonne se compose des caractères 1 à 20, que les caractères 22 à 40 forment la deuxième colonne, et ainsi de suite.
Pendant longtemps, ce type d’analyse de fichier texte était la seule méthode dont les administrateurs disposaient pour mettre bout à bout plusieurs commandes. En fait, les langages d’écriture de scripts tels que VBScript et Perl excellent dans la manipulation de chaînes, principalement parce qu’ils doivent pouvoir accepter la sortie texte d’un programme ou d’une commande et convertir ensuite cette sortie en données utiles pouvant être utilisées pour une tâche ultérieure. J’ai écrit des scripts VBScript, par exemple, qui utilisent la sortie de la commande Dir, extraient de la sortie les noms et dates de fichiers et déplacent ensuite les fichiers anciens et inutilisés vers un emplacement d’archive. Le traitement de chaîne est extrêmement difficile car des exceptions (les variations dans les données en entrée) surviennent presque toujours, vous obligeant à revoir la logique du script pour traiter toutes les permutations possibles.
En tant que forme d’écriture de script ou d’automatisation dans un environnement Windows, le traitement de chaîne est moins utile. En effet, Windows n’enregistre quant à lui que peu d’informations dans un format texte facile d’accès. Il utilise plutôt des magasins de données tels qu’Active Directory®, le Registre Windows et le magasin de certificats, pour que les utilisateurs de scripts utilisent d’abord un outil pour générer un certain type de sortie texte, puis un second pour effectuer son traitement et l’utiliser.

Les objets sont plus faciles
Les développeurs de logiciels Windows ont toujours eu la vie un peu plus facile. À l’origine, Microsoft a développé COM pour représenter spécifiquement les fonctionnements internes complexes de Windows d’une manière plus facile à utiliser. Aujourd’hui, Microsoft® .NET Framework poursuit cette tâche. Il représente les fonctionnements internes de logiciels de manière standardisée.
D’un point de vue générique, COM et .NET exposent les éléments en tant qu’objets (les développeurs de logiciels objecteront sans doute à cette simplification mais, dans l’intérêt de notre article, un terme simple suffira). Ces objets possèdent tous des membres de types variés. Dans notre cas, les propriétés et les méthodes des objets sont ce qui nous intéresse le plus. Une propriété décrit essentiellement un objet à certains égards ou modifie l’objet ou son comportement. Par exemple, un objet service peut disposer d’une propriété contenant le nom du service et d’une autre propriété contenant le mode de démarrage du service. Les méthodes font en sorte qu’un objet effectue une certaine action. Un objet service peut disposer de méthodes nommées Stop, Start, Pause et Resume représentant par exemple les diverses actions pouvant être exécutées avec le service.
Du point de vue de la programmation (ou de la génération de scripts), il est fait référence aux membres de l’objet avec une notation par points. Les objets sont souvent affectés à des variables, vous donnant ainsi une méthode de manipulation physique de l’objet. Si je dispose par exemple d’un service affecté à la variable $service, je peux arrêter ce service en utilisant la syntaxe $service.Stop. Je peux également récupérer le nom du service en affichant $service.Name.

Objets dans les canaux
Windows étant un système d’exploitation complexe et de taille importante, qui n’enregistre pas ses données de gestion dans des représentations de style texte, les anciennes techniques de shell ne sont pas vraiment adaptées à ce dernier. Supposons par exemple que je dispose d’un outil de ligne de commande nommé SvcList.exe produisant une liste mise en forme de services et leurs modes de démarrage. Dans le shell de ligne de commande de Windows (un shell dont les racines sont le shell MS-DOS, vieux de plusieurs décennies), je pourrais exécuter quelque chose de la forme :
SvcList.exe | MyScript.vbs
Cette instruction récupère une liste de services et la redirige vers un fichier VBScript. Il faudrait que j’écrive un fichier VBScript pour traiter la liste mise en forme et exécuter toute action de mon choix, par exemple extraire tous les services dont le mode de démarrage est Disabled (Désactivé). Cette tâche prendrait du temps. En fin de compte, le problème est que SvcList.exe possède une sortie unique. Il ne partage par de format commun que les autres commandes peuvent facilement utiliser pour tirer parti de sa sortie.
Les objets, cependant, peuvent fournir ce format commun et c’est pourquoi le pipeline Windows PowerShell fonctionne avec les objets entiers et non uniquement le texte. Lorsque vous exécutez une cmdlet telle que Get-WMIObject, vous produisez un groupe (ou une collection en jargon de programmation) d’objets. Chaque objet est complet, avec des propriétés et méthodes vous permettant de le manipuler. Si je redirige les objets vers la cmdlet Where-Object, je peux les filtrer pour que seuls les objets de mon choix soient affichés. Where-Object n’a pas besoin d’analyser du texte parce qu’elle ne reçoit pas de texte : elle reçoit des objets. Par exemple :
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Ou, si vous préférez la syntaxe plus courte disponible au travers d’alias :
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
Ce qui est intéressant est que Windows PowerShell passe toujours les objets dans le pipeline. Ce n’est qu’à la fin du pipeline (lorsqu’il n’existe plus rien vers lequel les objets peuvent être passés), que le shell génère une représentation textuelle des objets à l’aide de leurs règles de mise en forme intégrées. Examinons par exemple ceci :
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Cet ensemble de trois cmdlets récupère tous les services de mon ordinateur local, filtre tous ceux qui n’utilisent pas le compte LocalSystem pour ouvrir une session et passe ensuite le reste à la cmdlet Select-Object, qui extrait uniquement deux propriétés, Name et StartMode, que je lui ai demandé de sélectionner. Le résultat est un rapport simple de services ouvrant une session en tant que LocalSystem (par exemple dans un but d’audit de sécurité).
Puisque toutes les cmdlets partagent un format de données commun (les objets) elles sont capables de partager des données entre elles sans traitement de chaîne compliqué. Et puisque Windows PowerShell possède de manière native la possibilité de créer une représentation sous forme de texte d’un objet, la fin de ce canal est assurément une sortie que je peux, en tant que personne, comprendre. La figure 1 illustre un exemple de sortie produite.
Figure 1 Sortie texte produite par un ensemble de cmdlets redirigées passant des objets.
Figure 1 Sortie texte produite par un ensemble de cmdlets redirigées passant des objets.

Des canaux passionnants
La raison pour laquelle l’utilisation de canaux dans Windows PowerShell est si épatante est que tout dans Windows PowerShell est un objet, avec des propriétés et des méthodes que vous pouvez utiliser. Même un fichier texte est, du point de vue technique, une collection d’objets chaînes, chaque ligne de fichier faisant office d’objet chaîne unique et indépendant. Créez par exemple un fichier texte (à l’aide du Bloc-notes) nommé C:\Computers.txt. Remplissez le fichier avec du texte et exécutez ceci dans Windows PowerShell :
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Ou, encore, si vous préférez moins de frappe, vous pouvez utiliser des alias :
gc C:\Computers.txt | select Length | fl
Ce code fournit une liste indiquant la longueur de chaque ligne de votre fichier texte en nombre de caractères. Get-Content récupère les objets chaînes du fichier, Select-Object extrait la propriété Length de chacun de ces objets et Format-List crée ensuite une sortie agréable et lisible pour vous. Bien que ceci ne soit peut-être pas un outil d’administration pratique à utiliser, il illustre que même une chose aussi simple qu’une ligne de texte est un objet dans Windows PowerShell.
La possibilité de rediriger des objets de cmdlet en cmdlet (ou même d’une cmdlet vers un script) permet la création d’instructions d’une ligne d’une puissance incroyable. Ce sont de simples chaînes de cmdlets attachées dans un long pipeline qui affinent une série d’objets pour vous donner exactement ce que vous voulez. Avec pratiquement aucune écriture de script ou de programme de quelque sorte que ce soit, les cmdlets de Windows PowerShell, chaînées ensemble dans un pipeline approprié, peuvent accomplir des résultats remarquables.

Prise en charge des générations futures
Le fait que les futurs produits serveurs de Microsoft s’appuient également sur Windows PowerShell permet d’étendre cette fonctionnalité. Au cours de la mise en œuvre d’un nouvel ordinateur Exchange Server 2007, vous pouvez par exemple utiliser Windows PowerShell pour récupérer toutes les boîtes aux lettres, filtrer tout celles qui ne correspondent pas au bureau dans lequel le nouveau serveur de messagerie sera situé et transférer ensuite ces boîtes aux lettres vers le nouveau serveur, tout ceci en une seule ligne de texte sans écriture de script. L’équipe Exchange Server 2007 a publié une longue liste d’instructions puissantes d’une seule ligne. Celles-ci démontrent avec efficacité la puissance du pipeline et les tâches administratives qu’il est capable d’accomplir.
L’astuce avec Windows PowerShell est de comprendre que, bien qu’il s’appuie sur des principes et des philosophies du monde d’UNIX établis depuis longtemps, ce nouvel outil est tout particulièrement adapté à l’administration de Windows. Ne laissez pas la banalité de la terminologie vous faire croire que Windows PowerShell est tout juste une imitation pour Windows du shell d’UNIX. Windows PowerShell contient de tous nouveaux concepts qui tirent parti de la plate-forme Windows et il est solidement associé à la manière de faire les choses dans Windows.

Don Jones est MVP Windows PowerShell et auteur de Windows PowerShell 101 (ScriptingTraining.com). Vous pouvez contacter Don sur le site www.ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: Dans les scripts comme dans la vie, le look est important
Hé, vous le scripteur !
Dans les scripts comme dans la vie, le look est important
Les scripteurs Microsoft

Pendant des centaines et même des milliers d’années, les philosophes et les sages nous ont convaincus que nous devions regarder au delà de l’apparence physique pour juger quelqu’un ou quelque chose. (Ce qui ne veut pas dire que nous devrions juger les autres, ne nous méprenons pas, la beauté est une affaire de goût.) Mais vous savez ce qu’on dit : la vraie beauté vient de l’intérieur, pas de l’extérieur, et votre personnalité est bien plus importante que votre apparence.
À cela, les scripteurs ne peuvent ajouter qu’une chose : foutaises !
Vous avez bien lu, foutaises. Les scripteurs sont les premiers à reconnaître que dans un monde parfait l’apparence physique ne ferait aucune différence. Cependant, nous ne vivons pas dans un monde parfait. Si c’était le cas, les frites et la glace au chocolat formeraient deux des principaux groupes d’aliments. Que cela vous plaise ou non, l’apparence a son importance. Et cela s’applique à vos scripts comme à tout le reste.
Les scripteurs sont conscients que peu de gens sont émus par la pure beauté d’un script VBScript s’exécutant dans une fenêtre de commande (à l’exception peut-être du scripteur Dean Tsaltas, mais il est le seul qui nous vient à l’esprit).
D’un autre côté, il est également vrai que dans le monde de la haute technologie qui est le nôtre, les scripteurs ne sont plus limités à l’écriture de scripts qui s’exécutent dans une fenêtre de commande. Grâce aux applications HTML (HTA), les scripteurs peuvent faire appel à la puissance de DHTML pour créer des interfaces utilisateur graphiques pour leurs scripts. Ces mêmes compétences HTML peuvent être utilisées pour créer des gadgets Windows Vista™, une nouvelle voie qui a le potentiel de révolutionner l’écriture de scripts d’administration de système par rapport à ce qui existe aujourd’hui. Mais devinez quoi ? Dès que vous abordez le sujet des interfaces utilisateur graphiques, les vieilles notions bien ancrées selon lesquelles la beauté est superficielle s’enfuient à toutes jambes. Pour les scripts qui s’exécutent dans un environnement graphique, le look est tout aussi important que le fonctionnement et les performances.
Et c’est tout le problème. Après tout, nous sommes scripteurs ; que savons-nous de la création d’interfaces utilisateur graphiques ? On dirait que notre chance a tourné, pas vrai ?
Peut-être. Mais en y réfléchissant, peut-être que non. Est-ce que j’ai entendu quelqu’un dire « Dieu merci, nous avons les scripteurs » ?
Non, honnêtement. Vous n’avez pas entendu ça ? Peut-être que quelqu’un l’a un peu murmuré...
Cela n’a pas beaucoup d’importance. Quelqu’un aurait dû le dire, parce que les scripteurs sont là pour nous aider (que nous le voulions ou non).
Pour démarrer dans le monde merveilleux des interfaces utilisateur graphiques, jetons un coup d’œil à une petite HTA toute simple. (Si vous souhaitez avoir plus d’informations sur la création des HTA, consultez le Centre des développeurs HTA.)
Ce que vous voyez à la figure 1 est la première partie d’un magnifique système d’informations de bureautique. Comme vous pouvez le voir, nous avons commencé en plaçant un joli petit graphique dans le coin supérieur droit de la fenêtre de HTA. L’objectif est, lors du premier chargement de la HTA, de récupérer le nom de l’utilisateur connecté et d’afficher ensuite son nom et le nom de l’ordinateur sur cette image. Nous ajouterons plus tard toute une panoplie de choses intéressantes à la HTA mais, comme on dit, commençons par le commencement.
Figure 1 Les débuts de notre interface graphique HTA vraiment très jolie
Figure 1 Les débuts de notre interface graphique HTA vraiment très jolie
Non, nous ne savons pas vraiment à qui correspond ce « on ». Sûrement un philosophe... Probablement Voltaire. Cela ressemble bien à du Voltaire.
Je vous l’accorde, c’est une bien jolie petite application, mais sa...beauté...ne fera probablement pas monter les larmes aux yeux de notre scripteur Dean. Mais elle fait office d’outil de démonstration pratique, avec un concept fondamental applicable à de nombreuses situations différentes. Après tout, nombre de ces gadgets Windows Vista de haut vol fonctionnent sur un principe similaire : ils affichent simplement un graphique épatant (disons une jauge ou un cadran) et écrivent ensuite un peu de texte au-dessus de ce graphique. Ainsi, vous obtenez une petite jauge qui affiche l’espace disque disponible, alors qu’en fait, il ne s’agit que d’un graphique générique auquel est superposé un texte dynamique.
OK, pour tout vous avouer, cet aveu ne nous éclaire pas beaucoup non plus. Mais les choses devraient se préciser un peu, plus nous avancerons dans cet article.
Il existe juste un problème avec la notion de pouvoir afficher un graphique et d’écrire ensuite du texte par dessus le graphique : ça ne marche pas. Avec les balises HTML standard, on obtient plutôt quelque chose du genre de la figure 2. Pas vraiment ce que nous avions à l’esprit. Peut-être que Nietzsche, qui a déclaré que « les êtres humains ne pourront jamais espérer placer du texte au-dessus d’un graphique, du moins pas dans une HTA », avait raison.
Figure 2 Une première tentative de superposition de texte
Figure 2 Une première tentative de superposition de texte
Ou peut-être que Nietzsche avait tort : Est-ce que j’ai entendu quelqu’un dire... Ne faites pas attention à ce que je dis. Comme nous venons de le réaliser, nous ne pouvons pas faire ce que nous voulions en utilisant le HTML de tous les jours ; il ne fonctionne tout simplement pas de cette manière. Bien sûr, en théorie, nous pourrions faire de notre graphique un graphique d’arrière-plan et utiliser ensuite des tableaux et des espaces insécables et tout une panoplie d’autres petits trucs pour essayer de faire en sorte que le texte soit superposé à l’image. Mais nous ne disons pas « en théorie » pour rien, car à l’exception des cas les plus simples, cette stratégie ne fonctionne jamais.
Il se trouve qu’il existe une bien meilleure méthode pour créer des dispositions épatantes dans une HTA ou un gadget Windows Vista : les feuilles de style en cascade, mieux connues sous le nom de CSS.
Les CSS sont utilisées pour définir les polices, les marges et les alignements, les couleurs et autres aspects de présentation d’un document. (Ceci s’applique en particulier aux pages Web. Cependant, comme les HTA et les gadgets sont, fondamentalement, des pages Web, les CSS s’appliquent également bien à eux.) Il n’est même pas envisageable de commencer à décrire tout ce qu’il est possible de faire avec les CSS donc, pour plus d’informations, vous pourriez souhaiter consulter la documentation de référence CSS pratique et détaillée sur MSDN®. Pour le moment, il est suffisant de dire que nous pouvons utiliser les CSS avec précision pour contrôler la disposition du HTA, y compris la capacité de superposer un élément (notre texte) sur un autre (notre graphique).
Nous allons expliquer comment nous parvenons à faire tout cela. Mais avant de nous lancer dans cette explication, jetons un coup d’œil au code d’une HTA très simple à la Figure 3.
Figure 3 Pour terminer, le script... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Comme vous pouvez le voir, ce n’est pas vraiment impressionnant. Nous avons une sous-routine Window_OnLoad qui, comme l’indique son nom, s’exécute automatiquement chaque fois que notre HTA est démarrée ou actualisée. Nous parlerons de cette sous-routine dans une minute. En outre, nous avons deux éléments HTML : notre graphique et une balise span. Comme vous le savez sans aucun doute, nous utilisons ces balises pour insérer le graphique, en utilisant l’attribut align pour nous assurer que l’image apparaît sur le côté droit de la fenêtre :
<img src=”test2.jpg” align=”right”>
Ce qui nous amène aux balises HTML pour le span :
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
OK, nous avons donc utilisé ici une balise span. Qu’est-ce qu’une balise span ? Eh bien, pour toutes sortes d’utilisations, une balise span correspond tout simplement à une zone nommée de votre HTA. C’est une section « démarquée » de la fenêtre de HTA que nous pouvons identifier par programmation (principalement parce que nous lui avons affecté l’identificateur UserData). Une fois que nous avons configuré une balise span, nous pouvons écrire une sous-routine qui lui affecte du texte ou du code HTML. En fait, non seulement nous pouvons le faire, mais c’est précisément ce que nous avons fait pour notre HTA.
Toutefois, comme nous l’avons dit précédemment, nous parlerons de cela plus tard. Avant cela, nous devons jeter un œil au paramètre style ajouté à la balise span :
style=”position:absolute;left:770px;top:150px”
Ce paramètre, comme vous pourriez le suspecter, est l’astuce qui permet de positionner notre texte dynamique sur le graphique. Nous spécifions en fait ici trois attributs style séparés.
Position Nous avons indiqué à notre HTA que nous voulions que la position de notre balise span soit absolue. Cela signifie essentiellement que nous voulons toujours que la balise span soit au même emplacement, même si cela implique, comme c’est le cas ici, que le texte est écrit au-dessus d’un autre élément (tel que, pourquoi pas, un graphique).
Left Ceci spécifie simplement la position de la balise span par rapport au bord de l’extrême gauche de la fenêtre de HTA. Dans ce cas, nous souhaitons que la balise span commence à 770 pixels (770px) de la gauche.
Top Ce paramètre est très similaire à l’attribut Left, à ceci près que nous spécifions la position de la balise span par rapport au bord supérieur de la fenêtre de HTA. Dans ce cas, nous voulons démarrer en haut de la fenêtre et compter 150 pixels (150px) avant de commencer la balise span.
Comment avons-nous su que nous voulions définir le côté gauche de notre balise span sur 770 pixels et le côté supérieur sur 150 pixels ? Eh bien, pour être franc, nous n’en savions rien. Nous l’avons en fait deviné, en plaçant le graphique sur la page et en affectant des valeurs aux attributs Left et Top de la balise span. Nous avons ensuite ouvert le HTA et regardé le résultat. Comme vous pouvez le prévoir, nous étions un petit peu décalés et nous avons donc ajusté les valeurs, actualisé le HTA et regardé encore une fois. Nous avons fait ceci plusieurs fois jusqu’ à ce que, comme Boucles d’or, nous ayons trouvé quelque chose de parfait.
Remarque : vous connaissez l’histoire de Boucles d’or et des trois ours, leurs lits et leurs chaises, la soupe qui était trop chaude ou trop froide et ainsi de suite. Soit dit en passant, nous ne sommes pas sûrs que Boucles d’or puisse être considérée comme une grande philosophe. Il est intéressant de remarquer qu’elle n’a pas hésité à pénétrer dans la maison des ours, à manger leur soupe, à s’asseoir sur leurs chaises et à dormir dans leurs lits ; elle semble posséder une philosophie tout à fait unique.
Quoi qu’il en soit, la figure 4 illustre à quoi notre HTA ressemble maintenant. Je vous l’accorde, ce n’est peut-être pas une œuvre d’art, mais on ne peut demander à Picasso d’écrire par programmation des informations sur un graphique.
Figure 4 Gare à la puissance du style
Figure 4 Gare à la puissance du style
Puisqu’on en parle, comment avons-nous écrit par programmation des informations sur un graphique ? Eh bien, j’ai une bonne nouvelle : il est enfin temps de parler de notre sous-routine Window_OnLoad, qui apparaît à la figure 5.
Figure 5 Sous-routine Window_OnLoad (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
Maintenant que nous regardons cette sous-routine d’un peu plus près, nous voyons qu’il n’y a vraiment pas grand chose à en dire, n’est-ce pas ? Comme vous pouvez le voir, nous commençons par créer une instance de l’objet Wscript.Network. Nous utilisons ensuite ces lignes de code pour récupérer le nom d’utilisateur, le domaine et le nom d’ordinateur :
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
Ceci, bien sûr, se trouve être exactement les informations que nous voulons écrire dans notre fenêtre de HTA. Tout ce que nous avons à faire est de combiner les variables strUser et strComputer avec une petite balise HTML et d’affecter ensuite la chaîne résultante à la propriété InnerHTML de notre balise span :
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Oui, nous savons que ce morceau de code a l’air compliqué. Mais il n’est vraiment pas si mauvais que ça. Il paraît compliqué simplement parce que nous combinons plusieurs éléments dans une seule chaîne. Nous démarrons par une balise paragraph ouvrante, qui spécifie que nous voulons centrer le texte dans le paragraphe.
“<p align = ‘center’> “
Ensuite, nous faisons appel à une balise ouvrante font, qui spécifie que nous allons utiliser un texte blanc de 18 points :
“<font style=’font-size:18pt;color:white’>”
StrUser est la variable qui contient notre nom d’utilisateur, au format Domaine\Nom d’utilisateur. "<br> insère un saut de ligne. Nous l’insérons pour que le nom d’utilisateur apparaisse sur une ligne et le nom d’ordinateur sur une deuxième ligne. strComputer est la variable contenant le nom de notre ordinateur. Enfin, nous ajoutons les balises fermantes font et paragraph :
“</font></p>”
En examinant ces éléments individuellement, vous voyez que le code n’est pas du tout aussi compliqué qu’il y paraissait.
À propos, il est possible de positionner à peu près tout élément HTML de votre choix. Supposez par exemple que vous vouliez centrer un bouton sous le graphique. Pour cela, ajoutez simplement ceci à votre code de HTA :
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
Cela devrait vous donner une HTA ressemblant à celle de la figure 6.
Figure 6 Quel charmant bouton
Figure 6 Quel charmant bouton
Ici encore, vous devrez faire plusieurs essais pour que le bouton soit positionné à la perfection, mais cela ne devrait pas prendre très longtemps. En fait, si vous êtes prêt à effectuer des calculs, vous pouvez probablement déterminer la position correcte à l’avance. Tout ce que vous devez connaître est la largeur et la hauteur de chaque objet (ce que vous pouvez spécifier à l’aide du paramètre style) ainsi que la largeur et la hauteur de la fenêtre de HTA. Par défaut, tout du moins sur l’ordinateur de test des scripteurs, les HTA mesurent approximativement 1020 pixels de large par 685 pixels de haut (ces résultats peuvent bien sûr varier). Faute de mieux, vous pouvez démarrer avec ces nombres et les ajuster ensuite pour convenir à vos exigences.
Ceci est bien entendu une présentation beaucoup trop brève de CSS, mais elle devrait suffire pour vous lancer dans la voie qui vous permettra de rendre vos scripts magnifiques. Les philosophes ridiculiseront sans doute ces efforts et vous diront que la véritable beauté d’un script vient de l’intérieur et non de l’extérieur. Mais réfléchissez une seconde. Qui sont les plus grands philosophes de tous les temps ? Bingo. Platon, Socrate, Aristote, les suspects habituels. En gardant ça à l’esprit, j’aimerais vous poser une question : avez-vous déjà vu une photo de ces philosophes ? Vous ne trouvez pas bizarre qu’il n’existe aucune photo de ces personnes qui disent que la beauté n’a pas d’importance ? Cela ne vous paraît pas bizarre ? Je vous invite à y réfléchir.

Les scripteurs Microsoft travaillent pour (enfin, sont employés par) Microsoft. Lorsqu’ils ne sont pas en train de jouer au base-ball, d’entraîner une équipe ou de regarder un match (ou de se livrer à de multiples autres activités), ils dirigent le Script Center TechNet. Vous pouvez le vérifier vous-même sur www.scriptingguys.com.


 Questions et r&#233;ponses sur la file d'attente Exchange: R&#244;les de transport Hub et Edge, machines virtuelles, et plus encore
Questions et réponses sur la file d'attente Exchange
Rôles de transport Hub et Edge, machines virtuelles, et plus encore
KC Lemson and Nino Bilic

Dans l’article de mai 2007 de Questions et réponses sur la file d'attente Exchange, nous avons parlé des problèmes de stockage de fichiers .pst sur les partages réseau. L’équipe de performance de Windows Server a récemment lancé un blog et ils ont abordé
ce sujet avec de multiples détails techniques, c’est pourquoi nous souhaitons vous transmettre le lien. Passons maintenant aux questions.

Q : Dois-je nécessairement déployer le rôle de serveur Edge si je souhaite déployer Microsoft Exchange Server 2007 ?

R : Non, vous n’avez pas à déployer Edge afin de déployer Exchange Server 2007. Vous pouvez disposer d’une seule machine exécutant les rôles de serveur de base (tels que la boîte aux lettres, l’accès client et le transport Hub) acceptant les messages électroniques d’Internet pour votre domaine et exécutant des programmes anti-spam et antivirus.

Q : Quelles sont les différences entre les rôles de serveur de transport Edge et Hub ? Que va-t-il me manquer si je ne déploie pas Edge ?

R : Le principal objectif du rôle Hub est de transférer les messages au sein de l’organisation et d’appliquer des stratégies d’entreprise à ces messages. Avec le rôle Hub, les règles de transport sont basées sur les objets Active Directory® (les utilisateurs, les listes de distribution et ainsi de suite). Le rôle Hub vous permet également d’ajouter des exclusions aux messages ou d’effectuer une journalisation des messages envoyée aux groupes d’utilisateurs, étant donné que vous souhaitez probablement baser ces règles sur l’appartenance à Active Directory. Par exemple, vous souhaitez peut-être effectuer une journalisation de tous les messages envoyés à DLOfUsersOnLitigationHold ou ajouter des exclusions aux messages sortants envoyés par DLOfMembersOfLegalTeam. Bien qu’il soit possible d’exécuter des agents anti-spam sur le serveur Hub, ils ne sont pas activés par défaut. Par conséquent, vous devez les installer manuellement en exécutant le script install-antispamagents disponible dans le répertoire \scripts sur le serveur.
Le principal objectif du rôle Edge consiste à transmettre les messages de et vers l’organisation ainsi que d’exécuter l’hygiène de message (anti-spam, antivirus, filtrage de contenu ou de pièce jointe et ainsi de suite) sur ces messages. La fonctionnalité anti-spam est activée dès l’installation lorsque vous installez un serveur Edge. Une des fonctionnalité uniques du rôle Edge : il n’est pas nécessaire de l’ajouter à un domaine Windows®. Il peut être exécuté sur une installation Windows Server® autonome ne faisant pas partie d’un domaine Windows, mais Edge peut toujours être géré en tant que partie de l’organisation Exchange 2007 dans votre forêt d’entreprise.
Ceci est particulièrement avantageux dans un réseau de périmètre où vous pouvez souhaiter que le serveur fasse partie d’un groupe de travail. Vous pouvez également disposer d’une forêt séparée de manière explicite pour les machines dans le réseau de périmètre. Pour davantage de commodité, les serveurs Edge déployés dans cette situation peuvent exécuter toute hygiène de message et le routage pour les messages entre le réseau d’entreprise et Internet, tout en restant gérés conformément au reste de l’administration des systèmes Exchange 2007.
Sur un serveur Edge, les règles de transport sont basées sur des adresses SMTP, pas sur les objets Active Directory. Bien sûr, vous pouvez utiliser les adresses SMTP de listes de distributions ou d’utilisateurs dans votre Active Directory. Pour l’essentiel, les règles de transport Edge sont un sous-ensemble des règles de transport Hub, l’exception étant l’action de mise en quarantaine, qui est uniquement disponible sur les serveurs Edge.
Les serveurs Edge disposent également de certaines fonctionnalités exposées par les agents qui ne sont pas disponibles sur le serveur de transport Hub : suppression de pièces jointes et réécriture d’adressage. La suppression de pièces jointes permet de supprimer de manière sélective les pièces jointes potentiellement dangereuses avec des extensions telles que .exe et .com. L’agent de réécriture d’adressage vous permet de réécrire les en-têtes de message électronique pour que, bien que votre domaine et les adresses de proxy SMTP par défaut sur les comptes utilisateur soient @contoso.com, par exemple, les messages sortants vers Internet apparaîtront comme provenant de @northwindtraders com. De même, les serveurs Edge exécutent uniquement le routage basé sur le domaine ou l’espace d’adressage, donc si vous partagez le même espace d’adressage SMTP entre Exchange et un autre système de messagerie, vous devrez soit exécuter ce routage sur le serveur Hub, soit le faire en collaboration avec l’agent de réécriture d’adressage sur le serveur Edge.
Autre considération importante : le serveur Exchange 2007 est-il directement confronté à Internet (que ce soit par le rôle de serveur Hub ou Edge). En d’autres termes, les connexions au port 25 sur l’enregistrement MX de votre domaine sont-elles connectées à Exchange 2007 de quelque manière que ce soit ? Vous disposez peut-être déjà d’une passerelle SMTP, d’un mur de virus ou de tout autre solution sur Internet qui accepte le courrier pour votre domaine et le transmet à Exchange au sein du réseau de l’entreprise. Si vous déployez les serveurs Edge ou Hub pour qu’ils soient confrontés à Internet, vous pouvez alors profiter d’une des fonctionnalités les plus utiles d’Exchange 2007 : Agrégation de listes fiables. Avec l’agrégation de listes fiables, les utilisateurs qui ajoutent des expéditeurs à leurs listes fiables dans Microsoft Outlook® (ce qu’ils font généralement pour les bulletins Internet ou les messages électroniques de détaillants) propageront ces listes de manière sécurisée aux rôles Edge et Hub pour que les messages de ces expéditeurs contournent le filtre de contenu. Bien sûr, le spam d’un utilisateur est le précieux bulletin d’un autre utilisateur, par conséquent, l’agrégation de listes fiables s’effectue pour chaque utilisateur. Vous pouvez en apprendre davantage sur le fonctionnement de cette fonctionnalité dans la documentation d’Exchange 2007.
Si vous vous retrouvez avec un déploiement dans lequel un serveur s’exécutant avec le rôle Hub accepte les messages électroniques d’Internet pour votre domaine, gardez plusieurs choses à l’esprit. Bien sûr, vous devez d’abord vous assurer d’avoir un pare-feu correct ou une solution de filtrage de port pour que votre serveur ne reçoive que des connexions sur les ports nécessaires, tels que le port 25. De même, n’oubliez pas d’installer les agents anti-spam parce qu’ils ne sont ni installés ni activés par défaut. Étant donné que le scénario de déploiement le plus courant du serveur Hub est au sein du réseau d’entreprise, il n’autorise pas les connexions anonymes à l’installation. Vous devrez vérifier le groupe d’autorisation AnonymousUsers sur le connecteur de réception du port 25. Vous devrez également vous assurer d’activer l’agrégation de listes fiables et planifier son exécution périodique. Ainsi, à mesure que les utilisateurs mettent à jour les listes fiables dans leurs boîtes aux lettres, le courrier envoyé à ces utilisateurs à partir de leurs listes d’expéditeurs fiables contourne le filtrage du contenu. Vous trouverez plus de détails sur notre blog.
Le code suivant affiche une commande À qui met à jour toutes les boîtes aux lettres quotidiennement à 23H00 sur tous les serveurs à l’aide d’un fichier de commandes appelé SafeList.bat :
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
Ce code affiche les contenus du fichier SafeList.bat :
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
Si vous devez vérifier le fonctionnement correct des paramètres, vous trouverez plus d’informations dans la documentation d’Exchange 2007.

Q : Après avoir redémarré mon image Virtual PC avec Exchange, je continue à avoir des problèmes relatifs au répertoire ou au serveur LDAP. L’utilitaire Telnet vers 389 fonctionne et tous les services s’exécutent. Pourquoi ?

R : J’ai moi-même rencontré ce problème l’année dernière au Tech•Ed. J’avais une copie d’un Virtual PC sur mon ordinateur portable que j’avais copiée d’un ordinateur au bureau. J’envisageais de l’utiliser pour faire des démonstrations aux membres de la presse qui devaient publier des articles pour le lancement de la version bêta 2 d’Exchange 2007 le mois suivant.
J’ai fait des milliers de démonstrations du produit et je savais que la version était solide. Je ne me suis donc pas préparé outre mesure pour cette démonstration. Vous pouvez imaginer mon stress lorsque j’ai démarré Virtual PC le lundi matin, quelques heures avant la première réunion, et que chaque partie de ma version m’indiquait qu’elle ne pouvait pas contacter un contrôleur de domaine. Grâce au grand nombre de personnes brillantes sous la tente, nous avons pu résoudre rapidement ce problème.
Le problème que j’ai rencontré au Tech•Ed était le résultat d’une exécution de Virtual PC sur mon portable super lent. À la racine du problème était une situation d’engorgement de DNS et Active Directory. Le serveur DNS sur l’image était configuré pour être intégré à Active Directory, mais en raison de la séquence dans laquelle les services sur l’image étaient chargés (et disons, le manque de vélocité de mon portable), les services d’annuaire nécessaires n’avaient pas démarré au moment où le serveur DNS tentait de contacter Active Directory.
Cette situation peut se produire sur n’importe quel serveur ayant DC et Exchange sur la même machine (ce n’est pas nécessairement une image virtualisée). Il est cependant beaucoup plus probable que ce souci survienne dans un environnement virtualisé où il existe un ralentissement supplémentaire (particulièrement avec un portable très lent comme le mien).
J’ai également vu un problème similaire se produire avec des images Virtual PC copiées entre deux machines, surtout lorsqu’une de ces machines est sur un réseau différent. Si vous avez fait l’expérience de ce problème, vérifiez l’adresse IP du système d’exploitation dans l’image. Il peut avoir une ancienne adresse IP de l’ancien réseau. Actualisez-le pour obtenir une adresse IP du nouveau réseau et regardez si cela résout le problème.
Pour éviter ces types de problème à l’avenir, vous pouvez vous assurer que le serveur DNS sur l’invité ne soit pas intégré à Active Directory et installer DNS sur l’hôte et l’invité. Faites en sorte que l’invité transfert à l’hôte pour les enregistrements inconnus et que l’hôte transfert à son serveur DNS approprié pour les enregistrements inconnus. Lorsque votre image démarre et tente de mettre à jour les enregistrements DNS, elle sera moins sujette aux défaillances.

Q : Il semblerait que l’installation d’Exchange 2007 soit assez différente de l’installation dans les versions précédentes d’Exchange. Comment cela fonctionne-t-il ?

R : En effet, il y a plusieurs étapes à l’installation d’Exchange 2007. Voici un aperçu général du fonctionnement du processus.

Lors de la première exécution de setup.exe, un processus démarre vous offrant des liens vers la plupart des conditions préalables que vous devrez installer avant de pouvoir commencer l’installation des rôles de serveur réels. Après avoir installé toutes ces conditions préalables, le lien Install Microsoft Exchange devient disponible et vous pouvez cliquer dessus (voir la figure 1).
Figure 1 Lien d’installation disponible une fois les conditions préalables générales satisfaites
Figure 1 Lien d’installation disponible une fois les conditions préalables générales satisfaites
Si vous avez exécuté setup.exe à partir du réseau et que vous avez cliqué sur le lien d’installation, les fichiers d’installation de base seront copiés dans le dossier %TEMP%\ExchangeServerSetup\ sur l’ordinateur local. L’Assistant d’installation s’ouvre.
L’Assistant d’installation vous indique les divers choix possibles, tels que le contrat de licence, le signalement d’erreurs et le type d’installation (où vous pouvez choisir les rôles de serveur à installer). Les pages de l’Assistant varient en fonction de la présence et l’état de l’organisation Exchange actuelle (si tel est le cas).
Une fois ce processus terminé, l’installation exécutera une vérification de préparation. Il s’agit en fait d’une version subséquente de Microsoft Exchange Server Best Practices Analyzer (BPA), qui, par défaut, se connectera à Internet pour télécharger le dernier fichier XML des conditions préalables. Vous avez ainsi la possibilité de mettre à jour les conditions requises de manière périodique ou de résoudre tout problème porté à la connaissance de l’équipe d’Exchange depuis le lancement du produit. Une fois la vérification des conditions préalables terminée, vous pourrez consulter les résultats et poursuivre. Sinon, vous verrez tout problème à résoudre avant de poursuivre l’installation. Si votre serveur échoue la vérification de conditions préalables, l’Assistant vous permet de relancer la vérification dans la plupart des cas.
Une fois la vérification de conditions préalables réussie, le bouton Install apparaît et vous permet de démarrer l’installation à partir de n’importe quel rôle choisi précédemment. Seuls les fichiers pour les rôles sélectionnés seront copiés et installés.
À la fin de l’installation, vous pourrez lancer la console de gestion Exchange et appliquer toute mise à jour d’Exchange 2007 qui pourrait être disponible.

KC Lemson est Directeur expérience utilisateur pour Exchange Server. Son compte en banque en ligne a été temporairement interrompu.
Nino Bilic est responsable de programme de prise en charge pour Exchange Server. Il a récemment ajouté une deuxième adresse de messagerie à sa carte de crédit.


 Vigilance s&#233;curit&#233;: Outils de gestion des ACL
Vigilance sécurité
Outils de gestion des ACL
Jesper M. Johansson

Dans Windows, les listes de contrôle d’accès (ACL) vous offrent un contrôle très précis sur la possibilité des utilisateurs et des processus d’utiliser des ressources telles que les fichiers et les dossiers. La gestion des ACL peut constituer une des tâches les plus compliquées en ce qui concerne la protection de la sécurité des systèmes de vos utilisateurs. Heureusement, il existe plusieurs utilitaires avantageux
qui aident à automatiser et simplifier les tâches concernant les autorisations et les ACL.
La plupart des lecteurs connaissent l’outil apprécié cacls.exe qui est présent dans chaque version de Windows NT® depuis sa première publication. Si vous exécutez cacls.exe dans Windows Vista™, vous êtes accueilli par ce message :
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
En plus des mises à jour des ACL dans Windows Vista (que j’ai abordées dans le numéro de juin 2007 de TechNet Magazine, voir technetmagazine.com/issues/2007/06), Microsoft a également mis à jour certains des outils que vous utilisez pour gérer les ACL. Il est intéressant de noter que les plus importantes de ces mises à jour sont les outils de ligne de commande.
Icacls.exe est nouveau dans Windows Vista (et également à un bas niveau dans Windows Server® 2003 Service Pack 2). Il remplacera par la suite cacls.exe, qui, comme vous le savez peut-être, n’a jamais été complètement mis à jour pour prendre en charge les autorisations plus précises introduites avec Windows® 2000, ce qui en fait une mise à jour ayant environ sept ans de retard.
Étonnamment, bien qu’il soit désapprouvé, cacls.exe inclut certaines nouvelles fonctionnalités. D’abord, il connaît les points de jonction et les liens symboliques et sait comment les traverser. Deuxièmement, il peut imprimer et déterminer un ACL à l’aide d’une chaîne de langage SDDL (Security Description Definition Language).
Cependant, malgré les mises à jour de cacls.exe, vous souhaitez vraiment disposer des fonctionnalités disponibles dans icacls.exe.

Enregistrement et restauration des ACL
Un souhait constant (du moins pour moi) ces dix dernières années a été la possibilité d’enregistrer un ACL de manière à pouvoir le restaurer à une date ultérieure. Ceci s’avère être une des opérations les plus compliquées à exécuter sur les ACL. Sauf dans certains cas spéciaux, il est peu probable de pouvoir retourner exactement à l’endroit où vous vous seriez trouvé si vous n’aviez pas, pour commencer, corrompu les ACL. Néanmoins, cette fonctionnalité peut être tout à fait utile.
Avant d’examiner comment enregistrer ou restaurer les ACL, laissez-moi d’abord expliquer pourquoi c’est si difficile. Supposons que vous ayez une hiérarchie contenant des données utilisateur pour les étudiants d’une université locale. Vous enregistrez l’ACL le 1er février. Le 17 avril vous découvrez que d’une certaine manière, l’ACL a été corrompu et que vous allez le restaurer à partir de la copie enregistrée. Quelles complications pourrait-il y avoir avec cette opération ?
D’abord, le nouveau trimestre a démarré le 2 avril. Environ 15 % de vos étudiants ont obtenu leurs diplômes. Par conséquent, leurs répertoires n’existent plus. Ainsi, dans le fichier de sauvegarde, certains ACL ne sont pas valides. Vous avez également un lot de nouveaux étudiants, encore 15 %, qui ont démarré ce trimestre. Maintenant ils possèdent des répertoires de base, mais aucun ACL dans le fichier de sauvegarde. Que doivent être leurs ACL ? Ensuite bien sûr vous avez les 70 % qui sont toujours là, mais ils ont créé de nouveaux fichiers et dossiers et en ont supprimés d’autres. Vous pouvez ignorer les dossiers supprimés, mais comment configurez-vous les nouveaux dossiers qu’ils ont créés ? Que se passe-t-il si un étudiant a décidé de partager un dossier avec ses amis le 4 mars ? Changerez-vous cela lorsque vous restaurerez l’ACL ?
L’enregistrement et la restauration des ACL ne sont pas des opérations aussi simples que beaucoup de gens voudraient vous le faire croire. Vous devez être extrêmement prudent en effectuant ces opérations. Par conséquent, il est très possible, même probable, que vous ayez un comportement incertain. La restauration des ACL constitue sans aucun doute un dernier recours. Plus la dernière sauvegarde est ancienne, plus la probabilité de détérioration est grande lorsque vous les restaurez.
Si néanmoins, vous souhaitez essayer cette fonctionnalité, exécutez icacls.exe avec le commutateur /save :
icacls <target> /save acls.bin /t
Cela permet d’enregistrer les ACL sur un fichier appelé acls.bin. Ce fichier contiendra une ligne pour chaque objet avec un ACL suivi d’une ligne spécifiant l’ACL dans le langage SDDL. En utilisant le commutateur /t, la commande agira sur l’objet que vous avez spécifié et tous les objets et conteneurs situés au-dessous de celui-ci.
La fonctionnalité d’enregistrement est un ajout bienvenu dans la boîte à outils, mais elle a quelques défauts. Par exemple, elle enregistre seulement la liste de contrôle d’accès discrétionnaire (DACL), pas la liste de contrôle d’accès de système (SACL). En fait, s’il existe un SACL, elle enregistre une valeur factice qui indique cela, mais n’enregistre aucune partie du SACL.
De plus, la façon dont l’ACL est enregistré crée un problème intéressant. Avant d’ouvrir l’ACL enregistré dans votre éditeur de texte préféré, rappelez-vous de ne pas
modifier votre ACL enregistré !
Si vous deviez ouvrir le fichier contenant votre ACL enregistré dans un éditeur de texte, vous trouveriez qu’il s’agit d’un fichier texte formaté Unicode (UTF-16). En fait, c’est presque de cela qu’il s’agit. Ceci pourrait vous faire penser que vous pouvez le modifier et l’enregistrer à partir d’un éditeur de texte. Ne le faites pas !
Si vous ouvrez le fichier qui contient les ACL enregistrés dans un éditeur de texte et l’enregistrez ensuite, vous ne pourrez pas restaurer les ACL à partir de ce fichier. En fait ce n’est pas un fichier texte Unicode. Ce fichier doit commencer avec les 2 octets 0xfffe. Si vous enregistrez le fichier avec un éditeur de texte, tel que le Bloc-notes, il mettra cet indicateur dans le fichier dans les deux premiers octets. Cependant, l’outil icacls.exe suppose que les données ACL démarrent à l’octet 0 dans le fichier. Par conséquent, l’outil ne pourra pas traiter les ACL dans le fichier comme il suppose que les deux premiers octets font partie de la chaîne spécifiant l’objet sur lequel effectuer les opérations. Votre fichier de sauvegarde sera inutilisable.
Microsoft est conscient de ce problème, mais comme il n’a été signalé que très tard dans le cycle bêta pour Windows Vista, ce défaut n’a pas été corrigé avant la sortie. À ce stade, nous ne savons pas quand il sera corrigé, ni même s’il le sera. Donc pour le moment, le meilleur conseil est de ne pas modifier vos ACL enregistrés. Si vous avez besoin de le faire, enregistrez le fichier comme fichier .bin et utilisez un éditeur hexadécimal, comme par exemple votre environnement de développement préféré.
Une fois que vous avez enregistré un ACL à l’aide du commutateur /save, vous pouvez le restaurer en utilisant icacls.exe avec le commutateur /restore. La commande de restauration dans sa forme la plus simple utilise cette syntaxe :
icacls <directory> /restore acls.bin
La procédure de restauration ne fonctionne pas sur les fichiers. Pour voir cela, examinez la séquence de commandes illustrée à la figure 1. Ici je crée un fichier d’enregistrement en pointant icacls.exe vers un fichier. J’essaie ensuite de le restaurer en remplaçant simplement /restore par /save. Cela échoue parce que la commande de restauration ne fonctionne que sur les répertoires. Les fichiers qu’elle est supposée modifier sont déjà spécifiés dans le fichier acls.bin. Pour restaurer l’ACL, je le pointe vers le répertoire au lieu du fichier. C’est ce que je fais dans la dernière commande où je spécifie « . » comme l’objet sur lequel effectuer les opérations.
Figure 1 Enregistrement et restauration des ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Notez également que la commande de restauration doit être exécutée dans le mode élevé ! Vous pouvez exécuter la commande d’enregistrement d’une invite de commande s’exécutant comme utilisateur à faible privilège ou même comme utilisateur standard, tant que vous avez le droit de lire l’ACL. Cependant, pour restaurer l’ACL, vous devez disposer d’un jeton administratif complet et non corrompu.

Remplacement des SID
Une autre fonctionnalité qui est très utile dans icacls.exe, est la possibilité de remplacer les autorisations d’un utilisateur par des autorisations d’un utilisateur différent. Cela s’effectue pendant la restauration à l’aide du commutateur /substitute. La documentation du commutateur de remplacement indique qu’il a besoin d’un SID, mais plus tard elle explique que cela peut en fait être un nom d’utilisateur normal. Ainsi, la séquence illustrée à la figure 2 fonctionne.
Figure 2 Remplacement des SID pendant la restauration (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Comme vous pouvez le voir, je me retrouve avec l’ACL que j’avais avant, mais l’ACE qui spécifiait les autorisations pour foo les spécifie maintenant pour bar à la place.

Modification du propriétaire
L’outil chown a été un élément de base des systèmes UNIX pendant des années. Windows n’avait pas eu au départ de mode intégré pour modifier le propriétaire d’un objet. Puis l’outil setowner a été intégré dans le Kit de ressources. Ensuite l’outil takeown.exe a été fourni dans Windows NT 4.0, mais cet utilitaire vous permettait seulement d’obtenir la propriété, pas d’accorder celle-ci à d’autres à moins que vous ayez leur mot de passe. Maintenant icacls.exe intègre la possibilité de définir le propriétaire d’objets sur lesquels vous avez l’autorisation de définir le propriétaire :
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Malheureusement, icacls.exe ne peut pas afficher le propriétaire d’un objet. En fait, il n’y a aucun moyen d’afficher, à partir de la ligne de commande, le propriétaire d’un objet. De plus, si vous enregistrez l’ACL pour un objet, il n’enregistre pas le propriétaire de l’objet.
icacls.exe contient un bogue qui empêche d’invoquer SeTakeOwnershipPrivilege pour modifier le propriétaire. Si vous avez le droit de modifier le propriétaire d’un objet basé sur l’ACL, icacls.exe fonctionne correctement. Cependant, si vous êtes administrateur, mais que vous n’êtes pas autorisé à modifier le propriétaire basé sur l’ACL de l’objet, vous ne pouvez pas utiliser icacls.exe pour le faire à cause de ce bogue. Dans ce cas, vous devez utiliser l’outil takeown.exe, qui invoque SeTakeOwnershipPrivilege, mais peut seulement modifier le propriétaire de votre compte ou du groupe Administrateurs, pas d’un compte arbitraire :
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Notez, bien sûr, que l’outil subinacl, qui est téléchargeable à partir du centre de téléchargement Microsoft, possède également un commutateur setowner. Subinacl fonctionne en fait plus intuitivement que icacls dans de nombreux cas, mais il est également beaucoup plus compliqué à utiliser.

Recherche de fichiers pour un utilisateur particulier
Icacls possède une autre fonction utile : il peut trouver des fichiers possédant des autorisations pour des utilisateurs particuliers. Par exemple :
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Cela peut être utile si vous essayez de savoir à quoi un utilisateur particulier pourrait avoir accès.

Réinitialisation et modification des ACL
Si un ACL est corrompu ou détruit, icacls.exe peut le réinitialiser pour hériter de son parent. Cela aurait été extrêmement utile pour une menace sur la sécurité, zero-day, qui a eu lieu à l’automne 2006. L'une des méthodes utilisée pour résoudre le problème dans un composant Windows a été de refuser à tout le monde l’accès à l’objet. Cette partie était facile, mais la suppression de cette entrée de contrôle d’accès (ACE) était pratiquement impossible à l’aide d’outils intégrés dans Windows XP et Windows Server 2003. Cependant, dans Windows Vista, il suffit d’exécuter cette commande :
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe, dispose, bien entendu, de toutes les opérations grant/deny/remove. Le seul nouvel élément dans cette liste est remove. À l’aide de ce commutateur, vous pouvez supprimer tous les ACE d’autorisation, tous les ACE de refus d’accès, ou les deux, pour un utilisateur donné d’un objet ou d’une hiérarchie spécifique. La figure 3 présente des exemples de différentes opérations grant, remove et deny.
Figure 3 Opérations grant, deny et remove (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
La possibilité de supprimer uniquement les ACE de refus d’accès peut être très utile si vous souhaitez ouvrir l’accès d’un objet à un groupe ou un utilisateur particulier.

Configuration de niveaux d’intégrité
Icacls.exe a également la capacité d’afficher et de définir des niveaux d’intégrité. Windows Vista prend en charge l’affichage d’étiquettes d’intégrité sur les objets. Icacls.exe est l’outil de ligne de commande à utiliser pour cela :
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Notez que icacls.exe n’affiche l’étiquette d’intégrité que si un objet est doté d’une étiquette explicitement définie. Ce n’est pas le cas pour la plupart des fichiers, donc il est rare de voir des étiquettes.
Enfin, icacls.exe peut vérifier qu’un objet possède un ACL canonique. Comme mentionné précédemment, les outils tiers sont connus pour placer les ACE dans le desordre dans les ACL. Icacls.exe peut vérifier et réparer ces types de problèmes, comme indiqué ici :
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

Interface utilisateur de l’ACL
L’IU de l’ACL, ou l’interface utilisateur de l’ACL, a été légèrement modifiée par rapport à celle de Windows XP. Les figures 4 et 5 présentent les boîtes de dialogue de l’interface utilisateur de l’ACL de Windows XP et de Windows Vista, respectivement.
Figure 4 Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows XP
Figure 4 Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows XP
Figure 5 Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows Vista
Figure 5 Boîte de dialogue de l’interface utilisateur de l’ACL dans Windows Vista
Comme vous pouvez le voir, quelques modifications ont eu lieu ici. Tout d’abord, la boîte de dialogue affiche très clairement l’objet sur lequel porte l’opération, ce qui peut être utile si vous traitez plusieurs objets à la fois. Deuxièmement, il existe un lien hypertexte vers l’aide en bas. Cependant, le changement le plus notable est la suppression des boutons Ajouter et Supprimer remplacés par le bouton Modifier qui est principalement présent pour la prise en charge du contrôle d’accès d’utilisateur (UAC) dans Windows Vista. Comme vous pouvez le voir par l’icône de protection placée sur le bouton, l’utilisateur qui a lancé cette boîte de dialogue n’a pas l’autorisation de modifier l’ACL et donc nécessitera une élévation avant de pouvoir modifier les autorisations. Notez que cela n’est pas la valeur par défaut si vous créez un dossier dans la racine du lecteur C: et vérifiez tout de suite les propriétés de celui-ci. En tant que propriétaire du dossier, vous auriez des autorisations implicites pour modifier l’ACL et la protection manquerait. La protection représente un nom COM qui est un mécanisme utilisé pour lancer une invite d’élévation pour une partie d’un processus en cours d’exécution. Si vous cliquez sur le bouton Modifier, vous obtenez la boîte de dialogue d’élévation familière, et si dans celle-ci vous cliquez sur Continuer, vous obtenez une boîte de dialogue presque identique à celle qui s’ouvre dans Windows XP en cliquant sur le bouton Ajouter. L’interface utilisateur de l’ACL suit ce concept de double dialogue à plusieurs emplacements. Vous obtenez une boîte de dialogue jusqu’à ce que vous éleviez les privilèges, puis une fois que c’est fait, vous obtenez la boîte de dialogue familière des versions précédentes de Windows.
Si vous cliquez sur le bouton Avancé puis sur l’onglet Audit, vous obtenez toujours un bouton d’élévation, comme illustré à la figure 6. Vous ne pouvez pas modifier l’audit sans élévation, même si vous disposez du contrôle total sur l’objet et que vous êtes le propriétaire. C’est parce que la capacité de modifier un objet SACL est régie par le privilège SE_SECURITY_NAME, nommé « Gérer le journal d’audit et de sécurité » dans les outils d’interface graphique. Seuls les administrateurs possèdent ce droit par défaut. Cependant, le privilège est retiré à un administrateur dans le mode Approbation administrateur (lorsque l’UAC est activé), ce qui nécessite l’élévation même si vous êtes administrateur.
Figure 6 La modification des paramètres d’audit dans Windows Vista nécessite toujours une élévation
Figure 6 La modification des paramètres d’audit dans Windows Vista nécessite toujours une élévation
Une remarque finale sur la nécessité d’élévation lorsque vous modifiez les ACL : toutes ces stratégies sont déterminées par le fait que vous n’avez pas désactivé l’UAC. Si vous désactivez l’UAC, tous les comportements reviennent à ceux de Windows XP, à l’exception des boîtes de dialogue qui paraissent différentes. Cependant, aucune élévation ne sera nécessaire si vous ouvrez une session en tant qu’administrateur, puisque maintenant le SID des administrateurs sera toujours présent dans le jeton.

Autres outils
Icacls.exe est un outil très utile et constitue une amélioration majeure par rapport à cacls.exe, mais il possède encore des défauts. Le plus notable est sans doute qu’il ne peut pas gérer l’accès aux objets autres que les fichiers et les répertoires. Windows Vista fait peu de modifications aux ACL d’autres objets par rapport à Windows XP, mais il existe encore des occasions où vous souhaitez gérer des ACL dans un service, une clé de registre ou même un objet Active Directory®.
Si vous êtes un fan de lignes de commande, il vous faut pour cela subinacl.exe. Subinacl.exe fait partie des outils de support et est également disponible en tant que téléchargement.
Cependant, je dois vous avertir que subinacl.exe n’est pas facile à utiliser. En effet, il est parfois complètement obscur. Cependant, subinad.exe est un outil incroyablement puissant pour gérer le contrôle d’accès. Chaque administrateur avec pouvoir a besoin de cet outil.

Les ACL de registre
Les ACL de registre ont subi des modifications tout comme les ACL de système de fichiers. Néanmoins, ces modifications sont beaucoup moins importantes que celles apportées au système de fichiers. La différence la plus évidente avec les versions précédentes de Windows est que, en raison de la désapprobation des Utilisateurs avec pouvoir, presque tous les ACE des utilisateurs avec pouvoir ont disparu. Les utilisateurs avec pouvoir ne sont pas censés être plus puissants que les autres utilisateurs. Cela démontre à quel point les ACL sont compliqués, même si tous les ACE pour les Utilisateurs avec pouvoir n’ont pas disparu. Quelques-uns ont malheureusement été oubliés.
Lorsque vous examinez les ACL dans le Registre, vous voyez à certains emplacements un ACE pour un SID RESTREINT. Ce n’est pas nouveau dans Windows Vista, mais c’est un SID intéressant et incompris. Le SID RESTREINT désigne un processus qui présente un jeton restreint. Un jeton restreint est créé en utilisant une fonctionnalité spéciale de l’API CreateRestrictedToken. Ce jeton possède un ou plusieurs SID restreints utilisés dans une vérification d’accès séparée. Imaginons que nous avons un processus s’exécutant avec un jeton limité. Si ce processus tente d’accéder à un objet avec un ACE pour le SID RESTREINT, Windows exécute deux vérifications d’accès. La première est la vérification d’accès normale. La seconde fonctionne exactement comme la première, mais a lieu seulement par rapport aux SID restreints dans le jeton. Les deux vérifications d’accès doivent réussir.
Actuellement, il existe plusieurs ACL qui utilisent le SID RESTREINT, en particulier sur le registre. Une capture d’écran de ce type d’ACL est illustrée à la figure 7.
Figure 7 Les ACL de Registre incluent un ACE pour RESTREINT à plusieurs emplacements
Figure 7 Les ACL de Registre incluent un ACE pour RESTREINT à plusieurs emplacements
En ce moment, peu de processus utilisent la fonctionnalité de jeton restreint, en particulier pour ce qui concerne les SID restreints. Un exemple de processus qui utilise cette fonctionnalité est le processus de service qui héberge le pare-feu Windows, le moteur de filtrage de base et le service de stratégie des diagnostics. Il utilise également un jeton d’écriture restreinte. D’après mes découvertes, seuls neuf services utilisent actuellement des jetons RESTREINTS et d’écriture restreinte dans Windows Vista.
Comme avec les versions précédentes récentes de Windows, concernant les autorisations de registre, il est conseillé de procéder avec prudence. Sauf circonstances exceptionnelles et extrêmement ciblées, ne modifiez pas les autorisations dans le Registre. Compte tenu du modèle compliqué d’héritage et des opérations sensibles exécutées sur le registre, la probabilité de défaillance fatale est particulièrement élevée, si vous modifiez négligemment des ACL dans le registre.

Résumé
Comme avec la plupart des versions de Windows, il existe certaines modifications subtiles pour accéder au contrôle dans Windows Vista. Cependant, contrairement à certaines des autres versions récentes, il existe en fait beaucoup de modifications mineures qui s’ajoutent à une modification assez significative de comportement. L’UAC, en particulier, a nécessité plusieurs modifications, telles que les étiquettes d’intégrité et les modifications apportées à l’interface utilisateur des ACL. De plus, il s’agit historiquement du premier nettoyage majeur des ACL.
D’une manière générale, les ACL par défaut dans Windows sont simplifiés dans Windows Vista, ce qui n’était jamais arrivé auparavant. Comme avec les versions précédentes, cependant, vous devez procéder avec beaucoup de prudence concernant le contrôle d’accès pour en obtenir une compréhension exhaustive. C’est surtout vrai avec les nouvelles versions du système d’exploitation. Espérons que les outils présentés dans cet article faciliteront votre exploration des ACL.

Jesper M. Johansson est ingénieur de sécurité principal, chargé des problèmes de sécurité de logiciel et contribue à l’élaboration de TechNet Magazine. Il est titulaire d’un doctorat en systèmes d’information de gestion et possède plus de 20 ans d’expérience dans le domaine de la sécurité informatique. Cet article est une adaptation du nouveau livre de Roger Grimes et Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).


 Histoires de Bureau: Microsoft Desktop Optimization Pack
Histoires de Bureau
Microsoft Desktop Optimization Pack
Wes Miller
Cette rubrique est basée sur les éléments de version bêta de Microsoft Desktop Optimization Pack. Toutes les informations contenues dans le présent document sont susceptibles d’être modifiées.

Depuis le lancement du programme de licences Software Assurance (SA) il y a plusieurs années, Microsoft a continuellement cherché à ajouter des fonctionnalités à la licence SA pour que les clients y trouvent une valeur croissante dans le temps. En plus d’offrir des mises à niveau pour les produits Microsoft inclus dans la licence, l’entreprise a cherché à offrir
des produits et des technologies (Windows® PE, par exemple, était l’un des premiers) qui peuvent aider une organisation à améliorer son expérience avec Windows, Office et les autres logiciels Microsoft.
Microsoft s’est concentré sur la plupart de ces outils et programmes pour fournir des capacités supplémentaires afin de réduire le coût général de possession de Windows, Office et des autres applications Microsoft comprises dans la couverture de la licence SA d’une organisation.
Microsoft a acquis plusieurs entreprises, en 2006, qui avaient toutes des objectifs semblables : réduire les coûts de possession et de complexité associés à la gestion et la réparation de Windows et des applications Windows. Microsoft a regroupé plusieurs de ces technologies récemment acquises dans une nouvelle offre de produit, disponible en tant que valeur ajoutée pour les clients ayant la licence SA. Les technologies de Softricity, DesktopStandard, AssetMetrix et Winternals Software seront disponibles à partir de l’année prochaine en tant que composants de Microsoft® Desktop Optimization Pack (MDOP). En outre, MDOP comprendra un composant intégré en interne par Microsoft, appelé Microsoft System Center Desktop Error Monitoring.
Quant aux économies, Microsoft estime que MDOP peut aider votre organisation à économiser entre 100 $ et 500 $ par an et par bureau, en fonction des méthodes recommandées que vous mettez en place lorsque vous utilisez MDOP. Des informations supplémentaires sur MDOP sont disponibles en ligne à l’adresse windowsvista.com/optimizeddesktop.

Objectifs de Microsoft Desktop Optimization Pack
Pour résumer, le principal objectif du MDOP est de permettre à Microsoft d’offrir de nouvelles technologies de gestion pour une planification plus facile, au lieu d’être lié aux nouvelles versions du système d’exploitation. D’accord, Microsoft souhaite s’assurer que la durée qui s’est écoulée entre la sortie de Windows XP et de Windows Vista™ ne se reproduise pas. Mais en offrant des outils avec un calendrier prévisible entre les versions, MDOP permet à Microsoft de répondre aux besoins de ses utilisateurs de manière flexible et ainsi aux clients d’entreprise d’optimiser la valeur de leurs investissements logiciels.
Pour aider les entreprises à devenir plus performantes, Microsoft a recherché une stratégie permettant d’aider les clients à passer à une infrastructure plus dynamique. Par dynamique, j’entends la manière dont Microsoft définit l’initiative DSI (Dynamic Systems Initiative). Pour des informations supplémentaires sur DSI, lisez les informations disponibles à l’adresse microsoft.com/business/dsi.
Mais j’ai assez parlé de la stratégie de haut niveau. Jetons maintenant un coup d’œil sur chacune des cinq technologies incluses dans MDOP :
  • Virtualisation d’applications SoftGrid
  • Service d’inventaire des actifs
  • Jeu d’outils de récupération et de diagnostic
  • Gestion de stratégie de groupe avancée
  • Microsoft System Center Desktop Error Monitoring

Virtualisation d’applications SoftGrid
La virtualisation d’applications SoftGrid, achetée à Softricity, offre, comme son nom implique, la virtualisation d’applications. Lorsque j’ai commencé à me plonger dans SoftGrid, j’ai réalisé qu’il s’agissait de l’application de publication que Windows 2000 IntelliMirror® aurait dû être. Pourquoi ? Parce que les applications ne sont pas diffusées aux clients, elles sont entièrement virtualisées ; ainsi les applications sont autorisées à être mises à disposition facilement sur les systèmes clients (ou Terminal Server). Tout aussi important, les applications peuvent être gérées de manière centralisée et même rappelées ou mises à jour si nécessaire. Comparé au modèle traditionnel de MSI et aux transformations, le modèle SoftGrid rend le déploiement des applications de manière significative moins pénible et moins risqué.
Une manière d’envisager SoftGrid consiste à l’associer à une image virtuelle. Vous connaissez peut-être le concept d’une image de disque utilisée pour déployer Windows (et souvent les applications à l’intérieur) vers des systèmes. En gros, SoftGrid prend l’application et en fait une copie dans une image d’application, plutôt que dans une image de la totalité du système d’exploitation.
La virtualisation d’applications SoftGrid comprend trois composants clés : la virtualisation d’applications, la livraison d’applications et la console d’administration centrale.
La virtualisation d’applications est elle-même composée de représentations virtuelles du système de fichiers Windows (y compris les fichiers de système), du registre de Windows, des polices, des fichiers .ini, des objets COM/DCOM, des services, des objets noyau (sémaphores, mutex), des objets nommés et des espaces de noms de tous les composants.
Il est important que vous ne confondiez pas la virtualisation SoftGrid avec la manière dont le contrôle de compte d’utilisateur de Windows Vista exécute la redirection. Avec le contrôle de compte d’utilisateur, lorsqu’une application tente d’écrire à ou de modifier des zones protégées du registre ou du système de fichiers, elle est redirigée vers un affichage utilisateur du registre et du système de fichiers. En revanche, SoftGrid utilise un concept de véritable virtualisation de l’application vers le système d’exploitation (y compris tous les composants du système de fichiers et de registre qui le compose). Mais l’élégance de SoftGrid est qu’il ne s’agit pas d’une simple tache qui définit une application. À la place, il se compose :
  • d’un fichier SFT de 4 Go maximum. Il contient une ou plusieurs applications et toutes leurs dépendances sauf les dépendances Windows, qui sont attendues sur les systèmes de destination.
  • d’un fichier OSD d’environ 2 Ko. Il contient une définition sur la manière dont l’application peut être demandée et exécutée. Vous pouvez penser au fichier OSD en tant qu’un fichier EXE.
  • d’un fichier ICO d’environ 24 Ko. Il s’agit en fait d’un raccourci pour lancer l’application.
  • d’un fichier SPRJ d’environ 13 Ko. Il est utilisé par le séquenceur (noyau de SoftGrid) pour publier, ouvrir, mettre à jour et réparer les packages existants.
Un diagramme complet sur la manière dont la virtualisation d’applications SoftGrid fonctionne est disponible sur le site Web softricity.com/ products/architecture.asp.
Avantage important de la solution SoftGrid : il s’agit d’une console d’administration centrale (voir la figure 1) qui peut être utilisée pour déterminer les applications disponibles pour un utilisateur ou un ensemble d’utilisateurs Active Directory® donné. Ces applications peuvent ensuite être rapidement transmises aux utilisateurs à la demande à l’aide d’un protocole de transfert standard. Une fois installées, les applications se comportent comme si elles étaient installées localement. Elles honorent les personnalisations des utilisateurs (même à l’aide des profils des utilisateurs itinérants) et elles fonctionnent même lorsque les clients sont déconnectés du réseau. Les administrateurs peuvent même arrêter la disponibilité des applications, de manière dynamique ou automatique (après un délai défini, par exemple).
Figure 1 Console de gestion SoftGrid
Figure 1 Console de gestion SoftGrid
Surtout, étant donné la manière dont les applications sont déployées, la totalité d’une application n’a pas besoin d’être mise à disposition. À la place, seules les parties nécessaires à l’exécution de l’application utilisée par l’utilisateur sont téléchargées. Imaginez un scénario dans lequel tout Microsoft Office est mis à disposition en tant que package. Si un utilisateur exécute uniquement Word, seuls les composants nécessaires pour son exécution sont téléchargés et non les parties nécessaires à l’exécution d’Excel®, de PowerPoint® et ainsi de suite. Dès que l’utilisateur exécute une de ces applications (Excel, par exemple), les composants associés sont demandés si nécessaire.
Que signifie ERD ?
  • Invite de commande
  • Explorateur
  • Recherche
  • Bloc-notes
  • Assistant de solution
  • Outils d’administration : Autoruns, Gestion des disques, Observateur d’événements, Éditeur du registre, Services et pilotes, Informations système
  • Outils de mise en réseau : Partage de fichiers, Mappage de lecteur réseau, Configuration TCP/IP
  • Outils système : Service d’analyse des incidents, Disk Commander, DiskWipe, FileRestore, Désinstallation de correctifs, Locksmith, Réparation de fichiers système, Restauration du système

Un autre composant de SoftGrid est sa capacité à effectuer la vérification automatique des licences et du contrôle de logiciel. Ceci vous permet de rester en conformité avec votre licence logicielle sans devoir ajouter de logiciels supplémentaires.
La quasi-totalité peut être virtualisée. Les exceptions principales sont Internet Explorer® et les autres composants Windows (y compris les correctifs et les Services Packs), les logiciels antivirus et les pilotes de périphérique. Si vous souhaitez en savoir plus sur le fonctionnement de SoftGrid et explorer son potentiel, je vous recommande de lire le livre blanc disponible à Softricity.com.

Gestion de stratégie de groupe avancée
DesktopStandard s’est fait un nom en développant des outils qui comblent certains des maillons les plus faibles de la stratégie de groupe. En offrant l’outil anciennement appelé GPOVault dans MDOP (et désormais connu sous le nom de gestion des stratégies de groupe avancée), Microsoft a fourni aux clients un superbe outil qui peut entraîner GPO d’un processus puissant (et parfois dangereux) vers un processus beaucoup plus raffiné et contrôlé.
Si vous connaissez les notions fondamentales du logiciel de contrôle source, envisagez la gestion de stratégie de groupe avancée comme le contrôle source pour vos stratégies de groupe Active Directory. (Voir la figure 2 pour une capture d’écran de la console de gestion de stratégie de groupe avancée.) Les administrateurs peuvent vérifier les révisions de stratégie existantes, les modifier et les revérifier, auditer les résultats à l’aide des rapports console de gestion de stratégie de groupe. Une fois que l’administrateur est satisfait et que l’état de stratégie souhaité a été atteint, il peut valider les modifications et les publier. Tel un bon logiciel de contrôle de source, lorsque quelque chose déraille, les modifications peuvent être rapidement récupérées et restaurées à une révision précédente sans aucune conjecture qui serait survenue dans un tel processus.
Figure 2 Console de gestion de stratégie de groupe avancée
Figure 2 Console de gestion de stratégie de groupe avancée
Autre aspect clé de ce processus : la possibilité de modifier des stratégies hors ligne, plutôt que d’avoir à effectuer les modifications demandées sur tous les systèmes actifs en ligne. Ceci permet de tester les modifications de manière isolée avant que les modifications soient faites sur tout le domaine ou dans l'OU.
Enfin, grâce à un modèle basé sur un rôle, la gestion de stratégie de groupe avancée permet aux modifications de passer par un processus de flux de travail conçu. En créant des rôles (tels qu’éditeur, réviseur et approbateur), une administration peut s’assurer qu’un processus est mis en place et autorisera des modifications d’une manière contrôlée. Ainsi, lorsque l’analyste pense que la modification est prête à être validée, il peut disposer d’un puissant mécanisme de contrôle de modification pour s’assurer que les modifications de GPO ne surviennent pas sans l’approbation appropriée.

Service d’inventaire des actifs
Le Service d’inventaire des actifs (AIS, Asset Inventory Service), composé de technologies obtenues par Microsoft grâce à l’acquisition d’AssetMetrix, est une solution de gestion d’inventaire des actifs puissante. Contrairement aux autres composants de MDOP, AIS utilise un modèle Web hébergé. AIS utilise un très petit espace, un agent de bande passante réduite, qui peut s’exécuter une fois ou à intervalles réguliers, permettant à un administrateur de rechercher des applications dans une base de données (hébergée sur Microsoft) incroyablement vaste de plus de 400 000 applications pour déterminer celles qui sont installées sur les systèmes clients. AIS peut ensuite prendre ces données de restauration et les rapprocher de vos licences achetées, pour s’assurer de la conformité et éviter le gaspillage entraîné par un surstockage de licences.
Au début, certains administrateurs peuvent hésiter avant d’utiliser AIS étant donné qu’il s’agit d’un modèle hébergé hors du pare-feu et qu’il répertorie les systèmes internes des logiciels installés. Mais il est important de comprendre le travail considérable effectué par Microsoft pour s’assurer de la confidentialité organisationnelle, en commençant par la réécriture des composants fondamentaux de l’application qui compose AIS. Il n’y a aucun lien entre les données informatiques individuelles et les données organisationnelles. Microsoft certifiera également la technologie de transfert des données avec une partie tierce pour s’assurer que les clients sont à l’aise avec le modèle utilisé par AIS.

Jeu d’outils de récupération et de diagnostic
Comme vous le savez peut-être (si vous avez déjà lu ma biographie dans ma rubrique ces derniers mois), j’étais membre de Winternals lorsqu’elle a été rachetée par Microsoft. J’étais le responsable de produit pour la plupart des produits Winternals, y compris le Pack de l’administrateur Winternals. Ce Pack correspondait au prédécesseur du jeu d’outils de récupération et de diagnostic de Microsoft (DaRT). Bien que certains des outils faisant précédemment partie du Pack de l’administrateur ne sont pas inclus dans DaRT, les composants clés constituant le produit ERD Commander sont toujours disponibles.
L’objectif de DaRT est de fournir une série d’outils permettant de vous aider à diagnostique les problèmes système (même si un système ne démarre pas correctement). Et vous pouvez souvent réparer ces problèmes hors ligne.
ERD Commander utilise Windows PE pour démarrer un système qui ne démarre pas ou ne démarre pas normalement. Sous une interface utilisateur semblable à l’explorateur Windows personnalisé, un jeu d’outils est disponible. Deux de ces outils, le Service d’analyse des incidents et FileRestore, sont également disponibles pour une utilisation en ligne. Cependant, ceux-ci doivent être installés sur tous les systèmes sur lesquels vous souhaitez les exécuter si vous n’utilisez pas ERD Commander pour le diagnostic ou la récupération hors ligne.
La version DaRT d’ERD Commander est affichée à la figure 3. Une liste des outils inclus dans le composant ERD Commander se trouve dans l’encadré. À l’exception de l’outil Explorer, les cinq premiers outils répertoriés sont les mêmes applications que vous utiliseriez sur une installation Windows normale. Explorer est (tout comme l’application de menu Démarrer à partir de laquelle il est démarré) une version spécialisée (plus petite) développée pour être exécutée sous Windows PE.
Figure 3 ERD Commander
Figure 3 ERD Commander
Autoruns est un outil, dérivé d’un outil Sysinternals portant le même nom, qui vous permet de voir toutes les applications qui sont définies pour démarrer lorsque le système démarre ou qu’un utilisateur ouvre une session. La gestion des disques, l’observateur d’événements, les services et pilotes et les informations système sont des outils qui existent au sein d’une interface utilisateur commune et offrent des expériences comparables aux outils de noms similaires sous Windows. Les services et pilotes sont très utiles étant donné qu’ils peuvent vous aider à obtenir le démarrage d’un système lorsque le système échoue en raison d’un pilote de périphérique ou d’un service qui ne fonctionne pas correctement. Enfin, l’Éditeur du registre Windows est inclus pour que vous puissiez manipuler le registre d’un système hors ligne.
La mise en relation est également disponible sous ERD Commander. Bien que le système soit automatiquement configuré à l’aide de DHCP, vous pouvez définir une adresse IP statique à l’aide de l’applet de configuration TCP/IP. Que vous utilisiez DHCP ou l’adresse IP statique, vous pouvez mapper soit un lecteur réseau et copier les fichiers du ou vers le système interrompu, soit utiliser le partage de fichiers pour transformer le système en un serveur de fichiers afin de pouvoir utiliser un système qui fonctionne pour copier les fichiers du système défaillant.
Enfin, une collection d’outils divers est également incluse. Le Service d’analyse des incidents utilise les outils de débogage pour Windows (qui doivent être téléchargés et installés séparément [ils sont gratuit, mais régulièrement mis à jour]) pour diagnostiquer la cause d’un incident. Vous pouvez soit l’exécuter hors ligne sous ERD Commander si le système ne démarre pas, soit copier un fichier DMP sur un système s’exécutant avec DaRT installé et effectuer le diagnostic à cet endroit. Une fois isolé, si le coupable est un nouveau service ou un lecteur, vous pouvez utiliser les Services et pilotes pour le désactiver et voir si le système revient à un fonctionnement normal.
Disk Commander peut vous aider à récupérer une partition qui a été accidentellement supprimée ou endommagée ainsi qu’un groupe de fichiers ou un répertoire qui a été supprimé. De l’autre côté du spectre, DiskWipe vous permet de terminer un effacement de volume ou de disque compatible DoD. FileRestore vous permet (que vous soyez en ligne ou hors ligne) de récupérer un seul fichier qui pourrait avoir été accidentellement supprimé. Gardez à l’esprit que le type de fichiers et l’activité heure/disque depuis la suppression affecteront la récupérabilité, quelque soit l’outil utilisé.
Si un correctif Windows ou le Service Pack empêche le système de démarrer normalement, vous pouvez utiliser la désinstallation des correctifs pour désinstaller de manière sélective un ou plusieurs correctifs ou Services Packs. Le redémarrage est requis pour terminer le processus, étant donné que Windows ne prend pas en charge la désinstallation d’applications hors ligne complète. Mais il peut souvent vous demander de redémarrer.
Locksmith était un des outils les plus populaires inclus dans le jeu d’outils ERD Commander chez Winternals. Il vous autorise à réinitialiser le mot de passe local de l’utilisateur. Il ne fonctionne pas sur les contrôleurs de domaine et ne peut pas réinitialiser tout mot de passe de l’utilisateur de domaine. Il est généralement utilisé pour réinitialiser le mot de passe de l’administrateur local lorsqu’il a été oublié ou que l’utilisateur a quitté l’organisation. La réparation de fichiers système analysera tous les fichiers de système protégé, les examinera pour voir si certains d’entre eux sont endommagés et les remplacera si nécessaire. La restauration du système, comme son nom l’indique, vous permet de restaurer ou de transférer tout point de restauration de système Windows sur un système Windows XP. (Windows XP avec des points de restauration préexistants est nécessaire pour utiliser cette fonctionnalité.) Je compte parmi ceux qui ont été sauvés par cette fonctionnalité unique.
Les outils de ERD Commander et DaRT peuvent sembler un peu aléatoires, mais ils sont une puissante association d’utilitaires que Winternals a progressivement développés. Je suis certain que vous verrez leurs valeurs et les trouverez utiles lors de vos tâches de récupération et de dépannage.

Microsoft System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) fournit une manière rapide et facile pour toute organisation de centraliser et diagnostiquer les incidents Windows et les applications qui se bloquent. Au lieu d’envoyer les incidents et les rapports de blocage à Microsoft, DEM utilise la stratégie de groupe et le rapport d’erreurs Windows intégré pour envoyer des rapports à un serveur que vous désignez au sein de votre organisation pour les diagnostics (et il ne nécessite pas d’agent de logiciels supplémentaire). Toutes les données de serveur DEM sont enregistrées dans une base de données SQL Server. Vous pouvez donc interroger facilement les données recueillies pour vos propres applications et rapports internes. Ceci vous permet de diagnostiquer des problèmes au sein de votre organisation de manière proactive. À l’aide de ces informations, vous pouvez rendre obligatoire le rapport de tels incidents, découvrir les causes les plus fréquentes d’incidents et de blocages, et vous assurer que les correctifs et applications Windows sont hiérarchisés pour réduire ou éliminer l’arrêt du système.
Vous pouvez également configurer votre serveur DEM pour transférer les résultats vers Microsoft et pour que DEM télécharge automatiquement les dernières données de dépannage pour Microsoft et les applications tierces. Les données supplémentaires peuvent être rassemblées à partir de clients en cas d’incident ou de blocage.

Licence MDOP
La première exigence pour l’octroi de licence MDOP à un client est de disposer d’un accord SA de Microsoft existant. Lorsque vous disposez de ceci, les coûts de licence commencent à 7-10 $ par bureau. Des remises sur le volume et des tarifs éducatifs sont disponibles.
Le MDOP n’est pas disponible en dehors du contexte d’un accord SA, à une exception près : Les clients qui souhaitent utiliser les technologies SoftGrid avec leurs serveurs Terminal Server (voir softricity.com/solutions/sbc.asp) ou SMS (voir softricity.com/products/softgrid-sms.asp) peuvent le faire, et les technologies AssetMetrix seront mises à disposition dans les prochaines versions de SMS et System Center Configuration Manager.

Disponibilité et mises à jour
Les composants initiaux de MDOP sont aujourd’hui disponibles. Les composants sont expédiés comme suit :
  • SoftGrid est disponible chez Microsoft depuis le début de l’année 2007.
  • Microsoft DaRT est disponible depuis mai 2007.
  • Les technologies GPOVault devraient être disponibles en juillet 2007.
  • Desktop Error Monitoring devrait être disponible dans MDOP en juillet 2007.
  • Les technologies AssetMetrix devraient être disponibles dans la version bêta en juillet 2007 et seront disponibles dans la version du mois d’août.
  • Une mise à jour des composants DaRT est planifiée pour la fin 2007, dont l’amélioration principale sera la compatibilité avec Windows Vista.
Les versions futures de MDOP fourniront des améliorations, des mises à niveau et de nouvelles fonctionnalités deux fois par an.

Directions pour MDOP
Comme mentionné, les composants clés de technologies AssetMetrix seront intégrés aux versions futures de System Center Configuration Manager. En fait, vous pouvez prévoir que progressivement, à mesure que Microsoft développe la fonctionnalité MDOP, le déploiement, la gestion et les technologies de configuration Microsoft de base seront petit à petit inclus. Les nouvelles technologies (certaines créées par Microsoft, d’autres acquises d’autres entreprises), seront ensuite mises à disposition dans les versions futures de MDOP. En gros, MDOP sera un package évolutif de technologies de configuration et de gestion de pointe.

Wes Miller est responsable du développement chez Pluck à Austin, au Texas. Auparavant, il a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.
J’aimerais remercier Chad Jones et Gavriella Schuster, responsables de produit de Microsoft Desktop Optimization Pack, pour leur aide à la rédaction de cette rubrique.


 La vie secr&#232;te de Windows: Pouvoirs r&#233;parateurs du mode Sans &#233;chec
La vie secrète de Windows
Pouvoirs réparateurs du mode Sans échec
Raymond Chen

Le mode Sans échec de Windows (également connu comme le mode « oh non quel désordre, merci de réparer ! ») a tout d’abord été développé pour Windows® 95. Son but n’était pas simplement de désactiver les pilotes. Il a également été conçu pour réparer ce qui pouvait être réparé automatiquement.
Par exemple, lorsque vous démarrez en mode Sans échec, l’explorateur Windows vérifie la position de toutes les icônes du bureau, pour s’assurer qu’elles sont toutes visibles parce qu’il est possible de créer un état où une icône peut être placée hors écran.
Pour comprendre de quoi je parle, placez deux icônes sur le bureau, l’une dans l’angle gauche et à l’autre dans l’angle droit. Utilisez les commandes Ctrl+Clic pour sélectionner ces deux icônes. Saisissez ensuite celle située à gauche et faites-la glisser à la droite de l’écran. Lorsque vous effectuez cette opération, la deuxième icône sera également déplacée, conservant le même positionnement relatif à l’icône que vous faites glisser. La deuxième icône se déplace à la droite de l’écran.
Le mode Sans échec permet aux utilisateurs de réparer Windows
Le mode Sans échec permet aux utilisateurs de réparer Windows
Si l’explorateur Windows n’a pas réparé la position des icônes en mode Sans échec, les instructions de dépannage pourraient s’avérer potentiellement plus troublantes qu’utiles :
  1. Démarrez l’ordinateur en mode Sans échec. (OK.)
  2. Double-cliquez sur l’icône Poste de travail. (Euh, je ne vois pas l’icône Poste de travail.)
  3. ...
L’icône Poste de travail est hors écran ou n’est pas disponible. Vous ne pouvez même pas passer à l’étape 2 de la résolution des problèmes.
Nous avons reçu quelques plaintes de personnes disant « vous n’auriez pas dû réparer les icônes automatiquement. Si un utilisateur appelle le support technique avec un problème, il suffit à l’ingénieur du support d’indiquer à l’utilisateur de cliquer avec le bouton droit de la souris sur le bureau et de sélectionner l’option Reset Icon Positions. Mission accomplie et le mode Sans échec n’a pas mis la pagaille dans mes icônes ».
Tout d’abord, vous avez déjà perdu lorsque vous dites « si un utilisateur appelle le support technique avec un problème ». Si un utilisateur doit prendre son téléphone, vous avez échoué.
De plus, cette proposition passe à côté de la psychologie du mode Sans échec. Les utilisateurs démarrent en mode Sans échec lorsque l’ordinateur ne fonctionne pas correctement, bien qu’ils ne sachent pas nécessairement ce qu’ils vont devoir faire une fois ce mode activé. Ce qu’ils font vraiment consiste à voir ce qui va se passer. « Il y a un problème, essayons le mode Sans échec ». Dans Windows 95, nous avons utilisé cette psychologie à notre avantage en implémentant divers types d’actions de réparations automatiques en mode Sans échec. Ca a plutôt bien fonctionné.
De plus, si les utilisateurs appellent et que vous leur dites « Le redémarrage en mode Sans échec permet de résoudre votre problème, » ils vont se dire « la résolution était assez facile. J’aurais dû y penser. »
Mais si vous leur donnez une série d’instructions plus longue, en leur disant « Démarrez en mode Sans échec, cliquez avec le bouton droit ici, sélectionnez cette option de menu, puis cliquez sur cette case », les utilisateurs suivront les instructions et le problème sera réparé, mais cela ne les mettra pas en confiance avec les ordinateurs. Ils se sentiront plutôt fragilisés et découragés. Au lieu de mettre le pouvoir en leurs mains, les utilisateurs se sentent vraiment impuissants. « Je n’aurais jamais pu résoudre ce problème tout seul. Les ordinateurs sont trop durs à utiliser. ».

Raymond Chen, The Old New Thing, et son livre portant le même titre (Addison-Wesley, 2007) traitent de l’historique de Windows et de la programmation Win32. Il préfère se faire la belle avant l’arrivée de problèmes !