Lync 2013 Security Guide

Introduction

Microsoft always stresses security best practices in Lync environments in general. Taking those concerns into consideration, the Lync environment is separated into different security areas and layers and deployments should always include TLS encryption and certificates using 2048-bit or longer key lengths. There are several key areas that also strengthen security.

In general, these key areas are:

1. Internet based Access
2. Logon Traffic Redirection
3. Internal Server service segregation
4. Mediation Server to Gateway communication

This white paper will focus on Internet directed traffic and communication in Lync 2013 deployments. While relevant and important, security layer area not discussed in the document is Two-Factor authentication.

In order to define context we first need to ask ourselves the question, “Why is this necessary? Our old phone system and methods of communication didn’t leverage encryption and advanced security measures.”

First off though, we need to redefine the word “communication.”

What is Unified Communication Anyway?

Unified Communication (UC), simply said, is everything beside email. This includes all communication which could possibly be answered immediately, such as Instant Messaging, Voice/ Video Call (Phone Calls), Conferencing as well as others such as Desktop Sharing and Active File Transfer.

With this definition, it’s easier to see why we need additional security. Since these methods of communication can be used with entities outside of the corporate firewall it’s also critical that security measures be applied both internally and externally especially since UC not only allows the transfer of voice as with our traditional telephone systems but also allows the transfer of more sensitive content like files, desktops and application data.

With this understanding let’s discuss 4 different security key areas in Lync 2013 architectures.

4 Areas of security concerns

Let’s analyze the areas in reverse, from 4 to 1 until we reach the Internet, the most unsecure zone.

Mediation Server / Gateway

The Mediation Server Component can be installed in two different ways, either consolidated on the Front End Server (being part of the Front End Pool), or as a dedicated Pool with Mediation Server functionality only. In both scenarios the audio path between the Mediation Server and Gateway(s) can be secured in different ways. Either the Mediation Server to Gateway network is dedicated, meaning a physically and logically isolated LAN or consolidated, transmitting audio traffic over the production LAN with the use of TLS encryption.

Isolated LAN:

If the Mediation Sever component is installed on the Frontend Pool and has its own network card or, if the Mediation Server is its own Pool with a dual NIC, we have a dedicated LAN between the Mediation Server and the PSTN Gateway (i.e. a dedicated LAN cable to the PSTN.)

Let’s look at restrictions and possibilities with this setup:

Since the LAN is isolated and not routed, we can possibly run IP traffic in this dedicated network segment without encryption, thereby reducing CPU utilization on both the PSTN Gateway and the Mediation Server Pool. The caveat of this is that Media-Bypass is NOT possible in this configuration.

Figure 1 Mediation Server and Gateway (Isolated LAN)

Consolidated LAN

In this topology design, Mediation Server can be consolidated on the Frontend Pool or can be dedicated role. Media-Bypass is possible and therefore audio traffic is routed from/ to all possible clients and is fully traceable on the network. TLS encryption is always used in this configuration.

Figure 2 Mediation Server and Gateway (Consolidated LAN)

Internal Lync Services segregation

Both Web and Session Lync services traffic is encrypted. With this, one obvious question that arises is, if this traffic can reach the Lync servers from external clients, how do we ensure it is legitimate traffic?

The answer isn’t simple but since Microsoft improved IIS and the security of Windows servers in general over the years, we can now segregate the traffic based on its origin and direct it to different targets, internal and external IIS WebSites (e.g. port segregation 443/ 4443). We will cover how it actually works in more detail later in this section.

Lync Web traffic has an interesting characteristic... Until we reach an internal Lync System, either Director or Frontend Server, the Web traffic is NOT authenticated. Authentication can only be carried out by Domain Joined Lync Servers!

SIP, compared to Web traffic, is quite different! Here, even when initiated from external networks, it will be logically seen as internal traffic. We will also cover this behavior in detail later in this section. However, there is the one traffic which cannot be encrypted – internal Phone Update and CRL traffic. It needs to be HTTP rather than HTTPS.

Figure 3 Lync Services Web Traffic Segregation

Logon traffic redirection

Lync offers support for larger deployments, offering increased security. This feature is supported by a Server role called the Director Server, a deployment component able to authenticate and then redirect incoming traffic, to its intended destination at point of ingress.

Interestingly, if you have a multi zone security model, you might place Director Servers in an internal DMZ which is in-between the Internet facing DMZ and LAN zone. So to speak a DMZ which can be internally and indirectly, externally, contacted.

Figure 4 Lync external Web Services (Pool Configuration)

Internet based access

Now, let’s discuss the systems directly facing the Internet. As we can guess from the internal service segregation, there must be two systems handling traffic coming from the Internet:

Reverse Proxy and Lync Edge Server

First is the Reverse Proxy component. It is highly recommended to use solutions which are supported, either by Microsoft or from a third-party vendor. Provided by Microsoft are IIS ARR/WAP and TMG^[1].

A non-Microsoft solution example is from Kemp Technologies, the LoadMaster application load balancer equipped with Edge Security Pack (ESP), which we will discuss later along with configuration examples.

Then, there is the Lync Edge Server, one of the most secure servers! While the Reverse Proxy only handles all Web traffic, the Edge Server handles all SIP traffic. This server acts as a real application firewall for Lync deployments.

Figure 5 Lync Reverse Proxy

Security requirements and compliance

Most customers require a strict traffic segregation and inspection policy for all traffic coming from and going to the Internet and this is no different for Lync 2013. This traffic must be fully inspected, at least at Layer 7. Layer 7 of the OSI model describe the IP application layer which is in our case HTTP/HTTPS and SIP.

But in case of a Unified Communication solution, this is not enough.

Web traffic is easier to analyze based on Reverse Proxy technologies. But how can we analyze SIP traffic? How do we ensure the enforcement of assigned policies?

Assuming we find a possible way of doing some inspection within this traffic, Lync is a very sensitive communication system, operating with real-time data. Real-time data is time sensitive and it is session aware. What about the Web traffic? Does it have its own uniqueness? It sure does! In Lync we have web session tickets which must be kept intact. Those tickets ensure that your external client will receive the correct buddy list and prevents crossover of user information.

So how can Lync operate in such complex environments, securely?

Lync external facing Security Components

We identified a handful of systems during the 4 areas of security that must be considered in Lync 2013 deployments. There are two components facing the Internet directly and two components which are internal, LAN based systems. Let’s dive deeper into the first two:

Reverse Proxy

Reverse Proxy, the system which handles all incoming HTTP(S) traffic. This includes traffic generated from services such as address books, distribution group expansion and anonymous traffic for Dial-in and Meet. User connections to these components are fronted with forms based access pages. In total there are three pages offering FBA: dial-in, meet and scheduler.

Dial-In is the landing page for audio conferences. If a conference is planned and the link was sent to possible participants, they are able to access this page and find possible dial-in phone numbers. This web page is accessible anonymously. But with a “sign in” option, Lync users homed on the system can access their own dial-in parameters and preferences.

Meet is the landing page for the Lync Web App. If you try accessing the web page without a valid conferencing ID, Lync provides you with an error page first. If you have submitted a proper conference ID, it will either redirect the connection to a locally installed Lync client or it will present you with the meeting login page. A forms based login page for anonymous users provide only a naming identifier or the second option for Lync system homed user to identify themselves with the Active Directory domain credentials.

Scheduler is the meeting planning landing page. If you do not have an Outlook client installed along with a local Lync client installation, you need this (manually) configured web page accessing and planning Lync meeting/ conferences. It has a forms based login page for Domain authenticated users.

Other web services covers everything else that Lync clients, Mobile Clients, App Store Clients and Rich Client require. Those services can only be accessed by users once they’ve authenticated themselves again Active Directory and have valid session tickets granted. Once we discuss the IIS components in Lync, we will discuss more details of these services and their directories.

Edge Server

The Edge server is the first Lync server in this scenario we are going to discuss. This role provides the following three services:

Access Edge Service: This application component is also called Access Proxy. It controls the remote user communication and pass-through of authentication. Another feature is federation to other UC solutions and infrastructures including other Lync deployments, other versions of Lync or OCS and Public IM Connectivity (PIC) to MSN and Skype. The third component is XMPP which, despite being a dedicated service, is also related to the Access Edge. The main purpose of this service is validating SIP connections between users inside and outside of your internal network.

Web Conferencing Edge Service:
A dedicated service for web conferencing media distribution. The Edge Web Conference service proxies the conferencing data stream between the internal Frontend Server hosting the conference and the external connected Lync client (rich and mobile).

Audio/ Video Edge Service:
The third core component in Lync Edge is the A/V component. This service handles not just streams containing A/V content but also proxies application and desktop sharing and file transfer to external users. The AV Edge Service has two functionalities – Audio/ Video Edge Service and Audio/ Video Authentication Service.

The question is now, how does Lync Edge for Audio/ Video actually work? The Lync AV Edge Service serves as the MRAS (Media Relay Access Server), allowing for the pass-through of A/V traffic. The AV Authentication Service is an internal Lync component related to the internal deployment, authenticating Media traffic coming from internal and traveling to external destinations.

SRTP (Secure Real time Protocol) is a call leveraged by the AV Edge service and has its own native security within. Essentially, the SRTP protocol exchanges security keys within the SIP protocol first using a Master Key protecting the Session Key. Additional information about SRTP can be found in the related RFC. For Lync it is important to understand the Edge Server Service positioning, either the external interfaces or the internal interface.

Figure 6 Lync A/V Edge Services

This also reveals why the Edge Server requires 2 network interfaces. Since the AV site is segregated into two sites, security must be ensured.

The next component is the internal site of Lync, where we take a look at the Lync Director Server and the Internet Information Server (IIS).

Director Server

As we have seen in the Edge Server section of this document, the Edge Server segregates SIP traffic but it is not responsible for authentication. We have unauthenticated traffic, like presence status requests and traffic from remote users, which needs to be authenticated. Authentication can only be handled by a SIP Registrar which is the Frontend Server.

Which role does the Director play if not the Registrar? It really is another type of proxy server. It knows where a user is homed and can process the authentication, before passing the authenticated traffic to the user’s home pool.

But can it act also as an additional security layer? Yes it can!

Since traffic flows through Directors before making it to front ends, in case of a denial-of-service attack, the attack will never make it to the internal systems. If the network is flooded with invalid external traffic, it will simply be terminated here with no impact to any other internal and more sensitive systems.

Figure 7 Lync external Web Services (Pool Configuration)

The IIS Web Services are listed in the picture below, each of the certificates provide several functions and is split into the “external” and “internal” web sites.

Figure 8 Lync Web Services IIS structure

IIS Web Services Security description

As mentioned earlier, IIS provides several function along for Lync as listed here:

• Enables users to download files from the Address Book Service
• Enables clients to obtain updates
• Enables conferencing
• Enables users to download meeting content
• Enables users to expand distribution groups
• Enables phone conferencing
• Enables response group features

In addition, the cumulative update for Lync Server 2010: November 2011 installer creates virtual directories in IIS for the following purposes:

• On Front End Servers or Standard Edition servers to support mobility functionality, such as instant messaging (IM) and presence, on mobile devices
• On Front End Servers or Standard Edition servers and on Directors to enable mobile devices to automatically discover mobility resources

In the following table, some of the most common services are addressed and described:

Lync Web Service	Address	Description
Address Book Server	https://<Internal FQDN>/ABS/int/Handler	Location of Address Book Server download files for internal users.
Autodiscover Service	https://<Internal FQDN>/Autodiscover	Location of the Lync Server Autodiscover Service that locates mobility resources for internal mobile device users.
Client updates	http://<Internal FQDN>/AutoUpdate/Int	Location of update files for internal computer-based clients.
Conf	http://<Internal FQDN>/Conf/Int	Location of conferencing resources for internal users.
Device updates	http://<Internal FQDN>/DeviceUpdateFiles_Int	Location of unified communications (UC) device update files for internal UC devices.
>Meeting	http://<Internal FQDN>/etc/place/null	Location of meeting content for internal users.
Mobility Service	https://<Internal FQDN>/Mcx	Location of Mobility Service resources for internal mobile device users.
Group Expansion and Address Book Web Query service	http://<Internal FQDN>/GroupExpansion/int/service.asmx	Location of the Web service that enables group expansion for internal users. Also, the location of the Address Book Web Query service that provides global address list information to internal Lync Mobile Microsoft Lync 2010 Mobile clients.
Phone Conferencing	http://<Internal FQDN>/PhoneConferencing/Int	Location of phone conferencing data for internal users.
Device updates	http://<Internal FQDN>/RequestHandler	Location of the Device Update Web service Request Handler that enables internal UC devices to upload logs and check for updates.
Response Group application	http://<Internal FQDN>/RgsConfig http://<Internal FQDN>/RgsClients	Location of Response Group Configuration

DNS Mobility Setting for internal Clients:

Mobile users encounter various mobile application scenarios that require special planning. For example, someone might start using a mobile application while away from work by connecting through a 4G network, then switch to the corporate Wi-Fi network when arriving at work, and then switch back to 4G when leaving the building. You need to plan your environment to support such network transitions and guarantee a consistent user experience. This section describes the infrastructure requirements that you must have in order to support mobile applications and automatic discovery of mobility resources.

Supporting this scenario can only be accomplished if the client stays connected via single entity. This entity is the Reverse Proxy.

It is important to note that the internal Web service (running on port 443) does not offer mobility services, as the below Microsoft diagram depicts:

Figure 9 Lync Mobility Services (recommended design)

Load Balancing Requirements for Web Services

Following are the hardware load balancer requirements for Director and Front End pool Web Services:

Summary of Hardware Load Balancer Affinity Requirements

Client/user location	External web services FQDN affinity requirements	Internal web services FQDN affinity requirements
Lync web access (internal and external users) Mobile device (internal and external users)	None required	Source address affinity
Lync web access (external users only) Mobile device (internal and external users)	None required	Source address affinity
Lync web access (internal users only) Mobile device (not deployed)	None required	Source address affinity

Security Topology

The Edge server itself acts as a highly secure, real Application Proxy and is a NON-Domain Joined system with incoming data replication only. Let’s step through an incoming SIP session.

Arriving at the external Edge Server interface, it terminates external traffic, starts full application inspection, entitlement verification and user policy validation. After this inspection the traffic is sent via the internal network interface to the next network security layer, which is the Lync Director Pool or the Frontend Pool. In our example, we will assume that this additional security layer of a Director Pool is in use. It should be noted that in this scenario user authentication requests will only be performed on a Director Pool and this traffic is redirected to the user’s destination Frontend pool. From there onward, the traffic is treated as authenticated and a VIA (Path) is established between the Edge Pool, Director Pool, Frontend Pool and the internal user client. This information is sent by a NOTIFY SIP command. The same principal is valid even if users are homed on SBA’s (Survival Branch Appliances).

SIP traffic also has the provisioning for VIA (Path) headers and therefore is aware of the context of the traffic flow.

More important is the Web Service traffic. Here we’re referring to the earlier mentioned topic of generic web traffic, such as ‘meet’ or ‘dial-in’ and the web services homed on all Lync Pools, Director Pools as well as on Frontend Pools. The traffic flow for those must be taken into consideration.

Simply put, for Pool Web Services, the Director is NOT an additional security layer. This is where IIS web site segregation comes into play as defined earlier

Let’s now take a look into a minimal deployment with an Edge Server and a Reverse Proxy.

Minimal Deployment

The importance of certificates cannot be stressed enough. You must implement the correct public certificates on the Edge and the Reverse Proxy in order to establish a working and secure deployment. The Edge Server additionally requires an internal certificate. Only this ensures the correct proxying, or better said, basic Lync application firewall functionality. The Reverse Proxy also needs a public certificate and must be able to recognize the internal web services assigned certificates. The core essence of this is that you need a correctly configured infrastructure ensuring that encrypted traffic can correctly traverse the entire deployment.

The minimal deployment consists of a single Lync Edge Server and a Reverse Proxy Solution as illustrated below:

Figure 10 DMZ Lync Server 2013 security compliance (minimal deployment)

The Reverse Proxy listens on TCP Port 443 and simply redirects the traffic to the internal IIS server on TCP Port 4443, inspecting the HTTPS stream, repacking and re-encrypt the traffic with the certificate assigned to the external web service web site.

The Lync Edge server acts slightly different. It still needs a valid public certificate, so the incoming and outgoing IP traffic stream can be encrypted. Clients or other Edge Servers need a certificate validation check before accepting TLS traffic encryption.

When Lync has an incoming SIP request, the external client will contact the Access Edge which than terminates the SIP connection on its external Access component. The next step involved is processing this request and validating what its intent is. Assuming it is a user authentication, than the Edge server initiates an outgoing session on its internal Access component, contacting the next hop which was defined in the Lync topology builder at deployment. If anything within this traffic doesn’t match Lync specific traffic (e.g. malformed packages) the Edge Server does not process this request. Visually seen, the Edge Server is a fixed component in this communication path. With the VIA parameter, we see an internal and external (NAT) IP address.

See the following example:

Figure 11 Example NATed Lync Incoming Request Flow

From this we can see the path from the client 172.28.91.102 until 10.11.10.84, which is the NATed Access IP of an Edge Server including an external IP (greyed out). The 10.10.10.128 is the internal Frontend server. This NOTIFY commands were received by the local client (172.28.91.102). The second involved Edge Server is the 172.19.45.67, without a public IP. This is because the log was collected on a Lync client in the internal LAN connecting the internal Edge Access interface and obviously doesn’t need to know any public associated IP address.

We can see that there are two Edge servers involved. As a SIP Proxy should look like another hop in this communication path the Lync topology on both Lync environments provide the Edge server the necessary information to where the incoming SIP traffic should be routed first.

Since the topology information is only replicated in a unidirectional method and the Edge Server deployment should be based on Microsoft best practices, meaning DNS should only be configured on the external NIC and internally a HOSTS file should be used, this scenario is considered as safe. Even if the Edge server should be compromised, no internal network information can be acquired.

Highly Secure Deployment

In a secure environment Director Servers are recommended. They are the target for mostly all Internet related traffic, with a single exemption – Frontend Server Web Services traffic. This is still acceptable due to the fact that this traffic is only established once the initial SIP authentication is successfully processed.

Since web-based traffic to resources such as MEET and DIALI-IN don’t require authentication and will be redirected to the Director Servers this security model becomes holistically valid.

Figure 12 Director Pool Configuration

If you wish to take a step further and separate even this traffic, you can do so by simply applying a second Director Pool and making this the preferred target for internal consolidated access. The DMZ based Director Pool will then be the target defined in the EDGE Server NEXT HOP parameter.

The next illustration offers a solution where the “INSIDE DMZ” zone is treated as second defense zone and is allowed to be accessible from internal clients too. Besides the introduced Director Pool, we also have a Reverse Proxy Chain. A chain is where at least two proxy server are configured in a row and depend on one another.

All external Web Services are published with a listener on the first internet facing reverse proxy server, pointing from there towards its chain member, the second reverse proxy, which then directs all requests to it designated destinations.

The Edge Server works in this scenario as described earlier. It just acts as the NEXT HOP configuration point towards the Director Server, implemented as an additional security layer.

The Director now handles SIP and Web Service traffic and builds another line of defense.

Figure 13 DMZ Lync Server 2013 security compliance (with Director pool)

Highly Secure Deployment Multi-Pools

Now we will discuss a highly secure complex design. In this scenario we have an Active Directory Forest with three (3) Domains: The Forest Root Domain CIE.INT and two sub-level Domains, DE and US. Each Domain contains Lync Server components and we have Administrators separated for each security area.

This 4 security areas are:

This is a real life scenario principally designed for a defense corporation with more than 8 Domains, with high secure backbone technologies, full administrative isolations and highly complex requirements in order to satisfy security policies.

Figure 14 DMZ Lync Server 2013 security compliance (real world scenario)

Configure Kemp ESP for Lync (Edge Security Pack)

Now let’s configure a Reverse Proxy solution.

It’s always recommended to run Lync in high availability configuration as it often is deployed as a business critical application for subscribed stakeholders. Therefore, the use of an external Load Balancer is required. Kemp’s hardware-based, virtual and bare-metal software LoadMaster Systems all provide you with needed application load balancing and Reverse Proxy services for Lync 2013 deployments. Natively, a Reverse Proxy, the LoadMaster offers additional features in Microsoft’s end-of-life Forefront Threat Management Gateway (TMG) or the Internet Information Server Application Request Routing (IIS ARR) with its integrated Edge Security Pack (ESP).

Figure 15 Kemp LoadMaster Integrated Reverse Proxy Services

Guiding through the configuration of ESP, we need to have the necessary Lync Web Service information compiled first:

Address (FQDN and Listener IP)	Listener IP	Internal IP	Description
WS-EXT.MYCLOUAD.AG	192.168.20.5		Lync external Web Service FQDN Director Pool
FEPOOL-EXT.MYCLOUAD.AG	192.168.20.6	192.168.20.51 192.168.20.52	Lync external Web Service FQDN Frontend Pool
LYNCDISCOVER.MYCLOUD.AG	192.168.20.5	192.168.20.51 192.168.20.52	LYNC Mobility Services Director Pool
MEET.MYCLOUD.AG	192.168.20.5	192.168.20.51 192.168.20.52	Web Conferencing Landing Page Director Pool
DIALIN.MYCLOUD.AG	192.168.20.5	192.168.20.51 192.168.20.52	Dial-In Information Landing Page Director Pool
SCHEDULER.MYCLOUD.AG	192.168.20.5	192.168.20.51 192.168.20.52	Web Scheduler for Lync Conferences Director Pool

In this configuration example we will demonstrate the Direct Setup only. All other service setup follows the same core principals discussed throughout this white paper.

We will now jump straight into the configuration of LoadMaster Virtual Services which are used to publish load balanced Lync deployments with high availability. For all definitions and detailed walkthrough on all prerequisites and steps, see the Kemp LoadMaster deployment guide for Lync 2013:

http://kemptechnologies.com/files/assets/documentation/7.1/deployment-guides/Deployment_Guide-MS_Lync_2013.pdf

Certificate Deployment

The virtual service used on Kemp LoadMasters to publish Lync services should not be transparent when enabled ESP, therefore we need a valid public certificate assigned to this Virtual Service.

Figure 16 Kemp LoadMaster TLS (SSL) Certificate Deployment

Rules or Regular Expression

As we are aware with an Exchange publishing, we have defined a subset of rules. Generally for Lync this is not necessary due to built-in security measures.

Adding a Virtual Service with ESP

We are now ready with the prerequisites fulfilled and continue with the Reverse Proxy Setup. This setup looks quite similar with the setup we are doing internally for the Lync internal Web Services.

We have defined the NATed IP Listener in the DMZ: 192.168.20.5
and the Server Name as : ESPforLYNC. Since this is the external facing site, the listening port must be: 443 (https)

Figure 17 Creating Kemp LoadMaster ESP Virtual Service

Configuring the Basic and Standard Options

The basic options are setup during the initial activation of a new virtual service and we have no other parameter to be set.

The standard options are addressing the mode and principle of access. We have disabled the transparency option.

Figure 18 Kemp LoadMaster Virtual Service Settings

In Lync 2013 cookie persistence is now optional. If you choose to configure cookie persistence, use the following parameters:

Persistence Option/ Mode: Active Cookie
Persistence Option/ Timeout: 20 Minutes
Persistence Option/ Cookie Name: MS-WSMAN

Sharing Method: least connection

Idle Connection Timeout: 1800 sec

Optionally it is also supported to define source IP persistence:

This setting can have a disadvantage, when a remote client is behind a NATed LAN, the external and therefore visible IP address is persistent. Meaning if there are more than one client connecting form the same location, the load balancing mechanism is not as efficient.
Force L7: True
Persistence Option/ Mode: Source IP Address
Persistence Option/ Timeout: 20 Minutes

Sharing Method: least connection

Idle Connection Timeout: 1800 sec

Figure 19 Kemp LoadMaster Virtual Service Standard Options

Configuring SSL Properties

As this is the Reverse Proxy, SSL is required with the public certificate acquired for external access.

The certificate which was imported during an earlier step will now be assigned to this virtual service.

Figure 20 Kemp LoadMaster SSL Properties

Configuring ESP Options

The actual reverse proxy configuration is part of a virtual service and needs to be activated here. As this acts as a security layer, I recommend enabling all logging options for analysis. An SSO (single sign on) domain must not be set since Lync do not support pre-authentication. Only the Allowed Virtual Hosts are required, so the VS is enabled for listening with security activation (ESP).

The host name (FQDN) for the Director are: WS.EXT/ MEET/ DIALIN/ SCHEDULER/ LYNCDISCOVER.MYCLOUD.AG

Figure 21 Kemp LoadMaster Virtual Service ESP Options

Configuring Real Servers

The load balancer with activated ESP still needs the information for the basic load balancing functionality such as where and against what it should check to determine whether or not defined servers/services are active and healthy. You can copy your own html file on the external web service (IIS) or you use a Lync define path, e.g. /abs/handler to health check against.

Figure 22 Kemp LoadMaster Real Server Helath Checks

The reverse proxy needs to address the correct internal IIS web page on the assigned port 4443. This is a configuration you have to provide for each real server.

Figure 23 Adding Real Server to Kemp LoadMaster Virtual Service

The result after adding the real servers should look like:

Figure 24 Kemp LoadMaster Virtual Service Real Server List

Final Result ESP Setup

With this last step, you finished the entire Reverse Proxy setup and the result should display as ‘green’ and ‘up’.

Figure 25 Kemp LoadMaster Virtual Service Status List

Microsoft Lync provides an enterprise-ready unified communications platform for engaging, accessible and interactive collaboration from virtually any location and any device. For IT organizations, the highly secure and reliable Lync architecture allows for seamless integration with existing collaboration tools, reduced management complexity and flexible deployment options. Microsoft Lync 2013 builds on the innovation ushered in by Microsoft Lync 2010, bringing improved scalability and new features such as persistent chat, Lync Web App and a Plug-In specialized for Virtual Desktop Infrastructure. These, along with new client features that provide for a better user experience, enable users to stay connected and stay productive.

Kemp’s LoadMaster fully supports Microsoft’s key solutions and are approved by Microsoft (Kemp is a Microsoft Gold partner). The LoadMaster efficiently distributes user traffic and secures published Microsoft Lync 2013 deployments so that users get the best experience possible.

Website Links

• For internal Web Services VIPs, set Source_address persistence (internal port 80, 443) on the hardware load balancer. For Lync Server 15, Source_address persistence means that multiple connections coming from a single IP address are always sent to one server to maintain session state.
• Use TCP idle timeout of 1800 seconds.
• On the firewall between the reverse proxy and the next hop pool’s hardware load balancer, create a rule to allow https: traffic on port 4443, from the reverse proxy to the hardware load balancer. The hardware load balancer must be configured to listen on ports 80, 443, and 4443.
  1. FO, the Internet facing zone without domain members,
  2. MO zone a DMZ with contains the second defense line Director Servers as Root domain Members
  3. Domain 1 as user and resources domain
  4. Domain 2 as user and resources domain
  • Kemp Deployment Guide
  • Kemp Lync 2013 Templates
  • Lync Blogspot
  • DNS Load Balancing Blogspot
  • Edge Server Certificate Planning
  • Edge Server Certificate Requirements
  • Credits to Microsoft Lync MVP, Thomas Poett