Authentification et sécurité RPC sur HTTP

Article
10/25/2013

Dernière rubrique modifiée : 2005-05-18

En ce qui concerne l'authentification et la sécurité, l'utilisation de RPC sur HTTP a les avantages suivants :

Vous ne devez autoriser aucun port Internet en dehors de ceux que vous avez déjà autorisés pour Microsoft® Office Outlook® Web Access, Microsoft Exchange ActiveSync® ou Outlook Mobile Access.
Vous devez utiliser SSL.
Outlook doit envoyer des requêtes authentifiées.
Le serveur proxy RPC et le serveur Exchange authentifient les requêtes Outlook qui utilisent RPC sur HTTP.
Vous n'exposez pas le mappeur de point final.
Les ordinateurs clients peuvent accéder uniquement aux services Exchange sur les serveurs Exchange spécifiés.

Authentification HTTP

Le service IIS sur le serveur proxy RPC contrôle l'authentification HTTP de session. Lorsque vous configurez le serveur proxy RPC, vous devez définir le répertoire virtuel RPC pour utiliser l'authentification de base, l'authentification NTLM, ou les deux. En fonction de la configuration de son profil, Outlook peut envoyer l'authentification de base ou l'authentification NTLM pour la session HTTP. Le serveur proxy RPC ISAPI n'accepte pas les connexions authentifiées de manière anonyme.

Remarque :
Lorsque vous utilisez le Gestionnaire système Exchange dans Exchange Server 2003 Service Pack 1 (SP1) pour configurer RPC sur HTTP, le Gestionnaire système Exchange configure automatiquement les paramètres d'authentification sur le répertoire virtuel RPC.

Remarque :
L'authentification NTLM est également connue sous le nom d'authentification Windows intégrée.

Le mécanisme d'authentification que vous configurez dans votre profil Outlook est utilisé seulement pour la session HTTP vers le serveur proxy RPC. Le mécanisme d'authentification entre Outlook et le serveur Exchange, lorsque Outlook accède au serveur Exchange en utilisant RPC sur HTTP, est toujours NTLM. Il est fortement recommandé d'utiliser le cryptage SSL pour la session HTTP au serveur proxy RPC, surtout si vous utilisez l'authentification de base pour la session HTTP. Si vous utilisez le cryptage SSL, vous empêchez votre nom d'utilisateur et votre mot de passe d'être envoyés en texte clair. Outlook ne vous permet pas d'utiliser l'authentification de base lors de la connexion à votre serveur proxy RPC sans utiliser le cryptage SSL.

Si vous avez un pare-feu qui examine le trafic HTTP et le modifie, vous devez peut-être utiliser l'authentification de base au lieu de l'authentification NTLM. L'authentification NTLM échoue si le serveur proxy RPC n'approuve pas les informations d'authentification. Vous pouvez par exemple avoir un pare-feu qui met fin à la session depuis Internet et établit une nouvelle session au serveur proxy RPC, au lieu de passer la session HTTPS (SSL) au serveur Exchange sans modification. Ce processus s'appelle proxy inverse ou publication sur le Web. Certains pare-feu, tels que Microsoft Internet Security and Acceleration (ISA) Server 2004, peuvent correctement effectuer l'opération de proxy inverse ou publier la session Web, et continuer à autoriser l'authentification NTLM.

Remarque :
ISA Server 2000 ne peut pas effectuer l'opération de proxy inverse ou publier la session Web tout en autorisant l'authentification NTLM.

L'authentification de base n'est pas affectée par l'opération de proxy inverse ou la publication Web, et fonctionne quels que soient les pare-feu. Si vous utilisez l'authentification de base, vous devez taper votre domaine, nom d'utilisateur et mot de passe à chaque démarrage de session Outlook.

Authentification de base et authentification NTLM

Le tableau suivant illustre quelques-unes des différences entre l'authentification de base et l'authentification NTLM.

Authentification de base	Authentification NTLM
L'ordinateur client envoie le nom d'utilisateur et le mot de passe en texte clair. Vous devez toujours utiliser SSL lorsque vous utilisez l'authentification de base. Outlook ne vous permet pas de sélectionner l'authentification de base sans sélectionner également SSL. Le serveur proxy RPC requiert également SSL.	L'ordinateur client envoie une requête d'ouverture de session au serveur. Le serveur répond en indiquant à l'ordinateur client une stimulation ou un « jeton » généré aléatoirement. L'ordinateur client hache le mot de passe protégé par cryptographie de l'utilisateur actuellement connecté avec le système de vérification et envoie la « réponse » obtenue au serveur. Le serveur reçoit la réponse hachée avec le système de vérification et la compare à ce qu'il sait être la réponse appropriée. (Le serveur fait une copie du jeton d'origine qu'il a généré et la hache par rapport à ce qu'il sait être le hachage de mot de passe de sa propre base de données de comptes d'utilisateurs.) Si la réponse reçue correspond à la réponse attendue, l'utilisateur est authentifié avec succès sur l'hôte.
L'authentification de base fonctionne avec des pare-feu de proxy inverse.	L'authentification NTLM ne peut pas fonctionner avec certains pare-feu de proxy inverse. Si le pare-feu examine le trafic et le modifie, l'authentification NTLM peut être invalidée.
L'authentification de base oblige l'utilisateur à entrer le domaine, le nom d'utilisateur et le mot de passe.	NTLM peut utiliser les informations d'ouverture de session actuelles du système d'exploitation Microsoft Windows®.

L'ordinateur client envoie le nom d'utilisateur et le mot de passe en texte clair.

Vous devez toujours utiliser SSL lorsque vous utilisez l'authentification de base.

Outlook ne vous permet pas de sélectionner l'authentification de base sans sélectionner également SSL.

Le serveur proxy RPC requiert également SSL.

L'ordinateur client envoie une requête d'ouverture de session au serveur.

Le serveur répond en indiquant à l'ordinateur client une stimulation ou un « jeton » généré aléatoirement.

L'ordinateur client hache le mot de passe protégé par cryptographie de l'utilisateur actuellement connecté avec le système de vérification et envoie la « réponse » obtenue au serveur.

Le serveur reçoit la réponse hachée avec le système de vérification et la compare à ce qu'il sait être la réponse appropriée. (Le serveur fait une copie du jeton d'origine qu'il a généré et la hache par rapport à ce qu'il sait être le hachage de mot de passe de sa propre base de données de comptes d'utilisateurs.)

Si la réponse reçue correspond à la réponse attendue, l'utilisateur est authentifié avec succès sur l'hôte.

L'authentification de base fonctionne avec des pare-feu de proxy inverse.

L'authentification NTLM ne peut pas fonctionner avec certains pare-feu de proxy inverse.

Si le pare-feu examine le trafic et le modifie, l'authentification NTLM peut être invalidée.

L'authentification de base oblige l'utilisateur à entrer le domaine, le nom d'utilisateur et le mot de passe.

NTLM peut utiliser les informations d'ouverture de session actuelles du système d'exploitation Microsoft Windows®.

Conditions nécessaires pour que RPC sur HTTP utilise les informations d'ouverture de session actuelles du système d'exploitation Windows

Pour que RPC sur HTTP utilise les informations d'ouverture de session actuelles du système d'exploitation Windows, les conditions suivantes doivent être remplies :

L'utilisateur ouvre une session sur l'ordinateur client avec les informations d'identification de domaine correctes.
L'utilisateur sélectionne l'authentification NTLM dans le profil Outlook.
Le pare-feu autorise l'authentification NTLM. Cela peut se produire si le pare-feu transmet simplement la session SSL au serveur Exchange sans aucune modification (filtrage de port) ou si le pare-feu est un pare-feu avancé tel qu'ISA Server 2004. ISA Server 2004 peut effectuer l'opération de proxy inverse que le Web publie sur le serveur Exchange et autoriser l'authentification NTLM.
L'utilisateur envoie automatiquement les informations d'authentification NTLM avec la connexion. Cela se produit lorsque l'une des conditions suivantes est remplie :
- Vous configurez Outlook pour effectuer une authentification mutuelle sur SSL. Il s'agit de la méthode recommandée.
- Le paramètre LmCompatibilityLevel de l'ordinateur client a la valeur 2 ou 3.

Pour plus d'informations sur la configuration de LmCompatibilityLevel, consultez l'article de Base de connaissances Microsoft 820281 « You must provide Windows account credentials when you connect to Exchange Server 2003 by using the Outlook 2003 RPC over HTTP feature » (https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281).

Authentification RPC

Les requêtes RPC que le serveur Exchange authentifie utilisent toujours l'authentification NTLM.

SSL

L'ordinateur client doit approuver le certificat utilisé pour SSL. Pour que l'ordinateur client approuve le certificat utilisé pour SSL, les conditions suivantes doivent être remplies :

Le nom du certificat correspond au site Web auquel vous accédez.
Le certificat n'a pas expiré.
L'ordinateur client approuve l'autorité de certification qui a délivré le certificat.

Si vous avez déjà configuré correctement Outlook Web Access, Exchange ActiveSync ou tout autre service Web pour utiliser votre serveur frontal Exchange, le certificat répond à ces exigences.

Vous pouvez rechercher le répertoire virtuel RPC en utilisant Microsoft Internet Explorer pour vérifier que le certificat est correct. Si le certificat n'est pas valide, Internet Explorer émet un avertissement.

Déchargement SSL

Le déchargement SSL se produit lorsque le pare-feu situé devant le serveur proxy RPC quitte la session SSL et établit une nouvelle session non-SSL sur le serveur frontal. Plus précisément, il n'établit pas de nouvelle session SSL.

Si vous utilisez le déchargement SSL, vous devez configurer une clé de Registre pour indiquer au serveur proxy RPC qu'il peut accepter une session non-SSL. Pour des informations détaillées sur la définition de cette clé de Registre, consultez Comment configurer le serveur proxy RPC afin d'autoriser le déchargement SSL sur un serveur distinct.

Partager via