bonjour à tous,
Je suis actuellement en train d'installer un Lync EDGE dans une infrastructure EDGe existante. Il m'est nécessaire de configurer les certificats sur les interfaces externes de mon EDGE et de mon TMG (reverse proxy). Est il possible d'utiliser mon serveur interne de cetificats aussi pour ces interfaces externes ? en effet les utilisateurs sont connus et peuvent télécharger le certificat sur leur pc directement.

Bonjour,
 
Oui c'est possible de ce servir d'une autorité interne de certification.
Mais les gens qui voudrons accéder à LYNC depuis l'extérieur devront posséder les certificats.
 
Il existe des commandes pour générer la demande du certificat, il suffit d'aller valider ce certificat sur l'autorité interne.

Oui, par contre ça veut dire que tu ne fais pas de fédération ni de PIC, que l'ensemble des postes qui utiliseront lync de l'extérieur auront la chaine de certification.
 
Par contre tu devrais si possible publier la CRL

ok très bien merci, je vais ouvrir un nouveau topic je pense plutôt m'orienter vers l'achat de certif

non continue ici

Bonjour à tous,
 
Je suis actuellement entrain d'installer un serveur Lync EDGE dans ma boîte et il m'est nécessaire afin de sécuriser les accès aux serveurs de ma DMZ nécessaires à l'architecture EDGE d'utiliser un/des certificats SSL de type UCC (unificate comunication certif).
 
Ma boite est partenaire de la compagnie InstantSSL.com qui propose ce type de certificat:
http://www.instantssl.com/ssl-cert [...] e-ucc.html
 
Est ce possible d'acheter un unique certificat et de l'installer à la fois sur mon serveur ForeFront TMG et sur mon LyncEDGE ? je pense que j'aurais un problème dans le sens où le CN de l'entreprise est différent à chaque fois, (une fois ce sera le TMG et une autre pour le EDGE) non ?

Les sujets suivant ont été fusionnés à ce sujet par Je@nb

• Lync EDGE - Certificats externes nécessaires

Sauf si tu achètes un wildcard ou un certificat avec tous les SAN nécessaire, non sinon oui mais peu recommandé

ma société possède déjà un wildcard certificate je peux l'appliquer sur le TMG et utliser le UCC sur le EDGE ? ce serait l'idéal non ?

potentiellement oui, faut voir les domaines etc aussi.
 
J'ai plus en tête les prérequis vu le nb qu'il y a

pour les domaines on parle des FQDN à inclure dans les SAN ?

ouais

le mieux serait de modifier le wildcard existant (est ce possible ?) où d'acheter un second certificat ?

non voir si le wildcard suffit et un autre certificat pour l'edge (ou le wildcard aussi si ça passe mais je crois pas, faut regarder les docs)

pas pour le edge c'est sur, il faut obligatoirement un UCC pour ça. Je vais voir si c'est possible de modifier le wildcard, dans ce cas il faudrait simplement ajouter un champ SAN au certif avec l'enregistrement de mon reverse proxy ?

Bonsoir,
 
La wildcard est censé passé mais pas compatible avec tous les matériels (notamment les téléphones portable il me semble....)
 
voici un super article très complet d'un MVP Microsoft http://blog.schertz.name/2011/02/w [...] nc-server/ . Tu trouveras d'autres infos super intéressante !
 
Pour un LYNC externet, il faut 2 certificats SAN (1 avec 3 nom et 1 avec 4 nom)
Le nom principal du premier certif correspond au FQDN du serveur EDGE, les SAN correspondent au FQDN du rôle de webconf et le domaine SIP
Le nom principal du deuxième certif correspond au serveur web de la webapp et les SAN correspondent au dialin, meet et un autre mais je ne me souvient plus quoi...

Pour le premier je me doutais bien qu'il fallait acheter un UCC jusque là pas de soucis.

Par contre pour le deuxieme, il faut donc le faire correspondre avec mon reverse proxy (serveur web - web app), je dois acheter un deuxieme UCC ou je peux utiliser le wildcard ?

EDIT: ce que j'ai du mal à piger, c'est que je dois inscrire meet.mondomain.com et dialin.mondomain.com, mais ils ne sont pas accessibles de l'extérieur vu que celà désigne mon serveur Lync... qui lui est dans mon LAN et ne possède pas d'adresses IP publique et n'a donc pas d'enregistrement dns chez mon registrar... sinon à quoi celà sert il d'avoir un Edge si on le rend dispo de l'externe ?

En fait pour résumé, tu as un certificat à appliquer sur le serveur EDGE qui correspond à ton accès externe EDGE (register + webconf)
 
Et tu as un certificat pour la partie site web qui est effectivement hébergé sur le Front End dans ton réseau local. Là tu as le choix d'utiliser un reverse proxy ou d'attaquer directement le front End.
 
Je suis clair ou pas ?

Ah je vois, mais dans mon configuration je passe par un reverse proxy sous forefront TMG.
Donc deux certificats, deux UCC ?
 
- 1 pour le EDGE (client lourd) avec:
 
CN= edge.mondomaine.com
 
SAN= edge.mondomaine.com
SAN=webconf.mondomaine.com
SAN=av.mondomaine.com
 
 
- 1 pour le reverse proxy avec:
 
CN= webtmg.mondomaine.com
SAN=webtmg.mondomaine.com
SAN=meet.mondomaine.com
SAN=dialin.mondomaine.com
 
Ce que je pige pas, c'est que j'ai pas d'enregistrement comme jle disais dans le dns du registrar pour meet et dialin... mais uniquement dans mon dns interne (split brain dns d'ailleurs), est il nécessaire que ces adresse renseignées dans le certificat soit dispo depuis le net ? ou la config que j'ai renseignée au dessus suffit ?

personne n'a d'idée ?

SAN=meet.mondomaine.com
SAN=dialin.mondomaine.com
 
C'est 2 enregistrements sont bien des adresses publique ? Le nom de domaine est accessible via internet? Je vois pas trop où est ton problème...

non ils ne le sont pas justement... on doit rendre public des IP se situant dans mon LAN interne ?! J'ai alloué 4 IP publiques pour webconf/av/accesedge de mon lyncedge et une pour le webaccess de mon forefront et c'est tout.
Je dois aussi mettre en public mon Lync du LAN en public ?  

bon j'en suis au test de la connexion externe, j'ai installé mes certificats comme je le pensais au dessus on verra si ça coince à ce niveau là plus tard.

J'utilise le site Test OCS Connectivity, je passe les étapes de DNS, mon port TCP443 est bien ouvert, le SSLCertificate passe (j'ai coché de ne pas obligé un certificat trust), par contre l'étape:

"Testing the remote connectivity to Microsoft Lync Server through the Access Edge server sip.mondomaine.com on port number 443 to see if user moi@mondomaine.com can connect remotely. Specified Remote Connectivity test(s) to Microsoft Lync Server failed. Please examin this site:"

J'en arrive à une page technet avec pas mal de solutions différentes:

http://technet.microsoft.com/en-us [...] 13%29.aspx

Là où je pense déjà avoir un problème c'est dans le menu topology sur mon serveur Lync j'ai bien ma ligne "lync_edge", la réplication est validée par contre le status reste sur N/A... quelqu'un a une idée de où celà peut provenir ?

EDIT: Je précise que mes serveurs se ping évidemment, les routes sont faites sur mon EDGE et aucune gtw n'a été précisée...

C'est bien ça, tu as 4 IP publique (3 pour le EDGE et 1 pour le WebAccess)
Et dans le WebAccess tu as 3 sites différents (le meet, le dialin et le weblync).
 
Pour le OCS Connectivity, il ne faut pas trop s'y fier non plus, teste l'accès externe depuis un poste chez toi pour tester si ça fonctionne. Mois aussi j'avais des erreurs avec OCS Connectivity et mon infra marche.

Ok, pour le moment le plus important reste mon accès en client lourd EDGE, j'ai bien ma réplication qui est fait entre mon EDGE et mon Lync, le Get-CsManagementStoreReplicationStatus me le confirmant.

J'ai mes ports ouverts depuis l'extérieur et mon DNS ext "sip.mondomaine.com" pointe bien vers l'interface access de mon EDGE. Pourtant ça ne fonctionne pas... d'où celà peut il bien venir ?

en attendant d'avoir un certificat signé, j'ai mis un certif délivré par mon authorité de certif interne, ça peut venir de là ? Je dois certainement installé ce certif sur la machine qui veut 'y connecter au préalable ?

Oui, si ton certificat a été généré par ton autorité interne, il faut que tu installe le certificat racine de cette autorité interne sur un poste qui doit se connecter à ton serveur EDGE.
 
Tu dois placer ce certificat dans l'autorité racine de confiance du groupe ordinateur local, et là pas de soucis ! (ne pas oublier de mettre cette autorité sur ton serveur EDGE aussi, sinon tes certificats ne seront pas valide).

Je vois très bien, je suis tout de même en train d'établir un certificat sur un signe approuvé.
Normalement après celà mon client lourd pourra se connecter sans soucis ? en conf manuelle je dois rendre le "sip.mondomaine.com" en serveur externe (en cas de non entrée DNS SRV dans mon dns externe) ?

Si tu as une autorité reconnue genre verisign et digicert tu n'aura aucun souci.
 
Concernant le nom de domaine, j'imagine que tu parle de l'entrée SRV _sip._tls.mondomaine.com, je comprend pas bien la question là.

oui c'est exactement ça.
Niveau port j'ai ouvert mon 443 et mon 5051 pour le serveur SIP mais je n'ai pas de réponses et impossible de me connecter depuis l'extérieur... =/

Tu n'est pas obligé d'ouvrir le 5061, tu dois l'ouvrir seulement si tu veux utiliser la fédération.
 
Le 443 sur les 4 IP externe est obligatoire sinon ça risque de coincer dans certains firewall d'autres entreprises ! Et il ne faut pas oublier de déclarer dans le générateur de topologie l'IP publique de l'A/V sinon ça marchera pas bien.
 
Pour le SRV, il faut rentrer _sip._tls.mondomaine.com --> accessedge.mondomaine.com --> 443  
Sinon tu dois spécifier en manuel dans le client lync accessedge.mondomaine.com:443 si tu n'as pas d'entrée dans ton DNS externe

Ok très bien, c'est quoi exactement la fédération ? J'ai lu les tutos en long en large et en travers et il y a très peu d'explication là dessus.

Tu es l'entreprise A avec mondomaineA.com qui possède son Lync en interne, et donc tu peux rajouter en contact l'ensemble des personnes qui ont un compte sur ton Lync à toi.
 
Si maintenant une Entreprises B avec laquelle tu travailles possède aussi son Lync avec mondomaineB.com, en fédérant ton domaine et le sien, tu donne la possibilité à tes utilisateurs de rajouter des contacts de l'entreprise B et de leur fournir l'ensemble des fonctionnalités que tu as en interne à savoir audio, vidéo, présence, partage de contenu, etc...
 
Si tu regarde dans l'interface d'admin de Lync, tu verras qu'il existe des fédérations avec des domaines publiques bien connu comme Messenger ! Si tu autorise la fédération publique, tes utilisateurs qui ont Lync peuvent rajouter des contacts toto@live.fr et communiquer avec !
 
Voilà ce qu'est la fédération, c'est clair ?

Et faut les licences PIC aussi
 
Sinon, pour ton problème, je pense que tu aurais déjà tout résolu si tu avais suivi les prérequis expliqué très bien sur technet : http://technet.microsoft.com/en-us [...] 99001.aspx

d'accord très bien, très clair Merci beaucoup !    
J'espère que dès que j'aurai ce certif ça fonctionnera...

licences PIC ?
Je vais check avec ce lien

Les licences PIC sont gratuites pour messenger et aol (cf ce poste : http://blogs.technet.com/b/uc/arch [...] mains.aspx ) et je trouve que c'est une bonne chose de ne plus faire payer ça...
 
N'hésite pas s@mus si tu as encore des questions.

Je vais explorer tout ça, mais je veux juste que ma boite puisse accéder au Lync interne sans passer par un VPN et donc utiliser un edge (même le webaccess à la limite n'est pas très utile pour le moment), seul le client lourd est important.
 
Ton aide m'est très précieuse en tout cas !

Bon j'en ai presque fini (du moins je pense), avec le client lourd: le site www.testocsconnectivity.com arrive au bout en me disant que tout est ok par le port 443.
En revanche si j'utilise la connexion pour le port 5061 là le test échoue et n'arrive pas à trouver le service en face. J'ai installé un certificat UCC conforme (acheté chez comodo).
 
De plus, j'ai dans mon "event viewer" de Windows 2k8R2, une erreur qui apparait à chaque test avec le port 5061 (j'ai un Audit Success lors du test avec le port 443), un Audit Failure...
 
Faut il vraiment que ce port fonctionne pour que le client lourd Lync 2010 fonctionne ? j'ai indiqué sip.mondomaine.com dans le client pour être sur mais la connexion reste impossible...

Bonsoir,
 
Le 5061 est uniquement requis si tu fais de la fédération.  
Sinon pour l'accès au serveur EDGE c'est 3 IPs sur 443 pour passer à travers tous les firewalls d'entreprise.