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!