Securing Your Lync Server (Part 3)

by [Published on 4 June 2014 / Last Updated on 4 June 2014]

This article looks at some security tips specific to using Lync across the Internet and with users outside the organization.

If you would like to read the other parts in this article series please go to:

Introduction

In Part 1 of this series on securing your Lync Server, we discussed the evolution of Microsoft’s Lync software that grew out of the old Office Communications Server (OCS), what it does and how it works, the built-in security mechanisms (authentication and encryption) and the use of Active Directory and Group Policy, as well as how to use the Lync Server Management Shell to assign and create administrative roles. In Part 2, we talked about common threats to Lync servers, some tips and tricks for hardening your Lync server and the Lync database, and how to plan and configure two-factor authentication for Lync. This time, we’ll wrap it up with some security tips specific to using Lync across the Internet and with users outside the organization.

Security implications of using Lync across the Internet

When you deploy Lync for use of your internal users to communicate with each other, you have optimal control over security. Unfortunately, though, that’s likely not enough. In this highly mobile and highly interactive work world, chances are good that your internal users will also need to be able to communicate with people who are outside the organization via instant messaging, audio and video conferencing, as well. This can include customers and potential customers, vendors and suppliers, and colleagues and partners who work for other organizations, as well as your own employees who are on the road or who telecommute from home or a satellite office.

If Lync users need to connect with others who are outside the boundaries of the corporate firewalls, that needs to be factored in when you consider how to most securely deploy and manage your Lync servers. You don’t want your internal servers to be directly available from the Internet, so the way to avoid that is to set up a Lync Edge Server. The edge server can then be placed in your DMZ network (a.k.a. perimeter network). This server acts as the intermediary between internal users and those on the other side of the firewall.

The Lync Edge Server can support presence and IM and audio and video conferencing via the Lync client, the web, and Lync mobile apps. It can also support voice (VoIP) calling with Lync.

In this article, we’ll be talking specifically about Lync Server and Client 2013 and taking advantage of their advanced feature sets. There are a number of differences between Lync 2013 and Lync 2010 that impact the Edge Server deployment.

New Lync 2013 features

One important change is that Lync Server 2013 supports IPv6 addressing. Many organizations are now beginning to move their networks to IPv6 as the depletion of public IPv4 addresses continues. You can use IPv6 addressing when you configure the Lync Edge Server. To do this, you will need to create DNS records, including AAAA host records. Another new feature is the ability for users to have contacts who are part of an organization that uses the Extensible Messaging and Presence Protocol (XMPP) protocols, such as users of Google Talk (other XMPP systems may or may not support federation with Lync). Your users can obtain presence information and exchange instant messages with them. This is done via an XMPP proxy that is deployed on your Lync Edge Server that works in conjunction with an XMPP gateway that you deploy on the Lync Front End Server.

Especially relevant to the security discussion is Lync Server 2013’s new support for “rolling” A/V authentication and server-to-server authentication certificates. Here’s how that works: Tokens are generated by certificates and the tokens, which are cached for as much as 8 hours, are used for the authentication of requests for port allocation. When these tokens’ certificates expire, clients must obtain new tokens with valid certificates. Without a valid token, audio/video sessions will fail. Server-to-server authentication works somewhat differently. It uses one global certificate that authenticates all the servers – Lync Server 2013, Exchange 2013 and SharePoint 2013. Server-to-server authentication expires after 24 hours. What’s new is that new A/V and Server-to-server certificates can be issued prior to the extant certificate expiring and both can be used simultaneously (the old one to verify current sessions and the new one for new authentication requests).

Edge topology

The most important component in your Lync edge topology is the Edge Server(s). These are the servers in the DMZ that run the edge services necessary for sending and receiving communications between internal and external users. The edge services run by the Edge Server include the following:

  • Access Edge Service that handles SIP traffic.
  • Web Conferencing Edge Service through which external users can join meetings hosted through the internal Lync Servers.
  • A/V Edge Service through which external users can participate in audio and video meetings with internal users. File transfers and sharing of the desktop are also supported.
  • XMPP Proxy Service that, as mentioned earlier, handles IM and presence exchange between internal users and external XMPP-based users.

An important security issue is that the external users who connect to your internal Lync servers cannot access anything else on your internal network. Note that users do not have to connect to your network through a VPN to participate in Lync meetings and calls. In fact, it is better for users outside the org to connect directly to the A/V Edge Server instead of through the VPN because there can be a negative impact on A/V traffic when users connect through the VPN.

Your edge topology also includes a reverse proxy, which makes it possible for external users to use simple URLs to connect to meetings and also enables them to download content from meetings, get user-based certificates, download files from the Address Book server and more.

The Director Server role is now optional in Lync 2013. It does the same thing it did in Lync 2010 – preauthenticates inbound requests and then sends them to the user’s home server or home pool of servers – but these same tasks can be performed by the Front End servers. However, the use of a Director can improve the security of your Lync 2013 deployment, as it protects the Front End servers from denial of service (DoS) attacks. Using a Director can also improve performance.

You can deploy a single Director or a Director Pool. Note that you will need to publish the Director web services through the reverse proxy along with the web services of the Front End servers.

Note that the Director role should always be deployed as a separate server, not running on a Lync Server that runs other server roles. In addition, the Edge Server and the Reverse Proxy should each be deployed as dedicated servers. The Reverse Proxy can, however, be used to publish web sites and over services that have nothing to do with Lync. You can use an existing reverse proxy if you already have one in the DMZ; it’s not necessary to deploy one just for the Lync services.

Best practices for securing your Lync Edge topology include:

  • Create a subnet dedicated to the Lync Edge Servers.
  • Disable broadcast and multicast for the subnet.
  • Follow best practices for certificates when using the same certificate on multiple Edge Servers.
  • Put the Edge Servers in a domain that isn’t part of the internal Active Directory domain or deploy Edge Servers in a workgroup instead of a domain. The point is to keep your internal AD services out of the DMZ.
  • Minimize the total number of listening ports by disabling unnecessary services (note that reducing the number of ports used by a single service does not provide added protection or decrease exposure to attack).
  • Configure the Director to monitor all outside user traffic for security auditing.
  • Define rules during the configuration of each server role to strictly control the paths allowed for both Internet traffic going to the internal network and internal traffic going to the Internet.
  • All Edge Servers should have a properly associated firewall policy.
  • Use computers with two network adapters for physical separation of internal and external interfaces.

Finally, your DMZ should be secured with firewalls. It is possible to use only an external firewall but best practice is to use two firewalls, one external (between the DMZ network and the Internet) and one internal (between the DMZ network and the internal local area network). This provides for the optimum protection of the resources in your internal network, as they are protected from the Internet by a double layer of firewalls.

Summary

Securely deploying Lync for external users is a bit more complicated than a deployment that stays within the corporate network, but provides users with more communications capabilities. This article has only touched on some of the important factors affecting security of deploying Lync for across-the-Internet usage and does not go into details regarding the many steps that need to be taken to make this scenario work properly. For that guidance, check out the document titled Planning for External User Access that is part of the Microsoft Lync Server 2013 documentation on the Technet web site.

I hope you’ve enjoyed this 3-part article on securing your Lync servers. Microsoft Lync is a versatile and effective communications tool that, when properly deployed, can provide business users with many options for interacting with each other within an organization and with the outside world.

If you would like to read the other parts in this article series please go to:

Featured Links