Skype4B/Lync certificate expiration time

I was at Modern Workplace Summit in Olso a week ago and did a presentation together with Fabrizio Volpe (@fabriziovlp) about security in Skype for Business. A part of my presentation touched upon the certificate based authentication used by Lync and Skype for business. After a twitter conversation with Randy Chapman (@randychapman) and Alexander Holmeset (Holmez85) I decided to write a short post about it.

Skype4B uses an authentication method called TLS-DSK which is a certificate based authentication. No it’s not client certificate authentication, it’s certificate based authentication. There is a very big difference and from a security perspective it’s important to understand that it’s not client certificate authentication.

When a client has authenticated to the server (Kerberos or NTLM) it gets a webticket. That webticket is then used to contact the Certificate Provisioning Service and retrieve a “Skype4B/Lync certificate”. This certificate is then used for subsequent authentications using TLS-DSK.

By default this certificate is valid for 180 days. This means that the client can use this certificate to retrieve new webtickets for 180 days. When a webticket is retrieved using the certificate, no check towards Active Directory user object is done. This means a locked AD account can retrieve webtickets without any problems. It’s only when an NTLM authentication is done that the AD is involved in the authentication process.

So the obvious question here is of course; “is there any way to set how long these certificates should be valid”? Yes there is, it can be done in PowerShell. This setting is a part of the web services configuration. The command below sets the expiration time of issued certificates to 24 hours.

Set-CsWebServiceConfiguration -Id site:site1 -DefaultValidityPeriodHours 24

Lync certificates and two-factor authentication considerations

Hello everyone. Time for another blog post. As you might have noticed, if you have read my other posts, I have been very focused on the security aspects of Lync. Today’s post is not any different in that aspect but it will focus on the standard Lync web service configuration when using any two-factor authentication for Lync.

As you probably know most Lync clients retrieve a certificate upon a successful authentication towards the Lync front-end server. This certificate, like any, has a validity time and by default this is set to 180 days. If we take a step back and analyze that we can clearly see how that doesn’t go well with two-factor authentication. We implement two-factor authentication to raise the security bar and most importantly to be absolutely sure that the user logging in to our Lync really is who he or she claims to be.

A user signs in using two-factor authentication. Then Lync provides the user with a one-factor authentication (the certificate) to be used for upcoming authentication purposes for 180 days. Kind of defeats the purpose to demand one two-factor authentication for 180 days. The tricky part is that upon an authentication the user is first given a webticket (by default valid for 15 minutes for external users and 8 hours for internal users), this webticket is then used as authentication to get the certificate. This certificate can then be used to get a new webticket and yes the webticket can then be used to get a new certificate… See where this is going?

So what can we do? Well first and foremost we can change the validity time of the certificates that Lync creates. The following command shows your current configuration.

Get-CsWebServicesConfiguration |DefaultValidityPeriodHours

DefaultValidityPeriodHours : 4320

By issuing the following command you set the validity period to 8 hours.

Set-CsWebServicesConfiguration –DefaultValidityPeriodHours 8

This will not stop a client from using either the webticket or the certificate to renew itself, however the time frame is much more limited. This is important because, from my experience, only the PC client is able to keep signed in for a very long time (if kept powered on and never is rebooted). The mobility clients are often in sleep state where this “renewal” does not happen and as such they are prompted for the two-factor again.

I’ve met quite some Lync customers that has a policy that state that the Lync PC client has to connect over VPN to get Lync access. Quite a nice policy.

Before wrapping up I would like to take a second and thank Graham Cropley (@grahamcropley) for an excellent blog post about Lync certificate provisioning and beyond – http://www.lyncexch.co.uk/lync-certificate-provisioning-service-deeper-dive/.

Thanks for reading! Stay tuned for more.