If the default Zeacom System Administrator (or System Admin) credentials for your deployment have not been changed, they should be:

• Login Name: System Admin
• Password: 2222

New July 2014 Lync Phone Edition updates: http://support.microsoft.com/kb/2973941

This cumulative update resolves the following issue:
2973943 Update for Lync Phone Edition to accommodate daylight saving time (DST) in Egypt and Morocco

Update: Sophos released an official guide on how to get Lync Web Services to work over the UTM’s WAF. https://sophserv.sophos.com/repo_kb/120454/file/Configuring%20UTM%20firewall%20for%20Lync%20connectivity.pdf

Using a Sophos UTM or Astaro Security Gateway (ASG) appliance? You can use it to reverse proxy to your Lync front ends!

v8 a feature called Web Application Firewall, which is a nicely wrapped version of Apache mod_proxy, and can be configured to reverse proxy your Lync Mobility and simple URLs, Office Web Apps and can also work with Exchange and pass Outlook Anywhere. The added benefit is that you can configure rules to block Cross-Site Scripting (XSS) and SQL Injection type attacks, among other things.

If you have the subscription, here’s how you set it up with Lync 2013:

Configure your Lync Front Ends as Real Webservers. You will need to configure two servers for each FE, one for 8080 and another for 4443. If you plan on using the proxy for internal loopback (to avoid cert conflicts), then you will need 4 real servers, one for each port (80, 443, 4443, 8080). If you only want SSL, then skip the 80 and 8080:

Then configure your Virtual Web Server (I will assume you already uploaded a valid certificate to the Sophos appliance). Make sure to check Pass Host Header, and you can enable HTTP redirection so your end users are happy when they skip HTTPS prefixes.

Save it, enable it, and DONE!

NOTE: If you have issues with the Lync iOS client resetting the connection, you can increase the timeout on the Real Webservers to 960 or 1200, but you will need to be on firmware version 9.204-19 or greater, since the feature was introduced then.

Both Lync and Exchange rely heavily on public-key encryption using X.509 certificates (commonly known as SSL Certificates), and so they are required in every implementation. Regardless of whether you are using a public certification authority like DigiCert, or host your own internal CA, generating, installing and managing certificates can get pretty complex, especially when you have to deal with Intermediate Certificates.

Certificate Chains can be a confusing concept and hopefully I do a good job in trying to explain them with a real-world analogy. Here goes:

Let’s say you are John Doe, a fellow citizen that obeys the laws and respects the rules and guidelines put forth by society, and you’ve been asked to make a State of the Union speech on national television. Sounds crazy, I know, but I had a hard time coming up with a better situation… (comments?)

Here’s one issue to tackle as soon as you show up on that big screen: “Who’s THIS guy?”. You begin your speech, and in the first few statements you say that you’ve been granted authority to speak by Senator Joe Smith, and that any questions of authority should be directed to him. Officially, the Senator endorsed (or signed for) you, John Doe the citizen.

Now, most people may not know Senator Joe Smith, but they do know the President of the United States. If you were to call the Senator and ask him for his authority or credentials, he will say he has been granted permission to act on the President’s behalf for the purpose of assigning someone to speak at the State of the Union speech. In other words, the President endorsed (or signed for) the Senator, who in turn signed for you.

If we were to break this down, John Doe citizen is the holder of the end LEAF certificate, the Senator is the INTERMEDIATE authority, and the President is the ROOT Certification Authority… Makes sense so far?

You were never technically granted authority to speak directly by the President. In fact, you were never in contact with him, and were only granted authority by an intermediary that has been endorsed by him. In this case, the CHAIN is:

Root (President) >Intermediary (Senator) > You (Citizen).

If during the initial stages of your speech you were to have said the President gave you authority, and everyone went to check with him, they would find that statement to be false. The President never directly endorsed YOU, therefore the chain is broken and cannot be validated. There’s something missing, and that’s the information about the intermediary. If you never send that chain information, some (or most) will not trust you, even if you claim to be authentic.

What does that mean in IT terms? Make sure your certificate chain is followed, and organize your certificates properly in your Certificates MMC on each system that presents them. Follow these rules:

• Root CA certificates will always be self-signed and must be placed on the Trusted Root Certification Authorities store.
• Intermediate CA certificates will be signed by a Root CA or another Intermediate CA, and must be placed on the Intermediate Certification Authorities store.
• Your own certificates will be signed by either a Root CA (less likely) or an Intermediate CA (more likely), and should be stored in the Personal store.

Here are samples screenshots of the public certs I am using for my Lync lab:

Root CA (notice how it’s self-signed):

Intermediate CA (signed by the above Root CA):

Chain:

Hope this article didn’t get too messy or confusing. If you have any questions, please drop me a comment!

Going to Help > About in the AudioCodes Syslog tool ACSyslog gives you a nice little show at first…

The little animation blew my mind, so I subconsciously clicked on it, and was blown away even more. BOOM!

Have fun using Keys 1, 5, Left, Right and Ctrl while debugging SIP messages!

X.509 certs are annoying. You need to get them issued with the right names, or reissued if you make a mistake or forget a SAN, and they need to be cared for from time to time otherwise they expire and make your world hell.

Wouldn’t it be great if you could make them last longer than the default of 2 years? Especially if you’ve installed them all over your Lync infrastructure, like:

• Front End servers
• Mediation servers
• Edge server’s Inside NIC
• Office Web App Server
• Reverse Proxy or HLB
• Voice Gateways
• Exchange UM

Having to track and schedule downtime for cert renewal of all of the above components is quite the chore. So let’s extend it to 5 years using Microsoft Windows AD Certificate Services (AD CS)

To start, we’ll duplicate the Web Server template. Open your Certification Authority MMC, go on your CA, and right click on Certificate Templates, then click Manage.

Right click on Web Server, then go on Duplicate Template.

Under General, we will need to give it a name and Validity Period. I’ve chosen LyncServer but it can be anything. You will need the Template Name when getting certificates issued without auto-enrollment, like from an edge server, or from your voice gateway using a CSR.

Under Request Handling, make sure to check Allow private key to be exported, review the other tabs and options to satisfy your curiosity, then click OK.

You can close the Certificate Templates Console and wait a bit for AD to replicate, or force it.

We will now enable the certificate so it can be issued. Right click on Certificate Templates again, then go on New, and Certificate Template to Issue. Look for your new LyncServer template, then click OK.

ONE LAST STEP!

On the CA server, you will need to extend the limit on the validity period, otherwise it will remain at 2 years regardless of what our template says. To do this, run:

certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod years

The restart the Active Directory Certificate Services service, and the CA is now ready to start issuing longer certs!

When requesting certificates from Lync (or others), make sure to specify the template name when prompted. And if using a CSR for your gateway or edge servers, you can force the template attribute which is not included in the CSR, and is required by Windows to issue you a cert. To do that run:

certreq -attrib “CertificateTemplate:LyncServer”

Then pick the CSR, and then save the resulting signed certificate. BOOM!

The Lync 2013 Management Shell has a tendency of getting stuck or hung when running on Windows Server 2012 R2. Upon opening it, all you see is a black window, no prompt.

To fix the problem, just install the latest Cumulative Update package (CU from January 2014 fixes the problem).

http://support.microsoft.com/kb/2809243

During configuration of an AudioCodes gateway, a required config for successful TLS negotiation is the use of an NTP server. If you’re running Active Directory domain in your network, your primary time source is the Domain Controller hosting the PDC Operations Master role.

To test NTP is working correctly before hardcoding it into your appliances, you can run the following command:

w32tm /stripchart /computer:<yourNTPsource>

The Stripchart modifier will show a strip chart of the offset between your computer and the NTP source you specified.

Also, for future-proof NTP configuration and to avoid having broken services in case you move PDC role and demote your time source, you can create CNAME records such as ntp.yourdomain.com, or use SRV records like the standard _ntp._udp.yourdomain.com (and point them to _ldap._tcp.pdc._msdcs.yourdomain.com for no manual intervention!).