Lync is secure by design

Perceived threat scenarios

Customers approaches Two-factor authentication Reverse proxy futures

All communication is secured by default No accounts are enabled by default

Account enabling requires admin interaction.

Including 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 users are admin by default PINs are required on phones

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

External access is disabled by default

Users must configure a PIN on phones that they use.

This access includes mobile devices, devices from home, and federated partners.

Built-in limits to ease the load on Edge Servers

Federated partners can send only 20 messages per second; if spam is detected, it is reduced to one message per second.

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 servers FQDN.

Lync Server 2013 relies on a public key infrastructure (PKI). Public certificates issued after November 1, 2015 must follow these rules:
No private IP No private DNS names The 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.

Not Security through Obscurity

All specifications are available on MSDN

Redline documentation

We actively encourage vendors to build devices and services that interact with Lync securely
SNOM Polycom Lync Room System vendors Audiocodes NET Dialogic And so on > http://technet.Microsoft.com/UCOIP

Threat
Compromised-key attack Network denial-of-service attack

Probability to affect Lync

Low Low

Mitigation solutions
Protect private PKI keys Use firewall to throttle Internet

Eavesdropping
Identity spoofing/IP address spoofing Man-in-the-middle attack RTP replay attack

Very low
Very low Very low Very low

Protect private PKI keys

Transport Layer Security (TLS) protects from spoofing IP addresses Protect Active Directory from adding MIM as trusted server Lync maintains an index of received SRTP packets 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. Train users to only accept federation requests from known and trusted individuals.

SPIM (spam over Internet Messaging, or IM)

Personally identifiable information

Low

Low

Greatest challenge when securing Lync

Policies dictate what is and is not secure

But policy dictates us to

Remote user

Mobile user

Federated/ Anonymous user

Edge Server

Reverse Proxy

Remote user Access Edge server

Front End Server

Anonymous user No authentication No authentication

NTLM or TLS-DSK Basic, NTLM, or TLS-DSK

Reverse proxy

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

Remote user

Mobile user

Federated/ Anonymous user

No 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

Customer policy

Addition of Director server

Topology changes

Director server becomes primary point of login

Edge Server

Reverse Proxy

Minor delay in sign-in due to redirection

Director Server Director Server

User experience impact

Front End Server

Director server is no longer required or recommended in the default scenario Adds administrative / hardware overhead If an external attack were to bring down the bridgehead server, this would be the Director

Considerations

Remote user

Mobile user

Federated/ Anonymous user

Customer policy All communication from external must run in a VPN tunnel No exposure allowed for any services except for VPN concentrator User experience impact

Topology changes Removal of Edge server Removal of reverse proxy Addition of VPN concentrator

Front End Server

User has to sign in to VPN before signing in to Lync externally All media will travel over VPN (double encryption), adding overhead and serious quality issues No federation, no anonymous participants in conferences, no Lync Mobile

Considerations Media over a VPN is always discouraged Alternative could be to implement an Edge server just for media and use a split tunnel VPN

Remote user

Mobile user

Federated/ Anonymous user

Customer policy Remote users must always use a tunnel (VPN) when connecting to corporate resources Federation/anonymous users are allowed (for meetings and so on)

Topology changes Addition of VPN concentrator Disabling of remote access for Lync users

Edge Server

Reverse Proxy

Front End Server

User experience impact User has to sign in to VPN before signing in to Lync externally If split tunnel is not implemented, media quality will be severely affected when using VPN No Lync Mobile possible

Considerations Customer still wants to do meetings with anonymous participants and do federation Adds complexity to maintaining and troubleshooting

Remote user

Mobile user

Federated/ Anonymous user

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

Topology changes Addition of second set of Edge servers with private certs Requires manual configuration on Lync clients

Edge Server Edge Server Reverse Proxy

Reverse Proxy

Front End Server

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

Considerations Dual Edge servers are difficult to maintain Requires manual configuration to control signaling and media flow Cannot guarantee the media flow to not traverse the public edge

Remote user

Mobile user

Federated/ Anonymous user

Customer policy Block IP if more than three wrong passwords are entered

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

Edge Server

Reverse Proxy

User experience impact No user experience impact if servers are properly scaled0

Front End Server

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

Considerations

Lync is secure by default but might not fit your organizations policies. Customers use the versatility of Lync to fit their organizations needs. Multiple roads lead to Rome

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

Lync mobile adds support for passive authentication

Includes support for redirection to third party authentication party such as ADFS to enable two factor authentication

Is essentially smart card authentication for Lync client

Remote user

Mobile user

Federated/ Anonymous user

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

Customer policy

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

Create custom web service configuration on Lync pools Disable common authentication mechanisms on Director, Front End and Edge servers. Will require separate pools for users with and without two-factor authentication Two-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.

Topology changes

Edge Server

Reverse Proxy

Front End Server

Internal user

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

User experience impact

Background

External Lync User

Perimeter

Internet

ADFS Proxy

Lync Edge

Internal Network

ADFS Service

Lync Pool

23

Internal Lync User

Configuration type Web service Web service Proxy Proxy

Service type WebServer WebServer EdgeServer Registrar

Server role Director Front End Edge Front End

Authentication type to disable Kerberos, NTLM, and Certificate Kerberos, NTLM, and Certificate Kerberos and NTLM Kerberos and NTLM

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

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

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

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.

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

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-server2013.aspx