Dans la boîte de dialogue RPC Properties, allez à l’onglet Directory Security et cliquez sur le bouton Edit dans la section Authentication and access control. Dans la boîte de dialogue Authentication Methods résultante, assurez-vous que la case Enable anonymous access est décochée. RPC sur HTTP exige que les utilisateurs s’authentifient.
Courriel d’entreprise (2)
![Courriel d’entreprise (2) Courriel d’entreprise (2)](https://www.itpro.fr/wp-content/uploads/2015/05/a3df589dc0e7e0254bfd4dab94b55e0e.jpg)
Vous pouvez choisir l’authentification Integrated Windows ou l’authentification basique, ou les deux.
Je recommande de sélectionner l’authentification basique pour RPC sur HTTP. Bien sûr, cela signifie que les noms et mots de passe utilisateur traverseront votre réseau en texte clair, mais vous pouvez utiliser Secure Sockets Layer (SSL) pour crypter le trafic RPC sur HTTP. L’authentification Integrated Windows fonctionnera dans certains cas mais, parfois, soulèvera des problèmes épineux. Si vous sélectionnez l’authentification basique, un message d’avertissement apparaîtra. Cliquez sur Yes pour poursuivre la sélection puis sur OK, Apply et OK.
La troisième étape consiste à configurer les ports qu’utilisera le RPC over HTTP Proxy. Sur votre serveur Exchange, à partir de la ligne de commande, exécutez la commande IPconfig/all et enregistrez le nom de l’hôte et le nom du domaine. Ensuite, lancez un éditeur de registre et naviguez jusqu’à la sous-clé HKEY_LOCAL_MACHINE\SOFTWARE \Microsoft\Rpc\RpcProxy. Double-cliquez sur la valeur ValidPorts et modifiez-la de la façon suivante :
<hostname>:6001-6002;
<hostname>. <domainname>:6001-6002;
<hostname>:6004;
<hostname> .<domainname>:6004;
où hostname et domainname sont les valeurs que vous avez enregistrées lors de l’exécution de Ipconfig/all.
Les pièges habituels en la circonstance se manifestent : le fait de modifier le registre peut rendre votre système instable. Par conséquent, notez les valeurs existantes de toutes les entrées et préparez-vous à les réappliquer dans le cas où des problèmes de stabilité se manifesteraient. Pour permettre aux clients Outlook 2003 de se connecter aux serveurs Exchange 2003 par l’intermédiaire de RPC sur HTTP, il faut aussi configurer quelque peu le client. Dans Outlook 2003, sélectionnez Tools dans la barre des menus puis Email Accounts. Sélectionnez View or change existing email accounts, cliquez sur Next, sélectionnez le compte email de type Exchange, cliquez sur le bouton Change puis cliquez sur More Settings.
Dans la boîte de dialogue Microsoft Exchange Server, allez à l’onglet Connections, sélectionnez Connect to my Exchange mailbox using HTTP puis cliquez sur Exchange Proxy Settings. Dans la boîte de dialogue Exchange Proxy Settings, que montre la figure 2, entrez l’URL pour le serveur proxy Exchange et sélectionnez les paramètres de connexion. Une fois le client et le serveur configurés, Outlook 2003 pourra communiquer avec Exchange 2003 sans le concours d’un VPN. OWA. Il se peut que vous ne vouliez pas installer RPC sur HTTP, ou que vos utilisateurs travaillent sur une ancienne version d’Outlook, ou encore que vous utilisiez Windows 2000 ou Exchange 2000.
Les utilisateurs peuvent néanmoins accéder au courriel à distance par l’intermédiaire de OWA (Outlook Web Access). OWA est très pratique et donne accès aux boîtes de réception et aux dossiers en ligne des utilisateurs à partir d’un banal navigateur Web. Pour accéder à OWA à partir d’un navigateur, les utilisateurs tapent simplement le nom de leur serveur Exchange et ajoutent /exchange (par exemple, https://mail.contoso.com/exchange ).
Pour permettre l’accès au courriel par OWA de l’extérieur du pare-feu, vous devez publier votre serveur Exchange : c’est-à-dire, le mettre à la disposition des utilisateurs Internet. Pour cela, le moyen le plus simple consiste à utiliser ISA Server 2006 ou un pare-feu applicatif similaire capable d’inspecter le trafic OWA pour voir s’il ne contient rien de malveillant. ISA Server contient des wizards pas à pas grâce auxquels il est facile de publier les sites OWA. Si vous utilisez OWA, je conseille d’utiliser aussi un certificat SSL pour préserver la confidentialité du courriel entre votre serveur Exchange et les navigateurs de vos utilisateurs. Je recommande également de désactiver le verrouillage de compte.
Si ce verrouillage est activé, un utilisateur mal intentionné pourrait lancer une attaque par déni de service (DoS, Denial of Service) contre tout utilisateur dont il connaît le nom. Enfin, pour que le help desk ne soit pas submergé d’appels, je vous conseille de configurer le pare-feu de manière à diriger tout trafic adressé au Fully Qualified Domain Name (FQDN) du serveur OWA, vers le répertoire virtuel \exchange sur votre serveur Exchange. Ainsi, les utilisateurs n’auront pas à se rappeler d’ajouter /exchange à l’URL qu’ils tapent dans leur navigateur. Autre recommandation : rediriger vers le site protégé par SSL tout utilisateur qui oublie de taper https:// ou qui tape seulement http://.
Téléchargez cette ressource
![Guide de Reporting Microsoft 365 & Microsoft Exchange](https://www.itpro.fr/wp-content/uploads/2023/06/Promodag-Reports-pour-Microsoft-Exchange-Solution-de-reporting-detaille-de-lutilisation-de-Microsoft-Exchange-2023-1.jpg)
Guide de Reporting Microsoft 365 & Microsoft Exchange
Comment bénéficier d’une vision unifiée de vos messageries, mieux protéger vos données sensibles, vous conformer plus aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Découvrez la solution de reporting complet de l’utilisation de Microsoft Exchange, en mode on-premise ou dans le Cloud.