Conferencing, in Lync Server 2013, has the same default security configuration that we had in Lync Server 2010. Justin Morris, in a post dedicated to Lync Server 2010 conferencing (http://www.justin-morris.net/understanding-conference-security-in-lync-server-2010/), pointed out some of them, including the fact that every Lync user has a meeting URL and a conference ID that never changes by default, and that users invited to a meeting using a PSTN line have the ability to bypass the lobby. If we always use the same conference ID, people outside our company whom we have invited in the past could use it with malicious motivations, or different (unrelated) conferences with different people could merge if our time schedule is not perfect. We will list some steps to improve conferencing security, including a couple of cmdlets from the previously mentioned post.
We can start assessing the security configuration of conferencing for our Lync deployment using
Get-CsMeetingConfiguration.To disable the lobby bypass for PSTN users, use the following cmdlet:
Set-CsMeetingConfiguration -PstnCallersBypassLobby $false
To force users to schedule private meetings (with unique IDs), use the following cmdlet:
Set-CsMeetingConfiguration -AssignedConferenceTypeByDefault $false -EnableAssignedConferenceType $true
Then, we have to work on the conferencing policies. The default global policy allows almost any of the available conferencing features. I suggest that you clone it using
New-CsClonedPolicyfrom Pat Richard (http://www.ehloworld.com/2300). This script is useful to create a new user-conferencing policy called, for example,DefaultConferencing, which will have the same parameters we had in the global policy. The cmdlet we will use is the following one:.\New-CsClonedPolicy.ps1 -SourcePolicyName global -TargetPolicyName "DefaultConferencing" -PolicyType ConferencingPolicy
Restrict the global conferencing policy to match the minimal level of service we will grant to every Lync-enabled user.
To enhance conferencing security, we can also restrict the number of TCP ports involved in the client communication. Launch the
Get-CsConferencingConfigurationcmdlet to look at the applied configuration. IfClientMediaPortRangeEnabledisFalse, then the clients will use a port between ports1024and65535when involved in a communication session. We can use the following cmdlet to force port range (default will be starting from TCP port5350for all the kind of network traffic):Get-CsConferencingConfiguration | Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled $True
As we said, the cmdlet shown in step 6 will use the same TCP port for all the network traffic involved in the clients' communication. We can refer to Chapter 11, Controlling Your Network – A Quick Drill into QoS and CAC to also implement Quality of Service (QoS) and Call Admission Control (CAC).
I suggest that you also read a second post from Justin Morris, which is related to the unique conference IDs, Why You Should and Shouldn't Configure Unique Conference IDs in Lync (http://www.justin-morris.net/why-you-should-and-shouldnt-configure-unique-conference-ids-in-lync/#sthash.W9h9mCzn.dpuf). This post examines the pros and cons of the solution outlined in the previous document in depth.