Lync 2010 Client Authentication

From: http://blogs.technet.com/b/nexthop/archive/2012/11/28/lync-2010-client-authentication.aspx

Users have multiple options for login into Lync Server 2010. Users can use Lync 2010, Lync Web App, Lync Mobile, browser connecting to the simple URLs, and Lync Attendee. Each of these clients uses different protocols when authenticating the user to Lync Server. This article dives into the details of how each of these clients authenticates users to Lync Server.

Author: Rui Maximo Microsoft, Principal Writer and Fabian Kunz Connectis AG, Unified Communications and System Center solution architect

Publication date: November 27, 2012

Product version: Microsoft Lync Server 2010

Microsoft Lync 2010

Lync 2010 is the main desktop client for Lync Server 2010. I won’t cover how it discovers the user’s home pool through DNS discovery. My focus in this article is how Lync 2010 authenticates to Lync Server 2010 as this aspect of logic is often of interest to Lync administrators particularly when users connect from outside the corporate network.

Internal Users

When the user is inside the corporate network and signs in to Lync Server from a domain joined computer using their corporate Active Directory user account, Lync 2010 uses the following three protocols[1] to authenticate the user when signing in to Lync Server 2010:

• Kerberos v5
• TLS-DSK
• NTLM v2

A user connecting to Lync Server from inside the corporate network for the first time using a Lync 2010 client the user has never signed in from will experience the following authentication process.

The Lync 2010 internal user authentication process is as follows:

1. If the user has no certificate, Lync 2010 attempts to sign-in the user to Front-End Server using Kerberos (SIP traffic).
2. The Front-End Server rejects the authentication request, and redirects the Lync 2010 client to the Lync Web Services (https://lync.contoso.com/CertProv/CertProvisioningService.svc) to request a certificate (SIP traffic)
3. Lync 2010 authenticates the user to Lync’s Web Services using NTLM[2] (HTTPS traffic).
4. Once authenticated, Lync 2010 requests a certificate for the user (HTTPS traffic). This client certificate is then stored in the user’s Personal certificate store.
5. Lync 2010 re-authenticates the user to the Front End Server using TLS-DSK (SIP traffic).

For all subsequent sign-in requests, Lync 2010 authenticates to Lync Server using the TLS-DSK protocol with the user’s certificate instead of using Kerberos or NTLM. This user certificate is valid for a period of 180 days, and is automatically renewed one month prior to expiration regardless of whether the user is connected internally or externally. Jeff Guillet’s article Disabling a User in AD Does Not Disable the User in Lync provides a good background about revoking this certificate and properly disabling the user from accessing Lync services when their Active Directory user account is disabled.

If the internal user is unable to sign-in using Kerberos or TLS-DSK, Lync 2010 attempts to sign-in the user using the NTLM v.2 protocol. If the user logs in from a non-domain joined client the user must supply credentials. These credentials are stored in Credential Manager in the user’s local computer if the Save my password setting is checked and the user is not prompted for credentials at each sign-in. This covers the authentication logic for internal users, and is illustrated in Figure 1.

Figure 1. Authentication logic for internal users.

External Users

For remote users connecting over the SIP channel via the Edge Server, Lync 2010 can only use the following two authentication protocols[3]:

• TLS-DSK
• NTLM v.2

If the user doesn’t already have a certificate issued by Lync Server, then Lync 2010 will sign-in using NTLM v.2. Lync 2010 attempts to sign-in to Lync Server using the logged on user’s account. If the user is logged on to the computer using their corporate domain credentials, then the user is automatically signed in to Lync Server assuming the user is enabled for Lync.

If the user tries to sign-in to Lync Server from a computer that is not joined to the corporate domain, Lync 2010 prompts for credentials, and these credentials are stored in Credential Manager in the current user’s logon profile. If the Save my password checkbox is checked the user isn’t prompted for credentials the next time she signs in to Lync Server.

The Lync 2010 external user authentication process is as follows:

1. If the user does not have a certificate, Lync 2010 attempts to sign-in the user to Lync Server using NTLM through the Edge Server (SIP traffic).
2. The Edge Server rejects the authentication request, and redirects the Lync 2010 client to the Lync Web Services (https://lyncexternal.contoso.com/CertProv/CertProvisioningService.svc) through the reverse proxy to request a certificate (SIP traffic).
3. Lync 2010 authenticates the user to Lync’s Web Services using NTLM v2 (HTTPS traffic).
4. After authentication, Lync 2010 requests a certificate for the user (HTTPS traffic). This client certificate is then stored in the user’s Personal certificate store.
5. Lync 2010 re-authenticates the user through the Edge Server using TLS-DSK (SIP traffic).

This is illustrated in Figure 2.

Figure 2. Authentication logic for external users.

So, why does Lync 2010 still prompt for credentials from a modal dialog box? This authentication prompt is actually to authenticate to Exchange Web Services (EWS). In the absence of Outlook installed and running on the user’s computer, Lync 2010 also authenticates to Exchange to retrieve the user’s free/busy information, and so forth[4].

With a better understanding of how Lync 2010 authenticates the user to Lync Server both internally and externally, and where credentials are stored locally, experiment with the behavior of Lync 2010 by deleting the credentials in the Credential Manager and client certificate from the Personal store on a computer that is not joined to the corporate Active Directory domain.

For example:

• If a client certificate is already issued and stored in the user’s Personal store, then deleting the credentials used to authenticate to Lync Server in the Credential Manager will have no impact unless you as the Lync administrator prevent TLS-DSK authentication in Lync Server or revoke the certificate. Lync 2010 will use the client certificate to authenticate the user with Lync Server using TLS-DSK.
• If you delete the client certificate from the Personal certificate store, but not the credential in Credential Manager, Lync 2010 will use the credential stored in Credential Manager to authenticate the user using NTLM v2. Once successfully re-authenticated, a new client certificate will appear in the user’s Personal certificate store, and subsequent sign-ins will be authenticated using TLS-DSK.
• If you delete both the client certificate from the Personal certificate store and the credential from Credential Manager, Lync 2010 will prompt the user for credentials, and re-authenticate the user using NTLM v2. After successful authentication, a new client certificate appears in the user’s Personal certificate store, and subsequent sign-ins will be authenticated using TLS-DSK.

To keep things simple, these scenarios do not cover the authentication process Lync 2010 performs to validate the user with Exchange Web Services (EWS).

Credential Manager is found in the Control Panel under User Accounts (see Figure 3).

Figure 3. Credential Manager.

The user’s Personal Store is found in the Certificate Manager (see Figure 4).

Figure 4. Personal Certificates.

Lync Mobile (Android, WP7.5, iPhone, iPad)

The Mobility Service in Lync Server 2010 allows users to sign-in to Lync Server using a Lync Mobile client for any of the following clients – Windows Phone, Android, iPhone, and iPad. Users using a Lync Mobile client always connect through the corporate’s reverse proxy in the network perimeter because they are considered external users. Even when users are connected to the corporate’s WiFi network, best practice is to redirect connects to go through the external reverse proxy to maintain the integrity of the internal corporate.

One might assume that Lync Mobile clients connect to Lync Server using SIP similar to the desktop client, Lync 2010; however, this is an incorrect assumption. Lync Mobile network traffic to Lync Server is entirely web based, and therefore connects to the internal Lync Web Services through the reverse proxy that is located in the network perimeter. As such, Lync Mobile clients never connect to the Edge Server. All traffic goes through the reverse proxy.

Lync Mobile clients authenticate to Lync Server using NTLM authentication only specified in the Authorization field of the HTTPS request. Lync Mobile currently does not support other forms of authentication such as Kerberos, TLS-DSK, or Basic Auth. NTLM authentication with iPhone and iPad is slightly different. The binary message is packaged differently by Apple’s implementation of NTLM. I’m not sure why, but oddly enough it is.

Browser (Internet Explorer, Safari, Firefox, Chrome)

Browsers connecting to the Lync simple URLs can authenticate the user to access for example the dial-in URL. This user authentication request uses Basic Authentication. The authentication request is embedded in the SOAP envelop send to the Lync Server regardless of browser type.

Microsoft Lync Web App

Users without Microsoft Lync 2010, can still join Lync meetings using the Lync Web App[5]. Lync Web App is a Silverlight based web browser client that allows participants to join meetings hosted on Microsoft Lync Server 2010. This client authenticates to Lync Server Web Services using HTTPS through the reverse proxy. Users authenticate using Basic Authentication. However, this authentication process is different than with browsers. Instead of sending the user credentials in the SOAP envelop, the payload is specified in the Authorization field of the HTTPS request.

When anonymous users join a Lync meeting, the Digest protocol is used to authenticate these users. Anonymous users are external users who do not have credentials in the organizer’s Active Directory domain. Digest authentication is not used for other client interactions[6]. If anonymous users are authenticated using Digest, you might wonder what credentials these users use in that they are by definition anonymous and do not have an Active Directory account in the organizer’s domain. When the organizer creates a meeting invite, Lync Server generates a unique meeting ID. The meeting URL generated by Lync Server contains this meeting ID.

When the anonymous user logs in with the Lync Web App, the username it uses is an odd looking SIP URI called a Globally Routable User agent URI (GRUU). A SIP URI represents a Lync user. A GRUU is a SIP URI that represents a resource such as a particular device used by a Lync user. For example, a user may be signed in to Lync from her laptop and her mobile phone. A GRUU could represent the SIP URI of the specific mobile device she is logged in from, while another GRUU would represent the SIP URI of the Lync 2010 client running on her laptop.

In the case of an anonymous user joining a meeting using Lync Web App, this GRUU is composed of the SIP URI of the organizer appended by the string ‘;gruu;opaque=app:conf:focus:id:’ and the meeting ID. This looks like the following:

sip:[email protected];gruu;opaque=app:conf:focus:id:EF6AF0E2

Where EF6AF0E2 is the meeting specific ID. This GRUU specifies that this SIP URI targets an application resource of type conference (i.e. meeting). Thus, the string, ‘app:conf’, used in the GRUU to specify that the target resource is an application not a user or device.

For the password, the Lync Web App uses the meeting ID (e.g. EF6AF0E2) to login the anonymous user. The anonymous user is then placed in the lobby until the organizer or an authenticated user allows the anonymous user to enter the meeting.

Conclusion

Lync Server supports many different types of clients—from browsers to mobile client applications to desktop clients—that users can use to connect to Lync Server. Each type of client authenticates the user using different authentication protocols. Having a good understanding how each client authenticates the user to Lync Server will help secure your corporate network from unauthorized access.

Lync Server Resources

• Lync Server 2010 Documentation Library
• DrRez blog
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

[1] Lync Server can be configured to restrict specific authentication protocols

[2] It is possible to use Kerberos. To configure Kerberos authentication, see http://blogs.technet.com/b/jenstr/archive/2010/09/23/kerberos-and-microsoft-lync-server-2010-web-services.aspx

[3] Lync Server can be configured to restrict specific authentication protocols

[4] For a complete list: http://technet.microsoft.com/en-au/library/gg398806.aspx.

[5] Reference: http://office.microsoft.com/en-us/communicator-help/welcome-to-microsoft-lync-web-app-HA101908015.aspx

[6] Reference: http://technet.microsoft.com/en-us/library/gg195618.aspx