Lync 2013 On-Prem and Client Authentication.

I recently was made aware of a new “feature” in Lync 2013 which I was not aware of. This is regarding client authentication and remote access users.

There are three authentication methods on the security – registrar tab in Lync Server Control Panel:
Security_registrar

The following TechNet article describes each of these  http://technet.microsoft.com/en-us/library/gg182601.aspx

Notice that the checkbox for Enable Integrated Windows Authentication is cleared in my configuration. According to the TechNet article, Microsoft recommends to enable this when serving remote access users, otherwise they won’t be able to authenticate. And here’s where my discovery comes in play.

I discovered that if this setting is enabled, a remote user with a local Lync client can log in to Lync with a username and password(of a Lync enabled user) without having to present a valid root certificate. The local PC does not have to be domain joined either. In my opinion, this is not very secure…The feature has obviously been there for a while, but I’ve never tried logging in to a system before without having the root certificate in place so that’s why I kinda didn’t know this was possible.

I think this setting was default disabled on Lync 2010 and had to be turned on, but I might be wrong on this one. Nevertheless, I would recommend this setting to be turned off in order to have some control of the clients logging in to the Lync environment. When Microsoft states that remote access clients won’t be able to authenticate unless you enable NTLM authentication, that’s not entirely true. They will be able to authenticate if they are provided with the domains root certificate from the internal rootCA. Domain joined clients get this by default, but nondomain clients like Mac’s, Linux and other Windows clients will have to import the certificate to the local trusted root certificate store.

This involves some manual actions to be taken, but in my opinion it’s worth the extra effort in order to have a more secure environment.

Of course, if the Lync environment is a multitenant solution where all users are treated as remote users and not able to acquire the root certificate from the domain in which Lync is installed(without a lot of intervention from the system administrators), NTLM authentication is the only way to allow clients to authenticate.

If anyone has comments regarding this matter or even have some other opinion on why this might be nice or not, please feel free to comment on this post :)

Lync for Mac 14.0.8 crashes, relogin and acts weird.

Ok, I admit it. I’m running Lync on OSx :(

Several of my machines, including my work machine, are apple products. But I still want to run Lync in a local client. Sadly, Microsoft has not come up with a Mac client worthy of comparison with the Lync 2013 client for Windows.

So, I have to stick with the Lync 2011 client for Mac :) This client is very unstable, and does a lot of strange things. I’ve managed to get it fairly stable and working, but not 100%. It keeps crashing when I plug in USB devices etc.

After the last update to version 14.0.8, the client started to sign in and out every few seconds. It seems like the problem arises due to the fact that newer Mac OSx is case sensitive, which is not taken into consideration by Microsoft.In order to fix this, I had to run the following command in Terminal on my Mac:

cd /Applications/Microsoft\ Lync.app/Contents/Frameworks \
    && ln -s USBHIDWrapper.framework USBHidWrapper.framework

Just so you know it in case you are in the same situation as I am :)
PS: VmWare Fusion is a super product for running Windows on a Mac(if you have to) :)

Note: It turns out that the last patch for Lync for Mac 2011(14.0.8) also fixed some other problems I had with the client crashing when removing or inserting USB headsets and web cam’s while the client was running.

Unable to route incoming call to a single Lync 2013 User.

Recently I came across a strange problem which I thought I would share.

The scenario is Lync Server 2013 Standard edition and Lync Server 2010 Mediation server(in process of migrating). The problem started when a user reported that he wasn’t able to receive incoming PSTN calls. Outbound calls was working just fine.

I started investigating the problem and ran some tracing with Wireshark on the Mediation server along with Lync Server logging tool. The Wireshark traces showed that the Lync Mediation server was sending “487 – Request terminated” to the PSTN gateway after receiving a CANCEL.
Snooper logs was showing the same messages and also in some cases “504 – Server timed out”. The Lync Monitoring server had no records of the call beeing established at all. After checking with the service provider of the PSTN gateway and doing some thorough checks of the unassigned numbers and all other kind of stuff(including the use of this script from a colleague to check all registered telephone numbers used in Lync and other systems), I was left in the dark. There was no reason for this not to work as it should.

Solution: Rebooted the Lync 2013 FrontEnd server, and everything worked like a charm.
Key takeaway from this post: When in doubt, reboot :-)

Windows Server 2012 Certificate issues with Lync.

With the new Windows Server 2012 and the enhanced certificate control, some may have experienced different “strange” error scenarios. Features stop working, and servers are behaving strange.

In Lync, one of the most common situations is when federation stops working. In most cases, you’re able to see Messages in the event log on you Access edge server indicating that something is wrong with the certificates. The Server 2012 has a more strict certificate handling than previous server versions, and the placing of certificates in the certificate store is critical.

Make sure that no intermediate certificates are placed under Trusted Root Certificates. If they are, this will break the certificate structure on the server and strange errors will start to appear in the event logs.

To check if you have certificates in the wrong stores, the following PS command can be run(it will list the certificates with wrong location):

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File “c:\computer_filtered.txt”

Lync Server 2013: Event ID 32054, LS Storage Service

Problem With event ID 32054 appearing in event log onm Lync 2013 server.

The scenario is as follows:
Lync 2010 upgraded to Lync 2013 CU3 in co-excistence with Exchange 2010 SP2 running on Windows Server 2008 R2.

Problem:
The event log on the Lync 2013 server is showing repeated event ID 32054. “Sorage Service had an EWS Autodiscovery failure.”
Event ID 32054

The error message pointing in direction of missconfigured autodiscovery or reverse proxy configuration. Since I’m not a big fan of red messages in the event log, I proceeded to check out the possible causes to this error.

Ran a check of the Exchange web services configuration:

EWS_config

Everything seems OK here.
Also checked for autodiscover.domain.com in internal and external DNS. All good there as well. Even had the SRV records for autodiscovery in place both internally and externally.
Ok.
Next step was to check all the Lync features to see if anything was not working as it should. Did a complete check of all features both on my internal Lync PC client and from my mobile iOS client. Everything worked like a charm, while at the same time the events kept popping up in the event log saying “this is not right”.

My conclusion:
The event ID 32054 can safely be discarded as rubbish as long as everything is working fine. I’ve seen multiple posts regarding the same problem all over, and currently there has been no cure.

If anyone by any chance has a working, documented solution to this “problem”(Microsoft???), please feel free to post a comment with links in this post.