Configuration requise pour le proxy inverse dans Lync Server 2013
Rubrique Dernière modification : 2013-03-05
Lync Server 2013 impose quelques exigences sur les communications du client externe qui sont ensuite transmises aux services Web externes hébergés sur le directeur, le pool d’administrateurs, le serveur frontal ou le pool frontal. Le proxy inverse est également responsable de la publication d’Office Web Apps Server, si vous offrez des conférences à vos utilisateurs.
Remarque
Lync Server 2013 ne spécifie pas de proxy inverse particulier que vous devez utiliser. Lync Server 2013 définit uniquement les exigences opérationnelles que le proxy inverse doit être en mesure de faire. En règle générale, le proxy inverse que vous avez déjà déployé dans votre infrastructure peut être en mesure de répondre aux exigences.
Configuration requise pour le proxy inverse
Les opérations fonctionnelles que Lync Server 2013 s’attend à ce qu’un proxy inverse effectue sont les suivantes :
Utilisez le protocole SSL (Secure Socket Layer) et le protocole TLS (Transport Layer Security) implémentés à l’aide de certificats acquis auprès d’une autorité de certification publique pour vous connecter aux services Web externes publiés du pool d’administrateurs, du serveur frontal ou du pool frontal. Le directeur et le serveur frontal peuvent se trouver dans un pool à charge équilibrée à l’aide d’équilibreurs de charge matériels.
Possibilité de publier des sites Web internes à l’aide de certificats pour le chiffrement, ou de les publier sur un moyen non chiffré, si nécessaire.
Possibilité de publier un site web hébergé en interne en externe à l’aide d’un nom de domaine complet (FQDN).
Possibilité de publier tout le contenu du site web hébergé. Par défaut, vous pouvez utiliser la /* directive, qui est reconnue par la plupart des serveurs web pour signifier « Publier tout le contenu sur le serveur web ». Vous pouvez également modifier la directive, par exemple /Uwca/*, ce qui signifie « Publier tout le contenu sous le répertoire virtuel Ucwa ».
Doit être configurable pour exiger des connexions SSL (Secure Sockets Layer) et/ou TLS (Transport Layer Security) avec des clients qui demandent du contenu à partir d’un site web publié.
Doit accepter des certificats avec des entrées SAN (Subject Alternative Name).
Doit être en mesure d’autoriser la liaison d’un certificat à un écouteur ou à une interface par le biais duquel le nom de domaine complet des services web externes sera résolu. Les configurations d’écouteurs sont préférables aux interfaces. De nombreux écouteurs peuvent être configurés sur une même interface ;
Doit autoriser la configuration de la gestion des en-têtes d’hôte. Souvent, l’en-tête d’hôte d’origine envoyé par le client demandeur doit être transmis en toute transparence, au lieu d’être modifié par le proxy inverse.
Pontage du trafic SSL et TLS d’un port défini en externe (par exemple, TCP 443) vers un autre port défini (par exemple, TCP 4443). Le proxy inverse peut déchiffrer le paquet à la réception, puis recrypter le paquet lors de l’envoi.
Pontage du trafic TCP non chiffré d’un port (par exemple, TCP 80) à un autre (par exemple, TCP 8080).
Autorisez la configuration de l’authentification NTLM, aucune authentification et l’authentification directe.