Lync – Privacy Configuration

We have shortly described the Lync federations in a previous post. With the usage of federations the question comes about the privacy and the security of the user’s information (e.g. presence information). There are scenarios where an employee doesn’t answer the phone but is mentioned as “available” in Lync. This could lead to a misunderstanding and bad mood at the customer’s or a partner’s side because the person “should” be available. Other scenarios involve e.g. stalking a given person using his present / idling status. These are just two practical examples – without mentioning any legal aspect – why there are good reasons to restrict access to this kind of information.

A further restriction could be set to only allow communication request of persons who are already in the contact list. Lync doesn’t offer many options for this. So in this post we try to show you the spot to look at to enhance privacy in Lync.

The following cmdlets are involved depending on your infrastructure:

  • CsPrivacyConfiguration
  • CsAccessEdgeConfiguration
  • CsHostingProvider
  • CsPublicProvider

Lync offers an option to limit access to your presence information to the people you already have in your contact list. Unfortunately, there is no distinction of corporation: you can’t just give access to your presence information to people of your company while restricting access for federated contacts present in your contact list. So either restrict access for all or nobody in your contact list.

Quote from “Configuring Enhanced Presence Privacy Mode” [2]:

“With enhanced presence privacy mode, users can restrict their presence information so that it is visible only to the contacts listed in their Lync 2013 Contacts list. The New-CsPrivacyConfiguration and Set-CsPrivacyConfiguration cmdlets have an EnablePrivacyMode parameter controls this option. When EnablePrivacyMode is set to True, the option to restrict presence information to contacts becomes available in the Lync 2013 Status options. When EnablePrivacyMode is set to False, users can choose either to always allow everyone to see their presence information or to adhere to any future changes the administrator makes to the privacy mode.”

PS> Get-CsPrivacyConfiguration

Identity : Global
EnablePrivacyMode : True
AutoInitiateContacts : False
PublishLocationDataDefault : False
DisplayPublishedPhotoDefault : False

Further quote from [2]:
“[…]Lync 2013 and Lync 2010 privacy settings are not honored by previous versions (Microsoft Office Communicator 2007 R2 or Microsoft Office Communicator 2007). If previous versions of Office Communicator are allowed to sign in, a Lync 2013 user’s status, contact information, or picture could be viewed by someone who has not been authorized to view it […]

In a migration scenario and due to these aforementioned compatibility reasons, enforce the following points before you enable enhanced presence privacy mode:

  • Ensure that every user has Lync 2013 installed.
  • Define a client version policy rule to prevent previous versions of Communicator from signing in.

[…]”

Lync Server 2013 has public provider configurations for America Online, Windows Live and Yahoo! instant messaging. Each public provider is configured with the provider’s Edge server fully qualified domain name, and the default verification level is set to “Allow users to communicate only with people on their Contacts list who use this provider” (CsHostingProvider and CsPublicProvider). This default setting will limit communication to contacts that you have accepted and are in your contact list.

Selecting “Allow users to communicate with everyone using this provider” removes the restriction. Anyone can now retrieve your presence information, without you received and accepted a contact invite. This setting does not limit who can contact you from the public provider’s network.

A further VerificationLevel property is used to monitor and assess the verification level of incoming messages (CsAccessEdgeConfiguration, [3]). Valid values are:

  • AlwaysVerifiable: All requests received on the default route are marked as verified. If a verification header is not present it will automatically be added to the message.
  • AlwaysUnverifiable: Messages are passed only if the addressee (the user the message is intended for) has configured an Allow ACE (access control entry) for the person who sent the message.
  • UseSourceVerification: Message verification is based on the verification level included with the message. If no verification header is present then the message will be marked as unverified.

We strongly recommend to use “AlwaysUnverifiable” for the VerificationLevel.

Conclusion
There are not many options to limit access to presence information and how the communication is established to federated users, but the few options should be evaluated during the implementation phase. With the privacy setting, the users are able to restrict access to their presence information for those people who are on their contact list.

We recommend to use the privacy mode and to restrict the communication establishment as strictly as possible.

References
[1] Privacy supplement for Microsoft Lync 2013, http://office.microsoft.com/en-us/lync-help/privacy-supplement-for-microsoft-lync-2013-HA102762444.aspx, last visited 26.01.2014
[2] Configuring Enhanced Presence Privacy Mode, http://technet.microsoft.com/en-us/library/gg399028.aspx, last visited 26.01.2014
[3] Set-CsAccessEdgeConfiguration, http://technet.microsoft.com/en-us/library/gg413017.aspx, last visited 26.01.2014

Lync – Top 5 Security Issues

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