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.

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.