Présentation du pare-feu d'en-tête

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

Dans Microsoft Exchange Server 2010, un pare-feu d’en-tête est un mécanisme qui supprime les champs d’en-tête spécifiques de messages entrants et sortants. Les ordinateurs exécutant Exchange 2010 sur lesquels le rôle serveur de transport Hub ou serveur de transport Edge est installé insèrent des champs d’en-tête X personnalisés dans l’en-tête de message. Un en-tête X est un champ d’en-tête défini par l’utilisateur et non officiel qui existe dans l’en-tête de message. Les en-têtes X ne sont pas mentionnés spécifiquement dans RFC 2822, mais l’utilisation d’un champ d’en-tête non défini commençant par X- est devenue une manière reconnue d’ajouter des champs d’en-tête non officiels à un message. Les applications de messagerie, telles que les applications de blocage du courrier indésirable et des virus et les applications de serveur de messagerie, peuvent ajouter leurs propres en-têtes X à un message. Les champs d’en-tête X sont préservés mais ignorés par les serveurs et clients de messagerie qui ne les utilisent pas.

Les champs d’en-tête X contiennent des informations sur les actions exécutées sur le message par le serveur de transport, telles que le seuil de probabilité de courrier indésirable (SCL), les résultats du filtrage du contenu et l’état de traitement des règles. La divulgation de ces informations à des sources non autorisées peut constituer un risque pour la sécurité.

Le pare-feu d’en-tête empêche l’usurpation des en-têtes X en les supprimant des messages provenant de sources non approuvées qui entrent dans l’organisation Exchange. Le pare-feu d’en-tête empêche la divulgation de ces en-têtes X en les supprimant des messages sortants adressés à des destinations non approuvées en dehors de l’organisation Exchange. Le pare-feu d’en-tête empêche également l’usurpation des en-têtes de routage standard utilisés pour suivre l’historique de routage d’un message.

Souhaitez-vous rechercher les tâches de gestion relatives à la gestion des serveurs de transport ? Voir Gestion des serveurs de transport.

Contenu de cette rubrique

En-têtes X d’organisation et en-têtes X de forêt personnalisés utilisés dans Exchange 2010

Pare-feu d’en-tête pour les en-têtes X d’organisation et les en-têtes X de forêt

Pare-feu d’en-tête pour les en-têtes de routage

Pare-feu d’en-tête et versions antérieures d’Exchange

En-têtes X d’organisation et en-têtes X de forêt personnalisés utilisés dans Exchange 2010

Les en-têtes X d’organisation commencent par X-MS-Exchange-Organization-. Les en-têtes X de forêt commencent par X-MS-Exchange-Forest-.

Le tableau suivant décrit certains en-têtes X d’organisation et en-têtes X de forêt utilisés dans les messages au sein d’une organisation Exchange 2010.

Certains en-têtes X d’organisation et en-têtes X de forêt utilisés dans les messages au sein d’une organisation Exchange 2010

Retour au début

Pare-feu d’en-tête pour les en-têtes X d’organisation et les en-têtes X de forêt

Exchange 2010 applique un pare-feu d’en-tête aux en-têtes X d’organisation et de forêt qui existent dans les messages comme suit :

• Des autorisations utilisables pour préserver ou supprimer des en-têtes X spécifiques dans les messages sont attribuées aux connecteurs d’envoi ou de réception.

• Un pare-feu d’en-tête est automatiquement implémenté pour les en-têtes X des messages au cours d’autres types de dépôt de messages.

Procédure d’application d’un pare-feu d’en-tête à des en-têtes X d’organisation et des en-têtes X de forêt dans les messages

Un pare-feu d’en-tête pour les en-têtes X d’organisation et en-têtes X de forêt existant dans les messages entrants est constitué de deux autorisations spécifiques attribuées à un connecteur de réception configuré sur un serveur de transport Hub ou un serveur de transport Edge :

• Si les autorisations sont attribuées au connecteur de réception, aucun pare-feu d’en-tête n’est appliqué au message. Les en-têtes X d’organisation ou de forêt du message sont préservés.

• Si les autorisations ne sont pas appliquées au connecteur de réception, un pare-feu d’en-tête est appliqué au message. Les en-têtes X d’organisation ou de forêt sont supprimés du message.

Le tableau suivant décrit les autorisations de pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt disponibles sur un connecteur de réception.

Autorisations de pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt disponibles sur un connecteur de réception pour les messages entrants

Pour appliquer un pare-feu d’en-tête à des en-têtes X d’organisation et de forêt dans un scénario de connecteur de réception personnalisé, utilisez l’une des méthodes suivantes :

• Créez un connecteur de réception, puis sélectionnez un type d’utilisation autre que Internal. Vous ne pouvez définir le type d’utilisation du connecteur de réception que lors de la création du connecteur. Pour plus d’informations, consultez la rubrique Créer un connecteur de réception SMTP.

• Modifiez un connecteur de réception existant et supprimez le groupe d’autorisations ExchangeServers. Pour plus d’informations, consultez la rubrique Configurer les propriétés du connecteur de réception.

• La cmdlet Remove-ADPermission permet de supprimer l’autorisation Ms-Exch-Accept-Headers-Organization et l’autorisation Ms-Exch-Accept-Headers-Forest d’un principal de sécurité configuré sur le connecteur de réception. Cette méthode ne fonctionne pas si l’autorisation a été attribuée au principal de sécurité à l’aide d’un groupe d’autorisations. Vous ne pouvez pas modifier les autorisations attribuées ou l’appartenance à un groupe d’un groupe d’autorisations. Pour plus d’informations, consultez la rubrique remove-ADPermission.

• La cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Accept-Headers-Organization et l’autorisation Ms-Exch-Accept-Headers-Forest à un principal de sécurité configuré sur le connecteur de réception. Pour plus d’informations, consultez la rubrique add-ADPermission.

Procédure d’application d’un pare-feu d’en-tête à des en-têtes X d’organisation et des en-têtes X de forêt dans les messages sortants

Un pare-feu d’en-tête pour les en-têtes X d’organisation et en-têtes X de forêt existant dans les messages sortants est constitué de deux autorisations spécifiques attribuées à un connecteur d’envoi configuré sur un serveur de transport Hub ou un serveur de transport Edge :

• Si les autorisations sont attribuées au connecteur d’envoi, aucun pare-feu d’en-tête n’est appliqué au message. Les en-têtes X d’organisation ou de forêt du message sont préservés.

• Si les autorisations ne sont pas appliquées au connecteur d’envoi, un pare-feu d’en-tête est appliqué au message. Les en-têtes X d’organisation et de forêt sont supprimés du message.

Le tableau suivant décrit les autorisations de pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt disponibles sur un connecteur d’envoi.

Autorisations de pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt disponibles sur un connecteur d’envoi pour les messages sortants

Pour appliquer un pare-feu d’en-tête à des en-têtes X d’organisation ou de forêt dans un scénario de connecteur d’envoi personnalisé, utilisez l’une des méthodes suivantes :

• Créez un connecteur d’envoi, puis sélectionnez un type d’utilisation autre que Internal ou Partner. Vous ne pouvez définir le type d’utilisation du connecteur d’envoi que lors de la création du connecteur. Pour plus d’informations, consultez la rubrique Créer un connecteur d’envoi SMTP.

• Supprimez du connecteur un principal de sécurité qui attribue les autorisations Ms-Exch-Send-Headers-Organization et Ms-Exch-Send-Headers-Forest. Pour plus d’informations, consultez la rubrique Configurer les propriétés du connecteur d’envoi.

• La cmdlet Remove-ADPermission permet de supprimer l’autorisation Ms-Exch-Send-Headers-Organization et l’autorisation Ms-Exch-Send-Headers-Forest d’un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique remove-ADPermission.

• La cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Send-Headers-Organization et l’autorisation Ms-Exch-Send-Headers-Forest à un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique add-ADPermission.

Procédure d’application d’un pare-feu d’en-tête à des en-têtes X d’organisation et des en-têtes X de forêt d’autres sources de messages

Les messages peuvent entrer dans le pipeline de transport Exchange 2010 sur un serveur de transport Hub ou un serveur de transport Edge sans utiliser de connecteurs d’envoi ou de réception. Un pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est appliqué aux messages provenant de ces autres sources de messages, comme indiqué dans la liste suivante :

• Répertoire de collecte   Le répertoire de collecte est utilisé par les administrateurs ou les applications pour déposer des fichiers de messages. Un pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est toujours appliqué aux fichiers de messages dans le répertoire de collecte. Pour plus d’informations sur le répertoire de collecte, consultez la rubrique Présentation des répertoires de collecte et de relecture.

• Répertoire de relecture   Le répertoire de relecture permet de déposer à nouveau des messages exportés à partir des files d’attente des messages Exchange 2010. Le mode d’application du pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt à ces messages est contrôlé par le champ d’en-tête X-CreatedBy: dans le fichier de message :

  • Si la valeur de ce champ d’en-tête est MSExchange14, aucun pare-feu d’en-tête n’est appliqué au message.

  • Si la valeur de X-CreatedBy: n’est pas MSExchange14, un pare-feu d’en-tête est appliqué.

  • Si le champ d’en-tête X-CreatedBy: n’existe pas dans le fichier de message, un pare-feu d’en-tête est appliqué.

  Pour plus d’informations sur le répertoire de relecture, consultez la rubrique Présentation des répertoires de collecte et de relecture.

• Répertoire de dépôt   Le répertoire de dépôt est utilisé par les connecteurs étrangers sur les serveurs de transport Hub pour envoyer des messages à des serveurs de messagerie qui n’utilisent pas le protocole SMTP pour transférer les messages. Un pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est toujours appliqué aux fichiers de messages avant leur placement dans le répertoire de dépôt. Pour plus d’informations sur les connecteurs étrangers, consultez la rubrique Présentation des connecteurs étrangers.

• Pilote de banque d’informations   Le pilote de banque d’informations sur les serveurs de transport Hub est utilisé pour l’échange de messages sur des serveurs de boîtes aux lettres. Pour les messages sortants créés et déposés à partir de boîtes aux lettres, le pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est toujours appliqué. Pour les messages entrants, le pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est appliqué de façon sélective. Les en-têtes X spécifiés dans la liste ci-après ne sont pas bloqués par le pare-feu d’en-tête pour les messages entrants adressés à des destinataires de boîte aux lettres :

  • X-MS-Exchange-Organization-SCL

  • X-MS-Exchange-Organization-AuthDomain

  • X-MS-Exchange-Organization-AuthMechanism

  • X-MS-Exchange-Organization-AuthSource

  • X-MS-Exchange-Organization-AuthAs

  • X-MS-Exchange-Organization-OriginalArrivalTime

  • X-MS-Exchange-Organization-OriginalSize

  Pour plus d’informations sur le pilote de banque d’informations, consultez la rubrique Présentation du pipeline de transport.

• Messages de notification d’état de remise   Un pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est toujours appliqué au message d’origine ou à l’en-tête de message d’origine associé au message de notification d’état de remise. Pour plus d’informations sur les messages de notification d’état de remise, consultez la rubrique Gestion des notifications d’état de remise.

• Dépôt par des agents   Aucun pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt n’est appliqué aux messages déposés par des agents.

Retour au début

Pare-feu d’en-tête pour les en-têtes de routage

Les en-têtes de routage sont des champs d’en-tête SMTP standard définis dans RFC 2821 et RFC 2822. Les en-têtes de routage marquent un message à l’aide d’informations sur les différents serveurs de messagerie utilisés pour remettre le message au destinataire. Les en-têtes de routage disponibles sont décrits dans la liste ci-après :

• Received:   Une autre instance de ce champ d’en-tête est ajoutée à l’en-tête de message par chaque serveur de messagerie ayant accepté et transmis le message au destinataire. L’en-tête Received: inclut généralement le nom du serveur de messagerie et un horodateur.

• Resent-*:   Les champs d’en-tête Resent sont des champs informatifs qui permettent de déterminer si un message a été transféré par un utilisateur. Les champs d’en-tête Resent disponibles sont les suivants : Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc: et Resent-Message-ID:.

  Les champs Resent sont utilisés de façon à ce que le message apparaisse au destinataire comme s’il était envoyé directement par l’expéditeur d’origine. Le destinataire peut afficher l’en-tête de message pour voir qui a transféré le message.

Les en-têtes de routage insérés dans les messages permettent de représenter sous un faux jour le chemin de routage qu’un message a parcouru pour atteindre un destinataire. Exchange 2010 utilise deux méthodes différentes pour appliquer un pare-feu d’en-tête aux en-têtes de routage existant dans les messages :

• Des autorisations sont attribuées aux connecteurs d’envoi et de réception utilisables pour préserver ou supprimer des en-têtes de routage dans les messages.

• Un pare-feu d’en-tête est automatiquement implémenté pour les en-têtes de routage des messages au cours d’autres types de dépôt de messages.

Procédure d’application d’un pare-feu d’en-tête à des en-têtes de routage dans les messages entrants

Les connecteurs de réception ont l’autorisation Ms-Exch-Accept-Headers-Routing utilisée pour accepter ou rejeter les en-têtes de routage existant dans un message entrant :

• Si cette autorisation est octroyée, tous les en-têtes de routage sont préservés dans le message entrant.

• Si cette autorisation n’est pas octroyée, tous les en-têtes de routage sont supprimés du message entrant.

Le tableau suivant décrit l’application par défaut de l’autorisation Ms-Exch-Accept-Headers-Routing sur un connecteur de réception.

Application par défaut de l’autorisation Ms-Exch-Accept-Headers-Routing sur un connecteur de réception

L’autorisation Ms-Exch-Accept-Headers-Routing est attribuée à tous les types d’utilisation, à l’exception de Custom. Pour appliquer un pare-feu d’en-tête à des en-têtes de routage dans un scénario de connecteur de réception personnalisé, procédez comme suit :

1. Effectuez l’une des actions suivantes :

   • Créez un connecteur de réception, puis sélectionnez le type d’utilisation Custom. N’attribuez pas des groupes d’autorisations au connecteur de réception. Vous ne pouvez pas modifier les autorisations attribuées ou l’appartenance à un groupe d’un groupe d’autorisations.

   • Modifiez un connecteur de réception existant, puis définissez le paramètre PermissionGroups sur la valeur None.

2. La cmdlet Add-ADPermission permet d’ajouter les principaux de sécurité requis sur le connecteur de réception. Assurez-vous que l’autorisation Ms-Exch-Accept-Headers-Routing n’est attribuée à aucun principal de sécurité. Si nécessaire, la cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Accept-Headers-Routing au principal de sécurité que vous voulez configurer pour utiliser le connecteur de réception.

Pour plus d’informations, consultez les rubriques suivantes :

• Créer un connecteur de réception SMTP

• Configurer les propriétés du connecteur de réception

• add-ADPermission

• remove-ADPermission

Procédure d’application d’un pare-feu d’en-tête à des en-têtes de routage dans les messages sortants

Les connecteurs d’envoi ont l’autorisation Ms-Exch-Send-Headers-Routing utilisée pour autoriser ou supprimer les en-têtes de routage existant dans un message sortant :

• Si cette autorisation est octroyée, tous les en-têtes de routage sont préservés dans le message sortant.

• Si cette autorisation n’est pas octroyée, tous les en-têtes de routage sont supprimés du message sortant.

Le tableau suivant décrit l’application par défaut de l’autorisation Ms-Exch-Send-Headers-Routing sur un connecteur d’envoi.

Application par défaut de l’autorisation Ms-Exch-Send-Headers-Routing sur un connecteur d’envoi

L’autorisation Ms-Exch-Send-Headers-Routing est attribuée à tous les types d’utilisation, à l’exception de Custom. Pour appliquer un pare-feu d’en-tête à des en-têtes de routage dans un scénario de connecteur d’envoi personnalisé, utilisez l’une des méthodes suivantes :

• Créez un connecteur d’envoi, puis sélectionnez le type d’utilisation Custom. Vous ne pouvez définir le type d’utilisation du connecteur d’envoi que lors de la création du connecteur. Pour plus d’informations, consultez la rubrique Créer un connecteur d’envoi SMTP.

• Supprimez du connecteur un principal de sécurité qui attribue l’autorisation Ms-Exch-Send-Headers-Routing. Pour plus d’informations, consultez la rubrique Configurer les propriétés du connecteur d’envoi.

• La cmdlet Remove-ADPermission permet de supprimer l’autorisation Ms-Exch-Send-Headers-Routing d’un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique remove-ADPermission.

• La cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Send-Headers-Routing à un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique add-ADPermission.

Procédure d’application d’un pare-feu d’en-tête à des en-têtes de routage d’autres sources de messages

Les messages peuvent entrer dans le pipeline de transport Exchange 2010 sur un serveur de transport Hub ou un serveur de transport Edge sans utiliser de connecteurs d’envoi ou de réception. Un pare-feu d’en-tête pour les en-têtes de routage est appliqué aux autres sources de messages décrites dans la liste suivante :

• Répertoire de collecte   Le répertoire de collecte est utilisé par les administrateurs ou les applications pour déposer des fichiers de messages. Un pare-feu d’en-tête pour les en-têtes de routage est toujours appliqué aux fichiers de messages dans le répertoire de collecte. Pour plus d’informations sur le répertoire de collecte, consultez la rubrique Présentation des répertoires de collecte et de relecture.

• Pilote de banque d’informations   Le pilote de banque d’informations sur les serveurs de transport Hub est utilisé pour l’échange de messages sur des serveurs de boîtes aux lettres. Un pare-feu d’en-tête pour les en-têtes de routage est toujours appliqué aux messages envoyés à partir de boîtes aux lettres sur des serveurs de boîtes aux lettres. Le pare-feu d’en-tête pour les en-têtes de routage n’est pas appliqué aux messages entrants pour la remise à des destinataires de boîtes aux lettres. Pour plus d’informations sur le pilote de banque d’informations, consultez la rubrique Présentation du pipeline de transport.

• Messages de notification d’état de remise   Un pare-feu d’en-tête pour les en-têtes de routage est toujours appliqué au message d’origine ou à l’en-tête de message d’origine associé au message de notification d’état de remise. Pour plus d’informations sur les messages de notification d’état de remise, consultez la rubrique Gestion des notifications d’état de remise.

• Répertoire de relecture, Répertoire de dépôt et Dépôt par des agents   Le pare-feu d’en-tête pour les en-têtes de routage n’est pas appliqué aux messages déposés par le répertoire de relecture, le répertoire de dépôt ou les agents.

Retour au début

Pare-feu d’en-tête et versions antérieures d’Exchange

Exchange 2003 et les versions antérieures d’Exchange n’utilisent pas les en-têtes X d’organisation ou de forêt. Exchange 2010 traite les versions d’Exchange antérieures à Exchange 2007 comme sources de messages non approuvées. Un pare-feu d’en-tête est appliqué à tous les en-têtes X d’organisation et de forêt dans les messages provenant de serveurs exécutant les versions antérieures d’Exchange. Un pare-feu d’en-tête pour les en-têtes X d’organisation et de forêt est également appliqué aux messages remis aux serveurs exécutant les versions antérieures d’Exchange existant au sein de l’organisation Exchange.

Les versions antérieures d’Exchange utilisent le verbe propriétaire X-EXCH50 pour transmettre les informations sur les messages et les destinataires qui ne peuvent pas être incorporées dans le message électronique. Les informations sont transmises en tant qu’objet blob Exch50. L’objet blob Exch50 est un ensemble de données binaires stockées comme un seul objet. Exch50 contient des données telles que le seuil de probabilité de courrier indésirable (SCL), les informations de réécriture d’adresses et d’autres propriétés MAPI qui n’ont pas de représentation MIME. X-EXCH50 étant un verbe ESMTP (Extended Simple Mail Transfer Protocol) propriétaire, les données Exch50 ne peuvent pas être propagées par un serveur sur lequel Exchange n’est pas installé. Pour plus d’informations, consultez la rubrique Exchange 2003 - Planification d’une feuille de route pour la mise à niveau et la coexistence.

Les connecteurs de groupe de routage entre serveurs sur lesquels Exchange 2010 ou Exchange 2003 est installé sont automatiquement configurés pour prendre en charge l’envoi et la réception des données Exch50. Les connecteurs d’envoi et de réception disposent d’autorisations qui activent la commande Exch50.

Le tableau suivant décrit les autorisations qui activent la commande Exch50 sur un connecteur de réception pour les messages entrants. Si l’une de ces autorisations n’est pas accordée alors qu’un message contenant la commande Exch50 est envoyé, le serveur accepte le message, mais n’inclut pas la commande Exch50.

Autorisations qui activent la commande Exch50 sur un connecteur de réception pour les messages entrants

Pour bloquer la commande Exch50 dans un scénario de connecteur de réception personnalisé, utilisez l’une des méthodes suivantes :

• Créez un connecteur de réception, puis sélectionnez un type d’utilisation autre que Internal. Vous ne pouvez définir le type d’utilisation du connecteur de réception que lors de la création du connecteur. Pour plus d’informations, consultez la rubrique Créer un connecteur de réception SMTP.

• Modifiez un connecteur de réception existant et supprimez le groupe d’autorisations ExchangeServers. Pour plus d’informations, consultez la rubrique Configurer les propriétés du connecteur de réception.

• La cmdlet Remove-ADPermission permet de supprimer l’autorisation Ms-Exch-Accept-Exch50 d’un principal de sécurité configuré sur le connecteur de réception. Cette méthode ne fonctionne pas si l’autorisation a été attribuée au principal de sécurité à l’aide d’un groupe d’autorisations. Vous ne pouvez pas modifier les autorisations attribuées ou l’appartenance à un groupe d’un groupe d’autorisations. Pour plus d’informations, consultez la rubrique remove-ADPermission.

• La cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Accept-Exch50 à un principal de sécurité configuré sur le connecteur de réception. Pour plus d’informations, consultez la rubrique add-ADPermission.

Le tableau suivant décrit l’autorisation qui active la commande Exch50 sur un connecteur d’envoi pour les messages sortants. Si cette autorisation n’est pas accordée alors qu’un message contenant la commande Exch50 est envoyé, le serveur envoie le message, mais n’inclut pas la commande Exch50.

Autorisation activant la commande Exch50 sur un connecteur d’envoi pour les messages sortants

Pour bloquer la commande Exch50 dans un scénario de connecteur d’envoi personnalisé, utilisez l’une des méthodes suivantes :

• Créez un connecteur d’envoi, puis sélectionnez un type d’utilisation autre que Internal. Vous ne pouvez définir le type d’utilisation du connecteur d’envoi que lors de la création du connecteur. Pour plus d’informations, consultez la rubrique Créer un connecteur d’envoi SMTP.

• Supprimez du connecteur un principal de sécurité qui attribue l’autorisation Ms-Exch-Send-Exch50.

• La cmdlet Remove-ADPermission permet de supprimer l’autorisation Ms-Exch-Send-Exch50 d’un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique remove-ADPermission.

• La cmdlet Add-ADPermission permet de refuser l’autorisation Ms-Exch-Send-Exch50 à un principal de sécurité configuré sur le connecteur d’envoi. Pour plus d’informations, consultez la rubrique add-ADPermission.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.