Dans cette deuxième partie nous allons voir les subtilités avec l’introduction du rôle Director dans notre précèdent schéma !
On constate rapidement que cela nous fait 3 certificats en plus … mais le plus inquiétant est celui situé au niveau Reverse Proxy partie Externe (un port d’écoute supplémentaire) ! Nous allons voir le pourquoi du comment.
Un petit rappel sur les certificats déjà en place :
La partie Reverse Proxy (certificat 1)
CN = webext.domaineSIP.fr
SAN = webext.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr
La partie Edge (certificat 2 + 3)
Certificat 2
Pour la configuration v1
CN = access.domaineSIP.fr
SAN = access.domaineSIP.fr,sip.domaineSIP.fr
Pour la configuration v2
CN = sip.domaineSIP.fr
SAN = sip.domaineSIP.fr,webcon.domaineSIP.fr,av.domaineSIP.fr
Certificat 3
CN = ls-edge.domaineLOACAL.local (fqdn interne de votre edge)
Pas de SAN !
La partie FrontEnd/AVConferencing/MediaServer (certificat 4)
CN = ls-fe.domaineLOACAL.local (fqdn interne de votre FrontEnd)
SAN = ls-fe.domaineLOACAL.local,sip.domaineSIP.fr,webext.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr,admin.domaineLOCAL.local
Pour plus d’information je vous renvoie à mon précèdent billet sur les certificats au sein de Lync.
Maintenant passons au Director, tout d’abord il a pour but de :
Define the Director :
If you enable access for external users by deploying Edge Servers, you should also deploy a Director. A Director is a server running Microsoft Lync Server 2010 that authenticates user requests, but does not home any user accounts. When you use a Director to authenticate external users, it does the following:
Relieves servers in the Front End pool from the overhead of performing authentication of these users.
Helps insulate internal Front End pools from malicious traffic, such as denial-of-service (DoS) attacks.
Ends traffic at the Director when the network is flooded with invalid external traffic in a DoS or similar attack. As a result, internal users should not experience any effect on performance.
Le Director est une version allégée du front-end, il va s’occuper principalement de l’authentification et de la redirection vers le bon pool de l’utilisateur. Il contient donc, comme le FE, 2 sites web « Lync Server Internal Web Site » et Lync Server External Web Site »
Note : une différence importante entre l’utilisation du Director par les utilisateurs internes et externes est que, dans le cas d’un utilisateur interne, une fois que le Director renvoi le pool auquel il est rattaché lors d’une tentative de connexion, il se s’authentifiera à nouveau sur son pool ! (le Director sort de la boucle et là le client est bien en liaison directe avec son pool). Pour un utilisateur externe, le Edge forward la demande d’authentification au Director qui lui, s’il valide la demande, va établir une liaison sécurisée (MTLS) avec le pool ! (le Director dans ce cas reste dans le boucle et sert de proxy, il n’y a donc pas de double authentification de la part de l’utilisateur).
Sur technet on nous dit qu’il faut publier l’URL externe du FE mais aussi celle du Director au travers d’un mécanisme de Reverse Proxy (dans notre exemple à l’aide de TMG 2010 SP1) http://technet.microsoft.com/en-us/library/gg398069.aspx
Alors pour quoi ? Que se passe-t-il exactement ?
Un client externe qui essaie de se connecter résout l’enregistrement SRV _sip._tls qui pointe vers la partie access du serveur Edge (dans notre exemple : access.domaineSIP.fr), le nexhop du serveur Edge sera le Director.
Si le Director valide l’authentification, il établit la liaison MTLS avec le pool associé à l’utilisateur.
L’utilisateur va maintenant récupérer la configuration Lync ainsi que la partie Distribution Group Expansion, l’address book etc à partir de l’URL Externe du pool (pas du Director !)
Par contre étant donné que l’authentification est faite sur le Director, le WebTicket est généré dessus … et c’est à ce moment là qu’intervient l’URL Externe du Director ! s’il n’y a pas de point d’entrée sur le Director, la requête du certificat ne pourra pas aboutir et le WebTicket ne pourra pas être émis !
Pour finir, que deviennent les URL Simple ?! (dialin.domaineSIP.fr,meet.domaineSIP.fr)
Et bien pour n’avoir qu’un point d’entré il serait intéressant de les rediriger vers le Director pour exposer le moins possible le pool !
NOTE : coté TMG vous l’aurez compris, il faut un listener supplémentaire (donc un IP Publique de plus).
Maintenant voyons un peu la configuration :
La partie Director (certificat 6 et 7)
Il faudra, pour commencer, configurer Lync dans le Topology Builder. le CN à utiliser sera composé de webext2 (vous pouvez choisir ce que vous voulez) comme nom pour l’enregistrement A que nous créerons sur notre zone DNS hébergée chez notre registrar + votre domaine SIP.
Ici pour le reste de l’explication nous utiliserons webext2.domaineSIP.fr
Le certificat 6
que nous utiliserons sera demandé à notre autorité de certification interne et comportera les informations suivantes :
CN = webext2.domaineSIP.fr
SAN = webext2.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr
Clef privée exportable et taille de clef 2048.
Toujours à l’aide de la commande powershell « Request-CSCertificate »
Request-CSCertificate -New -Type WebServicesExternal -CA « ServeurCA.domaineLOCAL.local\NomDeLaCA » -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync Director External Cert » -KeySize 2048 -PrivateKeyExportable $True -Organization « Votre Org »
Le certificat est demandé en direct et sera directement importé, il nous suffira de l’activer avec le Thumbprint généré.
Set-CSCertificate -Type WebServicesExternal -Thumbprint XXXX
Le certificat 7
que nous utiliserons sera demandé à notre autorité de certification interne et comportera les informations suivantes :
CN = ls-director.domaineLOACAL.local (fqdn interne de votre Director)
SAN = ls-director.domaineLOACAL.local,sip.domaineSIP.fr,webext2.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr,admin.domaineLOACAL.local
Clef privée exportable et taille de clef 2048.
Toujours à l’aide de la commande powershell « Request-CSCertificate »
Request-CSCertificate -New -Type Default,WebServicesInternal -CA « ServeurCA.domaineLOCAL.local\NomDeLaCA » -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync Director internal Cert » -KeySize 2048 -PrivateKeyExportable $True -Organization « Votre Org » -DomainName « sip.vcloudconsulting.fr »
Le certificat est demandé en direct et sera directement importé, il nous suffira de l’activer avec le Thumbprint généré.
Set-CSCertificate -Type Default,WebServicesInternal -Thumbprint XXXX
La partie Reverse Proxy (certificat 1 et 5)
Concernant la partie reverse proxy nous allons modifier le le port d’écoute actuel (vu dans la configuration précédente) et ajouter un nouveau port d’écoute pour publier le Director.
Le certificat 1
que nous utilisions sera modifié et comportera les informations suivantes :
CN = webext.domaineSIP.fr
SAN = plus besoin !
Clef privée exportable et taille de clef 2048.
Le certificat 5
que nous utiliserons sera demandé à une autorité externe publique de confiance (VeriSign, Digicert, etc) et comportera les informations suivantes :
CN = webext2.domaineSIP.fr
SAN = webext2.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr
Clef privée exportable et taille de clef 2048.
NOTE : ces 2 certificats peuvent être le même pour économiser un peu.
Certificat possible (1 + 5) est utilisation du même certificat sur les 2 ports d’écoute TMG :
CN = webext.domaineSIP.fr
SAN = webext.domaineSIP.fr,webext2.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr
Nous voilà arrive au bout.
Nous avons fait le tour de toutes les possibilités concernant les certificats au sein d’une infrastructure Lync 2010.
Bonne lecture.
Anthony COSTESEQUE
Travailler ensemble 
1 commentaire