In a previous post Understanding Conference Security in Lync Server 2010, I detailed the difference between public and private meetings, how assigned conferences work in Lync and the user experience. When you first deploy and configure Lync, users schedule meetings with the same meeting join URL and conference ID every time. However there are some scenarios where this ease of access exposes a vulnerability, especially if there is heavy conference usage. In this post, I’m going expand to on my last post to cover the business reasons why you’d want to configure unique URLs/conference IDs and what the pros and cons are of configuring this.

Business Security Justification

Imagine this scenario. I use the same conference ID and meeting URL for every Lync meeting. I happen to schedule a meeting from 3pm to 4pm with my HR manager to discuss salaries and head count of a particular team of people. I also have a 4pm call scheduled with the Sales team to talk forecasts and targets.

I join the 3pm call and discuss confidential HR  information for the hour. We get engrossed in things and my call runs over time. 4pm rolls around and all my sales people join their scheduled meeting using the same URL and ID that my HR people used to join. What do you think would happen if a large group of people joined the call right as we were discussing whether we should keep their team in the company?

That would be an awkward moment.

Or perhaps I’ve sent my conference details to external parties in the past, like industry analysts or journalists, to discuss news or announcements. Then out of the blue, something happens in the company or within a client project that causes our share price to plummet. What if my conference details were to fall into the hands of someone that wanted an inside scoop on what was going on? My conferences could get hijacked by unscrupulous people, leaving me exposed and without secure conferencing facilities.

Configuring unique meeting URLs and conference IDs in Lync solves this problem, and ensures that conference details are never the same for any two meetings.

Potential Pitfalls and Alternatives

This does look like a great solution on face value. It ensures conferences are completely secure and there is no chance of hijack, but at what impact to the user experience?

For starters, this means users don’t have a static conference ID they can use for ad-hoc conferences when they’re not in front of their PC (as they need to use Outlook or the Web Scheduler to generate conference details). This means that if I’m at lunch and have a brainwave and want to get a few people on a call ASAP to discuss the idea, I don’t have any conference details memorised that I can give to people to join by quickly putting the conference details in an email, SMS or telling them over the phone. This represents a significant blocker that will slow the user adoption of Lync.

The other thing to consider here is that conference IDs can reach 10 or 12 (or more) digits long because Lync is generating new ones for each conference for each users. Sending out such long conference IDs could degrade the experience for users joining from the PSTN (this can be somewhat alleviated by creating new conference directories on the Front End pool).

There is an alternative to configuring unique conference IDs and URLs. You could leave static IDs/URLs in place and instruct users to modify meeting options (in the Lync Meeting before they send the invite) if a secure conference is required. This means they will always have the flexibility of consistent conference information, but can provide a secure meeting if the scenario requires it.

Conclusion

Enforcing unique conference information looks like a great way to solve security concerns on face value, but this and every option in Lync should be completely assessed from both a technical, security and user experience perspective to ensure there’s some degree of balance provided.