Création d'un serveur virtuel Office Communicator Web Access
Dernière rubrique modifiée : 2009-03-06
Après avoir installé et activé Office Communicator Web Access (version 2007 R2), vous devez créer au moins un serveur virtuel Office Communicator Web Access. Les utilisateurs ne peuvent pas utiliser les fonctions de messagerie instantanée, d'audioconférence ou toute autre fonctionnalité d'Office Communicator Web Access tant qu'ils ne disposent d'aucun serveur virtuel auquel se connecter.
.gif "Dd441275.note(fr-fr,office.13).gif") Remarque : |
|---|
| Pour l'essentiel, un serveur virtuel est simplement un site Web. Si des utilisateurs ouvrent une session sur Office Communicator Web Access à l'aide de l'URL https://im.contoso.com, https://im.contoso.com n'est pas uniquement un site Web mais également un serveur virtuel Office Communicator Web Access. L'utilité des serveurs virtuels réside dans le fait qu'ils permettent à un ordinateur IIS (Services Internet) unique d'héberger plusieurs sites Web. Par exemple, un ordinateur pourrait héberger aussi bien https://im.fabrikam.com que https://im.contoso.com. |
Si vous envisagez de gérer des demandes émanant à la fois d'utilisateurs internes (autrement dit, des utilisateurs se trouvant derrière le pare‑feu de l'organisation) que d'utilisateurs externes (utilisateurs se trouvant à l'extérieur du pare‑feu de l'organisation), vous devrez créer deux serveurs virtuels : un pour les utilisateurs internes et un pour les utilisateurs externes. Vous pouvez utiliser l'Assistant Déploiement pour créer le premier serveur virtuel, puis utiliser le composant logiciel enfichable Office Communicator Web Access pour créer le second serveur virtuel.
| Remarque : |
|---|
| Si vous allez gérer des demandes émanant d'utilisateurs externes, il est fortement recommandé d'utiliser un serveur proxy inverse pour publier ce serveur virtuel sur le Web. Pour plus d'informations sur l'utilisation d'un serveur proxy inverse pour publier un serveur virtuel Office Communicator Web Access, consultez Utilisation d'un serveur proxy inverse pour l'activation de l'accès distant. De plus, et pour des raisons de sécurité, il est recommandé d'héberger sur des ordinateurs différents le serveur virtuel destiné aux utilisateurs internes et le serveur virtuel destiné aux utilisateurs externes. |
Pour créer le premier serveur virtuel sur un ordinateur, reportez-vous à la procédure « Pour créer le premier serveur virtuel » dans Création d'un serveur virtuel Office Communicator Web Access à l'aide de l'Assistant Déploiement. La création d'un second serveur virtuel sur ce même ordinateur doit être effectuée à l'aide du composant logiciel enfichable Office Communicator Web Access. Pour créer un second serveur virtuel sur un ordinateur, procédez comme suit :
- Ouvrez le composant logiciel enfichable Office Communicator Web Access, cliquez avec le bouton droit sur le nom du serveur sur lequel le serveur virtuel sera créé, puis cliquez sur Création d'un serveur virtuel.
- Une fois l'Assistant Création d'un serveur virtuel affiché, utilisez la même approche pour créer le premier serveur virtuel sur l'ordinateur.
Avant de créer un serveur virtuel, vous devez choisir une méthode d'authentification, un type de connectivité et un serveur du tronçon suivant.
Méthodes d'authentification
Lorsque vous créez un serveur virtuel, vous devrez spécifier des valeurs pour un certain nombre de propriétés de clé, en commençant par le mécanisme d'authentification. Office Communicator Web Access fournit plusieurs options d'authentification.
Authentification par mot de passe intégrée (NTLM/Kerberos)
C'est le type d'authentification le plus sécurisé et l'option qui requiert le moins d'effort. Avec l'authentification par mot de passe intégrée, les utilisateurs n'ont pas à entrer un nom d'utilisateur et un mot de passe. Au lieu de cela, ils sont authentifiés à l'aide des mêmes informations d'identification que celles qu'ils ont utilisées lors de l'ouverture de session sur leur ordinateur.
Toutefois, l'authentification par mot de passe intégrée présente deux inconvénients. Tout d'abord, ce type d'authentification peut être utilisé uniquement avec des serveurs virtuels internes. Les utilisateurs externes doivent toujours fournir des informations d'identification ; par conséquent, les sites qui gèrent des demandes d'ouverture de session externes doivent utiliser l'authentification basée sur les formulaires ou l'authentification personnalisée.
De plus, l'authentification par mot de passe intégrée peut être utilisée uniquement par des personnes qui présentent les deux particularités suivantes : elles se connectent à partir d'un ordinateur exécutant Microsoft Windows et elles utilisent un navigateur Web qui prend en charge l'authentification NTLM ou Kerberos. Si tous vos utilisateurs sont des utilisateurs internes exécutant Internet Explorer et Microsoft Windows, vous pouvez utiliser l'authentification par mot de passe intégrée comme unique mécanisme d'authentification. Sinon, vous devrez utiliser à la fois l'authentification par mot de passe intégrée et l'authentification basée sur les formulaires, ou bien vous devrez utiliser une méthode d'authentification personnalisée.
| Remarque : |
|---|
| Si vous utilisez à la fois l'authentification par mot de passe intégrée et l'authentification basée sur les formulaires, Office Communicator Web Access essaiera d'abord de connecter un utilisateur en utilisant l'authentification par mot de passe intégrée. En cas d'échec, l'utilisateur aura la possibilité de se connecter en utilisant l'authentification basée sur les formulaires. |
Authentification basée sur les formulaires
Avec l'authentification basée sur les formulaires, une boîte de dialogue d'ouverture de session s'affiche à tout utilisateur qui tente d'accéder à un serveur virtuel Office Communicator Web Access. Ce dernier doit alors indiquer ses informations d'identification (domaine, nom d'utilisateur et mot de passe) avant de pouvoir être authentifié et accéder au site. L'authentification basée sur les formulaires vous permet de prendre en charge les utilisateurs suivants :
- utilisateurs Macintosh et Linux ;
- utilisateurs qui n'exécutent pas Internet Explorer ;
- utilisateurs externes (c'est‑à‑dire les utilisateurs se connectant en dehors du pare-feu de l'organisation).
L'inconvénient de l'authentification basée sur les formulaires est que ce mécanisme n'est pas très sécurisé. Par exemple, les informations d'identification de l'utilisateur sont passées au serveur au format texte brut. De ce fait, il vous est vivement conseillé d'utiliser la connectivité HTTPS pour tout serveur virtuel qui autorise l'authentification basée sur les formulaires.
Authentification personnalisée
En plus des mécanismes d'authentification intégrés au système d'exploitation Windows, Office Communicator Web Access prend également en charge des méthodes d'authentification personnalisées ou tierces. Par exemple, Office Communicator Web Access prend en charge l'utilisation de l'authentification à 2 facteurs, au cours de laquelle deux informations d'identification (généralement, une carte à puce et un code confidentiel (PIN)) doivent être présentées avant qu'un utilisateur puisse être authentifié.
Office Communicator Web Access prend également en charge l'authentification unique, mais seulement avec Microsoft Internet Security and Acceleration Server (ISA) 2006. Avec ce type d'authentification, un utilisateur peut se connecter une fois et se voir accorder l'accès à plusieurs applications. Par exemple, un utilisateur peut se connecter à Microsoft Outlook Web Access et être automatiquement connecté à Office Communicator Web Access également (ou vice versa).
| Remarque : |
|---|
| Si vous utilisez l'authentification unique, vous devez spécifier l'option URL de déconnexion, qui est une URL à laquelle l'utilisateur accèdera chaque fois qu'il se déconnectera d'Office Communicator Web Access. En visitant cette page, l'utilisateur peut être assuré que tous les cookies d'authentification stockés sur son ordinateur seront supprimés. Pour plus d'informations, consultez la documentation relative à votre méthode d'authentification personnalisée. |
Type de connectivité
Après avoir spécifié le mécanisme d'authentification, vous devez spécifier le type de connectivité. Office Communicator Web Access prend en charge deux protocoles de connectivité différents : HTTP et HTTPS. Entre les deux, il est préférable d'utiliser HTTPS car ce protocole est le plus sécurisé. HTTPS chiffre notamment tout le trafic entre le serveur et le navigateur. Si vous décidez d'utiliser HTTPS (protocole recommandé), vous devez assigner un certificat à cette connexion. Pour plus d'informations, consultez Préparation des certificats pour Communicator Web Access.
| Remarque : |
|---|
| Le protocole HTTPS est obligatoire si vous envisagez d'implémenter le partage du Bureau. Si vous ouvrez une session sur un site Web Office Communicator Web Access qui utilise le protocole HTTP, le bouton de partage du Bureau sera désactivé. Si vous maintenez la souris sur le bouton, une info-bulle s'affiche et indique : « Le partage du Bureau requiert une connexion sécurisée (HTTPS). Contactez votre administrateur système. » |
Vous devez également attribuer une adresse IP et un port à chaque serveur virtuel. Des serveurs virtuels peuvent partager une adresse IP, mais ils ne peuvent pas utiliser le même port : chaque serveur virtuel doit avoir son propre port, un port non utilisé par toute autre application. Par défaut, le programme d'installation propose d'utiliser le port 443 pour les connexions HTTP et le port 80 pour les connexions HTTPS. Étant donné qu'il s'agit également des ports utilisés par le site Web par défaut dans les Services Internet (IIS), vous devrez désactiver ce site pour que ces ports puissent être attribués à Office Communicator Web Access.
Comme indiqué, lorsque vous créez un serveur virtuel, vous devez spécifier le port qu'il devra utiliser. Si le port spécifié est déjà en cours d'utilisation par une autre application, le programme d'installation vous informera que le port a déjà été réservé, et vous demandera de sélectionner un autre numéro de port. Supposons, par exemple, que le port 443 soit utilisé par le site Web par défaut dans IIS. Si vous n'avez pas désactivé ce site, le programme d'installation ne vous autorisera pas à utiliser le port 443 comme port de serveur virtuel.
Toutefois, Office Communicator Web Access ne reconnaît pas toujours les ports qui sont actuellement en cours d'utilisation par un composant système Windows. Supposons, par exemple, que vous sélectionniez le port 137 lors de la création d'un serveur virtuel. Le programme d'installation vous autorisera à utiliser ce numéro de port et créera automatiquement le serveur virtuel. Toutefois, vous ne pourrez pas démarrer ce nouveau serveur virtuel. En effet, ce port est utilisé par la fonctionnalité Partage de fichiers et d'imprimantes. Dans ce cas, vous devrez utiliser le composant logiciel enfichable Office Communicator Web Access pour modifier le numéro de port.
Serveur du tronçon suivant
Enfin, vous devrez attribuer un « serveur du tronçon suivant » au serveur virtuel. Lorsqu'un utilisateur participe à une conférence, les messages doivent être transmis entre le serveur Office Communicator Web Access Server et le serveur central de l'utilisateur. Les utilisateurs anonymes (autrement dit, les utilisateurs qui n'ont pas de compte dans votre domaine Active Directory ou le domaine d'un partenaire fédéré) peuvent participer à des conférences. Toutefois, étant donné que les utilisateurs anonymes n'ont pas de serveur central, Office Communicator Web Access ne dispose d'aucun emplacement pour relayer les messages.
De ce fait, vous devez attribuer à chaque serveur virtuel un serveur du « tronçon suivant », c'est‑à‑dire un serveur (ou un pool de serveurs) qui peut jouer le rôle de serveur central pour les utilisateurs anonymes. Un serveur du tronçon suivant peut être tout ordinateur de la forêt qui exécute Office Communications Server 2007 R2.
Lorsque vous attribuez un serveur du tronçon suivant, assurez‑vous que ce dernier fonctionne correctement. N'attribuez pas un serveur du tronçon suivant qui est actuellement hors connexion ou qui va être mis hors connexion. Si le serveur du tronçon suivant échoue, le serveur Office Communicator Web Access échoue également. C'est pourquoi il est vous recommandé d'utiliser un pool de serveurs comme serveur du tronçon suivant. Ainsi, la panne d'un seul serveur n'entraînera pas la panne d'Office Communicator Web Access.
Encore une fois, notez que l'Assistant Installation vous permet de créer uniquement un serveur virtuel par ordinateur Office Communicator Web Access. Si vous souhaitez créer un second serveur virtuel sur ce même ordinateur (par exemple, pour qu'un serveur Office Communicator Web Access Server puisse prendre en charge des utilisateurs internes et des utilisateurs externes), vous devez, pour cela, utiliser le composant logiciel enfichable Office Communicator Web Access. Pour plus d'informations, consultez Création d'un serveur virtuel Office Communicator Web Access à l'aide du composant logiciel enfichable Office Communicator Web Access.