Lync is secure by design Perceived threat scenarios Customers’ approaches Two-factor authentication Reverse proxy futures

All communication is secured by default 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 accounts are enabled by default Account enabling requires admin interaction.

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

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

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

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 server’s 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 Eavesdropping Identity spoofing/IP address spoofing Man-in-the-middle attack RTP replay attack SPIM (spam over Internet Messaging, or IM) Personally identifiable information

Probability to affect Lync

Low Low Very low Very low Very low Very low Low Low

Mitigation solutions

Protect private PKI keys Use firewall to throttle Internet 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.

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 Front End Server

Access Edge server Reverse proxy

Remote user

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

Anonymous user

No authentication No authentication

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 Edge Server Reverse Proxy Customer policy

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

User experience impact

Minor delay in sign-in due to redirection

Director Server Director Server Front End Server Topology changes

Addition of Director server Director server becomes primary point of login

Considerations

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

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

Topology changes

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

Front End Server User experience impact

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

Front End Server Edge Server Reverse Proxy 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 Reverse Proxy Front End Server Edge Server Reverse Proxy 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 maintain

Considerations

Dual Edge servers are difficult to 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 Front End Server User experience impact

No user experience impact if servers are properly scaled0

Considerations

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

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…

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 Edge Server Reverse Proxy Front End Server Federated/ Anonymous user Internal user Customer policy

Remote 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 impact

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

Topology changes

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

Background

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.

External Lync User 23 ADFS Proxy Lync Edge ADFS Service Lync Pool 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 More information: http://technet.microsoft.com/en-us/library/dn308562.aspx

Authentication type to disable

Kerberos, NTLM, and Certificate Kerberos, NTLM, and Certificate Kerberos and NTLM Kerberos and NTLM

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-server 2013.aspx