Connexion à Office Communicator et découverte

Dernière rubrique modifiée : 2009-04-02

Office Communicator doit déterminer le serveur auquel il doit se connecter à l'aide de l'URI de l'utilisateur (par exemple, jeremy@contoso.com) et des paramètres manuels configurés sur le client. Si les paramètres manuels sont fournis, le problème est résolu. Cependant, si l'URI était le seul indicateur, la découverte s'impose.

La découverte Office Communicator varie selon la configuration. Lorsque le client a découvert le serveur auquel il doit se connecter, il essaie d'ouvrir une session à l'aide du protocole TCP ou TLS sur TCP. S'il fait appel à TLS, le serveur fournit un certificat pour s'authentifier auprès du client. Le client doit valider le certificat avant de poursuivre. Le client peut négocier la compression (s'il utilise TLS sur TCP), puis lance l'inscription SIP.

Par la suite, le client envoie un message SIP REGISTER au serveur sans informations d'identification. Cette opération invite Office Communications Server à fournir les informations d'identification utilisateur et spécifie au client Communicator le protocole d'authentification qu'il accepte.

Au stade de la spécification des informations d'identification, Communicator a deux possibilités. Office Communicator utilise les informations d'identification Windows actuelles de l'utilisateur ou il invite l'utilisateur à spécifier ces informations.

Remarque :

Il est possible de recourir au gestionnaire des informations d'identification de Windows pour gérer les informations d'identification. Vous trouverez de plus amples informations sur le gestionnaire dans le kit de ressources de Windows XP au sein de l'article publié sur Microsoft TechNet : Assimilation des concepts d'authentification et d'autorisation à l'adresse https://go.microsoft.com/fwlink/?Linkid=133674, dans la section relative aux noms d'utilisateur et aux mots de passe.

Les échecs d'authentification peuvent se produire pendant la première partie du processus d'ouverture de session. En effet, il se peut que les informations d'identification ne soient pas enregistrées ou que les informations d'identification du Bureau ne concordent pas à celles du compte qu'Office Communicator essaie d'utiliser. Il est possible aussi que l'URI SIP, le nom du compte ou le mot de passe saisi soit incorrect ou encore que les informations d'identification ne concordent pas avec l'URI SIP. Imaginons, par exemple, que Jeremy essaie de se connecter à l'URI sip:jeremy@contoso.com. Il utilise le compte utilisateur et le mot de passe en vigueur pour CONTOSO\vadim au lieu de ses informations d'identification de propriétaire de compte, à savoir CONTOSO\jeremy.

Connaissance de la configuration automatique du client et de la découverte DNS

Pour les organisations qui envisagent d'utiliser la configuration automatique, une des exigences au cours du déploiement du serveur consiste à créer un enregistrement SRV DNS interne associant l'un des enregistrements suivants au nom de domaine complet du pool d'entreprise ou du serveur Standard Edition Server qui traite les demandes de connexion :

• _sipinternaltls._tcp.<domaine> (pour les connexions TLS internes)
• _sipinternal._tcp. <domaine> (pour les connexions TCP internes ; uniquement si l'utilisation de TCP est autorisée)

Lorsque la configuration automatique est définie pour un client, il utilise l'URI SIP fourni par l'utilisateur pour découvrir le serveur auquel il doit se connecter. Pour ce faire, Office Communicator fait appel aux enregistrements SRV DNS publiés pour la partie domaine de l'URI SIP.

Si, par exemple, l'utilisateur spécifie l'URI sip:jeremy@contoso.com, Office Communicator utilise contoso.com pour découvrir un serveur SIP qui utilise le DNS. Office Communicator inclut les enregistrements SRV suivants dans sa recherche d'un serveur approprié :

• _sipinternaltls._tcp.contoso.com
• _sipinternal._tcp.contoso.com
• _sip._tls.contoso.com

Si ces enregistrements n'existent pas, Office Communicator interroge les enregistrements de l'hôte (A).

• sipinternal.contoso.com
• sipexternal.contoso.com

La première interrogation recherche un serveur interne dans le domaine contoso.com offrant des ports prenant en charge le protocole TLS sur TCP. La deuxième interrogation tente de découvrir un serveur interne dans le domaine contoso.com offrant des ports TCP aux clients. Enfin, la troisième interrogation recherche un serveur accessible via Internet pour le domaine contoso.com offrant des ports qui prennent en charge TLS sur TCP. Office Communicator ne recherche jamais un serveur accessible via Internet qui prenne en charge le protocole TCP, car l'utilisation de texte en clair sur Internet n'est pas envisageable en termes de sécurité. Autrement dit, Office Communicator ne sait pas si le réseau qui est utilisé est interne ou externe. Office Communicator interroge tous les enregistrements DNS SRV. Toutefois, il essaie d'abord les connexions TLS sur TCP. L'utilisation du protocole TLS sur TCP est forcée au moyen d'un serveur de périphérie (il n'existe pas d'option autorisant les connexions TCP non sécurisées).

En dernier lieu, si aucun enregistrement DNS SRV n'existe (pas s'ils ne sont pas valides, mais uniquement s'ils n'existent pas du tout), le client revient au niveau de sipinternal.<domaine URI> et essaie de résoudre ce nom d'hôte. Si le nom d'hôte aboutit à une adresse IP, Office Communicator essaie de se connecter à l'aide du protocole TLS sur TCP, TCP ou des deux protocoles, selon la stratégie définie. Si cette opération échoue, il essaie une dernière fois avec sipexternal.<domaine URI>.

Des stratégies Office Communicator peuvent être mises en place pour empêcher l'utilisation de TCP et éviter ainsi l'exécution de la deuxième requête. La stratégie EnableStrictDNSNaming peut également être spécifiée et implique que les ordinateurs découverts correspondent strictement aux noms recherchés. Dans ce cas, Office Communicator est autorisé à se connecter à un serveur uniquement si son nom correspond au domaine de la partie domaine de l'URI SIP de l'utilisateur ou si son nom de domaine complet est sip.<domaine URI>. Si cette stratégie n'est pas activée, tout serveur au format <nom de serveur>.<domaine URI> est autorisé. Par exemple, pour sip:jeremy@contoso.com, l'hôte sip.contoso.com est toujours autorisé (stratégie stricte ou non). Server77.contoso.com, sipfed.contoso.com et ap.contoso.com sont tous autorisés si la stratégie d'appellation stricte n'est pas activée. Les noms de serveurs suivants ne sont jamais autorisés, car ils ne se conforment pas exactement au domaine de l'URI de l'utilisateur spécifié. Par conséquent, le client n'approuve pas ces serveurs comme points d'ouverture de session valides : sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com, etc.

La stricte validation du nom d'hôte et de l'URI s'effectue de manière spécifique car la seule configuration fournie au client est l'URI SIP. Pour cette raison, le client doit veiller à se prémunir des attaques du DNS en n'autorisant pas la connexion d'un intercepteur (man-in-the-middle) susceptible de surveiller le trafic d'Office Communicator. L'établissement d'une relation liant étroitement l'URI aux noms d'hôtes autorisés pour l'ouverture de session garantit à Office Communicator que le certificat que l'utilisateur valide réellement fait autorité sur le domaine auquel il tente de se connecter.

Après l'identification du nom d'hôte, Office Communicator résout également le nom d'hôte vers une adresse IP. C'est en général l'objet de la requête DNS SRV, mais tant que l'adresse IP n'est pas résolue, Office Communicator n'est pas habilité à se connecter. Cela peut poser un problème au cours de l'ouverture de la session.

La version la plus récente d'Office Communicator donne la possibilité de spécifier manuellement à la fois un serveur interne et un serveur externe pour l'ouverture de session. Office Communicator tente toujours de se connecter au serveur interne s'il est disponible, mais dans la négative, le serveur externe. Auparavant, Office Communicator ne disposait que d'une seule entrée manuelle, ce qui était problématique pour les employés itinérants. Grâce à la possibilité de spécifier manuellement un serveur interne et un serveur externe, il est désormais plus facile pour les administrateurs de configurer et activer les configurations d'ordinateurs portables transitant par les réseaux interne et externe. Cette fonctionnalité supplémentaire est également importante pour les entreprises lorsque le domaine figurant dans l'URI de l'utilisateur diffère de leur domaine de serveur d'entreprise SIP. Puisque l'administrateur configure Office Communicator (sur un ordinateur portable, par exemple) une seule fois, l'utilisateur n'a plus besoin de se rappeler des serveurs interne ou externe tandis que les administrateurs sont dispensés de publier des enregistrements DNS SRV pour tous les domaines à prendre en charge pour les utilisateurs d'accès distant.

Le client Office Communicator permet à l'utilisateur de se connecter automatiquement au serveur Office Communications Server approprié sans préciser le nom du serveur. Que le client soit au sein du réseau interne ou travaille à l'extérieur, cette fonction redirige le client et lui permet de s'identifier et de se connecter à son propre serveur Office Communications Server (Standard Edition) ou du pool central (Enterprise Edition). Cette fonction a une grande dépendance vis à vis du DNS. Pour fonctionner normalement, les enregistrements SRV appropriés doivent être publiés en interne et en externe.

Lorsque le client Office Communicator démarre pour la première fois et que l'utilisateur essaie de se connecter, Office Communicator essaie toujours de se connecter au pool de serveurs ou au pool central au sein du même domaine ou à l'aide du même URI SIP en guise d'adresse d'ouverture de session. Si, par exemple, le nom de connexion utilisé est kim.akers@fabrikam.com, Office Communicator recherche le pool central ou le serveur Office Communications Server dans le même espace de noms DNS, c'est-à-dire fabrikam.com. Ce processus est facilité par l'utilisation des enregistrements DNS SRV ; il désigne en dernier ressort au client le nom de domaine complet du pool central ou du serveur dans le domaine qui convient. Le processus fonctionne de la même manière si le client appartient à un réseau interne ou externe.

Le client commence à interroger les enregistrements SRV et, par défaut, il essaie toujours d'utiliser le protocole TLS à des fins d'authentification. Si le protocole TLS échoue, il utilise à ce moment-là le protocole TCP (Transmission Control Protocol).

• _sipinternaltls._tcp.fabrikam.com
• _sipinternal._tcp.fabrikam.com

Un de ces deux premiers enregistrements DNS doivent être publiés et disponibles dans l'espace de nom DNS interne. Ainsi, si le client obtient à ce stade le nom d'hôte, il se connecte directement au pool central ou au serveur Office Communications Server. Autrement, il poursuit son processus d'interrogation, sachant que l'élément recherché n'appartient pas au réseau interne.

• _sip._tls.fabrikam.com
• _sip._tcp.fabrikam.com

Si l'une de ces interrogations aboutit, le client est redirigé vers le périmètre externe du serveur Edge d'accès et par voie de conséquence vers le pool central interne ou Office Communications Server. En revanche, si le processus échoue encore, il effectue une ultime tentative visant à rechercher les enregistrements d'hôtes directement comme indiqué dans les deux exemples suivants. Si cette tentative de configuration des paramètres échoue automatiquement, Office Communicator échoue et exige une intervention manuelle.

• sip.fabrikam.com
• sipinternal.fabrikam.com