If you are preparing for a Lync installation, you will have to know your fair share of the technology Lync utilizes to operate. One of these technologies is certifications. Why am I bringing this up now? Lync has been around for a long time, and experienced UC guys know we also used certificates on earlier versions of LCS and OCS.
Well, as a consultant, I have had the pleassure of working with many implementations over the last two years. In many of these implementations I have met the most experienced of system administrators, who crouch when I start talking about certificates I need from them to complete a Lync installation.
What is so difficult, and hard to understand? I am in no way an expert of PKI, certificates or encryption. But I do grasp the concepts of encryption and trust, and I do believe if you try to look at it from a non-technical aspect, it might be easier to grasp.
I will give to really simple examples, and then talk about a few things a Lync administrator really should know about. You might find my example very silly, but it is an example I have used when talking about PKI in the classroom. Giving an analog comparison like this can sometimes help students get the concept.
The key
Encryption has been around for a long time. A lot longer than the IT business has been around. All it takes to send an encrypted message from one person to another in what seems to be a garbled code, is to hold the key.
A very simple example of this is the following string "12 25 14 3" which looks like 4 numbers. They are of course, a representation of the letters "L Y N C" "encrypted" with number replacement for letters as the "key". Where a=1, b=2 and so on. Servers and clients use a lot more complex encryption than the one in my example, but the using the "key" as the encoder and decoder is still the same.
The trust and verification
Before you let someone in, and agree to a secured channel where you will send important information to and from your computer, wouldn't it be nice to know the other end is actually who it claims to be?
Lets make a really simple example. As a kid, I was told not to talk to strangers. So whenever I was approached by strangers, I would not talk to them. Someone I had not seen in many years, and I did not recognized told me I should trust him because he was my grand father. Now how would I know if he could be trusted or not? My parents told me he was. Since someone I trusted confirmed the statement, I knew he was who he said he wan, and I could trust him.
Putting the examples together
Knowing now, that the man I was communicating with was my grandfather, because someone we both trusted said so. We could now start sending each other secret and encrypted messages with the key my grandfather gave to me.
Moving the "Analog examples" til the digital world of Lync
I like to compare the issuing Certificate Authority to my parents. They are someone I trust, and when they can confirm someones identity, I will believe they are who they say they are.
Next I compare the the services I access across the net/web as the strangers I do not know. I will ask them to present some sort of proof they are who they claim to be (i.e. a web URL), and if they (the strangers, services) in return give me a certificate issued by someone I trust (Issuing CA), I know they are who they claim to be, and I can proceed.
Simple enough, is it not?
Lync related tips and tricks.
Requesting, creating and assigning Lync certificates have been made very easy using the Lync Deployment Wizard. So easy, I would say, you do not need any understanding beyond the description above. But in the heat of the moment (when trying to keep up with ambitious deployment plans) it will not hurt to know a trick or two. Or at least be aware of certain conditions you might have to consider.
Before embarking on the installation, make sure you have read through, and understand the requirements:
http://technet.microsoft.com/en-us/library/gg398066
Internal servers:
- In all my deployments, I expect the customer to have an internal PKI deployment in place. You can deploy Lync without an internal PKI, but things are so much easier when you do have one.
- It is important that all clients trust the root and issuing CA by having installed these certificates in the client computer "Trusted Root Certification Authorities" in the local computer store (not user).
- If you deploy lyncdiscoverinternal, the mobile clients also have to trust the issuing chian described in the previous bullet.
- When selecting a CA to automatically request a certificate from, make sure you select an active node. If best practice is followed, the root CA will not be available (but possibly be listed first).
- Lync will request a certificate based on the 2000 server web certificate, make sure this is available to you.
- I always select "Mark the certificate private key as exportable". This way it is easy to backup, restore or move the service from one server to another. This is required when creating enterprise pools with more than one server.
- The "Organization Information" and the "Geographical information" really does not matter internally. but it is best practice to keep thing as close to fact as possible.
- I always select all my sip domains to be included in the Front End server SAN
- If you are deploying a fresh installation of Lync, using the RTM release, you can save yourself some time by adding the lyncdiscover.domain.com and lyncdiscoverinternal.domain.com in the initial request. If you do not, you will have to request a new certificate after deploying CU4 (or later) and adding the mobility service.
- I always use the deployment wizard on internal servers, but sometimes the issuing CA might not be available to you, and you might have to create an offline request and hand the file over to someone else.
Edge and TMG - External services
- Both the edge and the TMG server might or might not be domain members. If they are not, chances are they do not trust the internal issuing PKI. Make sure these servers trust the issuing PKI, just as the clients should (or you will be sure to run into problems).
- When requesting and buying a certificate from an online vendor, make sure you also trust them as you trust your internal PKI (I have run into certain vendors not included in the Windows server default setup)
- When requesting certificates for the internet facing interfaces, you can use your internal PKI. But this will render render your installation "useless" if you want to interop with other installation. Using public providers is the only real option.
- When requesting certificates for the internet facing interfaces, the "Organization Information" and the "Geographical information" really matters, and should match that of your domain. This will make the request so much easier to complete, and save you time.
- When requesting certificates, I tell the issuer the request is based on "other" (not IIS7). I have had less problems when doing so.
- If you do not know how to make a proper request on the TMG server (as it does not have the Lync deployment wizard). Just search for the following phrase in a search engine: "Manually Generating Certificate request Lync Reverse proxy " And you will surely find something to follow.
I hope this post has been helpful. And I will make updates it if something more should pop into my head.
Comments