Tag Archives: Security

Device partnership and pre-authentication for Lync 2013

Posted on by
Reply

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.

Increase Lync 2013 security

Posted on by
1

My posting will have a little Lync sprint at the moments since we’re in the middle of Lync Conf 14. As I mentioned in my previous post, this post will be about securing your Lync 2013 deployment. More specifically it will focus on how to increase security when you publish your Lync to the Internet.

When publishing a default installed Lync deployment to the Internet, clients will authenticate directly to the Lync Front-End server using their domain credentials. While it’s true that the traffic is sent through a reverse proxy the actual authentication takes place at the Lync Front-End server.

This means that for instance you can lock any user’s AD account by just knowing its username, thereby inflicting a Denial-Of-Service, not only for Lync. On the mobile clients you can also choose to save the password in the client which means that a lost or stolen device has the domain credentials stored on the device. It’s also worth to notice that two-factor authentication is not possible without ADFS and a third-party identity provider.

For many, this just isn’t not good enough for a system that is published to the Internet. Looking back at past projects, which have included publishing a system to the internet, there are a two requirements that have been in common for almost all of them.

1)      Domain credentials may not be used.
2)      Two-factor authentication is mandatory for external access.

So, how do we fulfill these two requirements? There are two ways to solve this and both Requires integration from a third party. Both solutions have their advantages.

pa_pam2

Deploying any of these solutions greatly increases the security of your Lync deployment.

My upcoming post will explain how to configure both solutions, starting with “Lync Passive Authentication with two-factor authentication”. Stay tuned for more Lync security!