Exchange your Mind

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

Archive for the ‘Transport-2010’ Category

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 : Tableaux de flux

Posted by Teruin laurent le octobre 4, 2010


Vous trouverez ci-dessous le tableau des principaux flux de communication entre les serveurs Exchange (rôle de transport et serveurs de boites aux lettres).
Cordialement
Laurent Teruin

 

SERVEURS HUB & EDGE

Haut du formulaire

CheminBas du formulaire

Ports requis

Authentification par défaut

Authentification supportée

Support du cryptage

Crypté par défaut

ROLE

Serveur de transport(Hub) vers Serveur de transport(Hub)

25/TCP (SMTP)

Kerberos

Kerberos

Oui, via Transport Layer Security (TLS)

Oui

HUB

Serveur de transport(Hub) vers Serveur de Transport (Edge)

25/TCP (SMTP)

Direct trust

Direct trust

Oui via TLS

Oui

HUB

Serveur de Transport (Edge) vers Serveur de transport(Hub)

25/TCP (SMTP)

Direct trust

Direct trust

Oui via TLS

Oui

HUB

Serveur de Transport (Edge) vers Serveur de Transport (Edge)

25/TCP SMTP

Anonymes, Certificate

Anonymes, Certificate

Oui via TLS

Oui

HUB

Serveur de boites aux lettres
vers Serveur de transport(Hub) via the Microsoft Exchange Mail Submission Service

135/TCP (RPC)

NTLM. si le serveur Hub et le serveur de boites aux lettres sont sur la même machine alors Kerberos est utilisé.

NTLM/Kerberos

Oui via Encryption RPC

Oui

HUB

Hub Transport vers Serveur de boites aux lettres
via MAPI

135/TCP (RPC)

NTLM. si le serveur Hub et le serveur de boites aux lettres sont sur la même machine alors Kerberos est utilisé.

NTLM/Kerberos

Oui via Encryption RPC

Oui

HUB

Serveur de messagerie Unifiée vers Serveur de transport(Hub)

25/TCP (SMTP)

Kerberos

Kerberos

Oui via TLS

Oui

HUB

Service Microsoft Exchange EdgeSync depuis Serveur de transport(Hub) vers Serveur de Transport (Edge)

50636/TCP (SSL)

Basic

Basic

Oui, via LDAP over SSL (LDAPS)

Oui

HUB

Accès AD depuis Serveur de transport(Hub)

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

HUB

Active DirectoryRights Management Services (AD RMS) vers depuis Serveur de transport(Hub)

443/TCP (HTTPS)

NTLM/Kerberos

NTLM/Kerberos

Oui, via SSL

Oui*

HUB

SMTP clients vers Serveur de transport(Hub) (Utilisateur Outlook express par exemple)

587 (SMTP)

NTLM/Kerberos

NTLM/Kerberos

Oui via TLS

Oui

Bas du formulaire

HUB

25/TCP (SMTP)

  

             

SERVEUR DE BOITES AUX LETTRES

             

Haut du formulaire

Chemin

Bas du formulaire

Ports requis

Authentification par défault

Authentification supportée

Support du cryptage

Crypté par défault

ROLE

Accès Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

MB

Accès Admin remote (Remote Registry)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Accès Admin remote (SMB/File)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Availability Web service (Client vers Mailbox)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Clustering

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via IPsec

Non

MB

Indexation de contenus

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Log shipping

64327 (personalisable)

NTLM/Kerberos

NTLM/Kerberos

Oui

Non

MB

Seeding

64327 (personalisable)

NTLM/Kerberos

NTLM/Kerberos

Oui

Non

MB

Sauvegarde via Volume shadow copy service (VSS)

Local Message Block (SMB)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Assistants de boites aux lettres

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Accès MAPI

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Accès Microsoft Exchange Active Directory Topology service

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Accès Microsoft Exchange System Attendant service legacy (Ecoute de requêtes)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

MB

Microsoft Exchange System Attendant service legacy vers Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

MB

Microsoft Exchange System Attendant service legacy vers (Comme un client MAPI )

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui, via RPC encryption

Oui

MB

Offline address book (OAB) versing Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Oui, via RPC encryption

Oui

MB

Outlook versing OAB

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Oui, via HTTPS

Non

MB

Accès Recipient Update Service RPC

135/TCP (RPC)

Kerberos

Kerberos

Oui, via RPC encryption

Oui

MB

Recipient update vers Active Directory

389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon)

Kerberos

Kerberos

Oui, via Kerberos encryption

Oui

Bas du formulaire

MB

Posted in 1-EXCHANGE 2010, Doc-de-Ref-2010, 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 2010 : Plaidoyer pour les répartiteurs de charges matériels

Posted by Teruin laurent le août 18, 2010


L’avènement de l’environnement exchange 2010 et notamment de ses nouvelles fonctionnalités de haute disponibilité vont permettre à plusieurs d’entre nous de mettre en place des solutions messagerie à forte disponibilité. Un des intérêts notables de la version Exchange 2010 est de pouvoir bénéficier d’une haute disponibilité avec simplement deux serveurs physiques ou virtuel. Cependant cette solution va nécessiter de mettre en place des solutions matérielles de répartition de charge. Ces solutions de répartition de charge matérielle vont petit à petit remplacer notre bon vieux NLB Windows qui,il faut bien le dire, n’offre que peu de fonctionnalité. Ce dernier est en effet incapable de vérifier si le service reparti est toujours opérationnel, et de plus il est de plus très difficile voire impossible de le mettre en place dans le cadre de serveur étendu sur plusieurs sites. Quand à son support en environnement Dag Multi rôles il est tout simplement : non supporté. Alors est-il temps d’envisager la solution matérielle. La réponse est oui et clairement oui.

Une des premières questions que j’anticipe est : Quels couts ? Sachez que ce dernier varie selon le type d’équipement que vous allez choisir, les services que vous allez lui demander de faire, le nombre de connexion simultanées que ces équipements vont devoir gérer. En haut de l’affiche vous trouverez des solutions très évoluées fonctionnellement comme les solutions de la société F5 qui ne se contente pas de faire de la simple répartition de charge mais qui offre des fonctions de contrôle pour la publication d’application. On ne parle d’ailleurs plus de répartiteur de charge mais de contrôleur de publication d’application (Application Delivery controler). Sachez que selon les marques et les modèles et les services, les prix oscillent entre 10 K€ et 4K€. De quoi vous donnez l’embarras du choix.

Les répartiteurs de charge offrent hormis le fait que ces derniers sont obligatoires dans le cadre d’un environnement Exchange 2010 DAG composé uniquement de deux serveurs beaucoup de services complémentaires qu’aurai du bien mal à donner une solution NLB. Voici en quelques mots les 5 services fondamentaux que peuvent vous rendre les répartiteurs de charge matérielle.

  1. Le premier service est la vérification que le service réparti est fonctionnel. Cela n’a l’air de rien mais le service de répartition de charge Windows ne le fait pas. Si le service Smtp s’arrête le NLB Windows va continuer à acheminer le flux Smtp sur le serveur en question. Les services Exchange 2010 n’ont pas grand-chose à voir avec la couche de répartition de charge Windows. La conséquence de ce mode de fonctionnement est que si votre service d’accès client ou de transport s’arrête dans le cas de figure où vous disposez d’un répartiteur, vos utilisateurs ne s’apercevront de rien, dans le cas contraire pour quelque personne cela va fonctionner pour d’autre pas. L’intérêt de mettre en place un DAG en environnement Exchange 2010 et aussi de justifier de l’évolution des plates-formes messagerie est de fournir un service ayant une meilleure disponibilité. Dans le cas du NLB l’objectif ne sera clairement pas atteint.
  2. Le second service est la possibilité de faire fonctionner une répartition de charge en environnement étendu (deux sites distant) ce qui est très compliqué via le NLB Windows voir quasiment impossible selon certain cas de figure.
  3. Le troisième service en environnement Exchange 2010 et ne de pas répartir la charge sur un serveur sauf si aucun autre serveur ne répond. Ce comportement conviendra tout à fait aux sites de secours.
  4. Le quatrième service rendu par les load balancer est une protection d’intrusion qui permet de mieux protéger les serveurs en question. Nlb n’offre pas ce service.
  5. Le cinquième service est la persistance de session lors de basculement d’un serveur vers un autre. Dans le cas du NLB il n’y pas de persistance de session et si un utilisateur passe d’un serveur a l’autre il y aura forcément une authentification supplémentaire.

Est-ce complexe à mettre en place ?

La réponse est non dans 80 % des cas mais peut varier selon ce que vous leurs demander de faire et selon les infrastructures concernées. Concernant Exchange 2010, il sera beaucoup plus facile, moins consommateur de temps et certainement plus stable de mettre en place une solution matérielle de répartition de charge qu’un environnement NLB en environnement virtuel (Hyper-V / Vmware) sur une configuration étirée sur deux sites distants (Je vous parle de vécu la !). Dans tous les cas les services seront loin d’être les mêmes. La plupart du temps l’installation des Load Balancer pour l’environnement Exchange se résume a peu de chose (Https/http, smtp(s) , Pop(s)/Imap(s)) et par conséquent s’avère être très simple à mettre en place. Certains possèdent la fonctionnalité d’auto découverte comme chez Barracuda, la configuration est alors un jeu d’enfant.

Dans un prochain article nous ferons d’un répartiteur de milieu de gamme afin de mieux comprendre les différentes étapes de la mise en place de ces équipements dans l’environnement Exchange 2010.

Laurent Teruin

 

 

 

 


 

Posted in 1-EXCHANGE 2010, Transport-2010 | 2 Comments »

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 »

Ex2K10 Install : ‘This property can’t be found in the cache (2147504141)/Impossible de trouver la propriété dans le cache

Posted by Teruin laurent le avril 27, 2010


The following error was generated when « $error.Clear(); install-ExsetdataAt om -AtomName SMTP -DomainController $RoleDomainController » was run: « An error occurred with error code 2147504141′ and message ‘This property can’t be found in the cache.’. ».
ou
Une erreur s’est produite. Le code erreur 2147504141 a affiché le message « Impossible de trouver la propriété dans le cache ».

Nous avons rencontré cela lors d’une installation toute neuve sur un environnement Windows 2008 R2 avec l’adresse IP V6 activée mais en DHCP. La première chose a été de tester sans la couche IPV6 activée. Même symptôme. Ce problème est référencé par Microsoft à l’adresse suivante : http://support.microsoft.com/kb/952842/fr. Le téléchargement proposé dans cet article de semble pas fonctionner sur la plateforme Windows 2008 R2 Standard Edition X64 UK. Nous avons donc procéder à la modification suivante extrait du dit article puis redémarrer la machine.

We encountered a installation Issue on a fresh Hyper-v Windows 2008 R2 UK std Domain Controller installation on with IPV6 Dhcp Enable We have just try to disable entirely the IPV6 by following this process.

  • Ouvrez l’Éditeur du Registre.
  • Recherchez la sous-clé de Registre suivante : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
  • Dans le volet de détails, cliquez sur Nouveau , puis sur Valeur DWORD (32 bits).
  • Tapez DisabledComponents et appuyez sur Entrée.
  • Double-cliquez sur DisabledComponents, puis tapez 0xffffffff en hexadécimal ou 4294967295 en décimal.

La configuration utilisée fut donc la suivante : The used configuration was below


Mais cela à donner le même résultat comme le montre la figure suivante
But it gave the same result

Nous avons donc supprimé la clef de registre et remis en fonction IPV6 en spécifiant cette fois ci une adresse IPV6 statique et retenté l’opération.
We just delete the registry Key, restart the computer and enable IPV6 with a static entry and reinstall from a fresh installation

But it was the same issue.Mais l’installation n’a pas fonctionnée

Nous sommes donc revenus en arrière avec un snapshot, repositionné une configuration IPV6 statique avant de réinstaller l’ensemble des composants requis pour Exchange 2010. Puis refait une nouvelle installation en utilisant la commande Setup /role:MT,HT,CA,MB /OrganizationName:MARIE /EnableLegacyOutlook
We have reloaded a snapshot and put again a static IPV6 configuration before installing all the Exchange requirements. We restart a fresh installation in these conditions. The script for installing Exchange 2010 was this one : « Setup /role:MT,HT,CA,MB /OrganizationName:MARIE /EnableLegacyOutlook »
And our IP configuration was :

And we got this issue.
et nous avons eu cette erreur

After that, we decided to change tack, and to retry to delete this… fu… IPV6 configuration. We reloaded a clean snapshot where we deactivate the IPV6 configuration and remove IPV6 entries in the host file and put again the registry key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters. Restarting the computer and relaunch the installation.
Apres cela nous avons décidé de changer de tactique et nous avons rechargé un cliché instantané vierge et repositionné la clef de registre, supprimer les entrées IPV6 dans le fichier Host redémarrer le serveur et relancer l’installation encore une fois.


our configuration was this one  Notre environnement était celui-ci.
 


And the result was …
Et le resultat fut :

En dernier recours nous avons essayé d’appliquer cette recommendation Microsoft : http://support.microsoft.com/kb/980050/fr
As a last resort we tryied to apply this Microsoft recommendation:
http://support.microsoft.com/kb/980050

  1. Open the Hyper-V Manager console. Right-click the virtual machine on which you want to install Exchange Server 2010, and then click Settings.
  2. On the Settings tab, click the Management section, and then click Integration Services.
  3. Click to clear the Time synchronization check box, and then click OK.
  4. Install Exchange Server 2010 on the virtual machine.


 And relaunch the installation of Exchange Hub service like this.

 
Oups another error message . so let start with an clean snapshot again.
Oula encore un message d’erreur, repartons d’un cliché instantané propre After restarting from a clean snapshot with IPV6 deactivated (Unchecked in protocol and by registry) and with Timesynchronisation disabled on Hyperv and on the Hosted computer
Après un redémarrage d’un cliché instantané avec IPV6 désactivé (Decoché dans la configuration du protocol et avec la clef de register correcte) et la synchronization de temps désactivé sur la machine Hyper-v ainsi que sur la machine virtuelle

 
Et le résultat fonctionne parfaitement  And the consequent is that.. it is working flawlessly !!
Bon dans l’optique de terminer cet article So in the goal to wind up this article let resume
Vous pouvez installer Microsoft Exchange 2010 en Hyper- V sans IPV6
You can install Exchange 2010 on Hyper-v With out IPV6 but for that you have to
1- Desactivate IPV6 with the registry key (Désactiver IPV6 avec la clef de registre)
2- Uncheck IPv6 Protocol in the current configuration (Décocher IPV6 dans la partie protocolaire de votre serveur)
3- Disabled Time Synchronisation Hyperv integrated service (Désactiver le service de synchronization de temps si la machine que vous utiliez est dans une GMT différente de la machine host)

Quand on veut on peut : When there’s a will there’s a way !!
Laurent TERUIN

Posted in 1-EXCHANGE 2010, Installation-2010, Transport-2010 | 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 »

Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams

Posted by David PEKMEZ le novembre 23, 2009


Les diagrammes d’architecture des serveurs de transport sont disponibles en téléchargement sur le site Microsoft

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6eb8c09a-6ea4-442a-9faa-de33265ceb84&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+MicrosoftDownloadCenter+(Microsoft+Download+Center)#tm

Bonne lecture J

Posted in Transport-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 224 autres abonnés