Modèle d'autorisations de transport Exchange 2007
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2007-08-27
Cette rubrique fournit des informations détaillées sur le modèle d'autorisations de transport Microsoft Exchange Server 2007. Dans Microsoft Exchange Server 2007, le transport fait référence au processus de transfert de messages d’un serveur à un autre. Lorsque des messages sont transférés entre un serveur de boîtes aux lettres et un serveur de transport Hub, le protocole MAPI est utilisé. Lorsque des messages sont envoyés et reçu entre des serveurs de transport Hub, le protocole SMTP (Simple Mail Transfer Protocol) est utilisé. Chaque session de communication entre les serveurs peut disposer d’une étape d'authentification supplémentaire. Les demandes de connexion peuvent nécessiter des vérifications d’autorisation.
L’authentification est le processus qui essaie d’identifier l’expéditeur d’un message. Si aucune authentification n’est effectuée ou que la tentative d’authentification échoue, l'identité de l'expéditeur est anonyme. L’autorisation est le processus qui détermine si l'utilisateur, le programme ou le périphérique qui se connecte est autorisé à accéder à certaines données, à certaines fonctionnalités ou à certains services. Cet accès dépend de l'action demandée. Le processus d’authentification vérifie l’identité. Le processus d’autorisation détermine le niveau d’accès accordé.
Dans Exchange 2007, les protocoles SMTP et MAPI sont fournis par le service de transport Microsoft Exchange. Dans les sessions utilisant le protocole SMTP ou MAPI, le service de transport Microsoft Exchange utilise le modèle d’autorisation Microsoft Windows pour gérer les permissions d’une session. Dans le contexte de transport dans Exchange 2007, l’autorisation est liée à l’acceptation ou non des différents verbes ou événements de protocole. Par exemple, l’autorisation vérifie les autorisations permettant à l’expéditeur de remettre un message à partir d’une adresse de messagerie donnée ou autorisant une taille de message donnée. Au cours des conversations de protocoles MAPI et SMTP, Exchange 2007 peut effectuer une authentification de session. Une fois qu’une session est authentifiée, les groupes d’autorisations disponibles pour la session peuvent être modifiés à cause de l’authentification. Cela permet aux messages anonymes d’Internet et aux messages envoyés par des utilisateurs authentifiés de l’organisation Exchange d’être traités différemment en raison des différents groupes d'autorisations accordés par l’authentification.
Le comportement par défaut du transport d’un rôle de serveur de transport Edge diffère du comportement par défaut d'un rôle de serveur de transport Hub. Cette différence n'est pas due à une variation de code. Cette différence est causée par une différence dans l'ensemble d'autorisations par défaut pour chaque rôle. Les serveurs Exchange faisant partie de la même forêt Active Directory ont une relation d’approbation. Cette relation d’approbation signifie que les autorisations par défaut configurées pendant l’installation activent un flux de message sécurisé dans la forêt.
La session authentifiée présente un jeton d’accès qui répertorie l’identificateur de sécurité pour chaque groupe auquel l'entité de sécurité d’authentification appartient. La figure 1 illustre la relation entre les appartenances de groupes répertoriées dans le jeton d'accès et les autorisations accordées à ces groupes pour l'objet auquel ils accèdent.
Figure 1 Composants d’autorisation de transport d’Exchange 2007
.gif "Composants d'autorisation de transport Exchange")
Différence entre les sessions authentifiées et les messages authentifiés
Un concept central du modèle de transport d’Exchange 2007 est la différence entre les sessions de transport authentifiées et les messages authentifiés. Un message peut être estampillé avec des métadonnées indiquant qu’il est authentifié ou anonyme. Lorsqu’un serveur est authentifié auprès d’un autre serveur, il peut alors envoyer un message et l’estampiller avec des métadonnées indiquant si le message est authentifié ou anonyme. Le serveur de réception détermine si l'attribut authentifié est approuvé. Si le serveur de réception approuve l’expéditeur, l'attribut authentifié reste intact. Si le serveur de réception n’approuve pas l’expéditeur, il remplace l'attribut authentifié du serveur d'expédition et estampille le message avec des métadonnées indiquant que le message est anonyme. Dans l’organisation Exchange, il se produit un flux de messages internes de bout en bout entre les serveurs approuvant l'attribut de message authentifié. Un serveur de transport Edge recevant des messages depuis Internet n’approuve pas l’attribut authentifié des serveurs anonymes sur Internet. Le serveur de transport Edge estampille donc chaque message avec des métadonnées qui indiquent que le message est anonyme avant qu’il ne soit envoyé à un serveur de transport Hub via une connexion authentifiée.
Fonctionnement du processus d’autorisation et d'authentification de transport de message
Dans Exchange 2007, les mécanismes de base suivants sont disponibles pour authentifier une session SMTP :
Vous pouvez utiliser un compte et un mot de passe Windows dans une session MAPI. Vous pouvez également utiliser l’extension AUTH du SMTP. Cela inclut une authentification de mot de passe en texte brut, une authentification NTLM et une authentification Kerberos.
Vous pouvez utiliser un certificat X.509 à l’aide de l’extension STARTTLS du SMTP. Dans ce scénario, le serveur fournit un certificat dans le cadre de la négociation TLS (Transport Layer Security). Facultativement, le client fournit également un certificat.
Vous pouvez utiliser un mécanisme d’authentification externe. L’authentification externe utilise un mécanisme qui ne fait pas partie d'Exchange, tel qu’un réseau sécurisé physiquement ou IPsec. Cette méthode est utilisée lorsqu’il se produit une communication via des routes IP sur des connecteurs d’envoi et de réception dédiés.
Le serveur de transport d’expédition peut être authentifié auprès du serveur de transport de réception avant que le message ne soit envoyé. Une fois que l’expéditeur est authentifié, le serveur de transport de réception applique ces autorisations au jeton d'accès de la session accordées à cet expéditeur.
Dans Exchange 2007, les connecteurs d’envoi et de réception gèrent le flux de messages. Les connecteurs ont une liste de contrôle d'accès discrétionnaire (DACL) qui définit les autorisations qui sont associées à l’envoi et à la réception de messages. Les autorisations des connecteurs de réception sont plus importantes. La DACL du connecteur de réception détermine les autorisations de l’expéditeur pour les messages envoyés via un connecteur de réception. Une fois qu’une session SMTP est établie avec un connecteur de réception, la session démarre avec un jeton d’accès anonyme pour cette session. Une authentification réussie par la suite modifie le jeton d’accès. Si une session n’est pas authentifiée, les groupes d'autorisations du jeton d’accès restent identiques. Si un session est authentifiée, elle se voit accorder les autorisations assignées au compte ou rôle individuel ou les autorisations assignées à tout groupe de sécurité auquel ce compte appartient.
L’organigramme de la figure 2 illustre l’utilisation par un serveur de transport Exchange 2007 de l’authentification et de l’autorisation dans une session SMTP.
Figure 2 Processus d’authentification et d’autorisation d’une session SMTP
.gif "Organigramme du processus d'authentification de session SMTP")
Configurations de l’authentification
L’ensemble des mécanismes d’authentification configurés pour un connecteur de réception détermine les mécanismes d'authentification disponibles pour utilisation par les sessions qui envoient des messages au connecteur de réception. Le mécanisme d'authentification qui est configuré pour un connecteur d'envoi détermine quel mécanisme d'authentification sera utilisé par le connecteur d’envoi pour s’authentifier auprès d’un hôte actif.
Authentification des connecteurs de réception
Vous pouvez configurer plusieurs mécanismes d'authentification sur un connecteur de réception. Pour un connecteur de réception, le paramètre d'authentification détermine l'ensemble des mécanismes d'authentification activés par le serveur pour authentifier des sessions qui envoient des messages au serveur. Le serveur d’envoi détermine quel mécanisme d’authentification est utilisé.
Le tableau 1 répertorie les mécanismes d’authentification que vous pouvez configurer sur un connecteur de réception. Pour configurer le mécanisme d’authentification du connecteur de réception, utilisez l’onglet Authentification des propriétés du connecteur de réception d’Exchange Management Console ou le paramètre AuthMechanism avec la cmdlet Set-ReceiveConnector d’Exchange Management Shell.
Tableau 1 Mécanismes d’authentification des connecteurs de réception
| Mécanisme d'authentification | Description |
|---|---|
Aucun |
Aucune option d’authentification n’est offerte. |
TLS (Transport Layer Security) |
Le connecteur offre STARTTLS aux clients. |
Authentification intégrée Windows |
Le connecteur offre AUTH plus NTLM GSSAPI aux clients. Le GSSAPI permet aux clients de négocier NTLM ou Kerberos. |
Authentification de base |
Le connecteur offre AUTH plus LOGIN aux clients. Le nom et le mot de passe de l’utilisateur sont reçus en texte clair du client. Ce mécanisme nécessite un compte Windows pour valider les informations d’identification. |
Authentification de base sur TLS |
Il s’agit du modificateur de stratégie pour l’authentification de base. Le connecteur offre AUTH plus LOGIN au client uniquement après que le client a négocié TLS. Ce mécanisme nécessite également que TLS soit défini comme le mécanisme d’authentification. |
Authentification Exchange Server |
Le connecteur offre EXPS plus GSSAPI pour les serveurs Exchange qui exécutent des versions antérieures d’Exchange Server et X-ANONYMOUSTLS aux clients pour les serveurs Exchange 2007. |
Sécurisé de l'extérieur (par exemple, avec IPsec) |
Cette option considère toutes les connexions comme issues d’un autre serveur faisant autorité. |
Authentification des connecteurs d’envoi d’hôte actif
Pour un connecteur d’envoi, le paramètre SmartHostAuthMechanism détermine la manière dont le serveur d’envoi s’authentifie auprès de l’hôte actif cible. SmartHostAuthMechanism ne peut avoir qu’une seule valeur. Si SmartHostAuthMechanism est configuré, l’authentification doit réussir avant que le message ne soit envoyé. Si le mécanisme d’authentification utilisé pour le serveur d’envoi Exchange 2007 n’est pas fourni par l’hôte actif, le serveur n’enverra pas de messages électroniques et la session sera terminée. Si le mécanisme d’authentification utilisé par le serveur d’envoi Exchange 2007 est fourni, mais que l’authentification échoue, le serveur n’enverra également pas de messages électroniques et la session sera terminée.
Le tableau 2 répertorie les mécanismes d’authentification que vous pouvez configurer sur un connecteur d’envoi. Pour configurer le mécanisme d’authentification du connecteur d’envoi, utilisez la boîte de dialogue Configurer l’authentification d’un hôte actif sous l’onglet Réseau des propriétés du connecteur d’envoi d’Exchange Management Console ou le paramètre SmartHostAuthMechanism avec la cmdlet Set-SendConnector d’Exchange Management Shell.
Tableau 2 Mécanismes d’authentification pour les connecteurs d’hôte actif
| Mécanisme d'authentification | Description |
|---|---|
Aucun |
L’accès anonyme est autorisé. |
Authentification de base |
Le connecteur doit utiliser AUTH plus LOGIN. Cela requiert que vous entriez un nom d'utilisateur et un mot de passe. L'authentification de base envoie des informations d'identification en texte clair. Tous les hôtes actifs auprès desquels ce connecteur d'envoi s'authentifie doivent accepter les mêmes nom d'utilisateur et mot de passe. Si le paramètre RequireTLS est également défini sur |
L'authentification de base requiert TLS. |
Il s’agit d’un modificateur de stratégie pour l’authentification de base. Cela nécessite que le connecteur utilise TLS avant d’essayer AUTH. Cela nécessite également que le serveur d’envoi exécute la validation du certificat X.509 du serveur de réception. La validation de certificat inclut la vérification de la liste de révocation de certificats (CRL) et la mise en correspondance de l’identité du serveur avec la liste des hôtes actifs configurés sur le connecteur avant d’essayer AUTH. L’un des noms de domaine complets (FQDN) répertorié comme hôte actif doit être présent dans le certificat du serveur pour que la mise en correspondance des noms réussisse. Par conséquent, si le FQDN de l’hôte actif pointe vers un enregistrement MX, le FQDN d’hôte actif répertorié doit être présent dans le certificat. |
Authentification Exchange Server |
Le connecteur doit utiliser EXPS plus GSSAPI pour les serveurs Exchange qui exécutent des versions antérieures d’Exchange Server ou X-ANONYMOUSTLS pour les serveurs Exchange 2007. |
Sécurisé de l'extérieur (par exemple, avec IPsec) |
La connexion réseau est sécurisée par l'utilisation d'une méthode externe au serveur Exchange. |
TLS (Transport Layer Security)
Le protocole TLS est décrit dans RFC 2246. Il utilise des certificats X.509. Il s’agit d’une forme d’informations d’identification électroniques. Le TLS peut être utilisé comme suit :
Pour confidentialité uniquement.
Pour authentification de serveur avec confidentialité lorsque le certificat de serveur est validé.
Pour authentification mutuelle avec confidentialité lorsque les certificats du client et du serveur sont validés.
Pendant la conversation de protocole SMTP, le client émet la commande SMTP STARTTLS pour demander que TLS soit négocié pour cette session. Le client reçoit un certificat X.509 du serveur dans le cadre de la négociation de protocole TLS. La stratégie d’authentification du client détermine alors si le certificat du serveur de réception doit être validé et si un autre critère doit être appliqué au certificat, tel que la mise en correspondance du nom.
Une partie facultative de la négociation TLS active le serveur de réception pour qu’il demande également un certificat du serveur d’envoi. Si le serveur d’envoi envoie un certificat au serveur de réception, la stratégie locale du serveur de réception détermine la manière dont le certificat est validé et les autorisations qui sont accordées au serveur d’envoi en raison de l’authentification.
Lorsque le TLS est utilisé pour l'authentification du serveur, seul le certificat du serveur de réception est validé. Si le TLS est utilisé pour une authentification mutuelle, le certificat du serveur d’envoi et le certificat du serveur de réception doivent tous deux être validés.
Lorsque le TLS est configuré pour un connecteur de réception Exchange 2007, le serveur doit avoir un certificat X.509. Ce certificat peut être un certificat autosigné ou un certificat signé par une autorité de certification (CA). Le serveur Exchange recherche dans la banque locale un certificat qui correspond au FQDN du connecteur. Le serveur d’envoi sélectionne la manière dont le protocole TLS est utilisé. Lorsqu’Exchange utilise le protocole TLS pour confidentialité uniquement, le client Exchange ne valide pas le certificat. Par exemple, lorsqu’Exchange utilise TLS entre des serveurs de transport Hub utilisant Kerberos via le protocole TLS, il établit un canal confidentiel entre les serveurs et n’exécute aucune validation sur le certificat. L’authentification entre les serveurs a lieu lorsque vous utilisez Kerberos après que le protocole TLS est terminé.
Lorsque l’authentification TLS est requise, Exchange doit valider le certificat. Exchange peut valider le certificat de deux manières : validation de confiance directe ou X.509. Lorsque TLS est utilisé pour la communication du serveur de transport Edge au serveur de transport Hub, Exchange utilise un mécanisme de confiance directe pour valider le certificat.
La confiance directe signifie qu'Exchange utilise une banque approuvée, telle que Active Directory ou Active Directory en mode application (ADAM). La confiance directe signifie également que la présence du certificat dans la banque valide le certificat. Lorsque la confiance directe est utilisée, que le certificat soit autosigné ou signé par une autorité de certification est sans importance. Lorsque vous abonnez un serveur de transport Edge à une organisation Exchange, l'abonnement publie le certificat de serveur de transport Edge dans Active Directory pour validation par les serveurs de transport Hub. Le service Microsoft Exchange EdgeSync met à jour ADAM avec l'ensemble des certificats de serveur de transport Hub pour validation par le serveur de transport Edge.
L’autre méthode utilisée par Exchange pour valider des certificats est la validation X.509. Lorsque la validation X.509 est utilisée, le certificat doit être signé par une autorité de certification. Exchange utilise la validation X.509 lorsqu’il authentifie des hôtes actifs ou qu’il utilise la sécurité de domaine. La sécurité de domaine est expliquée dans la section suivante.
Sécurité de domaine
La sécurité de domaine fait référence à l’ensemble des fonctionnalités d’Exchange 2007 et de Microsoft Office Outlook qui fournissent une alternative à relativement faible coût à S/MIME ou aux autres solutions de sécurité au niveau message. L’objectif de la sécurité de domaine est de fournir aux administrateurs un moyen de gérer les chemins de messages sécurisés sur Internet avec les partenaires commerciaux. Une fois que ces chemins de messages sécurisés sont configurés, les messages ayant voyagé avec succès sur le chemin sécurisé depuis un expéditeur authentifié sont affichés à l’attention de l'utilisateur comme « Domaine sécurisé » dans l'interface Outlook Web Access.
Un connecteur d’envoi vérifie que le domaine cible est dans la liste des domaines d’expéditeurs qui sont configurés pour la sécurité de domaine si les conditions suivantes sont réunies :
Le connecteur d'envoi est configuré pour router les messages en utilisant des enregistrements de ressource de messagerie Exchange (MX) DNS (Domain Name System).
Le connecteur d'envoi est configuré comme sécurisé pour le domaine.
Si le domaine cible se trouve dans la liste, le serveur de transport applique l’authentification TLS mutuelle lors de l’envoi de message au domaine.
Le serveur de réception répond par une commande SMTP QUIT si les conditions suivantes sont réunies :
Exchange ne peut pas négocier TLS.
La validation de certificat de serveur ou la vérification de la liste CRL échoue.
Les messages sont alors dans la file d’attente sur le serveur d'envoi. La file d’attente est dans un état de nouvelle tentative. Ce comportement se produit également lorsque la vérification de nom échoue.
Si le domaine d’un connecteur de réception est sécurisé, le serveur de transport vérifie les messages reçus. Le serveur de transport applique alors l’authentification TLS mutuelle si l’expéditeur est sur la liste des domaines du destinataire configurés pour la sécurité de domaine. Si toutes les vérifications sont réussies, le message reçu est marqué comme « Domaine sécurisé ». Si l'expéditeur ne peut pas négocier de TLS ou si la validation de certificat de serveur ou la vérification de la liste CRL échoue, le serveur de transport rejette le message à l’aide de la commande REJECT du protocole SMTP. Si la vérification de nom échoue, cela résulte également en l’application de la commande REJECT du protocole SMTP. Le serveur Exchange envoie alors un message avec une erreur SMTP temporaire (4xx) au serveur d’envoi. Cela signifie que le serveur d’envoi doit réessayer plus tard. Ce comportement évite les erreurs passagères causées par des échecs temporaires de vérification CRL générant des rapports de non-remise immédiats à l'expéditeur. L’échec ne fait que retarder la remise du message.
Pour plus d'informations, consultez la rubrique Gestion de la sécurité d'un domaine.
Authentification sécurisée de l'extérieur
Vous pouvez sélectionner l’option d’authentification sécurisée de l’extérieur si vous êtes sûr que la connexion réseau entre les serveurs est approuvée. Cette connexion peut être une association IPsec ou un réseau privé virtuel. De la même façon, les serveurs peuvent résider dans un réseau contrôlé physiquement approuvé. Cette configuration est utile dans le cas suivant :
Vous établissez un flux de messages entre un serveur de transport Exchange 2007 et une version antérieure d’Exchange Server ou tout autre serveur SMTP.
Vous ne voulez pas utiliser l’authentification de base.
Les connecteurs Exchange qui sont configurés comme sécurisés de l’extérieur doivent utiliser des connecteurs d’envoi et de réception dédiés parce que toutes les connexions aux connecteurs sont supposées sécurisées. Les connecteurs d'envoi qui sont configurés comme sécurisés de l’extérieur doivent utiliser un hôte actif pour router les messages. De plus, les adresses IP des hôtes actifs cibles doivent être configurés sur le connecteur. Pour les connecteurs de réception qui sont configurés comme sécurisés de l'extérieur, RemoteIPRanges doit être défini sur la plage d’adresses IP des serveurs d’envoi. TLS peut également être combiné avec l’option d’authentification sécurisée de l’extérieur pour améliorer la confidentialité de la session. Vous pouvez effectuer cette opération dans Exchange Management Shell si vous définissez le paramètre RequireTLS des connecteurs sur $True.
Autorisation
Pendant le transport du message, l’autorisation est le processus qui détermine si une action demandée, telle que l’envoi d’un message, est permise pour une session SMTP.
Autorisations de transport Exchange 2007
Les serveurs de transport Exchange 2007 utilisent le modèle d'autorisation Windows pour qu'une session SMTP détermine si l’expéditeur est autorisé à envoyer des messages à un connecteur donné, à un destinataire donné et comme un expéditeur donné, par exemple. Une session SMTP reçoit un ensemble d’autorisations initial (anonyme). Une fois qu’une session est authentifiée, davantage d’autorisations sont disponibles pour la session. Cela modifie l’ensemble des actions autorisées pour la session.
Dans le modèle d’autorisation Windows, les autorisations sont accordées via une interaction de contrôle d'accès qui compare le jeton d'accès à la liste de contrôle d'accès (ACL). Un jeton d’accès répertorie un ensemble d’entités de sécurité. Une entité de sécurité peut être un compte utilisateur, un compte d’ordinateur ou un groupe de sécurité. Chaque entité de sécurité a un identificateur de sécurité (SID) associé. Un jeton d’accès est assigné à chaque session. Les ACL sont définies sur l’objet connecteur dans Active Directory ou ADAM. Une DACL contient un ensemble d’entrées de contrôle d’accès (ACE). Chaque ACE fournit ou refuse une autorisation à une entité de sécurité. Lorsque le serveur de transport vérifie si la session dispose d'une autorisation, telle que l'envoi de message, il appelle une API de contrôle d’accès Windows et fournit le jeton d’accès de la session et la DACL du connecteur comme des paramètres, ainsi que l’autorisation demandée.
Ce processus est identique à la manière dont est déterminée une autorisation de lecture de fichier. Le jeton d’accès, la DACL du fichier et l’autorisation demandée sont soumis à la même API. L’API vérifie chaque entité de sécurité répertoriée dans le jeton d'accès par rapport à chaque ACE de la DACL pour déterminer si l'autorisation demandée est accordée ou refusée. En plus des SID Windows fournis par Active Directory, ADAM ou la base de données du Gestionnaire de comptes de sécurité (SAM) local d’un ordinateur, Exchange 2007 définit des SID supplémentaires. Ces SID représentent des groupes logiques. Le tableau 3 répertorie les SID définis par Exchange 2007 pour une utilisation pendant l’authentification de transport.
Tableau 3 SID Exchange 2007
| Nom complet | SID | Groupe logique |
|---|---|---|
Serveurs partenaires |
S-1-9-1419165041-1139599005-3936102811-1022490595-10 |
Domaines d’expéditeur et de destinataires configurés pour la sécurité de domaine. |
Serveurs de transport Hub |
S-1-9-1419165041-1139599005-3936102811-1022490595-21 |
Serveurs de transport Hub dans la même organisation Exchange. |
Serveurs de transport Edge |
S-1-9-1419165041-1139599005-3936102811-1022490595-22 |
Serveurs de transport Edge approuvés. |
Serveurs sécurisés de l'extérieur |
S-1-9-1419165041-1139599005-3936102811-1022490595-23 |
Serveurs tiers approuvés étant dans le même domaine faisant autorité. |
Serveurs Exchange hérités |
S-1-9-1419165041-1139599005-3936102811-1022490595-24 |
Serveurs Exchange Server 2003 étant dans la même organisation Exchange. |
Autorisations du connecteur de réception
Des connecteurs de réception traitent les sessions entrantes sur le serveur. La session peut être établie par un expéditeur authentifié ou par un expéditeur anonyme. Si une session est authentifiée avec succès, les SID du jeton d'accès de session sont mis à jour. Le tableau 4 répertorie les autorisations qui peuvent être accordées à une session se connectant à un connecteur de réception.
Tableau 4 Autorisations du connecteur de réception
| Autorisation | Nom complet | Description |
|---|---|---|
ms-Exch-SMTP-Submit |
Envoyer des messages au serveur |
La session doit recevoir cette autorisation, sans quoi elle ne peut pas soumettre de messages à ce connecteur de réception. Si une session n'a pas cette autorisation, la commande MAIL FROM échoue. |
ms-Exch-SMTP-Accept-Any-Recipient |
Envoyer des messages à n’importe quel destinataire |
Cette autorisation permet à la session de relayer des messages via ce connecteur. Si cette autorisation n'est pas octroyée, seuls les messages adressés à des destinataires dans des domaines acceptés sont acceptés par ce connecteur. |
ms-Exch-SMTP-Accept-Any-Sender |
Accepter tous les destinataires |
Cette autorisation permet à la session d'ignorer le contrôle d'usurpation d'adresse de l'expéditeur. |
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender |
Accepter un expéditeur de domaine faisant autorité |
Cette autorisation autorise la session à contourner la vérification qui interdit les messages entrants d'adresses électroniques dans les domaines faisant autorité. |
ms-Exch-SMTP-Accept-Authentication-Flag |
Accepter les identificateurs d’authentification |
Cette autorisation autorise les serveurs Exchange qui exécutent des versions antérieures d’Exchange Server à envoyer des messages d'expéditeurs internes. Les serveurs Exchange 2007 reconnaissent le message comme interne. |
ms-Exch-Accept-Headers-Routing |
Accepter les en-têtes de routage |
Cette autorisation permet à la session de soumettre un message dont tous les en-têtes de réception sont intacts. Si cette autorisation n'est pas octroyée, le serveur supprime tous les en-têtes reçus. |
ms-Exch-Accept-Headers-Organization |
Accepter les en-têtes d'organisation |
Cette autorisation permet à la session de soumettre un message dont tous les en-têtes d'organisation sont intacts. Les en-têtes d'organisation commencent tous par « X-MS-Exchange-Organization- ». Si cette autorisation n'est pas octroyée, le serveur de réception supprime tous les en-têtes d'organisation. |
ms-Exch-Accept-Headers-Forest |
Accepter les en-têtes de forêt |
Cette autorisation permet à la session de soumettre un message dont tous les en-têtes de forêt sont intacts. Les en-têtes de forêt commencent tous par « X-MS-Exchange-Forest- ». Si cette autorisation n'est pas octroyée, le serveur de réception supprime tous les en-têtes de forêt. |
ms-Exch-Accept-Exch50 |
Accepter Exch50 |
Cette autorisation permet à la session de soumettre un message contenant la commande XEXCH50. Cette commande est nécessaire pour l'interopérabilité avec Exchange Server 2000 et Exchange 2003. La commande XEXCH50 fournit des données telles que le contrôle d'accès (SCL) pour le message. |
ms-Exch-Bypass-Message-Size-Limit |
Ignorer la limite de taille du message |
Cette autorisation permet à la session de soumettre un message dont la taille dépasse la valeur de restriction de taille de message configurée pour le connecteur. |
Ms-Exch-Bypass-Anti-Spam |
Ignorer le blocage du courrier indésirable |
Cette autorisation permet à la session d'ignorer les filtres du courrier indésirable. |
Autorisations du connecteur d'envoi
Envoyer les connecteurs traiter les sessions entrantes sur un autre serveur. La session peut être établie par l’expéditeur pour un destinataire anonyme ou authentifié. Si la session est authentifiée avec succès, l’ensemble des SID du jeton d’accès de session est mis à jour. Les autorisations de connecteur d’envoi déterminent les types d’informations d’en-tête qui peuvent être incluses dans un message envoyé à l’aide du connecteur. Les messages envoyés à d’autres serveurs Exchange de l’organisation ou à une organisation Exchange approuvée d’un scénario inter-forêts sont généralement autorisés à envoyer tous les en-têtes. Les messages envoyés sur Internet ou à des serveurs SMTP non-Exchange ne sont pas autorisés à contenir tous les en-têtes. Si des en-têtes sont inclus dans le message, la fonctionnalité de pare-feu d'en-tête d'Exchange 2007 supprime ces en-têtes. Le tableau 5 répertorie les autorisations qui peuvent être accordées à une session se connectant à un connecteur d’envoi.
Tableau 5 Autorisations du connecteur d'envoi
| Autorisation | Nom complet | Description |
|---|---|---|
ms-Exch-Send-Exch50 |
Envoyer Exch50 |
Cette autorisation permet à la session d'envoyer un message contenant la commande EXCH50. Si cette autorisation n’est pas accordée, le serveur envoie le message mais n’inclut pas la commande EXCH50. |
Ms-Exch-Send-Headers-Routing |
Envoyer les en-têtes de routage |
Cette autorisation permet à la session d'envoyer un message dont tous les en-têtes de réception sont intacts. Si cette autorisation n'est pas octroyée, le serveur supprime tous les en-têtes reçus. |
Ms-Exch-Send-Headers-Organization |
Envoyer des en-têtes d’organisation |
Cette autorisation permet à la session d'envoyer un message dont tous les en-têtes d'organisation sont intacts. Les en-têtes d'organisation commencent tous par « X-MS-Exchange-Organization- ». Si cette autorisation n'est pas octroyée, le serveur d'envoi supprime tous les en-têtes d'organisation. |
Ms-Exch-Send-Headers-Forest |
Envoyer les en-têtes de forêt |
Cette autorisation permet à la session d'envoyer un message dont tous les en-têtes de forêt sont intacts. Les en-têtes de forêt commencent tous par « X-MS-Exchange-Forest- ». Si cette autorisation n'est pas octroyée, le serveur d'envoi supprime tous les en-têtes de forêt. |
Groupes d'autorisations
Un groupe d'autorisations est un ensemble d'autorisations prédéfinies qui peut être accordé à un connecteur de réception. Des groupes d'autorisations ne sont disponibles que pour des connecteurs de réception. L'utilisation d'un groupe d'autorisations simplifie la configuration des autorisations sur les connecteurs de réception. La propriété PermissionGroups définit les groupes ou les rôles pouvant soumettre des messages au connecteur de réception et les autorisations attribuées à ces groupes. L'ensemble de groupes d'autorisation est prédéfini dans Exchange 2007. Cela signifie que vous ne pouvez pas créer de groupes d'autorisations supplémentaires. Vous ne pouvez pas non plus modifier les membres d'un groupe d'autorisations ou les autorisations associées.
Le tableau 6 répertorie les groupes d’autorisations, les membres de groupes d’autorisations et les autorisations associées qui sont disponibles dans Exchange 2007.
Tableau 6 Groupes d'autorisations du connecteur de réception et autorisations associées
| Nom du groupe d'autorisations | Entités de sécurité | Autorisations accordées sur les serveurs de transport Edge | Autorisations accordées sur les serveurs de transport Hub |
|---|---|---|---|
Anonyme |
Utilisateurs anonymes |
|
|
ExchangeUsers |
Utilisateurs authentifiés (les comptes connus sont exclus) |
Non disponible |
|
Serveurs Exchange |
Serveurs Exchange 2007 |
Toutes les autorisations de réception |
|
ExchangeLegacyServers |
Serveurs Exchange 2003 et Exchange 2000 |
Non disponible |
|
Partenaire |
Compte de serveur partenaire |
|
|
Types d'utilisations du connecteur
Lorsque vous créez un connecteur, vous pouvez spécifier un type d’utilisation. Le type d'utilisation détermine les paramètres par défaut pour le connecteur. Cela comprend les SID authentifiés, les autorisations affectées à ces SID et le mécanisme d’authentification.
Le tableau 7 répertorie les types d’utilisations disponibles pour un connecteur de réception. Lorsque vous sélectionnez un type d’utilisation pour un connecteur de réception, des groupes d’autorisations sont automatiquement affectés au connecteur. Un mécanisme d’authentification par défaut est également configuré.
Tableau 7 Types d'utilisation du connecteur de réception
| Type d'utilisation | Groupes d'autorisations par défaut | Mécanismes d'authentification par défaut |
|---|---|---|
Client |
ExchangeUsers |
|
Personnalisé |
Aucun |
Aucun. |
Interne |
|
Authentification Exchange Server. |
Internet |
AnonymousUsers Partenaire |
Aucun ou sécurisé de l'extérieur. |
Partenaire |
Partenaire |
Non applicable. Ce type d'utilisation est sélectionné lorsque vous établissez une authentification TLS mutuelle avec un domaine distant. |
Le tableau 8 répertorie les types d’utilisations disponibles pour un connecteur d’envoi. Lorsque vous sélectionnez un type d’utilisation pour un connecteur d’envoi, des autorisations sont automatiquement affectées aux SID. Un mécanisme d’authentification par défaut est également configuré.
Tableau 8 Types d'utilisation du connecteur d'envoi
| Type d'utilisation | Autorisations par défaut | Entités de sécurité | Mécanisme d’authentification par défaut pour les hôtes actifs |
|---|---|---|---|
Personnalisé |
Aucun |
Aucun |
Aucun |
Interne |
|
|
Authentification Exchange Server. |
Internet |
Envoyer les en-têtes de routage |
Compte d'utilisateur anonyme |
Aucun. |
Partenaire |
Envoyer les en-têtes de routage |
Serveurs partenaires |
Non applicable. Ce type d'utilisation est sélectionné lorsque vous établissez une authentification TLS mutuelle avec un domaine distant. |
Si vous sélectionnez le type d’utilisation Personnalisé pour un connecteur d’envoi ou de réception, vous devez configurer manuellement la méthode d’authentification et les SID autorisés et affecter des autorisations à ces SID. Si vous ne spécifiez pas de type d’utilisation, le type d’utilisation du connecteur est défini sur Personnalisé.
Définition d’autorisations à l’aide du script Enable-CrossForestConnector
Le script Enable-CrossForestConnector.ps1 permet de simplifier la configuration des autorisations sur les connecteurs inter-forêts. Le script attribue des autorisations d'une manière proche des groupes d'autorisations. Un ensemble d'autorisations défini est affecté à un connecteur d'envoi ou de réception. Vous pouvez modifier cet ensemble d’autorisations comme requis pour votre scénario de connexion en modifiant le contenu du script Enable-CrossForestConnector.ps1 . Pour plus d'informations, consultez la rubrique Configuration des connecteurs inter-forêts.
Définition d'autorisations à l’aide de la cmdlet Add-AdPermission
La cmdlet Add-AdPermission d’Exchange Management Shell est une cmdlet globale utilisée pour affecter des autorisations à des objets stockés dans Active Directory. Vous pouvez utiliser la cmdlet Add-AdPermission pour accorder des autorisations individuelles sur un connecteur d'envoi ou de réception. La cmdlet Add-AdPermission n’est généralement pas utilisée pour gérer les autorisations de transport. Toutefois, elle doit être utilisée pour configurer des permissions dans les scénarios suivants :
Établissement d’un flux de messages dans un scénario inter-forêts.
Acceptation de messages anonymes d’Internet d’un expéditeur dans un domaine faisant autorité.
Les autorisations de transport Exchange 2007 font partie de l’ensemble de droits étendus qui peuvent être affectés lors de l’utilisation de cette cmdlet. La procédure suivante illustre la manière dont vous pouvez utiliser la cmdlet Add-AdPermission pour définir des autorisations sur un connecteur de réception de serveur de transport Hub pour permettre aux sessions anonymes d’envoyer des messages :
Définition d'autorisations sur un connecteur de réception à l'aide d'Exchange Management Shell
Exécutez la commande suivante :
Add-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
Vous pouvez utiliser la cmdlet Get-AdPermission pour afficher la DACL d’un connecteur d'envoi ou de réception. Exécutez l’une des commandes suivantes pour extraire les autorisations affectées à un connecteur de réception et afficher les résultats dans une table mise en forme :
Affichage des autorisations étendues sur un connecteur de réception à l'aide d'Exchange Management Shell
Exécutez une des commandes suivantes :
Get-AdPermission -Identity "Default ServerName" | format-table -view User Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
Vous pouvez utiliser la cmdlet Remove-AdPermission pour supprimer des autorisations précédemment affectées.
Pour plus d'informations sur la définition, l'affichage et la suppression d'autorisations à l'aide d'Exchange Management Shell, consultez les rubriques suivantes :
Définition d'autorisations à l'aide d'ADSI Edit
ADSI (Active Directory Service Interfaces) Edit est une console de gestion Microsoft fournie avec les Outils de support Windows. ADSI est utilisé comme un éditeur de bas niveau pour modifier les propriétés des objets Active Directory ou ADAM qui ne sont pas exposés dans d’autres interfaces de gestion. ADSI Edit ne doit être utilisé que par des administrateurs expérimentés.
ADSI Edit permet d’afficher et de modifier les ACL des connecteurs d’envoi et de réception. Après avoir ouvert ADSI Edit, localisez l’objet connecteur. Les connecteurs Exchange 2007 sont stockés dans la partition de configuration du service d'annuaire. Les connecteurs d'envoi sont stockés comme des objets dans le conteneur Connexions. Les connecteurs de réception sont stockés comme des objets enfants du serveur de transport Exchange 2007.
Pour modifier des autorisations de connecteur de réception à l’aide d’ADSI Edit :
Localisez le connecteur de réception en allant à l’emplacement suivant :
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organisation>\CN=Groupes d’administration\CN=Groupes d’administration Exchange (FYDIBOHF23SPDLT)\CN=Serveurs\CN=<Nom du serveur>\CN=Protocoles\CN=Connecteurs de réception SMTP
Sélectionnez un connecteur de réception dans le volet Résultats. Cliquez avec le bouton droit, puis cliquez sur Propriétés.
Cliquez sur l'onglet Sécurité. L'écran suivant s'affiche :
.gif "Onglet Sécurité du connecteur de réception dans l'éditeur ADSI")
Cliquez sur Ajouter pour sélectionner l’utilisateur ou le groupe auquel les autorisations sont accordées, ou sélectionnez une entrée Groupe ou nom d’utilisateur.
Sélectionnez les autorisations devant être affectées au compte et activez la case à cocher de la colonne Autoriser.
Pour modifier des autorisations de connecteur d’envoi à l’aide d’ADSI Edit :
Localisez le connecteur d’envoi en allant à l’emplacement suivant :
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<Organisation>\CN=Groupes d'administration\CN=Groupes d’administration Exchange (FYDIBOHF23SPDLT)\CN=Groupes de routage\CN=Groupe de routage (DWBGZMFD01QNBJR)\CN=Connexions
Sélectionnez un connecteur d'envoi dans le volet Résultats. Cliquez avec le bouton droit, puis cliquez sur Propriétés.
Cliquez sur l'onglet Sécurité. L'écran suivant s'affiche :
.gif "Onglet Sécurité du connecteur d'envoi dans l'éditeur ADSI")
Cliquez sur Ajouter pour sélectionner l’utilisateur ou le groupe auquel les autorisations sont accordées, ou sélectionnez une entrée Groupe ou nom d’utilisateur.
Sélectionnez les autorisations devant être affectées au compte et activez la case à cocher de la colonne Autoriser.
Autorisations de dépannage
Pendant la conversation de protocole, le serveur SMTP peut rejeter certaines commandes pour cause de manque d’autorisations. Le tableau 9 répertorie les messages communs de rejet de protocole et la configuration d'autorisations qui cause cette erreur.
Tableau 9 Messages communs de rejet de protocole et leurs causes
| Réponse du serveur SMTP | Cause |
|---|---|
530 5.7.1 Le client n’a pas été authentifié |
L’expéditeur spécifié dans le champ MAIL FROM du protocole SMTP n’a pas l’autorisation d'effectuer des envois sur ce serveur. L’autorisation ms-Exch-SMTP-Submit doit être accordée à l’expéditeur. |
535 5.7.3 Échec de l’authentification |
Pendant la phase AUTH de la conversation de protocole SMTP, les informations d’identification fournies étaient incorrectes ou l’utilisateur authentifié n’a pas l’autorisation d’effectuer des envois sur ce serveur. |
550 5.7.1 Le client ne dispose pas de l'autorisation d'envoyer des messages à ce serveur |
L’expéditeur spécifié dans le champ MAIL FROM de la conversation de protocole SMTP a été authentifié mais n’a pas l’autorisation d'effectuer des envois sur ce serveur. |
550 5.7.1 Le client ne dispose pas de l'autorisation d'envoyer des messages à cet expéditeur |
L’expéditeur spécifié dans le champ MAIL FROM de la conversation du protocole SMTP est une adresse est un domaine faisant autorité. Toutefois, la session n’a pas l’autorisation ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. Cela peut arriver si un message a été envoyé à partir d’Internet sur un serveur de transport Edge depuis une adresse d’expéditeur pour laquelle l’organisation Exchange fait autorité. |
550 5.7.1 Le client ne dispose pas des autorisations nécessaires pour envoyer à la place de l'adresse d'expédition. |
L’utilisateur authentifié n’a pas l’autorisation d'envoyer un message de la part de l'expéditeur spécifié dans l'en-tête du message. De plus, la session n’a pas l’autorisation ms-Exch-SMTP-Accept-Any-Sender. |
550 5.7.1. Impossible de remettre le message |
Le domaine de destinataire auquel le message est adressé ne fait pas partie des domaines acceptés définis pour cette organisation. De plus, la session n’a pas l’autorisation ms-Exch-SMTP-Accept-Any-Recipient. |
Pour plus d'informations
Pour plus d'informations, consultez les rubriques suivantes :