Problèmes courants liés à la connexion automatique et à la découverte

Dernière rubrique modifiée : 2009-07-20

Lorsque vous tentez de résoudre des problèmes de connexion, un des premiers éléments à vérifier consiste à déterminer si l'utilisateur a saisi les informations appropriées. Vous devez ensuite vous assurer que le compte de l'utilisateur est un compte actif activé pour Office Communications Server. Si les informations utilisateur sont correctes, examinez la configuration côté serveur. À ce stade, déterminez en premier lieu si les paramètres de connexion du client sont définis de manière automatique ou manuelle. Cette section décrit certains des problèmes les plus courants rencontrés au cours de la connexion que ce soit du point de vue de l'utilisateur ou du point de vue du serveur.

Informations utilisateur incorrectes

Les scénarios suivants décrivent certains problèmes de connexion courants relatifs au compte de l'utilisateur ou aux informations que l'utilisateur spécifie lors de la connexion.

Adresse de connexion incorrecte

Lorsque vous essayez de vous connecter à Office Communicator, le message suivant s'affiche : « Impossible de se connecter à Office Communicator. L'adresse de connexion, le nom d'utilisateur ou le mot de passe spécifié est peut-être incorrect, ou le service d'authentification n'est pas compatible avec cette version du programme. ».

L'utilisateur essaie, par intermittence, de se connecter à l'aide d'une adresse qui ne correspond pas à l'URI SIP spécifié dans les propriétés Active Directory de l'utilisateur. Le format de l'URI SIP est déterminé par les administrateurs lorsqu'ils activent les utilisateurs pour Office Communications Server. L'URL SIP peut être généré à partir de l'adresse électronique de l'utilisateur, du nom principal de l'utilisateur, du nom complet ou du compte de gestionnaire de comptes de sécurité (nom d'ouverture de session utilisé dans les versions précédentes du système d'exploitation Windows). L'utilisateur doit essayer de se connecter à nouveau en utilisant le format SIP URI adapté.

Compte utilisateur non activé pour Office Communications Server

Si l'utilisateur a eu recours au bon format URI SIP, mais que la connexion échoue toujours, l'administrateur réseau doit vérifier que le compte utilisateur est activé, que l'utilisateur est activé pour Office Communications Server et que le mot de passe pour le compte n'a pas expiré ou n'a pas été redéfini.

Pour plus d'informations sur la configuration des comptes utilisateur, consultez la bibliothèque technique de Microsoft Office Communications Server 2007 R2 à l'adresse https://go.microsoft.com/fwlink/?Linkid=144479, sous Operations (Opérations) > (Administration d'Office Communications Server 2007 R2) > Managing User Accounts (Gestion des comptes utilisateur).

L'utilisateur n'a pas l'autorisation sur le dossier du profil

Si un utilisateur reçoit un message d'erreur lui indiquant que le serveur n'est pas disponible, activez l'enregistrement des événements Windows pour Office Communicator et vérifiez le journal de suivi d'événements Windows. Les journaux peuvent indiquer que l'accès a été refusé à la création du dossier Office Communicator sous C:\Documents and Settings\<nom de l'utilisateur>\Local Settings\Application Data\Microsoft. Pour remédier à ce problème, attribuez les droits appropriés à l'utilisateur pour le dossier Office Communicator.

Échec de la connexion avec une configuration manuelle

En mode de configuration manuelle, les problèmes de connexion proviennent généralement d'entrées de nom de serveur incorrectes dans les paramètres de connexion avancées figurant sur l'ordinateur client. Dans l'Observateur d'événements pour le client, le message « Communicator failed to connect to server 192.168.0.2 (192.168.0.2) on port 5060 due to error 10061 » s'affiche éventuellement ; ce message indique l'adresse IP d'un serveur auquel le client n'arrive pas à se connecter. Il se peut aussi que des références indiquent que le serveur présenté ne correspond pas au nom de l'hôte prévu. Ces erreurs se produisent souvent en raison d'une adresse IP du serveur saisie dans la boîte de dialogue Paramètres de connexion avancés.

Au lieu de saisir l'adresse IP du serveur ou un nom NetBIOS dans Paramètres de connexion avancés, entrez le nom de domaine complet du serveur.

Lorsque vous procédez à la configuration manuelle des paramètres de connexion, vous devez également prévoir si TLS est nécessaire à la connexion des clients au serveur Office Communications Server. Si TLS est requis, il est nécessaire de sélectionner l'option TLS dans la boîte de dialogue Paramètres de connexion avancés et de spécifier le nom de domaine complet du serveur (à la place de l'adresse IP du serveur ou du nom NetBIOS) de sorte que le nom du serveur corresponde aux certificats en vigueur.

Si les connexions au serveur font appel au protocole TCP, assurez-vous que les propriétés du pool d'Office Communications Server sont définies sur le port d'écoute TCP 5060.

Échec de la connexion avec une configuration automatique

En mode de configuration automatique, des problèmes liés à la configuration DNS, aux certificats ou encore à l'appellation du serveur peuvent se produire.

Configuration DNS

Si vous utilisez la configuration automatique, assurez-vous que le nom du serveur publié au format DNS (système de noms de domaine) est pris en charge par le certificat du serveur. Pour plus d'informations sur la création d'enregistrements DNS qui permettent la détection de clients et de serveurs, ainsi que la prise en charge de l'ouverture de session client automatique (si votre organisation souhaite la prendre en charge), consultez l'article « Domain Name System (DNS) Requirements » (en anglais) relatif à Microsoft Office Communications Server 2007 R2 à l'adresse https://go.microsoft.com/fwlink/?linkid=146936.

Lorsque les clients sont configurés pour une ouverture automatique de session, assurez-vous que les enregistrements DNS SRV appropriés existent. Lorsque vous utilisez une connexion TLS, ajoutez l'enregistrement SRV suivant et mappez-le sur l'enregistrement hôte du serveur :

_sipinternaltls._tcp.<domaine> over port 5061.

Remarque :
Si le domaine SIP est différent du domaine Office Communications Server, nous vous conseillons de créer un enregistrement hôte sip.<domaine> au lieu de l'enregistrement d'hôte Office Communications Server.

Lorsque vous utilisez une connexion TCP, ajoutez l'enregistrement SRV suivant et mappez-le sur l'enregistrement d'hôte du serveur :

_sipinternal._tcp.<domaine> over port 5060

Vérification stricte du nom

Si les clients font appel à la configuration automatique pour ouvrir une session et que TLS est requis, le paramètre de stratégie EnableStrictDNSNaming permet parfois d'analyser les échecs de connexion. Lorsque Office Communicator est configuré en mode de connexion automatique et que TLS est appliqué, cette stratégie permet à Office Communicator d'envoyer et de recevoir des messages instantanés en toute sécurité lors de l'utilisation du service de communications SIP. Cette stratégie n'a pas d'incidence sur les services Windows .NET ou Microsoft Exchange Server. La confusion relative à la stratégie EnableStrictDNSNaming provient la plupart du temps d'une description de stratégie ambiguë. Définir incorrectement cette stratégie risque de créer des problèmes inattendus lors de la négociation TLS ou de l'ouverture de session client. L'interprétation correcte de cette stratégie est la suivante :

Si vous définissez la stratégie EnableStrictDNSNaming sur Activé, les clients d'Office Communicator peuvent seulement se connecter à un serveur si son nom correspond au domaine URI SIP de l'utilisateur ou si son nom de domaine complet est sip.<domaine URI>. Si, par exemple, l'URI SIP de l'utilisateur est xyz@contoso.com, Office Communicator sera en mesure de se connecter aux serveurs suivants :

• contoso.com
• sip.contoso.com

Si vous ne configurez pas cette stratégie ou si vous choisissez Désactivé, les clients d'Office Communicator peuvent communiquer avec un serveur SIP dont le nom de domaine complet se termine par le domaine de l'URI SIP de l'utilisateur. Par exemple, Office Communicator sera en mesure de se communiquer avec les serveurs sip.division.contoso.com ou lc.contoso.com. L'inconvénient de cette méthode est qu'une personne malveillante peut répondre à la requête DNS initiale en utilisant un nom de serveur tel que intrus.contoso.com. Si vous ne configurez pas cette stratégie ou la désactivez, vous serez plus exposé aux attaques de l'intercepteur (« man-in-the-middle »).

Ne pas activer cette stratégie se justifie si votre organisation possède plusieurs sous-domaines et, lors de la configuration des certificats, si vous avez besoin d'une certaine souplesse dans l'attribution de noms de serveurs non stricts.

Pour activer cette stratégie, assurez-vous que le nom de domaine complet du serveur SIP correspond à un des formats stricts.

Remarque :
Vous pouvez configurer ce paramètre de stratégie sous Configuration ordinateur et sous Configuration utilisateur, mais le paramètre de stratégie sous Configuration ordinateur est prioritaire.

Les utilisateurs externes ne parviennent pas à ouvrir une session

Si les utilisateurs internes peuvent ouvrir une session alors que les utilisateurs externes rencontrent des difficultés pour le faire, il convient d'examiner la configuration des protocoles d'authentification, les ports spécifiés au cours de l'ouverture de session et les paramètres de chiffrement côté serveur.

Définir le protocole d'authentification sur NTLM et Kerberos

Office Communications Server 2007 R2 utilise le protocole Kerberos ou NTLM pour l'authentification selon l'emplacement de l'utilisateur. Le protocole Kerberos impliquant la connexion du client à Active Directory est utilisé pour les utilisateurs internes avec des informations d'identification Active Directory. Les utilisateurs externes disposant d'informations d'identification Active Directory qui se connectent à partir d'emplacements situés à l'extérieur du pare-feu de l'entreprise font appel au protocole NTLM.

Si les utilisateurs externes ne parviennent pas à s'identifier, assurez-vous que le protocole d'authentification figurant dans les propriétés de serveur frontal d'Office Communications Server est défini sur NTLM et Kerberos.

Ouverture de session manuelle du client sur le port 5061, écoute sur le serveur Edge d'accès 443

Les clients qui se connectent depuis l'extérieur d'un pare-feu d'entreprise utilisent le port 443 pour communiquer avec les servers Edge. Parfois, certains clients sont configurés pour se connecter au serveur en mode de configuration manuelle, alors que le serveur externe est configuré avec un port qui ne convient pas. Si, par exemple, un client est configuré manuellement pour se connecter à un serveur sur le port 5061 tandis que le serveur Edge d'accès écoute sur le port 443, la connexion échoue. Vérifiez les Paramètres de connexion avancés sous Nom ou adresse IP du serveur externe et assurez-vous que l'entrée spécifie le port 443, par exemple sip.domaine.com:443.

Spécifiez également le port 443 si vous utilisez une stratégie de groupe pour indiquer le nom du serveur externe.

Non concordance entre NTLMMINCLIENTSEC et NTLMMINSERVERSEC

Les organisations peuvent utiliser des stratégies locales et des stratégies de groupe pour configurer les paramètres de sécurité spécifiques dans des domaines du serveur Windows pour renforcer la sécurité. L'authentification NTLMv2 est un exemple de ce type de paramètre et peut être configuré pour exiger le chiffrement des communications entre les serveurs et les clients. Si les paramètres côté client et côté serveur ne correspondent pas, les communications ne peuvent pas être établies.

Les paramètres pour l'authentification NTLMv2 situés dans le Registre sont les suivants :

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_0ntlmminclientsec

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

Parfois, le serveur sera configuré de manière à utiliser le chiffrement, mais pas le client. Dans ce cas, la demande NTLM du client n'est pas transmise par le serveur frontal. Cette situation affecte principalement les utilisateurs externes, car NTLM est le seul protocole d'authentification qui permet aux clients externes d'ouvrir une session. Si, par exemple, la clé serveur est configurée pour avoir une valeur de 0x20080030 ce qui spécifie un chiffrement de 128 bits alors que les clients ne sont pas configurés ainsi, les clients seront incapables de se connecter. Il convient de s'assurer que cette clé sur le client est définie de manière à concorder avec le paramètre du serveur.

Pour plus d'informations, consultez l'article 823659 de la Base de connaissances Microsoft, « Incompatibilités entre les clients, les services et les programmes lorsque vous modifiez des paramètres de sécurité et des attributions des droits d'utilisateurs », à l'adresse https://go.microsoft.com/fwlink/?linkid=147230