Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Transport-2007’ Category

Exchange 2007 : Inbound authentication failed with error IllegalMessage for Receive connector.

Posted by Teruin laurent le avril 3, 2012


Un petit cas Exchange 2007 à ce jour entre deux serveurs Exchange 2007

Inbound authentication failed with error IllegalMessage for Receive connector Default MYEXSERVER.The authentication mechanism is ExchangeAuth. The source IP address of the client who tried to authenticate to Microsoft Exchange is [172.16.18.126].

 

En regardant les SPN nous pouvons voir que tout est correct

Registered ServicePrincipalNames for CN=MYEXSERVER,OU=Domain Controllers,DC=UNIFIEDIT,DC=local:

    POP3/MYEXSERVER

    POP3/MYEXSERVER.unifiedit.local

    exchangeMDB/MYEXSERVER.unifiedit.local

    exchangeMDB/MYEXSERVER

    exchangeRFR/MYEXSERVER.unifiedit.local

    exchangeRFR/MYEXSERVER

    SMTP/MYEXSERVER

    SMTP/MYEXSERVER.unifiedit.local

    SmtpSvc/MYEXSERVER

    SmtpSvc/MYEXSERVER.unifiedit.local

    exchangeAB/MYEXSERVER

    exchangeAB/MYEXSERVER.unifiedit.local

    ldap/MYEXSERVER.unifiedit.local/ForestDnsZones.unifiedit.local

    ldap/MYEXSERVER.unifiedit.local/DomainDnsZones.unifiedit.local

    DNS/MYEXSERVER.unifiedit.local

    NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/MYEXSERVER.unifiedit.local

    GC/MYEXSERVER.unifiedit.local/unifiedit.local

    HOST/MYEXSERVER.unifiedit.local/unifiedit.local

    HOST/MYEXSERVER.unifiedit.local/UNIFIEDIT

    ldap/1d6d7ff2-b3a3-45c1-b737-41788d0d59b6._msdcs.unifiedit.local

    ldap/MYEXSERVER.unifiedit.local/UNIFIEDIT

    ldap/MYEXSERVER

    ldap/MYEXSERVER.unifiedit.local

    ldap/MYEXSERVER.unifiedit.local/unifiedit.local

    E3514235-4B06-11D1-AB04-00C04FC2DCD2/1d6d7ff2-b3a3-45c1-b737-41788d0d59b6/unifiedit.local

    WSMAN/MYEXSERVER.unifiedit.local

    WSMAN/MYEXSERVER

    HOST/MYEXSERVER

    HOST/MYEXSERVER.unifiedit.local

 

En modifiant les clefs de registre suivantes

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
  2. Dans le menu Edition, pointez sur Nouveau et cliquez sur Valeur DWORD.
  3. Dans le volet de détails, entrer la nouvelle valeur LogLevel et appuyez sur entrée.
  4. Cliquez avec le bouton droit sur LogLevel, puis cliquez sur Modifier.
  5. Dans la boîte de dialogue Modifier la valeur DWORD, sous base, cliquez sur décimale.
  6. Dans la zone données de la valeur, tapez la valeur 1, puis cliquez sur OK.
  7. Fermez l’Éditeur du Registre.

Puis en redemarrant le service KDC nous avons obtenu l’erreur suivante

Event Type:       Warning

Event Source:   KDC

Event Category:               None

Event ID:             20

Date:                    4/3/2012

Time:                    9:56:00 AM

User:                    N/A

Computer:         MYEXSERVER

Description:

The currently selected KDC certificate was once valid, but now is invalid and no suitable replacement was found.  Smartcard logon may not function correctly if this problem is not remedied.  Have the system administrator check on the state of the domain’s public key infrastructure.  The chain status is in the error data.

Puis

Event Type:       Error

Event Source:   Kerberos

Event Category:               None

Event ID:             3

Date:                    4/3/2012

Time:                    9:57:21 AM

User:                    N/A

Computer:         MYEXSERVER

Description:

A Kerberos Error Message was received:

         on logon session

 Client Time:

 Server Time: 7:57:21.0000 4/3/2012 Z

Error Code: 0xd KDC_ERR_BADOPTION

Extended Error: 0xc00000bb KLIN(0)

Client Realm:

 Client Name:

 Server Realm: UNIFIEDIT.LOCAL

Server Name: host/MyExServer.unifiedit.local

Target Name: host/MyExServer.unifiedit.local@UNIFIEDIT.LOCAL

Error Text:

 File: 9

Line: b22

Error Data is in record data.

 

 

En purgeant les tickets Kerberos et en redémarrant les services KDC de part et d’autre le problème a été résolu.

 

 

Documents additionnels

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21820

Cordialement

Laurent Teruin

 

 


Posted in Exchange Server 2007, Transport-2007 | Leave a Comment »

Exchange 2010/2007 Supprimer les entêtes SMTP internes indiscrètes

Posted by Teruin laurent le janvier 19, 2011


(How to remove Received  Headers )

 

Bonjour

Si vous envoyez un message depuis un serveur de transport Exchange 2007/2010 vous vous apercevrez que les entêtes de messages SMTP divulguent un certain nombre de renseignements sur votre réseau interne.
L’exemple suivant donne un aperçu de ce qui est communiqué.

Received: from dtxvttr-exs-01.unified.fr (93.103.118.42) by
aubvitexs05.unifiedit.fr (10.253.0.13) with Microsoft SMTP Server (TLS) id
8.2.213.0; Thu, 13 Jan 2011 16:27:14 +0100
Received: from MyHub1.myactiveDirecory.local(196.102.15.97) by
mail.unifiedit.fr (92.104.117.42) with Microsoft SMTP Server (TLS) id
8.2.255.0; Thu, 13 Jan 2011 16:27:14 +0100
Received: from MailboxS1.myactiveDirectory.local ([172.23.49.1]) by
MyHub2.myactiveDirectory.local ([173.22.49.1]) with mapi; Thu, 13 Jan 2011
16:27:12 +0100

Pour éviter cela exécuter la commande

Get-SendConnector "Nomdevotresendconnector" | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

N’essayez pas d’utiliser les règles de transport pour effectuer cette opération. Cela ne fonctionnera pas si vous utilisez des serveurs Hub pour envoyer directement des messages vers Internet.

Cordialement
Laurent Teruin

Posted in 1-EXCHANGE 2010, EXCHANGE 2007, Transport-2007, Transport-2010 | Leave a Comment »

Exchange 2010/2007 : Création d’une règle de transport :

Posted by Teruin laurent le août 19, 2010


Comme bon nombre d’entre vous le savent les règles de transport peuvent être d’un grand secours pour réacheminer des flux de messagerie. Dans ce petit article nous allons créer une simple règle de transport qui permettra le réacheminement d’un flux de messagerie vers une autre adresse email entre deux boites autres lettres une hébergée sur Exchange 2007 une autre sur Exchange 2010

Dans l’environnement Exchange 2007 la création des règles de transport est relativement simple. Dans 2010 la commande new-transportrule
a pris un peu d’embonpoint comme nous le verrons par la suite

 

Création d’une règle de transport en environnement 2007.

 

Identifier la commande powershell

La commande Powershell qui est nécessaire à la création de la règle de transport est la suivante :

New-TransportRule -Name <String> -Actions <TransportRuleAction[]> [-Comments <String>] [-Conditions <TransportRulePredicate[]>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-Enabled <$true | $false>] [-Exceptions <TransportRulePredicate[]>] [-Priority <Int32>] [-TemplateInstance <PSObject>] [-WhatIf [<SwitchParameter>]]

 

Identifier les conditions de déclenchement de la régle.

Dans Exchange 2007 ont parle de Predicats. Ce sont en fait les conditions et valeurs que l’on doit spécifier pour que la régle se déclenche. Les prédicats sont nombreux et obeissent a des régles de syntaxes précises. la définition du prédicat est donné par le technet

« Les prédicats donnent pour instruction à une condition ou à une exception d’examiner un élément spécifique d’un message électronique afin de déterminer si la règle de transport s’applique. Certains prédicats examinent les champs À ou De d’un message, tandis que d’autres examinent l’objet, le corps ou la taille de la pièce jointe. Pour déterminer si une règle de transport doit s’appliquer à un message, la plupart des prédicats requièrent la spécification d’une valeur à l’aide de laquelle les prédicats testent le message. Ces valeurs sont attribuées à une ou plusieurs propriétés de prédicat. Certains prédicats ne nécessitent pas de propriété de prédicat. »

Il faudra donc trouver le bon predicat la bonne syntaxe de ce dernier et indiquez les valeurs qui doivent être testées. Attention certains prédicats sont pris en charge sur des serveurs de transport d’autre sur des serveurs Edge.

La commande Get-TransportRulePredicate [-Name <String>] vous donnera la liste des prédicats utilisables.

Cependant vous obtiendrez de plus amples renseignement en tapant le nom de votre prédicat suivit de | FL comme le montre l’écran suivant

 

Dans notre cas c’est le prédicat idéal car nous voulons faire une régle qui effectue un traitement sauf si : le message vient de la personne qui est censé recevoir.

La premiére etape est donc de déclarer la condition

Pour connaitre les conditions possibles utilisez la commande : Get-transportRulePredicate

 

Pour connaitre les paramétres utiliser la commande Get-transportRulePredicate –name « nomdupredicat » | fl

 

La seconde étape est de déclarer l’exception . Pour connaitre les exceptions possible utiliser également la commande : Get-transportRulePredicate

La troisieme étape est de déclarer l’action a réaliser. Pour cela utiliser la commande Get-transportRuleAction

Pour ce faire nous allons utiliser des variables dans lesquelles nous allons stocker , les conditions, les execptions, et les actions

Voici un petit exemple de ce que l’on peut faire

Dans cet exemple on créez un régle qui lorsque ce eric cantona recoit un message celui-ci est discretement envoyé a une boite aux lettres de backup saut si ce message provient de lui-même. Noter que si vous ne spécifiez rien la régle est active par défaut.

Dans notre cas de figure nous avons du utiliser un mail user plutôt qu’un contact. Si vous remplacer le get-mailuser par un get-contact et que votre objet est un contact cela ne fonctionera pas.

Création d’une règle de transport en environnement 2010.

 

Dans l’environnement Exchange 2010 la syntaxe est différente car comme vous pouvez le voir la commande à pris un peu de poid non ?

New-TransportRule -Name <String> [-ADComparisonAttribute <DisplayName | FirstName | Initials | LastName | Office | PhoneNumber | OtherPhoneNumber | Email | Street | POBox | City | State | ZipCode | Country | UserLogonName | HomePhoneNumber | OtherHomePhoneNumber | PagerNumber | MobileNumber | FaxNumber | OtherFaxNumber | Notes | Title | Department | Company | Manager | CustomAttribute1 | CustomAttribute2 | CustomAttribute3 | CustomAttribute4 | CustomAttribute5 | CustomAttribute6 | CustomAttribute7 | CustomAttribute8 | CustomAttribute9 | CustomAttribute10 | CustomAttribute11 | CustomAttribute12 | CustomAttribute13 | CustomAttribute14 | CustomAttribute15>] [-ADComparisonOperator <Equal | NotEqual>] [-AddManagerAsRecipientType <To | Cc | Bcc | Redirect>] [-AddToRecipients <RecipientIdParameter[]>] [-AnyOfCcHeader <RecipientIdParameter[]>] [-AnyOfCcHeaderMemberOf <RecipientIdParameter[]>] [-AnyOfRecipientAddressContainsWords <Word[]>] [-AnyOfRecipientAddressMatchesPatterns <Pattern[]>] [-AnyOfToCcHeader <RecipientIdParameter[]>] [-AnyOfToCcHeaderMemberOf <RecipientIdParameter[]>] [-AnyOfToHeader <RecipientIdParameter[]>] [-AnyOfToHeaderMemberOf <RecipientIdParameter[]>] [-ApplyClassification <String>] [-ApplyHtmlDisclaimerFallbackAction <Wrap | Ignore | Reject>] [-ApplyHtmlDisclaimerLocation <Append | Prepend>] [-ApplyHtmlDisclaimerText <DisclaimerText>] [-ApplyRightsProtectionTemplate <RmsTemplateIdParameter>] [-AttachmentContainsWords <Word[]>] [-AttachmentIsUnsupported <$true | $false>] [-AttachmentMatchesPatterns <Pattern[]>] [-AttachmentNameMatchesPatterns <Pattern[]>] [-AttachmentSizeOver <ByteQuantifiedSize>] [-BetweenMemberOf1 <RecipientIdParameter[]>] [-BetweenMemberOf2 <RecipientIdParameter[]>] [-BlindCopyTo <RecipientIdParameter[]>] [-Comments <String>] [-Confirm [<SwitchParameter>]] [-CopyTo <RecipientIdParameter[]>] [-DeleteMessage <$true | $false>] [-Disconnect <$true | $false>] [-DomainController <Fqdn>] [-Enabled <$true | $false>] [-ExceptIfADComparisonAttribute <DisplayName | FirstName | Initials | LastName | Office | PhoneNumber | OtherPhoneNumber | Email | Street | POBox | City | State | ZipCode | Country | UserLogonName | HomePhoneNumber | OtherHomePhoneNumber | PagerNumber | MobileNumber | FaxNumber | OtherFaxNumber | Notes | Title | Department | Company | Manager | CustomAttribute1 | CustomAttribute2 | CustomAttribute3 | CustomAttribute4 | CustomAttribute5 | CustomAttribute6 | CustomAttribute7 | CustomAttribute8 | CustomAttribute9 | CustomAttribute10 | CustomAttribute11 | CustomAttribute12 | CustomAttribute13 | CustomAttribute14 | CustomAttribute15>] [-ExceptIfADComparisonOperator <Equal | NotEqual>] [-ExceptIfAnyOfCcHeader <RecipientIdParameter[]>] [-ExceptIfAnyOfCcHeaderMemberOf <RecipientIdParameter[]>] [-ExceptIfAnyOfRecipientAddressContainsWords <Word[]>] [-ExceptIfAnyOfRecipientAddressMatchesPatterns <Pattern[]>] [-ExceptIfAnyOfToCcHeader <RecipientIdParameter[]>] [-ExceptIfAnyOfToCcHeaderMemberOf <RecipientIdParameter[]>] [-ExceptIfAnyOfToHeader <RecipientIdParameter[]>] [-ExceptIfAnyOfToHeaderMemberOf <RecipientIdParameter[]>] [-ExceptIfAttachmentContainsWords <Word[]>] [-ExceptIfAttachmentIsUnsupported <$true | $false>] [-ExceptIfAttachmentMatchesPatterns <Pattern[]>] [-ExceptIfAttachmentNameMatchesPatterns <Pattern[]>] [-ExceptIfAttachmentSizeOver <ByteQuantifiedSize>] [-ExceptIfBetweenMemberOf1 <RecipientIdParameter[]>] [-ExceptIfBetweenMemberOf2 <RecipientIdParameter[]>] [-ExceptIfFrom <RecipientIdParameter[]>] [-ExceptIfFromAddressContainsWords <Word[]>] [-ExceptIfFromAddressMatchesPatterns <Pattern[]>] [-ExceptIfFromMemberOf <RecipientIdParameter[]>] [-ExceptIfFromScope <InOrganization | NotInOrganization>] [-ExceptIfHasClassification <String>] [-ExceptIfHasNoClassification <$true | $false>] [-ExceptIfHeaderContainsMessageHeader <HeaderName>] [-ExceptIfHeaderContainsWords <Word[]>] [-ExceptIfHeaderMatchesMessageHeader <HeaderName>] [-ExceptIfHeaderMatchesPatterns <Pattern[]>] [-ExceptIfManagerAddresses <RecipientIdParameter[]>] [-ExceptIfManagerForEvaluatedUser <Sender | Recipient>] [-ExceptIfMessageTypeMatches <OOF | AutoForward | Encrypted | Calendaring | PermissionControlled | Voicemail | Signed | ApprovalRequest | ReadReceipt>] [-ExceptIfRecipientADAttributeContainsWords <Word[]>] [-ExceptIfRecipientADAttributeMatchesPatterns <Pattern[]>] [-ExceptIfRecipientAddressContainsWords <Word[]>] [-ExceptIfRecipientAddressMatchesPatterns <Pattern[]>] [-ExceptIfRecipientInSenderList <Word[]>] [-ExceptIfSCLOver <SclValue>] [-ExceptIfSenderADAttributeContainsWords <Word[]>] [-ExceptIfSenderADAttributeMatchesPatterns <Pattern[]>] [-ExceptIfSenderInRecipientList <Word[]>] [-ExceptIfSenderManagementRelationship <Manager | DirectReport>] [-ExceptIfSentTo <RecipientIdParameter[]>] [-ExceptIfSentToMemberOf <RecipientIdParameter[]>] [-ExceptIfSentToScope <InOrganization | NotInOrganization | ExternalPartner | ExternalNonPartner>] [-ExceptIfSubjectContainsWords <Word[]>] [-ExceptIfSubjectMatchesPatterns <Pattern[]>] [-ExceptIfSubjectOrBodyContainsWords <Word[]>] [-ExceptIfSubjectOrBodyMatchesPatterns <Pattern[]>] [-ExceptIfWithImportance <Low | Normal | High>] [-From <RecipientIdParameter[]>] [-FromAddressContainsWords <Word[]>] [-FromAddressMatchesPatterns <Pattern[]>] [-FromMemberOf <RecipientIdParameter[]>] [-FromScope <InOrganization | NotInOrganization>] [-HasClassification <String>] [-HasNoClassification <$true | $false>] [-HeaderContainsMessageHeader <HeaderName>] [-HeaderContainsWords <Word[]>] [-HeaderMatchesMessageHeader <HeaderName>] [-HeaderMatchesPatterns <Pattern[]>] [-LogEventText <Nullable>] [-ManagerAddresses <RecipientIdParameter[]>] [-ManagerForEvaluatedUser <Sender | Recipient>] [-MessageTypeMatches <OOF | AutoForward | Encrypted | Calendaring | PermissionControlled | Voicemail | Signed | ApprovalRequest | ReadReceipt>] [-ModerateMessageByManager <$true | $false>] [-ModerateMessageByUser <RecipientIdParameter[]>] [-Organization <OrganizationIdParameter>] [-PrependSubject <Nullable>] [-Priority <Int32>] [-Quarantine <$true | $false>] [-RecipientADAttributeContainsWords <Word[]>] [-RecipientADAttributeMatchesPatterns <Pattern[]>] [-RecipientAddressContainsWords <Word[]>] [-RecipientAddressMatchesPatterns <Pattern[]>] [-RecipientInSenderList <Word[]>] [-RedirectMessageTo <RecipientIdParameter[]>] [-RejectMessageEnhancedStatusCode <RejectEnhancedStatus>] [-RejectMessageReasonText <RejectText>] [-RemoveHeader <HeaderName>] [-SCLOver <SclValue>] [-SenderADAttributeContainsWords <Word[]>] [-SenderADAttributeMatchesPatterns <Pattern[]>] [-SenderInRecipientList <Word[]>] [-SenderManagementRelationship <Manager | DirectReport>] [-SentTo <RecipientIdParameter[]>] [-SentToMemberOf <RecipientIdParameter[]>] [-SentToScope <InOrganization | NotInOrganization | ExternalPartner | ExternalNonPartner>] [-SetHeaderName <HeaderName>] [-SetHeaderValue <HeaderValue>] [-SetSCL <SclValue>] [-SmtpRejectMessageRejectStatusCode <Nullable>] [-SmtpRejectMessageRejectText <Nullable>] [-SubjectContainsWords <Word[]>] [-SubjectMatchesPatterns <Pattern[]>] [-SubjectOrBodyContainsWords <Word[]>] [-SubjectOrBodyMatchesPatterns <Pattern[]>] [-WhatIf [<SwitchParameter>]] [-WithImportance <Low | Normal | High>]

 

Pour connaitre les prédicats de conditions la commande n’as pas changée. Cependant la nous pouvons noter quelques critéres supplémentaires….

Cependant malgré cela, la création de la même régle en Exchange 2010 est devenue nettement plus simple comme le montre l’exemple suivant :

De plus lors de création en mode de commande il est possible d’adresser dans le cas du blindcopy des adresses Email externes sans avoir a déclarer un quelquonque object de type mailuser dans l’environnement Exchange 2010 Exemple :

Si vous essayer de faire cela en Exchange 2007 voici ce que cela donne. Pour que cela fonctionne il faut créer un objet de type Mailuser.

Pour plus d’information vous pouvez vous reporter aux liens suivants :

Exchange 2010 New-transportrule : http://technet.microsoft.com/fr-fr/library/bb125138.aspx

Exchange 2007 New-transportrule : http://technet.microsoft.com/fr-fr/library/bb125138(EXCHG.80).aspx

Laurent Teruin

 

 

 

Posted in Transport-2007, Transport-2010 | Leave a Comment »

Exchange 2Kx : Autoriser le relai en mode authentifié : Client does not have permissions to send as this sender ##

Posted by Teruin laurent le août 13, 2010


Autoriser le relay interne et externe en mode ouvert est simple. Sa mise en place est documentée dans l’article http://msexchangeteam.com/archive/2006/12/28/432013.aspx.
Cet article propose de documenter un autre mode de relay qui consiste à mettre en place une autorisation de relai smtp sur un serveur Exchange 2007 qui devra acceptée une connexion smtp authentifié en mode basic. La figure suivante illustre l’environnement à mettre en place :

Permit an open relay is easy. It documented in this article : http://msexchangeteam.com/archive/2006/12/28/432013.aspx. post is just precise how to do the same thing with basic authentication and with a single domain distributed on two different organizations.
The

 

Figure 1 what is needed

 Keep in mind that:

  • Both exchange organizations share the same smtp domain : myorg.com
  • Target local domain use myorg.com as authoritative
  • Source local domain use myorg as InternalRelay


Gardez à l’esprit que :

  • Les deux organisations gèrent le même nom de domaine smtp : myorg.com
  • Le domaine Target.local à positionné le domaine accepté myorg.com en mode authoritative
  • Le domaine source.local à positionné le domaine accepté myorg.com en mode InternalRelay

The Receive connector on the target.local cas server is configured as follow
Le connecteur de réception sur le server CAS du domaine target.local est configure comme ceci.



Figure 2 : Authentication parameters

Le compte utilisé par le connecteur d’envoi dans le domaine cible est un compte utilisateur avec boites aux lettres dans le domaine cible / The account used by the send connector in the source domain is a target domain mailbox user.

Voici la configuration du connecteur d’envoi du domaine source.local
This is the Send Connector configuration from the source.local domain


PREMIER ESSAI /FIRST TRY

 Si vous envoyez un message depuis une boite aux lettres du domaine source, vous allez rapidement recevoir le NDR suivant / If you send a mail from the target organization, you will receive very quickly a NDR who say

Delivery has failed to these recipients or groups:

laurent.teruin@myorg.com (laurent.teruin@myorg.com)
message wasn’t delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.
YourThe following organization rejected your message: TargetCAS.myorg.local.
Diagnostic information for administrators:
Generating server: Ex2K10.source.local

laurent.teruin@myorg.comTargetCAS.myorg.local #550 5.7.1 Client does not have permissions to send as this sender ##

L’aspect positif est que l’authentification fonctionne, le coté négatif est que le message n’est pas remis. The good think is that you authentication is working, the bad is that the message is not delivered

 SOLUTION
Ce comportement est normal car le domaine target.local est en mode authoritative sur le domaine myorg.com/ The behavior is normal because the target domain use the myorg.com as authoritative domain.
Il n’acceptera pas de message provenant d’une source étrangère (les deux exchanges ne sont pas dans la même forêt) quand l’émetteur provient du même domaine / He will not accept messages coming from a foreign source when the sender belong as the same domain. Pour que cela fonctionne vous devez tapez la commande Powershell suivante vers le récepteur de connexion/ To succeed you have to type this Powershell command line.

Get-ReceiveConnector "TARGETCAS\Myreceiveconnector" | Add-ADPermission -User "TARGET\MARIE" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"Une fois effectué votre message sera relayé/ When done your message will be relayed.
Ce qui est à note est que le relay est autorisé vers l’interne et l’externe sans avoir la nécessité de mettre en place l’autorisation ms-Exch-SMTP-Accept-Any-Sender pour le compte utilisé par le connecteur.
What it can be noticed is that relay is permitted to internal and External without the necessity to give the ms-Exch-SMTP-Accept-Any-Sender permission to the account used by the connector.
Les permissions en place sont les suivantes : The current permissions are:

[PS] C:\Documents and Settings\_lteruin>Get-ReceiveConnector "TARGETCAS\

Myreceiveconnector " | Get-ADPermission -user "NT AUTHORITY\ANONYMOUS LOGON"
Identity User Deny Inherited Rights
——– —- —- ——— ——
TargetCAS\MyReceiveConnector NT AUTHORITY\ANON… False True ms-Exch-Store-Create-Named-Properties
TargetCAS\MyReceiveConnector NT AUTHORITY\ANON… False True ms-Exch-Create-Public-Folder
TargetCAS\MyReceiveConnector NT AUTHORITY\ANON… False True GenericRead
TargetCAS\MyReceiveConnector NT AUTHORITY\ANON… False True GenericRead

[PS] C:\Documents and Settings\_lteruin>Get-ReceiveConnector "TARGETCAS\
Myreceiveconnector " | Get-ADPermission -user "TARGET\MARIE"  Identity User Deny Inherited Rights

——– —- —- ——— ——

TargetCAS\MyReceiveConnector TARGET\MARIE False False ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

 Laurent Teruin

Posted in 1-EXCHANGE 2010, EXCHANGE 2007, Transport-2007, Transport-2010 | Tagué: , | Leave a Comment »

Sécurisation des flux Sortants : Mind the Gap (Partie1)

Posted by Teruin laurent le avril 8, 2010


Si la disponibilité des services de messagerie Microsoft Exchange est actuellement complètement résolue par les techniques des groupes de disponibilité et de redondance des services et de données, la fiabilisation des flux en bordure de l’environnement reste encore un point parfois négligé dans la conception d’architecture de messagerie.

De plus en plus, la messagerie est considérée par les utilisateurs comme un moyen extrêmement fiable pour la communication extérieure. Or la signature électronique, et les techniques de sécurisation des messages ne sont pas encore totalement rentrées dans les mœurs. Si la conception d’environnement messagerie n’ayant pas de point de rupture unique est devenue une tendance forte, la réflexion sur la continuité du service de communication s’arrête bien souvent à la bordure Internet.

Paradoxalement, les utilisateurs ont depuis longtemps accordé leurs confiances à ce mode de transmission sans ce soucier des problèmes de sécurisation et d’identification que cela supposais. Peu conscient des risques, la plupart n’hésite pas à communiquer sans précaution particulière des données confidentielles par messageries interposées. D’un autre coté, les équipes techniques considèrent que l’envoi de message en sortie de leurs infrastructures ne relèvent plus de leurs compétences et négligent généralement certains dispositifs de sécurisation qui pourtant sont totalement gratuits et dont la mise en place n’engendrent aucun impact coté utilisateur. Il est bien évident que la sécurisation totale des échanges d’une entreprise vers le reste du monde reste pour l’instant illusoire, malgré tout un effort devrait être porté sur la fiabilisation des flux smtp surtout si il s’agit d’action totalement transparente pour l’utilisateur.

Une des premières questions à se poser, concerne la disponibilité des services de réception et d’envoi des flux de messagerie. Ce sont typiquement dans l’environnement Microsoft Exchange, les services EDGE que l’on trouvera généralement au sein d’une DMZ. Dans certains cas de figure, les services Edge sont utilisés en réception par une publication bien souvent unique d’un seul enregistrement MailXExchanger. Or un des points faibles provient de cette unicité de référencement. L’usage d’un seul MX peut en effet poser problème notamment si ce dernier est identifié comme potentiellement dangereux par les services de « blacklistage » de plus en plus usités sur l’Internet. Ce blacklistage est par ailleurs souvent engendré par des erreurs de configuration autorisant soit le relai ouvert ou partiellement ouvert ou bien la non adéquation du nom externe des passerelles SMTP avec leurs adresses IP natées par les équipements de sécurité. Il est en effet indispensable que l’adresse IP natée utilisée par la passerelle SMTP de sortie corresponde en tout point à l’enregistrement MX publié sur internet. Dans le cas contraire, certaines passerelles effectuant des opérations de recherches inversées refuseront le message via un simple déni de connexion. L’on notera sur ce point que l’effort de conformité doit être particulièrement porté sur la configuration des éléments sortants plutôt que sur les dispositifs de réception, qui en règle générale ne posent que peu de problème.

D’un point de vue pratique, je pense par expérience que l’utilisation de plusieurs MX à un réel intérêt. Le premier consiste à utiliser nativement une technologie de tolérance de panne totalement gratuite et partagée par la quasi-totalité des passerelles SMTP, j’ai nommé les MX. L’intérêt de cette dernière est donc, plutôt que de masquer plusieurs dispositifs d’envoi vers Internet à travers un « nattage unique », de bénéficier de la publication de deux environnements sortants et identifiés comme tel. Je conseillerais par ailleurs un usage sortant, basé sur une mode de fonctionnement de type « tolérance de panne », de façon à ce qu’une seule passerelle émette en même temps. L’intérêt de cette solution est de permettre à l’entreprise en cas de « blacklistage » de pouvoir utiliser la seconde passerelle déclarée sur une deuxième adresse Ip Externe et un deuxième enregistrement MX. De la sorte vous contribuerez à rendre toujours disponible votre environnement et disposerez de temps afin de régler votre problème de référencement incorrect auprès des services de type mailabuse etc..

La figure suivante illustre un environnement possible


 

Dans ce cas de figure les deux passerelles externes seront connues séparément avec leurs deux identités. Pensez à modifier également l’invite des passerelles Smtp pour qu’elle reflète les noms externes. Edgex.unifiedit.com. Vérifier également que le Nat en sortie est correct. Pour ce faire, envoyer un message en interne vers une boite aux lettres Externe et éditer les entêtes de message via Outlook depuis votre boite aux lettres de réception.


Vous devriez apercevoir l’adresse IP avec laquelle votre passerelle se présente. Voir l’exemple ci-dessous :

Received: from smtp1.unifiedit.com (94.2.0.20) by
smtp.itpro.fr (10.64.3.234) with Microsoft SMTP Server (TLS) id
8.1.375.2; Fri, 26 Feb 2010 14:46:52 +0100

Dans le cas contraire, le blacklistage risque d’apparaitre après quelques jours, et certains messages de votre organisation n’arriveront pas à certaine destination. Notamment celles qui possèdent des passerelles SMTP qui effectuent des opérations de vérification basées sur des recherches inverses.

Meilleur encore est l’utilisation des enregistrements Sender Policy Framework au sein de vos DNS qui vont décrire de façon explicite au reste du monde l’organisation de vos flux smtp externes. La mise en place de ces enregistrements déclaratifs va renforcer la confiance des passerelles SMTP de destination et faciliter votre indentification et diminuer votre « SPAM Score » réduisant de facto le risque de mauvaise classification de vos envois. Si vous n’êtes pas familier avec cette technologie, je vous conseille le site élaboré par Microsoft qui vous aidera dans la rédaction de vos enregistrements Dns de type SPF.

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

L’extrait suivant montre l’effet d’une déclaration SPF réussie et approuvée par la passerelle de destination

Received: from dtactr-eexs-01.hotmail.com (92.168.100.10) by
btz-exs-02.hotmail.com (10.64.3.234) with Microsoft SMTP Server (TLS) id
8.1.375.2; Thu, 8 Apr 2010 13:57:35 +0200
Received: from smtp1.unifiedit.com (94.2.0.20) by mail.hotmail.com
(92.168.100.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 8 Apr
2010 13:57:44 +0200
From: Teruin Laurent laurent.teruin@unifiedit.com
To: TERUIN Laurent laurentt@hotmail.com
Date: Thu, 8 Apr 2010 13:57:27 +0200
Subject: RE: Prochaine date d’intervention unifiedit
Thread-Topic: Prochaine date d’intervention unifiedit
Thread-Index: AcrW+VWGOtIZN7AVQJakHmawNNYyEwAGUXWQ
Message-ID: 4499A138EB2B604C862C32F36971A7C001330C85F997@EXCCLUS.unifiedit.local
References: 6ddd1745-074a-4283-849a-e01ef75dbb86@casmac2K01.unifiedit.local
In-Reply-To: 6ddd1745-074a-4283-849a-e01ef75dbb86@casmac2K01.unifiedit.local
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: multipart/alternative;
boundary="_000_4499A138EB2B604C862C32F36971A7C001330C85F997EXCCLUSbour_"
MIME-Version: 1.0
Return-Path: laurent.teruin@unifiedit.com
X-MS-Exchange-Organization-PRD: unifiedit.com
Received-SPF: Pass (dtactr-eexs-01.hotmail.com: domain of laurent.teruin@unifiedit.com designates 94.2.0.20 as permitted sender) receiver=dtactr-eexs-01.hotmail.com; client-ip=94.2.0.20; helo=smtp1.unifiedit.com;
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.8805.535;SV:3.3.8702.1003;SID:SenderIDStatus Pass;OrigIP:94.2.0.20
X-MS-Exchange-Organization-SCL: 0
X-MS-Exchange-Organization-SenderIdResult: PASS

Dans le cas contraire voici ce que vous devriez constatez.

Received-SPF: None (mail1.itpro.fr: Laurent.TERUIN@unifiedit.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SenderIdResult: NONE

Dans le prochain article nous parlons des signatures de domaine à insérer dans vos flux sortants et les quelques outils qui pourront vous servir pour diagnostiquer la facon dont sont percus sur internet vos passerelles smtp.

Bonne soirée
Laurent Teruin

 

Posted in Transport-2007, Transport-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés