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.

Note

Information about Form base authentication

Even though there is forms based authentication, you cannot pre-authenticate the users using reverse proxy. This is not a supported configuration. Lync provided forms based authentication simplifies the deployment, so a simple, but Lync aware web traffic redirect can be used.

 

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).
 

Note

Office Web Application

Office Web Application Server is required for PowerPoint html5 rendering, this is not handled by the conferencing service

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.

Note

Certificate requirements A/V Edge

All Edge server traffic must be encrypted using TLS. It is necessary that public certificates are assigned to Access Edge Service interface and Web Conferencing Edge Services interface. Audio/ Video Edge Service does not require a certificate assigned to its interface, the certificate must be assigned to the A/V Authentication Service. The A/V Edge service does not use the subject name or the subject alternative names entries.

 

 

Important or Warning

A/V Authentication Certificate Information

The A/V Authentication Service Certificate in Lync Edge Pool must share the same Private Key.

The Edge Services are ignoring the Certificates Subject Name, therefore only the Subject Alternative Names (SAN) are used and important

 

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.

Note

Front End Web Service

Every Lync Frontend Server has its own web services which need to be published via the Reverse Proxy. Those services cannot be redirected via the Director Server.

NOTE:

IIS Server

An essential security mechanism from a Lync 2013 perspective is the ability to segregate web services into internal and external IIS web pages. An added benefit is that if one service or even an entire web page is compromised or crashes, the entire system will not run into issues. Another security opportunity is based on the certificate assignment to the individual web sites, along with dedicated CN assignments and separation with different TCP/IP ports.

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.

Remark

Discover URL pointing direction

LYNCDISCOVERYINTERNAL -> (must point to) the Frontend Pool WebService VIPs

Frontend Server internal mobility URL -> (must point to) the Reverse Proxy external IP

Frontend Server external WebService URL -> (must point to) the Reverse Proxy external IP

 

Note

Mobility

Although mobile applications can also connect to other Lync Server 2013 services, the requirement to send all mobile application web requests to the same external web fully qualified domain name (FQDN) applies only to the Lync Server 2013 Mobility Service. Other mobility services do not require this configuration. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN

 

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:

   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.

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.

Note

Incoming Protocols

Starting with the initial principals is defining the incoming protocols. Here we have SIP, PSOM, STUN, RTP and HTTPS. We, also during the next topology definition, will not allow any unencrypted traffic, therefore HTTP is not relevant. Additionally, make the illustration easier in understanding, we have consolidated all Edge Server relevant protocols in the word SIP.

 

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

 

Note

Security model and internal DNS targets

If we apply this security model, you need to be aware, that all internal DNS targets will have to point to this Director Pool  too.

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)

 

Note

Mobility Design

Difficult in all those design is the Lync Mobility design. The clients need as defined in the prerequisites access to the same Reverse Proxy entry point for internal (WLAN) and external (3G). With a chained proxy it can be difficult. This should be discussed with your internal security officers how internal WLAN client can establish those required connections.

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:
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

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.

Machine generated alternative text:
KEMP 
Main Menu (bal) 
Home 
Virtual Services 
Add New 
Vie'.v/McdiF,' Services 
Manage Templates 
Manage SSO Domains 
Global Balancing 
Sta tistics 
Real Servers 
Rules & Checking 
Content Rules 
Check Parameters 
Certificates 
System Configuration 
-Back 
LoadMaster 
Properties of tcp/192.168.20.5:443 
Properties for tcp/192.168.20.5:443 - Operating at Layer 7 
Service Name 
Alternate Address 
Service Type 
Activate or Deactivate Service 
Transparency 
Persistence Options 
Scheduling Method 
Idle Connection Timeout 
use Address for Server NAT 
Quality of Service 
Basic Properties 
ESPforLYNC 
HTTP/HTTPS 
Duplicate VIP Change Address 
Set Nickname 
Set Alternate Address 
Set Cookie 
Disabled 
Mode: 
Timeout: 
Standard Options 
Active Cookie 
20 Minutes v 
Cookie name: MS-WSMAN 
least connection 
1800 
Set Idle Timeout 
Normal-Service 
SSL Properties (Acceleration Enabled)

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

Machine generated alternative text:
Force L7 
Transparency 
Extra Ports 
Persistence Options 
Scheduling Method 
Idle Connection Timeout 
Mode: 
Standard Options 
Set Extra Ports 
Source IP Address v 
Timeout: 20 Minutes V 
least connection 
1800 
Set Idle Timeout

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’.

Machine generated alternative text:
KEMP 
Main Menu (bal) 
Home 
Virtual Services 
Add New 
Vie'.v/McdiF,' 
Manage Templates 
Manage SSO Domains 
Global Balancing 
02: 
32:09 PM 
Add New 
Virtual IP 
Address 
1 192.168.20.5:443 
2 192.168.20.42:443 
Pro 
tcp 
tcp 
LoadMaster 
Virtual Services 
Name 
ESPforLYNC 
Exchange2013 
tu 
Certificate 
Installed 
Scheduler 
Real Servers 
Action 
Modify 
Delete 
Modify 
Delete 
Laye 
192. 
192. 
192. 
192. 
168. 
20.51 
168. 
20.52 
168. 
20.40 
168 
.20.44 
least connection 
EXT.MYCLOUD.AG 
weighted least 
on Real Server 
connection

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

 

[1] At time of write this white paper, Windows Server 2012 R2 Web Application Proxy is NOT officially supported, due to problems handling Lync deployments with multiple SIP Domains.