Microsoft Lync Server (a combination of “link” and “sync”, see [6]) communications software offers instant messaging (IM), presence, conferencing, and telephony solutions. Lync can be integrated with SharePoint or Exchange to extend its functionalities. Users can e.g. search for specific skills within the Lync client when SharePoint integration is enabled. Exchange is used as a unified store of different user specific data, like contact list.

As we are seeing in our daily business, Lync is becoming more and more a widespread collaboration platform within many companies. Therefore, it’s important to know the issues when implementing Lync and especially the hot spots for weaknesses to keep in mind during concept creation. This blog post will describe some of the top issues, without formal priority.

Lync has many security features built-in. Encryption is for example used by default and cannot be turned off since Lync Server 2013. Furthermore, internal user authentication is handled via Kerberos or client-certificates.

On the other hand, some features like the Federations (connection with other companies) highly increase the attack surface. Additionally, external users can authenticate themselves with NTLM. Therefore, attacks against the user accounts are possible. When not using Federations and external access, many security implications could be eliminated if no Edge server is in use. On the other side, the ease of the use of external access is a great advantage in Lync.

A very basic Lync topology is depicted in the following picture to show the weak spots described later in this post. The numbers on the arrows refer to the sections below.
Lync Topology diagramEdge Server allows us to communicate and collaborate with users located outside the firewall. Remote users (internal users working outside the network) or users from other companies (Federations) connect into the network through the Edge server.

Front-End-Server is used for user authentication and handling of all communication features (IM, voice). It’s responsible for registration and routing requests. All Web components, such as Address Book or the Control Panel (administration panel) are located on the Front-End-Server.

The Director role is used as an intermediate stop between the external users and the Front-End-Server. The Director does not host users but, as a member of an Active Directory domain, it has access to Active Directory Domain Services for purposes of authenticating remote users and routing traffic to the appropriate server or Enterprise pool. Directors can authenticate requests before they are passed to the internal servers. DoS attacks ends on the Directors and don’t reach the Front-End-Servers.

External access (remote users and Federations) is the possibility to use the Lync infrastructure from outside the company’s network. Federations give the possibility to communicate between different companies using Microsoft’s unified communication software. Full communication is possible (VoIP, messaging, conferencing). Remote access is also possible with mobile phones.

1. Threats because of Federations
The following policies are used to control federations and external access:

  • CsExternalAccessPolicy
  • CsAccessEdgeConfiguration

To allow federation on the Edge Server use the following PowerShell command (“Import-Module Lync” if the normal PowerShell is used):

Set-CsAccessEdgeConfiguration –AllowFederatedUsers:$True

Read the AccessEdgeConfiguration:

Get-CsAccessEdgeConfiguration

A further step is needed: every user must be covered by a CsExternalAccessPolicy that enables federation for those users.

Set-CsExternalAccessPolicy –Identity <scope> -<Enable*Access>
  • <Enable*Access> can be one of the following, depending on your needs: EnableFederationAccess, EnableOutsideAccess, EnablePublicCloudAccess, EnablePublicCloudAudioVideoAccess, EnableXmppAccess
  • EnablePartnerDiscovery should be set to false, to restrict federation to those domains specified manually. Otherwise, it enables open federation where companies looking to federate will locate each other through the DNS SRV records and connect automatically.
  • Be careful which external access is allowed for which users (federation, remote user, public IM connectivity, see [5] for more details about the different possibilities).

To see which domains are allowed and/or blocked, use the following get-cmdlets:

Get-CsAllowedDomain
Get-CsBlockedDomain

Inspecting chat traffic and disabling file transfer for only external communication is difficult in Lync. There is no known solution which implements this need. However, traffic monitoring could be applied for specific connections but preventing leakage of a company’s data isn’t available out of the box. This must be considered and kept in mind when using Federations or other external access.

If not used, Federations should be deactivated to mitigate the new possibility to exfiltrate data from the internal network to the outside and therefore bypass possible existing data leakage prevention (DLP) mechanisms.

2. NTLM AD lockouts without proper Edge Server security
The Edge server receives the authentication requests from external users and passes them to the Director resp. to the Front-End-Server. The authentication itself is performed by either one of these two servers inside the network against the Active Directory (AD). NTLM authentication is used when certificates aren’t available.

Therefore, NTLM lockout attacks could be performed against internal users. To mitigate this issue, block NTLM requests from outside and use only certificate based login for external users. This can be enforced by a policy which requires that the initial login request (always NTLM or Kerberos based) is only performed from inside the internal network.

Besides blocking NTLM request, the use of a security filter on the Edge server could be used to prevent the lockout of internal AD user. Such security filters handle failed login attempts on the Edge Server and don’t pass every login request to the Director or Front-End server.

3. The “Certificate-based-login” pitfall
Using certificate authentication has many advantages. One of them is availability: when a domain controller is not reachable, users can still log in because authentication relies solely on the client certificate. However, if the users are disabled in Lync and/or in the AD, they can continue to log in (which was an advantage one sentence earlier). Business processes such as those handling the decommissioning of user accounts must be adapted accordingly to prevent further usage of Lync for a disabled user (see [2][3]).

You can read the certificates used by a user with the following PowerShell command:

Get-CsClientCertificate –Identity <userID>

Revoke these certificates with the following command:

Revoke-CsClientCertificate –Identitiy <userID>

<userID> is the SIP name of the user, e.g. sip:name@lync-domain.tld

You can also use the Control Panel to revoke the certificates by using “Remove user certificate” on the specific user.

Really important side-note: A certificate is generated for each individual client, not each user. So the same user can have many certificates depending on the amount of devices he installed Lync on.

4. No End-To-End Encryption
The IM and web conferencing are encrypted between the different Lync components (e.g. Client and Front-End) but not end-to-end from the Client to the Client. There is no mitigation for this within the Lync environment and must be considered when evaluating it. This has different desired and needed reasons, e.g. archiving, monitoring or troubleshooting. Audio and video can’t be archived and are always encrypted between the endpoints (for federated partners, the Edge server is still in the middle). See [4] for more details about the communication paths.

However, the ability of snooping traffic on the Front-End-Server conflicts with the requirements for privacy and end-to-end encryption. Even Microsoft itself gives detailed instructions how to intercept the traffic, for troubleshooting reasons of course (e.g. [1], could also be done with Wireshark). And don’t forget the Lync archiving mechanisms which record all the data.

5. Role-Based Access Control (RBAC)
Lync introduced RBAC in Lync Server 2010 and enhanced it in Lync Server 2013. With RBAC, administrators can be granted only permissions they really needed for their tasks. An administrator is e.g. granted the rights to run certain PowerShell cmdlets. Cmdlets are used in the PowerShell to perform an action and typically return a Microsoft .NET Framework object to the next command in the pipeline. Besides a nice collection of predefined RBAC roles, custom roles can be created and then used to secure the execution of specific cmdlets.

The really important fact is, that RBAC only takes effect when you are using PowerShell or the Lync Control Panel (which in fact only executes cmdlets) remotely. You can see the cmdlets you are allowed to run by executing the following command:

Get-Command

To see the allowed cmdlets for a specific role, use the following command

Get-CsAdminRole [-Identity <role-name>]

The “Cmdlets” description is limited within this output. With the following command, you can expand this attribute:

Get-CsAdminRole –Identity <role> | Select-Object –ExpandProperty Cmdlets

When using the LSMS (Lync Server Management Shell) or the Control Panel on the Lync Server, the RBAC isn’t used. Instead the administration rights are governed by membership of the Real Time Communications (RTC) named groups.

Check roles and users in the special Lync groups and apply a strict RBAC approach. Follow the least privilege principle and only grant minimal permissions for the required cmdlets.

The most powerful Lync RBAC groups are:

  • CsAdministrator
  • CsServerAdministrator
  • CsUserAdministrator

Interesting fact: although CSAdministrator has the most functionality available in a role, it doesn’t enable you to run all the commands that exist in the Lync PowerShell.

The most powerful Lync RTC groups are:

  • RTCUniversalServerAdmins
  • RTCUniversalUserAdmins

Conclusion
As we just saw, Lync is a versatile solution which affects different components in an existing infrastructure. A default Lync installation has many security features available and enabled. It is important to understand its architecture and features before implementing it. There are different issues which must be kept in mind when using Lync. The above list should give you an overview about different spots to look at. We’ve seen that Federations gives a great new possibility to easily connect companies, but there are privacy issues and the NTLM attack vector which could be opened when not using the correct configuration. Or the new certificate based login approach increases the security of the login procedure but raises the new risk that a disabled user can continue using Lync.

This leads to the conclusion that despite a quit secure default installation of Lync, a proper understanding of all the security features and configuration must be acquired and applied to provide the most secure environment.

Further blog posts regarding Lync security features:

References
[1] http://blogs.technet.com/b/nexthop/archive/2012/02/15/how-to-decrypt-lync-2010-tls-traffic-using-microsoft-network-monitor.aspx, last visit on 15.01.2014
[2] http://www.expta.com/2011/03/disabling-user-in-ad-does-not-disable.html, last visit on 15.01.2014
[3] Mastering Lync Server 2013, Keith Hanna, Nathan Winters, 2013, p. 90
[4] Microsoft Lync Server 2013 Protocol Workloads Poster, http://www.microsoft.com/en-us/download/details.aspx?id=39968, last visit on 15.01.2014
[5] Overview of External User Access, http://technet.microsoft.com/en-us/library/gg398775.aspx, last visit on 15.01.2014
[6] Lync Server 2013, http://office.microsoft.com/de-ch/lync/, last visit on 15.01.2014