Securing Lync is Critical, especially now a day, where security breaches are common.
Our focus will be on securing external access to Lync. Lync Edge server and Director server are here for that, for providing external access to Lync and protect it in the same time.
Lync Core Security
Lync in its core provide security by encrypting the travelling Signaling and Media traffic. In addition to the Normal user authentication using Active Directory Username and password, PIN and Extension authentication coupled with Certificate authentication are used on the Lync Phone edition devices.
Signaling Traffic
For communications between servers, Lync is using MTLS to secure the communication between servers. For communication between your mediation server and the Gateway, it’s recommended to use TLS if supported by your Gateway.
When MTLS is used, servers exchange Certificates, those certificates are issued by internal CA that is trusted by both servers.
For communications between the Lync Client and the Lync server, TLS play a role here for securing and encrypting the communications.
As for Reverse proxy it’s using SSL and TLS (HTTPS) for securing the web services.
Media Traffic
For media traffic, the protocol used for encrypting and securing the data is SRTP (Secure Real-Time transport Protocol).
Client Authentication:
There is a number of ways that users authenticate against Lync, e.g. internal client , external, phone device…etc.
If the user is inside the LAN, the authentication will happen using Kerberos, if the user is outside the LAN then it will authentication will be via NTLM, because Kerberos need to access Active Directory for authentication, in general Kerberos is more secure than NTLM simply because the Password is never sent through.
If for some reason your infrastructure is not allowed to use NTLM in it, you might need to consider implementing Direct access using UAG 2010.
As mentioned in beginning of this article, there is the PIN authentication method, usually used for Phones, in this method the user uses his/her PIN + the Phone extension to logon to the phone, which download a certificate with the user in either the subject or subject alternative name, and it must be issued by a root CA that is trusted by the servers running Lync.
Lync Externally
If you decided to deploy Lync Edge to provide secure External access to your users, then follow this article to understand more about how Lync Edge, Lync Director and the Reverse Proxy can be used to provide external access for your users and Partners while keeping it secure.
Edge Server
Lync Edge is one of the components that is used to provide external access, Edge has a number of roles that are consolidated onto a single server, not like the old OCS days when you could have a whole range of different roles split onto different servers.
You can deploy the Edge Server using one of the following topology options:
- Single Consolidated Edge
- Scaled Consolidated Edge with DNS load balancing
- Scaled Consolidated Edge with Hardware load balancing
The components (Roles) provided by the Lync Edge are
- Access
- Access edge act as a SIP proxy server, its concern with only passing SIP authentication traffic (as Edge server is not joined to the Domain it cannot authenticate users) from the external users to the next hop which is usually either the Front-end server/pool or the Director server/pool.
- AV
- AV edge used for Lync ICE protocol, the ICE protocol is used to enable the media traffic to travel in a NAT infrastructure.
- Web conferencing
- Web Conferencing edge act as a PSOM proxy, PSOM is the protocol used to provide access to the conference data such as whiteboard, Poll pages and slides, this is done with conjunction of the access edge and reverse proxy.
Each one of those roles provides specific security capabilities and has specific requirements, each one require a certificate that have the correct name of the services as well as a specific port to be opened in your firewall.
Director Server
The Lync Director Server, as understood from the name of it, provide user authentication and redirect the user to a front-end server that it’s home at, This means that all user authentication requests first hit the Lync Director, which can then authenticate and route the traffic to the correct Lync front-end-server.
Another benefit of the Director server, as it’s the stop of the traffic coming from the Lync Edge to the Front-end, its used to protect against DOS attacks as it will stop at the Director and won’t be forwarded to your Front End server or Pool.
The Lync Director can be deployed with same topology options as mentioned in the Lync Edge section.
Reverse Proxy
The Reverse Proxy provide external access to the Lync IIS website by publishing the required URLs hosted by the Lync Front-end and Director.
With publishing those web services, you are allowing the remote users to have access and connect to meetings or dial-in conferencing using URLs query the address book, get client update, expand a distribution group and two more which I cannot remember while writing this article 🙂
So the “Simple URLs” that will be need to published using the Reverse proxy are:
Role | Services provided | Subject name syntax |
External web services – FQDN of the front end pool | Conference contentAddress book files
Client/device updates DG expansion |
Lyncwebext.lyncdude.net |
External Web services – FQDN of the Director pool | Same as above | LyncDirwebext.lyncdude.net |
Dial-in | Dial-in Conference information | Dailin.lyncdude.net |
Meet | Meetings URL | Meet.lyncdude.net |
Lync Discover | Lync auto discovery | Lyncdiscover.lyncdude.net |
Simple URLs are a way to make the URL used in conferencing easier for the users to understand. Where there is a Director pool in place, the URLs are published on the Director, this doesn’t mean replacing the Web services of your Front end pool with Director, Lync Director web services is published with the Lync Front end web service too.
Note: for meet URL you will need meet URL for each SIP domain you have in your deployments.
According to Tech Net there are three possible way to plan for your URLs, I will summarize them as following:
Simple URL naming Option 1:
You have a dedicated URL for each site as following, this option require a number of certificates or subject alternative name to support each URL.
&
https://meet.anotherdomain.com
Last URL is if you have another SIP domain in your deployment
Simple URL naming Option 2:
In this option, the URL is a virtual directory under the external web service URL (Called Shared Simple URL)
https://lyncwebext.lyncdude.net/meet/
https://lyncwebext.lyncdude.net/dialin/
&
https://lyncwebext.anotherdomain.com/meet
Last URL if you have another SIP domain in your deployment
If you publishing using Director pool (LyncDirwebext.lyncdude.net), you should use them for the reverse proxy.
https://lyncdirwebext.lyncdude.net/meet/
https://lyncdirwebext.lyncdude.net/dialin/
&
https://lyncdirwebext.anotherdomain.com/meet/
Simple URL naming Option 3:
This is one of the most efficient use of URLs, if you publishing the Front end web services then:
https://lyncwebext.lyncdude.net/lyncdude/meet/
https://lyncwebext.lyncdude.net/anotherdomain/meet/
https://lyncwebext.lyncdude.net/lyncdude/dialin
And if you have deployed Lync Director then use the Director web services to publish the URLs:
https://lyncdirwebext.lyncdude.net/lyncdude/meet
https://lyncdirwebext.lyncdude.net/anotherdomain/meet
2 Pingback