Securing your Edge Server with Lync Security Filter (or how to avoid NTLM-based Lync authentication over the Internet)
For some time now I have been arguing debating that the benefits of Lync Edge Services (specifically client access without the need for a corporate VPN) out-weigh the security concerns around exposing NTLM-based authentication over the web – we already have a lock-out policy defined within group policy and some times you need to take a more risk-based approach right?
Unfortunately I was fighting a losing battle, I knew that the only way I could ever win this debate was if I somehow managed to replicate the incumbant two-factor VPN authentication that was already being deployed, in our case RSA – I know don’t get me started right?
My thoughts have always been swayed towards computer-based certificates, this would be the most seamless way of reproducing a two factor scenario (i.e something you know – in my case succesful Windows logon to an encrypted Laptop and something you own – the locally installed cert), much the same as the network access protection setup we had deployed a year earlier. In essence this consisted of:
(a) authentication with Active Directory + (b) a valid computer certificate = (c) an enabled network switch port
This would be great for Lync!
There was a realisation today that I must have been sleeping under a rock as I came across an interesting “tweet” from Rui Maximo, specifically regarding a Lync Security Filter he had developed.
This add-on (which is installed on your Edge Server) offers the following:
- A soft lock-out policy you can enforce independently of your internal group policy settings (for value here you would need to set this below your internal lock-out threshold)
- UPN to Netbios normalisation (i.e. where your domain is contoso and your SIP FQDN is contoso.com)
Last but not least…
- The ability to disable NTLM v.2 authentication altogether, failing back to TLS-DSK-only authentication!
So what’s TLS-DSK?
Taken from the Lync Security Filter Documentation:
“Lync Server 2010 introduces support for an additional authentication protocol called TLS-DSK. This requires users to supply a client certificate for authentication. The Lync client requests certificates from Lync Server. This is an automatic process that happens the first time the user signs in to Lync Server from within the corporate network where the user is authenticated using Kerberos.
This client certificate is used for authentication with any subsequent log-in attempts. This is a self-signed certificate issued by Lync Server, not a Certificate Authority. If that same user tries to sign in to Lync from a different computer, he’s authenticated using Kerberos (if inside the corporate network) or using NTLM v2 (if outside the corporate network). The process of obtaining another client certificate starts all over.
TLS-DSK provides a level of security that’s very close to two-factor authentication. When combined with Windows BitLocker, the computer or laptop acts as the equivalent of a smartcard (something you have). The password that BitLocker requires to boot your computer is equivalent to the pin required to authorize the use of the smartcard (something you know).
There’s the remote possibility someone could steal the client certificate from the user’s computer, but you can mitigate this risk. Make sure corporate-issued computers are locked down to prevent users from downloading unauthorized applications.
You can force the Edge Server to negotiate the authentication protocol down from TLS-DSK to NTLM v2. In this case, the attacker can still target the user’s account, as discussed earlier. To prevent this scenario, the security filter provides an option to reject all NTLM v2 authentication requests, forcing TLS-DSK-only authentication. This doesn’t affect federated partner connections or PIC connections.”
In essence this Edge Server add-on completely mitigates the risk of allowing NTLM v.2 authentication over the web, burn turning it off. The only draw back here is that initial client logons will need to take place inside your corporate network (or directly between the Lync client and the Lync Front End Server).
Download: here
Nice one Rui! 🙂
Related Content:
For more on Lync Edge Server Security I’d recommend you read Rui’s guide on TechNet here
Thanks for blogging about the security filter, Adam. Let me know if you have any feature requests. I’ve been actively incorporating customer feedback for the past 2 years.
regards,
rui
A pleasure Rui. As you can probably tell from my blog post, I’m extremely pleased to see that there is a way of securing Edge Services, specifically a way of mitigating NTLM brute force attacks.
Many thanks.
– Adam
thanks, very interesting, especially the extra hint to the TLS-DSK.
How would this work in a mobile scenario where my users have personally owned iPad’s with the Lync client? These iPads will not be connected to the corporate network to get the cert.
Hi Alan,
Great question, the Lync Mobile Client does not utilise TLS-DSK as connections are made via the MCX service and not the Edge Server.
– Adam
if TLS-DSK authentication is mandated through the use of the Security Filter, is there any impact to the end user experience? ie. what happens when a corporate user takes their work laptop and connects in via the Edge Servers? Do they still logon automatically without entering user credentials etc?
Does anyone have a diagram or how the Lync client authentication process works (with TLS-DSK)… that would be useful.
Hi James,
The only difference to the end-user experience, as I understand it, is that the initial authentication would need to be carried out internally – NTLM is an initial requirement for certificate provision. For more on this (and a diagram), I’d suggest you take a look at Rui’s documentation here
– Adam
Yes, I’ve been in conversations with Rui, and this is my understanding now. This isn’t a problem in our environment, and is in fact the desired outcome. We want new Lync machines to provisioned onsite, and then to restrict the subsequent external connections (via the Edge) to only those PCs, blocking connections from non-domain joined machines that don’t have the necessary client cert.
All sounds good… time to test 🙂