Microsoft Lync/Skype for Business has revolutionised the way people can communicate and collaborate in the workplace. With light weight and portable form factors coming into their own, devices have enabled businesses to rethink their communication strategy. Lync not only enables users to communicate using great device form factors, but also from wherever they may be located. The sense of a roaming lync identity brings freedom to how people choose to collaborate and office spaces, desks and name tags mounted above them, seem like a necessity of the past. The enablement of remote connectivity across these devices is pivotal in a Lync deployment, but sometimes isn’t entirely understood. In some circumstances security is of high concern for all forms of connectivity that can be done over the public internet, but you wouldn’t want to go without it. To remove remote access for users would be crippling the UC strategy that you were trying to put in place.
When we think about Lync/SFB with external authentication we first must articulate that there’s more than one form of authentication a user can attempt and there is many device types they can attempt authentication with. Therefore it can also be said that there is more than one endpoint and port on the edge of the corporate network listening, waiting and proxying these forms of authentication. What we need to do is make sure that each case is in a controlled and known measure to best suit your deployment.
Question: “So Arran what is secure?”
Answer: “Well the security policy should govern what is and isn’t classified as secure for you.”
The common device(s) attempting authentication are:
- Lync Office Client
- Mobile/Tablet app
- Windows 8 Store App
With these authentication types:
- Passive (ADFS)
We aren’t going to talk about Kerberos cause we are concerned with external logins.
NTLM is usually well understood as a simple challenge/response authentication but if we look at it in Lync it means that every time a web ticket expires the same challenge authentication must be presented. Usually to make this simple to the end-user we allow them to cache/save the password to the device for re-authentication on our behalf.
NTLM will generally be a big ‘NO’ straight away if these conversations have started with a security team, so let’s look at Transport Layer Security Derived Session Key (TLS-DSK) as a certificate based authentication. Every Lync Front End Server is issuing a Lync User Certificate upon initial successful authentication and once the certificate is saved, the stored AD Credentials aren’t needed for the validity of the certificate which can range from 8 hours to 365 days (your choice). A key point to make about TLS-DSK is that if I have multiple devices I will receive my certificate for each. I will then use my certificate on each device to authenticate to Lync as me. Additionally the certificate I have stored is only trusted by Lync, not my entire domain or ADFS and can’t be used across other application or services.
TLS-DSK allows us to move away from the simple challenge authentication and subsequent re-authentications all together.
TLS-DSK is great!
By disabling NTLM on external registration (shown in the diagram above with Green – Internal and Blue -External) we can then understand that a client has to have obtained a Lync certificate from the internal Front End Servers when on-premises and not provisioned through an Edge proxy. The certificate can NOT be issued from external locations due to the authentication process breaking when the client requests a web ticket to start the process. Currently Skype for Business does not do this natively. The client NTLM authentication against the web services is via the Simple URLs which is controlled via a Reverse Proxy. Currently there are only a few out the box solutions for this, Lync Solutions and Skype Shield are worth investigating.
If you go the extra mile to not allow NTLM authentication from your external network, you are then protected via additional forms of on-premises security;
- The individual has gotten physical access to a site location through a perimeter locked entrance
- The individual has gotten network layer 2 connectivity with a device on a access switch
- The individual has an approved domain joined computer to gain access to domain services on the appropriate VLAN
- The individual has supplied correct credentials of a provisioned Lync user account.
Sounds like a job for Tom Cruise hanging from the roof if you ask me. The end result is a Lync user certificate in the user store of the trusted machine. We should now be happy for the user to go out in the world with this device knowing that themselves and the managed device are who we think.
What if you would NOT like Lync to do any authentication.
“I have a centralised authentication services called Active Directory Federation Services (ADFS) and I would like to use it with Lync”.
Lync can be integrated with ADFS as your Secure Token Service (STS) and also provide a second factor if needed. You can then leverage forms based authentication or smart cards. There are a few tricks to enabling Lync Server with passive authentication, first of all to enable passive we must disable all other forms of authentication. As this is a ‘big bang’ approach to effectively disable all other authentication protocols per pool make sure you plan and test appropriately.
Lync Mobile Clients
Lync is a free download in each of the mobile stores and we can’t control if a trusted or untrusted device downloads it. So for our external access of the Lync 2013 mobile client we must feel comfortable with the authentication, which comes in the 3 forms that are available;
- Lync Certificate
NTLM once again maybe too basic to meet our requirements and we need to look at what else is on offer, James Frost has a great comment at the bottom of this post about products that can be used. As James points out that the certificate web service URL is exposed to the internet via the reverse proxy you are using. Depending on what type of device you are using will indicate what might be possible for you to achieve with validation of approved devices or authentication attempts. The reverse proxy is breaking the connection from front to backend and this is a perfect time to inspect it if necessary. ADFS can be a big leap just to comply with remote authentication with the Lync app, instead we can protect our users and devices via whipping the initial NTLM credentials from the devices disk and memory via PowerShell mobility in band provisioning policy;
Set-CsMobilityPolicy -AllowSaveCredentials <$true/$false>
We can also disable EWS requests which does simple NTLM requests to exchange inside the app also;
Set-CsMobilityPolicy - AllowExchangeConnectivity <$true/$false>
Where does the authentication happen?
When I stated that there is “more than one endpoint on the edge of the corporate network, waiting and proxying these forms of authentication” this is because clients behave differently. Lync Office Client directs its authentication requests to the Lync Edge servers with SIP over TLS, while all mobile device apps will use a reverse proxy that has a published URL rule as all its signalling traffic is SIP over HTTPS while on a 3G/4G data network. So there is more then one ingress point for authentication to monitor. The Edge Server is inspecting all packets, while a Reverse Proxy can inspect the HTTPS traffics as it’s also splitting the traffic from frontend to backend.
Options are available to change the way Lync can authenticate to your network. A greater understanding of the authentication endpoints, protocols and flows will aid you in being on top of your environment and smoothly rolling out external devices that are secure and trusted.