{"id":378,"date":"2013-06-19T22:25:53","date_gmt":"2013-06-19T20:25:53","guid":{"rendered":"http:\/\/blog.lync2013.org\/?p=378"},"modified":"2014-05-07T13:20:02","modified_gmt":"2014-05-07T13:20:02","slug":"378","status":"publish","type":"post","link":"https:\/\/modern-workplace.uk\/?p=378","title":{"rendered":"Reducing The Costs of Lync Certificates. Mismatched Domains and Other Tricks"},"content":{"rendered":"

Disclaimer<\/span><\/h4>\n

The solution I will describe here is not a standard one, so you must consider all the possible risks, including future updates \/ fix for the Lync 2013 server or for the clients that could enforce the best practices that are not fully respected in this approach with results that I can\u2019t predict.<\/span><\/p>\n

\n

<\/h4>\n

Reducing The Costs of Lync Certificates. Mismatched Domains and Other Tricks
\n<\/span><\/h4>\n

Whenever you’re involved in a Lync project, you can be sure that the company you are working with will complain about the cost of SAN certificate required. If the infrastructure is shared between several different companies, you will have to add to the certificate more FQDN for the various SIP domains and the complaint will become sort of a howl.<\/span><\/p>\n

The changes in the Lync 2013 client autodiscover process (and also in the Lync 2010 client, as I will explain later) and the possibility to use mismatched domains between the SRV and Host (A) records open an interesting opportunity to downsize the required SAN names to a total of six (S I X).<\/span><\/p>\n

\n

 <\/p>\n

Our Scenario<\/span><\/h4>\n

Let\u2019s imagine to have two companies, Lync2013.Org and MCEnigma.Org that will use a single Lync infrastructure (for example using a common resource forest). We want to keep the cost of our SSL certificates as low as possible, so we need to reduce the SAN names required to make our external users work (for the internal users a lot of different solutions including certificates from an internal C.A. are available).<\/span><\/p>\n

A SIP domain for every company involved is required, so we will have to accommodate this in our solution.<\/span><\/p>\n

Note: the process I will explain can be used to address multiple SIP domains. To keep it simple, in the example, I used only two domains.<\/span><\/p>\n

\n

 <\/p>\n

First Step: Lyncdiscover<\/span><\/h4>\n

Lync 2013 client for Windows and Lync 2013 Windows Store App prefer to search lyncdiscoverinternal.<sipdoimain><\/i>\u00a0and lyncdiscover.<sipdomain><\/i>\u00a0for automatic sign-in.<\/span><\/p>\n

The aforementioned FQDN are A records. The first suggestion, here, is to point the Lyncdiscover record to the address of our reverse proxy and leave the port 80 of the reverse proxy opened.<\/span><\/p>\n

As you know, if your rules are well written, the server will retrieves resources on behalf of a client from the Lync Front End server on port 8080.<\/span><\/p>\n

Working this way, you need no certificate for the automatic sign-in<\/span><\/p>\n

\"Step1\"<\/a><\/p>\n

<\/h4>\n
\n

Second Step: _sip._tls.<sipdomain><\/span><\/h4>\n

The next step requires the record _sip._tls.<sipdomain><\/i> that you usually will point to the public FQDN of the Edge Server and you will have one FQDN for every domain.<\/span><\/p>\n

But we are going to keep our costs low, so we will point _sip._tls. Lync2013.Org<\/i> and _sip._tls. MCEnigma.Org<\/i> to SIP.Lync2013.Org<\/i><\/span><\/p>\n

Now, if your user\u2019s SIP domain is Lync2013.Org the aforementioned solution will work with no issue.<\/span><\/p>\n

What about MCEnigma.Org users ? Well, basically they will receive an error from their client, explaining that they are talking with a host that is not part of their SIP domain.<\/span><\/p>\n

They can \u201chide\u201d this message after the first time and they will be able to use Lync from the external network with no problem (you can also work on group policies to add Lync2013.Org to the list of trusted domains for MCEnigma.Org).<\/span><\/p>\n

For more details please read this article Lync cannot verify that the server is trusted for your sign-in address<\/a><\/span><\/p>\n

So, we no longer need a SAN in our certificate for the SIP record of every single domain.<\/span><\/p>\n

\"Step2\"<\/a><\/p>\n

 <\/p>\n

\n

Third Step: Webconf.<sipdomain><\/span><\/h4>\n

The aforementioned record is required for web conferencing BUT in our scenario we will need to publish only Webconf.Lync2013.Org<\/em><\/span><\/p>\n

Fourth Step: AV.<sipdomain><\/span><\/p>\n

Simply you do not need it, so you will not have to add it in the SSL certificate for any domain.<\/span><\/p>\n

Lync Server no longer requires that the AV Edge FQDN is provided in the certificate.<\/span><\/p>\n

Fifth Step: Simple URLs of Lync<\/span><\/p>\n

Here we are talking about meet.<sipdomain><\/i>,<\/i> dialin.<sipdomain><\/i> and admin.<sipdomain><\/i> that are the records required for the web services of Lync.<\/span><\/p>\n

Let\u2019s start from the latter admin<\/i>: if you have no intention to open the Lync Control Panel from the external network, you do not need it.<\/span><\/p>\n

Dialin<\/i>: you will have a single name (let\u2019s say dialin.lync2013.org) because multiple name for the dialin conferencing service are not supported.<\/span><\/p>\n

Meet<\/i>: as I explained here some time ago Understanding Simple URLs In Lync<\/a> you are able to use a single root FQDN and to create a specific URL for all the required SIP domains in a form like<\/span><\/p>\n

https:\/\/meet.lync2013.org\/sipdomain1\/Meet<\/em><\/span><\/p>\n

https:\/\/ meet.lync2013.org \/sipdomain2\/Meet<\/em><\/span><\/p>\n

\n

 <\/p>\n

Let\u2019s Summarize<\/span><\/h4>\n

The reverse proxy requires to have in the SSL certificate the public FQDN of the Lync Enterprise Edition Pool or the public FQDN of our Standard Editions servers in the subject name of the SSL certificate.<\/span><\/p>\n

The Lync Edge expects to have its public FQDN in the subject name of the certificate (you could use SIP that is required anyway or pick up another name).<\/span><\/p>\n

We may decide to require two different certificates<\/span><\/p>\n

_________________________________________________________________________<\/span><\/p>\n

Certificate 1 (to apply on the Reverse Proxy)<\/span><\/p>\n

Subject Name: FQDN of the Lync Front End<\/em><\/span><\/p>\n

SAN:\u00a0FQDN of the Lync Front End<\/em><\/span><\/p>\n

SAN: meet.<sipdomain><\/em><\/span><\/p>\n

SAN: dialin.<sipdomain><\/em><\/span><\/p>\n

_________________________________________________________________________<\/span><\/p>\n

Certificate 2 (to apply on the Lync Edge)<\/span><\/p>\n

Subject Name: FQDN of the Lync Edge<\/em><\/span><\/p>\n

SAN: sip.<sipdomain><\/span><\/p>\n

SAN: Webconf.<sipdomain><\/em><\/span><\/p>\n

_________________________________________________________________________<\/span><\/p>\n

As you can see we are able to deploy our external user access with a six names that we could decide to distribute as in the aforementioned schema or to put in a single certificate, with Subject Name\u00e8 FQDN of the Lync Edge and the FQDN of the Lync Front End added as a SAN.<\/span><\/p>\n

What About The Lync 2010 Client?<\/span><\/p>\n

Looking at this article \u201cUnderstanding Autodiscover<\/a>\u201d there is an important phrase: Additionally, <\/i>newer versions of the Lync 2010 <\/span><\/i>and Lync 2013 desktop client prefer Autodiscover over the domain name system (DNS) SRV records, using DNS SRV records only if lyncdiscover.<domain> or lyncdiscoverinternal.<domain> does not respond or does not resolve.<\/i><\/span><\/p>\n

The implication are clear: if you have done your homework and kept the Lync 2010 client up to date with the various C.U. and patches, the autodiscover process is the same you have with the Lync 2013 client. And the solution depicted here works also for the \u201clegacy\u201d clients<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

The changes in the Lync 2013 client autodiscover process (and also in the Lync 2010 client, as I will explain later) and the possibility to use mismatched domains between the SRV and Host (A) records open an interesting opportunity to downsize the required SAN names to a total of six (S I X).<\/p>\n","protected":false},"author":1,"featured_media":1221,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_sitemap_exclude":false,"_sitemap_priority":"","_sitemap_frequency":"","twitterCardType":"","cardImageID":0,"cardImage":"","cardTitle":"","cardDesc":"","cardImageAlt":"","cardPlayer":"","cardPlayerWidth":0,"cardPlayerHeight":0,"cardPlayerStream":"","cardPlayerCodec":"","footnotes":""},"categories":[18,19],"tags":[91,73,28,92,93,94,55,95,50,96,97,98,702,99,100,32,33,101,102,35,36,103,104,105,26,106,44,78,79,107,108,109,21],"class_list":["post-378","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-english","category-lync","tag-av","tag-cloud","tag-communication","tag-deploy-lync-2013","tag-deployment","tag-edge","tag-enterprise-features","tag-external-user-access","tag-fabrizio-volpe","tag-front-end","tag-lower-costs","tag-lower-lync-costs","tag-lync","tag-lync-2010","tag-lync-2013-2","tag-lync-2013-client","tag-lync-2013-server","tag-lync-best-practices","tag-lync-certificates","tag-lync-client","tag-lync-microsoft","tag-lync-mobile","tag-lync-multiple-domains","tag-lync-san","tag-lync-server","tag-microsoft-lync","tag-microsoft-lync-2013","tag-on-premises","tag-online","tag-requirements-for-lync","tag-sip","tag-webconf","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/posts\/378","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=378"}],"version-history":[{"count":2,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/posts\/378\/revisions"}],"predecessor-version":[{"id":1183,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/posts\/378\/revisions\/1183"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=\/wp\/v2\/media\/1221"}],"wp:attachment":[{"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/modern-workplace.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}