Securing Lync is Critical, especially now a day, where security breaches are common.

Our focus will be on securing external access to Lync. Lync Edge server and Director server are here for that, for providing external access to Lync and protect it in the same time.

Lync Core Security

Lync in its core provide security by encrypting the travelling Signaling and Media traffic. In addition to the Normal user authentication using Active Directory Username and password, PIN and Extension authentication coupled with Certificate authentication are used on the Lync Phone edition devices.

Signaling Traffic

For communications between servers, Lync is using MTLS to secure the communication between servers. For communication between your mediation server and the Gateway, it’s recommended to use TLS if supported by your Gateway.

When MTLS is used, servers exchange Certificates, those certificates are issued by internal CA that is trusted by both servers.

For communications between the Lync Client and the Lync server, TLS play a role here for securing and encrypting the communications.

As for Reverse proxy it’s using SSL and TLS (HTTPS) for securing the web services.

Media Traffic

For media traffic, the protocol used for encrypting and securing the data is SRTP (Secure Real-Time transport Protocol).

Client Authentication:

There is a number of ways that users authenticate against Lync, e.g. internal client , external, phone device…etc.

If the user is inside the LAN, the authentication will happen using Kerberos, if the user is outside the LAN then it will authentication will be via NTLM, because Kerberos need to access Active Directory for authentication, in general Kerberos is more secure than NTLM simply because the Password is never sent through.

If for some reason your infrastructure is not allowed to use NTLM in it, you might need to consider implementing Direct access using UAG 2010.

As mentioned in beginning of this article, there is the PIN authentication method, usually used for Phones, in this method the user uses his/her PIN + the Phone extension to logon to the phone, which download a certificate  with the user in either the subject or subject alternative name, and it must be issued by a root CA that is trusted by the servers running Lync.

Lync Externally

If you decided to deploy Lync Edge to provide secure External access to your users, then follow this article to understand more about how Lync Edge, Lync Director and the Reverse Proxy can be used to provide external access for your users and Partners while keeping it secure.

Edge Server

Lync Edge is one of the components that is used to provide external access, Edge has a number of roles that are consolidated onto a single server, not like the old OCS days when you could have a whole range of different roles split onto different servers.

You can deploy the Edge Server using one of the following topology options:

  • Single Consolidated Edge
  • Scaled Consolidated Edge with      DNS load balancing
  • Scaled Consolidated Edge with      Hardware load balancing

The components (Roles) provided by the Lync Edge are

  • Access
    • Access edge act as a SIP proxy server, its concern with only passing SIP authentication traffic (as Edge server is not joined to the Domain it cannot authenticate users) from the external users to the next hop which is usually either the Front-end server/pool or the Director server/pool.
  • AV
    • AV edge used for Lync ICE protocol, the ICE protocol is used to enable the media traffic to travel in a NAT infrastructure.
  • Web conferencing
    • Web Conferencing edge act as a PSOM proxy, PSOM is the protocol used to provide access to the conference data such as whiteboard, Poll pages and slides, this is done with conjunction of the access edge and reverse proxy.

Each one of those roles provides specific security capabilities  and has specific requirements, each one require a certificate that have the correct name of the services as well as a specific port to be opened in your firewall.

Director Server

The Lync Director Server, as understood from the name of it, provide user authentication and redirect the user to a front-end server that it’s home at, This means that all user authentication requests first hit the Lync Director, which can then authenticate and route the traffic to the correct Lync front-end-server.

Another benefit of the Director server, as it’s the stop of  the traffic coming from the Lync Edge to the Front-end, its used to protect against DOS attacks as it will stop at the Director and won’t be forwarded to your Front End server or Pool.

The Lync Director can be deployed with same topology options as mentioned in the Lync Edge section.

Reverse Proxy

The Reverse Proxy provide external access to the Lync IIS website by publishing the required URLs hosted by the Lync Front-end and Director.

With publishing those web services, you are allowing the remote users to have access and connect to meetings or dial-in conferencing using URLs query the address book, get client update, expand a distribution group and two more which I cannot remember while writing this article 🙂

So the “Simple URLs” that will be need to published using the Reverse proxy are:

Role Services provided Subject name syntax
External web services – FQDN of the front end pool Conference contentAddress book files

Client/device   updates

DG expansion

Lyncwebext.lyncdude.net
External Web services – FQDN of the Director pool Same as above LyncDirwebext.lyncdude.net
Dial-in Dial-in Conference   information Dailin.lyncdude.net
Meet Meetings URL Meet.lyncdude.net
Lync Discover Lync auto   discovery Lyncdiscover.lyncdude.net

Simple URLs are a way to make the URL used in conferencing easier for the users to understand. Where there is a Director pool in place, the URLs are published on the Director, this doesn’t mean replacing the Web services of your Front end pool with Director, Lync Director web services is published with the Lync Front end web service too.

Note: for meet URL you will need meet URL for each SIP domain you have in your deployments.

According to Tech Net there are three possible way to plan for your URLs, I will summarize them as following:

Simple URL naming Option 1:

You have a dedicated URL for each site as following, this option require a number of certificates or subject alternative name to support each URL.

Https://meet.lyncdude.net

https://dialin.lyncdude.net

&

https://meet.anotherdomain.com

Last URL is if you have another SIP domain in your deployment

Simple URL naming Option 2:

In this option, the URL is a virtual directory under the external web service URL (Called Shared Simple URL)

https://lyncwebext.lyncdude.net/meet/

https://lyncwebext.lyncdude.net/dialin/

&

https://lyncwebext.anotherdomain.com/meet

Last URL if you have another SIP domain in your deployment

If you publishing using Director pool (LyncDirwebext.lyncdude.net), you should use them for the reverse proxy.

https://lyncdirwebext.lyncdude.net/meet/

https://lyncdirwebext.lyncdude.net/dialin/

&

https://lyncdirwebext.anotherdomain.com/meet/

Simple URL naming Option 3:

This is one of the most efficient  use of URLs, if you publishing the Front end web services then:

https://lyncwebext.lyncdude.net/lyncdude/meet/

https://lyncwebext.lyncdude.net/anotherdomain/meet/

https://lyncwebext.lyncdude.net/lyncdude/dialin

And if you have deployed Lync Director then use the Director web services to publish the URLs:

https://lyncdirwebext.lyncdude.net/lyncdude/meet

https://lyncdirwebext.lyncdude.net/anotherdomain/meet

https://lyncdirwebext.lyncdude.net/dialin/

Understanding Lync Security – Part 2