About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2016/12/27

Server and Client OID with Skype (Lync 2013) Edge

The following is firmly in the “unsupported” range of topics. Follow this line of thinking at your own risk. Don’t blame me or anyone else should this go sideways on you. If this does not bother you, read on.

Scenario

I am working a side project that involves connecting Jabber and Lync 2013 (SfB would work also I suspect) using a mix of the Cisco guidance and Lync 2013 documentation. The intent is to create an inter-domain federation using Lync 2013 Edge services on one side, with the Jabber organization presenting services via an ASA using an ASA feature that provides a TLS proxy. Interesting, yes? Notice that I did not invoke the phrase XMPP. As in the XMPP is not being used. And this is IM/P only.

Here is what we are doing:

image

 

Why are we here?

Without stepping too far out on the edge of the cliff, this article is going to concern itself with one element of this construction – namely the requirement to establish the TLS connection between the ASA doing TLS proxy, and the Lync 2013 Edge server (or servers). Basically, it works as you would expect, however, the ASA is looking for a certificate that has both client and server OID codes. And it needs to trust the issuing CA.

Using a certificate from a public authority – well from DigiCert at any rate – will fill this requirement for you (I don’t have a cert handy from another vendor)(oops, I spoke too soon. Entrust, GoDaddy, and Verisign all do it also, but you should check your vendor to make sure). If you are doing a one-off, then you might be using your internal Windows Certificate Authority, which does NOT issue this duality by default. Nor does the standard certificate request generated by the Lync (SfB) wizard prompt you for this requirement – basically because it has no clue as to what you are fixing on doing!

So, what to do? Well, If you have a Windows Enterprise CA, then you are in luck. If you have the standard version, some bright individual will have to figure out how to make a standard edition CA allow for templates. No, I am not that bright.

With your Windows Enterprise CA firmly in hand, open the template editor.

clip_image001

Then, copy the existing “Web Server” template…

clip_image002

Change things around as needed… I don’t know all the implications of making random changes – so tread carefully on some of these items….

But, on the General Tab, you will want to change the “Template display name”, and the “Template name” to something easy to remember. In the “Template name” I suggest using something with no spaces…maybe like this?

clip_image003

After that, head over to the “Extensions” tab…select the “Edit” button…

clip_image004

Select “Add”

clip_image005

Select Client Authentication, and click the obvious button marked “OK”

clip_image006

OK again…

clip_image007

And, one more time on the “OK” button…

clip_image008

So, close the template manager, then right click “Certificate Templates” and choose New | Certificate Template to Issue…

clip_image009

From the resulting list, choose whatever it is that you called your new template, and do the “OK” thing…

clip_image010

…and now we have our squeaky clean new template ready for you to use. Finally.

clip_image011

Skype

Let’s now turn to the real reason we are here, and use this new template to get a certificate for our Edge Server. Yes, usually we will do a public cert, and we have already proved that the major public CA issuers will give us what we want – but we do need to test this in lab first – or you may be doing a one-off, yes?

Open the SfB Deployment Wizard… get yourself over to step three of “Install or Update Skype for Business Server System” and lean on the “Run Again” or “Run” option…

clip_image013

Select the external group, and do “request”…

clip_image015

Adjust the parameters to meet some common-sense items – like shorten up that friendly name – holy crap – but remember that you need the “Advanced” button down at the bottom…

clip_image016

Prepare request now, but…

clip_image017

Specify a file name…

clip_image018

Gees. Finally we are where all this has lead up to!

Specify your alternate template name now. And if you did not heed the advice to use a name with no spaces, my guess is going to be caps count, and don’t use the spaces. Cleverly, having run into this before, I know not to use long certificate template names and long CA names. Adelante! If you have been reading along (or not) you will see that my modified template name is WebServerAndClient…

clip_image019

…which plugs into the SfB Deployment Wizard thusly:

clip_image020

At this point, you can proceed normally. At last.

 

Clean it up

If you do use an internal certificate source for the outside of your edge server, you will need to provide a copy of the trusted root that issued your Edge certificate to anyone who is wanting to connect – hence the reason we use public certificates.  But, for our scenario, we placed the issuing root cert onto the ASA and wala!

 

Summary:

For whatever reason, you want to get a certificate for your SfB/Lync Edge Server that has both server and client OID authentication. We can fairly certain that public CA providers provide certificates with both by default. Windows Enterprise Certificate Authorities do not provide both OID’s by default – you must create and publish a custom certificate template. And we showed how to use that custom template with the SfB deployment wizard.

YMMV

No comments:

Coaching

Have you ever considered getting some help with professional development? Have you ever had someone, a co-worker perhaps, or a friend or fam...