Securing Lync DeploymentsOctober 2013Microsoft Corporation

2

Lync is secure by design

Perceived threat scenarios

Customers’ approaches

Two-factor authentication

Reverse proxy futures

Agenda

Lync – Secure by Design

4

All communication is secured by defaultIncluding signaling (Session Initiation Protocol - SIP), media (Secure Real-time Transport Protocol - SRTP), content, web traffic (Secure Hypertext Transfer Protocol - HTTPS), and inter-server traffic.An admin must make a change to the configuration to disable this if needed. Can be disabled only for interoperability traffic; inter-server traffic cannot be unsecure.

No accounts are enabled by defaultAccount enabling requires admin interaction.

No users are admin by defaultNo groups are ever added to the admin groups, not even the enterprise admin groups.

External access is disabled by defaultThis access includes mobile devices, devices from home, and federated partners.

PINs are required on phonesUsers must configure a PIN on phones that they use.

Built-in limits to ease the load on Edge ServersFederated partners can send only 20 messages per second; if spam is detected, it is reduced to one message per second.

Lync – Secure by Design

5

The fully qualified domain name (FQDN) of the server occurs in the topology stored in Central Management store (CMS).

The server presents a valid certificate from a trusted CA.

If either of these criteria is missing, the server is not trusted and connection with it is refused. This double requirement prevents a possible, if unlikely, attack in which a rogue server attempts to take over a valid server’s FQDN.

Lync Trusted Servers

6

Lync Server 2013 relies on a public key infrastructure (PKI). Public certificates issued after November 1, 2015 must follow these rules:No private IPNo private DNS namesThe Subject Name / Common Name field is deprecated and discouraged for use

Q: What does this mean when your servers are installed in the contoso.local domain?A: You must deploy an internal enterprise CA.

Certificate Changes

7

Not Security through Obscurity

All specifications are available on MSDNRedline documentation

We actively encourage vendors to build devices and services that interact with Lync securelySNOMPolycomLync Room System vendorsAudiocodesNETDialogicAnd so on > http://technet.Microsoft.com/UCOIP

Open to Secure Third-Party Products

Perceived Threat Scenarios

9

Threat Probability to affect Lync Mitigation solutions

Compromised-key attack Low Protect private PKI keys

Network denial-of-service attack Low Use firewall to throttle Internet

Eavesdropping Very low Protect private PKI keys

Identity spoofing/IP address spoofing Very low Transport Layer Security (TLS) protects from

spoofing IP addresses

Man-in-the-middle attack Very low Protect Active Directory from adding MIM as trusted server

RTP replay attack Very low Lync maintains an index of received SRTP packets

SPIM (spam over Internet Messaging, or IM) Low

Block SPIM-offending IP at firewall or disable federation during the attack. Edge server also automatically throttles down requests if failure/success ratio becomes too high for IM.

Personally identifiable information Low Train users to only accept federation requests from known and trusted individuals.

Perceived Threat Scenarios

10

Greatest challenge when securing Lync

Policies dictate what is and is not secure

“But policy dictates us to… “

Company Policies

Customer Approaches

12

Authentication methodsLync Perimeter as Recommended

Based on standard guidelines

Remote clients are allowedPerimeter servers talk to internal server(s)

Edge Server Reverse Proxy

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote userFederated/Anonymous user

Remote user Anonymous user

Access Edge server NTLM or TLS-DSK

No authentication

Reverse proxy Basic, NTLM, or TLS-DSK

No authentication

Mobile user

13

Addition of Director server

No Edge server, no reverse proxy

Edge for federation and anonymous

“Public” Edge and “private” Edge

Customer-specific MSPL scripts

These are customer variations to make Lync comply with their security policies

They are not Microsoft-recommended approaches

Customer Variations

14

ConsiderationsDirector server is no longer required or recommended in the default scenarioAdds administrative / hardware overheadIf an external attack were to bring down the bridgehead server, this would be the Director

Addition of Director Server

Director Server

Edge Server Reverse Proxy

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote userFederated/Anonymous userMobile user

Director Server

Topology changesAddition of Director server

Director server becomes primary point of login

Customer policyNo direct contact between production servers and perimeter servers

Bridgehead server/Session Border Controller (SBC) between perimeter and internal servers to proxy requests from the Internet

User experience impactMinor delay in sign-in due to redirection

15

No Edge Server, No Reverse Proxy

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote user

VPN

Mobile userFederated/Anonymous user

Topology changesRemoval of Edge serverRemoval of reverse proxyAddition of VPN concentrator

Customer policyAll communication from external must run in a VPN tunnel

No exposure allowed for any services except for VPN concentrator

User experience impactUser has to sign in to VPN before signing in to Lync externallyAll media will travel over VPN (double encryption), adding overhead and serious quality issuesNo federation, no anonymous participants in conferences, no Lync Mobile

ConsiderationsMedia over a VPN is always discouragedAlternative could be to implement an Edge server just for media and use a split tunnel VPN

Edge for Federation and Anonymous

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote user

VPNEdge Server Reverse Proxy

Mobile userFederated/Anonymous user

Topology changesAddition of VPN concentratorDisabling of remote access for Lync users

Customer policyRemote users must always use a tunnel (VPN) when connecting to corporate resourcesFederation/anonymous users are allowed (for meetings and so on)

User experience impactUser has to sign in to VPN before signing in to Lync externallyIf split tunnel is not implemented, media quality will be severely affected when using VPNNo Lync Mobile possible

ConsiderationsCustomer still wants to do meetings with anonymous participants and do federationAdds complexity to maintaining and troubleshooting

17

“Public” Edge and “Private” Edge Servers

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote user

VPN

Edge Server Reverse Proxy

Mobile user

Edge Server

Sig

nalin

g

only

Federated/Anonymous user

Reverse Proxy

Customer policyNo anonymous user can use any of the infrastructure that the authenticated users use

User experience impactNo Lync Mobile possible unless certificates are being deployed to those devicesNew devices have to get all private root certs before using Lync externally

ConsiderationsDual Edge servers are difficult to maintainRequires manual configuration to control signaling and media flowCannot guarantee the media flow to not traverse the public edge

Topology changesAddition of second set of Edge servers with private certsRequires manual configuration on Lync clients

18

Customer-Specific MSPL Scripts

Edge Server Reverse Proxy

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote userFederated/Anonymous userMobile user

Topology changesCreate customer specific MSPL (Microsoft SIP Processing Language) script running on the Edge, Director, Front End or any combination of servers that achieves this.

Customer policyBlock IP if more than three wrong passwords are entered

ConsiderationsCustomers can engage either a partner or Microsoft to create a MSPL script to achieve this capabilityMSPL resides on the SIP processing engine and can inspect, change, and act upon anything in SIP messages

User experience impactNo user experience impact if servers are properly scaled0

19

Customer Approaches Summary

Lync is secure by default but might not fit your organization’s policies.

Customers use the versatility of Lync to fit their organization’s needs.

Multiple roads lead to Rome…

Two-Factor Authentication

21

Introduction

Common request from customersRequires July 2013 update for Lync Server and clientOnly works for Lync 2013 clientLync Phone Edition, web client, Mac client do not support two-factor authentication

Lync mobile adds support for passive authenticationIncludes support for redirection to third party authentication party such as ADFS to enable two factor authentication

Is essentially smart card authentication for Lync client

22

Two-Factor Authentication

Edge Server Reverse Proxy

Front End Server

Inte

rne

tPe

rim

ete

rIn

tern

al

Remote user Mobile userFederated/Anonymous user

Topology changesCreate custom web service configuration on Lync poolsDisable common authentication mechanisms on Director, Front End and Edge servers.Will require separate pools for users with and without two-factor authentication

Customer policyRemote users must use two-factor authentication when signing in to Lync

Internal users must use two-factor authentication when signing in to Lync

User experience impactUser has to be provisioned for smart card (two factor) authentication before using Lync externallyLync Mobile does not workIf the user has not been configured for two-factor authentication, external access does not work

BackgroundTwo-factor authentication was added because of customer requests to comply with internal customer policies in the July 2013 update. Has major impact on Lync client functionality, such as Unified Contact Store, changing PIN ,and other functionality.

Internal user

ADFS & Lync - High LevelInternal

1. The user connects to the Lync Front End

2. Lync Front End redirects the client to ADFS for Authentication

3. ADFS Authenticates and the client can register

External

4. The Client connects to the Lync Edge

5. The Edge forwards the request to the Next Hop (Lync pool or Director

6. Lync Front End redirects the client to ADFS for Authentication

7. The client connects to the ADFS Proxy

8. The ADFS Proxy forwards the request to ADFS

9. ADFS Authenticates and the client can register23

ADFS Proxy

ADFS Service

Lync Edge

Lync Pool

Perim

eter

Inte

rnet

Inte

rnal

Net

wor

k

Internal Lync User

External Lync User

24

Topology RequirementsConfiguration type Service type Server role Authentication

type to disable

Web service WebServer Director Kerberos, NTLM, and Certificate

Web service WebServer Front End Kerberos, NTLM, and Certificate

Proxy EdgeServer Edge Kerberos and NTLM

Proxy Registrar Front End Kerberos and NTLM

More information:http://technet.microsoft.com/en-us/library/dn308562.aspx

25

User Experience

Two-factor authentication with the Lync 2013 clientUser starts Lync clientUser enters SIP addressUser inserts smart card (if physical)User enter smart card password instead of domain passwordSuccessful sign-in

Reverse Proxy Futures

27

“Any reverse proxy is expected to work with Lync Server”

Currently qualified reverse proxies: Threat Management Gateway (TMG ) (licensing stopped November 2012) Internet Information Services Application Request Routing (IIS ARR)

Source : http://technet.microsoft.com/en-US/lync/gg131938.aspx

Reverse Proxy Requirements

28

True, but…“any reverse proxy is expected to work with Lync Server.”

Reverse proxy vendors can get their solution qualified.

Example: Forefront Unified Access Gateway (UAG) – not qualified. Works except for mobile.

But My Reverse Proxy isn’t Listed?

29

IIS Application Request Routing

LAB N will be transitioning Lync RP connections from TMG to an IIS farm with ARR

30

Many Lync enterprise customers deployed Microsoft TMG just to host Lync reverse proxy connections. It is possible to use IIS in Windows 2008 Application Request Routing 2.5 as a reverse proxy replacement.Setup guide: http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

IIS Application Request Routing

Questions?

Resources

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.