Lync perimeter—recommended topology

Adding a Lync Director

Remote access through VPN

Translates one or more internal addresses to one external address

Allows connections from private network

Blocks connection from public networks

Security versus usability

Blocks unwanted traffic

Might also block wanted traffic

Sharing of IP addresses

Controlling data traffic from the internet

Reachable: on the internet

Proxies all SIP traffic

STUN reflects NAT addresses (b) and (e)

TURN relays media packets (c) (d) (x) (y)

Lync Edge Server in the topology

ms-user-

lomrasUri>sip:Mras.contoso.com

gon-data: RemoteUser

< SIP Service <location>internet</location>

<hostName>edge.contoso.com

<udpPort>3478

<tcpPort>443

<username> 77qq8yXccBc2lwOmFy

<password> Wnujl0eo00YkV/5dg=

<duration>480

<hostName>94.245.124.238

<udpPort>3478

<tcpPort>443

<username> 77qq8yXccBc2lwOF

<password>

Wnujl0eo00YkV/5g=

<duration>480

c :: a, b, c, d, e

y :: v, w, x, y, z

y :: v, w, x, y, z

IPv4 before IPv6

Direct before relay

UDP before TCP

Requires 50,000-59,999 TCP/UDP outbound and inbound

For compatibility with OCS 2007, 50,000-59,999 TCP/UDP outbound and inbound

Requires “50,000-59,999 TCP outbound”

A/V Edge service interface Any TCP 50,000-59,999 TCP 443

A/V Edge service interface Any UDP 3478 UDP 3478

Any A/V Edge service interface Any TCP 443

Any A/V Edge service interface Any UDP 3478

Reverse proxy

Microsoft Unified Communications Open Interoperability Program (UCOIP): “while any reverse proxy is expected to work with Lync Server, the reverse proxies listed below have completed extensive testing and are posted with detailed deployment white papers to assist in configuration”

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

• For example: Windows Server 2012 R2 Web Application Proxy (WAP)—not qualified, but works as reverse proxy and is supported

Reverse proxy vendors can get their solution qualified

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

Customers seeking a replacement for TMG

Often Microsoft TMG was deployed to host Lync Reverse Proxy connections only

IIS in Windows 2008 (or later) Application Request Routing 2.5 is qualified and supported as reverse proxy replacement

Detailed setup guidance published at http://blogs.technet.com/b/nexthop/archive/2013/02/19/ using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

Replacement for the previous AD FS Proxy role

Web Application Proxy (WAP) acts as a reverse proxy and as an ADFS proxy

Requires a Windows Server 2012 R2 ADFS server

Detailed setup guidance published at http://technet.microsoft.com/en-us/library/dn280944.aspx and http://blogs.technet.com/b/dodeitte/archive/2013/10/29/how-to-publish-lync-server-2013- web-services-with-windows-server-2012-r2-web-application-proxy.aspx

Implementing Two-Factor Authentication

Provides improved security by requiring users to meet two authentication criteria: a user name/password combination and a token or certificate

Includes support for redirection to third-party authentication, such as Active Directory Federation Services (ADFS) to enable Two-Factor Authentication Passive Authentication (Lync Server gets out of the “authentication business”)

Multi-factor Authentication (also MFA, Two-Factor Authentication, two-step verification, TFA, T-FA or 2FA) is an approach to authentication that requires the presentation of two or more of the three authentication factors: a knowledge factor ("something only the user knows"), a possession factor ("something only the user has"), and an inherence factor ("something only the user is"). After presentation, each factor must be validated by the other party for authentication to occur.

http://en.wikipedia.org/wiki/2FA

Subsequent updates for client, server, and mobile client (for example: Android)

Lync Online using Authentication Tickets obtained with username/password

Lync Phone Edition, web client, and Mac client do not support Two-Factor Authentication

NTLM for every query (prompt for credentials unless admin authorizes local storage of credentials)

Can remove EWS dependent capabilities from client

• (For example: Set-CsMobilityPolicy—AllowExchangeConnectivity <$true | $false>)

Provided by Certificate Provisioning Service on Front-End

Lync certificate used for subsequent re-authentication to Lync Server (to obtain Web Ticket)

Also available on mobile clients with recent updates (previously only NTLM for mobile clients)

Proven model, used for several releases for Lync clients on PC, Lync Phone Edition, etc.

Scoped to Lync Server only, provides no rights to other corporate resources

Stored on device in a location that does not allow access from other applications

Certificate is revocable by Lync Admin (PowerShell cmdlet)

After certificate is revoked and Web Ticket expires, user is signed out and must sign back in using initial sign-in process

Sign out (both user or server provoked) requires user to sign back in using initial sign-in process

Certificate lifetime and automatic renewal manageable by Lync Admin

Initially introduced for Lync 2013 PC client

Example use: user accounts and Lync in separate forests without trust

Server delegates authentication to trusted Security Token Service (STS) i.e., ADFS (redirects client to Security Token Service (STS))

STS serves custom authentication web page, rendered within Lync app (Trident page)

Authentication uses form entries in Trident page and can use certificate on device or smart card, mobile clients can support forms-based multifactor (password + OTP or SecureID, etc.)

STS passes token back to client, which presents it to Lync Server

Lync Server trusts the token and authorizes the user

Cannot be client policy because client would only obtain it after authentication

Server policy—scope per pool, affects all users and all client types

Enable Passive Authentication, disable Kerberos and NTLM

User starts Lync client

User enters SIP address

User is prompted to insert smart card (physical or uses virtual in Windows 8) by ADFS STS

User enters smart card PIN instead of domain password

Successful sign-in

User starts Lync client

User enters SIP address

User is presented with Trident page and uses, for example, SecureID or OTP

Successful sign-in

Establish a trust partnership from ADFS to Lync Server

Configure ADFS to support client authentication

On Lync Server, disable Kerberos and NTLM, enable Passive Authentication and Certificate Authentication (Registrar and Web Services)

Configure Lync Server to trust the Federation Service Name of ADFS

Grant desired policies to users

Ensure Autodiscover points to a pool configured for Passive Authentication, or provide manual configuration

http://technet.microsoft.com/en-us/library/dn308569.aspx (generic server configuration for Passive Authentication)

http://blogs.technet.com/b/jenstr/archive/2013/10/09/microsoft-lync-2013-for-mobile-and-passive-authentication.aspx (step by step configuration for Lync Mobile)

http://aka.ms/UNC323

Session Evaluation

Appendix

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

Account enabling requires admin interaction

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

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

Users must configure a PIN on phones that they use

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

Server Fully Qualified Domain Name (FQDN) must match the name in the Lync topology stored in Central Management Store (CMS)

Server must present a valid certificate

The server certificate must be from a trusted Certificate Authority (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

Important changes for organizations that use public certificates internally

Private IP addresses may no longer be part of a certificate

Private DNS names may no longer be part of a certificate

The Subject Name/Common Name field is deprecated and discouraged for use

After 2015, it will be impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified

An internal enterprise Certificate Authority (CA) is required

Redline documentation

SNOM

Polycom

Lync Room System vendors

Audiocodes

Sonus

Etc.