Condividi tramite


Creazione di un server virtuale Communicator Web Access

Ultima modifica dell'argomento: 2009-03-06

Dopo avere installato e attivato Communicator Web Access (versione 2007 R2), è necessario creare almeno un server virtuale Communicator Web Access. Gli utenti possono utilizzare la messaggistica immediata, il servizio di audioconferenza o le altre funzionalità di Communicator Web Access solo se dispongono di un server virtuale a cui accedere.

Nota

In linea di massima, un server virtuale è semplicemente un sito Web. Se si accede a Communicator Web Access mediante l'URL https://im.contoso.com, tale URL non rappresenta solo un sito Web bensì un server virtuale Communicator Web Access. I server virtuali consentono a un singolo computer Internet Information Services (IIS) di ospitare più siti Web. Ad esempio, un solo computer potrebbe ospitare https://im.fabrikam.com e https://im.contoso.com.

Se si intende gestire le richieste di utenti interni, ovvero utenti protetti dal firewall dell'organizzazione, e di utenti esterni, ovvero utenti esterni al firewall dell'organizzazione, sarà necessario creare due server virtuali, uno per gli utenti interni e uno per gli utenti esterni. È possibile utilizzare la Distribuzione guidata per creare il primo server virtuale, quindi utilizzare lo snap-in Communicator Web Access per creare il secondo.

Nota

Se si gestiscono le richieste di utenti esterni, è consigliabile utilizzare un server proxy inverso per pubblicare il server virtuale nel Web. Per ulteriori informazioni sull'utilizzo di un server proxy inverso per pubblicare un server virtuale Communicator Web Access, vedere Utilizzo di un proxy inverso per abilitare l'accesso utente remoto. Inoltre, sempre per motivi di protezione, è consigliabile ospitare il server virtuale per gli utenti interni e il server virtuale per gli utenti esterni in computer separati.

Per creare il primo server virtuale in un computer, vedere la procedura descritta nella sezione "Per creare il primo server virtuale" in Creazione di un server virtuale Communicator Web Access mediante la Distribuzione guidata. Se si desidera creare un secondo server virtuale nello stesso computer, utilizzare lo snap-in Communicator Web Access. Per creare un secondo server virtuale in un computer, effettuare le operazioni seguenti:

  • Aprire lo snap-in Communicator Web Access, fare clic con il pulsante destro del mouse sul nome del server in cui deve essere creato il server virtuale, quindi scegliere Crea server virtuale.
  • Una volta visualizzata la Creazione guidata server virtuale, attenersi alla procedura utilizzata per creare il primo server virtuale nel computer.

Prima di creare un server virtuale, è necessario scegliere un metodo di autenticazione, un tipo di connettività e un server dell'hop successivo.

Metodi di autenticazione

Quando si crea un server virtuale, è necessario specificare i valori per diverse proprietà chiave, a partire dal meccanismo di autenticazione. In Communicator Web Access sono disponibili diverse opzioni di autenticazione.

Autenticazione tramite password integrata (NTLM/Kerberos)

Questa opzione rappresenta il tipo di autenticazione più sicuro con il minimo sforzo. Con l'autenticazione tramite password integrata, gli utenti non devono immettere né il nome utente né la password, in quanto vengono autenticati con le stesse credenziali utilizzate per accedere al proprio computer.

L'autenticazione tramite password integrata presenta però due svantaggi. In primo luogo, questo tipo di autenticazione può essere utilizzato solo con i server virtuali interni. Gli utenti esterni devono sempre fornire le credenziali, per cui nei siti che gestiscono le richieste di accesso esterno deve essere utilizzata l'autenticazione basata su form o l'autenticazione personalizzata.

In secondo luogo, l'autenticazione tramite password integrata può essere utilizzata solo da utenti che accedono da un computer che esegue Microsoft Windows e che utilizzano un Web browser che supporta l'autenticazione NTLM o Kerberos. Se tutti gli utenti sono utenti interni che utilizzano Internet Explorer e Microsoft Windows, sarà possibile utilizzare l'autenticazione tramite password integrata come unico meccanismo di autenticazione. In caso contrario, sarà necessario utilizzare sia l'autenticazione tramite password integrata che l'autenticazione basata su form oppure un metodo di autenticazione personalizzato.

Nota

Se si utilizzano entrambi i tipi di autenticazione, l'accesso a Communicator Web Access verrà eseguito utilizzando innanzitutto l'autenticazione tramite password integrata. In caso di esito negativo, l'accesso verrà quindi eseguito mediante l'autenticazione basata su form.

Autenticazione basata su form

Con l'autenticazione basata su form, quando un tenta di accedere al server virtuale Communicator Web Access, viene visualizzata una finestra di dialogo di accesso in cui l'utente deve immettere le proprie credenziali, quali dominio, nome utente e password, per poter essere autenticato e accedere quindi al sito. L'autenticazione basata su form consente di fornire supporto per:

  • Utenti Macintosh e Linux
  • Utenti che non utilizzano Internet Explorer
  • Utenti esterni, ovvero utenti che eseguono l'accesso dall'esterno del firewall dell'organizzazione

Lo svantaggio dell'autenticazione basata su form consiste nel fatto di non essere un meccanismo molto sicuro. Le credenziali dell'utente vengono ad esempio inviate al server come testo normale. Per questo motivo, è consigliabile utilizzare la connettività HTTPS per i server virtuali che consentono l'autenticazione basata su form.

Autenticazione personalizzata

Oltre ai meccanismi di autenticazione predefiniti del sistema operativo Windows, Communicator Web Access supporta inoltre metodi di autenticazione personalizzati o di terze parti. Communicator Web Access supporta ad esempio l'utilizzo dell'autenticazione a due fattori, in cui gli utenti devono presentare due elementi di identificazione (in genere una smart card e un PIN) per poter essere autenticati.

Communicator Web Access supporta inoltre l'autenticazione Single Sign-On, ma solo con Microsoft Internet Security and Acceleration (ISA) Server 2006. Con Single Sign-On, un utente può accedere una volta ottenendo l'accesso a più applicazioni. Un utente può ad esempio accedere a Microsoft Outlook Web Access e ottenere automaticamente l'accesso a Communicator Web Access o viceversa.

Nota

Se si utilizza l'autenticazione Single Sign-On, è necessario specificare l'opzione URL di disconnessione, ovvero un URL a cui viene reindirizzato l'utente al momento della disconnessione da Communicator Web Access. Visitando questa pagina, è possibile essere certi che tutti i cookie di autenticazione archiviati nel computer verranno eliminati. Per ulteriori informazioni, vedere la documentazione relativa al metodo di autenticazione personalizzato.

Tipo di connettività

Dopo avere specificato il meccanismo di autenticazione, è necessario definire il tipo di connettività. In Communicator Web Access sono supportati due diversi protocolli di connettività, HTTP e HTTPS. HTTPS è il protocollo consigliato in quanto più sicuro perché utilizza ad esempio la crittografia per tutto il traffico tra il server e il browser. Se si decide di utilizzare il protocollo HTTPS, è necessario assegnare un certificato a questa connessione. Per ulteriori informazioni, vedere Preparazione dei certificati per Communicator Web Access.

Nota

Il protocollo HTTPS è necessario se si intende implementare la condivisione del desktop. Se si accede a un sito Web di Communicator Web Access che utilizza il protocollo HTTP, il pulsante di condivisione del desktop risulterà disabilitato. Se si sposta il mouse sul pulsante, verrà visualizzata la descrizione comando "Per la condivisione del desktop è necessaria una connessione protetta (HTTPS). Contattare l'amministratore di sistema".

È inoltre necessario assegnare a ogni server virtuale un indirizzo IP e una porta. I server virtuali possono condividere gli indirizzi IP, ma non le porte. Ogni server virtuale deve avere una propria porta, ovvero una porta non utilizzata da un'altra applicazione. Per impostazione predefinita, viene proposta la porta 443 per le connessioni HTTPS e la porta 80 per le connessioni HTTP. Poiché queste porte corrispondono a quelle utilizzate dal sito Web predefinito in Internet Information Services (IIS), sarà necessario chiudere il sito prima di assegnarle a Communicator Web Access.

Come osservato, quando si crea un server virtuale, è necessario specificare una porta da utilizzare con il server. Se la porta specificata è già in uso da un'altra applicazione, verrà indicato che la porta è già stata riservata e verrà richiesto di selezionare un numero di porta diverso. Ad esempio, la porta 443 è utilizzata dal Sito Web predefinito in IIS. Se non si disabilita questo sito Web, non sarà possibile utilizzare la porta 443 come porta del server virtuale.

Tuttavia, Communicator Web Access non sempre riconosce le porte attualmente in uso da un componente di sistema Windows. Si supponga, ad esempio, di selezionare la porta 137 durante la creazione di un server virtuale. Viene consentito l'utilizzo di tale numero di porta e viene creato il server virtuale. Tuttavia, non sarà possibile avviare il nuovo server virtuale, poiché tale porta è utilizzata da Condivisione file e stampanti. In questo caso, utilizzare lo snap-in Communicator Web Access per modificare il numero di porta.

Server dell'hop successivo

Infine, sarà necessario assegnare al server virtuale un server dell'hop successivo. Quando un utente partecipa a una conferenza, vengono scambiati messaggi tra il server Communicator Web Access e il server principale dell'utente. Gli utenti anonimi, ovvero gli utenti che non dispongono di un account nel dominio Active Directory o nel dominio di un partner federato, possono partecipare alle conferenze. Poiché tuttavia gli utenti anonimi non dispongono di un server principale, non è presente alcun server utilizzabile da Communicator Web Access per l'inoltro dei messaggi.

Per questo motivo, è necessario assegnare a ogni server virtuale un server dell'hop successivo, ovvero un server o un pool di server che funge da server principale per gli utenti anonimi. Il server dell'hop successivo può essere un qualsiasi computer della foresta che esegue Office Communications Server 2007 R2.

Quando si assegna un server dell'hop successivo, assicurarsi che tale server sia attivo e in esecuzione. Non assegnare un server dell'hop successivo che è attualmente non in linea o che verrà posto in modalità non in linea. In caso di errore nel server dell'hop successivo, si verificherà un errore anche in Communicator Web Access. Per questo motivo, è consigliabile utilizzare un pool di server come server dell'hop successivo. In questo modo, l'errore di un singolo server non genererà un errore anche in Communicator Web Access.

Si noti che l'Installazione guidata consente di creare un solo server virtuale per ogni computer Communicator Web Access. Se si desidera creare un secondo server virtuale nello stesso computer, in modo che, ad esempio, un server Communicator Web Access possa supportare utenti sia interni che esterni, sarà necessario utilizzare lo snap-in Office Communicator Web Access. Per ulteriori informazioni, vedere Creazione di un server virtuale Communicator Web Access mediante lo snap-in Communicator Web Access.