Häufige Probleme mit der Anmeldung und Erkennung

Letztes Änderungsdatum des Themas: 2009-07-20

Bei der Problembehandlung im Zusammenhang mit der Anmeldung sollte zunächst festgestellt werden, ob der Benutzer die richtigen Informationen eingegeben hat. Stellen Sie als Nächstes sicher, dass das Benutzerkonto aktiv ist und für Office Communications Server aktiviert wurde. Wenn das Problem nicht durch die Benutzerinformationen verursacht wurde, untersuchen Sie die serverseitige Konfiguration. Wenn Sie die Anmeldung auf der Seite des Servers untersuchen, prüfen Sie zuerst fest, ob die Clientverbindungseinstellungen auf automatische oder auf manuelle Konfiguration festgelegt wurden. In diesem Abschnitt werden einige häufige Probleme beschrieben, die bei der Anmeldung sowohl auf Benutzerseite als auch auf Serverseite auftreten können.

Falsche Benutzerinformationen

In den folgenden Szenarien werden häufige Anmeldeprobleme in Zusammenhang mit dem Benutzerkonto oder den eingegebenen Anmeldeinformationen des Benutzers veranschaulicht.

Falsche Anmeldeadresse

Wenn ein Benutzer versucht, sich bei Communicator anzumelden, wird u. U. die folgende Nachricht angezeigt: "Die Anmeldung bei Communicator kann nicht ausgeführt werden. Möglicherweise haben Sie die Anmeldeadresse, den Benutzernamen oder das Kennwort falsch eingegeben, oder der Authentifizierungsdienst ist mit dieser Version des Programms nicht kompatibel."

In vielen Fällen versucht ein Benutzer, sich mit einer Anmeldeadresse anzumelden, die nicht mit dem SIP-URI übereinstimmt, der in den Active Directory-Eigenschaften des Benutzers angegeben ist. Das Format für den SIP-URI wird vom Administrator festgelegt, wenn er Benutzer für Office Communications Server aktiviert. Die SIP-URL kann aus der E-Mail-Adresse des Benutzers, dem Benutzerprinzipalnamen, dem vollständigen Namen oder dem Konto des Sicherheitskonto-Managers (dem Anmeldenamen, der in älteren Windows-Betriebssystemversionen verwendet wird, SAM-Konto) generiert werden. Der Benutzer sollte versuchen, sich mit dem richtigen SIP-URI-Format erneut anzumelden.

Benutzerkonto nicht für Office Communications Server aktiviert

Wenn der Benutzer das richtige SIP-URI-Format eingibt und die Anmeldung trotzdem fehlschlägt, sollte der Administrator überprüfen, dass das Benutzerkonto aktiviert ist, dass der Benutzer für Office Communications Server aktiviert ist und dass das Kennwort für das Konto nicht abgelaufen ist oder zurückgesetzt wurde.

Weitere Informationen über das Aktivieren von Benutzerkonten finden Sie in der technischen Bibliothek von Microsoft Office Communications Server 2007 R2 unter https://go.microsoft.com/fwlink/?Linkid=144479 – unter "Operations > Administering Office Communications Server 2007 R2 > Managing User Accounts" (Vorgänge > Verwaltung von Office Communications Server 2007 R2 > Benutzerkonten verwalten).

Benutzer verfügt über keine Berechtigungen im Profilordner

Wenn ein Benutzer die Fehlermeldung erhält, dass der Server nicht verfügbar ist, aktivieren Sie die Windows-Ereignisprotokollierung für Communicator und prüfen das Protokoll der Ereignisablaufverfolgung von Windows. Bei der Erstellung des Communicator-Ordners unter C:\Dokumente und Einstellungen\<Benutzername>\Lokale Einstellungen\Anwendungsdaten\Microsoft wird für die Protokolle möglicherweise der Fehler "Zugriff verweigert" angezeigt. Sie können dieses Problem lösen, indem Sie dem Benutzer die entsprechenden Berechtigungen für den Communicator-Ordner erteilen.

Anmeldefehler bei der manuellen Konfiguration

Wenn bei einer manuellen Konfiguration Anmeldeprobleme auftreten, liegt das gewöhnlich daran, dass der Servername auf dem Client im Feld Erweiterte Verbindungseinstellungen falsch eingegeben wurde. In der Ereignisanzeige für den Client wird möglicherweise Folgendes angezeigt: "Communicator konnte aufgrund des Fehlers 10061 keine Verbindung mit dem Server 192.168.0.2 (192.168.0.2) am Port 5060 herstellen". Dies verweist auf die IP-Adresse eines Servers, zu dem der Client keine Verbindung herstellen konnte. Oder Sie erhalten Hinweise, dass der vom Server bereitgestellte Server nicht mit dem erwarteten Hostnamen übereinstimmt. Diese Fehler treten häufig auf, weil auf dem Client im Dialogfeld Erweiterte Verbindungseinstellungen eine Server-IP-Adresse eingegeben wurde.

Geben Sie im Dialogfeld Erweiterte Verbindungseinstellungen statt der Server-IP-Adresse oder eines NetBIOS-Namens den vollqualifizierten Domänennamen des Servers ein.

Wenn Sie Verbindungseinstellungen manuell konfigurieren, müssen Sie außerdem wissen, ob TLS für die Verbindungen zwischen den Clients und Office Communications Server erforderlich ist. Falls TLS erforderlich ist, muss die TLS-Option im Dialogfeld Erweiterte Verbindungseinstellungen ausgewählt sein, und der vollqualifizierte Domänenname des Servers muss angegeben sein (statt der Server-IP-Adresse oder des NetBIOS-Namens), damit der Servername mit den vorhandenen Zertifikaten übereinstimmt.

Wenn Verbindungen zum Server über TCP hergestellt werden, stellen Sie sicher, dass die Pooleigenschaften von Office Communications Server auf den TCP-Überwachungsport 5060 festgelegt sind.

Anmeldefehler bei der automatischen Konfiguration

Bei der automatischen Konfiguration können Probleme mit der DNS-Konfiguration, mit Zertifikaten oder der Benennung von Servern auftreten.

DNS-Konfiguration

Wenn Sie die automatische Konfiguration verwenden, stellen Sie sicher, dass der veröffentlichte Servername im DNS vom Serverzertifikat unterstützt wird. Informationen über die erforderliche Erstellung von DNS-Datensätzen, die die Erkennung von Clients und Servern ermöglichen, sowie über die Unterstützung der automatischen Clientanmeldung (wenn diese Option in Ihrer Organisation unterstützt werden soll) finden Sie im Microsoft Office Communications Server 2007 R2-Artikel "DNS-Anforderungen (Domain Name System)" unter https://go.microsoft.com/fwlink/?linkid=146936.

Wenn Clients für die automatische Anmeldung konfiguriert werden, stellen Sie sicher, dass die entsprechenden DNS-SRV-Einträge vorhanden sind. Fügen Sie bei Verwendung einer TLS-Verbindung den folgenden SRV-Eintrag hinzu, und ordnen Sie den SRV-Eintrag dem Hosteintrag des Servers zu:

_sipinternaltls._tcp.<Domäne> über Port 5061.

Dd637123.note(de-de,office.13).gifHinweis:
Wenn sich die SIP-Domäne von der Office Communications Server-Domäne unterscheidet, wird empfohlen, dass Sie statt des Office Communications Server-Hosteintrags einen Hosteintrag sip.<Domäne> erstellen.

Fügen Sie bei Verwendung einer TCP-Verbindung den folgenden SRV-Eintrag hinzu, und ordnen Sie den SRV-Eintrag dem Hosteintrag des Servers zu:

_sipinternal._tcp.<Domäne> über Port 5060

Strenge Namensüberprüfung

Wenn Clients eine automatische Konfiguration für die Anmeldung verwenden und TLS erforderlich ist, können Verbindungsfehler in manchen Fällen auf die Richtlinieneinstellung EnableStrictDNSNaming zurückverfolgt werden. Ist Communicator für die automatische Verbindungsherstellung konfiguriert und wird TLS erzwungen, ermöglicht die Richtlinie Office Communicator das sichere Senden und Empfangen von Sofortnachrichten, wenn der SIP-Kommunikationsdienst verwendet wird. Diese Richtlinie hat keine Auswirkung auf Windows .NET- oder Microsoft Exchange Server-Dienste. Ein Großteil der Verwirrung um die Richtlinie EnableStrictDNSNaming ist durch eine unklare Richtlinienbeschreibung entstanden. Wenn diese Richtlinie falsch festgelegt wird, können unerwartete Probleme mit der TLS-Verhandlung und der Clientanmeldung auftreten. Die richtige Beschreibung der Richtlinie lautet wie folgt:

Wenn Sie die Richtlinie EnableStrictDNSNaming auf Aktiviert festlegen, können Communicator-Clients nur dann eine Verbindung mit einem Server herstellen, wenn der Name mit der SIP-URI-Domäne des Benutzers übereinstimmt oder wenn der vollqualifizierte Domänenname sip.<URI-Domäne> lautet. Wenn der SIP-URI des Benutzers jemand@contoso.com lautet, kann Communicator nur eine Verbindung zu den folgenden Servern herstellen:

  • contoso.com
  • sip.contoso.com

Wenn Sie diese Richtlinie nicht konfigurieren oder Sie auf Deaktiviert festlegen, können Communicator-Clients mit jedem SIP-Server kommunizieren, der einen vollqualifizierten Domänennamen aufweist, der mit dem Domänenteil des SIP-URI des Benutzers endet. Communicator kann z. B. mit Servern mit dem Namen sip.division.contoso.com oder lc.contoso.com kommunizieren. Der Nachteil ist, dass ein Angreifer auf eine erste DNS-Abfrage mit einem Servernamen wie attacker.contoso.com reagieren kann. Wenn Sie diese Richtlinie nicht konfigurieren oder sie deaktivieren, sind Sie anfälliger für Man-in-the-Middle-Angriffe.

Ein Grund dafür, diese Richtlinie nicht zu aktivieren, liegt dann vor, wenn Ihre Organisation mehrere Unterdomänen aufweist und wenn Sie beim Einrichten von Zertifikaten die Flexibilität benötigen, dass für Servernamen keine strenge Zuordnung erforderlich ist.

Stellen Sie sicher, dass der vollqualifizierte Domänenname des SIP-Servers mit einem der strengen Namensformate übereinstimmt.

Dd637123.note(de-de,office.13).gifHinweis:
Diese Richtlinieneinstellung kann sowohl in der Computerkonfiguration als auch in der Benutzerkonfiguration vorgenommen werden, die Einstellung in der Computerkonfiguration hat jedoch Vorrang.

Externe Benutzer können sich nicht anmelden

Wenn sich interne Benutzer anmelden können, bei externen Benutzern aber Schwierigkeiten auftreten, kann das Problem an der Konfiguration der Authentifizierungsprotokolle, der Angabe der Ports bei der Anmeldung oder an serverseitigen Verschlüsselungseinstellungen liegen.

Sowohl NTLM als auch Kerberos als Authentifizierungsprotokoll festlegen

Office Communications Server 2007 R2 verwendet Kerberos- oder NTLM-Authentifizierungsprotokolle – abhängig vom Standort des Benutzers. Das Kerberos-Protokoll, das erfordert, dass Clients eine Verbindung mit Active Directory herstellen können, wird für interne Benutzer mit Active Directory-Anmeldeinformationen verwendet. Externe Benutzer, die zwar über Active Directory-Anmeldeinformationen verfügen, aber von außerhalb der Unternehmensfirewall eine Verbindung herstellen, verwenden NTLM.

Wenn externe Benutzer nicht authentifiziert werden können, stellen Sie sicher, dass das Authentifizierungsprotokoll in den Eigenschaften des Office Communications Server-Front-End-Servers auf NTLM und Kerberos festgelegt ist.

Manuelle Anmeldung des Clients über 5061, Überwachung des Zugriffs-Edgeservers über 443

Clients, die von außerhalb der Unternehmensfirewall eine Verbindung herstellen, verwenden Port 443 für die SIP-Kommunikation mit Edgeservern. Manchmal sind Clients so konfiguriert, dass sie eine manuelle Konfiguration verwenden, um eine Verbindung zum Server herzustellen, aber für den externen Server ist der falsche Port konfiguriert. Beispiel: Wenn ein Client manuell konfiguriert wurde, eine Verbindung zum Server auf Port 5061 herzustellen, während der Zugriffs-Edgeserver den Port 443 überwacht, kann keine Verbindung hergestellt werden. Prüfen Sie unter Externer Servername oder IP-Adresse die Option Erweiterte Verbindungseinstellungen des Clients, und stellen Sie sicher, dass der Eintrag Port 443 angibt, z. B. sip.domain.com:443.

Geben Sie Port 443 auch an, wenn Sie die Gruppenrichtlinien zur Angabe des externen Servernamens verwenden.

Unterschied zwischen NTLMMINCLIENTSEC und NTLMMINSERVERSEC

Organisationen können lokale Richtlinien und Gruppenrichtlinien verwenden, um bestimmte Sicherheitseinstellungen in den Windows-Serverdomänen zu konfigurieren und dadurch die Sicherheit zu erhöhen. Zu diesen Einstellungen gehört die Einstellung für die NTLMv2-Authentifizierung, die so konfiguriert werden kann, dass eine Verschlüsselung zwischen Servern und Clients erforderlich ist. Wenn die Einstellungen auf Clientseite nicht mit den Einstellungen auf Serverseite übereinstimmen, kann keine Kommunikation eingerichtet werden.

Die Einstellungen für die NTLMv2-Authentifizierung befinden sich in der Registrierung unter:

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_0ntlmminclientsec

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_ ntlmminserversec

Manchmal kommt es vor, dass der Server so konfiguriert ist, dass eine Verschlüsselung erforderlich ist, der Client aber keine Verschlüsselung benötigt. In einem solchen Fall wird die NTLM-Anforderung des Clients nicht durch den Front-End-Server weitergeleitet. Dieses Szenario betrifft vor allem externe Benutzer, weil NTLM das einzige Authentifizierungsprotokoll ist, das externe Clients für die Anmeldung verwenden können. Wenn der Serverschlüssel z. B. mit dem Wert 0x20080030 konfiguriert ist, der eine 128-Bit-Verschlüsselung angibt, und Clients nicht so konfiguriert sind, können Clients sich nicht anmelden. Stellen Sie sicher, dass dieser Schlüssel auf dem Client genauso wie auf dem Server konfiguriert ist.

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 823659 "Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit Clients, Diensten und Programmen auftreten" unter https://go.microsoft.com/fwlink/?linkid=147230.