S4B iOS Mobile EWS bug

The December update (version 6.2.0.24) of the Skype for Business iOS mobile app contains a bug that breaks exchange integration. It’s quite annoying as it keeps popping an error message inside the client over and over.

When the client receives the Exchange Autodiscover request and parses the response it attempts to connect to the internal URL of EWS instead of the external URL. Since the internal URL most often aren’t reachable from the external network it wont reach the Exchange server.

I can think of two workarounds to this problem

  1. Set internalURL and externalURL to the same value. This might work for some companies depending on their DNS infrastructure but generally I think this is a bad idea.
  2. Rewrite the response data between exchange and the client so that the internalURL value matches the externalURL value.

Device partnership and pre-authentication for Lync 2013

Updated 12/6 – Added answers to some questions at the end.

Time for another blog post! As promised, on twitter, I’ll give you all some more information about pre-authentication and device partnership but first I would like to give a little background to this functionality.

Our first solution for Lync 2013 (described in the Lync active two-factor authentication post) raised the security bar considerably, especially by providing an application specific password and the option to use two-factor authentication without the need for passive authentication.

This done, we still felt that we wanted to do even more to further enhance the security. Coming from the security field, one of the things I dislike about Lync is the fact that the reverse proxy just passes the traffic anonymously to the Front-End server for external clients. That combined with the fact that we already built a reverse proxy (PointSharp Mobile Gateway) specialized for Exchange ActiveSync made it quite clear what we needed to do.
So we set out to bring some of the most popular features that we have for Exchange ActiveSync to Lync 2013, namely user/device partnership and pre-authentication. This resulted in an extended Mobile Gateway with specialized support for Lync 2013.

Mobile_Gateway_Lync

The authentication is moved from the trusted LAN to the DMZ. This means that authentication takes place on the Mobile Gateway and requiring a successful authentication before passing the traffic to the Lync Front-End. The authentication used is NTLM and it support application specific passwords as well as two-factor authentication. An authentication request is then sent to PointSharp ID that verifies the credentials and decides whether to accept or reject the user. Just to be clear, this has nothing at all to do with passive authentication.

User/device partnership. So what does this mean? Simplified it means that only the correct user with the correct device is allowed to use the service. The device is registered to the user so that if the credentials are stolen they cannot be used without the correct device. What it does is that it inspects the device when it has authenticated and sends an authorization request to the PointSharp ID server which then tells the Mobile Gateway whether the device should be accepted or rejected. Apart from this it is also possible only allow certain types of devices as well as limit the number of devices that can be used.

I know this is mostly an overview that does not go into all technical details but I wanted to keep my twitter-promise and give you all some more information on the subject. More will surely come.

I also have to add; Designing, developing, testing and generally working on this project with all my fantastic colleagues has been great and extremely rewarding.

I also want to give a special thanks to Tom Arbuthnot (@tomarbuthnot) and Graham Cropley (@grahamcropley)for answering my desperate questions on twitter!

* Update 12/6: I received questions regarding how this affects clients, if any special client is needed and whether Mobile Gateway takes over the reverse proxy role. The answer is no, no special client is needed and the clients are not affected in any way. The Mobile Gateway is a reverse proxy, therefore no other reverse proxy is needed.

Lync mobile update for Android – More than meets the eye

Twitter and blogs have been buzzing about the update for the Lync mobile client for android. It was released on the 12th of May and demoed on the same day by Modality System’s Justin Morris (@justimorris) at this year’s TechEd NA.

The update includes the following features:
– Tablet support
– Add participants into an ongoing conversation (IM or Lync Meeting)
– Start an ad-hoc group conversation
– Bug fixes

These are great changes to the android client, bringing its functionality closer to its Windows Phone and iOS siblings. You have most likely read this already since it has been all over the Internet. So why am I writing yet another blog post about this? Well, the simple answer is that this update contains more than meets the eye. Specifically there are two changes that I find particularly important.

– Security improvements through tightened SSL validation.
– Authentication protocol changed to NTLM

While these features might not sound as shiny and extravagant as the previous list they are very important from a security perspective.

Any change to strengthen the validation of certificates is a good change. The tightened SSL validation means that the client must be able to validate the certificate and its chain. A valid certificate must therefore meet the following criteria’s:

• Certificates cannot be expired.
• The certificate chain must be validated, and certificates must meet one of the following requirements:
     o Certificates must be trusted (that is, signed by a trusted authority).
     o Certificates (and chain) have to be installed on the device.
• The DNS Name certificate property has to match the URL.

The second feature much appreciated. I spent the entire TechEd EU 2013 asking presenters and Microsoft employees why the Android client was sending its credentials in clear text (no, Base64 is not encrypted, it’s encoded) while the other mobile clients used NTLM. I never got an answer. But with this update the authentication protocol for the Android client has changed to NTLM which means that no more credentials are being sent in clear text.

This means I must update the table from my first blog post about the Lync authentication process to reflect this.

Client Authentication protocol
PC-client (internal network) Kerberos
PC-client (external network) NTLM
Windows Phone NTLM
iOS NTLM
Android NTLM (Versions prior to 5.4 use SOAP)
Lync Web App (domain user) SOAP
Lync Web App (guest) SOAP (Anonymous)

It should be noted that the Android client still doesn’t request a certificate like Windows Phone, iOS and the PC client does. Perhaps in the next update!

As always, thank your for reading. I hope you enjoyed the read.

Lync mobility – One small step for Lync, a giant leap for Lynckind

Hello everyone, time for another post. A post that won’t be showing you how to do something technical but hopefully something that, if nothing else, can start a discussion. Don’t worry, more technical posts will follow.

I have started getting quite some questions about Lync mobility, both in my daily work and through other means such as this blog. There seem to be a lot of Lync deployments that haven’t deployed mobility. It seems that security departments are reluctant to allow it.

If you are or have been in this situation you probably recognize one or more of these arguments:
– We can’t allow storing of domain passwords on mobile devices.
– Our policy requires the use of two-factor authentication for external access.
– We don’t want to expose infrastructure if we can’t limit it to certain clients.

Those are the most common I come across and they are all valid points. Those are the arguments I would use myself. In fact, they are excellent arguments and should be asked by any security department. The thing is that you can fulfill all these requirements for Lync.

You can use an application specific password or you can use 2-factor authentication and you can limit the clients accessing Lync from the outside.

What I’m getting at here is that Lync is truly a great application (but you already knew that) and while mobility might just be a small part, it is an awesome part. Don’t cripple your Lyncers, empower them!

Have a good weekend!