Office Communicator-Anmeldung und -Erkennung
Letztes Änderungsdatum des Themas: 2009-04-02
Office Communicator muss anhand des Benutzer-URI (z. B. ) und manueller Einstellungen auf dem Client ermitteln, bei welchem Server die Anmeldung erfolgen soll. Wurden manuelle Einstellungen angegeben, ist der zu verwendende Server eindeutig. Wenn der URI jedoch die einzige Information ist, erfordert die Erkennung einige Schritte.
Die Communicator-Erkennung variiert basierend auf der Konfiguration. Nachdem der Client den Server für die Verbindung erkannt hat, wird versucht, eine Verbindung unter Verwendung von TCP oder TLS über TCP herzustellen. Bei Verwendung von TLS stellt der Server ein Zertifikat für seine Authentifizierung beim Client bereit. Der Client muss das Zertifikat überprüfen, bevor der Vorgang fortgesetzt werden kann. Der Client kann unter Umständen eine Komprimierung aushandeln (bei Verwendung von TLS über TCP) und anschließend eine SIP-Registrierung initiieren.
Als Nächstes sendet der Client eine SIP REGISTER-Meldung ohne Anmeldeinformationen an den Server. Daraufhin fordert Office Communications Server zur Eingabe von Benutzeranmeldeinformationen auf und gibt gegenüber dem Communicator-Client die akzeptierten Authentifizierungsprotokolle an.
Bei der Angabe von Anmeldeinformationen bietet Communicator zwei Optionen. Communicator kann die aktuellen Windows-Anmeldeinformationen zur Anmeldung verwenden oder den Benutzer zur Eingabe von Anmeldeinformationen auffordern.
.gif "Dd637152.note(de-de,office.13).gif") Hinweis: |
|---|
| Der Anmeldeinformations-Manager in Windows kann auch zur Verwaltung von Anmeldeinformationen verwendet werden. Weitere Informationen zum Anmeldeinformations-Manager finden Sie im Microsoft TechNet-Artikel im Windows XP Resource Kit: "Anmeldung und Authentifizierung" unter https://go.microsoft.com/fwlink/?Linkid=133674 (möglicherweise in englischer Sprache). Lesen Sie dort den Abschnitt zu gespeicherten Benutzernamen und Kennwörtern. |
Im ersten Teil des Anmeldevorgangs kann es zu Authentifizierungsfehlern kommen. Diese Fehler können auftreten, wenn die Anmeldeinformationen nicht bereits gespeichert sind oder wenn die Desktopanmeldeinformationen nicht mit dem Konto übereinstimmen, das Communicator verwenden möchte. Authentifizierungsfehler können auch dann auftreten, wenn der SIP-URI, der Kontoname oder das Kennwort falsch eingegeben wurden oder wenn Anmeldeinformationen und der SIP-URI nicht übereinstimmen. Ein Beispiel dafür ist, wenn Herr Koch versucht, sich mit dem URI sip:j.koch@contoso.com anzumelden, aber das Benutzerkonto und Kennwort für CONTOSO\v.adim anstatt der eigenen Anmeldeinformationen CONTOSO\j.koch verwendet.
Grundlegendes zur auotmatischen Clientkonfiguration und DNS-Erkennung
Unternehmen, die die automatische Konfiguration verwenden möchten, müssen bei der Serverbereitstellung einen internen DNS-SRV-Eintrag erstellen, der einen der folgenden Einträge mit dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Enterprise-Pools oder Standard Edition-Servers verknüpft, der Clientanmeldeanforderungen verarbeitet:
- _sipinternaltls._tcp.<Domäne> (nur für interne TLS-Verbindungen)
- _sipinternal._tcp. <Domäne> (für interne TCP-Verbindungen und nur, wenn TCP zugelassen ist)
Wenn der Client für die automatische Konfiguration eingerichtet ist, verwendet er den vom Benutzer bereitgestellten SIP-URI, um den Server für die Anmeldung zu ermitteln. Communicator führt dies mithilfe der DNS-SRV-Einträge aus, die für den Domänenteil des SIP-URI veröffentlicht werden.
Wenn der Benutzer z. B. den URI sip:j.koch@contoso.com eingibt, verwendet Communicator contoso.com zum Erkennen eines SIP-Servers, der DNS verwendet. Communicator sucht nach folgenden SRV-Einträgen, um den geeigneten Server zu ermitteln:
- _sipinternaltls._tcp.contoso.com
- _sipinternal._tcp.contoso.com
- _sip._tls.contoso.com
Wenn diese Einträge nicht vorhanden sind, führt Communicator eine Abfrage für A-Einträge des Hosts aus:
- sipinternal.contoso.com
- sipexternal.contoso.com
Bei der ersten Abfrage wird nach einem internen Server in der Domäne contoso.com gesucht, der Ports mit Unterstützung für TLS über TCP für Clients bietet. Bei der zweiten Abfrage wird nach einem internen Server in der Domäne contoso.com gesucht, der Ports mit Unterstützung für TCP-Ports für Clients bietet. Bei der dritten Abfrage wird schließlich nach einem über das Internet erreichbaren Server in der Domäne contoso.com gesucht, der Ports mit Unterstützung für TLS über TCP für Clients bietet. Communicator sucht nie nach über das Internet erreichbaren Servern, die TCP unterstützen, da die Verwendung eines Klartext-SIP im Internet keinen Nutzen in Bezug auf die Sicherheit bringt. Anders ausgedrückt kann Communicator nicht erkennen, ob das verwendete Netzwerk intern oder extern ist. Communicator führt Abfragen für alle DNS-SRV-Einträge aus. Dabei werden jedoch TLS über TCP-Verbindungen zuerst gesucht. TLS über TCP wird durch einen Edgeserver erzwungen (keine Möglichkeit, unsichere TCP-Verbindungen zuzulassen).
Wenn keine DNS-SRV-Einträge vorhanden sind (nicht, wenn sie nicht gültig sind; nur wenn wirklich überhaupt keine vorhanden sind), greift der Client auf sipinternal.<URI-Domäne> zurück und versucht, diesen Hostnamen aufzulösen. Wenn der Hostname in eine IP-Adresse aufgelöst wird, versucht Communicator die Verbindung mit TLS über TCP und/oder TCP herzustellen, je nachdem, was die Richtlinie zulässt. Bei einem Fehler wird ein letzter Versuch mit sipexternal.<URI-Domäne> ausgeführt.
Communicator-Richtlinien können eingerichtet werden, um die Verwendung von TCP zu verhindern, und dies verhindert die Ausführung der zweiten Abfrage. Die Richtlinie EnableStrictDNSNaming kann auch angegeben werden; diese erfordert exakte Namen für die erkannten Computer. In diesem Fall kann Communicator nur dann Verbindungen zu Servern herstellen, wenn der Name mit der Domäne im Domänenteil des SIP-URI des Benutzers übereinstimmt oder wenn der FQDN sip.<URI-Domäne> lautet. Wenn die Richtlinie nicht aktiviert ist, ist jeder Servername mit dem Format <Servername>.<URI-Domäne> zulässig. Für sip:j.koch@contoso.com ist der Host sip.contoso.com immer zulässig (auch bei strengen Richtlinien). Server77.contoso.com, sipfed.contoso.com und ap.contoso.com sind ebenfalls zulässig, wenn die strenge Benennungsrichtlinie nicht aktiviert ist. Die folgenden Servernamen sind niemals zulässig, da sie nicht genau der Domäne entsprechen, die durch den Benutzer-URI angegeben wird. Der Client vertraut diesen Servern daher nicht als gültige Anmeldepunkte: sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com usw.
Der genaue Abgleich zwischen dem Hostnamen und dem URI wird vor allem durchgeführt, da die einzige Konfiguration für den Client der SIP-URI ist. Daher darf der Client keine Man-in-the-Middle-Angriffe über DNS zulassen, wodurch andere Personen den Communicator-Verkehr beobachten könnten. Durch die enge Verbindung zwischem dem URI und den für die Anmeldung zulässigen Hostnamen hat Communicator eine höhere Gewissheit, dass das vom Benutzer zu überprüfende Zertifikat die Berechtigungen für die Domäne hat, bei der er sich anmelden möchte.
Nach der Identifizierung des Hostnamens löst Communicator auch den Hostnamen in eine IP-Adresse auf. Dies geschieht in der Regel als Ergebnis der DNS-SRV-Anforderung, aber bevor die IP-Adresse nicht aufgelöst ist, kann Communicator keine Verbindung herstellen. Dies kann auch ein Problem während der Anmeldung sein.
Die neueste Version von Communicator bietet die Möglichkeit, sowohl einen internen als auch einen externen Server für die Anmeldung manuell anzugeben. Communicator versucht immer, eine Verbindung mit dem internen Server herzustellen, sofern dieser verfügbar ist, sonst wird auf den externen Server zurückgegriffen. Bisher wies Communicator nur einen manuellen Eintrag auf, der Probleme für mobile Mitarbeiter mit sich gebracht hat. Durch die Möglichkeit, einen internen und externen Server anzugeben, ist es jetzt für Administratoren einfacher, Laptopkonfigurationen einzurichten und zu aktivieren, die übergreifend für interne und externe Netzwerke gelten sollen. Diese erweiterte Funktionalität ist auch für Unternehmen wichtig, bei denen der Benutzer-URI von der Domäne des SIP-Unternehmensservers abweicht. Da der Administrator Communicator einmal konfigurieren kann (z. B. auf einem Laptop), braucht sich der Benutzer nicht die internen oder externen Server zu merken, und Administratoren müssen keine DNS-SRV-Einträge für alle Domänen veröffentlichen, die Remotebenutzer unterstützen sollen.
Der Office Communicator-Client ermöglicht dem Benutzer die automatische Herstellung einer Verbindung mit einem geeigneten Office Communications Server-Computer ohne Verwendung des Servernamens. Der Client wird unabhängig davon umgeleitet, ob er sich innerhalb oder außerhalb des Netzwerks befindet. Er wird gegenüber dem eigenen Office Communications Server-Computer (bei Standard Edition) oder gegenüber dem Homepool (bei Enterprise Edition) authentifiziert und kann eine Verbindung mit diesem herstellen. Dieses Feature hat eine hohe DNS-Abhängigkeit. Für eine einwandfreie Funktionsweise müssen die entsprechenden SRV-Einträge sowohl intern als auch extern veröffentlicht werden.
Wenn der Office Communicator-Client das erste Mal gestartet wird und der Benutzer versucht, eine Verbindung herzustellen, versucht Office Communicator, die Verbindung mit dem Server oder Homepool in der gleichen Domäne herzustellen oder sie unter Verwendung des gleichen SIP-URI wie in der Anmeldeadresse herzustellen. Wenn der verwendete Anmeldename z. B. lautet, sucht Office Communicator nach dem Homepool oder Office Communications Server-Computer im gleichen DNS-Namespace (fabrikam.com). Dieser Prozess wird durch die Verwendung von DNS-SRV-Einträgen vereinfacht, die den Client letztendlich auf den FQDN des Homepools oder Servers in der richtigen Domäne verweisen. Der Vorgang ist für interne und externe Netzwerke gleich.
Die Client beginnt mit der Abfrage von SRV-Einträgen und versucht standardmäßig immer, TLS für die Authentifizierung zu verwenden. Nur wenn TLS fehlerhaft ist, wird auf das Transmission Control-Protokoll (TCP) zurückgegriffen.
- _sipinternaltls._tcp.fabrikam.com
- _sipinternal._tcp.fabrikam.com
Einer dieser beiden ersten DNS-Einträge sollte veröffentlicht werden und im internen DNS-Namespace zur Verfügung stehen. Wenn der Client den Hostnamen erhält, stellt er eine direkte Verbindung zum Homepool oder Office Communications Server-Computer her. Oder er setzt den Abfragevorgang fort, wenn er sich gerade nicht im internen Netzwerk befindet.
- _sip._tls.fabrikam.com
- _sip._tcp.fabrikam.com
Wenn eine dieser Abfragen erfolgreich ist, wird der Client auf den externen Edgeserver des Zugriffs-Edgeservers und danach zum internen Homepool oder zum Office Communications Server-Computer umgeleitet. Wenn jedoch weiterhin Fehler auftreten, werden als letzte Lösung die Hosteinträge direkt gesucht, wie in den folgenden beiden Beispielen. Wenn dieser Versuch der automatischen Konfiguration der Einstellungen fehlerhaft ist, schlägt Office Communicator fehl und der Benutzer muss eingreifen.
- sip.fabrikam.com
- sipinternal.fabrikam.com