Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Posts Tagged ‘SSL’

Lync 2010 Certificat 101 – Suite

Posted by Anthony Costeseque sur mars 23, 2011


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

Publicités

Posted in Lync 2010 | Tagué: , , | 1 Comment »

Lync 2010 – Certificats SSL 101

Posted by Anthony Costeseque sur mars 10, 2011


Bonjour,

Aujourd’hui nous allons parler de la partie certificat dans Lync 2010 🙂 vaste sujet dans lequel on peut vite se perdre !!

Un peu de vocabulaire :

Enterprise/StandAlone CA (Certificate Authority) : Autorité de certification interne qui emmétra des certificats de confiance pour l’entreprise (le certificat de la CA (root) devra être déployé sur tous vos postes).

CA Public : Autorité de certification externe (VeriSign, DigiCert, …) qui emmétra des certificats de confiance pour tous (le certificat de la CA (root) est déjà présent sur tous vos postes).

Coté certificat on retrouve :

Un SN (Subject Name) = Le DN (Distinguished Name) complet (Exemple : CN=’Common Name’,O=Organization,L=Location,S=State,C=Country)

Un CN (Common Name) = un FQDN (Fully Qualified Domain Name)

Des SAN (Subject Alternative Name) = plusieurs FQDN


Passons maintenant au schéma de l’infrastructure que nous allons étudier.


Cette infrastructure (de petite taille) repose sur 1 Lync Server 2010 Standard Edition (avec tous les rôles (FE (Front End) MS (Media Server) A/V Conferencing) Co localisés) +

1 Reverse Proxy (TMG 2010) + 1 Lync Edge + 1 Exchange UM (pour la partie Voice Mail).

Le but étant de voir la partie certificat SSL, une fois comprise dans une installation de plus grande envergure, cela restera le même principe.

Nous distinguerons 3 domaines :

1 – La partie Reverse Proxy (certificat 1)

2 – La partie Edge (certificat 2 + 3)

3 – La partie FrontEnd/AVConferencing/MediaServer (certificat 4)

Alors c’est partie : Attention l’explication sera faite sur une infrastructure qui n’est pas en split-DNS (si non c’est trop facile ;p)

1 – La partie Reverse Proxy (certificat 1)

La partie reverse proxy permet de faire le lien avec les services web external hébergés sur le Front End.

 

Il faudra, pour commencer, configurer Lync dans le Topology Builder. le CN à utiliser sera composé de webext (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 webext.domaineSIP.fr


Au travers de webext.domaineSIP.fr nous pourrons accéder à toutes les virtual directory et web app du site « Lync Server External Web Site »

Pour terminer la partie Reverse proxy nous aurons aussi besoin des URL Simples :


Toujours dans le topology builder au niveau de l’organisation on retrouve les URL configurées. Les 2 CN sont composés de dialin et meet (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 dialin.domaineSIP.fr & meet.domaineSIP.fr

Note : vous voyez ici l’URL administrative pour l’accès à la console d’administration (en silverlight :p) le nom de domaine utilisé et le domaine interne car elle n’est accessible que de l’intérieur ! Si vous regardez le contenu du site web « Lync Server External Web Site » vous verrez qu’à la différence de « Lync Server Internal Web Site » la web app « cscp » n’est pas présente !


Maintenant que nous avons choisi nos CN passons au certificat :

Le certificat 1
que nous utiliserons sera demandé à une autorité externe publique de confiance (VeriSign, Digicert, etc) et comportera les informations suivantes :

CN = webext.domaineSIP.fr

SAN = webext.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr

Clef privée exportable et taille de clef 2048.

Notes : le CN doit aussi être présent dans les SAN ! Si vous avez plusieurs Standard Server, chacun devra avoir une external URL différente pour la partie web services ! si vous voulez utiliser qu’un seul port d’écoute web sur le TMG il faudra que toutes les URL soit présentes dans les SAN de ce certificat (exemple pour 2 Standard Edition on aura SAN = webext1.domaineSIP.fr, webext2.domaineSIP.fr,dialin.domaineSIP.fr,meet.domaineSIP.fr) ! Pour finir c’est au travers du reverse proxy que nous pourrons avoir accès à Lync Web App (web app « meet » du site web external) la version light du client Lync (en version web) !

Maintenant la génération de la demande : (nous le ferons à partir du FrontEnd)

A l’aide du shell powershell avec le module Lync de charger nous utiliserons la cmdlet « Request-CsCertificate »

Request-CsCertificate -New -Type WebServicesExternal -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync WebExternal Cert » -KeySize 2048 -PrivateKeyExportable $True -Organization « Votre Org » -Output C:\Certificates\WebServicesExternal.cer

Le contenu du fichier WebServicesExternal.cer devra être copié collé lors de votre demande de certificat sur l’autorité publique. Une fois le certificat délivré, il faudra l’importer (sur le FrontEnd) à l’aide de la commande :

Import-CsCertificate -Path « C:\Certificates\WebServicesExternal.cer » -PrivateKeyExportable $True

Le certificat, maintenant présent dans le magasin de certificat Personnel de l’ordinateur, pourra être exporté avec sa clef privée (dans un fichier .pfx) et importé dans le magasin de certificat personnel du TMG 2010 (partie ordinateur (pas utilisateur))

Ouf nous avons fini avec la partie Reverse Proxy 🙂

Passons à 2 – La partie Edge (certificat 2 + 3)

La partie Edge permet de connecter un client lourd Lync depuis l’extérieur de l’entreprise, au travers d’internet, de façon sécurisée !

De la même façon que pour la partie 1, nous aurons besoin de configurer Lync au travers du Topology Builder.


Dans cette configuration (que nous appellerons v1) j’ai choisi de mutualiser le CN et l’adresse IP que j’utilise pour publier les 3 services, j’ai donc besoin de définir 3 ports différents d’écoute.

Le CN mutualisé à utiliser sera composé de access (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 access.domaineSIP.fr


Dans cette configuration (que nous appellerons v2) j’ai choisi d’utiliser 1 CN distinct par service publié et donc 1 IP différente pour chaque, ils seront publiés sur le même port d’écoute (le port HTTPS par défaut tcp/443).

Le CN à utiliser pour chaque service sera composé de sip, webcon et av (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 sip.domaineSIP.fr & webcon.domaineSIP.fr & av.domaineSIP.fr

Maintenant que nous avons choisi nos CN passons au certificat :

Le certificat 2
que nous utiliserons sera demandé à une autorité externe publique de confiance (VeriSign, Digicert, etc) et comportera les informations suivantes :

Pour la configuration v1

CN = access.domaineSIP.fr

SAN = access.domaineSIP.fr,sip.domaineSIP.fr

Clef privée exportable et taille de clef 2048.

Pour la configuration v2

CN = sip.domaineSIP.fr

SAN = sip.domaineSIP.fr,webcon.domaineSIP.fr,av.domaineSIP.fr

Clef privée exportable et taille de clef 2048.

Notes : Nous voyons ici qu’entre la config v1 et la v2 nous avons 2CN pour 3CN ! Nous pouvons donc en économiser un (quand on voit le prix des certificats UCC (SAN) ce n’est pas un luxe :p) mais surtout dans un cas (la v1) nous avons besoin d’une IP publique alors que dans l’autre (la v2) nous en avons besoin de 3 !!

Maintenant la génération de la demande : (nous le ferons bien sûr à partir du serveur Edge)

Toujours à l’aide de la commande powershell « Request-CSCertificate »

Request-CSCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync Edge External Single Cert » -KeySize 2048 -PrivateKeyExportable $True -Organization « Votre Org » -DomainName « sip.domaineSIP.fr » -Output C:\Certificates\LyncEdgeExternalSingleCert.cer

Le contenu du fichier LyncEdgeExternalSingleCert.cer devra être copié collé lors de votre demande de certificat sur l’autorité publique. Une fois le certificat délivré, il faudra l’importer (sur le Edge) à l’aide de la commande :

Import-CsCertificate -Path « LyncEdgeExternalSingleCert.cer » -PrivateKeyExportable $True

Enfin il faudra l’activer pour les bons services : (il faudra utiliser le Thumbprint généré suite à l’import du certificat)

Set-CSCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint XXXX

Le certificat 3
(destiné au chalenge SSL de la partie interne (FrontEnd))
que nous utiliserons sera demandé à notre autorité de certification interne et comportera les informations suivantes :

CN = ls-edge.domaineLOACAL.local (fqdn interne de votre edge)

Pas de SAN !

Clef privée exportable et taille de clef 2048.

Note : ici le certificat est très simple.

Toujours à l’aide de la commande powershell « Request-CSCertificate »

Request-CSCertificate -New -Type Internal -CA « ServeurCA.domaineLOCAL.local\NomDeLaCA » -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync Edge Internal Cert » -KeySize 2048 -PrivateKeyExportable $True -Organization « Votre Org » -CAAccount « domaineLOCAL\administrateur » -CAPassword « VotrePassword »

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 Internal -Thumbprint XXXX

Ouf nous avons fini avec la partie Edge 🙂

Et pour finir 3 – La partie FrontEnd/AVConferencing/MediaServer (certificat 4)

Cette dernière partie va nous permettre de connecter nos clients lourds Lync à l’intérieur de l’entreprise de façon sécurisée !

La seule URL supplémentaire ici sera l’URL d’administration (pour accéder à CSCP (Communication Server Control Panel)) dont nous avons parlé dans la partie 1.

Ici pour le reste de l’explication nous utiliserons admin.domaineLOCAL.local

Le certificat 4
que nous utiliserons sera demandé à notre autorité de certification interne et comportera les informations suivantes :

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

Clef privée exportable et taille de clef 2048.

Note : ici le certificat comporte tous les CN que nous avons vus jusqu’ici.

Toujours à l’aide de la commande powershell « Request-CSCertificate »

Request-CSCertificate -New -Type Default,WebServicesInternal,WebServicesExternal -CA « ServeurCA.domaineLOCAL.local\NomDeLaCA » -Country FR -State « BdR » -City « Aix en Provence » -FriendlyName « Lync Single 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,WebServicesExternal -Thumbprint XXXX

Ouf nous avons tout fini :p

Bilan :

Pour la partie certificat destiné au publique (c’est là que c’est payant …) nous avons donc comme scénario possibles :

2 certificats : 1 pour TMG avec 3 CN et 1 pour Edge avec 2 CN en v1 et 3 CN en v2 -> On reste donc avec 2 certificat UCC (SAN) de moins de 5 CN !

1 certificat : le même pour TMG et Edge avec 5 CN pour la v1 et 6 CN pour la v2 -> Il tout à fait possible d’opter pour cette qui réduira les couts …

 
 

Le mot de la fin :

Maintenant lorsque vous lancerez l’assistant de certificats dans le setup de Lync vous saurez à quoi cela correspond !!



Et oui pour ceux qui sont arrivés au bout sans prendre l’Efferalgan 😉 vous avez bien vu que le certificat 1 pour le TMG pouvait se faire sur Lync mais pas avec l’assistant, uniquement dans le shell 🙂

Bonne lecture à tous et pour toutes questions n’hésitez pas.

Anthony Costeseque.

  

Posted in Lync 2010 | Tagué: , , | Leave a Comment »