Certificate Authentication in Lync Server 2010 and Enterprise PKI

NextHop

NTLM, Kerberos, and TLS-DSK are the three available authentication packages for registered Lync endpoints. By default, all Lync clients and Lync telephony devices authenticate against Lync servers using the new authentication package, TLS-DSK. This article explains which features in a Lync Server deployment rely on TLS-DSK and what impact TLS-DSK has on enterprise PKI deployments.
The TLS-DSK authentication package uses an X.509 v3 certificate to authenticate an endpoint. The certificate used for this authentication is a self-signed client authentication certificate issued to the client by Lync Server. This certificate is found in the user’s personal certificate store in their Windows profile. The presence of this certificate in the environment can affect the behavior of some common PKI implementations.

Author: Nick Firsow, Microsoft Senior Service Engineer
Publication date: August 20, 2012
Product version: Microsoft Lync Server 2010, Microsoft Lync Server 2013 Preview

There are three authentication packages available to the Lync client when authenticating a registered endpoint in a Lync environment: NTLM, Kerberos, and TLS-DSK. By default, all Lync clients and Lync telephony devices authenticate against Lync servers using the new authentication package, TLS-DSK. This article explains which Lync features rely on TLS-DSK and what impact this TKL-DSK may have on enterprise PKI deployments.
For a detailed explanation of how security associations are established in SIP, and specifics on the TLS-DSK protocol, see the Protocol Document. This article doesn’t delve into the technical details of TLS-DSK. If you want a deep-dive session that explains how Lync 2010 works, watch the Tech-Ed 2010 session, Microsoft Lync 2010 Technology Explained.
The TLS-DSK authentication package uses an X.509 v3 certificate to authenticate an endpoint. The certificate is a self-signed client authentication certificate issued to the client by Lync Server. This certificate is found in the user’s personal certificate store in their Windows profile. The mere presence of this certificate in the environment can affect the behavior of some common PKI implementations. We discuss this in more detail later in this article.

Certificate Authentication Features

Certificate authentication in Lync Server technologies provides several desirable features.

  • Authentication with Lync when Active Directory is unavailable.
  • Ability to use a certificate instead of enterprise credential.
  • Quicker authentication.
  • Numeric Pin authentication.
  • Failover pool authentication during disaster recovery.

Certificate Authentication Overview

After initial authentication and provisioning of a client authentication certificate, the user’s credentials are not requested or presented to the Lync Server system. Subsequent logins to the system utilize the certificate provisioned during initial login. The Registrar pool maintains a copy of all valid certificates issued in the Lync environment. This enables administrators to revoke a certificate and centrally manage the Lync environment. The default life of a Lync client authentication certificate is 180 days. This option is configurable on the CS-WebServiceConfiguration by tweaking the values of MaxValidityPeriodHours and MinValidityPeriodHours. For more information on manipulating the web service configuration see Set-CsWebServiceConfiguration.
The first situation to address with certificate authentication results from the default 180 day Lync client certificate validity period. The certificate allows a Lync client to authenticate and interact regardless of the state of their Active Directory account, provided the account still exists. To say this a different way, if you disable a user account with the intent blocking access to all resources, just disabling the account does not affect the ability of this user account to continue to authenticate with an already provisioned Lync certificate. The user account will continue to have full access for the duration of the Lync client certificate. It is important to revisit the user provisioning/de-provisioning process to determine what affect this behavior has, and if necessary, disable the Lync user account using Set-CSUser.These commands are not data destructive. They deny access to the Lync environment and preserve the certificate on both the Lync client and in the Registrar store. In addition, it does not remove user data and policies and can easily be rolled back with Set-CSUser –identity <userID> -Enabled $true. For a compromised endpoint or a more permanent access revocation, use the Disable-CSUser and Revoke-CSClientCertificate cmd-let to ensure the access for a disabled account is removed from the Lync system.

Impact of Self-Signed Certificates on PKI Behavior

As mentioned above, enterprise PKI behavior can be impacted by the presence of the self-signed Lync client authentication certificate in the users’ personal certificate stores.
Certificate authentication can be described as a set of keys and locks. When presented with a locked door, you must present the correct key in order to unlock the door and gain access to the resources it protects. Likewise with certificate authentication, you may be presented with an option to choose the right certificate for authentication to a particular resource. Choosing the wrong certificate or key, in this example, yields Access Denied with the infamous big red X and subsequent helpdesk call and/or irate user.
When a sole certificate exists in the user’s personal certificate store, the operating system automatically selects the certificate and accesses the secured resource without prompting the user. Enterprises rely on this behavior because it permits the use of a master key certificate that unlocks all doors within the enterprise PKI design with minimal end-user education.
After a Lync certificate is placed in the user’s personal certificate store, this behavior changes. Note: the presence of multiple certificates for user-authentication can be desirable. The prompting mechanism is designed for situations where a particular user or workstation possesses multiple identities and a user selection is necessary.

EAP/802.1x authentication

In some instances, when the self-signed client authentication certificate for Lync is introduced to a customer environment where EAP/802.1x authentication is used for VPN and/or Wireless network access, the presence of two client-authentication OID certificates in the user store will produce a certificate picker dialog presented by the 802.1x enabled client. This dialog will request the user to pick the correct certificate to use for certificate based authentication. It has been confirmed that this behavior is the result of a logic bug in the certificate enumeration logic within Windows EAPHost system service. For Windows 7 and Windows 2008 R2 operating systems, this behavior has been corrected and a patch is available at You are Prompted to Select a Certificate when you Connect to a Wireless Network in Windows 7 or in Windows Server 2008 R2.

Client-Certificate Mapping for Web Sites

Like the previous EAP example, some websites are configured to require client-authentication certificates to establish the identity of the user accessing the website. Like the EAP/802.1x authentication process, when the client’s operating system enumerates the existing certificates for client-authentication present in the store, it finds multiple certificates and issues a prompt to the user to select the identity to assert to the remote system. This action is by design in scenarios where multiple client-authentication identities are found in the certificate store, and allows the user to select which certificate to present to the remote system. The only difference in this case is that there is no distinguishing criteria that separates these website client-authentication certificates from Lync self-signed certs.
The simplest way to address certificate issues is with end-user education that instructs users which certificates to select for which activities. This requires an element of computer savvy which non-technical computer users may struggle with, and ultimately can spike call volumes to support centers, and make the users dissatisfied with their computing experience.
If you are running Windows 7 SP1, there is a patch to address the EAP/802.1x scenario. The patch changes the behavior of the certificate picker to invalidate the Lync certificate from the list of available certificates for this access type.
Great, but there is still a large installed base of Windows XP and Windows Vista systems in the wild, what about those users? Unfortunately there is not a user certificate based PKI solution that prevents prompting from occurring. It is possible to configure EAP/802.1x authentication to use machine based certificates for authentication, and this is the recommended course of action for those operating system bases.

Configuring IIS to Provide Trusted Root Certificates

There is a more elegant solution for website client certificate mapping. If you are using Microsoft Internet Information Services (IIS), you can configure IIS to provide the Trusted Root Certificate list to the user during the sign in operation. IE automatically invalidates any certificates from the store which do not roll up to the root certificates in the Trusted Root List. Details for this configuration can be found at Clients Cannot Make Connections if you Require Client Certificates on a Web Site or if you use IAS in Windows Server 2003.
Other PKI designs, such as document/code signing, may be impacted by the presence of additional certificates in the user’s personal certificate store.

Things to Consider Before Eliminating Certificate Based Authentication

If you search for references to PKI issues on UC community blogs, you may discover that some blogs erroneously blame the Lync certificate for “breaking” the environment. Others suggest turning the certificate authentication off to solve the issue. Before you decide to eliminate certificate based authentication, consider the following points.

  • First, there are features you cannot use without certificate based authentication.
  • Second, you re-introduce a dependency that Active Directory must be available to service requests for the Lync system.
  • Third, the impact of removing certificates from client workstations must be addressed.

How to Disable Client Authentication

To disable certificate authentication, modify the certificate based authentication properties on all affected Lync Server 2010 pools. In the Lync Server 2010 Control Panel select Security settings. Remove the check from the Enable certificate authentication checkbox in both the Registrar (Figure 1) and Web Service (Figure 2) tabs.

Figure 1. Disabling the Registrar.

Figure 2. Disabling the Web Service.
You can also change the global configuration using the Lync Management Shell by executing the following commands:
For Registrar Configuration: Set-CSProxyConfiguration –UseCertificateForClientToProxyAuth $False
For Web Service: Set-CSWebServiceConfiguration –UseCertificateAuth $False
To clean up the Lync client, remove all traces of certificate authentication by removing the self-signed certificate from the user’s personal certificate store.

Figure 3. Remove self-signed certificates from the Certificate store.
After the certificate is removed, launch the Lync client and authenticate using the UPN or DomainUsername and password, and save the credentials. Users are prompted to provide subsequent login credentials to authenticate to SharePoint and Exchange Servers if those service hooks are configured in the Lync system.

Summary

Client certificate authentication in Lync Server 2010 has many benefits for service resiliency and security. Enterprise PKI design should be part of any Lync Server design and deployment discussion. Lync’s impact on existing enterprise PKI implementations should be understood prior to rolling out the Lync Client, because cleanup after-the-fact is a high-touch operation and resource intensive. If you decide certificate authentication does not fit with your enterprise PKI design, consider what features and benefits you are eliminating, and what options are no longer available to you.
There are no plans to change the architecture of Lync Server 2010 and Lync Server 2013 Preview to allow enterprises to use their own PKI for certificate based authentication against Lync. Office 365 Lync Online uses certificate based authentication as the sole authentication mechanism. Certificate based authentication is critical for cloud service functionality, provisioning and authentication and cannot be disabled for O365 customers.

Additional Information

To learn more, check out the following articles:

Lync Server Resources

We Want to Hear from You

Related Posts

Shopping Cart
Scroll to Top