Securing your Edge Server with Lync Security Filter (or how to avoid NTLM-based Lync authentication over the Internet)

January 5th, 2012 | Tags: ,

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

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