Erstellen eines virtuellen Communicator Web Access-Servers

Authentifizierungsmethoden

Wenn Sie einen virtuellen Server erstellen, müssen Sie Werte für verschiedene Schlüsseleigenschaften, angefangen mit der Authentifizierungsmethode, angeben. Communicator Web Access stellt mehrere Authentifizierungsoptionen bereit.

Integrierte Kennwortauthentifizierung (NTLM/Kerberos)

Dies ist die sicherste Art der Authentifizierung, und diese Option erfordert den geringsten Aufwand. Bei der integrierten Kennwortauthentifizierung müssen Benutzer keinen Benutzernamen und kein Kennwort eingeben. Sie werden einfach mit denselben Anmeldeinformationen authentifiziert, die sie für die Anmeldung an ihrem Computer verwendet haben.

Die integrierte Kennwortauthentifizierung weist jedoch zwei Nachteile auf. Erstens kann diese Art der Authentifizierung nur für interne virtuelle Server verwendet werden. Externe Benutzer müssen ihre Anmeldeinformationen immer eingeben. Das bedeutet, dass Sites, die externe Anmeldeanforderungen verarbeiten, entweder die formularbasierte oder die benutzerdefinierte Authentifizierung verwenden müssen.

Zweitens kann die integrierte Kennwortauthentifizierung nur in den folgenden Fällen verwendet werden: Wenn sich die Benutzer von einem Computer anmelden, auf dem Microsoft Windows ausgeführt wird, und wenn sie einen Webbrowser verwenden, der die NTLM- oder Kerberos-Authentifizierung unterstützt. Wenn es sich bei allen Benutzern um interne Benutzer handelt, die Internet Explorer und Microsoft Windows ausführen, können Sie die integrierte Kennwortauthentifizierung als einzige Authentifizierungsmethode verwenden. Andernfalls müssen Sie neben der integrierten Kennwortauthentifizierung auch die formularbasierte Authentifizierung bereitstellen oder eine benutzerdefinierte Authentifizierungsmethode verwenden.

Hinweis:
Wenn Sie sowohl die integrierte Kennwortauthentifizierung als auch die formularbasierte Authentifizierung verwenden, versucht Communicator Web Access zuerst, einen Benutzer mit der integrierten Kennwortauthentifizierung anzumelden. Falls dies nicht funktioniert, kann sich der Benutzer mit der formularbasierten Authentifizierung anmelden.

Formularbasierte Authentifizierung

Wenn ein Benutzer auf einen virtuellen Communicator Web Access-Server zugreifen möchte, wird ihm bei der formularbasierten Authentifizierung ein Anmeldedialogfeld angezeigt. Der Benutzer muss die Anmeldeinformationen (also den Benutzernamen und das Kennwort) eingeben, um authentifiziert zu werden, sodass er auf die Website zugreifen kann. Die formularbasierte Authentifizierung ermöglicht die Unterstützung von:

• Macintosh- und Linux-Benutzern
• Benutzern, die nicht Internet Explorer verwenden
• Externen Benutzern (also Benutzern, die sich von außerhalb der Firewall der Organisation anmelden)

Die formularbasierte Authentifizierung hat den Nachteil, dass sie nicht sehr sicher ist. Die Anmeldeinformationen der Benutzer werden z. B. im Textformat an den Server übertragen. Aus diesem Grund wird dringend empfohlen, dass Sie das HTTPS-Verbindungsprotokoll für alle virtuellen Server verwenden, die die formularbasierte Authentifizierung zulassen.

Benutzerdefinierte Authentifizierung

Neben den im Windows-Betriebssystem integrierten Authentifizierungsmethoden unterstützt Communicator Web Access auch benutzerdefinierte Authentifizierungsmethoden oder Authentifizierungsmethoden von Drittanbietern. Communicator Web Access unterstützt z. B. die zweistufige Authentifizierung, bei der Benutzer zwei Angaben zur Identifizierung (in der Regel eine Smartcard und eine PIN-Nummer) bereitstellen müssen, um sich anmelden zu können.

Communicator Web Access unterstützt darüber hinaus die Authentifizierung per einmaliger Anmeldung (Single Sign-On, SSO), jedoch nur, wenn Sie Microsoft Internet Security and Acceleration Server (ISA) 2006 verwenden. Bei der einmaligen Anmeldung muss sich ein Benutzer nur einmal anmelden und erhält Zugriff auf mehrere Anwendungen. Wenn sich ein Benutzer z. B. bei Microsoft Outlook Web Access anmeldet, ist er automatisch auch bei Communicator Web Access angemeldet (und umgekehrt).

Hinweis:

Wenn Sie die SSO-Anmeldung verwenden, sollten Sie die Option Abmelde-URL angeben. Dabei handelt es sich um die URL der Website, zu der Benutzer nach ihrer Abmeldung von Communicator Web Access geleitet werden. Der Besuch dieser Site stellt sicher, dass alle Authentifizierungscookies gelöscht werden, die auf dem Computer des Benutzers gespeichert waren. Ausführliche Informationen finden Sie in der Dokumentation zu Ihrer benutzerdefinierten Authentifizierungsmethode.

Verbindungstyp

Nach Angabe der Authentifizierungsmethode müssen Sie den Verbindungstyp angeben. Communicator Web Access unterstützt zwei verschiedene Verbindungsprotokolle: HTTP und HTTPS. HTTPS ist das bevorzugte Protokoll, weil es sicherer ist. HTTPS verschlüsselt u. a. den gesamten Datenverkehr zwischen dem Server und dem Browser. Wenn Sie sich für die Verwendung von HTTPS (dem empfohlenen Protokoll) entscheiden, müssen Sie dieser Verbindung ein Zertifikat zuweisen. Ausführliche Informationen finden Sie unter Vorbereiten von Zertifikaten für Communicator Web Access.

Hinweis:

Das HTTPS-Protokoll ist eine Voraussetzung für die Implementierung der Desktopfreigabe. Wenn Sie sich bei einer Communicator Web Access-Website anmelden, die das HTTP-Protokoll verwendet, ist die Schaltfläche für die Desktopfreigabe deaktiviert. Wenn Sie den Mauszeiger über die Schaltfläche halten, wird eine QuickInfo mit folgendem Text angezeigt: Für die Desktopfreigabe ist eine sichere Verbindung (HTTPS) erforderlich. Wenden Sie sich an den Systemadministrator.

Sie müssen jedem virtuellen Server eine IP-Adresse und einen Port zuweisen. Virtuelle Server können gemeinsam eine IP-Adresse verwenden, sie können aber keinen Port gemeinsam verwenden: Jeder virtuelle Server muss über seinen eigenen Port verfügen. Dieser Port darf von keiner anderen Anwendung verwendet werden. Das Setupprogramm schlägt standardmäßig Port 443 für HTTPS-Verbindungen und Port 80 für HTTP-Verbindungen vor. Da diese Ports auch von der Standardwebsite in Internetinformationsdienste (Internet Information Services, IIS) verwendet werden, müssen Sie diese Site beenden, bevor Sie die Ports Communicator Web Access zuweisen können.

Wie bereits erwähnt, müssen Sie bei der Erstellung eines virtuellen Servers einen Port angeben, der von diesem Server verwendet wird. Wenn der angegebene Port bereits von einer anderen Anwendung verwendet wird, werden Sie vom Setupprogramm darüber informiert, dass der Port reserviert ist, und Sie werden aufgefordert, eine andere Portnummer auszuwählen. Port 443 wird z. B. von der Standardwebsite in IIS verwendet. Wenn Sie diese Website nicht deaktivieren, lässt das Setupprogramm die Verwendung von Port 443 als Port für den virtuellen Server nicht zu.

Communicator Web Access erkennt jedoch nicht immer, dass ein Port von einer Windows-Systemkomponente verwendet wird. Angenommen, Sie wählen bei der Erstellung eines virtuellen Servers Port 137 aus. Das Setupprogramm lässt die Verwendung dieser Portnummer zu und erstellt den virtuellen Server für Sie. Sie können den neuen virtuellen Server jedoch nicht starten. Das liegt daran, dass dieser Port von der Datei- und Druckerfreigabe verwendet wird. In diesem Fall müssen Sie die Portnummer mit dem Communicator Web Access-Snap-In ändern.

Server für den nächsten Hop

Schließlich müssen Sie dem virtuellen Server einen Server für den nächsten Hop zuweisen. Wenn ein Benutzer an einer Konferenz teilnimmt, müssen Nachrichten zwischen dem Communicator Web Access-Server und dem Homeserver des Benutzers hin- und hergeschickt werden. Anonyme Benutzer (d. h. Benutzer, die über kein Konto in Ihrer Active Directory-Domäne oder der Domäne eines Verbundpartners verfügen) können an Konferenzen teilnehmen. Anonyme Benutzer verfügen jedoch über keinen Homeserver und somit über keinen Server, an den Communicator Web Access Nachrichten senden kann.

Aus diesem Grund müssen Sie jedem virtuellen Server einen Server für den nächsten Hop zuweisen. Dieser Server (oder Serverpool) dient als Homeserver für anonyme Benutzer. Ein Server für den nächsten Hop kann ein beliebiger Computer in der Gesamtstruktur sein, auf dem Office Communications Server 2007 R2 ausgeführt wird.

Wenn Sie einen Server für den nächsten Hop zuweisen, stellen Sie sicher, dass der Server zur Verfügung steht. Weisen Sie keinen Server für den nächsten Hop zu, der zurzeit offline ist oder in Kürze außer Betrieb genommen wird. Falls beim Server für den nächsten Hop ein Fehler auftritt, tritt auch bei Communicator Web Access ein Fehler auf. Aus diesem Grund wird empfohlen, dass Sie einen Serverpool als Server für den nächsten Hop verwenden. Auf diese Weise führt der Ausfall eines einzelnen Servers nicht dazu, dass auch ein Fehler bei Communicator Web Access auftritt.

Hinweis: Beachten Sie, dass Sie mit dem Setup-Assistenten nur einen virtuellen Server pro Communicator Web Access-Computer erstellen können. Falls Sie auf demselben Computer einen zweiten virtuellen Server erstellen möchten (z. B. damit ein Communicator Web Access-Server sowohl interne als auch externe Benutzer unterstützen kann), müssen Sie den zweiten Server mit dem Communicator Web Access-Snap-In erstellen. Ausführliche Informationen finden Sie unter Erstellen eines virtuellen Communicator Web Access-Servers mit dem Communicator Web Access-Snap-In.

Siehe auch

Aufgaben

Erstellen eines virtuellen Communicator Web Access-Servers über die Befehlszeile