Connexion du client Lync

Mais avant cela, il devra établir la couche TLS entre le serveur et lui-même. Là, rentrent en compte la présence des certificats & l’approbation des autorités de certifications par le client.

• CSIPTransportLayerSecurity::StartTlsNegotiationWorkitem TLS negotiation is in progress
• SECURE_SOCKET: security negotiation has completed, verifying server cert
• SECURE_SOCKET: security negotiation has completed successfully
• CSIPTransportLayerSecurity::OnTlsNegotiationComplete (1075168) successful. Raising OnConnect with S_OK

Une fois la couche TLS établie, le client Lync va commencer à s’authentifier. Le client Lync va ensuite envoyer au serveur la séquence d’authentification suivante.

• REGISTER sip:unifiedit.com SIP/2.0
Via: SIP/2.0/TLS 10.1.1.3:63820
Max-Forwards: 70
From: <sip:administrator@unifiedit.com>;tag=eb053a6695;epid=336bc55da8
To: <sip:administrator@unifiedit.com>
Call-ID: 7ca1d3241baf4e3db4983d6115ac36cf
CSeq: 1 REGISTER
Contact: <sip:10.1.1.3:63820;transport=tls;ms-opaque=36c715b616>;methods= »INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY »;proxy=replace;+sip.instance= »<urn:uuid:55A41DD0-7C24-5017-80AC-B0A0EDFCB3C0> »
User-Agent: UCCAPI/4.0.7577.4072 OC/4.0.7577.4087 (Microsoft Lync 2010)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking Supported: ms-cluster-failover
Supported: ms-userservices-state-notification
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Content-Length: 0

Et va se faire recevoir par un gentil :

SIP/2.0 401 Unauthorized Date: Fri, 23 Mar 2012 09:30:51 GMTWWW-Authenticate: TLS-DSK opaque= »426D0385″, gssapi-data= »

Car aucune méthode d’authentification n’a été négociée. Les trois méthodes possibles d’authentification sont par défaut les suivantes et sont activables ou pas.

WWW-Authenticate: Kerberos . Cette méthode est utilisée pour les membres d’un domaine. Elle utilise par conséquent les services Key distribution center pour les tickets Kerberos.

WWW-Authenticate: NTLM. Utilisée pour les utilisateurs membres d’un domaine dans le cas où un client ne peut pas se connecter à un contrôleur de domaine. Cette méthode est utilisée fréquemment dans le cadre des connexions externes de type Edge.

WWW-Authenticate: TLS-DSK (Transport Layer Security – Derived Shared Key). Cette méthode est celle utilisée par défaut par les clients Lync. Cette méthode est basée sur  l’utilisation d’un certificat client issu du pool front end Lync qui va authentifier l’utilisateur. Cette méthode utilise un mécanisme mathématique afin de déduire une clef de session utilisée par le client et le serveur sans échanger la clef partagée.

Dans le cas de la méthode TLS-DSK, vous pouvez retrouver facilement le certificat client en inspectant le magasin local de la station de travail. Ce dernier est issu directement du pool Lync.

La phase suivante est alors à la négociation de la méthode d’authentification. Le serveur va alors envoyer les diverses méthodes d’authentification possible. On notera que dans le cas où le client est un client externe (connexion vers un serveur Edge) alors le serveur ne renverra pas par défaut  la méthode d’authentification Kerberos.

Le serveur va présenter ses méthodes d’authentification. Le client Lync va alors choisir la méthode par défaut (TLS-DSK) et commencer son authentification vers le point de communication.A ce niveau-ci, nous avons constaté plusieurs variantes de comportements selon la façon dont le compte utilisateurs est paramétré dans l’Active Directory. Dans le cas d’une station de travail en dehors de l’organisation, si l’adresse SIP saisie par l’utilisateur est identique à l’UPN de l’utilisateur, alors le client Lync va simplement demander le mot de passe. Si cela n’est pas le cas alors le client Lync demandera le compte utilisateur et le mot de passe sous la forme Domain\utilisateur.L’authentification par certificat permettra ensuite au client Lync de se connecter sans demander le mot de passe utilisateur.

Une fois le client Lync connecté au serveur Lync (Frontal ou Edge) ce dernier va rechercher à récupérer des informations concernant les données d’agenda et de carnet d’adresses. Le client Lync va alors chercher à se connecter à des services Web comme ceux de Microsoft Exchange ainsi qu’à ces propres services. Concernant les données d’agenda de Microsoft Exchange, le client a en réalité deux moyens à sa disposition. Le client Mapi, autant dire Outlook, ou les services Web de Microsoft Exchange.
Les services Web de Lync sont notamment utilisés pour publier le service de carnet d’adresses, le développement des groupes de distribution et le contenu des conférences internes Externes.

Pour observer comment le client Lync est connecté à ces différents services et ce qu’il cherche, cliquez droit sur l’icône Lync en maintenant la touche contrôle activée et sélectionnez ensuite « Informations de configuration ».

Vous obtiendrez ensuite un tableau des connexions fort utile qui ressemble à peu près à cela : voir Club Abonnés, IT Pro Magazine, Juin 2012.

Ce précieux tableau vous permettra de connaître les différents accès que le client Lync va rechercher durant sa phase et de connexion et d’exécution.

Quelques problèmes courants que nous avons constatés

Le premier problème que vous risquez de constater est relatif à une amélioration de sécurité récemment apportée au client Lync 2010. Afin d’éviter des risques liés à la récupération des informations de connexion lors d’usurpation des services DNS (DNS Spoofing), la sécurité du client Lync a été renforcée. Dans le cas où le domaine de l’adresse SIP rentré par l’utilisateur diffère du domaine FDQN des services Lync alors le client va émettre un avertissement de sécurité et demander à l’utilisateur de confirmer.

Lorsque Lync a découvert le serveur sur lequel il doit se connecter, il le compare à la liste des domaines des serveurs auquel il fait confiance dans la clef de registre.

Si le domaine du serveur est dans la liste alors la connexion vers le serveur est établie. Dans le cas contraire le message d’avertissement est affiché. Mais pour mieux comprendre, prenons un exemple :

• Le SIP URI de l’utilisateur est Laurentt@unifiedit.com
• Le nom du serveur Lync est Fe01.paris.unifiedIt.local
• Nous avons placé un enregistrement A pour le serveur FE01.paris.unifiedit.local qui correspond à l’adresse IP 192.168.1.10
• Nous avons placé un enregistrement SRV pour du type _SipinternalTls._Tcp.unifiedit.com qui renvoi sur le Fqdn fe01.paris.unifiedIt.local pour permettre la découverte automatique puis la connexion
• La connexion automatique du client Lync est donc opérationnelle

Lorsque l’utilisateur va se connecter la première fois, le client Lync va automatiquement faire confiance au domaine UnifiedIt.com mais comme il va récupérer dans l’enregistrement SRV le domaine paris.unified.local qui ne sera pas considéré comme un domaine de confiance alors le message de dessus va apparaître.

Pour éviter cela, je ne serai que trop vous conseiller de paramétrer vos accès Lync et autres web services en concordance avec votre domaine SIP principal. Vous éviterez de ce fait ce désagrément.
Via des GPO, il est possible d’ajouter dans la configuration du client Lync les domaines de confiance. Mais d’expérience, nous avons constaté que cette fameuse clef n’est présente qu’après le premier démarrage du client.

Le second problème que nous avons pu constater et reproduit est lié à l’environnement XP SP3 et lorsque votre serveur Lync fonctionne sur un serveur Windows 2008 R2, ce qui risque d’être le cas désormais.
Le client Lync ne peut pas se connecter et affiche le message d’erreur suivant :

‘ms-diagnostics: 1000;reason=”Final handshake failed”;source=”Lyncpool.unifiedit”;HRESULT=”0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)”

Pour que cela fonctionne, vous devez changer deux paramètres de sécurité sur votre serveur frontal. Pour ce faire, suivez la procédure suivante :
1. Exécutez secpol.msc sur le serveur Frontal Windows Server 2008 R2
2. Sélectionnez Local Policies et cliquez sur Security Options.
3. Vérifier que sur les entrées ci-dessous que les valeurs soient fixées à « No minimum »

Network Security: Minimum session security for NTLM SSP based (including secure RPC)
Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

Puis redémarrer votre serveur frontal, votre client Lync Windows XP SP3 devrait normalement pouvoir se connecter.

En vous souhaitant un excellent et rapide dépannage des connexions clientes Lync 😉